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

[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 219] New: Typo in error message
by bugzilla-daemon＠pixie.qos.ch 19 Apr '12

19 Apr '12

http://bugzilla.slf4j.org/show_bug.cgi?id=219 Summary: Typo in error message Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows NT Status: NEW Severity: blocker Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: cowwoc(a)bbs.darktech.org Replace "becasue" with "because" across the slf4j code-base. I got this specific error message: SLF4J: The following loggers will not work becasue they were created SLF4J: during the default configuration phase of the underlying logging system. SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger -- 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 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 225] New: log4j-over-slf4j Compatibility Enhancements: PropertyConfigurator, DOMConfigurator, NDC.
by bugzilla-daemon＠pixie.qos.ch 07 Jul '11

07 Jul '11

http://bugzilla.slf4j.org/show_bug.cgi?id=225 Summary: log4j-over-slf4j Compatibility Enhancements: PropertyConfigurator, DOMConfigurator, NDC. Product: SLF4J Version: 1.6.x Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P1 Component: log4j-over-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: jmsteward(a)gmail.com I'm currently developing a new project for my employer and recently made the decision to replace log4j with slf4j & logback. However as close as I came to completing this replacement I have finally come to terms with its impracticability and will need to unfortunately undo my changes & revert to log4j. The reason is because we have a number of first-party reusable "component" libraries that have been around for a decade or so. My new project, like many many of our other projects, require some parts of these legacy components. Because of the sheer number of scattered projects dependent on these components I am absolutely unable to alter any of their code. So I setup my new project with slf4j-api-1.6.1.jar, slf4j-ext-1.6.1.jar, logback-classic-0.9.29.jar & logback-core-0.9.29.jar, and I setup the legacy components to use log4j-over-slf4j-1.6.1.jar, slf4j-api-1.6.1.jar & slf4j-ext-1.6.1.jar. PropertyConfigurator Issue: A class used by many other projects for universal logging configuration exists in one of these component libraries and it uses org.apache.log4j.PropertyConfigurator. Although my project does not use the aforementioned class, it does require other classes from the library in question. Per reading through slf4j documentation I understand PropertyConfigurator is intended not to be supported. I understand the decision not to support its functionality but it doesn't make much sense to me that it should prevent code from compiling. I just need to be able to compile this code using log4j-over-slf4j, whether or not PropertyConfigurator is fully functional is a non-issue as my project does not use it, though other projects do use it and log4j will likely indefinitely remain in their classpaths'. So I propose a "bare bones" class be created at org.apache.log4j.PropertyConfigurator within log4j-over-slf4j. While it doesn't affect me I think it makes sense for org.apache.log4j.xml.DOMConfigurator too. Although I do see that org.apache.log4j.xml.DOMConfigurator does exist in the slf4j repository. Is that a sign this is being addressed? NDC Issue: This is a similar issue, where NDC is used within a legacy component, but my project also relies on that legacy usage of NDC for its contents to ultimately be apart of the log's pattern. This is subsequently used for reporting purposes. I came across the bug, that I can now not locate, where org.slf4j.NDC was added to slf4j-ext built atop org.slf4j.MDC with some basic functionality. NDC compiled fine using log4j-over-slf4j so I thought I was in the clear. I went ahead and wrote a class extending ClassicConverter that emulates log4j's NDC pattern so my new project that was using logback could output the NDC contents that the legacy component was controlling through org.apache.log4j.NDC. Nothing outputted to my log from the NDC pattern. I determined my NdcConverter class, conversion rule, and pattern were all correct. The break is between log4j-over-slf4j's org.apache.log4j.NDC and slf4j-ext's org.slf4j.NDC. org.apache.log4j.NDC is purely "bare bones" with all the methods but nothing within them. It doesn't make sense NDC, also seemingly unofficially supported by slf4j, has functionality in slf4j-ext but not the legacy bridge log4j-over-slf4j. This should be resolved in a similar manner as log4j-over-slf4j's org.apache.log4j.MDC and slf4j-api's org.slf4j.MDC where the former's methods call the latter's methods. Or would it be better design for the org.apache.log4j classes (MDC & NDC) to extend their org.slf4j countparts? I found Bug 170 that dismisses this NDC idea due to ... "This would require a slf4j-ext dependency in log4j-over-slf4j. Because of that, log4j-over-slf4j would then require Java>=1.5." ... Has a log4j-over-slf4j-ext component been considered? Perhaps you could migrate the loosely supported items to such a component; e.g. org.apache.log4j.NDC, org.apache.log4j.PropertyConfigurator & org.apache.log4j.xml.DOMConfigurator. While I'm designing things to be portable and allow for our legacy libraries to be purged and switched out with brand new code, it is not a possibility any time soon. I require those libraries to get other more crucial parts of the project into production. So slf4j is not an option for me despite my preference for it. These scenarios are not unique to me and I hope slf4j addresses them so it can become a more realistic option for those transitioning out of legacy code bases. Happy trails. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 9

[Bug 224] New: BasicMDCAdapter.getCopyOfContextMap can lead to ConcurrentModificationException
by bugzilla-daemon＠pixie.qos.ch 07 Jul '11

07 Jul '11

http://bugzilla.slf4j.org/show_bug.cgi?id=224 Summary: BasicMDCAdapter.getCopyOfContextMap can lead to ConcurrentModificationException Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: alex.boisvert(a)gmail.com As illustrated by this stacktrace, java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$EntryIterator.next(HashMap.java:834) at java.util.HashMap$EntryIterator.next(HashMap.java:832) at java.util.HashMap.putAllForCreate(HashMap.java:435) at java.util.HashMap.<init>(HashMap.java:225) at org.slf4j.helpers.BasicMDCAdapter.getCopyOfContextMap(BasicMDCAdapter.java:130) at org.slf4j.MDC.getCopyOfContextMap(MDC.java:176) at com.bizo.logging.SmtpHandler.publish(SmtpHandler.java:65) at java.util.logging.Logger.log(Logger.java:458) at java.util.logging.Logger.doLog(Logger.java:480) at java.util.logging.Logger.log(Logger.java:503) at java.util.logging.Logger.info(Logger.java:1022) it appears that if BasicMDCAdapter.getCopyOfContextMap() is called while the parent thread is mutating the context, a ConcurrentModificationException can be thrown. -- 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 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 27 Jun '11

27 Jun '11

http://bugzilla.slf4j.org/show_bug.cgi?id=31 Daniel Trebbien <dtrebbien(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtrebbien(a)gmail.com -- 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

[Bug 226] New: The requested version 1.6 by your slf4j binding is not compatible with [1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.5.11]
by bugzilla-daemon＠pixie.qos.ch 24 Jun '11

24 Jun '11

http://bugzilla.slf4j.org/show_bug.cgi?id=226 Summary: The requested version 1.6 by your slf4j binding is not compatible with [1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.5.11] Product: SLF4J Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: critical Priority: P1 Component: jul-to-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: paramesh.korrakuti(a)sc.com Hi, I am using the below jars in my project: jcl-over-slf4j-1.6.1.jar jul-to-slf4j-1.6.1.jar log4j-over-slf4j-1.6.1.jar slf4j-api-1.6.1.jar slf4j-jcl-1.6.1.jar slf4j-jdk14-1.6.1.jar slf4j-log4j12-1.6.1.jar slf4j-nop-1.6.1.jar and getting the below probelm. Please Can any one help me to resolve this problem.. Error Log: SLF4J: Found binding in [jar:file:/C:/PARAMESH/NFS_Workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/NFS_SO_UAE/WEB-INF/lib/logback-classic-0.9.28.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/C:/PARAMESH/NFS_Workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/NFS_SO_UAE/WEB-INF/lib/slf4j-jcl-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/C:/PARAMESH/NFS_Workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/NFS_SO_UAE/WEB-INF/lib/slf4j-jdk14-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/C:/PARAMESH/NFS_Workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/NFS_SO_UAE/WEB-INF/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/C:/PARAMESH/NFS_Workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/NFS_SO_UAE/WEB-INF/lib/slf4j-nop-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/C:/PARAMESH/NFS_Workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/NFS_SO_UAE/WEB-INF/lib/slf4j-simple-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) Caused by: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V at org.apache.commons.logging.impl.SLF4JLocationAwareLog.debug(SLF4JLocationAwareLog.java:133) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:314) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4302) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4139) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) ... 6 more -- 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 223] New: Race-conditions initializing LoggerFactory
by bugzilla-daemon＠pixie.qos.ch 19 Jun '11

19 Jun '11

http://bugzilla.slf4j.org/show_bug.cgi?id=223 Summary: Race-conditions initializing LoggerFactory Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows NT Status: NEW Severity: critical Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: cowwoc(a)bbs.darktech.org 1. Given: public class MyTest { private final Logger log = LoggerFactory.getLogger(MyTest.class); @Test public void firstMethod() {...} @Test public void secondMethod() {...} //etc } 2. Run the unit test through Surefire 2.8.1 or newer (I am using 2.8.2-SNAPSHOT) with <parallel>methods</parallel> and JUnit 4.8.2 3. slf4j will issue the following warning: SLF4J: The following loggers will not work because they were created SLF4J: during the default configuration phase of the underlying logging system. SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger 4. MyTest is instantiated multiple times simultaneously, each time invoking LoggerFactory.getLogger(). 5. The first call begins invoking performInitialization(). The subsequent calls return TEMP_FACTORY. As a result, the unit tests run with a misconfigured logger. Expected behavior: The first thread should run performInitialization() while subsequent threads block waiting for initialization to complete. I believe you can do this (and still allow re-entrant behavior) by using a "synchronized (LoggerFactory.class)" block. Workaround: Insert the following method once per class file: @BeforeClass public static void initSlf4j() { // Configure slf4j in a thread-safe manner, otherwise we get: // // SLF4J: The following loggers will not work because they were created // SLF4J: during the default configuration phase of the underlying logging system. // SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger LoggerFactory.getILoggerFactory(); } Though I don't think this workaround will work for <parallel>class</parallel> or <parallel>both</parallel>. -- 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

[GIT] SLF4J: Simple Logging Facade for Java branch, master, updated. v_1.6.1-34-gd9e7175
by git-noreply＠pixie.qos.ch 16 Jun '11

16 Jun '11

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 d9e7175fb77832e2366a5755995bb14399f015fa (commit) via d380a0953e126827e9efbbb501a7352b17bb21f2 (commit) from ebf05781718598adebd1e8fc058f459891002682 (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=d9e7175fb77832e2366a575599… http://github.com/ceki/slf4j/commit/d9e7175fb77832e2366a5755995bb14399f015fa commit d9e7175fb77832e2366a5755995bb14399f015fa Merge: d380a09 ebf0578 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Jun 16 11:22:26 2011 +0200 Merge branch 'master' of git.qos.ch:slf4j http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=d380a0953e126827e9efbbb501… http://github.com/ceki/slf4j/commit/d380a0953e126827e9efbbb501a7352b17bb21f2 commit d380a0953e126827e9efbbb501a7352b17bb21f2 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Jun 16 11:22:09 2011 +0200 precision regarding logback diff --git a/slf4j-site/src/site/pages/faq.html b/slf4j-site/src/site/pages/faq.html index 155f4df..ecd5d48 100644 --- a/slf4j-site/src/site/pages/faq.html +++ b/slf4j-site/src/site/pages/faq.html @@ -194,12 +194,13 @@ <dd> <p>In short, libraries and other embedded components should - consider SLF4J for their logging needs because libraries - cannot afford to impose their choice of logging system on the - end-user. On the other hand, it does not necessarily make - sense for stand-alone applications to use SLF4J. Stand-alone - applications can invoke the logging system of their choice - directly. + consider SLF4J for their logging needs because libraries cannot + afford to impose their choice of logging framework on the + end-user. On the other hand, it does not necessarily make sense + for stand-alone applications to use SLF4J. Stand-alone + applications can invoke the logging framework of their choice + directly. In the case of logback, the question is moot because + logback exposes its logger API via SLF4J. </p> <p>SLF4J is only a facade, meaning that it does not provide a ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/faq.html | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0