You know your environment better and know all the problems, but I think I am getting confused. Is it same application deployed with two different WAR files? I mean say app.war copied as prod.war and qa.war? How do applications know where to find other settings? Is it read from the resources or come via same external configuration.

I mean when you create the WAR file, something is telling application what to look at. Can same mechanism be used to modify the entry web.xml?

For local development, it's actually very easy - you just set -D flag in eclipse launch configuration. Other IDEs should be supporting something similar.

Good luck.

Regards,

Niranjan


On 04/15/2016 01:52 AM, Steven Yang wrote:
First of all thanks to all suggestions.

I dont think setting system property solves my issue because they are both
in the same tomcat which means they share the same system property.

setting the log4jConfiguration in web.xml means I will always have to set
it even if I am in local development right? unless I use different web.xml
for different environments?

I think I will go into the direction of Ralph's suggestion, however I am
probably going to use ${web:contextPath}.

Thanks all

On Fri, Apr 15, 2016 at 5:02 AM, Matt Sicker <[email protected]> wrote:

That functionality is from log4j-web.

On 14 April 2016 at 15:50, Niranjan Rao <[email protected]> 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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
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: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



--
Matt Sicker <[email protected]>



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to