Very interesting, this is just the reasoning I was looking for. Then I will conclude that if CXF considers themselves a non-legacy product, then they should redesign so that they do not use or set the TCCL when used in an OSGi setting? (my goal for this discussion thread was to see if it would make sense to submit such a ticket to the CXF project) Best regards Mike BJ Hargrave wrote:
If you are designing for OSGi, you would never call someone and expect them to be able to load a class from you. That is poor modularity. You should provide them the object of interest. This is one of the significant values of the service registry. The service registry is a broker. It does not require the service consumer to load the service provider's class. The service provider puts its object in the broker (service registry) where the service consume can find it. So there is no valid use case for TCCL in non-legacy OSGi scenarios. TCCL is a flawed concept as it requires breaking the encapsulation boundaries of the module. java.util.ServiceLoader is an example of this flawed design since it requires the caller (the service consumer) to supply a classloader or have set the TCCL so that the ServiceLoader implementation can load the service provider's classes. The service consumer should not have to know anything about the service provider including how to provide visibility to its implementation classes. All uses of TCCL are flawed in non-legacy OSGi scenarios. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the <http://www.osgi.org/> OSGi Alliance <mailto:hargr...@us.ibm.com> hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mike Wilson <mike...@hotmail.com> To: "'OSGi Developer Mail List'" <osgi-dev@mail.osgi.org> Date: 2015/02/23 15:12 Subject: Re: [osgi-dev] setting contextClassLoader inside library bundles Sent by: osgi-dev-boun...@mail.osgi.org _____ 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:hargr...@us.ibm.com> hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mike Wilson <mike...@hotmail.com> To: "'OSGi Developer Mail List'" <osgi-dev@mail.osgi.org> Date: 2015/02/23 13:37 Subject: Re: [osgi-dev] setting contextClassLoader inside library bundles Sent by: osgi-dev-boun...@mail.osgi.org _____ 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 > hargr...@us.ibm.com > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > From: Mike Wilson <mike...@hotmail.com> > To: "osgi-dev@mail.osgi.org" <osgi-dev@mail.osgi.org> > Date: 2015/02/23 11:03 > Subject: [osgi-dev] setting contextClassLoader inside library > bundles > Sent by: osgi-dev-boun...@mail.osgi.org > > > > 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 > osgi-dev@mail.osgi.org > <https://mail.osgi.org/mailman/listinfo/osgi-dev> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org <https://mail.osgi.org/mailman/listinfo/osgi-dev> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org <https://mail.osgi.org/mailman/listinfo/osgi-dev> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
