4

My current need is to specify different log4j.configuration properties for different web applications deployed on the same Tomcat instance.

Is it possible in Tomcat to specify system properties on a per-application basis?

skuro
  • 13,414
  • 1
  • 48
  • 67
  • [this](http://stackoverflow.com/questions/372686/how-can-i-specify-system-properties-in-tomcat-configuration-on-startup) suggests there's probably no way to do that unless I e.g. let my applications be JNDI aware. Or unless Tomcat6 provides any new feature for my needs. – skuro Mar 08 '11 at 14:37

1 Answers1

1

You're asking two separate questions (well, at least as of Tomcat 7 you are asking two separate questions).

Log4j2 is web app aware, so it can be configured differently in each web app.

And while you can't have different system properties for each web app (because by its very nature, system means global), you can have different programmer accessible properties per web app, just not system properties.

With Tomcat 7 configured to conform to the Servlet 3.0 specification, you can create your own ServletContainerInitializer, configure that initializer to be initialized first, before all other initializers, and then, within that initializer you can read settings out of a file, DB or anything else and "park" them in the ServletContext's attributes collection. Typically, your initializer would inspect the system it's running on and set the attributes based on what it discovers. There's little point in reading them from a file, since you could simply park them in web.xml. Then code in your web app can pull the settings out of the web app's unique instance of its ServletContext's attribute collection. This allows each web app, or each instance of the same web app, to be uniquely configured.

mbmast
  • 960
  • 11
  • 25
  • Additionally, if you're up to your neck in Log4j, the Log4j2 project provides a transition helper jar, named log4j-1.2-api-2.0-beta9.jar, that can wrap the Log4j2 calls around legacy Log4j calls, eliminating the need for you to change existing code to make the jump to Log4j2 (except for those log4j2 specific features you may decide to use). This is also handy if existing code, in jar files you don't control, makes Log4j calls. – mbmast Jan 12 '15 at 16:30