Re: Log4J2 and Tomcat: multiple external config files

[Scott Severtson <ss...@digitalmeasures.com>]

I've finally created the test web application for this problem, and 
attached a complete Tomcat environment to 
https://issues.apache.org/jira/browse/LOG4J2-161.

Should be pretty simple to demonstrate the problem, and includes notes 
from our research. Any help would be greatly appreciated.

Thanks,
--Scott


On 01/28/2013 01:09 PM, Scott Severtson wrote:
> I'm still planning to create a test web application to investigate the 
> matter further. We have it working reliably with some web 
> applications, but our primary app is still having problems. 
> Unfortunately, I have other demands on my time, and may not get to 
> this until midway through this week.
>
> --Scott
>
> On 01/28/2013 12:25 PM, Ralph Goers wrote:
>> 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-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>
>>>>>> --------------------------------------------------------------------- 
>>>>>>
>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org