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. 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. Cheers Niclas
