logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Separate appender for each application in same Tomcat
Date Thu, 14 Apr 2016 21:02:56 GMT
That functionality is from log4j-web.

On 14 April 2016 at 15:50, Niranjan Rao <nhrdls@gmail.com> wrote:

> If you are using spring by any chance, I think this can be resolved using
> following in web.xml
>
> <context-param>
>         <param-name>log4jConfiguration</param-name>
>         <param-value>${sys:LOG4J_PATH}</param-value>
>     </context-param>
>
> and LOG4J_PATH is defined using -DLOG4J_PATH=file:///<your path> in setenv
> file.
>
> I am not sure if this is spring functionality, or log4j functionality, but
> it does work for us. We have multiple application on same tomcat instance
> and each log goes to it's own file. We don't like to embed the log4j
> settings in the JAR or WAR files as it means another deployment if you want
> to change log settings to triage a problem.
>
> Regards,
>
> Niranjan
>
>
> On 04/13/2016 09:54 PM, Ralph Goers wrote:
>
>> Is the log4j configuration similar in the same environments?  If so you
>> could have your log4j.xml file be a “template” where all the items that are
>> variable are variables resolved by a lookup.  You could either use the
>> system properties lookup and make sure all the system properties are
>> defined, or you could create a custom lookup that reads a property file
>> named for the environment as you have described. You would then use that
>> lookup to resolve all the configurable items in log4j2.xml.
>>
>> Ralph
>>
>> On Apr 13, 2016, at 5:22 PM, Steven Yang <kenshin520@gmail.com> wrote:
>>>
>>> Hi
>>>
>>> currently the convention we adopt on property files are having separate
>>> file for each environment.
>>> for example, if there is a property file call "database" then there will
>>> be
>>> a database.dev.properties for local develop, database.uat.properties for
>>> UAT and a database.prod.properties for production.
>>> However log4j only supports a normal one and a test.
>>>
>>> Of course we can rename the file before deploying the application (no
>>> hassle, since we are using Gradle).
>>> However, we dont feel like its the best solution thats why we used the
>>> jvm
>>> argument when we were using separate tomcats.
>>>
>>> So just want to make sure there is no other better solution for this case
>>> before I go into using the xml file directly in the war file.
>>>
>>> Thanks
>>>
>>> On Wed, Apr 13, 2016 at 3:17 AM, Kamal Mettananda <lkamal@gmail.com>
>>> wrote:
>>>
>>> Hi Steven
>>>>
>>>> Have you looked at using separate and different log4j2.xml files inside
>>>> each app (.war files) rather than using command line configurations?
>>>>
>>>> Thanks
>>>> Kamal
>>>>
>>>> -----------------------
>>>> www.digizol.com
>>>>
>>>>
>>>> On Tue, Apr 12, 2016 at 4:10 PM Steven Yang <kenshin520@gmail.com>
>>>> wrote:
>>>>
>>>> Hi
>>>>>
>>>>> I am trying to deploy 2 applications in to one tomcat (originally in
2
>>>>> separate tomcat).
>>>>> And I use -Dlog4j.configurationFile to specify my log4j configuration.
>>>>> However, if I do that both applications will write to the same file.
>>>>> I want each application to write to there own files.
>>>>> Both applications have very similar packages and share many common
>>>>> libraries developed in-house, so using package name to separate logs
>>>>> will
>>>>> not be what we want.
>>>>>
>>>>> What is the best solution/practice to this kind of problem?
>>>>>
>>>>> (using log4j 2.5)
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>


-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message