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

[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 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 166] New: please add OSGI informations to jul-to-slf4j-1.5.10.jar
by bugzilla-daemon＠pixie.qos.ch 02 Sep '11

02 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=166 Summary: please add OSGI informations to jul-to-slf4j-1.5.10.jar Product: SLF4J Version: 1.5.x Platform: All OS/Version: Mac OS X 10.3 Status: NEW Severity: normal Priority: P3 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: ekke(a)ekkes-corner.org jul-to-slf4j-1.5.10.jar MANIFEST.MF is missing OSGI Informations ... Import-Package: org.slf4j;version="1.5.10", org.slf4j.spi;version="1.5.10" Export-Package: org.slf4j.bridge;version="1.5.10" ... so you have to wrap it by yourself or as workaround use the Bundle provided by SpringSource: http://www.springsource.com/repository/app/bundle/version/detail?name=com.s… ----- thx ekke -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[Bug 163] New: Copy & paste of LoggerFactory.getLogger
by bugzilla-daemon＠pixie.qos.ch 19 Jul '11

19 Jul '11

http://bugzilla.slf4j.org/show_bug.cgi?id=163 Summary: Copy & paste of LoggerFactory.getLogger Product: SLF4J Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: thomas.tom.mueller(a)gmail.com This is a feature request. Currently, when I create a new logger in a class, I copy & paste the following line from another class: private static Logger log = LoggerFactory.getLogger(AcmeImpl.class); Sometimes I forget to change the class name. SLF4J could help me here. I suggest to add a new method, so the class name is not required, so that I can copy & paste the line without having to remember that I have to change the class name. Also, it's a bit shorter: private static Logger log = LoggerFactory.getCallerClassLogger(); This is copy & paste friendly. The implementation is tricky, but trivial once you understand it: getCallerClassLogger() { return getLogger(new Error().getStackTrace()[1].getClassName()); } There is a project that tries to solve the copy & paste problem: http://code.google.com/p/morbok/ -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 40

[Bug 174] New: Handling of unknown priorities is different ( throwing an IllegalStateException ) than in log4j (defaulting to Priority. DEBUG)
by bugzilla-daemon＠pixie.qos.ch 10 Nov '10

10 Nov '10

http://bugzilla.slf4j.org/show_bug.cgi?id=174 Summary: Handling of unknown priorities is different (throwing an IllegalStateException ) than in log4j (defaulting to Priority.DEBUG) Product: SLF4J Version: 1.5.x Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P1 Component: log4j-over-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: torsten(a)springide.org Log4j silently converts an unknown Priority (given as int value or string) to the default of Priority.DEBUG (see default of switch-case in "Level.toLevel()"). If log4j-over-slf4j gets an unknown instance of Priority for it various "log()" methods then it throws an IllegalStateException (see default of switch-case in "Category.priorityToLevelInt()"): Caused by: java.lang.IllegalStateException: Unknown Priority TRACE at org.apache.log4j.Category.priorityToLevelInt(Category.java:316) at org.apache.log4j.Category.log(Category.java:287) Ok, now you're asking for the actual usecase for someone calling "Category.log()" with an invalid instance of Priority: We have a legacy application which has it's own logging abstraction extending (a very old version of) log4j with it's own log levels. Unluckily, here someone defined a TRACE level with a different value for "Priority.TRACE_INT" than Log4js "Level.TRACE_INT". -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 184] New: Log array contents if only one parameter is specified in log string
by bugzilla-daemon＠pixie.qos.ch 16 Jul '10

16 Jul '10

http://bugzilla.slf4j.org/show_bug.cgi?id=184 Summary: Log array contents if only one parameter is specified in log string Product: SLF4J Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: dumitru.postoronca(a)gmail.com Hello, When using Java5 var-args which are represented as an array, slf4j logs only the first item in the array (which is correct as per documentation, just that it's not very intuitive). Example: void getFilteredData(String... filterValues) { log.debug("Getting data, filtering using the following settings: {}", filterValues); return dao.doSomething(); } What happens is that only the first item is logged, insted of all the items being logged. The current work-around for this is to have the following method call: log.debug(".... {} {}", "", myArray); // note the first empty log parameter I would suggest enhancing the framework to automatically log the array content if only ONE {} parameter is specified in the log string. In this case: log.debug("... {}", myArray); // logs full array content, not only first item log.debug("... {}={}"); // logs as per current algorithm - first two items I believe it is safe to assume that people will use the log.debug(array) method only when they have more than two parameters to show, thus - if only one parameter is used, it's only reasonable that the FULL content of the passed object is logged, no matter the type. Thanks, Dima -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

Release of SLF4J version 1.6.0-RC0
by Ceki Gülcü 13 May '10

13 May '10

Hello all, I am happy to announce the immediate availability of SLF4J version 1.6.0-RC0, which is still experimental, consisting of several important enhancements and bug fixes. As of 1.6.0-RC0, in the absence of an SLF4J binding, slf4j-api will default to a no-operation implementation discarding all log requests. Thus, instead of throwing an exception, SLF4J will emit a single warning message about the absence of a binding and proceed to discard all log requests without further protest. Please refer to the the news page for precise details. http://www.slf4j.org/news.html You can download SLF4J, including full source code, class files and documentation on our download page, shown below. http://www.slf4j.org/download.html You can receive SLF4J related announcements by subscribing to the SLF4J announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://qos.ch/mailman/listinfo/announce -- Ceki Gülcü Logback: The reliable, fast and flexible logging framework for Java. http://logback.qos.ch

5 44

[Bug 183] New: Sign Slf4j artifacts.
by bugzilla-daemon＠pixie.qos.ch 13 May '10

13 May '10

http://bugzilla.slf4j.org/show_bug.cgi?id=183 Summary: Sign Slf4j artifacts. Product: SLF4J Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P3 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: elisha.ebenezer(a)gmail.com Following discussion with Ceki on user-list. I'm raising Issue request for signing slf4j artifacts. i.e. slf4j-api and it's implementations (logback) -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

Simple log admin facade?
by Jason Dillon 12 May '10

12 May '10

Is there any simple log admin facade api out there? Often apps expose a simple way to set logger levels or list what the current levels are. Does anything like that exist already for use with slf4j components? --jason

2 1

Release of SLF4J version 1.6.0
by Ceki Gülcü 08 May '10

08 May '10

Hello all, I am happy to announce the immediate availability of SLF4J version 1.6.0 consisting of several important enhancements and bug fixes. In the 1.6.x series, in the absence of an SLF4J binding, slf4j-api will default to a no-operation implementation discarding all log requests. Thus, instead of throwing an exception, SLF4J will emit a single warning message about the absence of a binding and proceed to discard all log requests without further protest. Please refer to the the news page for precise details. http://www.slf4j.org/news.html You can download SLF4J, including full source code, class files and documentation on our download page, shown below. http://www.slf4j.org/download.html You can receive SLF4J related announcements by subscribing to the SLF4J announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://qos.ch/mailman/listinfo/announce -- Ceki Gülcü Logback: The reliable, fast and flexible logging framework for Java. http://logback.qos.ch

1 0