Re: Web apps vs. Logging vs. Tomcat
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
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
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
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]
RE: Web apps vs. Logging vs. Tomcat
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]
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]
RE: Web apps vs. Logging vs. Tomcat
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]
Re: Web apps vs. Logging vs. Tomcat
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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? 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]
Re: Web apps vs. Logging vs. Tomcat
- 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
Re: Web apps vs. Logging vs. Tomcat
Bill Barker wrote: - 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. 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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
- Original Message - From: Jess Holle [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@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 [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. 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web apps vs. Logging vs. Tomcat
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web apps vs. Logging vs. Tomcat
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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
