Need help getting Derby running in JUnit

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Need help getting Derby running in JUnit

tbbstny
I set properties for Derby in my setUpClass method as explained in the
"Configuring DataSources in Tests" documentation.  When I run the tests, the
only thing I can see about my datasource in the output is a line similar to what
I've pated in below.  I do get notice that my EJB's loaded and can to a lookup
on the EJBs but not the DataSource.  I'd try to do the lookup like so:
 initialContext.lookup("MYDB").

I am not using JPA, so do not have a persistence.xml file.  As I am embedding
things directly into the JUnit test class(es), it is my understanding I
shouldn't need any any other xml files either - like the openejb.xml or
jndi.properties, etc.  Will I require a persistence.xml file just for my JUnit
tests?  Hoping it's something easy you can point me to.

- Configuring Service(id=MYDB, type=Resource, provider-id=Default JDBC Database)
TIA
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

dblevins
Administrator
On Mon, Nov 22, 2010 at 3:54 PM, Tony Tubbs <[hidden email]> wrote:

> I set properties for Derby in my setUpClass method as explained in the
> "Configuring DataSources in Tests" documentation.  When I run the tests, the
> only thing I can see about my datasource in the output is a line similar to what
> I've pated in below.  I do get notice that my EJB's loaded and can to a lookup
> on the EJBs but not the DataSource.  I'd try to do the lookup like so:
>  initialContext.lookup("MYDB").
>
> I am not using JPA, so do not have a persistence.xml file.  As I am embedding
> things directly into the JUnit test class(es), it is my understanding I
> shouldn't need any any other xml files either - like the openejb.xml or
> jndi.properties, etc.  Will I require a persistence.xml file just for my JUnit
> tests?  Hoping it's something easy you can point me to.
>
> - Configuring Service(id=MYDB, type=Resource, provider-id=Default JDBC Database)

If you want to use a non-portable name, your bean can lookup
"openejb:Resource/MYDB".

If you want to do things the portable way, your bean has to declare a
reference to the resource via xml or annotation:

  http://openejb.apache.org/3.0/resource-ref-for-datasource.html

This doc is still a work in progress, but has some info on Java EE and JNDI:

  http://openejb.apache.org/3.0/basics-getting-things.html


-David
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

tbbstny
> If you  want to use a non-portable name, your bean can  lookup

> "openejb:Resource/MYDB".

OK, tried this first, and the lookup worked.


> If you want to do things the portable  way, your bean has to declare a
> reference to the resource via xml or  annotation:
>   http://openejb.apache.org/3.0/resource-ref-for-datasource.html

Following those instructions, I changed the ejb-jar.xml to look like this:
(This appears to look right compared to other snippets I've found in the mail
list archives too)

<ejb-jar>
    <resource-ref>
        <res-ref-name>MYDB</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
    </resource-ref>
<ejb-jar/>


Now nothing is loaded, and I am getting this error:

[severity=ERROR,message=unexpected element
(uri:"http://java.sun.com/xml/ns/javaee", local:"resource-ref"). Expected
elements are
<{http://java.sun.com/xml/ns/javaee}assembly-descriptor>,<{http://java.sun.com/xml/ns/javaee}ejb-client-jar>,<{http://java.sun.com/xml/ns/javaee}icon>,<{http://java.sun.com/xml/ns/javaee}display-name>,<{http://java.sun.com/xml/ns/javaee}interceptors>,<{http://java.sun.com/xml/ns/javaee}description>,<{http://java.sun.com/xml/ns/javaee}enterprise-beans>,<{http://java.sun.com/xml/ns/javaee}relationships>,locator=[node=null,object=null,url=null,line=3,col=19,offset=-1]]



> This doc is still a work in progress, but has some info on Java EE and JNDI:
>  http://openejb.apache.org/3.0/basics-getting-things.html

I've read a few times.  Do I understand correctly that I will not be able to use
the same JNDI names in OpenEJB inside JUnit that I'm using when deployed to
JBoss?  For example, my JNDI name for my datasource when deployed would be
"java:/MYDB", and my EJB might be "java:comp/env/ShortcutFacade".

Besides the ejb-jar.xml file, I have OpenEJB included as part of my test
libraries, and my setUpClass method includes this:

            // Create initial context
            Properties properties = new Properties();
            properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
            properties.put("MYDB", "new://Resource?type=DataSource");
            properties.put("MYDB.JdbcDriver",
"org.apache.derby.jdbc.EmbeddedDriver");
            properties.put("MYDB.JdbcUrl",
"jdbc:derby:memory:DerbyDB;create=true");
            properties.put("MYDB.JtaManaged", "false");
            ic = new InitialContext(properties);
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

tbbstny
In reply to this post by dblevins
> From: David Blevins <[hidden email]>

> If you want to do things the portable  way, your bean has to declare a
> reference to the resource via xml or  annotation:
>
>   http://openejb.apache.org/3.0/resource-ref-for-datasource.html
>
> This  doc is still a work in progress, but has some info on Java EE and  JNDI:
>
>   http://openejb.apache.org/3.0/basics-getting-things.html

I'm confused.

- Re: link #1 above.  The example code is NOT passing parameters to the "new
InitialContext()" call as explained to do for JUnit testing elsewhere.  From
link #2, I understand this to be necessary if I want to make use of the
"java:/comp/env..." naming used throughout my code base.  What I don't
understand is how do I use a parameter-less constructor call in JUnit and get
OpenEJB to load up when I do so?

- If that is not possible, then what tricks do you use that allows the code to
work in the container when deployed (JBoss in my case), but will still work with
OpenEJB in JUnit?


Still trying to get some sort of xml configuration to work for 'a more portable
way', I've stubbed out the following ejb-jar.xml.  It loads w/o errors, but I
can still only do lookups using "openejb:Resource/WTSHARE" for my datasource and
the simple class name for the EJBs  (i.e.  just "AdvisorListFacadeLocal" not
"java:comp/env/AdvisorListFacade" as desired).  Given this xml, I can now do two
different lookups on my EJB, the one identified in the xml below, and the
auto-loaded name set by OpenEJB.

            ic.lookup("AdvisorListBeanLocal");  // via XML
            ic.lookup("AdvisorListFacadeLocal");// via auto-load by OpenEJB

<?xml version="1.0"?>
<ejb-jar>
    <enterprise-beans>
        <session>
            <ejb-name>AdvisorListBean</ejb-name>
           
<business-local>com.dstsystems.walletshare.ejb.facade.AdvisorListFacadeLocal</business-local>

           
<ejb-class>com.dstsystems.walletshare.ejb.jdbc.AdvisorListFacade</ejb-class>
            <session-type>Stateless</session-type>
            <transaction-type>Bean</transaction-type>

            <resource-ref>
                <res-ref-name>WTSHARE</res-ref-name>
                <res-type>javax.sql.DataSource</res-type>
                <res-auth>Application</res-auth>
            </resource-ref>

        </session>
    </enterprise-beans>
</ejb-jar>

Where am I going wrong?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

dblevins
Administrator
In reply to this post by tbbstny
On Tue, Nov 23, 2010 at 5:41 AM, tbbstny <[hidden email]> wrote:
>> This doc is still a work in progress, but has some info on Java EE and JNDI:
>>  http://openejb.apache.org/3.0/basics-getting-things.html
>
> I've read a few times.  Do I understand correctly that I will not be able to use
> the same JNDI names in OpenEJB inside JUnit that I'm using when deployed to
> JBoss?  For example, my JNDI name for my datasource when deployed would be
> "java:/MYDB", and my EJB might be "java:comp/env/ShortcutFacade".

The "java:comp/env" names used by the EJBs are portable and usable in
JBoss or any application server.  The "java:/MYDB" lookup is JBoss
specific. For all intense purposes imagine it as "jboss:/MYDB"

> Besides the ejb-jar.xml file, I have OpenEJB included as part of my test
> libraries, and my setUpClass method includes this:
>
>            // Create initial context
>            Properties properties = new Properties();
>            properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.openejb.client.LocalInitialContextFactory");
>            properties.put("MYDB", "new://Resource?type=DataSource");
>            properties.put("MYDB.JdbcDriver",
> "org.apache.derby.jdbc.EmbeddedDriver");
>            properties.put("MYDB.JdbcUrl",
> "jdbc:derby:memory:DerbyDB;create=true");
>            properties.put("MYDB.JtaManaged", "false");
>            ic = new InitialContext(properties);

In the testcase itself, I'd simply use the "openejb:Resource/MYDB".
In Java EE 5 there's no way to make a portable test case.

Will try to give more detail in the reply to the other message.

-David
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

dblevins
Administrator
In reply to this post by tbbstny
On Tue, Nov 23, 2010 at 7:23 AM, Tony Tubbs <[hidden email]> wrote:

>> From: David Blevins <[hidden email]>
>
>> If you want to do things the portable  way, your bean has to declare a
>> reference to the resource via xml or  annotation:
>>
>>   http://openejb.apache.org/3.0/resource-ref-for-datasource.html
>>
>> This  doc is still a work in progress, but has some info on Java EE and  JNDI:
>>
>>   http://openejb.apache.org/3.0/basics-getting-things.html
>
> I'm confused.
>
> - Re: link #1 above.  The example code is NOT passing parameters to the "new
> InitialContext()" call as explained to do for JUnit testing elsewhere.  From
> link #2, I understand this to be necessary if I want to make use of the
> "java:/comp/env..." naming used throughout my code base.

Correct on both counts.  And the implication as you notice is that you
cannot use "java:comp/env" lookups in your test case, just your EJBs.

Bottom line is that your testing code and your production code will be
using slightly different techniques to lookup things.  The testcase
will use the LocalInitialContextFactory approach and the EJBs will use
the no-arg "new InitialContext()" approach.

Why can't we make "java:comp/env" lookups work in a test case?  Well
the short answer is this aspect of JNDI was very badly designed.  The
"java:comp/env" namespace is not a global namespace, but relative to
each EJB.  So one EJB can define "java:comp/env/Foo" to point to a
datasource, while another EJB in the exact same jar can define
"java:comp/env/Foo" to point to say a JMS topic.  Under the covers the
container has to use ThreadLocals and similar to techniques to know
"who's asking" and what the lookup should return.

So if a testcase were to lookup "java:comp/env/Foo", what would the
desired behavior be?  Do they get the DataSource or the JMS Topic?  If
there are three EJBs we will have three separate "java:comp/env"
namespaces, each possibly conflicting.  Do we just pick one randomly?
Maybe we should at support so the testcase can define its own
"java:comp/env" like each EJB can?  Bottom line in that regard is it
would still be vendor specific, so it really isn't anyone's best
interests for us to make vendor specific behavior falsely appear to be
portable.

In Java EE 6 there are new namespaces, "java:global/", "java:app/" and
"java:module/" and each is scoped.  In the future, the testcase will
be able to lookup via "java:global" or "java:app".  The downside is
that there are more namespaces to think about and learn how to
configure.

 - - - Non lookup approach - - -

If you cut out JNDI and use injection instead, you can get a lot of
that complexity out of both your production code and your testcases
for your production code.

Here's an example that shows dependency injection of a datasource in an EJB:

http://openejb.apache.org/3.0/injection-of-datasource-example.html

You can get the same kind of injection into the testcase itself via a
slightly different technique:

http://openejb.apache.org/3.0/local-client-injection.html

There's an example for that one in the examples zip as well in the
"testcase-injection" dir.

> Still trying to get some sort of xml configuration to work for 'a more portable
> way', I've stubbed out the following ejb-jar.xml.  It loads w/o errors, but I
> can still only do lookups using "openejb:Resource/WTSHARE" for my datasource and
> the simple class name for the EJBs  (i.e.  just "AdvisorListFacadeLocal" not
> "java:comp/env/AdvisorListFacade" as desired).

The xml looks fine, but if you didn't use the no-arg "new
InitialContext()" in the EJB code that does the lookup than no
"java:comp/env" lookups will work.

It's also possible to set things up to use the annotation approach and
then instruct OpenEJB to spit out an equivalent xml descriptor via
setting the "openejb.descriptors.output" system property to "true".
It can also be specified in the InitialContext params. So even if
there was a strong desire to not use annotations, you could still use
them long enough to get OpenEJB to create all the xml for you.  After
which point you can just keep the xml and loose the annotations.

Hope this helps!


-David
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

tbbstny
> From: David Blevins <[hidden email]>
>
> If you cut out JNDI and use injection instead, you  can get a lot of
> that complexity out of both your production code and your  testcases
> for your production code.


Thanks for the hints!  I think I understand what you've said, but will need to
think on this some.  I'll get back to it next week.  This is all new to me, and
it's not yet clear where I am getting all the functionality.  NetBeans hides
much of the code-by-configuration, so when I have to get into it myself, it gets
hard.  I have a very risk adverse legal department that greatly restricts the
use of open source directly or embedded.  This is partly why I am not using JPA,
and because I'm not, I do not have EclipseLink, TopLink, etc in the project.
 I'm not sure now, but I think when I removed those libraries, that forced me to
remove the annotations such as @EJB.  I don't recall having made use of
@Resource.  

Also, I have an EAR project which contains an ejb jar and a war project.  The
war is making use of the EJBs out of the ejb jar.  It is my understanding that
the @EJB sort of injection does not work across projects that way (at least I
couldn't get it to work).  So, I'm using <ejb-local-ref> in my web.xml file.
 I haven't tried, but perhaps with my test cases still inside my ejb jar, I
could make use of the @EJB annotation there.


> The xml looks fine, but if  you didn't use the no-arg "new
> InitialContext()" in the EJB code that does  the lookup than no
> "java:comp/env" lookups will work.


Hmm...  I'm confused again.  I did try to use OpenEJB context in my EJBs.  The
no-arg constructor does not work in JUnit (I thought and how I came to find
OpenEJB) because there is no container, so I'm embedding OpenEJB to serve that
purpose, but to do so I'm unable to use the no-arg constructor.  I think there's
some bit of information right here in front of me, but I'm not making the
connection.  Perhaps you are saying that by embedding OpenEJB and passing the
properties object in the constructor, when it then loads it also causes the
no-arg version to start working too.  Will have to experiment with that.

> It's also  possible to set things up to use the annotation approach and
> then instruct  OpenEJB to spit out an equivalent xml descriptor via
> setting the  "openejb.descriptors.output" system property to "true".
> It can also be  specified in the InitialContext params. So even if
> there was a strong desire  to not use annotations, you could still use
> them long enough to get OpenEJB  to create all the xml for you.  After
> which point you can just keep the  xml and loose the annotations.


This sounds helpful.  Will have to look into this for sure.  I can make use of
anything I need to locally (EclipseLink or whatnot) to get things configured and
strip stuff back out again if necessary.  

Thanks again for the help.  It is much appreciated.
TT
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

tbbstny
In reply to this post by dblevins
> From: David Blevins <[hidden email]>

>
> Correct on both counts.  And the  implication as you notice is that you
> cannot use "java:comp/env" lookups in  your test case, just your EJBs.
>
> Bottom line is that your testing code and  your production code will be
> using slightly different techniques to lookup  things.  The testcase
> will use the LocalInitialContextFactory approach  and the EJBs will use
> the no-arg "new InitialContext()" approach.

Still not able to do EJB lookup using OpenEJB inside a JUnit test.  Below is my
actual code.  

- The lookup is failing
- Noticed that in the stack trace, openejb is referenced, even though I used the
no-arg initial context for the EJB stuff.  Appearantly something about embedding
it in the test case setup does cause OpenEJB to be used with the no-arg version
as well???
- I'm assuming that I have to tell OpenEJB somehow to use the java:comp/env
name?
- Further assuming I tell OpenEJB this via the ejb-jar.xml file  (Currently
JBoss gets this from <ejb-local-ref> blocks in web.xml, should I remove that in
favor of ejb-jar.xml???)
- Tried including "java:" in my ejb name in the ejb-jar.xml file, but get an
error that ':' is an invalid character.  



So, here's the code that's failing and some of the output (trimmed to the
relevant parts)...

JNDI name I've been using with JBoss w/o problems & want my tests to make use of
as well
-----------------------------------------------------------------------------------------

java:comp/env/ProductFamilyRegistrationFacade


One entry in the ejb-jar.xml - trying to setup the same name
-----------------------------------------------------------------------------------------

<?xml version="1.0"?>
<ejb-jar>
    <enterprise-beans>
        <session>
            <ejb-name>comp/env/ProductFamilyRegistrationFacade</ejb-name>
             
<business-local>com.<<snipped>>.ejb.facade.ProductFamilyRegistrationFacadeLocal</business-local>

           
<ejb-class>com.<<snipped>>.ejb.jdbc.ProductFamilyRegistrationFacade</ejb-class>
            <session-type>Stateless</session-type>
            <transaction-type>Bean</transaction-type>
        </session>
    </enterprise-beans>
</ejb-jar>


Failing JUnit test
-----------------------------------------------------------------------------------------

    @Test
    public void testCallStoredProcedure() {
        System.out.println("callStoredProcedure");
        IProcedureEntity sp = new ProductFamilyRegistrationProcedure(new
BigDecimal("0"));
        int expResultSize = 0;
        List result = EJBUtils.callStoredProcedure(sp, DataHandler.OPEN_DATA);
    }



Output Window
-----------------------------------------------------------------------------------------

...
INFO - Auto-creating a container for bean
comp/env/ProductFamilyRegistrationFacade: Container(type=STATELESS, id=Default
Stateless Container)
...
INFO - Jndi(name=comp/env/ProductFamilyRegistrationFacadeLocal) -->
Ejb(deployment-id=comp/env/ProductFamilyRegistrationFacade)
...
INFO - Created Ejb(deployment-id=comp/env/ProductFamilyRegistrationFacade,
ejb-name=comp/env/ProductFamilyRegistrationFacade, container=Default Stateless
Container)
...
callStoredProcedure
lookupStoredProcedure: java:comp/env/ProductFamilyRegistrationFacade
Nov 29, 2010 8:10:15 AM com.<<snipped>>.EJBUtils lookupStoredProcedure
SEVERE: exception caught
javax.naming.NameNotFoundException: Name
"comp/env/ProductFamilyRegistrationFacade" not found.
        at
org.apache.openejb.core.ivm.naming.IvmContext.federate(IvmContext.java:193)
        at
org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:150)
        at
org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:124)
        at javax.naming.InitialContext.lookup(InitialContext.java:392)
        at com.<<snipped>>.EJBUtils.lookupStoredProcedure(EJBUtils.java:33)


Helper method
-----------------------------------------------------------------------------------------

    private static IProcedureFacade lookupStoredProcedure(String jndiName) {
        System.out.println("lookupStoredProcedure: " + jndiName);

        try {
            InitialContext c = new InitialContext();                      // <==
using no-arg version here
            return (IProcedureFacade) c.lookup(jndiName);         // <== Line 33
referenced in output above; Name not found exception
        } catch (NamingException ne) {
            Logger.getLogger(EJBUtils.class.getName()).log(Level.SEVERE,
"exception caught", ne);
            throw new RuntimeException(ne);
        }
    }
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Need help getting Derby running in JUnit

tbbstny
In reply to this post by dblevins
OK, I've written some tests using the "openejb:Resource/MYDB" lookup syntax as
suggested.  My tests are running fine, but they never stop.  I can see all I
expect to see in the output window, but they just never stop running.  If I
manually stop them, they are all green.  In looking at threads and noticing some
exceptions along the way, it seems to me that embedding OpenEJB in JUnit also
caused some connection pools to be in use for my derby connections.  My guess is
the pools are not being released for some reason.  Can I just stop Open EJB in
the tear down?  How would I do that?

Thanks,
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

tbbstny
Found the following thread about shutting down OpenEJB programatically here:
http://www.mail-archive.com/users@.../msg00920.html

Says there is a close on the InitialContext that will shut it down.
I attempted to make this call in my @AfterClass method, but it is never called
because something is hanging before the JUnit can get this far in the process.

Any ideas why introducting OpenEJB would cause my tests to hang now?  How to fix
that?

TIA,




----- Original Message ----
> From: tbbstny <[hidden email]>
> To: [hidden email]
> Sent: Mon, November 29, 2010 9:54:50 AM
> Subject: Need help getting Derby running in JUnit
>
> OK, I've written some tests using the "openejb:Resource/MYDB" lookup syntax as

> suggested.  My tests are running fine, but they never stop.  I can  see all I
> expect to see in the output window, but they just never stop  running.  If I
> manually stop them, they are all green.  In looking  at threads and noticing
>some
>
> exceptions along the way, it seems to me that  embedding OpenEJB in JUnit also

> caused some connection pools to be in use  for my derby connections.  My guess
>is
>
> the pools are not being released  for some reason.  Can I just stop Open EJB in
>
> the tear down?  How  would I do that?
>
> Thanks,
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

dblevins
Administrator
In reply to this post by tbbstny
On Mon, Nov 29, 2010 at 6:31 AM, Tony Tubbs <[hidden email]> wrote:
>
> Still not able to do EJB lookup using OpenEJB inside a JUnit test.  Below is my
> actual code.
[...]
> Failing JUnit test
> -----------------------------------------------------------------------------------------
>
>    @Test
>    public void testCallStoredProcedure() {
>        System.out.println("callStoredProcedure");
>        IProcedureEntity sp = new ProductFamilyRegistrationProcedure(new
> BigDecimal("0"));
>        int expResultSize = 0;

Your testcase should be using a lookup and not 'new MyEjb'.  Doesn't
matter if the testcase lookup isn't portable, you stil need to use a
lookup to get any EJB features.  This could be the source of your
shutdown issues.  As well it looks like your ejb-jar.xml is attempting
to give the ejb the name
"java:comp/env/ProductFamilyRegistrationFacade" without using an
"<ejb-local-ref>" as noted in one of the other links I showed.

I think I have you far more confused and off in the wrong direction
than in the right direction :)  Very understandable as this is the
least intuitive aspect of Java EE and is very hard to explain and
learn.

I took another stab at a better doc:

  https://cwiki.apache.org/OPENEJBx30/lookup-of-other-ejbs-example.html

I setup this example to be deliberately confusing as possible and
challenge common false assumptions, but I've also tried to explain as
best as possible.  Maybe we can shift things away from your code for a
moment and spend some time discussing any aspects of this example that
you find confusing -- my hope is it can help us flush out some good
questions and answers.


-David
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

tbbstny
> From: David Blevins <[hidden email]>

> Your testcase should be using a lookup and not  'new MyEjb'...  

It is, just under the covers.  More below.

> This could be the  source of your shutdown issues.  

Maybe, but I am thinking not.  Seems to happen only if I interact with Derby.  
The following line of code will cause it to hang every time, but I get hangs
even with this line removed.  Still trying to tack this down.  This code is
inside one of the Derby jar files (ie not my code), is suppose to clean up any
thing in my database, and I was calling it in my @Before method to start with a
clean db before each test.  I googled the code and could not find anything I
though was suspicious.  I notice that when it is hung up, my threads window
consistently shows 16 PoolEviction and a Timer-1.  If I remove OpenEJB from the
test case all of those no longer show up in the threads window.  I don't know
what to make of that, but maybe you'll see something in it?

// Always causes JUnit to hang when integrating Derby with OpenEJB
CleanDatabaseTestSetup.cleanDatabase(c, false);


> I think I have you far more confused and off in the wrong  direction
> than in the right direction :)  Very understandable as this is  the
> least intuitive aspect of Java EE and is very hard to explain  and
> learn...
> Maybe we can shift things away from your code for a
> moment  and spend some time discussing any aspects of this example

Great, I'm all for taking a step back and going in baby steps.  I believe I
follow your example, and make the following observations:

- The exmple has EJB embedded / injected into other EJBs  (Red into blue and
vice-versa).  My code is not like this.  My ejb jar file is a library of EJBs
without injecting any into others.  I do believe this is THE ponit of confusion
for me and where I am misunderstanding what you are trying to tell me.  Because
I do not have embedded / injected / nested EJBs inside of EJBs, I don't see that
I require the <ejb-local-ref> tag, as this is embedding an EJB inside of
another, and I do not have that scenario in my code base (so far).  The
ejb-jar.xml and two tests below seemed a good baby step.  I was expecting both
tests to pass, but the 2nd fails.  I don't understand why.  It throws a
NoInitialContextException.

<?xml version="1.0"?>
<ejb-jar>
    <enterprise-beans>
        <session>
            <ejb-name>MyEjbName</ejb-name>
           
<business-local>com.dstsystems.walletshare.ejb.facade.ProductFamilyRegistrationFacadeLocal</business-local>

           
<ejb-class>com.dstsystems.walletshare.ejb.jdbc.ProductFamilyRegistrationFacade</ejb-class>

            <session-type>Stateless</session-type>
            <transaction-type>Bean</transaction-type>
        </session>
    </enterprise-beans>
</ejb-jar>

    @Test   // PASSES
    public void lookupEjbFromEjbJarXmlFile() throws NamingException {
       ic.lookup("MyEjbNameLocal");
    }

    @Test  // FAILS!  Why?  Shouldn't no arg work once OpenEJB has been
embedded?
    public void noargLookupEjbFromEjbJarXmlFile() throws NamingException {
        InitialContext ctx = new InitialContext();
        ctx.lookup("MyEjbNameLocal");
    }


- Next, I think maybe I am starting to get a point you've been making, which is
that I cannot make use of the "java:/comp/env' naming in my test cases AT ALL.  
No matter how far down the call stack they may occur.  In you example where you
call either initialContext.lookup("RedBeanLocal") or
initialContext.lookup("BlueBeanLocal") is where I've been trying / wanting to
make use of the 'java:/comp/env'.  My desire to do so is because my production
code is using that naming convention.  I mentioned before that I was in fact
doing a lookup, but that it was under the covers.  Basically I have POJOs that
represent the inputs to a query.  The POJO also includes a getter for the jndi
name of the EJB I need to instantiate for communicating with the database. They
have been coded in a way that makes JBoss work as expected, but fail in JUnit.  
(FWIW, EJBUtils uses the no arg context to do the lookups.) I added a couple of
other tests to try and make that clear.  Notice that in the second test, I've
used an annonymous inner class to override the jndi name to use the OpenEJB
syntax required.  Would be interested in your thoughts on this trick or if this
still points to a lack of understanding on my part.  Anyway, I find the results
of these test more confussing than the previous.  In this case, the first one is
using the JBoss naming and fails as expected with a NameNotFoundException.  I
was expecting the second one to pass, but again got the
NoInitialContextException.  Further details of that are :  Need to specify class
name in environment or system property, or as an applet parameter, or in an
application resource file:  java.naming.factory.initial


// JNDI==>> java:comp/env/ProductFamilyRegistrationFacade

    @Test (expected=RuntimeException.class)
    public void testEjbJBossWay() throws Exception {
        IProcedureEntity sp = new ProductFamilyRegistrationProcedure(new
BigDecimal("0"));

        // EJBUtils does a new InitialContext().lookup( sp.getJNDILookupName()
);
        System.out.println("JNDI==>> " + sp.getJNDILookupName());
        Object results = EJBUtils.callStoredProcedure(sp,
DataHandler.OPEN_DATA);
    }

// JNDI==>> MyEjbNameLocal

    @Test
    public void testEjbOpenEjbWay() throws Exception {
        IProcedureEntity sp = new ProductFamilyRegistrationProcedure(new
BigDecimal("0")) {
            @Override public String getJNDILookupName() {
                return "MyEjbNameLocal";
            }
        };

        // EJBUtils does a new InitialContext().lookup( sp.getJNDILookupName()
);
        System.out.println("JNDI==>> " + sp.getJNDILookupName());
        Object results = EJBUtils.callStoredProcedure(sp,
DataHandler.OPEN_DATA);
    }


Again, thanks for all your time and assistance,
TT
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit (hanging test issue)

tbbstny
In reply to this post by dblevins
I'm using an in-memory instance of derby to test my application, mainly the EJB
communication with the DB.  My EJBs are calling stored procedures.  For testing,
I've stubbed out Java based stored procedures in Derby.  I have narrowed down my
tests to those invoking one of these stored procedures as the one(s) that make
JUnit hang.  Having prepared a callable statement cstmt and calling execute on
it, Derby magically executes the java code for the procedure.  Perhaps my
notes/tracing below will point out something to those more knowledgeable than I
am, about what might be causing the problem.

TIA,
TT


*****************************************************************
     This run, the tests all run as expected, but JUnit hangs
     - Notice different ResultSet types on either side of the call
       Though the object id is the same on both
*****************************************************************

INSIDE EJB JAR CODE
Using:
- InitialContext ctx = new InitialContext();
- DataSource ds = (DataSource) ctx.lookup("openejb:Resource/WTSHARE");
- Connection conn = ds.getConnection();
---------------------------------------------
isResultSet = cstmt.execute();

        INSIDE DERBY JAVA BASED STORED PROCEDURE CODE
        Using:
        - Connection conn =
DriverManager.getConnection("jdbc:default:connection");
        ---------------------------------------------
        rs: org.apache.derby.impl.jdbc.EmbedResultSet40@9f8c02
        rs: org.apache.derby.impl.jdbc.EmbedResultSet40@18a577d
        rs: org.apache.derby.impl.jdbc.EmbedResultSet40@1a96bae

BACK inside ejb jar code
---------------------------------------------
isResultSet: true
rs: org.apache.commons.dbcp.DelegatingResultSet@9f8c02
rs: org.apache.commons.dbcp.DelegatingResultSet@18a577d
rs: org.apache.commons.dbcp.DelegatingResultSet@1a96bae



*****************************************************************
 This run, the tests fail, because execute reports no ResultSets
*****************************************************************

INSIDE EJB JAR CODE
Using:
- InitialContext ctx = new InitialContext();
- DataSource ds = (DataSource) ctx.lookup("openejb:Resource/WTSHARE");
- Connection conn = ds.getConnection();
---------------------------------------------
isResultSet = cstmt.execute();

        INSIDE DERBY JAVA BASED STORED PROCEDURE CODE
        Using: (attempting to use the same OpenEJB style connection this time)
        - InitialContext ctx = new InitialContext();
        - DataSource ds = (DataSource) ctx.lookup("openejb:Resource/WTSHARE");
        - Connection conn = ds.getConnection();
        ---------------------------------------------
        rs: org.apache.commons.dbcp.DelegatingResultSet@663ec
        rs: org.apache.commons.dbcp.DelegatingResultSet@1a48515
        rs: org.apache.commons.dbcp.DelegatingResultSet@101a4f3

BACK inside ejb jar code
---------------------------------------------
isResultSet: false
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

tbbstny
In reply to this post by tbbstny
Hanging JUnit test: Solved
In a finally I *thought* I was closing statements and connections.  Doing some
searching, I found something about calling commit on my connection because of
how Derby defaults it's cursor states.  I'm doing read only stuff, so didn't
think commit was necessary.  However, calling commit then close has caused the
hanging JUnit tests problem to go away.

Using the no-arg InitialContext constructor once OpenEJB has been embedded:
Solved.

To embed OpenEBJ, I have this.
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");

Once OpenEJB has been embedded, I also had to set the system property so the
no-arg constructor would also work.
System.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");


One last problem I'd appreciate your help one, or even a pointer to some
documentation.  I've googled but not finding what I'm looking for.  Prior to
integrating OpenEJB, I have configured my EBJ stuff in my web.xml file.  
Introducing the ebj-jar.xml file has caused JBoss problems, it looks like when
it's parsing the web.xml, because the first ejb-local-ref in my file results in
an exception being thrown.  If I move entries around in the file, the first
entry will cause JBoss to report an exception.  The final result being a message
that my deployment is in error.  An example of my web.xml entry follows:

    <ejb-local-ref>
        <ejb-ref-name>OfficeListFacade</ejb-ref-name>
        <ejb-ref-type>Session</ejb-ref-type>
       
<local>com.dstsystems.walletshare.ejb.facade.OfficeListFacadeLocal</local>
        <ejb-link>WalletShare-ejb.jar#OfficeListFacade</ejb-link>
    </ejb-local-ref>

- Can web.xml and ejb-jar.xml config work together
- Do you have an example or can point me to where I can find that.
- Even just the empty <ejb-jar/> tag in the ejb-jar.xml file makes JBoss fail.

Any pointers on this would be greatly appreciated.

TT
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help getting Derby running in JUnit

tbbstny
In reply to this post by tbbstny
Curses! Curses! and more Curses!

It seems JBoss does not play nice with an ejb-jar.xml file that does not include
namespaces.  Switching from an empty <ejb-jar/> file to a well formed version
seems to have fixed the integration problems between JBoss and OpenEJB.
More Here: The http://community.jboss.org/thread/121582?tstart=0

I'm calling the problem solved,
TT
Loading...