- logback-dev - mailman3.qos.ch

[Bug 1] Appender interface managing Layouts?
by bugzilla-daemon＠pixie.qos.ch 09 Jun '08

09 Jun '08

show_bug.cgi?id=1 Ceki Gulcu <noreply.ceki(a)qos.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |noreply.ceki(a)qos.ch --- Comment #1 from Ceki Gulcu <noreply.ceki(a)qos.ch> 2008-06-09 16:42:43 --- testing -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 83] Parser stops at ')'
by bugzilla-daemon＠pixie.qos.ch 09 Jun '08

09 Jun '08

show_bug.cgi?id=83 Ceki Gulcu <noreply.ceki(a)qos.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |noreply.ceki(a)qos.ch --- Comment #2 from Ceki Gulcu <noreply.ceki(a)qos.ch> 2008-06-09 16:21:09 --- <h2 style="color:#F00;">This bugzilla instance has been closed. Please see <a href="http://jira.qos.ch">http://jira.qos.ch</a> instead. -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

svn commit: r1703 - logback/trunk/logback-classic/src/main/java/org/slf4j/impl
by noreply.ceki＠qos.ch 09 Jun '08

09 Jun '08

Author: ceki Date: Mon Jun 9 15:16:55 2008 New Revision: 1703 Modified: logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java Log: Synchronize with changes to MDCAdapter interface in SLF4J 1.5.1 Modified: logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java (original) +++ logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java Mon Jun 9 15:16:55 2008 @@ -147,4 +147,20 @@ return null; } } + + + @SuppressWarnings("unchecked") + public void setContextMap(Map contextMap) { + HashMap<String, String> oldMap = inheritableThreadLocal.get(); + + HashMap<String, String> newMap = new HashMap<String, String>(); + newMap.putAll(contextMap); + + // the newMap replaces the old one for serialisation's sake + inheritableThreadLocal.set(newMap); + + // hints for the garbage collector + oldMap.clear(); + oldMap = null; + } }

1 0

[JIRA] Created: (LBGENERAL-20) Cannot build 0.9.10-SNAPSHOT
by Paul Gregoire (JIRA) 09 Jun '08

09 Jun '08

Cannot build 0.9.10-SNAPSHOT ---------------------------- Key: LBGENERAL-20 URL: http://jira.qos.ch/browse/LBGENERAL-20 Project: logback-general Issue Type: Bug Reporter: Paul Gregoire Assignee: Logback dev list After reading this http://logback.qos.ch/manual/introduction.html#BuildingLogback I pulling the latest source from SVN I installed Maven 2.0.9 I installed the jms api I ran this C:\dev\shared>mvn install:install-file -DgroupId=javax.jms -DartifactId=jms -Dversion=1.1 -Dpackagin g=jar -Dfile=c:/dev/shared/jms1.1/lib/jms.jar The result was: <pre> [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'install'. [INFO] org.apache.maven.plugins: checking for updates from central [INFO] org.codehaus.mojo: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin… 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/8/mave… 5K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/5/maven-parent-… 14K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin… 15K downloaded [INFO] ------------------------------------------------------------------------ [INFO] Building Maven Default Project [INFO] task-segment: [install:install-file] (aggregator-style) [INFO] ------------------------------------------------------------------------ Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-api/2.0.6/maven… 1K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.6/maven-2.0.6.pom 8K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-project/2.0.6/maven-pr… 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-settings/2.0.6/maven-s… 1K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-model/2.0.6/maven-mode… 2K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.4.1/plexus… 1K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/1.0.11/plexus-1.0.… 8K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/… 3K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0.3/p… 492b downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/1.0.4/plexus-1.0.4… 5K downloaded Downloading: http://repo1.maven.org/maven2/junit/junit/3.8.1/junit-3.8.1.pom 998b downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.0.4/plexus… 6K downloaded Downloading: http://repo1.maven.org/maven2/classworlds/classworlds/1.1-alpha-2/classworl… 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-profile/2.0.6/maven-pr… 1K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-artifact-manager/2.0.6… 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-repository-metadata/2.… 1K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-artifact/2.0.6/maven-a… 1K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0… 680b downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon/1.0-beta-2/wagon… 5K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven-parent-… 9K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-registry/2.0.6/… 1K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-digest/1.0/plexus-… 1K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-components/1.1.7/p… 4K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/1.0.8/plexus-1.0.8… 7K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/… 7K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.1/plexus-u… 767b downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.1/plexus-u… 164K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-digest/1.0/plexus-… 11K downloaded [INFO] [install:install-file] [INFO] Installing c:\dev\shared\jms1.1\lib\jms.jar to C:\Documents and Settings\Administrator\.m2\repository\javax\jms\jms\1.1\jms-1.1.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 15 seconds [INFO] Finished at: Fri Jun 06 15:27:30 PDT 2008 [INFO] Final Memory: 3M/6M [INFO] ------------------------------------------------------------------------ </pre> I then ran: mvn --version <pre> Maven version: 2.0.9 Java version: 1.6.0_04 OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows" </pre> I then cd'd into logback-0.9.9 directory (dont mind the name, it has the latest svn source in it) I ran mvn package and got this <pre> [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error building POM (may not be this project's POM). Project ID: ch.qos.logback:logback-core:jar:${parent.version} Reason: Cannot find parent: ch.qos.logback:logback-parent for project: ch.qos.logback:logback-core:jar:${parent.version} for project ch.qos.logback:logback-core:jar:${parent.version} [INFO] ------------------------------------------------------------------------ [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: ch.qos.logback:logback-parent for project: ch.qos.logback:logback-core:jar:${parent.version} for project ch.qos.logback:logback-co re:jar:${parent.version} at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: ch.qos.logback:logback-parent for project: ch.qos.logback:logback-core:jar:${parent.version} for project ch.qos.logback:logback-core:jar:${parent.version} at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'ch.qos.logback:logback-parent' not found in repository: Unable to download the artifact from any repository ch.qos.logback:logback-parent:pom:0.9.10-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) for project ch.qos.logback:logback-parent at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:603) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1366) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository ch.qos.logback:logback-parent:pom:0.9.10-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:212) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:556) ... 19 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:331) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:200) ... 21 more [INFO] ------------------------------------------------------------------------ [INFO] Total time: < 1 second [INFO] Finished at: Fri Jun 06 15:39:16 PDT 2008 [INFO] Final Memory: 1M/4M [INFO] ------------------------------------------------------------------------ </pre> I have also tried just mvn and both from logback-classic directories. I am not a maven user and I dont know what or where logback-parent is... -- 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 1

[JIRA] Commented: (LBCORE-24) LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++)
by Paul Gregoire (JIRA) 06 Jun '08

06 Jun '08

[ http://jira.qos.ch/browse/LBCORE-24?page=com.atlassian.jira.plugin.system.i… ] Paul Gregoire commented on LBCORE-24: ------------------------------------- Ceki, I made the change you suggested to org.slf4j.impl.StaticLoggerBinder but I cannot build logback (http://jira.qos.ch/browse/LBGENERAL-20) The change to line 93 is return (ContextSelector) cons.newInstance(new Object[]{defaultLoggerContext}); > LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++) > --------------------------------------------------------------- > > Key: LBCORE-24 > URL: http://jira.qos.ch/browse/LBCORE-24 > Project: logback-core > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Jens Elkner > Assignee: Logback dev list > > Since LoggerFactory obtains the LoggerContext to use in its static init stage, using a LoggerContextFilter as described in Chapter 8 is completely useless, since the JNDI selector is never consulted again. > Digging deeper on that issue reveals, that using a ContextJNDISelector (even if it would work) rarely leads to the intended behavior (e.g. webapp related logging), and is probably not thread safe wrt. common practice and intended logging. E.g. in tomcat we have two different cases: > a) each webapp provides its own slfj4*.jar as well as *logback*.jar > b) slfj4*.jar as well as *logback*.jar are shared via tomcat/common/lib or > tomcat/share/lib > c) a und b mixed > Well, to get things right, one can say case c) is unsupported ;-). > In case a) logback has its own playground, so using JNDI doesn't make sense at all, since the webapp/logback has its own playground - doesn't interfere with > other web apps since loaded via its dedicated classloader. > However case b) is a little bit more challenging. Here the LoggerFactory and other classes are !shared! between several webapps, since loading is delegated from the dedicated webapp classloader to the shared webapp classloader, which picks up everything in share/lib , common/lib. So right now in 0.9.7, even if one uses JNDISelector a per webapp logging is impossible: The first webapp, which asks for a LoggerFactory always wins! All other webapps, which ask later for a LoggerFactory.getLogger() will get a Logger from the LoggerContext associated with the first webapp, since the context is "cached", i.e. the JNDI selector gets never consulted again. > Assuming the LoggerFactory problem gets fixed by using e.g. > public static Logger getLogger(* *) { > return StaticLoggerBinder.SINGLETON.getLoggerFactory().getLogger(**); > } > there is still a problem wrt. common practice aka log* usage pattern and webapp shared classes, which can not be resolved by JNDI: Today most developer use something like: > public class XY { > private static [final] Logger log = LoggerFactory.getLogger(XY.class); > ... > } > That implies the same problem, as with the current LoggerFactory bug: The class gets the Logger from the context associated with the first webapp, which needs the shared class. And that's why all other webapps, which later need this class will use the the logger context of the first webapp. So e.g. if webapp A is configured to log to /var/log/a.log and another webapp B is configured to log to /var/log/b.log the loging output of shared classes will always go to /var/log/a.log if webapp used the classes in question first, no matter on which thread aka in which webapp the shared classes are used. > So even if LoggerFactory gets fixed, JNDI selector is of little use, if one wants to have a webapp dedicated log as soon as shared classes are involved. > The only way to solve the didcated webapp log problem a can think of, to introduce another level of indirection in the Logger.log* etc. method, which takes care of thread local settings and the settings of its parent threads (e.g. an application may start other threads, which do not inherit the thread local settings from the current thread ...). But this would probably influence the performance of logback in a rather negative way. > Another idea might be an architecture re-design: sharing Loggers would be no problem because of thread local AppenderContext soft ref, which points to an Appender in the global AppenderStore singleton ... > RFE: These problems should be reflected chapter 8 of the logback manual to avoid further confusion ... -- 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

[JIRA] Commented: (LBCORE-24) LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++)
by Paul Gregoire (JIRA) 06 Jun '08

06 Jun '08

[ http://jira.qos.ch/browse/LBCORE-24?page=com.atlassian.jira.plugin.system.i… ] Paul Gregoire commented on LBCORE-24: ------------------------------------- First off I must say that I've grown very disenchanted with all the logging frameworks out there. Problems like this just plain frustrating, there is way too much "magic" happening behind our backs. But to get on with my comment.. I have tried for several days to get slf4j and logback to work in harmony with Red5. Everything works well until you try to separate logging into web contexts or red5 app instances, all logging continues to go the topmost default level. I have created a log context selector, log filter, and log listener but they dont work properly.. maybe you guys can see where i've gone wrong? http://svn1.cvsdude.com/osflash/red5/java/server/trunk/src/org/red5/logging/ I have also tried to use the non-static non-final logging patter in my red5 apps but it doesnt improve anything. > LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++) > --------------------------------------------------------------- > > Key: LBCORE-24 > URL: http://jira.qos.ch/browse/LBCORE-24 > Project: logback-core > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Jens Elkner > Assignee: Logback dev list > > Since LoggerFactory obtains the LoggerContext to use in its static init stage, using a LoggerContextFilter as described in Chapter 8 is completely useless, since the JNDI selector is never consulted again. > Digging deeper on that issue reveals, that using a ContextJNDISelector (even if it would work) rarely leads to the intended behavior (e.g. webapp related logging), and is probably not thread safe wrt. common practice and intended logging. E.g. in tomcat we have two different cases: > a) each webapp provides its own slfj4*.jar as well as *logback*.jar > b) slfj4*.jar as well as *logback*.jar are shared via tomcat/common/lib or > tomcat/share/lib > c) a und b mixed > Well, to get things right, one can say case c) is unsupported ;-). > In case a) logback has its own playground, so using JNDI doesn't make sense at all, since the webapp/logback has its own playground - doesn't interfere with > other web apps since loaded via its dedicated classloader. > However case b) is a little bit more challenging. Here the LoggerFactory and other classes are !shared! between several webapps, since loading is delegated from the dedicated webapp classloader to the shared webapp classloader, which picks up everything in share/lib , common/lib. So right now in 0.9.7, even if one uses JNDISelector a per webapp logging is impossible: The first webapp, which asks for a LoggerFactory always wins! All other webapps, which ask later for a LoggerFactory.getLogger() will get a Logger from the LoggerContext associated with the first webapp, since the context is "cached", i.e. the JNDI selector gets never consulted again. > Assuming the LoggerFactory problem gets fixed by using e.g. > public static Logger getLogger(* *) { > return StaticLoggerBinder.SINGLETON.getLoggerFactory().getLogger(**); > } > there is still a problem wrt. common practice aka log* usage pattern and webapp shared classes, which can not be resolved by JNDI: Today most developer use something like: > public class XY { > private static [final] Logger log = LoggerFactory.getLogger(XY.class); > ... > } > That implies the same problem, as with the current LoggerFactory bug: The class gets the Logger from the context associated with the first webapp, which needs the shared class. And that's why all other webapps, which later need this class will use the the logger context of the first webapp. So e.g. if webapp A is configured to log to /var/log/a.log and another webapp B is configured to log to /var/log/b.log the loging output of shared classes will always go to /var/log/a.log if webapp used the classes in question first, no matter on which thread aka in which webapp the shared classes are used. > So even if LoggerFactory gets fixed, JNDI selector is of little use, if one wants to have a webapp dedicated log as soon as shared classes are involved. > The only way to solve the didcated webapp log problem a can think of, to introduce another level of indirection in the Logger.log* etc. method, which takes care of thread local settings and the settings of its parent threads (e.g. an application may start other threads, which do not inherit the thread local settings from the current thread ...). But this would probably influence the performance of logback in a rather negative way. > Another idea might be an architecture re-design: sharing Loggers would be no problem because of thread local AppenderContext soft ref, which points to an Appender in the global AppenderStore singleton ... > RFE: These problems should be reflected chapter 8 of the logback manual to avoid further confusion ... -- 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 1

[Bug 107] Specificy the config file to use as a System property
by bugzilla-daemon＠pixie.qos.ch 06 Jun '08

06 Jun '08

show_bug.cgi?id=107 Silvano Maffeis <silvano(a)maffeis.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #9 from Silvano Maffeis <silvano(a)maffeis.com> 2008-06-06 08:42:23 --- I'm voting for this feature, too -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 107] Specificy the config file to use as a System property
by bugzilla-daemon＠pixie.qos.ch 06 Jun '08

06 Jun '08

show_bug.cgi?id=107 Silvano Maffeis <silvano(a)maffeis.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |silvano(a)maffeis.com --- Comment #8 from Silvano Maffeis <silvano(a)maffeis.com> 2008-06-06 08:40:56 --- I'm voting for this feature, too -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[JIRA] Created: (LBGENERAL-19) PatternLayout where I can show just the
by Arthur Blake (JIRA) 05 Jun '08

05 Jun '08

PatternLayout needs to be able to show class name of the logger without it's package prefix MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk PatternLayout where I can show just the PatternLayout needs to be able to show class name of the logger without it's package prefix ------------------------------------------------------------------------------------------------------------------------------------- Key: LBGENERAL-19 URL: http://jira.qos.ch/browse/LBGENERAL-19 Project: logback-general Issue Type: New Feature Affects Versions: unspecified Environment: All Reporter: Arthur Blake Assignee: Logback dev list Priority: Minor It would be very useful to have an option in the PatternLayout to show *only* the class name without it's package prefix. See: http://marc.info/?l=logback-user&m=118417765316898&w=2 and http://marc.info/?l=logback-user&m=121266617228638&w=2 -- 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

[JIRA] Created: (LBSITE-14) Add documentation how to shutdown Logback in a web application
by Syvalta (JIRA) 04 Jun '08

04 Jun '08

Add documentation how to shutdown Logback in a web application -------------------------------------------------------------- Key: LBSITE-14 URL: http://jira.qos.ch/browse/LBSITE-14 Project: logback-site Issue Type: Improvement Components: Documentation Reporter: Syvalta Assignee: Logback dev list Currently it is not documented how to shutdown Logback in a web application. For more details, see: http://www.nabble.com/log-files-locked-after-application-undeploy-td1761950… -- 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