Ralph,
So, based on your response, here's what we've come up with:
* Log4J2 .jars deployed to Tomcat's CATALINA_BASE/lib directory
* -Dlog4j.configurationFile=/path/to/tomcat-specific/log4j2.xml
* Log4J2 .jars *also* deployed in web applications
* web.xml context-param:
log4jConfiguration=${log4j.application.configurationFile}
* web.xml listener Log4jContextListener
*
-Dlog4j.application.configurationFile=/path/to/application-specific/log4j2.xml
This works, for the most part. The application-specific log events are
sent to the appropriate application-specific appenders, and Tomcat log
events are sent to the Tomcat-specific appenders.
However, we have one problem: Application-specific log events are *also*
appended to the Tomcat root logger.
Do I need to add entries to the tomcat-specific configuration to
*exclude* application specific events? I was under the impression that
the ClassLoaderContextSelector and using Log4jContextListener would
prevent events from being sent between the two contexts.
For what it's worth, our applications do not currently specify a
display-name in web.xml, which according to the docs, would result in
ServletContext.getServletContextName() returning null. Also, no
context-param is configured for log4jContextName. However, based on my
reading of the Log4J2 code, the context name is not actually used by
Configurator or ConfigurationFactory, so I assumed the null name would
not matter.
Many thanks for any hints in the right direction,
--Scott
On 01/10/2013 12:27 PM, Ralph Goers wrote:
LOG4J2-18 and LOG4J2-42 have been sitting for quite some time waiting for
someone like yourself to come along and help come up with good approaches.
I think most of the tools are there but I'm not sure what the best way(s)
is/are to finish it off.
First, hopefully you are aware that the default ContextSelector is the
ClassLoaderContextSelector. If you place your Log4j 2 jars in the tomcat class
loader then Tomcat's logging will use the Logging Context associated with
Tomcat's class loader. That would need to use log4j2.xml or the system property
- unless something can be added to Tomcat startup that causes it to use a
different configuration file via the Configurator. All the web applications
will have their own logging contexts that is associated with their class
loader. If you use the Log4jContextListener in the web project and can
configure each web apps web.xml then you can cause each web app to have their
own configuration or you can set them to all use the same one. I suppose we
could also modify the context listener to look for a system property to
automatically cause all the web apps to share a configuration.
With the BasicContextSelector everything uses a single LoggerContext so that
probably isn't what you want.
With the JNDIContextSelector each web app does a JNDI lookup to locate its
LoggerContext. Again, you would need to configure each web app with the
location of the configuration file.
I'm open to suggestions on how to better handle this.
Ralph
On Jan 10, 2013, at 8:56 AM, Scott Severtson wrote:
All,
We'd like to replace Tomcat's built-in logging with Log4J2, and are able to do
so based on Tomcat's docs for using Log4J 1.x, and deploying the
log4j-1.2-api-2.0-beta4.jar shim.
However, we're running into an issue with external configuration...
Our webapps are always deployed with external logging configuration files.
Historically, we've used -Dlog4j.configuration=/path/to/log4j.properties (now
-Dlog4j.configurationFile=/path/to/log4j2.xml) to point the app to the correct
file.
Unfortunately, if we pass the app-specific config file to the Tomcat JVM, the
Tomcat-level Log4J2 instance *also* tries to that config file.
Is there a reasonable way to support externalized configuration files both for
the Tomcat-level Log4J2 instance, *and* app-specific external configuration
files as well?
Many thanks,
--Scott
---------------------------------------------------------------------
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]
