November 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 241] New: LoggerWrapper doesn't fully support Bug 70
by bugzilla-daemon＠pixie.qos.ch 12 Nov '14

12 Nov '14

http://bugzilla.slf4j.org/show_bug.cgi?id=241 Summary: LoggerWrapper doesn't fully support Bug 70 Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Mac OS X 10.3 Status: NEW Severity: blocker Priority: P1 Component: slf4j-ext AssignedTo: slf4j-dev(a)qos.ch ReportedBy: git(a)netcc.us Most methods in LoggerWrapper don't forward Throwables to the wrapped Logger per bug 70. Patch available at https://github.com/ceki/slf4j/pull/7 -- 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 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 239] New: performance issue in MessageFormatter
by bugzilla-daemon＠pixie.qos.ch 09 Jun '13

09 Jun '13

http://bugzilla.slf4j.org/show_bug.cgi?id=239 Summary: performance issue in MessageFormatter Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: kite668(a)mail.ru 1. org.slf4j.helpers.MessageFormatter.arrayFormat uses localy thread-safe StringBuffer instead of StringBuilder. I think it can be safely replaced. 2. "deeplyAppendParameter(sbuf, argArray[L], new HashMap());" - this is called for EVERY argument, even if it isn't array. I think instance of HashMap shouldn't be created for every argument. You can pass null and initialize HashMap in deeplyAppendParameter only for object's arrays and if it's previous value is null. Also you can initialize this map with initial capacity = array's size. 3. It will be very good if method arrayFormat would receive StringBuilder instead of creating instance of result String. This is common and more fast solution. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 3

[Bug 227] New: org.apache.log4j.Layout mistakenly in org.apache.log4j.spi
by bugzilla-daemon＠pixie.qos.ch 07 Jun '13

07 Jun '13

http://bugzilla.slf4j.org/show_bug.cgi?id=227 Summary: org.apache.log4j.Layout mistakenly in org.apache.log4j.spi Product: SLF4J Version: 1.6.x Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P1 Component: log4j-over-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: jmsteward(a)gmail.com This may block development that should reference org.apache.log4j.Layout. Currently in the log4j-over-slf4j component Layout mistakenly exists at org.apache.log4j.spi and should be moved to org.apache.log4j. org.apache.log4j.Appender will need refactoring to remove the line "import org.apache.log4j.spi.Layout;". -- 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