Re: [logback-user] Separating the logging-output of libraries in tomcat/shared
Hello I have a little question when I use configuration bellow I take Exception Caused by: java.lang.UnsupportedOperationException: Key cannot be set. Using fixed key contextName at at *.logging.JNDIBasedContextDiscriminator.setKey(JNDIBasedContextDiscriminator.java:57) Maybe I need other configuration ? Ceki Gulcu wrote:
I think the short answer is yes. The nested appenders will have the same configuration differentiated by the value returned by the discriminator. You could add properties to the logger context and since logger context properties are seen as variables, you could in principle use the value of the property to filter events. Here is an example using a ThresholdFilter and the variable myLevel with a default substitution value (see [1]).
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator"> <Key>context</Key> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="FILE-${context}" class="ch.qos.logback.core.FileAppender"> <File>${context}.log</File> <Append>true</Append> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>${myLevel:-DEBUG}</level> </filter> <layout> <pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</pattern> </layout> </appender> </sift> </appender>
You could set the myLevel property at the start of each application. Here is the sample code for web-app A:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app A);
For web-app B, the code is similar:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app B);
You need to make sure that the "myLevel" property is set before the logger context is configured which means that you need to override default logback configuration by invoking joran directly. Search for "Invoking JoranConfigurator directly" in [2]. The code then becomes:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); // the context was probably already configured by default configuration // rules lc.reset(); lc.putProperty("myLevel", some level value as appropriate for the web-app); configurator.doConfigure(args[0]);
HTH,
[1] http://logback.qos.ch/manual/configuration.html#defaultValuesForVariables [2] http://logback.qos.ch/manual/configuration.html
On 02/03/2010 1:52 PM, Achim Wiedemann wrote:
Hi Ceki,
I just implemented your suggestion and it works like a charm. :) So it seems like there's a workaround for LBLCLASSIC-166 with your new discriminator-class now. Great work and thanks a lot!
By the way: Is there any possibility to have different logging-levels for the nested appenders of a SiftingAppender?
greetz, achim
Ceki Gülcü schrieb:
You are right. ContextBasedDiscriminator will not help you because the context name is retreived from the LoggingEvent which ultimately gets its value from the calling logger. If the calling logger is attached to the wrong context, ContextBasedDiscriminator will give you the wrong context name. Sorry for misleading you.
However, I've written a new discriminator which should work assuming you have installed ContextJNDISelector as explained in
http://logback.qos.ch/manual/loggingSeparation.html
JNDIBasedContextDiscriminator can be found at
http://github.com/ceki/logback/blob/90e50c/logback-classic/src/main/java/ch/...
or the same in tiny-speak
Getting values from JNDIBasedContextDiscriminator, SiftingAppender will get the correct context name and things should work much better. Give it a try.
On 01/03/2010 9:38 AM, Achim Wiedemann wrote:
Hey Ceki,
thanks for your fast reply. I tested your tip with the SiftingAppender, but couldn't see how this gets me further compared to the logging-separation described in Ch8 of the manual (separation via JNDIContextSelector). The problem is still the same: The context of the logger, once initialized, remains the same in shared libraries. Since SiftingAppender has to sieve based on some criteria (in my case the context), it also can't solve this issue.
So I see, as you already stated, it's not possible to get this scenario to work. However, thanks for your time and all your work.
greetz, achim
Ceki Gulcu schrieb:
Hello Achim,
Thank you for your message.
The only way to solve this issue transparently and perfectly would be to introduce another level of indirection inside loggers so that each logger-shell somehow delegate work to an inner logger attached to the appropriate context. This is quite a difficult problem technically and would generate significant computational overhead. I don't see the problem fixed via such indirection any time soon. Read, as a logback user, don't expect this problem to be solved without a little work on your side.
As far as I can see, you have two options:
1) move shared classes whose loggers you care about to the web-app (unshare them)
If 1) is not an option, there is:
2) Use a single shared logback.xml file with separation done by SiftingAppender [1] using the context as separation criteria [2]. In conjunction with prudent mode of FileAppender, you will be able to separate logging by context.
Let me know if the above does not make sense.
[1] http://logback.qos.ch/manual/appenders.html#SiftingAppender [2] http://logback.qos.ch/xref/ch/qos/logback/classic/sift/ContextBasedDiscrimin...
On 26.02.2010 08:21, Achim Wiedemann wrote:
Hey everybody,
just wanted to port our application from commons-logging / log4j to slf4j / logback. Unfortunately I stumbled upon some problems when separating the logging-output from different webapps (using the JNDIContextSelector). As long as you only use logging from classes inside the webapp, everything works fine. But as soon as you've got classes in tomcat/shared which use logging, you run into trouble: All logging output of the shared classes (e.g. Spring) are directed to the logger-context of the webapp which first loads the (shared) class.
Example: Let's say you've got webbapp [A], webbapp [B], and Spring in tomcat/shared. Now both webapps use Spring. If webapp [B] first accesses any classes of Spring, all output of Spring will be directed to the log-file of [B], no matter from which webapp Spring is used. This is because static Logger references are used in Spring (which is commonplace) and are initialized with the context of webapp [B].
The issue is already described very well in the logback JIRA: http://jira.qos.ch/browse/LBCLASSIC-166
I wondered if anyone can make a suggestion how to deal with this. Any advice, tricks or magic is welcome. ;)
Thanks a lot, Achim
Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://old.nabble.com/Separating-the-logging-output-of-libraries-in-tomcat-s... Sent from the Logback User mailing list archive at Nabble.com.
Just remove "<Key>context</Key>" On 05/03/2010 12:00 AM, toxel wrote:
Hello
I have a little question when I use configuration bellow I take Exception
Caused by: java.lang.UnsupportedOperationException: Key cannot be set. Using fixed key contextName at at *.logging.JNDIBasedContextDiscriminator.setKey(JNDIBasedContextDiscriminator.java:57)
Maybe I need other configuration ?
Ceki Gulcu wrote:
I think the short answer is yes. The nested appenders will have the same configuration differentiated by the value returned by the discriminator. You could add properties to the logger context and since logger context properties are seen as variables, you could in principle use the value of the property to filter events. Here is an example using a ThresholdFilter and the variable myLevel with a default substitution value (see [1]).
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator"> <Key>context</Key> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="FILE-${context}" class="ch.qos.logback.core.FileAppender"> <File>${context}.log</File> <Append>true</Append> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>${myLevel:-DEBUG}</level> </filter> <layout> <pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</pattern> </layout> </appender> </sift> </appender>
You could set the myLevel property at the start of each application. Here is the sample code for web-app A:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app A);
For web-app B, the code is similar:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app B);
You need to make sure that the "myLevel" property is set before the logger context is configured which means that you need to override default logback configuration by invoking joran directly. Search for "Invoking JoranConfigurator directly" in [2]. The code then becomes:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); // the context was probably already configured by default configuration // rules lc.reset(); lc.putProperty("myLevel", some level value as appropriate for the web-app); configurator.doConfigure(args[0]);
HTH,
[1] http://logback.qos.ch/manual/configuration.html#defaultValuesForVariables [2] http://logback.qos.ch/manual/configuration.html
On 02/03/2010 1:52 PM, Achim Wiedemann wrote:
Hi Ceki,
I just implemented your suggestion and it works like a charm. :) So it seems like there's a workaround for LBLCLASSIC-166 with your new discriminator-class now. Great work and thanks a lot!
By the way: Is there any possibility to have different logging-levels for the nested appenders of a SiftingAppender?
greetz, achim
Ceki Gülcü schrieb:
You are right. ContextBasedDiscriminator will not help you because the context name is retreived from the LoggingEvent which ultimately gets its value from the calling logger. If the calling logger is attached to the wrong context, ContextBasedDiscriminator will give you the wrong context name. Sorry for misleading you.
However, I've written a new discriminator which should work assuming you have installed ContextJNDISelector as explained in
http://logback.qos.ch/manual/loggingSeparation.html
JNDIBasedContextDiscriminator can be found at
http://github.com/ceki/logback/blob/90e50c/logback-classic/src/main/java/ch/...
or the same in tiny-speak
Getting values from JNDIBasedContextDiscriminator, SiftingAppender will get the correct context name and things should work much better. Give it a try.
On 01/03/2010 9:38 AM, Achim Wiedemann wrote:
Hey Ceki,
thanks for your fast reply. I tested your tip with the SiftingAppender, but couldn't see how this gets me further compared to the logging-separation described in Ch8 of the manual (separation via JNDIContextSelector). The problem is still the same: The context of the logger, once initialized, remains the same in shared libraries. Since SiftingAppender has to sieve based on some criteria (in my case the context), it also can't solve this issue.
So I see, as you already stated, it's not possible to get this scenario to work. However, thanks for your time and all your work.
greetz, achim
Ceki Gulcu schrieb:
Hello Achim,
Thank you for your message.
The only way to solve this issue transparently and perfectly would be to introduce another level of indirection inside loggers so that each logger-shell somehow delegate work to an inner logger attached to the appropriate context. This is quite a difficult problem technically and would generate significant computational overhead. I don't see the problem fixed via such indirection any time soon. Read, as a logback user, don't expect this problem to be solved without a little work on your side.
As far as I can see, you have two options:
1) move shared classes whose loggers you care about to the web-app (unshare them)
If 1) is not an option, there is:
2) Use a single shared logback.xml file with separation done by SiftingAppender [1] using the context as separation criteria [2]. In conjunction with prudent mode of FileAppender, you will be able to separate logging by context.
Let me know if the above does not make sense.
[1] http://logback.qos.ch/manual/appenders.html#SiftingAppender [2] http://logback.qos.ch/xref/ch/qos/logback/classic/sift/ContextBasedDiscrimin...
On 26.02.2010 08:21, Achim Wiedemann wrote: > Hey everybody, > > just wanted to port our application from commons-logging / log4j to > slf4j / logback. Unfortunately I stumbled upon some problems when > separating the logging-output from different webapps (using the > JNDIContextSelector). As long as you only use logging from classes > inside the webapp, everything works fine. But as soon as you've got > classes in tomcat/shared which use logging, you run into trouble: All > logging output of the shared classes (e.g. Spring) are directed to > the > logger-context of the webapp which first loads the (shared) class. > > Example: Let's say you've got webbapp [A], webbapp [B], and Spring in > tomcat/shared. Now both webapps use Spring. If webapp [B] first > accesses > any classes of Spring, all output of Spring will be directed to the > log-file of [B], no matter from which webapp Spring is used. This is > because static Logger references are used in Spring (which is > commonplace) and are initialized with the context of webapp [B]. > > The issue is already described very well in the logback JIRA: > http://jira.qos.ch/browse/LBCLASSIC-166 > > I wondered if anyone can make a suggestion how to deal with this. Any > advice, tricks or magic is welcome. ;) > > > Thanks a lot, > Achim
Change references from ${context} to ${contextName} as JNDIBasedContextDiscriminator is hardwired to use the key "contextName". On 05/03/2010 12:04 AM, Ceki Gülcü wrote:
Just remove "<Key>context</Key>"
On 05/03/2010 12:00 AM, toxel wrote:
Hello
I have a little question when I use configuration bellow I take Exception
Caused by: java.lang.UnsupportedOperationException: Key cannot be set. Using fixed key contextName at at *.logging.JNDIBasedContextDiscriminator.setKey(JNDIBasedContextDiscriminator.java:57)
Maybe I need other configuration ?
Ceki Gulcu wrote:
I think the short answer is yes. The nested appenders will have the same configuration differentiated by the value returned by the discriminator. You could add properties to the logger context and since logger context properties are seen as variables, you could in principle use the value of the property to filter events. Here is an example using a ThresholdFilter and the variable myLevel with a default substitution value (see [1]).
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator"> <Key>context</Key> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="FILE-${context}" class="ch.qos.logback.core.FileAppender"> <File>${context}.log</File> <Append>true</Append> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>${myLevel:-DEBUG}</level> </filter> <layout> <pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</pattern> </layout> </appender> </sift> </appender>
You could set the myLevel property at the start of each application. Here is the sample code for web-app A:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app A);
For web-app B, the code is similar:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app B);
You need to make sure that the "myLevel" property is set before the logger context is configured which means that you need to override default logback configuration by invoking joran directly. Search for "Invoking JoranConfigurator directly" in [2]. The code then becomes:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); // the context was probably already configured by default configuration // rules lc.reset(); lc.putProperty("myLevel", some level value as appropriate for the web-app); configurator.doConfigure(args[0]);
HTH,
[1] http://logback.qos.ch/manual/configuration.html#defaultValuesForVariables
[2] http://logback.qos.ch/manual/configuration.html
On 02/03/2010 1:52 PM, Achim Wiedemann wrote:
Hi Ceki,
I just implemented your suggestion and it works like a charm. :) So it seems like there's a workaround for LBLCLASSIC-166 with your new discriminator-class now. Great work and thanks a lot!
By the way: Is there any possibility to have different logging-levels for the nested appenders of a SiftingAppender?
greetz, achim
Ceki Gülcü schrieb:
You are right. ContextBasedDiscriminator will not help you because the context name is retreived from the LoggingEvent which ultimately gets its value from the calling logger. If the calling logger is attached to the wrong context, ContextBasedDiscriminator will give you the wrong context name. Sorry for misleading you.
However, I've written a new discriminator which should work assuming you have installed ContextJNDISelector as explained in
http://logback.qos.ch/manual/loggingSeparation.html
JNDIBasedContextDiscriminator can be found at
http://github.com/ceki/logback/blob/90e50c/logback-classic/src/main/java/ch/...
or the same in tiny-speak
Getting values from JNDIBasedContextDiscriminator, SiftingAppender will get the correct context name and things should work much better. Give it a try.
On 01/03/2010 9:38 AM, Achim Wiedemann wrote:
Hey Ceki,
thanks for your fast reply. I tested your tip with the SiftingAppender, but couldn't see how this gets me further compared to the logging-separation described in Ch8 of the manual (separation via JNDIContextSelector). The problem is still the same: The context of the logger, once initialized, remains the same in shared libraries. Since SiftingAppender has to sieve based on some criteria (in my case the context), it also can't solve this issue.
So I see, as you already stated, it's not possible to get this scenario to work. However, thanks for your time and all your work.
greetz, achim
Ceki Gulcu schrieb: > > Hello Achim, > > Thank you for your message. > > > The only way to solve this issue transparently and perfectly > would be > to introduce another level of indirection inside loggers so that > each > logger-shell somehow delegate work to an inner logger attached to > the > appropriate context. This is quite a difficult problem > technically and > would generate significant computational overhead. I don't see the > problem fixed via such indirection any time soon. Read, as a logback > user, don't expect this problem to be solved without a little > work on > your side. > > As far as I can see, you have two options: > > 1) move shared classes whose loggers you care about to the web-app > (unshare them) > > If 1) is not an option, there is: > > 2) Use a single shared logback.xml file with separation done by > SiftingAppender [1] using the context as separation criteria [2]. In > conjunction with prudent mode of FileAppender, you will be able to > separate logging by context. > > Let me know if the above does not make sense. > > > [1] http://logback.qos.ch/manual/appenders.html#SiftingAppender > [2] > http://logback.qos.ch/xref/ch/qos/logback/classic/sift/ContextBasedDiscrimin... > > > > > On 26.02.2010 08:21, Achim Wiedemann wrote: >> Hey everybody, >> >> just wanted to port our application from commons-logging / log4j to >> slf4j / logback. Unfortunately I stumbled upon some problems when >> separating the logging-output from different webapps (using the >> JNDIContextSelector). As long as you only use logging from classes >> inside the webapp, everything works fine. But as soon as you've got >> classes in tomcat/shared which use logging, you run into >> trouble: All >> logging output of the shared classes (e.g. Spring) are directed to >> the >> logger-context of the webapp which first loads the (shared) class. >> >> Example: Let's say you've got webbapp [A], webbapp [B], and >> Spring in >> tomcat/shared. Now both webapps use Spring. If webapp [B] first >> accesses >> any classes of Spring, all output of Spring will be directed to the >> log-file of [B], no matter from which webapp Spring is used. >> This is >> because static Logger references are used in Spring (which is >> commonplace) and are initialized with the context of webapp [B]. >> >> The issue is already described very well in the logback JIRA: >> http://jira.qos.ch/browse/LBCLASSIC-166 >> >> I wondered if anyone can make a suggestion how to deal with >> this. Any >> advice, tricks or magic is welcome. ;) >> >> >> Thanks a lot, >> Achim
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Finally we have 1. logback.xml in shared libs with sift appender and JNDIBasedContextDiscriminator 2. configured ContextJNDISelector 3. configured web.xml for each application <env-entry-name>logback/context-name</env-entry-name> and no another web-app/app1/web-inf/classes/logback-context-name.xml ? Ceki Gulcu wrote:
Change references from ${context} to ${contextName} as JNDIBasedContextDiscriminator is hardwired to use the key "contextName".
On 05/03/2010 12:04 AM, Ceki Gülcü wrote:
Just remove "<Key>context</Key>"
On 05/03/2010 12:00 AM, toxel wrote:
Hello
I have a little question when I use configuration bellow I take Exception
Caused by: java.lang.UnsupportedOperationException: Key cannot be set. Using fixed key contextName at at *.logging.JNDIBasedContextDiscriminator.setKey(JNDIBasedContextDiscriminator.java:57)
Maybe I need other configuration ?
Ceki Gulcu wrote:
I think the short answer is yes. The nested appenders will have the same configuration differentiated by the value returned by the discriminator. You could add properties to the logger context and since logger context properties are seen as variables, you could in principle use the value of the property to filter events. Here is an example using a ThresholdFilter and the variable myLevel with a default substitution value (see [1]).
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator"> <Key>context</Key> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="FILE-${context}" class="ch.qos.logback.core.FileAppender"> <File>${context}.log</File> <Append>true</Append> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>${myLevel:-DEBUG}</level> </filter> <layout> <pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</pattern> </layout> </appender> </sift> </appender>
You could set the myLevel property at the start of each application. Here is the sample code for web-app A:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app A);
For web-app B, the code is similar:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app B);
You need to make sure that the "myLevel" property is set before the logger context is configured which means that you need to override default logback configuration by invoking joran directly. Search for "Invoking JoranConfigurator directly" in [2]. The code then becomes:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); // the context was probably already configured by default configuration // rules lc.reset(); lc.putProperty("myLevel", some level value as appropriate for the web-app); configurator.doConfigure(args[0]);
HTH,
[1] http://logback.qos.ch/manual/configuration.html#defaultValuesForVariables
[2] http://logback.qos.ch/manual/configuration.html
On 02/03/2010 1:52 PM, Achim Wiedemann wrote:
Hi Ceki,
I just implemented your suggestion and it works like a charm. :) So it seems like there's a workaround for LBLCLASSIC-166 with your new discriminator-class now. Great work and thanks a lot!
By the way: Is there any possibility to have different logging-levels for the nested appenders of a SiftingAppender?
greetz, achim
Ceki Gülcü schrieb:
You are right. ContextBasedDiscriminator will not help you because the context name is retreived from the LoggingEvent which ultimately gets its value from the calling logger. If the calling logger is attached to the wrong context, ContextBasedDiscriminator will give you the wrong context name. Sorry for misleading you.
However, I've written a new discriminator which should work assuming you have installed ContextJNDISelector as explained in
http://logback.qos.ch/manual/loggingSeparation.html
JNDIBasedContextDiscriminator can be found at
http://github.com/ceki/logback/blob/90e50c/logback-classic/src/main/java/ch/...
or the same in tiny-speak
Getting values from JNDIBasedContextDiscriminator, SiftingAppender will get the correct context name and things should work much better. Give it a try.
On 01/03/2010 9:38 AM, Achim Wiedemann wrote: > Hey Ceki, > > thanks for your fast reply. I tested your tip with the > SiftingAppender, > but couldn't see how this gets me further compared to the > logging-separation described in Ch8 of the manual (separation via > JNDIContextSelector). The problem is still the same: The context > of the > logger, once initialized, remains the same in shared libraries. > Since > SiftingAppender has to sieve based on some criteria (in my case the > context), it also can't solve this issue. > > So I see, as you already stated, it's not possible to get this > scenario > to work. However, thanks for your time and all your work. > > > greetz, > achim > > > Ceki Gulcu schrieb: >> >> Hello Achim, >> >> Thank you for your message. >> >> >> The only way to solve this issue transparently and perfectly >> would be >> to introduce another level of indirection inside loggers so that >> each >> logger-shell somehow delegate work to an inner logger attached to >> the >> appropriate context. This is quite a difficult problem >> technically and >> would generate significant computational overhead. I don't see the >> problem fixed via such indirection any time soon. Read, as a >> logback >> user, don't expect this problem to be solved without a little >> work on >> your side. >> >> As far as I can see, you have two options: >> >> 1) move shared classes whose loggers you care about to the web-app >> (unshare them) >> >> If 1) is not an option, there is: >> >> 2) Use a single shared logback.xml file with separation done by >> SiftingAppender [1] using the context as separation criteria [2]. >> In >> conjunction with prudent mode of FileAppender, you will be able to >> separate logging by context. >> >> Let me know if the above does not make sense. >> >> >> [1] http://logback.qos.ch/manual/appenders.html#SiftingAppender >> [2] >> http://logback.qos.ch/xref/ch/qos/logback/classic/sift/ContextBasedDiscrimin... >> >> >> >> >> On 26.02.2010 08:21, Achim Wiedemann wrote: >>> Hey everybody, >>> >>> just wanted to port our application from commons-logging / log4j >>> to >>> slf4j / logback. Unfortunately I stumbled upon some problems when >>> separating the logging-output from different webapps (using the >>> JNDIContextSelector). As long as you only use logging from classes >>> inside the webapp, everything works fine. But as soon as you've >>> got >>> classes in tomcat/shared which use logging, you run into >>> trouble: All >>> logging output of the shared classes (e.g. Spring) are directed to >>> the >>> logger-context of the webapp which first loads the (shared) class. >>> >>> Example: Let's say you've got webbapp [A], webbapp [B], and >>> Spring in >>> tomcat/shared. Now both webapps use Spring. If webapp [B] first >>> accesses >>> any classes of Spring, all output of Spring will be directed to >>> the >>> log-file of [B], no matter from which webapp Spring is used. >>> This is >>> because static Logger references are used in Spring (which is >>> commonplace) and are initialized with the context of webapp [B]. >>> >>> The issue is already described very well in the logback JIRA: >>> http://jira.qos.ch/browse/LBCLASSIC-166 >>> >>> I wondered if anyone can make a suggestion how to deal with >>> this. Any >>> advice, tricks or magic is welcome. ;) >>> >>> >>> Thanks a lot, >>> Achim
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://old.nabble.com/Separating-the-logging-output-of-libraries-in-tomcat-s... Sent from the Logback User mailing list archive at Nabble.com.
What do you mean by "no another web-app/app1/web-inf/classes/logback-context-name.xml" ? The rest looks good. On 05/03/2010 12:44 AM, toxel wrote:
Finally we have
1. logback.xml in shared libs with sift appender and JNDIBasedContextDiscriminator 2. configured ContextJNDISelector 3. configured web.xml for each application <env-entry-name>logback/context-name</env-entry-name>
and no another web-app/app1/web-inf/classes/logback-context-name.xml ?
Ceki Gulcu wrote:
Change references from ${context} to ${contextName} as JNDIBasedContextDiscriminator is hardwired to use the key "contextName".
On 05/03/2010 12:04 AM, Ceki Gülcü wrote:
Just remove "<Key>context</Key>"
On 05/03/2010 12:00 AM, toxel wrote:
Hello
I have a little question when I use configuration bellow I take Exception
Caused by: java.lang.UnsupportedOperationException: Key cannot be set. Using fixed key contextName at at *.logging.JNDIBasedContextDiscriminator.setKey(JNDIBasedContextDiscriminator.java:57)
Maybe I need other configuration ?
Ceki Gulcu wrote:
I think the short answer is yes. The nested appenders will have the same configuration differentiated by the value returned by the discriminator. You could add properties to the logger context and since logger context properties are seen as variables, you could in principle use the value of the property to filter events. Here is an example using a ThresholdFilter and the variable myLevel with a default substitution value (see [1]).
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator"> <Key>context</Key> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="FILE-${context}" class="ch.qos.logback.core.FileAppender"> <File>${context}.log</File> <Append>true</Append> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>${myLevel:-DEBUG}</level> </filter> <layout> <pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</pattern> </layout> </appender> </sift> </appender>
You could set the myLevel property at the start of each application. Here is the sample code for web-app A:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app A);
For web-app B, the code is similar:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app B);
You need to make sure that the "myLevel" property is set before the logger context is configured which means that you need to override default logback configuration by invoking joran directly. Search for "Invoking JoranConfigurator directly" in [2]. The code then becomes:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); // the context was probably already configured by default configuration // rules lc.reset(); lc.putProperty("myLevel", some level value as appropriate for the web-app); configurator.doConfigure(args[0]);
HTH,
[1] http://logback.qos.ch/manual/configuration.html#defaultValuesForVariables
[2] http://logback.qos.ch/manual/configuration.html
On 02/03/2010 1:52 PM, Achim Wiedemann wrote:
Hi Ceki,
I just implemented your suggestion and it works like a charm. :) So it seems like there's a workaround for LBLCLASSIC-166 with your new discriminator-class now. Great work and thanks a lot!
By the way: Is there any possibility to have different logging-levels for the nested appenders of a SiftingAppender?
greetz, achim
Ceki Gülcü schrieb: > You are right. ContextBasedDiscriminator will not help you because > the > context name is retreived from the LoggingEvent which ultimately gets > its value from the calling logger. If the calling logger is attached > to the wrong context, ContextBasedDiscriminator will give you the > wrong context name. Sorry for misleading you. > > However, I've written a new discriminator which should work assuming > you have installed ContextJNDISelector as explained in > > http://logback.qos.ch/manual/loggingSeparation.html > > JNDIBasedContextDiscriminator can be found at > > > http://github.com/ceki/logback/blob/90e50c/logback-classic/src/main/java/ch/... > > > > or the same in tiny-speak > > http://tinyurl.com/yb6pdj2 > > Getting values from JNDIBasedContextDiscriminator, SiftingAppender > will get the correct context name and things should work much better. > Give it a try. > > > > On 01/03/2010 9:38 AM, Achim Wiedemann wrote: >> Hey Ceki, >> >> thanks for your fast reply. I tested your tip with the >> SiftingAppender, >> but couldn't see how this gets me further compared to the >> logging-separation described in Ch8 of the manual (separation via >> JNDIContextSelector). The problem is still the same: The context >> of the >> logger, once initialized, remains the same in shared libraries. >> Since >> SiftingAppender has to sieve based on some criteria (in my case the >> context), it also can't solve this issue. >> >> So I see, as you already stated, it's not possible to get this >> scenario >> to work. However, thanks for your time and all your work. >> >> >> greetz, >> achim >> >> >> Ceki Gulcu schrieb: >>> >>> Hello Achim, >>> >>> Thank you for your message. >>> >>> >>> The only way to solve this issue transparently and perfectly >>> would be >>> to introduce another level of indirection inside loggers so that >>> each >>> logger-shell somehow delegate work to an inner logger attached to >>> the >>> appropriate context. This is quite a difficult problem >>> technically and >>> would generate significant computational overhead. I don't see the >>> problem fixed via such indirection any time soon. Read, as a >>> logback >>> user, don't expect this problem to be solved without a little >>> work on >>> your side. >>> >>> As far as I can see, you have two options: >>> >>> 1) move shared classes whose loggers you care about to the web-app >>> (unshare them) >>> >>> If 1) is not an option, there is: >>> >>> 2) Use a single shared logback.xml file with separation done by >>> SiftingAppender [1] using the context as separation criteria [2]. >>> In >>> conjunction with prudent mode of FileAppender, you will be able to >>> separate logging by context. >>> >>> Let me know if the above does not make sense. >>> >>> >>> [1] http://logback.qos.ch/manual/appenders.html#SiftingAppender >>> [2] >>> http://logback.qos.ch/xref/ch/qos/logback/classic/sift/ContextBasedDiscrimin... >>> >>> >>> >>> >>> On 26.02.2010 08:21, Achim Wiedemann wrote: >>>> Hey everybody, >>>> >>>> just wanted to port our application from commons-logging / log4j >>>> to >>>> slf4j / logback. Unfortunately I stumbled upon some problems when >>>> separating the logging-output from different webapps (using the >>>> JNDIContextSelector). As long as you only use logging from classes >>>> inside the webapp, everything works fine. But as soon as you've >>>> got >>>> classes in tomcat/shared which use logging, you run into >>>> trouble: All >>>> logging output of the shared classes (e.g. Spring) are directed to >>>> the >>>> logger-context of the webapp which first loads the (shared) class. >>>> >>>> Example: Let's say you've got webbapp [A], webbapp [B], and >>>> Spring in >>>> tomcat/shared. Now both webapps use Spring. If webapp [B] first >>>> accesses >>>> any classes of Spring, all output of Spring will be directed to >>>> the >>>> log-file of [B], no matter from which webapp Spring is used. >>>> This is >>>> because static Logger references are used in Spring (which is >>>> commonplace) and are initialized with the context of webapp [B]. >>>> >>>> The issue is already described very well in the logback JIRA: >>>> http://jira.qos.ch/browse/LBCLASSIC-166 >>>> >>>> I wondered if anyone can make a suggestion how to deal with >>>> this. Any >>>> advice, tricks or magic is welcome. ;) >>>> >>>> >>>> Thanks a lot, >>>> Achim
I read in manual (http://logback.qos.ch/manual/loggingSeparation.html) that : " Assuming you have enabled ContextJNDISelector, logging for Kenobi will be done using a logger context named "kenobi". Moreover, the "kenobi" logger context will be initialized by convention using the configuration file called logback-kenobi.xml which should be packaged within Kenobi web-application under the WEB-INF/classes folder. " And 2nd question: can I use next configuration for SIFT appender - with two underlying appenders <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="logfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <Encoding>utf-8</Encoding> </appender> <appender name="errfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}-error.log </File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}-error.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender> Ceki Gulcu wrote:
What do you mean by "no another web-app/app1/web-inf/classes/logback-context-name.xml" ? The rest looks good.
On 05/03/2010 12:44 AM, toxel wrote:
Finally we have
1. logback.xml in shared libs with sift appender and JNDIBasedContextDiscriminator 2. configured ContextJNDISelector 3. configured web.xml for each application <env-entry-name>logback/context-name</env-entry-name>
and no another web-app/app1/web-inf/classes/logback-context-name.xml ?
Ceki Gulcu wrote:
Change references from ${context} to ${contextName} as JNDIBasedContextDiscriminator is hardwired to use the key "contextName".
On 05/03/2010 12:04 AM, Ceki Gülcü wrote:
Just remove "<Key>context</Key>"
On 05/03/2010 12:00 AM, toxel wrote:
Hello
I have a little question when I use configuration bellow I take Exception
Caused by: java.lang.UnsupportedOperationException: Key cannot be set. Using fixed key contextName at at *.logging.JNDIBasedContextDiscriminator.setKey(JNDIBasedContextDiscriminator.java:57)
Maybe I need other configuration ?
Ceki Gulcu wrote:
I think the short answer is yes. The nested appenders will have the same configuration differentiated by the value returned by the discriminator. You could add properties to the logger context and since logger context properties are seen as variables, you could in principle use the value of the property to filter events. Here is an example using a ThresholdFilter and the variable myLevel with a default substitution value (see [1]).
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator"> <Key>context</Key> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="FILE-${context}" class="ch.qos.logback.core.FileAppender"> <File>${context}.log</File> <Append>true</Append> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>${myLevel:-DEBUG}</level> </filter> <layout> <pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</pattern> </layout> </appender> </sift> </appender>
You could set the myLevel property at the start of each application. Here is the sample code for web-app A:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app A);
For web-app B, the code is similar:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.putProperty("myLevel", some level value as appropriate for web-app B);
You need to make sure that the "myLevel" property is set before the logger context is configured which means that you need to override default logback configuration by invoking joran directly. Search for "Invoking JoranConfigurator directly" in [2]. The code then becomes:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); // the context was probably already configured by default configuration // rules lc.reset(); lc.putProperty("myLevel", some level value as appropriate for the web-app); configurator.doConfigure(args[0]);
HTH,
[1] http://logback.qos.ch/manual/configuration.html#defaultValuesForVariables
[2] http://logback.qos.ch/manual/configuration.html
On 02/03/2010 1:52 PM, Achim Wiedemann wrote: > Hi Ceki, > > I just implemented your suggestion and it works like a charm. :) > So it seems like there's a workaround for LBLCLASSIC-166 with your > new > discriminator-class now. Great work and thanks a lot! > > By the way: Is there any possibility to have different > logging-levels > for the nested appenders of a SiftingAppender? > > > greetz, > achim > > > > > Ceki Gülcü schrieb: >> You are right. ContextBasedDiscriminator will not help you because >> the >> context name is retreived from the LoggingEvent which ultimately >> gets >> its value from the calling logger. If the calling logger is >> attached >> to the wrong context, ContextBasedDiscriminator will give you the >> wrong context name. Sorry for misleading you. >> >> However, I've written a new discriminator which should work >> assuming >> you have installed ContextJNDISelector as explained in >> >> http://logback.qos.ch/manual/loggingSeparation.html >> >> JNDIBasedContextDiscriminator can be found at >> >> >> http://github.com/ceki/logback/blob/90e50c/logback-classic/src/main/java/ch/... >> >> >> >> or the same in tiny-speak >> >> http://tinyurl.com/yb6pdj2 >> >> Getting values from JNDIBasedContextDiscriminator, SiftingAppender >> will get the correct context name and things should work much >> better. >> Give it a try. >> >> >> >> On 01/03/2010 9:38 AM, Achim Wiedemann wrote: >>> Hey Ceki, >>> >>> thanks for your fast reply. I tested your tip with the >>> SiftingAppender, >>> but couldn't see how this gets me further compared to the >>> logging-separation described in Ch8 of the manual (separation via >>> JNDIContextSelector). The problem is still the same: The context >>> of the >>> logger, once initialized, remains the same in shared libraries. >>> Since >>> SiftingAppender has to sieve based on some criteria (in my case >>> the >>> context), it also can't solve this issue. >>> >>> So I see, as you already stated, it's not possible to get this >>> scenario >>> to work. However, thanks for your time and all your work. >>> >>> >>> greetz, >>> achim >>> >>> >>> Ceki Gulcu schrieb: >>>> >>>> Hello Achim, >>>> >>>> Thank you for your message. >>>> >>>> >>>> The only way to solve this issue transparently and perfectly >>>> would be >>>> to introduce another level of indirection inside loggers so that >>>> each >>>> logger-shell somehow delegate work to an inner logger attached to >>>> the >>>> appropriate context. This is quite a difficult problem >>>> technically and >>>> would generate significant computational overhead. I don't see >>>> the >>>> problem fixed via such indirection any time soon. Read, as a >>>> logback >>>> user, don't expect this problem to be solved without a little >>>> work on >>>> your side. >>>> >>>> As far as I can see, you have two options: >>>> >>>> 1) move shared classes whose loggers you care about to the >>>> web-app >>>> (unshare them) >>>> >>>> If 1) is not an option, there is: >>>> >>>> 2) Use a single shared logback.xml file with separation done by >>>> SiftingAppender [1] using the context as separation criteria [2]. >>>> In >>>> conjunction with prudent mode of FileAppender, you will be able >>>> to >>>> separate logging by context. >>>> >>>> Let me know if the above does not make sense. >>>> >>>> >>>> [1] http://logback.qos.ch/manual/appenders.html#SiftingAppender >>>> [2] >>>> http://logback.qos.ch/xref/ch/qos/logback/classic/sift/ContextBasedDiscrimin... >>>> >>>> >>>> >>>> >>>> On 26.02.2010 08:21, Achim Wiedemann wrote: >>>>> Hey everybody, >>>>> >>>>> just wanted to port our application from commons-logging / log4j >>>>> to >>>>> slf4j / logback. Unfortunately I stumbled upon some problems >>>>> when >>>>> separating the logging-output from different webapps (using the >>>>> JNDIContextSelector). As long as you only use logging from >>>>> classes >>>>> inside the webapp, everything works fine. But as soon as you've >>>>> got >>>>> classes in tomcat/shared which use logging, you run into >>>>> trouble: All >>>>> logging output of the shared classes (e.g. Spring) are directed >>>>> to >>>>> the >>>>> logger-context of the webapp which first loads the (shared) >>>>> class. >>>>> >>>>> Example: Let's say you've got webbapp [A], webbapp [B], and >>>>> Spring in >>>>> tomcat/shared. Now both webapps use Spring. If webapp [B] first >>>>> accesses >>>>> any classes of Spring, all output of Spring will be directed to >>>>> the >>>>> log-file of [B], no matter from which webapp Spring is used. >>>>> This is >>>>> because static Logger references are used in Spring (which is >>>>> commonplace) and are initialized with the context of webapp [B]. >>>>> >>>>> The issue is already described very well in the logback JIRA: >>>>> http://jira.qos.ch/browse/LBCLASSIC-166 >>>>> >>>>> I wondered if anyone can make a suggestion how to deal with >>>>> this. Any >>>>> advice, tricks or magic is welcome. ;) >>>>> >>>>> >>>>> Thanks a lot, >>>>> Achim
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://old.nabble.com/Separating-the-logging-output-of-libraries-in-tomcat-s... Sent from the Logback User mailing list archive at Nabble.com.
1) You can only have *one *nested-appender within SiftingAppender. To manage *two* nested appender families, create *two* sifted appenders. 2) <FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip looks suspicious, it should probably be <File>${catalina.home}/logs/tbank/tbank-${contextName}.d{yyyy-MM-dd}.log.zip</File> 3) Since you are going to share the same configuration file between all contexts, you should override the JNDIContextSelector convention and explicitly define the "logback/configuration-resource" to point to the same file. Include the following in each web.xml. The path to the logback should be the same (shared). <env-entry> <env-entry-name>logback/configuration-resource</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>c:/my_shared_logback_config.xml</env-entry-value> </env-entry> Alternatively you could follow the convention and have different logback configuration files with identical contents (which is rather silly in this case). I hope this helps, On 05/03/2010 9:32 AM, toxel wrote:
I read in manual (http://logback.qos.ch/manual/loggingSeparation.html) that : " Assuming you have enabled ContextJNDISelector, logging for Kenobi will be done using a logger context named "kenobi". Moreover, the "kenobi" logger context will be initialized by convention using the configuration file called logback-kenobi.xml which should be packaged within Kenobi web-application under the WEB-INF/classes folder. "
And 2nd question: can I use next configuration for SIFT appender - with two underlying appenders
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="logfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <Encoding>utf-8</Encoding> </appender>
<appender name="errfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}-error.log </File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}-error.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy>
<layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender>
Thank you very match for you help. It's work. But I have many INFO messages in my catalina.out INFO: Deploying web application archive tbank-ps#tbank-mailru.war 11:36:54,837 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 11:36:54,837 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter 11:36:54,837 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.sift.SiftingAppender] 11:36:54,837 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [SIFT-LOG] ..... 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [httpclient.wire.content] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [httpclient.wire.content] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org.springframework.ws.client.MessageTracing.received] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [org.springframework.ws.client.MessageTracing.received] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [httpclient.wire.header] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [httpclient.wire.header] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to WARN 11:36:54,840 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT] 11:36:54,841 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-LOG] to Logger[ROOT] 11:36:54,841 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-ERR] to Logger[ROOT] How can I remove this messages and log only WARN level ? I must configure level for logback ? Ceki Gulcu wrote:
1) You can only have *one *nested-appender within SiftingAppender.
To manage *two* nested appender families, create *two* sifted appenders.
2) <FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip looks suspicious, it should probably be <File>${catalina.home}/logs/tbank/tbank-${contextName}.d{yyyy-MM-dd}.log.zip</File>
3) Since you are going to share the same configuration file between all contexts, you should override the JNDIContextSelector convention and explicitly define the "logback/configuration-resource" to point to the same file. Include the following in each web.xml. The path to the logback should be the same (shared).
<env-entry> <env-entry-name>logback/configuration-resource</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>c:/my_shared_logback_config.xml</env-entry-value> </env-entry>
Alternatively you could follow the convention and have different logback configuration files with identical contents (which is rather silly in this case).
I hope this helps,
On 05/03/2010 9:32 AM, toxel wrote:
I read in manual (http://logback.qos.ch/manual/loggingSeparation.html) that : " Assuming you have enabled ContextJNDISelector, logging for Kenobi will be done using a logger context named "kenobi". Moreover, the "kenobi" logger context will be initialized by convention using the configuration file called logback-kenobi.xml which should be packaged within Kenobi web-application under the WEB-INF/classes folder. "
And 2nd question: can I use next configuration for SIFT appender - with two underlying appenders
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="logfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <Encoding>utf-8</Encoding> </appender>
<appender name="errfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}-error.log </File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}-error.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy>
<layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender>
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://old.nabble.com/Separating-the-logging-output-of-libraries-in-tomcat-s... Sent from the Logback User mailing list archive at Nabble.com.
There is no way to filter logback's internal messages by level. In general, logback will output its internal state after it is configured and only in case of errors or if you set debug=true in the <configuration> element. Have you attached a status listener in your configuration file? For example, do you have the following in your config file? <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener"/> If you do, remove it. See also the docs: http://logback.qos.ch/manual/configuration.html On 05/03/2010 9:58 AM, toxel wrote:
Thank you very match for you help. It's work. But I have many INFO messages in my catalina.out
INFO: Deploying web application archive tbank-ps#tbank-mailru.war 11:36:54,837 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 11:36:54,837 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter 11:36:54,837 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.sift.SiftingAppender] 11:36:54,837 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [SIFT-LOG] ..... 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [httpclient.wire.content] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [httpclient.wire.content] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org.springframework.ws.client.MessageTracing.received] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [org.springframework.ws.client.MessageTracing.received] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [httpclient.wire.header] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [httpclient.wire.header] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to WARN 11:36:54,840 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT] 11:36:54,841 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-LOG] to Logger[ROOT] 11:36:54,841 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-ERR] to Logger[ROOT]
How can I remove this messages and log only WARN level ? I must configure level for logback ?
Ceki Gulcu wrote:
1) You can only have *one *nested-appender within SiftingAppender.
To manage *two* nested appender families, create *two* sifted appenders.
2)<FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip looks suspicious, it should probably be <File>${catalina.home}/logs/tbank/tbank-${contextName}.d{yyyy-MM-dd}.log.zip</File>
3) Since you are going to share the same configuration file between all contexts, you should override the JNDIContextSelector convention and explicitly define the "logback/configuration-resource" to point to the same file. Include the following in each web.xml. The path to the logback should be the same (shared).
<env-entry> <env-entry-name>logback/configuration-resource</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>c:/my_shared_logback_config.xml</env-entry-value> </env-entry>
Alternatively you could follow the convention and have different logback configuration files with identical contents (which is rather silly in this case).
I hope this helps,
On 05/03/2010 9:32 AM, toxel wrote:
I read in manual (http://logback.qos.ch/manual/loggingSeparation.html) that : " Assuming you have enabled ContextJNDISelector, logging for Kenobi will be done using a logger context named "kenobi". Moreover, the "kenobi" logger context will be initialized by convention using the configuration file called logback-kenobi.xml which should be packaged within Kenobi web-application under the WEB-INF/classes folder. "
And 2nd question: can I use next configuration for SIFT appender - with two underlying appenders
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="logfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <Encoding>utf-8</Encoding> </appender>
<appender name="errfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}-error.log </File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}-error.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy>
<layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender>
Strange situation - directory and files for log dont't created. (INFO messages disappeared after I resolving WARN problems) <?xml version="1.0" encoding="UTF-8"?> <configuration scan="true" scanPeriod="30 seconds" debug="false"> <appender name="SIFT-LOG" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="logfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}.d{yyyy-MM-dd}.log.zip</FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender> <appender name="SIFT-ERR" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="errfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}-error.log </File> <!rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}-error.d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> <logger name="ru" level="DEBUG" /> <logger name="org.springframework" level="INFO" /> <logger name="org.springframework.web.filter" level="DEBUG" /> <logger name="org.springframework.ws.server.endpoint.interceptor.PayloadLoggingInterceptor" level="DEBUG" /> <logger name="org.springframework.ws.client.MessageTracing.sent" level="TRACE" /> <logger name="org.apache.commons.httpclient" level="DEBUG" /> <logger name="org.springframework.ws.server.MessageTracing" level="DEBUG" /> <logger name="httpclient.wire.content" level="DEBUG" /> <logger name="org.springframework.ws.client.MessageTracing.received" level="DEBUG" /> <logger name="httpclient.wire.header" level="DEBUG" /> <root level="WARN"> <appender-ref ref="STDOUT" /> <appender-ref ref="SIFT-LOG" /> <appender-ref ref="SIFT-ERR" /> </root> </configuration> Ceki Gulcu wrote:
There is no way to filter logback's internal messages by level. In general, logback will output its internal state after it is configured and only in case of errors or if you set debug=true in the <configuration> element.
Have you attached a status listener in your configuration file? For example, do you have the following in your config file?
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener"/>
If you do, remove it.
See also the docs: http://logback.qos.ch/manual/configuration.html
On 05/03/2010 9:58 AM, toxel wrote:
Thank you very match for you help. It's work. But I have many INFO messages in my catalina.out
INFO: Deploying web application archive tbank-ps#tbank-mailru.war 11:36:54,837 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 11:36:54,837 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter 11:36:54,837 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.sift.SiftingAppender] 11:36:54,837 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [SIFT-LOG] ..... 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [httpclient.wire.content] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [httpclient.wire.content] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org.springframework.ws.client.MessageTracing.received] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [org.springframework.ws.client.MessageTracing.received] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [httpclient.wire.header] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [httpclient.wire.header] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to WARN 11:36:54,840 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT] 11:36:54,841 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-LOG] to Logger[ROOT] 11:36:54,841 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-ERR] to Logger[ROOT]
How can I remove this messages and log only WARN level ? I must configure level for logback ?
Ceki Gulcu wrote:
1) You can only have *one *nested-appender within SiftingAppender.
To manage *two* nested appender families, create *two* sifted appenders.
2)<FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip looks suspicious, it should probably be <File>${catalina.home}/logs/tbank/tbank-${contextName}.d{yyyy-MM-dd}.log.zip</File>
3) Since you are going to share the same configuration file between all contexts, you should override the JNDIContextSelector convention and explicitly define the "logback/configuration-resource" to point to the same file. Include the following in each web.xml. The path to the logback should be the same (shared).
<env-entry> <env-entry-name>logback/configuration-resource</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>c:/my_shared_logback_config.xml</env-entry-value> </env-entry>
Alternatively you could follow the convention and have different logback configuration files with identical contents (which is rather silly in this case).
I hope this helps,
On 05/03/2010 9:32 AM, toxel wrote:
I read in manual (http://logback.qos.ch/manual/loggingSeparation.html) that : " Assuming you have enabled ContextJNDISelector, logging for Kenobi will be done using a logger context named "kenobi". Moreover, the "kenobi" logger context will be initialized by convention using the configuration file called logback-kenobi.xml which should be packaged within Kenobi web-application under the WEB-INF/classes folder. "
And 2nd question: can I use next configuration for SIFT appender - with two underlying appenders
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="logfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <Encoding>utf-8</Encoding> </appender>
<appender name="errfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}-error.log </File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}-error.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy>
<layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender>
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://old.nabble.com/Separating-the-logging-output-of-libraries-in-tomcat-s... Sent from the Logback User mailing list archive at Nabble.com.
What do the internal status messages say? To see the messages occurring after the configuration phase, add <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener"/> to your config file. Once you are happy with the results, remove the listener. On 05/03/2010 10:43 AM, toxel wrote:
Strange situation - directory and files for log dont't created. (INFO messages disappeared after I resolving WARN problems)
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="30 seconds" debug="false"> <appender name="SIFT-LOG" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="logfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<FileNamePattern>tbank-${contextName}.d{yyyy-MM-dd}.log.zip</FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender>
<appender name="SIFT-ERR" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="errfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}-error.log </File> <!rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}-error.d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy>
<layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender>
<logger name="ru" level="DEBUG" /> <logger name="org.springframework" level="INFO" /> <logger name="org.springframework.web.filter" level="DEBUG" /> <logger
name="org.springframework.ws.server.endpoint.interceptor.PayloadLoggingInterceptor" level="DEBUG" /> <logger name="org.springframework.ws.client.MessageTracing.sent" level="TRACE" /> <logger name="org.apache.commons.httpclient" level="DEBUG" /> <logger name="org.springframework.ws.server.MessageTracing" level="DEBUG" /> <logger name="httpclient.wire.content" level="DEBUG" /> <logger name="org.springframework.ws.client.MessageTracing.received" level="DEBUG" /> <logger name="httpclient.wire.header" level="DEBUG" /> <root level="WARN"> <appender-ref ref="STDOUT" /> <appender-ref ref="SIFT-LOG" /> <appender-ref ref="SIFT-ERR" /> </root> </configuration>
Ceki Gulcu wrote:
There is no way to filter logback's internal messages by level. In general, logback will output its internal state after it is configured and only in case of errors or if you set debug=true in the<configuration> element.
Have you attached a status listener in your configuration file? For example, do you have the following in your config file?
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener"/>
If you do, remove it.
See also the docs: http://logback.qos.ch/manual/configuration.html
On 05/03/2010 9:58 AM, toxel wrote:
Thank you very match for you help. It's work. But I have many INFO messages in my catalina.out
INFO: Deploying web application archive tbank-ps#tbank-mailru.war 11:36:54,837 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 11:36:54,837 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter 11:36:54,837 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.sift.SiftingAppender] 11:36:54,837 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [SIFT-LOG] ..... 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [httpclient.wire.content] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [httpclient.wire.content] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org.springframework.ws.client.MessageTracing.received] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [org.springframework.ws.client.MessageTracing.received] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [httpclient.wire.header] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [httpclient.wire.header] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to WARN 11:36:54,840 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT] 11:36:54,841 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-LOG] to Logger[ROOT] 11:36:54,841 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-ERR] to Logger[ROOT]
How can I remove this messages and log only WARN level ? I must configure level for logback ?
Ceki Gulcu wrote:
1) You can only have *one *nested-appender within SiftingAppender.
To manage *two* nested appender families, create *two* sifted appenders.
2)<FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip looks suspicious, it should probably be <File>${catalina.home}/logs/tbank/tbank-${contextName}.d{yyyy-MM-dd}.log.zip</File>
3) Since you are going to share the same configuration file between all contexts, you should override the JNDIContextSelector convention and explicitly define the "logback/configuration-resource" to point to the same file. Include the following in each web.xml. The path to the logback should be the same (shared).
<env-entry> <env-entry-name>logback/configuration-resource</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>c:/my_shared_logback_config.xml</env-entry-value> </env-entry>
Alternatively you could follow the convention and have different logback configuration files with identical contents (which is rather silly in this case).
I hope this helps,
On 05/03/2010 9:32 AM, toxel wrote:
I read in manual (http://logback.qos.ch/manual/loggingSeparation.html) that : " Assuming you have enabled ContextJNDISelector, logging for Kenobi will be done using a logger context named "kenobi". Moreover, the "kenobi" logger context will be initialized by convention using the configuration file called logback-kenobi.xml which should be packaged within Kenobi web-application under the WEB-INF/classes folder. "
And 2nd question: can I use next configuration for SIFT appender - with two underlying appenders
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="logfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <Encoding>utf-8</Encoding> </appender>
<appender name="errfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}-error.log </File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}-error.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy>
<layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender>
Problem was in <File>${catalina.home}/logs/tbank/tbank-${contextName}.d{yyyy-MM-dd}.log.zip</File> if I use <FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip it's work toxel wrote:
Strange situation - directory and files for log dont't created. (INFO messages disappeared after I resolving WARN problems)
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="30 seconds" debug="false"> <appender name="SIFT-LOG" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="logfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<FileNamePattern>tbank-${contextName}.d{yyyy-MM-dd}.log.zip</FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender>
<appender name="SIFT-ERR" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="errfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}-error.log </File> <!rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}-error.d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy>
<layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender>
<logger name="ru" level="DEBUG" /> <logger name="org.springframework" level="INFO" /> <logger name="org.springframework.web.filter" level="DEBUG" /> <logger
name="org.springframework.ws.server.endpoint.interceptor.PayloadLoggingInterceptor" level="DEBUG" /> <logger name="org.springframework.ws.client.MessageTracing.sent" level="TRACE" /> <logger name="org.apache.commons.httpclient" level="DEBUG" /> <logger name="org.springframework.ws.server.MessageTracing" level="DEBUG" /> <logger name="httpclient.wire.content" level="DEBUG" /> <logger name="org.springframework.ws.client.MessageTracing.received" level="DEBUG" /> <logger name="httpclient.wire.header" level="DEBUG" /> <root level="WARN"> <appender-ref ref="STDOUT" /> <appender-ref ref="SIFT-LOG" /> <appender-ref ref="SIFT-ERR" /> </root> </configuration>
Ceki Gulcu wrote:
There is no way to filter logback's internal messages by level. In general, logback will output its internal state after it is configured and only in case of errors or if you set debug=true in the <configuration> element.
Have you attached a status listener in your configuration file? For example, do you have the following in your config file?
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener"/>
If you do, remove it.
See also the docs: http://logback.qos.ch/manual/configuration.html
On 05/03/2010 9:58 AM, toxel wrote:
Thank you very match for you help. It's work. But I have many INFO messages in my catalina.out
INFO: Deploying web application archive tbank-ps#tbank-mailru.war 11:36:54,837 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 11:36:54,837 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter 11:36:54,837 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.sift.SiftingAppender] 11:36:54,837 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [SIFT-LOG] ..... 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [httpclient.wire.content] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [httpclient.wire.content] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org.springframework.ws.client.MessageTracing.received] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [org.springframework.ws.client.MessageTracing.received] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [httpclient.wire.header] to DEBUG 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [httpclient.wire.header] to true 11:36:54,840 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to WARN 11:36:54,840 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT] 11:36:54,841 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-LOG] to Logger[ROOT] 11:36:54,841 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-ERR] to Logger[ROOT]
How can I remove this messages and log only WARN level ? I must configure level for logback ?
Ceki Gulcu wrote:
1) You can only have *one *nested-appender within SiftingAppender.
To manage *two* nested appender families, create *two* sifted appenders.
2)<FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip looks suspicious, it should probably be <File>${catalina.home}/logs/tbank/tbank-${contextName}.d{yyyy-MM-dd}.log.zip</File>
3) Since you are going to share the same configuration file between all contexts, you should override the JNDIContextSelector convention and explicitly define the "logback/configuration-resource" to point to the same file. Include the following in each web.xml. The path to the logback should be the same (shared).
<env-entry> <env-entry-name>logback/configuration-resource</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>c:/my_shared_logback_config.xml</env-entry-value> </env-entry>
Alternatively you could follow the convention and have different logback configuration files with identical contents (which is rather silly in this case).
I hope this helps,
On 05/03/2010 9:32 AM, toxel wrote:
I read in manual (http://logback.qos.ch/manual/loggingSeparation.html) that : " Assuming you have enabled ContextJNDISelector, logging for Kenobi will be done using a logger context named "kenobi". Moreover, the "kenobi" logger context will be initialized by convention using the configuration file called logback-kenobi.xml which should be packaged within Kenobi web-application under the WEB-INF/classes folder. "
And 2nd question: can I use next configuration for SIFT appender - with two underlying appenders
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="utils.common.logging.JNDIBasedContextDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="logfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>tbank-${contextName}.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <Encoding>utf-8</Encoding> </appender>
<appender name="errfile-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/tbank/tbank-${contextName}-error.log </File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<FileNamePattern>tbank-${contextName}-error.%d{yyyy-MM-dd}.log.zip </FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy>
<layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %-5level %logger{35} - %msg%n </Pattern> </layout> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> <Encoding>utf-8</Encoding> </appender> </sift> </appender>
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://old.nabble.com/Separating-the-logging-output-of-libraries-in-tomcat-s... Sent from the Logback User mailing list archive at Nabble.com.
participants (2)
-
Ceki Gülcü -
toxel