At 01:26 AM 11/13/2004 +0100, you wrote: >On Fri, 12 Nov 2004 12:53:18 -0600, Jonathan Eric Miller ><[EMAIL PROTECTED]> 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 create the file using a simple <Logger> in the <Context> element of my context configuration file. This way, all I have to do is the deploy the app and the log file is created and rolled for me. Of course you're right that the context logging is weak on its own, but with the logging-log4j-sandbox ServletContextLogAppender (see http://tinyurl.com/5mf2q and http://tinyurl.com/3s94q ), I can hook in application logging to go to the ServletContext log file. And since that file is specified by the server, my own log4j config file need not point at any physical location on the machine (and it is my own app's config file, not the server's). The logging will show up wherever the server decides to put the servlet context log file for the application. No more context.getRealPath("/WEB-INF/logs") which is not guaranteed to work in all cases, nor do I have to configure any directory to point logging to. Plus, 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 this ability to dynamically define the logger at deployment time. For each context I want logging for, I have to set up an entry in my server-defined log4j config file in common/classes (in which case I also have to be the server admin) and then deploy the app. This extra step is a real downgrade in functionality and efficiency between 5.0.xx and 5.5.x, IMO. I'd like to see something like the old functionality come back, although I'm not holding my breath.
The other thing I'll mention is not so much a bug or defect, but an unfortunate collision between log4j's dtd and Tomcat-5.5.x's ServletContext logger naming scheme. for Log4j XML config files, the log4j dtd (used for the DOMConfigurator, but not for Log4j-1.3's JoranConfigurator which will, hopefully, ameliorate this issue) specifies the <logger> "name" attribute as being of Type ID. As such, the naming scheme Tomcat-5.5.x uses causes a parsing failure because it uses characters not allowed in XML ID attributes ("[", "]", and "/" in <logger name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/MyContext">). I'm not in any way implying that this is a bug in Tomcat-5.5.x. I just thought I'd mention it for those who attempt to use Log4j XML config files with the DOMConfigurator for servlet context logging. Using a properties file (which, unfortunately, doesn't have all the functionality that an XML config file has) or using Log4j-1.3's new JoranConfigurator should get around this (although I haven't actually tested this claim as of yet).
Jake
>-- >xxxxxxxxxxxxxxxxxxxxxxxxx >Rémy Maucherat >Developer & Consultant >JBoss Group (Europe) SàRL >xxxxxxxxxxxxxxxxxxxxxxxxx > >--------------------------------------------------------------------- >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]
