April 2012 - logback-dev - mailman3.qos.ch

[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: (LBCLASSIC-323) SMTPAppender does not send messages
by Lutz Huehnken (JIRA) 07 May '12

07 May '12

SMTPAppender does not send messages ----------------------------------- Key: LBCLASSIC-323 URL: http://jira.qos.ch/browse/LBCLASSIC-323 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 1.0.0 Environment: JDK 1.5 FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Apr 15 17:37:45 CEST 2008 amd64 Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b01) Java HotSpot(TM) 64-Bit Server VM (build diablo-1.5.0_07-b01, mixed mode) Reporter: Lutz Huehnken Assignee: Logback dev list After upgrading from 0.9.30 to 1.0.0, the ch.qos.logback.classic.net.SMTPAppender seizes to work. It just does not send any messages anymore. This behaviour has apparently been observed by others as well and is also described in this thread: http://old.nabble.com/SMTPAppender-mail-not-sent-%28logback-1.0.0%2C-JDK-1.… It resumes working when - while making no other changes - logback is downgraded to version 0.9.30 -- 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 11

[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

circular dependency with slf4j-api-1.6.4
by Paul Slusarz 27 Apr '12

27 Apr '12

Hi folks, I'm trying to build a logging stack in our apps, and running Tattletale on the project reveals the following circular dependency. Am I doing something wrong? Thanks, Paul ----------------------------------------------- slf4j-api-1.6.4.jar requires: org.slf4j.impl.StaticLoggerBinder org.slf4j.impl.StaticMDCBinder org.slf4j.impl.StaticMarkerBinder provides: org.slf4j.ILoggerFactory org.slf4j.IMarkerFactory org.slf4j.Logger org.slf4j.LoggerFactory org.slf4j.MDC org.slf4j.Marker org.slf4j.MarkerFactory org.slf4j.helpers.BasicMDCAdapter org.slf4j.helpers.BasicMarker org.slf4j.helpers.BasicMarkerFactory org.slf4j.helpers.FormattingTuple org.slf4j.helpers.MarkerIgnoringBase org.slf4j.helpers.MessageFormatter org.slf4j.helpers.NOPLogger org.slf4j.helpers.NOPLoggerFactory org.slf4j.helpers.NOPMDCAdapter org.slf4j.helpers.NamedLoggerBase org.slf4j.helpers.SubstituteLoggerFactory org.slf4j.helpers.Util org.slf4j.spi.LocationAwareLogger org.slf4j.spi.LoggerFactoryBinder org.slf4j.spi.MDCAdapter org.slf4j.spi.MarkerFactoryBinder -------------------------------------------------------------- logback-classic-1.0.0.jar requires: org.slf4j.ILoggerFactory org.slf4j.IMarkerFactory org.slf4j.Logger org.slf4j.LoggerFactory org.slf4j.MDC org.slf4j.Marker org.slf4j.MarkerFactory org.slf4j.helpers.BasicMarkerFactory org.slf4j.helpers.FormattingTuple org.slf4j.helpers.MessageFormatter org.slf4j.helpers.Util org.slf4j.spi.LocationAwareLogger org.slf4j.spi.LoggerFactoryBinder org.slf4j.spi.MDCAdapter org.slf4j.spi.MarkerFactoryBinder provides: org.slf4j.impl.StaticLoggerBinder org.slf4j.impl.StaticMDCBinder org.slf4j.impl.StaticMarkerBinder

1 0

[JIRA] Created: (LBCLASSIC-328) Bad parsing of pattern containing ')' with use property
by Jan Valta (JIRA) 27 Apr '12

27 Apr '12

Bad parsing of pattern containing ')' with use property ------------------------------------------------------- Key: LBCLASSIC-328 URL: http://jira.qos.ch/browse/LBCLASSIC-328 Project: logback-classic Issue Type: Bug Components: Other Environment: Operating System: All Platform: All Reporter: Jan Valta Assignee: Logback dev list Priority: Minor The following config works fine: <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>$%file$</pattern> </encoder> </appender> If I use property to define pattern, so it isn't work: <property name="PATTERN" value="$%file$" /> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>${PATTERN}</pattern> </encoder> </appender> I must use "\\)" instead "\)", then following config work fine: <property name="PATTERN" value="\$%file\$" /> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>${PATTERN}</pattern> </encoder> </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

1 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch master updated. v_1.0.2-1-g038fae3
by git-noreply＠pixie.qos.ch 26 Apr '12

26 Apr '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via 038fae3832917a45353459ce4e2eafaa4bd4d315 (commit) from 7286a1b515a98ff515e663f2d4cec776337bee81 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=038fae3832917a45353459ce… http://github.com/ceki/logback/commit/038fae3832917a45353459ce4e2eafaa4bd4d… commit 038fae3832917a45353459ce4e2eafaa4bd4d315 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Apr 26 22:06:13 2012 +0200 start work on 1.0.3 diff --git a/logback-access/pom.xml b/logback-access/pom.xml index 86648b5..e62dbea 100644 --- a/logback-access/pom.xml +++ b/logback-access/pom.xml @@ -7,7 +7,7 @@ <parent> <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>1.0.2</version> + <version>1.0.3-SNAPSHOT</version> </parent> <artifactId>logback-access</artifactId> diff --git a/logback-classic/pom.xml b/logback-classic/pom.xml index 589d126..8404054 100644 --- a/logback-classic/pom.xml +++ b/logback-classic/pom.xml @@ -7,7 +7,7 @@ <parent> <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>1.0.2</version> + <version>1.0.3-SNAPSHOT</version> </parent> <artifactId>logback-classic</artifactId> diff --git a/logback-core/pom.xml b/logback-core/pom.xml index bab53ff..c20077d 100644 --- a/logback-core/pom.xml +++ b/logback-core/pom.xml @@ -7,7 +7,7 @@ <parent> <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>1.0.2</version> + <version>1.0.3-SNAPSHOT</version> </parent> <artifactId>logback-core</artifactId> diff --git a/logback-examples/pom.xml b/logback-examples/pom.xml index 682ad74..ee401a4 100644 --- a/logback-examples/pom.xml +++ b/logback-examples/pom.xml @@ -5,7 +5,7 @@ <parent> <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>1.0.2</version> + <version>1.0.3-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/logback-site/pom.xml b/logback-site/pom.xml index b29a1bd..42a43f0 100644 --- a/logback-site/pom.xml +++ b/logback-site/pom.xml @@ -5,7 +5,7 @@ <parent> <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>1.0.2</version> + <version>1.0.3-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> diff --git a/pom.xml b/pom.xml index 1f1299c..f2b9998 100755 --- a/pom.xml +++ b/pom.xml @@ -6,7 +6,7 @@ <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>1.0.2</version> + <version>1.0.3-SNAPSHOT</version> <packaging>pom</packaging> <name>Logback-Parent</name> <description>logback project pom.xml file</description> ----------------------------------------------------------------------- Summary of changes: logback-access/pom.xml | 2 +- logback-classic/pom.xml | 2 +- logback-core/pom.xml | 2 +- logback-examples/pom.xml | 2 +- logback-site/pom.xml | 2 +- pom.xml | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0