tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tbbstny <tbbs...@yahoo.com>
Subject Re: Need help getting Derby running in JUnit
Date Tue, 30 Nov 2010 20:44:48 GMT
> From: David Blevins <david.blevins@visi.com>

> 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

Mime
View raw message