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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
