You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Dan H <hu...@yahoo.de> on 2010/04/15 23:24:56 UTC
Can the thread context classloader issue be solved at all?
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.
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Can the thread context classloader issue be solved at all?
Posted by Chris Blunck <ch...@thebluncks.com>.
I have hit this problem with some OSS projects. A workaround is to do
something like this in the code you own that calls into the OSS project:
ClassLoader osgi = getClass().getClassLoader();
ClassLoader thread = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(osgi);
try {
// invoke your un-osgi-aware oss library
} catch (Throwable t) { }
finally {
Thread.currentThread().setContextClassLoader(thread);
}
I can't vouch for whether this approach is sound or not. I can vouch that
it has gotten me out of many an XML parsing pickle though...
-c
On Thu, Apr 15, 2010 at 5:24 PM, Dan H <hu...@yahoo.de> 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.
>
> -Dan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Can the thread context classloader issue be solved at all?
Posted by Ivan Dubrov <wf...@gmail.com>.
On 01/19/2011 03:06 AM, Guillaume Nodet wrote:
> A cleaner API would be to actually pass a classloader directly (JaxbContext
> does that for example IIRC), but it's basically the same: the caller needs
> to build / find the classloader, so it does not really change anything.
It changes it in the way that this approach makes dependencies more
explicit. If library needs to load some resources it does not know in
advance, it is perfectly fine for it to ask for classloader directly,
like JAXBContext does. Also, the explicit approach allows to pass
classloader to the library just once, during instance creation (like
instantiating JAXBContext).
The whole TCCL thing just leads to the bad design (increased coupling),
just like other "static" state which is not bound to the instances.
Explicit references passing eased by dependency injection -- that is the
proper approach!
--
WBR,
Ivan S. Dubrov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Can the thread context classloader issue be solved at all?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Mittwoch, den 19.01.2011, 07:01 +0000 schrieb
Sergey_Zhemzhitsky@troika.ru:
> Just me two cents.
> When karaf will be capable to deploy multiple artifacts as applications
> (apache aries applications) or something like that it can use eclipse
> virgo's par approach.
> Here is the link:
> http://www.eclipse.org/virgo/documentation/virgo-documentation-2.1.0.RELEASE/docs/virgo-programmer-guide/html/ch04s02.html
> Quotation: The artifacts of a PAR have their exported packages imported by
> the synthetic context bundle which is used for thread context class
> loading. So, for example, hibernate will be able to load classes of any of
> the exported packages of the artifacts in a PAR file using Class.forName()
Hmm, probably *not* Class.forName() because this exact method is the
cause of the issues with Equinox' Thread Context ClassLoader support
(see [1]).
Always use ClassLoader.loadClass(String)....
Regards
Felix
[1]
http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html
> (or equivalent).
> Moreover PAR applications have some more useful features.
>
>
> Best Regards,
> Sergey
>
>
>
> Guillaume Nodet <gn...@gmail.com>
> 19.01.2011 00:07
> Please respond to
> users@felix.apache.org
>
>
> To
> users@felix.apache.org
> cc
>
> Subject
> Re: Can the thread context classloader issue be solved at all?
>
>
>
>
>
>
> As Richard said, there's no easy way to solve the problem. What we've
> done
> in Karaf / Servicemix / Camel where needed is that when using a library
> that
> require a TCCL to be set for finding classes or resources, we set it
> locally
> before calling that library.
> A cleaner API would be to actually pass a classloader directly
> (JaxbContext
> does that for example IIRC), but it's basically the same: the caller needs
> to build / find the classloader, so it does not really change anything.
>
> On Tue, Jan 18, 2011 at 21:35, boday <be...@initekconsulting.com>
> wrote:
>
> >
> > This remains a common/widespread issue and a cumbersome work around. Is
> > there an alternative to this approach? Has this issue been solved in
> > Felix/Karaf or is it simply not possible to at the container level?
> >
> > I've read about several different approaches to this including Context
> > Finder, Buddy Policy, etc.
> >
> > here are a few references that I found...
> >
> > http://wiki.eclipse.org/Context_Class_Loader_Enhancements (for equinox)
> >
> >
> http://stackoverflow.com/questions/2198928/better-handling-of-thread-context-classloader-in-osgi
>
> > (no responses)
> >
> > If there is a more definitive explanation of the issue and options,
> please
> > point me to it.
> >
> > thanks...
> >
> > -----
> > ___________________________________
> > Ben - Senior Consultant
> > using AMQ 5.3/Smx 4.2/Camel 2.2
> > --
> > View this message in context:
> >
> http://old.nabble.com/Can-the-thread-context-classloader-issue-be-solved-at-all--tp28260809p30704054.html
>
> > Sent from the Apache Felix - Users mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Can the thread context classloader issue be solved at all?
Posted by Se...@troika.ru.
Just me two cents.
When karaf will be capable to deploy multiple artifacts as applications
(apache aries applications) or something like that it can use eclipse
virgo's par approach.
Here is the link:
http://www.eclipse.org/virgo/documentation/virgo-documentation-2.1.0.RELEASE/docs/virgo-programmer-guide/html/ch04s02.html
Quotation: The artifacts of a PAR have their exported packages imported by
the synthetic context bundle which is used for thread context class
loading. So, for example, hibernate will be able to load classes of any of
the exported packages of the artifacts in a PAR file using Class.forName()
(or equivalent).
Moreover PAR applications have some more useful features.
Best Regards,
Sergey
Guillaume Nodet <gn...@gmail.com>
19.01.2011 00:07
Please respond to
users@felix.apache.org
To
users@felix.apache.org
cc
Subject
Re: Can the thread context classloader issue be solved at all?
As Richard said, there's no easy way to solve the problem. What we've
done
in Karaf / Servicemix / Camel where needed is that when using a library
that
require a TCCL to be set for finding classes or resources, we set it
locally
before calling that library.
A cleaner API would be to actually pass a classloader directly
(JaxbContext
does that for example IIRC), but it's basically the same: the caller needs
to build / find the classloader, so it does not really change anything.
On Tue, Jan 18, 2011 at 21:35, boday <be...@initekconsulting.com>
wrote:
>
> This remains a common/widespread issue and a cumbersome work around. Is
> there an alternative to this approach? Has this issue been solved in
> Felix/Karaf or is it simply not possible to at the container level?
>
> I've read about several different approaches to this including Context
> Finder, Buddy Policy, etc.
>
> here are a few references that I found...
>
> http://wiki.eclipse.org/Context_Class_Loader_Enhancements (for equinox)
>
>
http://stackoverflow.com/questions/2198928/better-handling-of-thread-context-classloader-in-osgi
> (no responses)
>
> If there is a more definitive explanation of the issue and options,
please
> point me to it.
>
> thanks...
>
> -----
> ___________________________________
> Ben - Senior Consultant
> using AMQ 5.3/Smx 4.2/Camel 2.2
> --
> View this message in context:
>
http://old.nabble.com/Can-the-thread-context-classloader-issue-be-solved-at-all--tp28260809p30704054.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Can the thread context classloader issue be solved at all?
Posted by Guillaume Nodet <gn...@gmail.com>.
As Richard said, there's no easy way to solve the problem. What we've done
in Karaf / Servicemix / Camel where needed is that when using a library that
require a TCCL to be set for finding classes or resources, we set it locally
before calling that library.
A cleaner API would be to actually pass a classloader directly (JaxbContext
does that for example IIRC), but it's basically the same: the caller needs
to build / find the classloader, so it does not really change anything.
On Tue, Jan 18, 2011 at 21:35, boday <be...@initekconsulting.com> wrote:
>
> This remains a common/widespread issue and a cumbersome work around. Is
> there an alternative to this approach? Has this issue been solved in
> Felix/Karaf or is it simply not possible to at the container level?
>
> I've read about several different approaches to this including Context
> Finder, Buddy Policy, etc.
>
> here are a few references that I found...
>
> http://wiki.eclipse.org/Context_Class_Loader_Enhancements (for equinox)
>
> http://stackoverflow.com/questions/2198928/better-handling-of-thread-context-classloader-in-osgi
> (no responses)
>
> If there is a more definitive explanation of the issue and options, please
> point me to it.
>
> thanks...
>
> -----
> ___________________________________
> Ben - Senior Consultant
> using AMQ 5.3/Smx 4.2/Camel 2.2
> --
> View this message in context:
> http://old.nabble.com/Can-the-thread-context-classloader-issue-be-solved-at-all--tp28260809p30704054.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Can the thread context classloader issue be solved at all?
Posted by boday <be...@initekconsulting.com>.
This remains a common/widespread issue and a cumbersome work around. Is
there an alternative to this approach? Has this issue been solved in
Felix/Karaf or is it simply not possible to at the container level?
I've read about several different approaches to this including Context
Finder, Buddy Policy, etc.
here are a few references that I found...
http://wiki.eclipse.org/Context_Class_Loader_Enhancements (for equinox)
http://stackoverflow.com/questions/2198928/better-handling-of-thread-context-classloader-in-osgi
(no responses)
If there is a more definitive explanation of the issue and options, please
point me to it.
thanks...
-----
___________________________________
Ben - Senior Consultant
using AMQ 5.3/Smx 4.2/Camel 2.2
--
View this message in context: http://old.nabble.com/Can-the-thread-context-classloader-issue-be-solved-at-all--tp28260809p30704054.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Can the thread context classloader issue be solved at all?
Posted by Dan H <hu...@yahoo.de>.
-------- Original Message --------
Subject: Re: Can the thread context classloader issue be solved at all?
From: Richard S. Hall <he...@ungoverned.org>
To: users@felix.apache.org
Date: 15.04.2010 23:47
> 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
>
Thanks for the clarification, I hope the powers that be can find a way
to solve this issue in the near future. I wouldn't mind at all if Java
just deprecated the whole getContextClassLoader backdoor (wishful
thinking, I know).
For now I'm just running things that require the context classloader in
a separate thread. Having to wrap everthing in Callable/Runnable is not
really a problem, yet.
--------------------------------------------------------------------
ExecutorService threadPool = Executors.newSingleThreadExecutor(new
ThreadFactory() {
@Override
public Thread newThread(Runnable r) {
Thread t = new Thread(r);
t.setContextClassLoader(
MyBundleThatImportsHibernate.class.getClassLoader());
return t;
}
});
//then
threadPool.submit(someCallable).get();
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Can the thread context classloader issue be solved at all?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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:heavy@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Can the thread context classloader issue be solved at all?
Posted by Mahammad Nasir <ma...@huawei.com>.
Equinox solved this problem? I think equinox uses this api through out the
code.
-----Original Message-----
From: Richard S. Hall [mailto:heavy@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Can the thread context classloader issue be solved at all?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org