June 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 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

[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

[Bug 189] New: 1.6.0: There is no site/ apidocs directory in the distribution zip file.
by bugzilla-daemon＠pixie.qos.ch 05 Jul '10

05 Jul '10

http://bugzilla.slf4j.org/show_bug.cgi?id=189 Summary: 1.6.0: There is no site/apidocs directory in the distribution zip file. Product: SLF4J Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: major Priority: P1 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: alex-pub.slf4j(a)reflexion.net slf4j-1.6.0.zip from the distribution directory does not contain 'site/apidocs' directory. The previous stable distribution sfl4j-1.5.8.zip contains this directory. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 6

Re: [slf4j-dev] Context for getLogger()
by Fred 02 Jul '10

02 Jul '10

I have been modifying slf4j for use on android. Beginning with the slf4j-android sub-project, I am adding in a context provider to record, forward, combine, filter and otherwise manage the log. In order to do this getLogger needs to know the current context. To work around this I have added a context parameter. e.g. import android.content.Context; import android.graphics.Matrix; import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class Sample implements Cloneable { private Sample(Context context) { _log = LoggerFactory.getLogger(Sample.class, context); ... I can provide more detail if this is not clear. What I want to know is if this is the best way do deal with the problem? In order to get this to work I have added some android specific stuff to the api/contract. The presumption seems to be that certain information is in some global variable. This doesn't seem quite right. What I am wondering is if there shouldn't be some generalization of context for slf4j. The specific implementation would change it as needed. What do you think?

2 4

[Bug 188] New: There is no 1.6.x version in a dropdown list.
by bugzilla-daemon＠pixie.qos.ch 30 Jun '10

30 Jun '10

http://bugzilla.slf4j.org/show_bug.cgi?id=188 Summary: There is no 1.6.x version in a dropdown list. Product: SLF4J Version: 1.5.x Platform: PC OS/Version: Windows XP Status: NEW Severity: blocker Priority: P1 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: alex-pub.slf4j(a)reflexion.net Summary says it all. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1