May 2011 - slf4j-dev - mailman3.qos.ch

[Bug 201] New: Need ability to shutdown loggers and flush appenders
by bugzilla-daemon＠pixie.qos.ch 03 Mar '15

03 Mar '15

http://bugzilla.slf4j.org/show_bug.cgi?id=201 Summary: Need ability to shutdown loggers and flush appenders Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: mike.schall(a)gmail.com There needs to be a way to shutdown logging and flush async appenders so when a process is closing, all log events are written before the process is closed. Should ILoggerFactory have a shutdown or stop method? It could shutdown whatever logging back end I'm using? For log4j it would call - org.apache.log4j.LogManager.getLoggerRepository().shutdown(); For logback it would call - loggerContext.stop() Other back ends - ??? This is required to allow me to not reference logging back ends explicitly in my code to shutdown successfully without losing events. Discussion about this is happening on the user list at - http://www.qos.ch/pipermail/logback-user/2010-September/001816.html -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 18

[Bug 176] New: Initialization (getILoggerFactory) is not thread safe
by bugzilla-daemon＠pixie.qos.ch 07 Mar '14

07 Mar '14

http://bugzilla.slf4j.org/show_bug.cgi?id=176 Summary: Initialization (getILoggerFactory) is not thread safe Product: SLF4J Version: 1.5.x Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: rcogswell(a)datasltn.com If a getLogger call occurs during initialization from a thread other than the one that triggered the initialization, it is treated the same as if it were a re-entrant call from the initialization thread (i.e. getILoggerFactory returns the TEMP_FACTORY). Scenario: 1. An SLF4J LogFactory.getLogger statement is at the beginning of a worker thread class's run method. 2. Two or more worker threads are started at the same time during server startup. 3. Since the getLogger statements from the workers are executed nearly simultaneously, the first one triggers the SLF4J initialization and subsequent workers receive NOPLogger instances from the TEMP_FACTORY since LoggerFactory.INITIALIZATION_STATE == ONGOING_INITILIZATION. 4. Logging then works successfully for the worker that triggered the initialization, but the logging for all other workers is suppressed. The only reason I've indicated the severity as "major" instead of "critical" is that I happen to have my own wrapper class around SLF4J, so it was easy for me to independently track whether or not SLF4J has been called and introduce appropriate synchronization around the first call. For those using SLF4J directly (as recommended), there would not likely be any straightforward workaround. Below I've included a new implementation for LoggerFactory.getILoggerFactory to address this. The key aspects of this new implementation are as follows: 1. Checks first for successful initialization since this is the case for which performance matters most. 2. Synchronizes around determining whether or not the current thread should perform initialization, but does not synchronize around the initialization itself. 3. Retains the previous behavior for re-entrant calls from the thread performing the initialization. 4. Calls from other threads during initialization will wait up to 10 seconds for the initialization to finish. The main downsides of the implementation below (aside from not yet being tested): 1. If a logging implementation uses multiple threads to perform its initialization and one of those threads does a getLogger call, then this change would have undesirable effects, but I would be very surprised if any SLF4J implementations have multi-threaded initialization. 2. 10 seconds was a fairly arbitrary choice. It might be worthwhile to allow this to be controlled by a system property with a default of 10 seconds. 3. Considerably more complicated than the current implementation. private static Thread INITIALIZATION_THREAD = null; private static Object INITIALIZATION_SYNCH = new Object(); /** * Return the {@link ILoggerFactory} instance in use. * * <p> * ILoggerFactory instance is bound with this class at compile time. * * @return the ILoggerFactory instance in use */ public static ILoggerFactory getILoggerFactory() { if (INITIALIZATION_STATE == SUCCESSFUL_INITILIZATION) { return getSingleton().getLoggerFactory(); } if (INITIALIZATION_STATE == FAILED_INITILIZATION) { throw new IllegalStateException(UNSUCCESSFUL_INIT_MSG); } boolean shouldPerformInitialization = false; synchronized (INITIALIZATION_SYNCH) { if (INITIALIZATION_STATE == UNINITIALIZED) { INITIALIZATION_STATE = ONGOING_INITILIZATION; INITIALIZATION_THREAD = Thread.currentThread(); shouldPerformInitialization = true; } else if (INITIALIZATION_STATE == ONGOING_INITILIZATION) { if (Thread.currentThread() == INITIALIZATION_THREAD) { // support re-entrant behavior. // See also http://bugzilla.slf4j.org/show_bug.cgi?id=106 return TEMP_FACTORY; } try { INITIALIZATION_SYNCH.wait(10000); } catch (InterruptedException e) { Util.reportFailure("Initialization failed to complete within 10 seconds."); return TEMP_FACTORY; } } } if (shouldPerformInitialization) { performInitialization(); synchronized (INITIALIZATION_SYNCH) { INITIALIZATION_THREAD = null; INITIALIZATION_SYNCH.notifyAll(); } } switch (INITIALIZATION_STATE) { case SUCCESSFUL_INITILIZATION: return getSingleton().getLoggerFactory(); case FAILED_INITILIZATION: throw new IllegalStateException(UNSUCCESSFUL_INIT_MSG); } throw new IllegalStateException("Unreachable code"); } -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 31

[Bug 197] New: XLogger enhancements
by bugzilla-daemon＠pixie.qos.ch 05 Feb '14

05 Feb '14

http://bugzilla.slf4j.org/show_bug.cgi?id=197 Summary: XLogger enhancements Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P1 Component: slf4j-ext AssignedTo: slf4j-dev(a)qos.ch ReportedBy: kalgon(a)hotmail.com Hi, I would like to propose to improve some methods in XLogger: <T> T exit(T result); <T extends Throwable> T throwing(T throwable); <T extends Throwable> T throwing(Level level, T throwable); so I could use them as follows: public void myMethod(String myParam, Object myOtherParam) { this.xlogger.entry(myParam, myOtherParam); if (conditionNotMet) { throw this.xlogger.throwing(new ConditionNotMetException("wrong")); } return this.xlogger.exit(myParam.concat(myOtherParam)); } Well maybe it's too much too ask after all the debates about varargs support over the years =) Xavier. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 2

[Bug 173] New: slf4j android: Android throws an IllegalArgumentException when Log Tag length exceeds 23 characters
by bugzilla-daemon＠pixie.qos.ch 11 Sep '13

11 Sep '13

http://bugzilla.slf4j.org/show_bug.cgi?id=173 Summary: slf4j android: Android throws an IllegalArgumentException when Log Tag length exceeds 23 characters Product: SLF4J Version: 1.5.x Platform: Other OS/Version: other Status: NEW Severity: blocker Priority: P1 Component: Implementations AssignedTo: slf4j-dev(a)qos.ch ReportedBy: lorecarra(a)gmail.com I don't know if the 23-characters long tag limitation has been removed in later releases, but, unfortunately, Android 1.1 has it. I think the tag length should be checked and the tag eventually trimmed in order to avoid incurring in this exception without having to change the application logging code. The check is performed into the native method android.util.Log.isLoggable() To reproduce the problem in Android 1.1: String ALLOWED_TAG = "abcdefghijklmnopqrstuvw"; String TOO_LONG_TAG = "abcdefghijklmnopqrstuvwxyz"; Log.i(ALLOWED_TAG, "blabla"); Log.i(TOO_LONG_TAG, "blabla"); -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 19

[Bug 190] New: juli-over-slf4j module
by bugzilla-daemon＠pixie.qos.ch 08 Jul '13

08 Jul '13

http://bugzilla.slf4j.org/show_bug.cgi?id=190 Summary: juli-over-slf4j module Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows XP Status: NEW Severity: blocker Priority: P1 Component: Implementations AssignedTo: slf4j-dev(a)qos.ch ReportedBy: olamy(a)apache.org Hi, Have a look at this fork : http://github.com/olamy/slf4j I have added a module to wrap juli logging library. Thanks -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 4

[Bug 205] New: make multiple bindings check more intelligent
by bugzilla-daemon＠pixie.qos.ch 13 May '13

13 May '13

http://bugzilla.slf4j.org/show_bug.cgi?id=205 Summary: make multiple bindings check more intelligent Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Linux Status: NEW Severity: trivial Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: gsubes(a)gmail.com I'am using SLF4J in a setup of a software product line where multiple eclipse projects (as modules) are used with their own dependency management. so every module has its own copy of the logger binding jar. the modules have references to other modules (vie eclipse project references) and thus have multiple versions of the same logger binding in the classpath when tests are run etc. This results in always receiving this warning: SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/subes/Dokumente/Entwicklung/invesdwin/inv-webproxy/trunk/03_module/invesdwin-gemeinsam/lib/default/logback-classic-0.9.25.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/subes/Dokumente/Entwicklung/invesdwin/inv-webproxy/trunk/03_module/invesdwin-gemeinsam-integration/lib/default/logback-classic-0.9.25.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/subes/Dokumente/Entwicklung/invesdwin/inv-webproxy/trunk/03_module/invesdwin-gemeinsam-integration-ws/lib/default/logback-classic-0.9.25.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/subes/Dokumente/Entwicklung/invesdwin/inv-webproxy/trunk/03_module/invesdwin-gemeinsam-webserver/lib/default/logback-classic-0.9.25.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. -------------------------------- It would be nice if slf4j would check if the bindings actually have the same name and then ignore multiple jars of the same binding. the warning is made without a real reason in this particular case and should be more intelligent to allow such use cases. Or at least give me a hint on how to disable this warning on my own account. :) -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 4

[Bug 212] New: MessageFormat. format throws Exception when attempting to parse parameters
by bugzilla-daemon＠pixie.qos.ch 13 Mar '13

13 Mar '13

http://bugzilla.slf4j.org/show_bug.cgi?id=212 Summary: MessageFormat.format throws Exception when attempting to parse parameters Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Mac OS X 10.3 Status: NEW Severity: blocker Priority: P1 Component: jul-to-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: kristof.pelckmans(a)wondergraphs.com I am trying to bridge a LogRecord with a message that is the result of HashMap.toString(): {interface com.google.code.morphia.annotations.Id=(a)com.google.code.morphia.annotations.Id()} and get following exception Caused by: java.lang.IllegalArgumentException: can't parse argument number interface com.google.code.morphia.annotations.Id=(a)com.google.code.morphia.annotations.Id() at java.text.MessageFormat.makeFormat(MessageFormat.java:1339) at java.text.MessageFormat.applyPattern(MessageFormat.java:458) at java.text.MessageFormat.<init>(MessageFormat.java:350) at java.text.MessageFormat.format(MessageFormat.java:811) at org.slf4j.bridge.SLF4JBridgeHandler.getMessageI18N(SLF4JBridgeHandler.java:233) FIX: do not format since there are no parameters! if (params != null && params.length > 0) -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 1

[Bug 218] New: Broken link on website
by bugzilla-daemon＠pixie.qos.ch 21 Sep '12

21 Sep '12

http://bugzilla.slf4j.org/show_bug.cgi?id=218 Summary: Broken link on website Product: SLF4J Version: unspecified Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P1 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: cowwoc(a)bbs.darktech.org The nabble links found at http://www.slf4j.org/mailing-lists.html point to deleted forums. Please recreate the forums. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 1

[Bug 220] New: Cannot build slf4j from source - missing osgi-build.xml
by bugzilla-daemon＠pixie.qos.ch 09 Aug '12

09 Aug '12

http://bugzilla.slf4j.org/show_bug.cgi?id=220 Summary: Cannot build slf4j from source - missing osgi-build.xml Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows XP Status: NEW Severity: blocker Priority: P1 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: dick.jones(a)kinetx.com I tried to build slf4j 1.6.1 from source and the build failed with the following error: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.2:run (ant-osgi-test) on project integration: An Ant BuildException has occured: The following error occurred while executing this line: java.io.FileNotFoundException: C:\Users\dick.jones.KINETX\Downloads\slf4j-1.6.1\integration\osgi-build.xml (The system cannot find the file specified) I emailed Ceki Gulcu who said the file, osgi-build.xml, was inadvertently ommitted and asked that I enter this as a bug. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 1

[Bug 186] New: [patch] Enhanced SimpleLogger implementation
by bugzilla-daemon＠pixie.qos.ch 12 Jun '12

12 Jun '12

http://bugzilla.slf4j.org/show_bug.cgi?id=186 Summary: [patch] Enhanced SimpleLogger implementation Product: SLF4J Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Implementations AssignedTo: slf4j-dev(a)qos.ch ReportedBy: cedrik.lime(a)gmail.com Created an attachment (id=70) --> (http://bugzilla.slf4j.org/attachment.cgi?id=70) New implementation of SimpleLogger I recently had to enhance SimpleLogger by back-porting some functionalities of commons-logging's SimpleLog into it. Namely, I have added the following: * optional configuration file; if none found, you get the exact same set of features as the currently released SimpleLogger. * enable to log more than the info log level * enable to set different log levels for different Loggers * enable to show/hide thread name * very primitive log messages customisation (about the same as commons-logging) Once again, the new code is totally compatible in behaviour and output with the currently released SimpleLogger. I also made it so that current users of commons-logging can upgrade to SLF4J very easily. Finally, I made sure to keep SimpleLogger as simple as possible: we already have fully-fledged logging frameworks, let's not re-invent one! I think this new implementation would enhance the value of SLF4J, while keeping a perfect retro-compatibility with previous versions. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 11