I think i'm getting it, out of the office till wednesday so i'll give it another whirl then.
I think possibly part of the problem is that I was only putting log4j.jar in the WEB-INF/lib and not the commons-logging.jar which is only in common/lib. I'm using solaris so no daft windows service difficulties. Hopefully I can capture the standard out of an app when I get the webapp log4j configuration to work. Thanks for the help and I'm sure you'll read it here if I have any more difficulty. Ta Matt -----Original Message----- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Thursday, December 09, 2004 6:16 PM To: Tomcat Users List Subject: RE: Tomcat 5.5 Webapp logging. Quoting "Dale, Matt" <[EMAIL PROTECTED]>: > > This sounds like kind of what I want but you've confused me. > > I basically want the System.out and stdout from a particular webapp to go to > a specific log file that is rotated and seperate for each webapp. > I'm not sure how you would separate System.out from any individual app. If you run Tomcat-5.5.x as a service (at least on WinXP, which is what I use currently), it will automatically write to a stdout.log file *and* give you daily log rotation for free. > I've now got log4j working with a log4j.properties in common/classes. > Everything is now logged to a rotated log file which is hunky dorey from that > point of view. My second requirement is that the webapps be seperated into > different log files. This, i've had trouble with, i've placed a > log4j.properties in WEB-INF/classes but it seems to be ignored (log4j.jar is > in the WEB-INF/lib). > If you mean System.out output, then there isn't much you can do with the standard console appender. It will all go to one place. However, your normal log4j defined loggers should be working according to your properties file. log4j.properties in WEB-INF/classes with log4j.jar in WEB-INF/lib should create a separate logging environment from the server for each webapp you do this with. > I could seperate things out in the the main log4j.properties but at least one > of the apps is comprised mostly of jsps without a specific package so i'm > unsure how to do this. > You can still name your JSP's according to some psuedo-package naming scheme. Loggers aren't tied to your packages. This is just the standard way of naming loggers to make naming predictable and easy to confgure. Name them whatever you want. > But where you've really confused me is the mention of log4j.xml, this is the > first i've seen on it. Could you perhaps tell me where it goes and point me > to something that can help me decide what to put in it? > So, you didn't realize that Log4j could be configured using an XML config file? Well, it can. However, the DTD for Log4j prevents using Tomcat's host and context logger names for the reasons I stated (which, again, is not longer an isssue in Log4j-1.3 because the DTD is not used anymore). For instance, the following is illegal because the "name" attribute is defined by the DTD as of type ID and the "[" and "]" are illegal characters... <logger name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost]"> .... </logger> If you are unaware of this naming scheme, see the Tomcat-5.5.x docs. The alternative is to use a properties file and use... log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost] > In short I could do with a bit more detail if you wouldn't mind. Hopefully that cleared things up a little bit. Jake > > Ta > Matt > > -----Original Message----- > From: Jacob Kjome [mailto:[EMAIL PROTECTED] > Sent: 09 December 2004 16:55 > To: Tomcat Users List > Subject: Re: Tomcat 5.5 Webapp logging. > > > > So, you want System.out stuff to go to the stdout, is that right? Just set > up a > console appender. Note that if you want to log to Tomcat's specially named > localhost and context loggers, you'll need to use a log4j.properties file > rather than log4j.xml because the naming pattern violates the XML spec's > naming > scheme for attributes of type ID. This is only true for Log4j-1.2.x. In > Log4j > 1.3, we no longer use a DOMConfigurator, but the new JoranConfigurator which > doesn't use a DTD and, therefore, doesn't define <logger> "name" attributes > as > of type ID. > > You can define loggers and appenders in a way where Tomcat's info can go to a > separate log file than the stdout console or stdout log file. > > Jake > > Quoting "Dale, Matt" <[EMAIL PROTECTED]>: > > > Hi, > > > > We have a 3rd party application which has a nasty habit of chucking out a > > load of messages to stdout and stderr. > > > > Up until tomcat 5 we used a console Logger with swallowOutput turned on to > > catch all that output so it didnt end up in catalina.out. > > > > Obviously in 5.5 this is not possible and Log4J seems to be the way to go. > > I've tried this but not having much luck. I think it's just that I don't > > understand the log4j.properties file. > > > > Could someone perhaps post a sample that would do roughly what I need and I > > can tweak it from there. > > > > Ta > > Matt > > > > > > > --------------------------------------------------------------------- > 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]
Any opinions expressed in this E-mail may be those of the individual and not necessarily the company. This E-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this E-mail in error and that any use or copying is strictly prohibited. If you have received this E-mail in error please notify the beCogent postmaster at [EMAIL PROTECTED] Unless expressly stated, opinions in this email are those of the individual sender and not beCogent Ltd. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
