cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: avoid using contextClassLoader inside OSGi?
Date Thu, 26 Feb 2015 21:36:59 GMT

> On Feb 26, 2015, at 4:04 PM, Mike Wilson <mikewse@hotmail.com> wrote:
> Having the luxury of not understanding the implications in the CXF codebase
> I would choose to disagree ;-), and welcome removal of TCCL usage as it
> seems not to be set in normal JEE scenarios and is only set when running in
> OSGi, where it is explicitly unrecommended to do so.

Well, no.  It’s also set when using Spring to setup your endpoints and services.   There
are other cases where it’s set as well.

Most importantly, there are a BUNCH of places in CXF and in the libraries that CXF uses that
require it.   CXF being primarily an implementation of J2EE specs in general uses the recommendations
and guidelines provided by J2EE which includes the use of the TCCL.    In particular, things
like loading the JAX-WS handlers from the @HandlerChain would require the use of the TCCL
to locate and “newInstance” them.   The xmlbeans and jibx data bindings would also require
the use of the TCCL for loading the various resources they need to operate.   The WS-Security
stuff we have may use the TCCL to load callback objects (although some of them can be passed
by reference to a bean instead of just a class name).    Some use of JAXB requires it (if
you do a JAXBContext.newInstance(“com.foo.package”) for example). 

Even some of the CXF annotations themselves would require it.  For example, @Features(features
= “org.apache.MyFeature”) would need it to load the appropriate feature.  (Although all
the CXF annotations that do this have an alternative form that takes the class object itself
that could be used instead.  @Features(classes = MyFeature.class))

Some of them could be “fixed” by adding a bunch of “ClassLoader”  parameters to various
methods and passing that around, but that’s a massive change and also a complete hack IMO.
  The TCCL was created specifically for providing the class loader of the current “context”
to avoid having to do all of that. 

Those are just a couple off the top of my head.    I’m sure there are others.

Dan


> Anyway, I'll put together a description of the bug and post here (as it
> seems this is where you prefer to do the discussion about it?).
> 
> Best regards
> Mike
> 
> Sergey Beryozkin wrote:
>> On 26/02/15 12:58, Mike Wilson wrote:
>>> Ok, let's see if other believe TCCL usage is possible to 
>> remove altogether.
>>> If not, I'll invest the time to create a ticket with the 
>> details of the bug.
>>> 
>>> In short, it happens when CXF logging is routed to Juli.
>> Do you have more details re why it breaks with Juli involved 
>> ? How does 
>> CXF setting TCCL affects Juli doing its work ?
>> 
>> IMHO the best way to get it moved forward is to have a concrete case 
>> discussion (as Christian suggested) and see what can be done 
>> it make it 
>> resolved as opposed to just considering completely removing 
>> the use of 
>> TCCL - might be risky, though may be Christian and Dan may 
>> have another 
>> view with respect to using an OSGI-specific loader in the chain...
>> 
>> Cheers, Sergey
>>> If configuring CXF
>>> to route through Slf4j the problem goes away.
>>> 
>>> Best regards
>>> Mike
>>> 
>>> Christian Schneider wrote:
>>>> I think it might make sense to remove the TCCL usage in OSGi
>>>> where ever
>>>> possible. This is not a small thing though as we have to be
>>>> careful not
>>>> to break existing code.
>>>> 
>>>> So for short term it will make more sense to work around 
>> the problem.
>>>> Can you give a concrete example where it breaks for you?
>>>> Btw. I am using pax logging a lot and itworks fine with CXF.
>>>> I just use
>>>> the slf4j API in my own code and pax logging implements it.
>>>> 
>>>> Christian
>>>> 
>>>> On 24.02.2015 15:46, Mike Wilson wrote:
>>>>> Yes, the undesired side-effect for us is that the
>>>> combination of CXF, Juli
>>>>> and Pax Logging breaks down. Looking at the code it seems
>>>> all involved
>>>>> parties have design decisions done with good intentions 
>> and the only
>>>>> questionable thing is CXF's use of TCCL, which is sort of
>>>> the trigger of the
>>>>> problem. So I thought this would be the first thing worth
>>>> considering as it
>>>>> is advised against in OSGi.
>>>>> 
>>>>> If not possible to remove TCCL entirely, then it might
>>>> still be possible to
>>>>> only set it during the very calls into stuff that need it,
>>>> instead of during
>>>>> the whole message cycle?
>>>>> 
>>>>> Best regards
>>>>> Mike
>>>>> 
>>>> 
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>> 
>>>> Open Source Architect
>>>> http://www.talend.com
>>>> 
>>>> 
>>> 
>> 
>> 
> 

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message