FYI, I'm planning on setting up a simple test web application and Tomcat
configuration to investigate the problems we're currently seeing, but
may not get to it until later this week. Hopefully the issues we're
seeing are reproducible and easy to address.
--Scott
On 01/17/2013 03:02 PM, Scott Severtson wrote:
All,
Hmmm... More experimentation has shown that this configuration does
not have reliable results. Sometimes on startup, the
application-specific messages end up in the Tomcat logs, but not in
the application-specific logs. Other times, the messages are routed
correctly.
Any thoughts? Is there some sort of configuration race condition going
on?
--Scott
On 01/17/2013 09:33 AM, Scott Severtson wrote:
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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
