tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Web apps vs. Logging vs. Tomcat
Date Thu, 17 Mar 2005 23:07:03 GMT

----- Original Message -----
From: "Jess Holle" <jessh@ptc.com>
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:jessh@ptc.com]
> >>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: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
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
> >
>
>



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.



Mime
View raw message