August 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. * * * 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 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 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 191] New: Implement java.util.logging.LogManager for jul-to-slf4j
by bugzilla-daemon＠pixie.qos.ch 13 Oct '10

13 Oct '10

http://bugzilla.slf4j.org/show_bug.cgi?id=191 Summary: Implement java.util.logging.LogManager for jul-to-slf4j Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows NT Status: NEW Severity: blocker Priority: P1 Component: jul-to-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: bryan(a)vancameron.net SLF4J implements a single Logger for J.U.L. that redirects log statements to SLF4J. This has significant performance implications as every log statement is processedby J.U.L. so it can then be forwarded to SLF4J. To avoid this, SLF4J should implement java.util.logging.LogManager and register this with J.U.L. to handle log statements. This is how application servers are able to implement their own logging system using the J.U.L. API without performance penalty. So, for example, there would be an org.slf4j.jul.LogManager implementation of java.util.logging.LogManager. This would then be registered with J.U.L. using the system property "java.util.logging.manager". -- 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

slf4j on the google android platform
by Darrin Edelman 31 Aug '10

31 Aug '10

Hello all - I did get slf4j-android working after going through the list here by grabbing the source code and patching it myself but I'm wondering if progress has been made on the issues below so that I can adopt a more official release? Thanks in advance, -Darrin >> >> I've run into a couple frustrating issues with slf4j-android >> that you're no doubt aware of as it seems that some work has occurred >> here: >> >> 1) http://bugzilla.slf4j.org/show_bug.cgi?id=173 >> >> Given that I'm dealing with a cross-platform library with lots of >> existing code the '23 character' android limit is a showstopper for >> me. I cannot change all the library code to use 'simplename' for >> example. Granted I see this as really an issue with Android - but >> still we should be able to handle this in the android port. This >> means that I cannot just handle it in the android specific portions >> of the code - the already written libraries have to properly deal >> with this issue by cropping the name of the logger - so that the >> library functions don't throw exceptions. This to me means that I >> need to change the StaticLoggerBinder to instantiate a version of >> code that knows how to deal with this issue properly even when the >> client code isn't aware of it. Wendel's solution in the above thread >> seems a reasonable solution. >> >> 2) Availability of android source-code from repo. >> >> Given that this is an for me issue I'd like to put the fix in that wendell >> suggest... use as much of the useful name as possible and hopefully >> Android comes around and fixes this limitation someday. I grabbed >> the codebase from git and I couldn't find references to the android >> branch. Specifically it seems like wendell's fix is a decent >> work-around for the android limitation. Unfortunately I cannot >> easily do this and contribute any branches back to the open source >> community because I cannot seem to find android code in this branch. Now >> this said - I did find the slf4j-android code base on the website so I can move >> forward... but why isn't this in Git?? >> >> 3) Really just a picky thing... slf4j-android does not appear to be >> available from any publicly accessible maven repository. >> >> I've resolved this by adding the jar to my project and automatically >> deploying it to the local repo - but this really isn't a very >> elegant solution. Any chance the android version is going to be made >> available anytime soon? I'd rather not package the jar as a build >> artifact. >

3 13

[GIT] SLF4J: Simple Logging Facade for Java branch, master, updated. v_1.6.1-3-gf31b487
by git-noreply＠pixie.qos.ch 27 Aug '10

27 Aug '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "SLF4J: Simple Logging Facade for Java". The branch, master has been updated via f31b487e0c856acf348b0c08a80b33326a98ca64 (commit) from 5ea054beea36b4a2d6e9fb58d0e2f877b9ab1608 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=f31b487e0c856acf348b0c08a8… http://github.com/ceki/slf4j/commit/f31b487e0c856acf348b0c08a80b33326a98ca64 commit f31b487e0c856acf348b0c08a80b33326a98ca64 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Aug 27 23:50:24 2010 +0200 typo fix diff --git a/slf4j-site/src/site/pages/manual.html b/slf4j-site/src/site/pages/manual.html index 0c79c40..cb1f9c8 100644 --- a/slf4j-site/src/site/pages/manual.html +++ b/slf4j-site/src/site/pages/manual.html @@ -164,7 +164,7 @@ public class HelloWorld { SLF4J does not rely on any special class loader machinery. In fact, the each SLF4J binding is hardwired at compile time to use one and only one specific logging framework. - For example, the slf4j-log12-${project.version}.jar binding is + For example, the slf4j-log4j12-${project.version}.jar binding is bound at compile time to use log4j. In your code, in addition to slf4j-api-${project.version}.jar, you simply drop one and only one binding of your choice onto the ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/manual.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0