Did you make any progress with this? Did you try deploying the Log4j 2 jars
only to the Tomcat directory?
Ralph
On Jan 21, 2013, at 11:11 AM, Scott Severtson wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
