Quoting Adrian Robert <[EMAIL PROTECTED]>:
>
> On Mar 2, 2005, at 12:25 AM, Jacob Kjome wrote:
>
> >
> > You first talk about ServletContext.log(), but then talk about log4j
> > loggers in your app. These are two completely separate things. Which
> > were you focusing on? With your setup, it it makes sense that
> > ServletContext.log() messages are going to catalina.log. However, if
> > you have log4j.jar in WEB-INF/lib and your application log4j logging
> > is going to catalina.log, then your setup is different than what you
> > describe here. There is quite simply no way that can happen given the
> > setup you've described. They should go to "bar.log" since that's the
> > only appender that your application's log4j configuration can see. In
> > any case, you don't need a separate log4j.jar in WEB-INF/lib for
> > ServletContext.log() messages to go to app-specific log files. Just
> > define those in your log4j.properties just like you have defined the
> > host logger. Here's my setup for Log4j-1.2.9 in
> > common/classes.log4j.properties (You can use log4j.xml when using
> > Log4j-1.3 because it uses a the new JoranConfigurator which doesn't
> > define a log4j.dtd. The current DOMConfigurator's dtd defines the
> > <logger> "name" attribute as an ID and the host and context logger
> > names that Tomcat uses characters not allowed in attributes of type
> > "id")....
>
> Thanks for your input.. I realize I wasn't clear about one thing. I
> don't want to define webapp-specific logging in the tomcat-global
> log4j.properties file. Instead, I want individual log4j.properties
> stored under webapp/*/WEB-INF/classes to cause logging to web-app
> specific files, without the container needing to be hard-coded for the
> webapps it is hosting.
Understandable. I was a little dismayed to see that what had been more
automatic in Tomcat-5.0.xx had become less so in Tomcat-5.5. What I mean is,
in Tomcat-5.0.xx, one could add a <Logger> to the context configuration file,
deploy that with the webapp, and dynamically get a log file for
ServletContext.log() output. In Tomcat-5.5, one has to have this in the logger
config file at Tomcat startup, therefore forcing one to predict the apps that
will be deployed to the appserver during runtime. Of course, Tomcat could
continue to use the <Logger> syntax, but only have it mean to programatically
use the currently configured logger implementation to add the logger to the
existing config rather than literally create a catalina logger which no longer
exists. This would continue to make Tomcat-5.5 more involved in logging than
it should, though. I think Yoav Shapira has it right when he says that Tomcat
should not really be directly involved in logging, but use the external
implementation. I'm not sure what the solution is. Probably needs more
discussion.
> I was trying to achieve this with multiple
> separate log4j.properties, one in the container (common/classes/) for
> the uncaught stack trace and other general logging, and others in each
> webapp. With my setup below I was expecting to get THREE files:
> catalina.out (with stdout/err), tomcat.log (with the container's log4j
> output), and bar.log (with the webapp's log4j output, which I changed
> from ServletContext.log() to use Logger.info()). Instead, I got only
> catalina.out and tomcat.log, the latter containing everything that I
> thought the webapp would be sending to bar.log.
>
And this should have worked. It works in every case I have ever tried. I
suggest you double and triple check that you have log4j.jar in both common/lib
and WEB-INF/lib and make sure you have log4j.properties in both common/classes
and WEB-INF/classes.
One thing that can trip people up is having a log4j.xml file somewhere in the
classpath, whether it is in a jar or in WEB-INF/classes. Log4j looks for
log4j.xml first and only looks for log4j.properties if it doesn't find it. If
a rogue log4j.xml file is sitting in the classpath somewhere your webapp might
be using it rather than the log4j.properties you think it is using. This is
one of the reasons I always use XML config files rather than property files. I
only use log4j.properties for Tomcat-5.5 because of incompatibilities with
Tomcat-5.5 context and host logger names and Log4j-1.2.x's dtd. Again,
Log4j-1.3 solves this be no longer having a DTD.
>
> > ...
> >
> > log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localho
> > st].[/myapp]=INFO, MYAPP
> > log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[loc
> > alhost].[/myapp]=false
>
> I don't understand this bracket notation. Is it documented anywhere?
> Is interpretation of it something implemented by tomcat or by log4j?
> Would it help me achieve what I'm trying to get without changing my
> webapp's code away from ServletContext.log()?
>
See Remy's message about this. It is detailed in the Tomcat docs.
>
> > BTW, you don't need commons-logging in your webapp. It is only Tomcat
> > that needs it, so just put it in common/lib, not WEB-INF/lib. You can
> > continue to put log4j.jar in both places if you desire. Otherwise,
> > you can also use a repository selector to separate webapp logging with
> > a single log4j.jar in common/lib. This makes more sense to start
> > doing with Log4j-1.3, though, using the ContextJNDISelector. You get
> > the same effect by having log4j.jar in WEB-INF/lib since the
> > classloader isolation will, effectively, create logging isolation per
> > webapp.
>
> Hmm.. I'm using log4j-1.2.9. I had the jar in both places but wasn't
> getting the isolation since my webapp was still pumping things into
> tomcat.log according to the container's log4j.properties.. However,
> I'm creating the logger in a static block in one of my webapp's classes
> -- could that have been the issue?
>
Do you have webapp libraries sitting in a shared classloader such as shared/lib
or common/lib? That would do it.
1. Make sure all your application classes are in WEB-INF/lib or WEB-INF/classes
2. Make sure log4j.jar is in WEB-INF/lib (remove commons-logging.jar if it is
there. If you don't specifically need it, it can, and will, cause problems for
you)
3. Make sure log4j.jar and commons-logging.jar (not
commons-logging-api.jar!!!!!!!!!!!) are in common/lib
4. Make sure you have log4j.properties in both common/classes and
WEB-INF/classes. You might even want to switch to using a log4j.xml config
file for your webapp just to be sure that you aren't picking another log4j.xml
file improperly distributed in a jar file.
If you do all the above, logging should work as you expect. Note that for
ServletContext.log() statements to go to context-specific files, you will still
have to define the loggers as detailed in the example log4j.properties that I
sent in my previous email.
Jake
>
>
>
>
> > At 06:18 PM 3/1/2005 -0500, you wrote:
> > >I'm having trouble approximating the earlier tomcat per-context
> > ><Logger> functionality using log4j under tomcat-5.5. Basically, I
> > >would like to have one file coming out under $CATALINA_BASE/logs/ per
> > >web application context. This appears to be no longer possible
> > through
> > >ServletContext.log(). So I tried using log4j:
> > >
> > >1) put log4j.jar, commons-logging.jar in common/lib AND
> > >webapps/*/WEB-INF/lib
> > >2) put log4j.properties in common/classes AND
> > webapps/*/WEB-INF/classes
> > >
> > >However, I can't seem to find the right combination of
> > log4j.properties
> > >lines, or maybe I'm trying something impossible. (I can't find good
> > >docs on the uses of log4j.properties when used inside the hierarchical
> > >classloading context that tomcat provides.) What keeps happening is
> > >that the webapp's log statements keep going into the global tomcat
> > log.
> > > Would I be better off with JDK logging instead?
> > >
> > >common/classes/log4j.properties
> > >-------------------
> > >log4j.rootLogger info, R
> > >log4j.appender.R org.apache.log4j.RollingFileAppender
> > >log4j.appender.R.File ${catalina.base}/logs/tomcat.log
> > >log4j.appender.R.MaxFileSize 10MB
> > >log4j.appender.R.MaxBackupIndex 10
> > >log4j.appender.R.layout org.apache.log4j.PatternLayout
> > >
> > >log4j.appender.R.layout.ConversionPattern %p %t %c - %m%n
> > >
> > >#log4j.logger.org.apache.catalina info, R
> > >#log4j.logger.org.apache.catalina.session info, R
> > >#log4j.logger.org.apache.catalina.session.ManagerBase info, R
> > >
> > >log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localh
> > os
> > >t]=info, R
> > >-------------------
> > >
> > >webapp/*/classes/log4j.properties
> > >-------------------
> > ># is this necessary? tried with and without...
> > >log4j.rootLogger info, A1
> > >
> > >log4j.category.com.foo , A1
> > >log4j.appender.A1
> > org.apache.log4j.DailyRollingFileAppender
> > >log4j.appender.A1.File ${catalina.base}/logs/bar.log
> > >log4j.appender.A1.MaxFileSize 10MB
> > >
> > >log4j.appender.A1.MaxBackupIndex 10
> > >log4j.appender.A1.layout org.apache.log4j.PatternLayout
> > >log4j.appender.A1.Append true
> > >
> > >log4j.appender.A1.layout.ConversionPattern %p %t %c - %m%n
> > >
> > >log4j.logger.com.foo info, A1
> > >-------------------
> > >
> > >Code in webapp:
> > >-------------------
> > >Logger logger = Logger.getLogger("com.foo");
> > >logger.info("bar");
> > >-------------------
> > >
> > >Any help appreciated..
> > >
>
>
> ---------------------------------------------------------------------
> 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]
