Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@www.apache.org Received: (qmail 35425 invoked from network); 15 Nov 2004 04:07:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 15 Nov 2004 04:07:53 -0000 Received: (qmail 22482 invoked by uid 500); 15 Nov 2004 04:07:37 -0000 Delivered-To: apmail-jakarta-tomcat-user-archive@jakarta.apache.org Received: (qmail 21860 invoked by uid 500); 15 Nov 2004 04:07:33 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 21846 invoked by uid 99); 15 Nov 2004 04:07:33 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO,MIME_QP_LONG_LINE X-Spam-Check-By: apache.org Received-SPF: error (hermes.apache.org: encountered temporary error during SPF processing of domain of hoju@visi.com) Received: from [204.127.202.56] (HELO sccrmhc12.comcast.net) (204.127.202.56) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 14 Nov 2004 20:07:27 -0800 Received: from nicki.visi.com (c-66-41-141-26.mn.client2.attbi.com[66.41.141.26]) by comcast.net (sccrmhc12) with SMTP id <2004111504070801200cr6lme>; Mon, 15 Nov 2004 04:07:08 +0000 Message-Id: <5.2.1.1.0.20041114212446.03679ac8@pop.shell.visi.com> X-Sender: hoju@pop.shell.visi.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 14 Nov 2004 22:06:19 -0600 To: "Tomcat Users List" From: Jacob Kjome Subject: Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log In-Reply-To: <6d959d48041112162632608c0c@mail.gmail.com> References: <003901c4c8e8$e02670c0$e3118780@skate> <5684A7E6FB10504393A2806C1F4C021003B0E678@orion.qas.com> <6d959d48041111120296f8664@mail.gmail.com> <003901c4c8e8$e02670c0$e3118780@skate> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N At 01:26 AM 11/13/2004 +0100, you wrote: >On Fri, 12 Nov 2004 12:53:18 -0600, Jonathan Eric Miller > wrote: >> Actually, I guess the default isn't that bad for UNIX/Linux anyway. In > >On Windows, I think it's time to start using the .exe wrapper (or >another similar wrapper), rather than keep using the .bat scripts, >given their current limitations. This redirects output to log files, >which are not rotated at the moment (unlike the main procrun logger). >I suppose the feature could be added. > >I know the "new" logging is not perfect, but I think it's better than >it was before. As the ServletContext logging is bad, applications were >never using it, and logging could not be unified due to Tomcat's use >of proprietary loggers. The container logger often has little data, >usually uncaught exceptions. > What I liked about the ServletContext logging was that I could dynamically= =20 create the file using a simple in the element of my=20 context configuration file. This way, all I have to do is the deploy the=20 app and the log file is created and rolled for me. Of course you're right= =20 that the context logging is weak on its own, but with the=20 logging-log4j-sandbox ServletContextLogAppender (see=20 http://tinyurl.com/5mf2q and http://tinyurl.com/3s94q ), I can hook in=20 application logging to go to the ServletContext log file. And since that=20 file is specified by the server, my own log4j config file need not point at= =20 any physical location on the machine (and it is my own app's config file,=20 not the server's). The logging will show up wherever the server decides to= =20 put the servlet context log file for the application. No more=20 context.getRealPath("/WEB-INF/logs") which is not guaranteed to work in all= =20 cases, nor do I have to configure any directory to point logging to. Plus,= =20 I have the full power of Log4j. This is logging heaven right up to Tomcat-5.0.xx, but with 5.5.x, I lose=20 this ability to dynamically define the logger at deployment time. For each= =20 context I want logging for, I have to set up an entry in my server-defined= =20 log4j config file in common/classes (in which case I also have to be the=20 server admin) and then deploy the app. This extra step is a real downgrade= =20 in functionality and efficiency between 5.0.xx and 5.5.x, IMO. I'd like to= =20 see something like the old functionality come back, although I'm not=20 holding my breath. The other thing I'll mention is not so much a bug or defect, but an=20 unfortunate collision between log4j's dtd and Tomcat-5.5.x's ServletContext= =20 logger naming scheme. for Log4j XML config files, the log4j dtd (used for= =20 the DOMConfigurator, but not for Log4j-1.3's JoranConfigurator which will,= =20 hopefully, ameliorate this issue) specifies the "name" attribute=20 as being of Type ID. As such, the naming scheme Tomcat-5.5.x uses causes a= =20 parsing failure because it uses characters not allowed in XML ID attributes= =20 ("[", "]", and "/" in ).=20 I'm not in any way implying that this is a bug in Tomcat-5.5.x. I just=20 thought I'd mention it for those who attempt to use Log4j XML config files= =20 with the DOMConfigurator for servlet context logging. Using a properties=20 file (which, unfortunately, doesn't have all the functionality that an XML= =20 config file has) or using Log4j-1.3's new JoranConfigurator should get=20 around this (although I haven't actually tested this claim as of yet). Jake >-- >xxxxxxxxxxxxxxxxxxxxxxxxx >R=E9my Maucherat >Developer & Consultant >JBoss Group (Europe) S=E0RL >xxxxxxxxxxxxxxxxxxxxxxxxx > >--------------------------------------------------------------------- >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-user-help@jakarta.apache.org