Home » Modeling » EMF » EPackage.Registry woes with different ClassLoaders
| EPackage.Registry woes with different ClassLoaders [message #903195] |
Wed, 22 August 2012 13:16  |
 Tassilo Horn
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  |
Tassilo Horn
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 |
Ed Merks
Messages: 33137
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EPackage.Registry woes with different ClassLoaders [message #903253 is a reply to message #903227] |
Wed, 22 August 2012 17:23 |
Tassilo Horn
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 |
|
|
|
Goto Forum:
Current Time: Fri Apr 19 23:33:35 GMT 2024
Powered by FUDForum. Page generated in 0.03315 seconds |
] 
Search
Help
Register
Login
Home
