felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman" <nic...@hedhman.org>
Subject Re: using pax-logger/log4j in embedded felix (class loader issue)
Date Mon, 07 Jul 2008 20:27:34 GMT
On Tue, Jul 8, 2008 at 3:26 AM, Niclas Hedhman <niclas@hedhman.org> wrote:
> On Tue, Jul 8, 2008 at 1:31 AM, Karl Pauls <karlpauls@gmail.com> wrote:
>> Is it somehow possible that log4j is
>> doing some classloader magic itself and maybe is using the context
>> classloader? The context classloader would be the WebAppClassloader I
>> think ...
> Good Suggestion. Will investigate that initially.

Ok. Here is the funky bits. Me and Alin Dreghiciu have both been
looking at different problems today(!) turning out to be the same

Craig, if you took the time to try out Equinox, you would probably
find that it might work in Equinox (the Spring case does), but not in
Felix and not in Knopflerfish... Why?

Log4J (as Spring in Alin's case) try to use the thread context
classloader, if one is present, otherwise use the classloader of
"itself". Hence we are seeing the Webapp classloader being used in
Log4J's loading of resources, resulting in terrible mismatches.
So why does it work in Equinox. Equinox sets the thread context
classloader to something they call ContextFinder, which will look at
the call stack, and take the first classloader found other than system
CL, which would be the classloader of Pax Logging Service in your

So, depending on how you are setting this up, you need to do
"something", like either replicate the ContextFinder approach, or
plainly set the TCL to null prior to loading up Felix.

I would be interested to hear if that helps. Also Many Thanks to Karl
who provided a 'short-cut', as the TCL was not the first thing on my


View raw message