Hi and thank for your reply, I have same kind of initialization routine in place (at least I think). Code below is implemented in my shared library (ServletContextListener - if that matters) and both web apps are using the listener (path to the application specific configuration file is given with web context parameter). After configuration routine have finished, I can see from status messages, that web app B have initialized also rolling appender from web app A configuration. Can JBoss module's shared classloader somehow mess logging context used in logback implementation? I have started to suspect some of classloading issues, because I am also facing following scenario during the JBoss startup: 1. Application A tries to invoke LoggerFactory.getILoggerFactory --> doesn't get the correct LoggerContext because underlying logback is not initialized properly(?) 2. Almost at the same time Application B tries to invoke LoggerFactory.getILoggerFactory --> Correct LoggerContext is retrieved and initialization continues 3. In step 1 I check if correct context is not returned, I put the thread to sleep for 15 seconds. After thread becomes active again, I can get correct LoggerContext and can do the initialization Ville On 20.3.2013 20:39, Donald McLean wrote:
The standard way for Logback to work, configuration is from the logback.xml file.
I had a similar problem in that I wanted to be able to feed Logback a custom configuration that came from somewhere else. This is the code that I wrote to do the configuration:
val lc = LoggerFactory.getILoggerFactory.asInstanceOf[LoggerContext]
val configurator = new JoranConfigurator() configurator.setContext(lc) // the context was probably already configured by default configuration rules lc.reset()
val stream = configurationAsStream(data) configurator.doConfigure(stream)
The code is in Scala, but it translates pretty easily since it's pretty much all just function calls. The important part is the call to "configurationAsStream", where I create an input stream containing the logback configuration that I want the app to use.
Donald
On Wed, Mar 20, 2013 at 2:29 PM, Ville Hägg <villeah@gmail.com> wrote:
Hi all,
I need to clarify if I have understood logging separation correctly.
I have almost the same scenario than described e.g. in this question: http://mailman.qos.ch/pipermail/logback-user/2010-March/001442.html. In my environment I have most of the application logic deployed to JBoss 7 as a JBoss module. Module have my shared libraries for common parts of the application as well as third party libraries (like Logback and Spring). My own custom shared implementations are using logging in a standard way by instantiating loggers as a static class variables.
I am also having two war-applications which are using module described. Requirement is to have own logging context for each of the application. Which means applications should have their own log files, log levels and root loggers etc. I have tried to introduce JNDIBasedContextDiscriminator together with ShiftingAppender with no luck. My problem is that after my applications are initialized, it seems both of them is somehow sharing the same appenders. If I view status messages servlet, I can see that application B have initialized also RollingFileAppenders configured in application A's configuration file or other way round. RollingFileAppenders are wrapped inside SiftingAppender in both configuration files.
Can anyone clarify to me can two applications using shared libraries have strictly separated configuration files which are introducing own loggers, appenders and logging levels? Or do I still have some kind of configuration problem with my setup?
Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user