On 29/04/2010 10:43 AM, Ralph Goers wrote:
Sorry, I've never used the SiftingAppender. Just read the doc for it. Yes, they are similar and it is a better approach. Although the doc mentions using it for static loggers it occurs to me that it is probably also useful if all the web apps are configured to use the same config file even if all the jars are in the web app.
If all the jars are in the same web-app (shared jars), then you don't need ContextJNDISelector nor SiftingAppender for secondary separation. If you wish to share the same logback.xml file for all web-apps, I'd use a prperty to set the context name. For example, <configuration> <contextName>${CONTEXT_NAME}</contextName> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>${CONTEXT_NAME}.log</file> <encoder> <pattern>%d [%thread] %-5level %logger{35} - %msg%n</pattern> </encoder> </appender> </configuration> The question is then how do you set the CONTEXT_NAME property. You could do so before invoking joran configurator, typically in a ServletContextListener. Here is sample code: public class MyServletContextListener implements ServletContextListener { public void contextInitialized(ServletContextEvent sce) { LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); // undo default configuration lc.reset(); lc.putProperty("CONTEXT_NAME", the_name_of_this_context); configurator.doConfigure(args[0]); } } If you only want to rely on automatic configuration, then defining properties on the fly could be adequate [1]. Your config file becomes: <configuration> <define name="CONTEXT_NAME" class="class.implementing.PropertyDefiner.ReturningAContextName"> <contextName>${CONTEXT_NAME}</contextName> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>${CONTEXT_NAME}.log</file> <encoder> <pattern>%d [%thread] %-5level %logger{35} - %msg%n</pattern> </encoder> </appender> </configuration> The "class.implementing.PropertyDefiner.ReturningAContextName" would need to figure out the name of the enclosing web-app via an adhoc mechanism, e.g. via a resource look up containing the name of the web-app. -- Ceki