That isn’t really feasible currently. Once Log4j finds the configuration file it can poll the file’s timestamp to see if it was updated and reload it, but IMO it would not be a great idea to modify the log4j config file in the directory wherever Jetty deployed it, and it certainly would be ugly to try to update the war file. What we did at my former employer with Tomcat and JBoss was to create a directory under their config directory and then add that directory to the server’s class path. Then specify that in your web app configuration. If you do that you can update the file whenever you want.
If we were to make some sort of modification it would probably be to do something like have it first look at the location that was provided and if not found then use the default mechanism to locate a configuration instead of throwing an exception. However, that would still mean your updated configuration would be outside of the war. Another possibility is the enhancement request we have to support multiple configurations. With that the file in your war would be the default and then it could reference another configuration that could initially be empty but could be updated with new configuration. Unfortunately, no one has started work on that. Ralph On Apr 25, 2014, at 7:52 AM, Mikael Ståldal <[email protected]> wrote: > I am using Log4j 2.0 in a Web Application, which is packaged as a .war > file, and deployed in an application server. > > I want to bundle a default Log4j configuration within the .war file, but > make it possible to override it in the application server when deploying, > without tampering with the .war file. > > Is that possible with Log4j 2.0? I am currently using Jetty 9.x as > application server, but I would like a solution which can be used in > multiple application servers. > > -- > Mikael Ståldal > Chief Software Architect > *Appear* > Phone: +46 8 545 91 572 > Email: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
