On Mon, Jul 7, 2008 at 10:27 PM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > On Tue, Jul 8, 2008 at 3:26 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: >> On Tue, Jul 8, 2008 at 1:31 AM, Karl Pauls <[EMAIL PROTECTED]> 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 > thing. > > 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 > case. > > 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.
Is that something pax logging can do? > 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 > mind. Well, it was the only thing left before considering it a framework bug - I'm lazy :-) regards, Karl > Cheers > Niclas > -- Karl Pauls [EMAIL PROTECTED]
