You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by boday <be...@initekconsulting.com> on 2011/01/18 21:35:51 UTC
Re: Can the thread context classloader issue be solved at all?
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 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