----- Original Message ----- From: "Jess Holle" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org> Sent: Thursday, March 17, 2005 2:25 PM Subject: Re: Web apps vs. Logging vs. Tomcat
> Just one more stupid question: > > How/where would I register/deregister (start/stop) MBeans at the > Tomcat level for the Tomcat-level log4j LoggerRepository -- rather > than in my ServletContextListener? > Sounds like a good use for conf/tomcat5-mbeans.xml. It invokes the standard Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your MBeans at the corresponding points of the Engine's Lifecycle, as well as handling JMX registration and un-registration. > For per-web-app MBeans, I can use ServletContextListener, of course, > but given that log4j loggers are not JMX-exposed, I'd like to put > some MBeans to do this up at the Tomcat application level. I do > this in my web app, but I'd like to have the Tomcat-level MBeans > installed even without any of my web apps installed. > > -- > Jess Holle > > Yoav Shapira wrote: > > >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] > > > > > > > > This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
