tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Web apps vs. Logging vs. Tomcat
Date Thu, 17 Mar 2005 21:29:33 GMT
Thanks.  That answers that part of the question quite succinctly.

Now what remains is how can I work with log4j and commons logging -- 
commons logging's behavior vis-a-vis the contextual classloader seems 
onerous if not just plain wrong.

The only way I can see to "fix" this is to deploy log4j in Tomcat's own 
lib directories -- and deploy my log4j controller MBeans there for the 
default LoggeRepository and again in each web app for each web app's 
LoggerRepository.

If that's what I need to do, I'll get on with doing it, but I'd like to 
know I'm not just overlooking the obvious...

--
Jess Holle

Yoav Shapira wrote:

>UGLI is far from mature enough to be used by Tomcat at this point.  When
>log4j 1.3 is out, we'll see.
>
>Yoav
>  
>
>>-----Original Message-----
>>From: Jess Holle [mailto:jessh@ptc.com]
>>Sent: Thursday, March 17, 2005 4:17 PM
>>To: Tomcat Developers List
>>Subject: Re: Web apps vs. Logging vs. Tomcat
>>
>>P.S.  Why does Tomcat use Commons Logging rather than UGLI?
>>
>>Jess Holle wrote:
>>
>>    
>>
>>>I had e-mailed this to users mailing list, but I have what I believe
>>>is a more "dev" follow-on question:
>>>
>>>   Is there a good way to get my own start/stop action called at a
>>>   per-VM level?
>>>
>>>   This is assuming I end up having to move log4j up into Tomcat's
>>>   classloaders -- at which point I'll want to install my
>>>   LoggerRepository controlling MBeans up at this level as well -- as
>>>   log4j's MBeans have issues and using log4j loggers means you don't
>>>   get the (admittedly sparse) java.util.logging MBean coverage.
>>>
>>>--
>>>Jess Holle
>>>
>>>Jess Holle wrote:
>>>
>>>      
>>>
>>>>I have been trying to get really serious about log4j in web apps.
>>>>
>>>>I note that Tomcat (thanks to commons-logging) uses java.util.logging
>>>>*except* for loggers created while my web app's classloader is the
>>>>current contextual classloader -- at which point it suddenly uses
>>>>log4j (since my web app does) without giving my web app a chance to
>>>>initialize it in any way as best I can tell.
>>>>
>>>>My web app has a ServletContextListener which initializes log4j by
>>>>setting up its own LoggerRepository, configuration file and watcher
>>>>(since log4j's won't shutdown), etc.  Of course, every Tomcat logger
>>>>created within my web app up until this point is now using log4j from
>>>>my web app (!) and using the basic log4j.properties [if present] from
>>>>my web app -- for loggers that apply to all web apps!
>>>>
>>>>How is one supposed to work this?  I am currently using a static
>>>>LoggerRepository reference within my web app so that a log4j loaded
>>>>higher in the classloader tree won't cause LoggerRepository sharing.
>>>>I was using a JNDI-based LoggerRepositorySelector as per log4j author
>>>>recommendations, but this goes a step further than above -- it puts
>>>>all the Tomcat loggers that are errantly using my log4j into my
>>>>LoggerRepository -- which would be fine if these loggers were not
>>>>shared with other web apps.
>>>>
>>>>What's the solution here?  Do I have to put log4j into Tomcat's lib
>>>>directories to force it to use its own centralized log4j?  Is that
>>>>the best solution?
>>>>
>>>>--
>>>>Jess Holle
>>>>        
>>>>
>>>
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>    
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>  
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message