On Feb 22, 2007, at 10:48 AM, Markus Wolf wrote:
Hi,
I have a problem using OpenEJB as JUnit4 container for my EJBs.
I use Java EE 5 and want to setup a unit test environment for this.
I follow the examples on the website with the following JUnit config:
@BeforeClass
public static void setUpBeforeClass() throws Exception {
Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
properties.setProperty("openejb.deployments.classpath.include",
".*emediaservices.*");
properties.setProperty("openejb.embedded.remotable", "true");
// Uncomment these properties to change the defaults
// properties.setProperty("openejb.ejbd.port", "4201");
// properties.setProperty("openejb.ejbd.bind", "localhost");
// properties.setProperty("openejb.ejbd.threads", "200");
// properties.setProperty("openejb.ejbd.disabled", "false");
// properties.setProperty("openejb.ejbd.only_from",
// "127.0.0.1,192.168.1.1");
new InitialContext(properties);
}
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.
But when I run any test in this class I get the following
exception. The
class which java complains about varies, but the message and the
stacktrace are always the same:
lang.ClassFormatError: Absent Code attribute in method that is not
native or abstract in class file javax/resource/ResourceException
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass
(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
Any hint what is causing this?
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 :)
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;"
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.
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'
And just for good measure, what kind of beans are you running?
-David
