Right, so then it seems there are also "valid" use cases for TCCL in non-legacy OSGi scenarios, similar to the /ext cases where a library wants to perform lookups in the caller's class space. This use case can be solved in several ways including TCCL, or supplying an explicit classloader argument, or even inspecting/walking the call stack (as is done in some hacks). Reading some articles I first thought TCCL was entirely out of scope in OSGi but now I see that it is only incorrect and/or unnecessary use of TCCL that is harmful in OSGi :-) Best regards Mike BJ Hargrave wrote:
In OSGi, just use the bundle's existing class loader. But there is no general purpose solution to setting the TCCL in OSGi since there is no one class loader that would have visibility to the types some arbitrary code wants to load. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the <http://www.osgi.org/> OSGi Alliance <mailto:[email protected]> [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mike Wilson <[email protected]> To: "'OSGi Developer Mail List'" <[email protected]> Date: 2015/02/23 13:37 Subject: Re: [osgi-dev] setting contextClassLoader inside library bundles Sent by: [email protected] _____ Hm, I'm pondering whether the TCCL assignment in CXF is aimed for CXF itself. Maybe it depends on this mechanism to get access to the classes in generated APIs? When calling methods on generated API, inside the CXF core bundle I see TCCL set to the generated API bundle. It seems this could be a general pattern for libraries that let the client generate code, and I wonder if there is a better solution than TCCL in OSGi for this case? Best regards Mike BJ Hargrave wrote: > There are times when it is necessary when dealing with legacy > code that > demands the TCCL provide visibility to some types. Normally you do a > try/finally to set and restore the TCCL around the call to > the legacy code > which needs the TCCL set to some value. But I imagine there > are times when > you will encounter conflicting interests in the value of TCCL > that cannot > be easily solved. > -- > > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > [email protected] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > From: Mike Wilson <[email protected]> > To: "[email protected]" <[email protected]> > Date: 2015/02/23 11:03 > Subject: [osgi-dev] setting contextClassLoader inside library > bundles > Sent by: [email protected] > > > > We just ran into some problems when running CXF inside Karaf. > The cause is > that CXF assigns the contextClassLoader to the bundle > ClassLoader during > each message event. > Based on various discussion on the net (f ex [1]) I had expected that > libraries like CXF would not touch the contextClassLoader > when run inside > OSGi. Or are there valid use cases for this? > > Thanks > Mike > > [1] > <http://njbartlett.name/2012/10/23/dreaded-thread-context-class> http://njbartlett.name/2012/10/23/dreaded-thread-context-class loader.html > > _______________________________________________ > OSGi Developer Mail List > [email protected] > <https://mail.osgi.org/mailman/listinfo/osgi-dev> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ OSGi Developer Mail List [email protected] <https://mail.osgi.org/mailman/listinfo/osgi-dev> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
