November 2011 - logback-dev

[JIRA] Created: (LBCLASSIC-159) Invalid multiple configuration file warning
by Hontvári József (JIRA) 08 May '12

08 May '12

Invalid multiple configuration file warning ------------------------------------------- Key: LBCLASSIC-159 URL: http://jira.qos.ch/browse/LBCLASSIC-159 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.917 Environment: Resin webapp Reporter: Hontvári József Assignee: Logback dev list I receive strange warnings in the status info. It says that logback.xml, which in this case comes from a file and not from the classpath, occurs multiple times. The file is specifies and logged using absolute path, so even relative paths cannot cause the warning. Logback configuration file is specified by the system property "logback.configurationFile". It is done by the Resin application server, somehow it is able to supply different properties for different web applications. I don't think this is important, however. Maybe I am doing something wrong, but at least the message doesn't help. 20:36:34,236 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [file:/C:/Progra~1/mireka/conf/logback.xml] at [file:/C:/Progra~1/mireka/conf/logback.xml] 20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:/C:/Progra~1/mireka/conf/logback.xml] occurs multiple times on the classpath. 20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:/C:/Progra~1/mireka/conf/logback.xml] occurs at [file:/C:/Progra~1/mireka/conf/logback.xml] 20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:/C:/Progra~1/mireka/conf/logback.xml] occurs at [file:/C:/Progra~1/mireka/conf/logback.xml] 20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:/C:/Progra~1/mireka/conf/logback.xml] occurs at [file:/C:/Progra~1/mireka/conf/logback.xml] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

4 16

[JIRA] Created: (LBACCESS-28) Could not find status manager
by seenimurugan shanmugam (JIRA) 05 May '12

05 May '12

Could not find status manager ----------------------------- Key: LBACCESS-28 URL: http://jira.qos.ch/browse/LBACCESS-28 Project: logback-access Issue Type: Bug Affects Versions: 0.9.30 Environment: tomcat 6.0.33 , mac lion os. Reporter: seenimurugan shanmugam Assignee: Logback dev list When access https://localhost:8443/lbAccessStatus i get this message on the screen ( Could not find status manager ). my configuration details. ===================== server -- tomcat 6.0.33 os ----- Mac OS X (Lion) web.xml config is ============== <servlet> <servlet-name>AccessViewStatusMessages</servlet-name> <servlet-class>ch.qos.logback.access.ViewStatusMessagesServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>AccessViewStatusMessages</servlet-name> <url-pattern>/lbAccessStatus</url-pattern> </servlet-mapping> logback-access.xml on tomcat/conf dirctory ================================== <?xml version="1.0" encoding="UTF-8"?> <configuration>  <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>access.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>access.%d{yyyy-MM-dd}.log.zip</fileNamePattern> </rollingPolicy> <encoder> <pattern>combined</pattern> </encoder> </appender> <appender-ref ref="FILE" /> </configuration> jar installed in tomcat/lib directory are ============================== logback-access-0.9.30.jar logback-core-0.9.30.jar when i run my web application in netbeans i can see the logback status message as ==================================================================== 18:43:39,490 |-INFO in ch.qos.logback.access.tomcat.LogbackValve[Catalina] - filename property not set. Assuming [/Users/seeni/software/apache-tomcat-6.0.33/conf/logback-access.xml] 18:43:39,556 |-INFO in ch.qos.logback.access.joran.action.ConfigurationAction - Ignoring debug attribute. 18:43:39,559 |-INFO in ch.qos.logback.core.joran.action.StatusListenerAction - Adding status listener of type [ch.qos.logback.core.status.OnConsoleStatusListener] 18:43:39,576 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender] 18:43:39,581 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [FILE] 18:43:39,622 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use zip compression 18:43:39,624 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use the pattern access.%d{yyyy-MM-dd}.log for the active file 18:43:39,632 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd' from file name pattern 'access.%d{yyyy-MM-dd}.log.zip'. 18:43:39,633 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over at midnight. 18:43:39,633 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Mon Nov 07 18:42:34 GMT 2011 18:43:39,635 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.access.PatternLayoutEncoder] for [encoder] property 18:43:39,659 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - Active log file name: access.log 18:43:39,659 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - File property is set to [access.log] 18:43:39,660 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [FILE] to ch.qos.logback.access.tomcat.LogbackValve[Catalina] 18:43:39,661 |-INFO in ch.qos.logback.access.joran.action.ConfigurationAction - End of configuration. 18:43:39,662 |-INFO in ch.qos.logback.access.joran.JoranConfigurator@4e299813 - Registering current configuration as safe fallback point 18:43:39,490 |-INFO in ch.qos.logback.access.tomcat.LogbackValve[Catalina] - filename property not set. Assuming [/Users/seeni/software/apache-tomcat-6.0.33/conf/logback-access.xml] 18:43:39,556 |-INFO in ch.qos.logback.access.joran.action.ConfigurationAction - Ignoring debug attribute. 18:43:39,559 |-INFO in ch.qos.logback.core.joran.action.StatusListenerAction - Adding status listener of type [ch.qos.logback.core.status.OnConsoleStatusListener] 18:43:39,576 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender] 18:43:39,581 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [FILE] 18:43:39,622 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use zip compression 18:43:39,624 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use the pattern access.%d{yyyy-MM-dd}.log for the active file 18:43:39,632 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd' from file name pattern 'access.%d{yyyy-MM-dd}.log.zip'. 18:43:39,633 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over at midnight. 18:43:39,633 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Mon Nov 07 18:42:34 GMT 2011 18:43:39,635 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.access.PatternLayoutEncoder] for [encoder] property 18:43:39,659 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - Active log file name: access.log 18:43:39,659 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - File property is set to [access.log] 18:43:39,660 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [FILE] to ch.qos.logback.access.tomcat.LogbackValve[Catalina] 18:43:39,661 |-INFO in ch.qos.logback.access.joran.action.ConfigurationAction - End of configuration. 18:43:39,662 |-INFO in ch.qos.logback.access.joran.JoranConfigurator@4e299813 - Registering current configuration as safe fallback point logback status looks ok. But could not see the status on browser when i access https://localhost:8443/lbClassicStatus , it's works fine but not https://localhost:8443/lbAccessStatus I spent a whole day looking at BasicStatusManager class and all the other stuff , but no luck. is there anything i am missing or is it really a bug? Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

3 15

[JIRA] Created: (LBCORE-234) write a special line as the first line in any log file so that the file can be automatically parsed by a tool
by James Strachan (JIRA) 03 May '12

03 May '12

write a special line as the first line in any log file so that the file can be automatically parsed by a tool ------------------------------------------------------------------------------------------------------------- Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Logback dev list So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

6 12

[JIRA] Created: (LBCLASSIC-256) java.util.logging propagated level changes are lost because of race condition with garbage collection
by Samuel Stanojevic (JIRA) 03 May '12

03 May '12

java.util.logging propagated level changes are lost because of race condition with garbage collection ----------------------------------------------------------------------------------------------------- Key: LBCLASSIC-256 URL: http://jira.qos.ch/browse/LBCLASSIC-256 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Environment: win7 64-bit, bootstrapped in a Tomcat server Reporter: Samuel Stanojevic Assignee: Logback dev list Attachments: LevelChangePropagator.java I have bootstrapped logback in my Tomcat server, and have setup JUL to redirect logging requests to SLF4J by adding the following in my logging.properties: .handlers = org.slf4j.bridge.SLF4JBridgeHandler Anyways, my setup works pretty nicely. The problem is when I try to activate the JUL LevelChangePropagator, the info doesn't quite propagate as expected. Here is my config: <configuration debug="true"> <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator"> <resetJUL>true</resetJUL> </contextListener> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">  <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> <target>System.out</target> </appender> <root level="ERROR"> <appender-ref ref="STDOUT" /> </root> <logger name="test.propagation" level="TRACE"/>  </configuration> The problem is that if my app tries to do: java.util.logging.Logger.getLogger("test.propagation").fine("hello world"); ..., it doesn't print. I have confirmed that the bug is because, even though the LevelChangePropagator class does propagate the level change info to JUL, it fails to keep a strong reference to the logger that it just changed. By not keeping a strong reference, and because the JUL LogManager only keeps WeakReferences to loggers, then the GC has time to clear out the change before the app's first attempt to use the logger. (see java.util.logging.LogManager#addLogger where the javadoc says "The application should retain its own reference to the Logger object to avoid it being garbage collected. The LogManager may only retain a weak reference") To test my hunch, I patched the LevelChangePropagator class by adding a global hashset of java.util.logging.Logger, and I systematically add the loggers to the hashset in the method "propagate(logger,level)". After this patch, my logging started working as expected. My fix may not be the best, and may have implications that I did not think about, but I think something along those lines needs to be done to fix the bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

5 7

[JIRA] Created: (LBCLASSIC-234) CLONE -Excessive synchronization in ReconfigureOnChangeFilter.decide
by uri unger (JIRA) 25 Apr '12

25 Apr '12

CLONE -Excessive synchronization in ReconfigureOnChangeFilter.decide -------------------------------------------------------------------- Key: LBCLASSIC-234 URL: http://jira.qos.ch/browse/LBCLASSIC-234 Project: logback-classic Issue Type: Bug Affects Versions: 0.917 Reporter: uri unger Assignee: Ceki Gulcu The synchronization in ReconfigureOnChangeFilter.decide hurts scalability. It seems unnecessary to serialize the code in changeDetected -- it should be possible to use atomic updates of nextCheck and lastModified and only serialize the actual reconfiguration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

6 18

[JIRA] Created: (LBCORE-221) Error in FileNamePattern::toRegex for index (Integer)
by Dieter Mueller (JIRA) 25 Apr '12

25 Apr '12

Error in FileNamePattern::toRegex for index (Integer) ----------------------------------------------------- Key: LBCORE-221 URL: http://jira.qos.ch/browse/LBCORE-221 Project: logback-core Issue Type: Bug Components: Pattern, Rolling Affects Versions: 0.9.29 Reporter: Dieter Mueller Assignee: Logback dev list Priority: Minor Deletion of old archived logs on rolling failes for index > 99. We have a process which logs much, which results in more than 99 log files per day (config below), e.g. snowball_POLL_MSG_SRV_xdebug-old-2011-09-13.110.log.zip. On rolling event, only the first 99 were deleted, due to bug in FileNamePattern::toRegex for index (Integer): regEx: \d{1,2) which means digits with max length of 2. We need at least 3 digits: regEx: \d{1,3) better 4? ;-) Workarounds like increasing file size, or hourly-rollover to hold index lower than 100 are not very wellcomed. Thanks in advance, Dieter Mueller. config: <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <fileNamePattern>${log.vm.file.prefix}_xdebug-old-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern> <maxHistory>1</maxHistory> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>20MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

3 2

[JIRA] Created: (LBCORE-169) RollingFileAppender/TimeBasedRollingPolicy failing to ZIP files in different directory
by Tomasz Nurkiewicz (JIRA) 24 Apr '12

24 Apr '12

RollingFileAppender/TimeBasedRollingPolicy failing to ZIP files in different directory -------------------------------------------------------------------------------------- Key: LBCORE-169 URL: http://jira.qos.ch/browse/LBCORE-169 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list When using ZIP feature to compress old log files, Logback does not allow to put ZIP files in different directory like in this example: <file>logs\server.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs\arch\server.%d{yyyy-MM-dd_HHmm}.log.zip</fileNamePattern> </rollingPolicy> Running the attached test maven project (it takes 1 minute to run) will create server.log3560979839057.tmp (or similar) temporary file instead of ZIP file in /arch subdirectory (preferably this directory should be created if not exists). If fileNamePattern in rollingPolicy is changed to: "logs\server.%d{yyyy-MM-dd_HHmm}.log.zip" everything works as expected. The root of this issue is to be able to automatically ZIP files AND archive them in different directory. It would be great to be able to use date placeholders in folder names, for instance: <fileNamePattern>logs\arch-%d{yyyy-MM}\server.%d{yyyy-MM-dd_HHmm}.log.zip</fileNamePattern> so that Logback would automatically create folders for each month with ZIPped files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

8 9

[JIRA] Created: (LBCORE-84) Typo in PropertyAction
by Michael Franz (JIRA) 24 Apr '12

24 Apr '12

Typo in PropertyAction ---------------------- Key: LBCORE-84 URL: http://jira.qos.ch/browse/LBCORE-84 Project: logback-core Issue Type: Bug Components: Joran Affects Versions: 0.9.14 Reporter: Michael Franz Assignee: Logback dev list Priority: Trivial The following message is printed |-WARN in ch.qos.logback.core.joran.action.PropertyAction - [substitutionProperty] element has been deprecated. Plase use the [property] element instead. There an 'e' missing in "Please". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

[JIRA] Created: (LBCLASSIC-309) Groovy-config fails without outside code noticing
by Endre Stølsvik (JIRA) 10 Apr '12

10 Apr '12

Groovy-config fails without outside code noticing ------------------------------------------------- Key: LBCLASSIC-309 URL: http://jira.qos.ch/browse/LBCLASSIC-309 Project: logback-classic Issue Type: Bug Components: joran Affects Versions: unspecified Environment: na Reporter: Endre Stølsvik Assignee: Logback dev list Priority: Minor [As reported on the user-list, where I was requested to make a bug report] This groovy-file ...: import ch.qos.logback.classic.PatternLayout import ch.qos.logback.core.ConsoleAppender import ch.qos.logback.core.encoder.LayoutWrappingEncoder appender("STDOUT", ConsoleAppender) { encoder(LayoutWrappingEncoder) { layout(PatternLayout) { pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{55}.%M.%L - %msg%n" } } } root(ALL, ["STDOUT"]) ... apparently crashes the configuration as such: Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: ALL for class: Script1 at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:50) at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:231) at Script1.run(Script1.groovy:13) at Script1$run.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112) at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:59) at ch.qos.logback.classic.gaffer.GafferConfigurator$run.callCurrent(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141) at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:37) at ch.qos.logback.classic.gaffer.GafferUtil.runGafferConfiguratorOn(GafferUtil.java:44) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:67) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:128) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:279) at XYZ.doLogConfig(XYZ.java:40) at XYZ.main(XYZ:169) The problem is obviously, as the error message states, the not-defined property "ALL". *The problem I am reporting is that this isn't caught*. The console-dump happens in the "We should never get here" catch block below: void init() { try { try { new ContextInitializer(defaultLoggerContext).autoConfig(); } catch (JoranException je) { Util.report("Failed to auto configure default logger context", je); } StatusPrinter.printInCaseOfErrorsOrWarnings(defaultLoggerContext); contextSelectorBinder.init(defaultLoggerContext, KEY); initialized = true; } catch (Throwable t) { // we should never get here Util.report("Failed to instantiate [" + LoggerContext.class.getName() + "]", t); } } Notice that the StatusManager does not know that the config failed: 13:32:07,643 |-INFO in ch.qos.logback.classic.LoggerContext[Emma logcontext] - Found resource [logback.groovy] at [file:/XYZ/target/classes/logback.groovy] 13:32:08,807 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@2111e072 - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 13:32:08,809 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@2111e072 - Naming appender as [STDOUT] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 1

[JIRA] Created: (LBCLASSIC-157) Add option to include caller data in JMS Appender or to disable caller data in DB Appender
by Ging Ming Chan (JIRA) 22 Mar '12

22 Mar '12

Add option to include caller data in JMS Appender or to disable caller data in DB Appender ------------------------------------------------------------------------------------------ Key: LBCLASSIC-157 URL: http://jira.qos.ch/browse/LBCLASSIC-157 Project: logback-classic Issue Type: New Feature Components: appender Affects Versions: 0.917 Reporter: Ging Ming Chan Assignee: Logback dev list Priority: Minor We are using the JMSQueueAppender remotely with a centralised server that uses the DBAppender to log to the database. However, since the JMSQueueAppender does not send the caller data, and the DBAppender always expect it, the operation never succeeded. There are two options to fix this, either add the includeCallerData option in the JMS Appender or to exclude caller data in the DB Appender. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

4 4