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
reason.
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.
-David
