Question

This problem is somewhat complicated and I'm in a little over my head. I will try to describe it as briefly as possible.

I have a J2EE application which runs on Glassfish v2 and consumes CCD messages using an implementation of EMF (MDHT). When this is invoked from a webservice which calls the EJB, it works perfectly and has worked for over a year. Recently we had a reason to invoke this from a WAR, the test case is a user uploading the same file which is normally sent over a webservice. When we call this from the WAR, it does not work, the EMF EPackage.Registry is empty!

When we call this from the WAR, the WAR gets an instance of the EJB session bean and just calls the EJB. We want to keep as much logic as possible in the EJB to not duplicate code.

Based on a discussion on the MDHT User list I'm led to believe this is more of an EMF issue than an MDHT issue and it relates to which classloader is in use.

The MDHT and EMF libraries are packaged in the EJB JAR and are visible to the EJB classloader.

I've tried several workaround and points to narrow this problem down:

  • moved JARs around to see if its a matter of the classloader not being able to see the MDHT libraries
  • Checked in the debugger to see which classloaders are in play when the Registry is populated
  • Dug deep into EMF and watched for ClassNotFoundExceptions
  • Put a logging breakpoint in to see which classloader is used when populating the Registry. It seems to use the EJB classloader as expected.

Are there any known or general use cases where an EMF implementation would behave differently when called from a WAR instead of an EJB?

Is this really an EMF issue or is it a more general issue when having a WAR call an EJB?

What other debugging steps should I try to isolate and identify the root-cause of this issue?

Was it helpful?

Solution

The solution to this problem was found on the EMF forums: http://www.eclipse.org/forums/index.php/m/758092/#msg_758092

If I set the org.eclipse.emf.ecore.EPackage.Registry.INSTANCE system property to org.eclipse.emf.ecore.impl.EPackageRegistryImpl magic happens and it works.

I'm curious as to why that works, but that is a different question.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top