January 2013 - slf4j-dev - mailman3.qos.ch

[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 285] New: Misc slf4j-simple fixes and enhancements
by bugzilla-daemon＠qos.ch 18 Mar '13

18 Mar '13

http://bugzilla.slf4j.org/show_bug.cgi?id=285 Summary: Misc slf4j-simple fixes and enhancements Product: SLF4J Version: 1.6.x Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Implementations AssignedTo: slf4j-dev(a)qos.ch ReportedBy: cedrik.lime(a)gmail.com (Note: version should be 1.7.x, which is unavailable in Bugzilla) Recent 1.7.x versions of SLF4J inadvertently broke the ability to turn off a given logger (in SimpleLogger module). This following pull request fixes this, as well as the following minor points: Bug fixes ========= * regression: restore ability to completely turn off logging for a given logger (level "off") * bug fix: force output file (if any) to UTF-8 to avoid platform-dependent surprises while logging to a file Enhancements ============ * Java 5 syntax (less Eclipse warnings) * update documentation (including example simplelogger.properties file which was out of sync with recent 1.7.[1-2] changes) * add SimpleLoggerAccess class to enable to change SimpleLogger logger levels at runtime (used e.g. in a monitoring utility) You will find all of those in pull request 28: https://github.com/qos-ch/slf4j/pull/28 Thanks! -- 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

[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

[Bug 236] New: Use standard java.util.ServiceLoader for SLF4J Binding
by bugzilla-daemon＠pixie.qos.ch 25 Feb '13

25 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=236 Summary: Use standard java.util.ServiceLoader for SLF4J Binding Product: SLF4J Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: cronier.jy(a)gmail.com What about use ServiceLoader to find which binding to use? For JDK<1.6 compatibility, we can test Class.forName("java.util.ServiceLoader") and switch to an internal equivalent implementation of ServiceLoader. No need to have one (or multiple) StaticLoggerBinder. This ServiceLoader is used, for example, for JRE XSL implementation, or java.sql.Driver. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 10

"Metadata Advice"
by Martin Ellis 24 Jan '13

24 Jan '13

Hi Ceki and others, I thought you might be interested to know about "Metadata Advice": it's an outreach project by folk involved in the OSGi community, who are willing to offer advice to people trying to package their software so it behaves well in an OSGi environment. http://blog.osgi.org/2013/01/get-help-adding-osgi-metadata-to-your.html Since there's been talk on this list of problems due to cyclic dependencies between slf4j-api and the logging implementations, I thought I'd point it out. Although it's called "Metadata Advice", I think they're willing to offer some suggestions for other aspects of using OSGi, beyond simply adding manifest headers (which slf4j already has). Perhaps it's worth creating an issue on their bugzilla inviting suggestions for improving OSGi support in slf4j? Regards, Martin

2 2

[Bug 290] New: StaticLoggerBinder shold not swallow Errors
by bugzilla-daemon＠qos.ch 24 Jan '13

24 Jan '13

http://bugzilla.slf4j.org/show_bug.cgi?id=290 Summary: StaticLoggerBinder shold not swallow Errors Product: SLF4J Version: 1.7.x Platform: PC OS/Version: Linux Status: NEW Severity: blocker Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: david(a)davidkarlsen.com I'm creating a custom Logback StatusListener which raises java.lang.Errors in case of severe logging issues (e.g. IOErrors) so that I can disable normal operation of my application in these situations. This works fine when I get an IOError after the application has started to run and loggers are bound (for instance when a filesystem becomes full). HOWEVER - it would not work for a non-writable file as slf4j/logback initializes, due to StaticLoggerBinders init() behaviour, which catches Throwable and simply logs this: void init() { try { try { new ContextInitializer(defaultLoggerContext).autoConfig(); } catch (JoranException je) { Util.report("Failed to auto configure default logger context", je); } StatusPrinter.printInCaseOfErrorsOrWarnings(defaultLoggerContext); contextSelectorBinder.init(defaultLoggerContext, KEY); initialized = true; } catch (Throwable t) { // we should never get here Util.report("Failed to instantiate [" + LoggerContext.class.getName() + "]", t); } } I think this should be changed to a catch ( Exception ) as it's not good behaviour to catch Errors (and certainly not when not rethrowing them). Alternatively keep the catch block as today, but if t instanceof Error rethrow the Error. using slf4j-api 1.7.2 and logback 1.0.9 -- 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

Why doesn't log4j-over-slf4j have a method for Category.setLevel?
by Dan Kaplan 10 Jan '13

10 Jan '13

Log4j-1.2.9.jar has a Category.setLevel(org.apache.log4j.Level level) method, but log4j-over-slf4j doesn't and this is causing an AbstractMethodError when I try to use a library that uses log4j. Is there any particular reason this method wasn't implemented, or is this a bug? Thanks

1 0