Hola, Your approach is right and should work. You basically have to move everything up the classloader hierarchy into Tomcat's section, and have a copy of the MBean stuff in each webapp classloader repository that you want to manage.
And I agree that it sucks... Yoav > -----Original Message----- > From: Jess Holle [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 17, 2005 4:30 PM > To: Tomcat Developers List > Subject: Re: Web apps vs. Logging vs. Tomcat > > 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] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
