cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Wilson <mike...@hotmail.com>
Subject RE: avoid using contextClassLoader inside OSGi?
Date Thu, 26 Feb 2015 12:52:56 GMT
[sorry about the delay]

Sergey Beryozkin wrote:
> Hi
> 
> 
> On 24/02/15 14: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?
> 
> Can you please describe in more details where setting TCCL in 
> CXF causes 
> issues with this particular combination ? Or is the problem 
> across CXF ? 
> I guess a single example would do for us to see if it is.
> 
> Are you referring to
> 
> public ChainInitiationObserver(Endpoint endpoint, Bus bus) {
>          super();
>          this.endpoint = endpoint;
>          this.bus = bus;
>          if (bus != null) {
>              loader = bus.getExtension(ClassLoader.class);
>          }
>      }
> 
> and then this loader, if not null, is set as TCCL ?
> 
> I've just tun a non OSGI test, it is null...
> 
> Cheers, Sergey

Yes, this is the place. The loader gets configured with a
org.apache.cxf.bus.blueprint.BundleDelegatingClassLoader when run under
OSGi. Btw, my impression is that this class isn't providing much added
functionality so maybe it could be removed or refactored.

Best regards
Mike


Mime
View raw message