Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EPackage.Registry woes with different ClassLoaders
EPackage.Registry woes with different ClassLoaders [message #903195] Wed, 22 August 2012 13:16 Go to next message
Tassilo Horn is currently offline Tassilo HornFriend
Messages: 93
Registered: July 2009
Member
Hi all,

I'm using EMF models from Clojure. Basically, that worked just fine
until today. Today, it occured to me that the
EPackage.Registry.INSTANCE (R in the following)

- forgets registered EPackages, that is,

R.getEPackage("http://some.known/uri")
R.containsKey("http://some.known/uri")

return some EPackage/true, but ten minutes later they return
null/false

- R.get("http://some.known/uri") always returns null

- R.keySet()/R.entrySet() always returns the empty set

Since I didn't change my code or updated EMF, I investigated what the
problem could be. I tracked it down to a ClassLoader issue. That is,
when I start a Clojure REPL using swank, which was my usual method until
yesterday, the context class loader is

#<AppClassLoader sun.misc.Launcher$AppClassLoader@4e81d783>

When I start a REPL with the new nREPL tool I started using today, the
context class loader is

#<DynamicClassLoader clojure.lang.DynamicClassLoader@5f1fd699>

This DynamicClassLoader basically changes everytime I recompile or
evaluate something, taking the previous ClassLoader as its parent. And
furthermore, after a certain time of inactivity the possibly large chain
of class loaders gets collected. That is, a minute ago I had

[... 20 more on top ...]
#<DynamicClassLoader clojure.lang.DynamicClassLoader@52f34d18>
#<DynamicClassLoader clojure.lang.DynamicClassLoader@634a8d33>
#<DynamicClassLoader clojure.lang.DynamicClassLoader@337c4232>
#<DynamicClassLoader clojure.lang.DynamicClassLoader@22ddfb06>
#<DynamicClassLoader clojure.lang.DynamicClassLoader@1b8b58cc>
#<DynamicClassLoader clojure.lang.DynamicClassLoader@5972c734>
#<AppClassLoader sun.misc.Launcher$AppClassLoader@2e6c01b9>
#<ExtClassLoader sun.misc.Launcher$ExtClassLoader@34e5307e>

and after waiting a minute, now I have

#<DynamicClassLoader clojure.lang.DynamicClassLoader@38978813>
#<AppClassLoader sun.misc.Launcher$AppClassLoader@2e6c01b9>
#<ExtClassLoader sun.misc.Launcher$ExtClassLoader@34e5307e>

So the only constants in the class loader chain are the AppClassLoader
with its parent, the ExtClassLoader. Therefore, the
WeakHashMap<ClassLoader, EPackage.Registry>-based Registry-lookup in
EPackageRegistryImpl first works, but after the DynamicClassLoaders get
collected over time, it stops working.

Now I changed my code, so that it is ensured that the context class
loader of the thread registering EPackages at the registry is the
AppClassLoader. That solved one problem: registered EPackages aren't
forgotten anymore, i.e.,

R.getEPackage("http://some.known/uri")
R.containsKey("http://some.known/uri")

always return the correct package/true.

But still, R.get() always returns null, and R.keySet() always returns
the empty set. How do I get all registered NsURIs?

Bye,
Tassilo
--
Dipl.-Inform. Tassilo Horn | Room: B015
University of Koblenz-Landau, Campus Koblenz | Phone: +49 (261) 287-2745
Institute for Software Technology | Mail: horn@xxxxxxxx
Universitätsstr. 1, 56070 Koblenz, Germany |
Re: EPackage.Registry woes with different ClassLoaders [message #903207 is a reply to message #903195] Wed, 22 August 2012 13:50 Go to previous messageGo to next message
Tassilo Horn is currently offline Tassilo HornFriend
Messages: 93
Registered: July 2009
Member
Tassilo Horn <horn@xxxxxxxx> writes:

Hi again,

> Now I changed my code, so that it is ensured that the context class
> loader of the thread registering EPackages at the registry is the
> AppClassLoader. That solved one problem: registered EPackages aren't
> forgotten anymore, i.e.,
>
> R.getEPackage("http://some.known/uri")
> R.containsKey("http://some.known/uri")
>
> always return the correct package/true.
>
> But still, R.get() always returns null, and R.keySet() always returns
> the empty set. How do I get all registered NsURIs?

Ok, I solved it by ensuring that also read-access to the registry has
the system class loader set as context class loader. While that works,
I'm not really sure if that's the way things are supposed to be...

Bye,
Tassilo
--
Dipl.-Inform. Tassilo Horn | Room: B015
University of Koblenz-Landau, Campus Koblenz | Phone: +49 (261) 287-2745
Institute for Software Technology | Mail: horn@xxxxxxxx
Universitätsstr. 1, 56070 Koblenz, Germany |
Re: EPackage.Registry woes with different ClassLoaders [message #903227 is a reply to message #903207] Wed, 22 August 2012 14:26 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26287
Registered: July 2009
Senior Member
You can use the JVM argument
-Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=org.eclipse.emf.ecore.impl.EPackageRegistryImpl
to specify not to use a classloader-scoped registry.


On 22/08/2012 3:50 PM, Tassilo Horn wrote:
> Tassilo Horn <horn@xxxxxxxx> writes:
>
> Hi again,
>
>> Now I changed my code, so that it is ensured that the context class
>> loader of the thread registering EPackages at the registry is the
>> AppClassLoader. That solved one problem: registered EPackages aren't
>> forgotten anymore, i.e.,
>>
>> R.getEPackage("http://some.known/uri")
>> R.containsKey("http://some.known/uri")
>>
>> always return the correct package/true.
>>
>> But still, R.get() always returns null, and R.keySet() always returns
>> the empty set. How do I get all registered NsURIs?
> Ok, I solved it by ensuring that also read-access to the registry has
> the system class loader set as context class loader. While that works,
> I'm not really sure if that's the way things are supposed to be...
>
> Bye,
> Tassilo
Re: EPackage.Registry woes with different ClassLoaders [message #903253 is a reply to message #903227] Wed, 22 August 2012 17:23 Go to previous message
Tassilo Horn is currently offline Tassilo HornFriend
Messages: 93
Registered: July 2009
Member
Ed Merks <ed.merks@xxxxxxxx> writes:

Hi Ed,

> You can use the JVM argument
> -Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=org.eclipse.emf.ecore.impl.EPackageRegistryImpl
> to specify not to use a classloader-scoped registry.

That's not really an option since my stuff is a library that might be
used by other applications I don't have any control over. So I think, I
have to stay with switching to the system class loader before accessing
the registry...

Bye,
Tassilo

> On 22/08/2012 3:50 PM, Tassilo Horn wrote:
>> Tassilo Horn <horn@xxxxxxxx> writes:
>>
>> Hi again,
>>
>>> Now I changed my code, so that it is ensured that the context class
>>> loader of the thread registering EPackages at the registry is the
>>> AppClassLoader. That solved one problem: registered EPackages aren't
>>> forgotten anymore, i.e.,
>>>
>>> R.getEPackage("http://some.known/uri")
>>> R.containsKey("http://some.known/uri")
>>>
>>> always return the correct package/true.
>>>
>>> But still, R.get() always returns null, and R.keySet() always returns
>>> the empty set. How do I get all registered NsURIs?
>> Ok, I solved it by ensuring that also read-access to the registry has
>> the system class loader set as context class loader. While that works,
>> I'm not really sure if that's the way things are supposed to be...
>>
>> Bye,
>> Tassilo
>

--
Dipl.-Inform. Tassilo Horn | Room: B015
University of Koblenz-Landau, Campus Koblenz | Phone: +49 (261) 287-2745
Institute for Software Technology | Mail: horn@xxxxxxxx
Universitätsstr. 1, 56070 Koblenz, Germany |
Previous Topic:[CDO] Pessimistic lock with EMF Transaction
Next Topic:[CDO] dbAdapter MySQL Problem
Goto Forum:
  


Current Time: Mon Dec 22 01:35:25 GMT 2014

Powered by FUDForum. Page generated in 0.12423 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software