December 2011 - logback-dev

[JIRA] Created: (LBCLASSIC-240) JNDIUtil.lookup always cast the JNDI lookup result to a String
by Maxence Dewil (JIRA) 22 May '12

22 May '12

JNDIUtil.lookup always cast the JNDI lookup result to a String -------------------------------------------------------------- Key: LBCLASSIC-240 URL: http://jira.qos.ch/browse/LBCLASSIC-240 Project: logback-classic Issue Type: Bug Components: joran Affects Versions: 0.9.27 Reporter: Maxence Dewil Assignee: Logback dev list JNDIUtil.lookup always cast the JNDI lookup result to a String. This method should support other object types like: java.net.URL, ... Description: 1. In our environment, we have declared a variable in Websphere that holds a URL. 2. We use an <insertFromJNDI /> tag. 3. Then the following exception is thrown: ERROR in ch.qos.logback.core.joran.spi.Interpreter@4:71 - RuntimeException in Action for tag [insertFromJNDI] java.lang.ClassCastException: java.net.URL incompatible with java.lang.String at java.lang.ClassCastException: java.net.URL incompatible with java.lang.String at at ch.qos.logback.classic.util.JNDIUtil.lookup(JNDIUtil.java:38) at at ch.qos.logback.classic.joran.action.InsertFromJNDIAction.begin(InsertFromJNDIAction.java:62) at at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:273) at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:145) at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:127) at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:40) at at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:332) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:126) -- 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 13

[JIRA] Created: (LBCLASSIC-176) Asynchronous File appender
by Konstantin Alexandrov (JIRA) 11 May '12

11 May '12

Asynchronous File appender -------------------------- Key: LBCLASSIC-176 URL: http://jira.qos.ch/browse/LBCLASSIC-176 Project: logback-classic Issue Type: New Feature Components: appender Reporter: Konstantin Alexandrov Assignee: Logback dev list Attachments: AsynchRollingFileAppender.java I implement asynch rolling file appender for my application, the reason is to decrease logging time in time critical part of application. This logger save up to 2 time logging time and decrease total IO concurrency. If you found this appender usable, then please include to distribution. 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

5 16

[JIRA] Created: (LBCLASSIC-180) XML/HTML tags haven't get escaped in HTMLLayout
by Xu Hui Hui (JIRA) 09 May '12

09 May '12

XML/HTML tags haven't get escaped in HTMLLayout ----------------------------------------------- Key: LBCLASSIC-180 URL: http://jira.qos.ch/browse/LBCLASSIC-180 Project: logback-classic Issue Type: Bug Components: layout Affects Versions: 0.9.18 Environment: Linux (Ubuntu), JavaSE 1.6 Reporter: Xu Hui Hui Assignee: Logback dev list View it here for a better looking: http://stackoverflow.com/questions/2069135/how-to-make-xml-get-escaped-in-h… I'm using logback (with slf4j) to do the logging, and I've got many XML content to be logged in both text files and HTML files (with HTMLLayout). However, logback just inserts the raw XML in the <TD> tags for the HTMLLayout, without any escaping or <pre> processing. Here is the snippet of my logback.xml: <appender name="ALL" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>${DIR_ALL}/%d{yyyy-MM-dd}.%i.html</FileNamePattern> <TimeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <MaxFileSize>500KB</MaxFileSize> </TimeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <layout class="ch.qos.logback.classic.html.HTMLLayout"> <pattern>%d{HH:mm:ss.SSS}%logger{1}%msg</pattern> <cssBuilder class="ch.qos.logback.classic.html.UrlCssBuilder"> <url>${CSS_HREF}</url> </cssBuilder> <title>Logs (ALL)</title> </layout> And the following is what I got: <td class="Message">(DemoCall) parsing response failed. Details: <call><action>getmessage</action></call> </td> What I'm expecting: <td class="Message">(DemoCall) parsing response failed. Details: <call><action>getmessage</action></call> </td> Or better wrap the above message with a <pre> tag. Do I need to extend the HTMLLayout to archive that? Or is it my job to do a StringEscapeUtils.escapeHTML(msg) for each log statement (I'm not going to do that, since there also is a file appender for which the escaping is not needed). 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

4 4

[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: (LBCORE-243) Return ImmediateFlush and perhaps buffering options to FileAppender
by Petr H (JIRA) 03 May '12

03 May '12

Return ImmediateFlush and perhaps buffering options to FileAppender ------------------------------------------------------------------- Key: LBCORE-243 URL: http://jira.qos.ch/browse/LBCORE-243 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 1.0.0 Reporter: Petr H Assignee: Logback dev list Based on the "log4j performance comparison" discussion in the logback-user mailing list: http://old.nabble.com/log4j-performance-comparison-td31183677.html I'd like to see at least the ImmediateFlush option back as it causes really big difference in writing performance at our systems with heavy logging activity. Last logback release with ImmediateFlush option is 0.9.18 and this is the one we have to stay at due to performance reasons. We can't afford to upgrade to later logback release or switch ImmediateFlush to true as it makes some of our systems practically unusable. The best option seems to be the use of FileWriter with the possibility to set the ImmediateFlush option and also buffering (wrapping with BufferedWriter and use of BufferedIO + BufferSize options) can help a little. -- 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-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