[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
