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
