From tomcat-dev-return-57075-apmail-jakarta-tomcat-dev-archive=jakarta.apache.org@jakarta.apache.org Fri Mar 18 02:37:57 2005 Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 54134 invoked from network); 18 Mar 2005 02:37:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 18 Mar 2005 02:37:57 -0000 Received: (qmail 93459 invoked by uid 500); 18 Mar 2005 02:37:52 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 93428 invoked by uid 500); 18 Mar 2005 02:37:51 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 93412 invoked by uid 99); 18 Mar 2005 02:37:51 -0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_10_20,HTML_MESSAGE,HTML_TITLE_EMPTY X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from relay2.ptc.com (HELO relay2.ptc.com) (12.11.148.122) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 17 Mar 2005 18:37:51 -0800 Received: from hq-exfe3.ptcnet.ptc.com (132.253.201.80) by relay2.ptc.com with ESMTP; 17 Mar 2005 21:38:52 -0500 X-IronPort-AV: i="3.91,100,1110171600"; d="scan'208,217"; a="13507192:sNHT29058904" Received: from [132.253.40.185] ([132.253.40.185]) by HQ-EXFE3.ptcnet.ptc.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Mar 2005 21:38:05 -0500 Message-ID: <423A3F0C.6070802@ptc.com> Date: Thu, 17 Mar 2005 20:38:04 -0600 From: Jess Holle User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat References: <200503172120.j2HLKX0Z025235@outgoing.mit.edu> <423A00DF.9080700@apache.org> <423A03AA.6010801@ptc.com> <423A11B9.5060007@apache.org> In-Reply-To: <423A11B9.5060007@apache.org> Content-Type: multipart/alternative; boundary="------------000003080501040302040402" X-OriginalArrivalTime: 18 Mar 2005 02:38:05.0267 (UTC) FILETIME=[83306230:01C52B63] X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --------------000003080501040302040402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------000003080501040302040402--