Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Jacob Kjome wrote: 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. I'd like to see something like the old functionality come back, although I'm not holding my breath. I second that. There is even one more reason why Tomcat 5.0 logging was better: With Tomcat 5.0, it was possible to log different web applications to different log files by using the swallowOutput attribute of the Context element, even if those applications used the same libraries. I know that swallowOutput is just a hack to capture the output of badly written applications that do their logging via System.out, but hey, it also worked for java.util.logging-based applications and it seemed to be the only way to distinguish between web applications. With Tomcat 5.5, I have no idea what application a log entry of, say, class org.apache.commons.fileupload.FileUploadBase is belonging to. It could be just any of my applications, because they all use Commons Fileupload. It is not sufficient to only select by package and class names. Regards, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log
I think you hit the nail on the head with the problem being people use System.out to log. I suppose it's the lesser of 2 evils .. should Tomcat's internal logging setup continue to support bad web application setup, or does it try to move forward like 5.5 is doing. Put simply, if you want per-web application logging, you need per-web application log4j configuration. It's very easy to do but I do understand that those using System.out will have to spend time refactoring. But they can stay on their = 5.0 versions. It's just 5.5 that moves away from this, so your decision I suppose. -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Andreas Schildbach Sent: 17 November 2004 15:27 To: [EMAIL PROTECTED] Subject: Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log Jacob Kjome wrote: 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. I'd like to see something like the old functionality come back, although I'm not holding my breath. I second that. There is even one more reason why Tomcat 5.0 logging was better: With Tomcat 5.0, it was possible to log different web applications to different log files by using the swallowOutput attribute of the Context element, even if those applications used the same libraries. I know that swallowOutput is just a hack to capture the output of badly written applications that do their logging via System.out, but hey, it also worked for java.util.logging-based applications and it seemed to be the only way to distinguish between web applications. With Tomcat 5.5, I have no idea what application a log entry of, say, class org.apache.commons.fileupload.FileUploadBase is belonging to. It could be just any of my applications, because they all use Commons Fileupload. It is not sufficient to only select by package and class names. Regards, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Hi, There is even one more reason why Tomcat 5.0 logging was better: With Tomcat 5.0, it was possible to log different web applications to different log files by using the swallowOutput attribute of the Context element, even if those applications used the same libraries. I This is still possible with proper logging configuration: the loggers are different for the webapps, but the appenders can be the same. As Jacob said, don't hold your breath waiting for Logger to come back: we carried our Loggers far too long as it was. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Shapira, Yoav wrote: There is even one more reason why Tomcat 5.0 logging was better: With Tomcat 5.0, it was possible to log different web applications to different log files by using the swallowOutput attribute of the Context element, even if those applications used the same libraries. I This is still possible with proper logging configuration: the loggers are different for the webapps, but the appenders can be the same. Can anyone give an example of how to configure this for java.util.logging, please? (I am not using log4j) Regards, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
On Wed, 17 Nov 2004 15:37:10 -, Allistair Crossley
[EMAIL PROTECTED] wrote:
Put simply, if you want per-web application logging, you need per-web
application log4j configuration. It's very easy to do but I do understand
that those using System.out will have to spend time refactoring. But they can
stay on their = 5.0 versions.
This is wrong: swallowOutput will log to the Context category name
using commons-logging.
if (context.getSwallowOutput()) {
try {
SystemLogHandler.startCapture();
filterChain.doFilter(request.getRequest(),
response.getResponse());
} finally {
String log = SystemLogHandler.stopCapture();
if (log != null log.length() 0) {
context.getLogger().info(log);
}
}
} else {
filterChain.doFilter
(request.getRequest(), response.getResponse());
}
--
x
Rémy Maucherat
Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
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 -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - 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: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Hi, I have some new information on this for my case. I created a small JSP that had a scriplet error and ran it. I am definately using 5.5.4 with Java 5.0. In this case, I got the error stack trace in stdout. This used to come out in localhost_log. That's fine, at least I got it. However, there is an error produced by my application on startup that is *not* being dumped anywhere, and I do not believe either that any amount of log4j/commons configuration would get it because log4j/commons logging is only useful where the developer chooses to notify the logging subsystem which is not runtime errors fromt the JRE. This is part of the stack trace in 5.0.28's localhost_log 2004-11-08 09:29:32 StandardContext[/iq]Exception sending context initialized event to listener instance of class com.qas.newmedia.intranet.iq.IQContextListener java.lang.NullPointerException at com.qas.newmedia.intranet.iq.logic.core.CoreLogic.getDepartmentsByCategory(CoreLogic.java:234) at com.qas.newmedia.intranet.iq.IQContextListener.contextInitialized(IQContextListener.java:86) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3805) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4321) Therefore a NullPointerException is being thrown in 5.5.4 but not being reported anywhere which is a little unhelpful for me :( So I am back to my original question really ... how on earth would I get this NPE logged by Tomcat 5.5.4. Cheers, Allistair -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 11 November 2004 20:34 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hi, I disagree with this statement, as it's too general. Personally, I consider what is definitely superior in log4j are the many logger implementations. As far as I can tell, these could (= should) be ported to the java.logging API. Sun can port those any time it wants -- they have the source. Log4j has features that make a difference in real life that go far beyond the logger implementations, in the areas of receivers and listeners. I see many people (including my company) moving away from the log4j API, and going to commons-logging in order to get unified logging. Ceki's continual refusal to engage in standardization process Whoa there ;) I don't think the causality is right above. Log4j is not the reason commons-logging is around. Commons-Logging was created to address other logging frameworks, most of which including JDK 1.4 logging far post-date log4j. If anything, those frameworks have caused more fragmentation than log4j itself. Many of the relevant logging standards (given that there's no JSR) are derived (if not plain copied) from log4j. Furthermore, the log4j people have been working for improve standards and teamwork in this area, with Logging Services TLP and its other projects like log4net, log4cpp, etc. will unfortunately have to veto any proposal to ship it with Tomcat. I don't think any such proposal is forthcoming ;) I'm in an anti-bloat mood anyways, don't want to add anything else. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
On Fri, 12 Nov 2004 09:55:20 -, Allistair Crossley [EMAIL PROTECTED] wrote: Hi, I have some new information on this for my case. I created a small JSP that had a scriplet error and ran it. I am definately using 5.5.4 with Java 5.0. In this case, I got the error stack trace in stdout. This used to come out in localhost_log. That's fine, at least I got it. However, there is an error produced by my application on startup that is *not* being dumped anywhere, and I do not believe either that any amount of log4j/commons configuration would get it because log4j/commons logging is only useful where the developer chooses to notify the logging subsystem which is not runtime errors fromt the JRE. This is part of the stack trace in 5.0.28's localhost_log 2004-11-08 09:29:32 StandardContext[/iq]Exception sending context initialized event to listener instance of class com.qas.newmedia.intranet.iq.IQContextListener java.lang.NullPointerException at com.qas.newmedia.intranet.iq.logic.core.CoreLogic.getDepartmentsByCategory(CoreLogic.java:234) at com.qas.newmedia.intranet.iq.IQContextListener.contextInitialized(IQContextListener.java:86) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3805) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4321) Therefore a NullPointerException is being thrown in 5.5.4 but not being reported anywhere which is a little unhelpful for me :( So I am back to my original question really ... how on earth would I get this NPE logged by Tomcat 5.5.4. This should go to the logger category for the Context, logged as ERROR level, as it will be logged through the servlet context. Maybe there's a problem somewhere, but I find it hard to believe. You can look at the code in StandardContext.listenerStart, ApplicationContext.log and in ContainerBase.getLogger: this looks very straightforward. You can send me a test war if you think it doesn't work. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Hm, maybe you are right Remy. I just explicitly placed a throw NPE in my contextInitialized and this came out to stdout. I am puzzled why the other NPE I know to be thrown is not doing the same. Will continue to look at this. On a positive note, my catalina.log as defined by a log4j configuration in common/classes has just appeared hooray! Will play around a bit more and let you know how it goes ... -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: 12 November 2004 10:07 To: Tomcat Users List Subject: Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log On Fri, 12 Nov 2004 09:55:20 -, Allistair Crossley [EMAIL PROTECTED] wrote: Hi, I have some new information on this for my case. I created a small JSP that had a scriplet error and ran it. I am definately using 5.5.4 with Java 5.0. In this case, I got the error stack trace in stdout. This used to come out in localhost_log. That's fine, at least I got it. However, there is an error produced by my application on startup that is *not* being dumped anywhere, and I do not believe either that any amount of log4j/commons configuration would get it because log4j/commons logging is only useful where the developer chooses to notify the logging subsystem which is not runtime errors fromt the JRE. This is part of the stack trace in 5.0.28's localhost_log 2004-11-08 09:29:32 StandardContext[/iq]Exception sending context initialized event to listener instance of class com.qas.newmedia.intranet.iq.IQContextListener java.lang.NullPointerException at com.qas.newmedia.intranet.iq.logic.core.CoreLogic.getDepartmen tsByCategory(CoreLogic.java:234) at com.qas.newmedia.intranet.iq.IQContextListener.contextInitiali zed(IQContextListener.java:86) at org.apache.catalina.core.StandardContext.listenerStart(Standar dContext.java:3805) at org.apache.catalina.core.StandardContext.start(StandardContext .java:4321) Therefore a NullPointerException is being thrown in 5.5.4 but not being reported anywhere which is a little unhelpful for me :( So I am back to my original question really ... how on earth would I get this NPE logged by Tomcat 5.5.4. This should go to the logger category for the Context, logged as ERROR level, as it will be logged through the servlet context. Maybe there's a problem somewhere, but I find it hard to believe. You can look at the code in StandardContext.listenerStart, ApplicationContext.log and in ContainerBase.getLogger: this looks very straightforward. You can send me a test war if you think it doesn't work. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Actually, I guess the default isn't that bad for UNIX/Linux anyway. In theory, if you are using J2SE 1.5 with the default log settings and you don't have Log4J installed, INFO level messages and above will get written to the console which gets redirected to catalina.out by catalina.sh. So, instead of having catalina.out, plus the other log, everything instead just goes into catalina.out. This is fine for my purposes, I just wanted to make sure that I wouldn't be missing important exceptions. As far as I know, if an unhandled exception occurs, it will get logged to catalina.out. If that's the case, then I'm happy. The only thing that I need to figure out now, is what is supposed to be better about Log4J over standard JDK logging and whether I actually need whatever that is. I'm guessing maybe log rotation or something? The other thing that I noticed is that a JDK logging.properties file seems to only allow you to specify a single FileHandler. I thought that it would let you assign different files to different loggers, but, as far as I can tell, this isn't possible (using the properties file anyway). Maybe this is one of the limitations? Jon - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, November 11, 2004 2:02 PM Subject: Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log On Thu, 11 Nov 2004 15:25:48 -, Allistair Crossley [EMAIL PROTECTED] wrote: Now, I know Logger has been removed from 5.5 series and that we are supposed to be using some kind of log4j / commons-logging stylee way but am fairly surprised that 5.5.4 did not come with a basic setup for this. I tried to find a reasonable default, but there's none IMO as the logger implementations that Sun provides with JREs 1.4 and 1.5 are quite limited. The only solution would be to write a logger for java logging, but I'm not a big fan of that. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - 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: Tomcat 5.5.4, Logging and the death of my friend localhost_log
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. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Hi, I have tried what I believed to be how to do this, e.g I placed a basic console appender log4j.properties file into tomcat/common/classes and popped log4j1.2.8 into the common/lib. No logging though. Where did you attach the console appender? To the root logger or on of your own packaged? Try creating an appender (probably a FileAppender) and associated it with the org.apache logger. If you want DEBUG-level logging, set its level DEBUG. Enjoy Halo 2 ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Hey Yoav, tomcat/common/classes/log4j.properties as follows log4j.rootLogger=DEBUG, A1 log4j.appender.A1=org.apache.log4j.ConsoleAppender log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n log4j.logger.org.apache.catalina=DEBUG This was pretty much just copied from the link on the Tomcat Logging FAQ except I changed the log level and also log4j.logger.org.apache to log4j.logger.org.apache.catalina I will try to add a file based appender... Allistair. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 11 November 2004 15:31 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hi, I have tried what I believed to be how to do this, e.g I placed a basic console appender log4j.properties file into tomcat/common/classes and popped log4j1.2.8 into the common/lib. No logging though. Where did you attach the console appender? To the root logger or on of your own packaged? Try creating an appender (probably a FileAppender) and associated it with the org.apache logger. If you want DEBUG-level logging, set its level DEBUG. Enjoy Halo 2 ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Hi again, I have tried to setup a file appender now without success. When I restart Tomcat it is clear that it does not wish to create the file I am specifying. I am wondering if Tomcat really is initialising the logging subsystem from placing log4j.properties in common/classes. I could be completely wrong and have missed something? log4j.rootLogger=debug, stdout, R log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=d:/jakarta-tomcat-5.5.4/logs/catalina.log log4j.appender.R.MaxFileSize=100KB log4j.appender.R.MaxBackupIndex=1 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n log4j.logger.org.apache.catalina=DEBUG, R Cheers! A. -Original Message- From: Allistair Crossley Sent: 11 November 2004 15:35 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hey Yoav, tomcat/common/classes/log4j.properties as follows log4j.rootLogger=DEBUG, A1 log4j.appender.A1=org.apache.log4j.ConsoleAppender log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n log4j.logger.org.apache.catalina=DEBUG This was pretty much just copied from the link on the Tomcat Logging FAQ except I changed the log level and also log4j.logger.org.apache to log4j.logger.org.apache.catalina I will try to add a file based appender... Allistair. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 11 November 2004 15:31 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hi, I have tried what I believed to be how to do this, e.g I placed a basic console appender log4j.properties file into tomcat/common/classes and popped log4j1.2.8 into the common/lib. No logging though. Where did you attach the console appender? To the root logger or on of your own packaged? Try creating an appender (probably a FileAppender) and associated it with the org.apache logger. If you want DEBUG-level logging, set its level DEBUG. Enjoy Halo 2 ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - 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: Tomcat 5.5.4, Logging and the death of my friend localhost_log
So, exceptions aren't logged by default? Does the new log4j method give you full stack traces, or, is it just one line error messages? If I don't configure log4j, does that mean that exceptions can be occurring and I won't know about it? IMHO, a decent default logging configuration should be provided by default. Not all of us are already experts in log4j... Jon - Original Message - From: Allistair Crossley [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, November 11, 2004 9:41 AM Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hi again, I have tried to setup a file appender now without success. When I restart Tomcat it is clear that it does not wish to create the file I am specifying. I am wondering if Tomcat really is initialising the logging subsystem from placing log4j.properties in common/classes. I could be completely wrong and have missed something? log4j.rootLogger=debug, stdout, R log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=d:/jakarta-tomcat-5.5.4/logs/catalina.log log4j.appender.R.MaxFileSize=100KB log4j.appender.R.MaxBackupIndex=1 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n log4j.logger.org.apache.catalina=DEBUG, R Cheers! A. -Original Message- From: Allistair Crossley Sent: 11 November 2004 15:35 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hey Yoav, tomcat/common/classes/log4j.properties as follows log4j.rootLogger=DEBUG, A1 log4j.appender.A1=org.apache.log4j.ConsoleAppender log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n log4j.logger.org.apache.catalina=DEBUG This was pretty much just copied from the link on the Tomcat Logging FAQ except I changed the log level and also log4j.logger.org.apache to log4j.logger.org.apache.catalina I will try to add a file based appender... Allistair. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 11 November 2004 15:31 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hi, I have tried what I believed to be how to do this, e.g I placed a basic console appender log4j.properties file into tomcat/common/classes and popped log4j1.2.8 into the common/lib. No logging though. Where did you attach the console appender? To the root logger or on of your own packaged? Try creating an appender (probably a FileAppender) and associated it with the org.apache logger. If you want DEBUG-level logging, set its level DEBUG. Enjoy Halo 2 ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - 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: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Hey, have you place also the common-logging.jar 1.0.4 with the log4j Factory at common/lib ? regards Peter Allistair Crossley schrieb: Hi again, I have tried to setup a file appender now without success. When I restart Tomcat it is clear that it does not wish to create the file I am specifying. I am wondering if Tomcat really is initialising the logging subsystem from placing log4j.properties in common/classes. I could be completely wrong and have missed something? log4j.rootLogger=debug, stdout, R log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=d:/jakarta-tomcat-5.5.4/logs/catalina.log log4j.appender.R.MaxFileSize=100KB log4j.appender.R.MaxBackupIndex=1 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n log4j.logger.org.apache.catalina=DEBUG, R Cheers! A. -Original Message- From: Allistair Crossley Sent: 11 November 2004 15:35 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hey Yoav, tomcat/common/classes/log4j.properties as follows log4j.rootLogger=DEBUG, A1 log4j.appender.A1=org.apache.log4j.ConsoleAppender log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n log4j.logger.org.apache.catalina=DEBUG This was pretty much just copied from the link on the Tomcat Logging FAQ except I changed the log level and also log4j.logger.org.apache to log4j.logger.org.apache.catalina I will try to add a file based appender... Allistair. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 11 November 2004 15:31 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hi, I have tried what I believed to be how to do this, e.g I placed a basic console appender log4j.properties file into tomcat/common/classes and popped log4j1.2.8 into the common/lib. No logging though. Where did you attach the console appender? To the root logger or on of your own packaged? Try creating an appender (probably a FileAppender) and associated it with the org.apache logger. If you want DEBUG-level logging, set its level DEBUG. Enjoy Halo 2 ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - 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: Tomcat 5.5.4, Logging and the death of my friend localhost_log
this is very true actually, i.e the old JSP stack trace errors and so on will not be directed into log4j-type logs .. that's not good at all i agree. And I know there is an exception occurring right now, but it's not being reported into the stdout. where is all the runtime exception stack tracing supposed to go Yoav? that won't be picked up by log4j which is a good point cheers! -Original Message- From: Jonathan Eric Miller [mailto:[EMAIL PROTECTED] Sent: Thu 11/11/2004 16:50 To: Tomcat Users List Cc: Subject: Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log So, exceptions aren't logged by default? Does the new log4j method give you full stack traces, or, is it just one line error messages? If I don't configure log4j, does that mean that exceptions can be occurring and I won't know about it? IMHO, a decent default logging configuration should be provided by default. Not all of us are already experts in log4j... Jon - Original Message - From: Allistair Crossley [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, November 11, 2004 9:41 AM Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hi again, I have tried to setup a file appender now without success. When I restart Tomcat it is clear that it does not wish to create the file I am specifying. I am wondering if Tomcat really is initialising the logging subsystem from placing log4j.properties in common/classes. I could be completely wrong and have missed something? log4j.rootLogger=debug, stdout, R log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=d:/jakarta-tomcat-5.5.4/logs/catalina.log log4j.appender.R.MaxFileSize=100KB log4j.appender.R.MaxBackupIndex=1 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n log4j.logger.org.apache.catalina=DEBUG, R Cheers! A. -Original Message- From: Allistair Crossley Sent: 11 November 2004 15:35 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hey Yoav, tomcat/common/classes/log4j.properties as follows log4j.rootLogger=DEBUG, A1 log4j.appender.A1=org.apache.log4j.ConsoleAppender log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n log4j.logger.org.apache.catalina=DEBUG This was pretty much just copied from the link on the Tomcat Logging FAQ except I changed the log level and also log4j.logger.org.apache to log4j.logger.org.apache.catalina I will try to add a file based appender... Allistair. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 11 November 2004 15:31 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hi, I have tried what I believed to be how to do this, e.g I placed a basic console appender log4j.properties file into tomcat/common/classes and popped log4j1.2.8 into the common/lib. No logging though. Where did you attach the console appender? To the root logger or on of your own packaged? Try creating an appender (probably a FileAppender) and associated it with the org.apache logger. If you want DEBUG-level logging, set its level DEBUG. Enjoy Halo 2 ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you
Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
On Thu, 11 Nov 2004 15:25:48 -, Allistair Crossley [EMAIL PROTECTED] wrote: Now, I know Logger has been removed from 5.5 series and that we are supposed to be using some kind of log4j / commons-logging stylee way but am fairly surprised that 5.5.4 did not come with a basic setup for this. I tried to find a reasonable default, but there's none IMO as the logger implementations that Sun provides with JREs 1.4 and 1.5 are quite limited. The only solution would be to write a logger for java logging, but I'm not a big fan of that. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
My current theory is that if you don't have Log4J installed (commons-logging prefers Log4J over standard Java 1.4 logging) and you're using J2SE 1.5, the errors should go to the console and/or catalina.out by default because the default $JAVA_HOME/jre/lib/logging.properties file that comes with J2SE 1.5 logs INFO messages and above to the console. As far as I know that is the same thing as System.out and System.out is redirected to catalina.out on UNIX/Linux as far as I know. On Windows, it just goes to the console. So if my theory is correct, it should work OK right out of the box, but, I'm just starting to test Tomcat 5.5 now and I don't have a lot of experience with configuring logging in general, so, I could be wrong. BTW, does anyone know if there are any advantages to using Log4J over Java 1.4 logging? Currently, I'm thinking of just using standard logging since it's there by default and doesn't require me to install another package, plus that fact that it's more standard since it's part of Java proper. Jon - Original Message - From: Allistair Crossley [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, November 11, 2004 1:54 PM Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log this is very true actually, i.e the old JSP stack trace errors and so on will not be directed into log4j-type logs .. that's not good at all i agree. And I know there is an exception occurring right now, but it's not being reported into the stdout. where is all the runtime exception stack tracing supposed to go Yoav? that won't be picked up by log4j which is a good point cheers! -Original Message- From: Jonathan Eric Miller [mailto:[EMAIL PROTECTED] Sent: Thu 11/11/2004 16:50 To: Tomcat Users List Cc: Subject: Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log So, exceptions aren't logged by default? Does the new log4j method give you full stack traces, or, is it just one line error messages? If I don't configure log4j, does that mean that exceptions can be occurring and I won't know about it? IMHO, a decent default logging configuration should be provided by default. Not all of us are already experts in log4j... Jon - Original Message - From: Allistair Crossley [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, November 11, 2004 9:41 AM Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hi again, I have tried to setup a file appender now without success. When I restart Tomcat it is clear that it does not wish to create the file I am specifying. I am wondering if Tomcat really is initialising the logging subsystem from placing log4j.properties in common/classes. I could be completely wrong and have missed something? log4j.rootLogger=debug, stdout, R log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=d:/jakarta-tomcat-5.5.4/logs/catalina.log log4j.appender.R.MaxFileSize=100KB log4j.appender.R.MaxBackupIndex=1 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n log4j.logger.org.apache.catalina=DEBUG, R Cheers! A. -Original Message- From: Allistair Crossley Sent: 11 November 2004 15:35 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hey Yoav, tomcat/common/classes/log4j.properties as follows log4j.rootLogger=DEBUG, A1 log4j.appender.A1=org.apache.log4j.ConsoleAppender log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n log4j.logger.org.apache.catalina=DEBUG This was pretty much just copied from the link on the Tomcat Logging FAQ except I changed the log level and also log4j.logger.org.apache to log4j.logger.org.apache.catalina I will try to add a file based appender... Allistair. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 11 November 2004 15:31 To: Tomcat Users List Subject: RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log Hi, I have tried what I believed to be how to do this, e.g I placed a basic console appender log4j.properties file into tomcat/common/classes and popped log4j1.2.8 into the common/lib. No logging though. Where did you attach the console appender? To the root logger or on of your own packaged? Try creating an appender (probably a FileAppender) and associated it with the org.apache logger. If you want DEBUG-level logging, set its level DEBUG. Enjoy Halo 2 ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information
RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Hi, BTW, does anyone know if there are any advantages to using Log4J over Java Numerous: http://logging.apache.org/log4j/docs/documentation.html has several articles. If you're looking for anything but the simplest logging features, log4j is far superior. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
On Thu, 11 Nov 2004 15:09:08 -0500, Shapira, Yoav [EMAIL PROTECTED] wrote: If you're looking for anything but the simplest logging features, log4j is far superior. I disagree with this statement, as it's too general. Personally, I consider what is definitely superior in log4j are the many logger implementations. As far as I can tell, these could (= should) be ported to the java.logging API. I see many people (including my company) moving away from the log4j API, and going to commons-logging in order to get unified logging. Ceki's continual refusal to engage in standardization process (whatever his motivations for this are) has been very unproductive and damaging for the Java platform as a whole, since the need of wrapper APIs (= useless complexity) has been made unavoidable. As a result, I'm extremely unhappy with log4j from a political point of view, and will unfortunately have to veto any proposal to ship it with Tomcat. Note 1: I have added a placeholder chapter in the documentation to have detailed instructions to use the various logging frameworks. Contributions welcome :) Note 2: the logging category used by each component is given in the configuration reference. For example, the context category is org.apache.catalina.core.ContainerBase.[enginename].[hostname].[path] As a result, you can easily specify a logger for a whole host. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.4, Logging and the death of my friend localhost_log
Hi, I disagree with this statement, as it's too general. Personally, I consider what is definitely superior in log4j are the many logger implementations. As far as I can tell, these could (= should) be ported to the java.logging API. Sun can port those any time it wants -- they have the source. Log4j has features that make a difference in real life that go far beyond the logger implementations, in the areas of receivers and listeners. I see many people (including my company) moving away from the log4j API, and going to commons-logging in order to get unified logging. Ceki's continual refusal to engage in standardization process Whoa there ;) I don't think the causality is right above. Log4j is not the reason commons-logging is around. Commons-Logging was created to address other logging frameworks, most of which including JDK 1.4 logging far post-date log4j. If anything, those frameworks have caused more fragmentation than log4j itself. Many of the relevant logging standards (given that there's no JSR) are derived (if not plain copied) from log4j. Furthermore, the log4j people have been working for improve standards and teamwork in this area, with Logging Services TLP and its other projects like log4net, log4cpp, etc. will unfortunately have to veto any proposal to ship it with Tomcat. I don't think any such proposal is forthcoming ;) I'm in an anti-bloat mood anyways, don't want to add anything else. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4, Logging and the death of my friend localhost_log
On Thu, 11 Nov 2004 15:34:09 -0500, Shapira, Yoav [EMAIL PROTECTED] wrote: Many of the relevant logging standards (given that there's no JSR) are derived (if not plain copied) from log4j. Furthermore, the log4j people have been working for improve standards and teamwork in this area, with Logging Services TLP and its other projects like log4net, log4cpp, etc. Nice, but this is irrelevant ;) There was a dominant logging framework (log4j). At some point, there was a need to do a logging standard. The Java standard is (unfortunately or not) governed mostly by the JCP. As a result, if log4j wanted to become the approved standard for the whole Java-land, and prevent the apparition of forked standards, it *had* to participate in that. Ceki chose not to and decided to put out Jon-like rants instead (I think the rant is quite justified, but you really have to be willing to make some compromises sometimes ...), and as a result, we have two dominant logging APIs now (log4j and java.logging). Without java.logging, we could probably ignore all APIs but log4j, so the need for commons-logging would be much smaller. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
