On 4/16/10 7:57, Mahammad Nasir wrote:
Equinox solved this problem? I think equinox uses this api through out the
code.
As I said, Equinox has a solution similar to the one described, however,
it does not address the underlying issues in the JRE. In other words, it
is only a partial solution which has pitfalls of its own. For example,
it inhibits garbage collection of bundles and I believe will not always
return the correct class in every case due to how class loaders cache
classes.
-> richard
-----Original Message-----
From: Richard S. Hall [mailto:he...@ungoverned.org]
Sent: Friday, April 16, 2010 3:17 AM
To: users@felix.apache.org
Subject: Re: Can the thread context classloader issue be solved at all?
On 4/15/10 5:24 PM, Dan H wrote:
Libraries such as Hibernate and StAX that use
Thread.getContextClassLoader() do not work (well) in Felix / Karaf.
From what I've read it's because the OSGi Alliance never got around to
specifying how this method should behave in an OSGi environment.
I was wondering if it is possible in theory to create a bundle that
provides a "correct" thread context classloader for all other bundles?
I imagine it would involve writing a custom delegating classloader and a
bundle listener that basically just make all exported classes from any
bundle visible to the thread context classloader. However, I don't see a way
to reliably set the context classloader since the main thread is managed by
Felix.
There is no reliable way to do this since there are underlying JRE issues
that cause memory leaks.
Such an approach as you suggest is implemented by Equinox and its "context
finder" class loader, but they uncovered these various issues and this is
why it has never been spec'ed by OSGi, not because they never got around to
it.
-> richard
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
