| Static package registration not populating same registry accessed by EMF deserialization code [message #757539] |
Fri, 18 November 2011 14:54  |
Eclipse User |
|
|
|
I am using MDHT, which is based on EMF, in my project. I am calling MDHT from one of my libraries which uses MDHT/EMF to parse an XML file and map it to a POJO. That library is invoked from an EJB. This has worked wonderfully for over a year.
Recently, my team added support for a use case where a user would upload a CCD from a WAR. The WAR then calls the EJB to process that file. This fails.
What seems to be happening is that the initial population of the EPackage.Registry goes OK, but then when the file is deserialized in EMF the Registry doesn't appear to have the packages that were loaded.
Looking at the debugger it appears that the EJB and WAR are using the same classloader when the registry is populated and when it is read. There should not be any threading issues in play, the WAR and EJB should run in the same thread. Even if they don't the EJB calls to my library and MDHT/EMF will happen in the same thread.
I'm in a little over my head. Please let me know what additional information to provide to describe this isssue.
What possible causes are there for this issue?
Any fixes or workarounds?
This has been discussed on the MDHT users list - https: www.projects.openhealthtools.org/sf/go/projects.mdht/discussion.forum1136.topc11587
|
|
|
|
|
|
|
|
|
|
| Re: Static package registration not populating same registry accessed by EMF deserialization code [message #758147 is a reply to message #758115] |
Tue, 22 November 2011 01:29  |
| Eclipse User |
|
|
|
Jon,
Can you reproduce the problem under debug control?
Here's my understanding of how web containers use class loaders. The
container itself has a class loader and it creates one for each thread
or each thing that runs in the container. That one has the container's
class loader as its parent. When the package is initialized,
Thread.getContextClassLoader determines which of a chain of registries
(corresponding to the chain of class loaders) will contain the
registration. When you do a lookup, the same process is used to find
it. So if the package is registered with one context and then lookup
happens with a different context that's not below the registered one
(below as defined by the opposite of ClassLoader.getParent), it won't be
visible. This allows different containers to avoid colliding their
registrations and even to register different versions of the same package.
As another nasty wrinkle, some web containers (e.g., WebSphere) use EMF
themselves and you might end up with their version of EMF, not your
own. You need to set some property for PARENT_LAST or something like
that so that the parent is the last place that's used to resolve classes
you need to load so you can ensure that your version of EMF is used.
As Ed suggested, do a Thread.dumpStack in your package init and see
where it's being registered. Registering early in a know context would
be a better workaround.
On 21/11/2011 11:20 PM, Jon.B wrote:
> What details can I look for or provide to explain the behaviour?
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.05684 seconds
Home