[logback-dev] App Servers and Thread.contextClassLoader

[Robert Elliot]

Hi Ceki,


On 30 Jul 2009, at 14:45, Ceki Gulcu wrote:

>
> my recommendation would be to ignore the
> logging separation issue by delegating it to SLF4J.
>

I intend to - the problem I'm trying to solve is that the webapp which  
replaces System.out will replace it with an instance of a class loaded  
by that webapp's classloader, which will load SLF4J and whatever  
binding it is loading.  So which ever web app is the last to replace  
System.out will get all System.out calls in all webapps (and indeed in  
the app server) redirected to the logging system specific to that  
webapp.  Which isn't what I want.  I've got a theory about it,  
hopefully I can get something working soon and show it, as real code  
is a better basis for discussion.
>
> Yes, as far as I know, the app server will set the web app specific
> class loader for the current thread.

Great, thanks.
> As for your goal, most application servers have their own way of
> capturing and redirecting the console. So you may be facing a big
> hurdle in order to get an app server to adopt your library.

Oh, I'm not aiming that high!  Just to allow the writer of a webapp to  
configure where System.out goes without it screwing up every other  
webapp deployed on the app server.

>
> Anyway, is it correct to assume that you wish to tackle bug 110 [1]
> outside SLF4J?

No, I'd still like to donate it  if you want it - just life has got in  
the way, I've embarked on a fairly major refactor and encountered  
issues like the one described above and a classloader memory leak that  
would mean anyone using the library and redeploying the webapp  
dynamically would have got PermGen issues.  I've got another idea  
about the exception handling issue, too.  Hopefully have something out  
soon.

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/logback-dev/attachments/20090730/06d74fb0/attachment-0001.htm>