Eclipse Community Forums: EMF » Static package registration not populating same registry accessed by EMF deserialization code

Home » Modeling » EMF » Static package registration not populating same registry accessed by EMF deserialization code(When calling an EMF implementation from an EJB which is in turn called by a WAR, the registry does not appear populated)

Show: Today's Messages :: Show Polls :: Message Navigator

Static package registration not populating same registry accessed by EMF deserialization code [message #757539]

Fri, 18 November 2011 19:54

Jon.B

Messages: 8
Registered: December 2009

Junior Member

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

Report message to a moderator

Re: Static package registration not populating same registry accessed by EMF deserialization code [message #757977 is a reply to message #757539]

Sat, 19 November 2011 08:35

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Jon, 
 
Comments below. 
 
On 18/11/2011 8:54 PM, Jon.B wrote:
<blockquote cite="mid:ja6d4t$cih$1@news.eclipse.org" type="cite">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.
 
</blockquote>
The package registry in stand alone mode is class loader scoped. 
<blockquote cite="mid:ja6d4t$cih$1@news.eclipse.org" type="cite">
 
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.</blockquote>
There wouldn't be a problem in that case... 
<blockquote cite="mid:ja6d4t$cih$1@news.eclipse.org" type="cite">
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? </blockquote>
It must be an issue of class loaders... 
<blockquote cite="mid:ja6d4t$cih$1@news.eclipse.org" type="cite">Any
fixes or workarounds?
 
</blockquote>
You can see how the registry is populated in EPackageRegistryImpl 
<blockquote> public static EPackage.Registry createGlobalRegistry() 
{ 
 try 
 { 
 String className =
System.getProperty("org.eclipse.emf.ecore.EPackage.Registry.INSTANCE"); 
</blockquote>
So one brute force solution is to specify this property with the
value org.eclipse.emf.ecore.impl.EPackageRegistryImpl 
<blockquote cite="mid:ja6d4t$cih$1@news.eclipse.org" type="cite">
 
This has been discussed on the MDHT users list - https:
<a class="moz-txt-link-abbreviated" href="http://www.projects.openhealthtools.org/sf/go/projects.mdht/discussion.forum1136.topc11587">www.projects.openhealthtools.org/sf/go/projects.mdht/discussion.forum1136.topc11587</a> 
</blockquote>
</body>
</html>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Static package registration not populating same registry accessed by EMF deserialization code [message #757978 is a reply to message #757539]

Sat, 19 November 2011 10:01

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

On 18/11/2011 19:54, Jon.B wrote:
>
> What possible causes are there for this issue? Any fixes or workarounds?
>
It is highly likely that you have two differently managed registries.

I find that when something impossible happens with models, there is no
substitute for checking out emf.ecore or emf.ecore.xmi as projects and
inserting a few println's printing out activity and object hashcodes.
Find out who's constructing registries. Find out who's gaining access to
the contents.

Instrumenting ResourceSetImpl.getResource is also helpful.

Regards

Ed Willink

Report message to a moderator

Re: Static package registration not populating same registry accessed by EMF deserialization code [message #757979 is a reply to message #757978]

Sat, 19 November 2011 16:16

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Ed,

It's highly likely to be related to EPackageRegistryImpl.Delegator doing
funky things in a context that has a funky class loader scheme as web
containers do...

On 19/11/2011 11:01 AM, Ed Willink wrote:
> Hi
>
> On 18/11/2011 19:54, Jon.B wrote:
>>
>> What possible causes are there for this issue? Any fixes or workarounds?
>>
> It is highly likely that you have two differently managed registries.
>
> I find that when something impossible happens with models, there is no
> substitute for checking out emf.ecore or emf.ecore.xmi as projects and
> inserting a few println's printing out activity and object hashcodes.
> Find out who's constructing registries. Find out who's gaining access
> to the contents.
>
> Instrumenting ResourceSetImpl.getResource is also helpful.
>
> Regards
>
> Ed Willink

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Static package registration not populating same registry accessed by EMF deserialization code [message #758042 is a reply to message #757979]

Mon, 21 November 2011 19:55

Jon.B

Messages: 8
Registered: December 2009

Junior Member

Quote:

So one brute force solution is to specify this property with the value org.eclipse.emf.ecore.impl.EPackageRegistryImpl

Bah I misread the statement at first.

Thank you for the advice. I will try that and report back!

[Updated on: Mon, 21 November 2011 20:01]

Report message to a moderator

Re: Static package registration not populating same registry accessed by EMF deserialization code [message #758092 is a reply to message #758042]

Mon, 21 November 2011 21:12

Jon.B

Messages: 8
Registered: December 2009

Junior Member

Hot damn! Setting that property seems to fix the problem.

So what is this actually doing? Why does this work?

Report message to a moderator

Re: Static package registration not populating same registry accessed by EMF deserialization code [message #758108 is a reply to message #758092]

Mon, 21 November 2011 21:40

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Jon,

The default stand alone instance is EPackageRegistryImpl.Delegator which
is class loader scoped; that seems to be causing you a problem (but
you've not explained enough detail for me to know why).

On 21/11/2011 10:12 PM, Jon.B wrote:
> Hot damn! Setting that property seems to fix the problem.
>
> So what is this actually doing? Why does this work?
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Static package registration not populating same registry accessed by EMF deserialization code [message #758115 is a reply to message #758108]

Mon, 21 November 2011 22:20

Jon.B

Messages: 8
Registered: December 2009

Junior Member

What details can I look for or provide to explain the behaviour?

Report message to a moderator

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 06:29

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

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?
>
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	[CDO] Import/Export for model migration?
Next Topic:	[Query2] Execute queries on large model

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Apr 27 01:39:51 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter