You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jess Holle <je...@ptc.com> on 2005/03/17 21:48:38 UTC
Re: Web apps vs. Logging vs. Tomcat
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
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Bill Barker wrote:
>You just need to provide the methods (if you wanted to code against
>Catalina, you'd just create a LifecycleListener :). This is a hook into
>commons-modeler, so you technically could use a plain old JavaBean.
>Otherwise, DynamicMBeans probably work best (or, at least give you the most
>control).
>
>
I have gotten used to using my own subclasses to StandardMBean. This
allows me to lay out the "static" portion of my MBean with an interface
and extend it as necessary -- adding dynamic and open MBean behaviors as
necessary in my own classes.
Java 1.5's APT turns out to make automated generation of MBean
descriptions, operation parameter names, impacts, etc, from MBean
interface Javadoc, formal parmeter names, annotations, etc, quite
simple. A little more elbow grease and the descriptions are localized
(based on the server's locale).
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jess Holle" <je...@ptc.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, March 17, 2005 3:12 PM
Subject: Re: Web apps vs. Logging vs. Tomcat
> Bill Barker wrote:
>
> >----- Original Message -----
> >From: "Jess Holle" <je...@ptc.com>
> >To: "Tomcat Developers List" <to...@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.
> >
> >
> Cool! Thanks!
>
> Do I have to actually implement Lifecycle or just provide these
> methods? Will a standard/dynamic MBean do or does it have to be a model
> MBean? [Mine extend StandardMBean and implement MBeanRegistration at
> the moment.]
>
You just need to provide the methods (if you wanted to code against
Catalina, you'd just create a LifecycleListener :). This is a hook into
commons-modeler, so you technically could use a plain old JavaBean.
Otherwise, DynamicMBeans probably work best (or, at least give you the most
control).
> --
> Jess Holle
>
>
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.
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Bill Barker wrote:
>----- Original Message -----
>From: "Jess Holle" <je...@ptc.com>
>To: "Tomcat Developers List" <to...@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.
>
>
Cool! Thanks!
Do I have to actually implement Lifecycle or just provide these
methods? Will a standard/dynamic MBean do or does it have to be a model
MBean? [Mine extend StandardMBean and implement MBeanRegistration at
the moment.]
--
Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jess Holle" <je...@ptc.com>
To: "Tomcat Developers List" <to...@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.
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
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?
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
>
>
>
RE: Web apps vs. Logging vs. Tomcat
Posted by Yoav Shapira <yo...@MIT.EDU>.
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
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
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
>
>
>
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> I also added fixes recently so that loggers are not accessed too
> early, which was a similar issue (some loggers would be have be
> improperly associated with the container classloader). There's lots of
> tweaking needed with logging overall, it's sort of to be expected.
I'll have to check out the latest 5.5 as that's basically the other
problem I was seeing. Tomcat using my log4j and my log4j.properties,
but was doing so before my first ServletContextListener was called, so I
had not had a chance to install my LoggerRepositorySelector. Thus these
loggers were in my web app but not using the LoggerRepository I
designated for my web app...
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Here, I suppose modifying all the loggers to be like this:
> private Log log = LogFactory.getLog(JspServlet.class);
> would fix the issue without further problems.
Hmm... Any chance of such a fix in the next few months. I can search
out such and suggest patches, but I'm quite sure you have a far greater
degree of familiarity with the details -- I just saw the "configuration
nightmare" as you aptly put it.
> It's not the official J2EE way (there's no official J2EE way, as the
> default java.util.logging implementation is one global namespace
> unsuitable for containers), but it's similar to JNDI handling.
Understood. I've already got reasonable JNDI-based approach -- assuming
the static loggers are to be cleaned up any time in the near future.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Remy Maucherat wrote:
> What's unexpected here is as you say that these loggers are static -- or
> in any event not per-web-app. Otherwise, this behavior would be fine
> and good!
Yes, I forgot about Jasper when I added the container loggers in 5.5 :(
At first when we added commons-logging support, we added static loggers
everywhere, since it was very easy this way.
Example from the main JSP servlet class:
private static Log log = LogFactory.getLog(JspServlet.class);
So since Jasper is in the common classloader, the class definition will
be loaded only once, and the loggers used by Jasper will be associated
with the first webapp which is loaded. It's a bit random, since some
classes (ex: the compiler) may be loaded a bit later by other webapps.
-> configuration nightmare
I also added fixes recently so that loggers are not accessed too early,
which was a similar issue (some loggers would be have be improperly
associated with the container classloader). There's lots of tweaking
needed with logging overall, it's sort of to be expected.
Here, I suppose modifying all the loggers to be like this:
private Log log = LogFactory.getLog(JspServlet.class);
would fix the issue without further problems.
>> Another completely different strategy for acquiring loggers is to use
>> the CL which loaded the class (ie, to use straight delegation).
>> There's the problem that it could cause classcast exceptions, however,
>> and it's more annoying to configure.
>>
>> Both solutions behave differently, but they have their own merits. I
>> happen to prefer the context classloader oriented one in a J2EE
>> environment (so it was used for the java.util.logging implementation I
>> added recently based on some user submitted code that I heavily
>> modfied - see http://issues.apache.org/bugzilla/show_bug.cgi?id=33143).
>
> Yes, I now have both approaches coded and as you say both have their
> merits. If the instances wherein Tomcat loggers configured/obtained
> from one web app are used across web apps are eliminated in Tomcat
> 5.5.x, then I could happily use the JNDI/J2EE approach and all Tomcat's
> own loggers for each web app would use that web app's configuration.
> Otherwise I really have to go with the straight delegation approach to
> prevent cross-web-app logger effects.
It's not the official J2EE way (there's no official J2EE way, as the
default java.util.logging implementation is one global namespace
unsuitable for containers), but it's similar to JNDI handling.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Jess Holle wrote:
>
>> Jess Holle wrote:
>>
>> Okay, I did a bit more digging.
>>
>> *If*:
>>
>> * Your web app contains log4j.jar *and* commons-logging.jar.
>> * You do not have log4j installed in any of Tomcat's own lib
>> directories.
>> * You use a JNDI or other contextual classloader based
>> LogRepositorySelector.
>>
>> *Then*:
>>
>> * The first Tomcat web application will "steal" loggers from the
>> Tomcat base, i.e. any that happen to be obtained while the first
>> web app's contextual classloader is active.
>> o In a brief, simple test, whichever web app receives the
>> first JSP page request will "steal" the following Tomcat
>> loggers:
>> + org.apache.jasper.compiler.Compiler
>> + org.apache.jasper.compiler.JspReader
>> + org.apache.jasper.runtime.PageContextImpl
>> + org.apache.jasper.servlet.JspServletWrapper
>> + org.apache.jasper.xmlparser.ParserUtils
>> * By "steal", I mean that these loggers end up in the
>> LoggerRepository of the given web app. Their configuration is thus
>> controlled by it. Also, they use the log4j library from the given
>> web app.
>
> There's nothing unexpected here: Jasper is a regular servlet, and thus
> all of its classes will be loaded with the webapp's classloader. It's
> basically like if you had the Jasper JARs inside /WEB-INF/lib. The
> problem then is that Jasper uses static logger instances, while it
> should either log to the servlet context or have per instance loggers,
> as it resides in a classloader shared across webapps. Regardless of
> what happens, we will need to cleanup Jasper's logging behavior.
What's unexpected here is as you say that these loggers are static -- or
in any event not per-web-app. Otherwise, this behavior would be fine
and good!
> Another completely different strategy for acquiring loggers is to use
> the CL which loaded the class (ie, to use straight delegation).
> There's the problem that it could cause classcast exceptions, however,
> and it's more annoying to configure.
>
> Both solutions behave differently, but they have their own merits. I
> happen to prefer the context classloader oriented one in a J2EE
> environment (so it was used for the java.util.logging implementation I
> added recently based on some user submitted code that I heavily
> modfied - see http://issues.apache.org/bugzilla/show_bug.cgi?id=33143).
Yes, I now have both approaches coded and as you say both have their
merits. If the instances wherein Tomcat loggers configured/obtained
from one web app are used across web apps are eliminated in Tomcat
5.5.x, then I could happily use the JNDI/J2EE approach and all Tomcat's
own loggers for each web app would use that web app's configuration.
Otherwise I really have to go with the straight delegation approach to
prevent cross-web-app logger effects.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Jess Holle wrote:
>
> Okay, I did a bit more digging.
>
> *If*:
>
> * Your web app contains log4j.jar *and* commons-logging.jar.
> * You do not have log4j installed in any of Tomcat's own lib
> directories.
> * You use a JNDI or other contextual classloader based
> LogRepositorySelector.
>
> *Then*:
>
> * The first Tomcat web application will "steal" loggers from the
> Tomcat base, i.e. any that happen to be obtained while the first
> web app's contextual classloader is active.
> o In a brief, simple test, whichever web app receives the
> first JSP page request will "steal" the following Tomcat
> loggers:
> + org.apache.jasper.compiler.Compiler
> + org.apache.jasper.compiler.JspReader
> + org.apache.jasper.runtime.PageContextImpl
> + org.apache.jasper.servlet.JspServletWrapper
> + org.apache.jasper.xmlparser.ParserUtils
> * By "steal", I mean that these loggers end up in the
> LoggerRepository of the given web app. Their configuration is thus
> controlled by it. Also, they use the log4j library from the given
> web app.
There's nothing unexpected here: Jasper is a regular servlet, and thus
all of its classes will be loaded with the webapp's classloader. It's
basically like if you had the Jasper JARs inside /WEB-INF/lib. The
problem then is that Jasper uses static logger instances, while it
should either log to the servlet context or have per instance loggers,
as it resides in a classloader shared across webapps. Regardless of what
happens, we will need to cleanup Jasper's logging behavior.
Another completely different strategy for acquiring loggers is to use
the CL which loaded the class (ie, to use straight delegation). There's
the problem that it could cause classcast exceptions, however, and it's
more annoying to configure.
Both solutions behave differently, but they have their own merits. I
happen to prefer the context classloader oriented one in a J2EE
environment (so it was used for the java.util.logging implementation I
added recently based on some user submitted code that I heavily modfied
- see http://issues.apache.org/bugzilla/show_bug.cgi?id=33143).
> I could always be mistaken, but my examination of the LoggerRepository's
> involved seems pretty conclusive.
>
> If one has to have log4j and commons-logging in one's web app, then the
> only solution appears to be to put log4j in Tomcat and use a
> non-contextual classloader based LogRepositorySelector. Avoiding the
> contextual classloader based LogRepositorySelector only keeps Tomcats
> loggers from sharing the web app's intended LoggerRepository -- they
> still use the web app's log4j and its default LoggerRepository.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Jess Holle wrote:
> Remy Maucherat wrote:
>
>>>> BTW, JBoss (supposedly, I didn't check personally) uses
>>>> commons-logging everywhere, and the logging implementation used is
>>>> log4j.
>>>
>>> That works since *everything* uses log4j. The issue is with Tomcat
>>> is really one of *not* having log4j at the Tomcat level but having
>>> it in your web app. This leads to:
>>>
>>> * whole crop of loggers using java.util.logging (fine, to be
>>> expected, and there are Java 5 MBeans -- albeit limited -- to
>>> interact with these)
>>> * a few core Tomcat loggers that are *not* by nature per web app
>>> loggers using the log4j jar and configuration of the first web app
>>> that uses the class enclosing them (e.g. the first web app to get
>>> a request!)
>>> * the web app's own classes using whatever you specify
>>>
>>> It is the 2nd of these 3 bullet that is so disturbing to me. I'd
>>> like to see these either have separate loggers for each web app, or
>>> behave like the rest the Tomcat loggers and cause a leak of data and
>>> references between web apps. This -- and a reasonable set of MBeans
>>> to control/expose loggers seems quite doable with the approach Yoav
>>> and Bill laid out. It's just unfortunate that the out-of-the-box
>>> behavior with web apps using log4j is so onerous.
>>
>> The core loggers you talk about are probably the ones used for
>> reporting your servlets/filters/etc loading errors. This seems webapp
>> related to me.
>
> Considering the classes containing these loggers are not per web app
> as best I can tell I don't believe the loggers are, but I guess more
> thorough debugging on my part is in order. Perhaps I am mistaken and
> these are Tomcat loggers, but are specific to my web app.
Okay, I did a bit more digging.
*If*:
* Your web app contains log4j.jar *and* commons-logging.jar.
* You do not have log4j installed in any of Tomcat's own lib
directories.
* You use a JNDI or other contextual classloader based
LogRepositorySelector.
*Then*:
* The first Tomcat web application will "steal" loggers from the
Tomcat base, i.e. any that happen to be obtained while the first
web app's contextual classloader is active.
o In a brief, simple test, whichever web app receives the
first JSP page request will "steal" the following Tomcat
loggers:
+ org.apache.jasper.compiler.Compiler
+ org.apache.jasper.compiler.JspReader
+ org.apache.jasper.runtime.PageContextImpl
+ org.apache.jasper.servlet.JspServletWrapper
+ org.apache.jasper.xmlparser.ParserUtils
* By "steal", I mean that these loggers end up in the
LoggerRepository of the given web app. Their configuration is thus
controlled by it. Also, they use the log4j library from the given
web app.
I could always be mistaken, but my examination of the LoggerRepository's
involved seems pretty conclusive.
If one has to have log4j and commons-logging in one's web app, then the
only solution appears to be to put log4j in Tomcat and use a
non-contextual classloader based LogRepositorySelector. Avoiding the
contextual classloader based LogRepositorySelector only keeps Tomcats
loggers from sharing the web app's intended LoggerRepository -- they
still use the web app's log4j and its default LoggerRepository.
--
Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
>>> BTW, JBoss (supposedly, I didn't check personally) uses
>>> commons-logging everywhere, and the logging implementation used is
>>> log4j.
>>
>> That works since *everything* uses log4j. The issue is with Tomcat
>> is really one of *not* having log4j at the Tomcat level but having it
>> in your web app. This leads to:
>>
>> * whole crop of loggers using java.util.logging (fine, to be
>> expected, and there are Java 5 MBeans -- albeit limited -- to
>> interact with these)
>> * a few core Tomcat loggers that are *not* by nature per web app
>> loggers using the log4j jar and configuration of the first web app
>> that uses the class enclosing them (e.g. the first web app to get
>> a request!)
>> * the web app's own classes using whatever you specify
>>
>> It is the 2nd of these 3 bullet that is so disturbing to me. I'd
>> like to see these either have separate loggers for each web app, or
>> behave like the rest the Tomcat loggers and cause a leak of data and
>> references between web apps. This -- and a reasonable set of MBeans
>> to control/expose loggers seems quite doable with the approach Yoav
>> and Bill laid out. It's just unfortunate that the out-of-the-box
>> behavior with web apps using log4j is so onerous.
>
> The core loggers you talk about are probably the ones used for
> reporting your servlets/filters/etc loading errors. This seems webapp
> related to me.
Considering the classes containing these loggers are not per web app as
best I can tell I don't believe the loggers are, but I guess more
thorough debugging on my part is in order. Perhaps I am mistaken and
these are Tomcat loggers, but are specific to my web app.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Remy Maucherat wrote:
>
>> Jess Holle wrote:
>>
>>> Why out of curiosity? I don't have a pro-UGLI ax to grind here, but
>>> Commons-Logging's behavior in Tomcat is really undesirable as is.
>>
>> It would be the same anyway: the loading configuration and the logger
>> instances will be tied to the webapp classloader. It has to work this
>> way. As I understand it, the thing that does not work for you right
>> now is that Tomcat uses your webapp's logger namespace before your
>> callbacks are called.
>
> Yes. The issue is really that Tomcat uses log4j out of my web app for
> loggers that are to be used outside my web app. Not only is the library
> used out of my web app but so is the configuration -- meaning web app A
> gets core Tomcat log output from web apps B and C...
>
> Yoav confirmed that the solution is to move log4j and a default
> configuration higher in the stack so that everything uses it. This
> together with a per-web-app ClassLoader (but not contextual
> classloader!) based LoggerRepository will ensure each web app gets its
> own loggers and configuration files and Tomcat core gets its own.
Yes, the logging namespaces need to be separate. I was faced with the
issue very recently when writing a log manager for java.util.logging
which would have a separate logger namespace for each classloader.
>>> Now if you're inside JBoss and it has pre-established log4j and
>>> configured it prior to Tomcat loading, then I don't see a problem
>>> with Commons Logging. Standalone Tomcat's Commons Logging behavior
>>> vis-a-vis log4j would seem to be an issue, though. The issues are
>>> especially bad and bizarre when log4j is used in a web app but Tomcat
>>> itself does not have log4j installed, but this is only part of the
>>> issue.
>>
>> I don't see any real difference. There should be plenty of container
>> listeners and stuff available to configure this.
>> (I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue
>> what it is)
>
> The nice thing about this as I understand it is that it would allow me
> to set up my own MBeans for a Tomcat-level / app-wide log4j
> LoggerRepository.
>
> You're right, though, as far as per-web-app MBeans and
> LoggerRepository's -- there are more than enough servlet listeners, etc,
> in the servlet spec to handle this.
>
>> BTW, JBoss (supposedly, I didn't check personally) uses
>> commons-logging everywhere, and the logging implementation used is log4j.
>
> That works since *everything* uses log4j. The issue is with Tomcat is
> really one of *not* having log4j at the Tomcat level but having it in
> your web app. This leads to:
>
> * whole crop of loggers using java.util.logging (fine, to be
> expected, and there are Java 5 MBeans -- albeit limited -- to
> interact with these)
> * a few core Tomcat loggers that are *not* by nature per web app
> loggers using the log4j jar and configuration of the first web app
> that uses the class enclosing them (e.g. the first web app to get
> a request!)
> * the web app's own classes using whatever you specify
>
> It is the 2nd of these 3 bullet that is so disturbing to me. I'd like
> to see these either have separate loggers for each web app, or behave
> like the rest the Tomcat loggers and cause a leak of data and references
> between web apps. This -- and a reasonable set of MBeans to
> control/expose loggers seems quite doable with the approach Yoav and
> Bill laid out. It's just unfortunate that the out-of-the-box behavior
> with web apps using log4j is so onerous.
The core loggers you talk about are probably the ones used for reporting
your servlets/filters/etc loading errors. This seems webapp related to me.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Jess Holle wrote:
>
>> Why out of curiosity? I don't have a pro-UGLI ax to grind here, but
>> Commons-Logging's behavior in Tomcat is really undesirable as is.
>
> It would be the same anyway: the loading configuration and the logger
> instances will be tied to the webapp classloader. It has to work this
> way. As I understand it, the thing that does not work for you right
> now is that Tomcat uses your webapp's logger namespace before your
> callbacks are called.
Yes. The issue is really that Tomcat uses log4j out of my web app for
loggers that are to be used outside my web app. Not only is the library
used out of my web app but so is the configuration -- meaning web app A
gets core Tomcat log output from web apps B and C...
Yoav confirmed that the solution is to move log4j and a default
configuration higher in the stack so that everything uses it. This
together with a per-web-app ClassLoader (but not contextual
classloader!) based LoggerRepository will ensure each web app gets its
own loggers and configuration files and Tomcat core gets its own.
>> Now if you're inside JBoss and it has pre-established log4j and
>> configured it prior to Tomcat loading, then I don't see a problem
>> with Commons Logging. Standalone Tomcat's Commons Logging behavior
>> vis-a-vis log4j would seem to be an issue, though. The issues are
>> especially bad and bizarre when log4j is used in a web app but Tomcat
>> itself does not have log4j installed, but this is only part of the
>> issue.
>
> I don't see any real difference. There should be plenty of container
> listeners and stuff available to configure this.
> (I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue
> what it is)
The nice thing about this as I understand it is that it would allow me
to set up my own MBeans for a Tomcat-level / app-wide log4j
LoggerRepository.
You're right, though, as far as per-web-app MBeans and
LoggerRepository's -- there are more than enough servlet listeners, etc,
in the servlet spec to handle this.
> BTW, JBoss (supposedly, I didn't check personally) uses
> commons-logging everywhere, and the logging implementation used is log4j.
That works since *everything* uses log4j. The issue is with Tomcat is
really one of *not* having log4j at the Tomcat level but having it in
your web app. This leads to:
* whole crop of loggers using java.util.logging (fine, to be
expected, and there are Java 5 MBeans -- albeit limited -- to
interact with these)
* a few core Tomcat loggers that are *not* by nature per web app
loggers using the log4j jar and configuration of the first web app
that uses the class enclosing them (e.g. the first web app to get
a request!)
* the web app's own classes using whatever you specify
It is the 2nd of these 3 bullet that is so disturbing to me. I'd like
to see these either have separate loggers for each web app, or behave
like the rest the Tomcat loggers and cause a leak of data and references
between web apps. This -- and a reasonable set of MBeans to
control/expose loggers seems quite doable with the approach Yoav and
Bill laid out. It's just unfortunate that the out-of-the-box behavior
with web apps using log4j is so onerous.
--
Jess Holle
Re: Web apps vs. Logging vs. Tomcat
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Why out of curiosity? I don't have a pro-UGLI ax to grind here, but
> Commons-Logging's behavior in Tomcat is really undesirable as is.
It would be the same anyway: the loading configuration and the logger
instances will be tied to the webapp classloader. It has to work this
way. As I understand it, the thing that does not work for you right now
is that Tomcat uses your webapp's logger namespace before your callbacks
are called.
> Now if you're inside JBoss and it has pre-established log4j and
> configured it prior to Tomcat loading, then I don't see a problem with
> Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis
> log4j would seem to be an issue, though. The issues are especially bad
> and bizarre when log4j is used in a web app but Tomcat itself does not
> have log4j installed, but this is only part of the issue.
I don't see any real difference. There should be plenty of container
listeners and stuff available to configure this.
(I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue
what it is)
BTW, JBoss (supposedly, I didn't check personally) uses commons-logging
everywhere, and the logging implementation used is log4j.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> 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.
>
> I already voted on that: -1.
Why out of curiosity? I don't have a pro-UGLI ax to grind here, but
Commons-Logging's behavior in Tomcat is really undesirable as is.
Now if you're inside JBoss and it has pre-established log4j and
configured it prior to Tomcat loading, then I don't see a problem with
Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis
log4j would seem to be an issue, though. The issues are especially bad
and bizarre when log4j is used in a web app but Tomcat itself does not
have log4j installed, but this is only part of the issue.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Web apps vs. Logging vs. Tomcat
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
> 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.
>
> I already voted on that: -1.
>
> Rémy
Yup, I know. I'm holding out for the possibility that UGLI will be a good
enough solution and a significant enough improvement of JCL to merit
re-consideration at some future time.
As I said, it's not something I'm pushing now, as the above is far (on the
time scale) from happening.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Web apps vs. Logging vs. Tomcat
Posted by Remy Maucherat <re...@apache.org>.
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.
I already voted on that: -1.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Web apps vs. Logging vs. Tomcat
Posted by Yoav Shapira <yo...@MIT.EDU>.
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
Re: Web apps vs. Logging vs. Tomcat
Posted by Jess Holle <je...@ptc.com>.
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