tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Unit Testing EJB with Junit4
Date Fri, 23 Feb 2007 02:30:53 GMT

On Feb 22, 2007, at 4:50 PM, Markus Wolf wrote:

> Hi David,
>>> [...]
>> Just a note on the "openejb.embedded.remotable" flag.  You don't  
>> need to
>> enable that and open ports if you're doing all your testing in the  
>> same
>> vm.  You really only need the "openejb.embedded.remotable" flag on if
>> you have clients connecting from another VM, which is probably  
>> something
>> you'd do more if OpenEJB was embedded in an application that  
>> wanted to
>> have an embedded EJB container to add remoting capabilities.
>> To say it another way, it doesn't have anything to do if you want to
>> test local interfaces vs remote interfaces.  Using remote  
>> interfaces to
>> beans in the same vm as you works just fine without the network stuff
>> enabled.
>> I don't really know JBoss at all, but I get the feeling their  
>> embedded
>> testing stuff doesn't work for people who are using remote interfaces
>> without opening sockets and the like -- which apparently they  
>> don't have
>> support for yet and there for can't test remote interfaces.  If  
>> someone
>> could confirm this that'd be really helpful as we'd probably want to
>> make an extra strong effort to document that things do not work  
>> this way
>> in OpenEJB.  At least it would be a big help in understand where  
>> users
>> are coming.
> I've tried with both ways and none of it does work. So it does not
> depend on the jvm/remote/port stuff, but that was not what I thought.

Good to know.  I recall at least one other person suspecting the  
exact same thing.

>>> [...]
>> Now that is truly strange.  Hmm.. don't know what could cause a
>> ClassFormatError on that class (or any class).  Best thing we can  
>> do is
>> start eliminating possibilities.  Hope you can follow my little debug
>> logic tree here :)
> I've found a hint on a sun blog entry for this exception. There was  
> said
> that the javaee5.jar I have in my maven dependencies is just for
> compiling, but I think having the api besides the implementation
> dependencies of OpenEJB would not cause trouble. I maybe can remove  
> this
> jar and try again, but I guess that would not help.

I'd definitely try that.  The error is invalid class def for a J2CA  
API class so it's definitely worth trying.  If they are in the  
classpath then OpenEJB will use them at unit test time.  I'm not sure  
what they could do to a class (especially an exception) that would  
make them warn against using the library at runtime, but considering  
that's such a strange request to make they must have some kind of  

Looking at your classpath in the maven output you posted, that seems  
like the only possible culprit of who could be adding an invalid def  
of that class.

>> 1.  Have you been able to run any of the other examples (like  
>> calculator
>> maybe)?  If so and they run successfully, try adding a line that  
>> would
>> case ResourceException to be loaded.  Something innocuous like  
>> "Class c
>> = javax.resource.ResourceException.class;"
> I have written a simple stateless 'echo'-Bean to test if OpenEJB does
> work at all in maven and junit and that does work very well.

That's great.  I'm sure we can get the rest working for you too.

>>   1.a. If that doesn't work and you get the same error, then it's  
>> likely
>> that you somehow got a bad jar in your maven repo and you'd likely  
>> have
>> to delete your repo (or back it up) and have maven download  
>> everything
>> anew.
> The jars in my path should be ok, because if I deploy it into my
> appserver everything does work, but deploying untested code gives me a
> bad feeling.

That's totally fine.  That kind of action is more a last resort.   
FYI, if your app server is glassfish we do have experimental support  
for their descriptors so if there's something you notice that isn't  
getting picked up, definitely let us know and we'll fix it.

>>   1.b. If that does work, then there must be something being  
>> included in
>> your maven pom perhaps pulled in by one of your dependencies.  In  
>> which
>> case run maven with -X to have it spit out all the classpath and  
>> debug
>> information and post it.  Easy way would be 'mvn -X clean install >
>> output.log'
> I'll can do that and post it here. That will take some minutes.
>> And just for good measure, what kind of beans are you running?
> I'm using stateless and stateful beans which use an EntityMananger  
> with
> annotation injection as stated in the JavaEE5 API.
> Could the problem related to the dependency injection?

Well, if the above approach of removing the sun javaee api jar  
doesn't fix things than perhaps there is something going on with JPA  
related class enhancing, but I'd guess the "do not use at runtime"  
jar is the bigger suspect.


View raw message