You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Scott Severtson <ss...@digitalmeasures.com> on 2013/01/10 17:56:25 UTC
Log4J2 and Tomcat: multiple external config files
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
Re: Log4J2 and Tomcat: multiple external config files
Posted by Ralph Goers <rg...@apache.org>.
Why do you deploy the Log4j2 jars to both the Tomcat directory and the application? That will mean that any Managers that should be shared across web apps won't be. I'm not sure why you would get varying results.
I'll be driving tomorrow to visit my in-laws for the long weekend so I'm not sure how responsive I will be.
Ralph
On Jan 17, 2013, at 1:02 PM, Scott Severtson <ss...@digitalmeasures.com> 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
Re: Log4J2 and Tomcat: multiple external config files
Posted by 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
Re: Log4J2 and Tomcat: multiple external config files
Posted by Scott Severtson <ss...@digitalmeasures.com>.
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
Re: Log4J2 and Tomcat: multiple external config files
Posted by Ralph Goers <ra...@dslextreme.com>.
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
Re: Log4J2 and Tomcat: multiple external config files
Posted by Scott Severtson <ss...@digitalmeasures.com>.
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
Re: Log4J2 and Tomcat: multiple external config files
Posted by Scott Severtson <ss...@digitalmeasures.com>.
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
Re: Log4J2 and Tomcat: multiple external config files
Posted by Scott Severtson <ss...@digitalmeasures.com>.
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
Re: Log4J2 and Tomcat: multiple external config files
Posted by Ralph Goers <ra...@dslextreme.com>.
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