Can logging configuration files be separated when using ContextJNDISelector?
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? Thanks a lot, Ville
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?
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
Hi Ville, It has been 3 full years since I've looked at JNDIBasedContextDiscriminator [1]. Looking at it again it lools like JNDIBasedContextDiscriminator code supposes that ContextJNDISelector has been previously installed and that there is only a single configuraton file for all applications. Have you installed ContextJNDISelector? Note that SiftingAppender could propbably fulfill the requirements of your use case with only a single logback configuration file without installing ContextJNDISelector. However, for that to work JNDIBasedContextDiscriminator would need to be (renamed and) modified to retreive its discriminating value directly from JNDI, something which is not hard to do. HTH, [1] http://goo.gl/BW3NA On 20.03.2013 19:29, Ville Hägg 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?
Thanks a lot, Ville
-- Ceki 65% of statistics are made up on the spot
Hi Ceki, I believe I have successfully configured ContextJNDISelector because I can see logfiles created with correct context name. Right? Did you say that only one logback configuration file is currently allowed and it is supposed to be shared by all applications using same shared logging module? If so, it would explain my current challenges. However I need to separate configuration files for each applications somehow since there should be dozens of them deployed to the same JBoss instance and managing them with one single config file is not enough. Here is my configuration and custom implementation for initializing logback. Can you see something obviously wrong with it? I also uploaded screenshots of status servlet outputs to my Picasa account: https://plus.google.com/photos/100215973516408184433/albums/5857700003962453... In screenshots you can see what happens when I deploy webapp_B to the environment where webapp_A already exists. As you can see, for some reason there are logfile initializations from webapp_B configuration. Also these log files exists in logging directory: - webapp_A-daily-2013-03-21.0.log (pattern from webapp_A-logback.xml) - webapp_B-daily-2013-03-21.0.log (pattern from webapp_A-logback.xml) - webapp_B-d-2013-03-21.0.log (pattern from webapp_B-logback.xml) Configurations and init routines: web.xml (context name is changed depending of application): <env-entry> <env-entry-name>logback/context-name</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>webapp_B</env-entry-value> </env-entry> <listener> <listener-class>my.shared.logging.LogbackConfigListener</listener-class> </listener> LogbackConfigListener invokes LogbackConfigurator where I initialize logback: String configuration = getApplicationSpecificPropertyPath(applicationId); addLogManagerInfoStatus("Initializing Logback instance using configuration file: " + configuration); File resourceFile = new File(configuration); LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); lc.reset(); try { configurator.doConfigure(resourceFile.getAbsolutePath()); } catch (Exception e) { addLogManagerErrorStatus("Cannot configure LogBack with file: '" + configuration + "'. Log init failed!"); throw new IllegalArgumentException( "Cannot configure LogBack with file: '" + configuration + "'", e); } StatusPrinter.print(lc); addLogManagerInfoStatus("Logback instance initialized succesfully using configuration file: " + configuration); webapp_A-logback.xml: <configuration scan="true" scanPeriod="30 seconds" debug="true"> <appender name="SIFT-1" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator"> <defaultValue>unknown</defaultValue> </discriminator> <sift> <appender name="CommonFileAppender-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <append>true</append> <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder"> <layout class="my.shared.logging.layout.ServiceLayout" /> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${logpath}/${contextName}-daily-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>100MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> </appender> </sift> </appender> <!-- Define root logger to use Common logger --> <root level="DEBUG"> <appender-ref ref="SIFT-1" /> </root> </configuration> webapp_B-logback.xml is otherwise the same, but it has SiftingAppender named SIFT-2 AND filename pattern is a BIT DIFFERENT: ${logpath}/${contextName}-d-%d{yyyy-MM-dd}.%i.log.zip. Cheers, Ville On Wed, Mar 20, 2013 at 9:56 PM, ceki <ceki@qos.ch> wrote:
Hi Ville,
It has been 3 full years since I've looked at JNDIBasedContextDiscriminator [1]. Looking at it again it lools like JNDIBasedContextDiscriminator code supposes that ContextJNDISelector has been previously installed and that there is only a single configuraton file for all applications. Have you installed ContextJNDISelector?
Note that SiftingAppender could propbably fulfill the requirements of your use case with only a single logback configuration file without installing ContextJNDISelector. However, for that to work JNDIBasedContextDiscriminator would need to be (renamed and) modified to retreive its discriminating value directly from JNDI, something which is not hard to do.
HTH,
On 20.03.2013 19:29, Ville Hägg 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?
Thanks a lot, Ville
-- Ceki 65% of statistics are made up on the spot
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
participants (3)
-
ceki -
Donald McLean -
Ville Hägg