Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of mikewse@hotmail.com
 designates 157.55.2.95 as permitted sender)
Message-ID: <DUB128-DS59314D88452056976C804A4140@phx.gbl>
From: Mike Wilson <mikewse@hotmail.com>
To: <dev@cxf.apache.org>
References: <DUB128-DS140D18AC86EE96D24909DCA4160@phx.gbl>
 <54EC5140.8060201@gmail.com> <DUB128-DS26BD3CA01BAEDE5F0E03E9A4160@phx.gbl>
 <54ECAF49.60503@gmail.com>
In-Reply-To: <54ECAF49.60503@gmail.com>
Subject: RE: avoid using contextClassLoader inside OSGi?
Date: Thu, 26 Feb 2015 13:52:56 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AdBQVB5TsWsiGkPFSMCOCFwDKf76pABbamRw

[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