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 <kenshin...@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 <lka...@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 <kenshin...@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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
