- slf4j-dev - mailman3.qos.ch

[Bug 133] Add ability to log at a dynamic level
by bugzilla-daemon＠qos.ch 08 Feb '13

08 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=133 --- Comment #8 from Matthew Hall <mhall(a)mhcomputing.net> 2013-02-08 04:01:55 CET --- Yes, that's what I'm praying for, an enum! :) -- 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 133] Add ability to log at a dynamic level
by bugzilla-daemon＠qos.ch 07 Feb '13

07 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=133 Joern Huxhorn <joern(a)huxhorn.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joern(a)huxhorn.de --- Comment #7 from Joern Huxhorn <joern(a)huxhorn.de> 2013-02-07 20:19:25 CET --- Just wanted to add that we have similar points in our application where subsystems are logging in their own way (e.g. an XSLT processor) and need to be mapped into SLF4J. That feature would come in quite handy. Given that SLF4J is now requiring Java 5 we could/should even use an Enum as LogLevel. -- 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 133] Add ability to log at a dynamic level
by bugzilla-daemon＠qos.ch 06 Feb '13

06 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=133 Matthew Hall <mhall(a)mhcomputing.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mhall(a)mhcomputing.net --- Comment #6 from Matthew Hall <mhall(a)mhcomputing.net> 2013-02-06 04:46:53 CET --- Hello gentlemen, I have a MUCH simpler use case for this feature that is important in an application and not just in libraries. I have many cases where I am writing code which performs security validation of input data. 99% of the time the messages coming in will be valid, thus boring, and should be logged at a very low level such as TRACE so you can enable viewing them in the production code to see what's being validated in case there is a problem somewhere. But 1% of the time you find something bad in the input, because some hacker or user has tried entering something crazy to find an exploit. It would be very nice if the exact same message can be logged as before, but at a lot higher severity so you know that something bad happened, without having duplicated calls for everything which could be good or could be bad at runtime, which is silly. Example of how I've done this before in many lines of code I've written using JDK and Log4J instead of SLF4J. boolean isOk = isXFieldValid && isYFieldValid && isZFieldValid; log.dynamic(isOk? TRACE : WARN, "isXFieldValid {} isYFieldValid {} isZFieldValid", isXFieldValid, isYFieldValid, isZFieldValid); Could we please reconsider this and think of a good solution? Thanks, Matthew. -- 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

"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

[Bug 287] New: Beautification of error message in Logger.createChildByName()
by bugzilla-daemon＠qos.ch 20 Dec '12

20 Dec '12

http://bugzilla.slf4j.org/show_bug.cgi?id=287 Summary: Beautification of error message in Logger.createChildByName() Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Linux Status: NEW Severity: minor Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: d.tonhofer(a)m-plify.com Currently the following text is generated: throw new IllegalArgumentException("For logger [" + this.name + "] child name [" + childName + " passed as parameter, may not include '.' after index" + (this.name.length() + 1)); This is missing a ] and a " ", (I also would replace "index" by "position" and use CoreConstants.DOT) thus: throw new IllegalArgumentException("For logger [" + this.name + "], child name [" + childName + "] passed as parameter may not include the dot separator '" + CoreConstants.DOT + "' after position " + (this.name.length() + 1)); -- 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 288] New: Problematic logger name splitting via Logger.getSeparatorIndexOf()
by bugzilla-daemon＠qos.ch 20 Dec '12

20 Dec '12

http://bugzilla.slf4j.org/show_bug.cgi?id=288 Summary: Problematic logger name splitting via Logger.getSeparatorIndexOf() 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: d.tonhofer(a)m-plify.com In the Logger class, the method getSeparatorIndexOf() is used to separate off child logger names (basically, to do String.split() on "name"). It looks for the occurrence of DOT or DOLLAR: --------------- static int getSeparatorIndexOf(String name, int fromIndex) { int i = name.indexOf(CoreConstants.DOT, fromIndex); if (i != -1) { return i; } else { return name.indexOf(CoreConstants.DOLLAR, fromIndex); } } --------------- LoggerContext.getLogger() uses the above to split a passed "name" String. The logic, however is peculiar. getSeparatorIndexOf() splits a String along the DOT. Unless that is impossible, in which case it splits it along the DOLLAR. Unfortunately, LoggerContext.getLogger() may then behave surprisingly The name "A.B.C$D" will give the Logger chain A -> A.B -> A.B.C -> A.B.C.D as expected The name "A.B$C.D" could give the Logger chain A -> A.B -> A.B.C -> A.B.C.D but construction will fail! Because: Decomposition via getSeparatorIndexOf() will yield A , B$C , D But construction of a Logger in LoggerContext.getLogger() named "B$C" will fail because that method checks whether decomposition is still possible; given "B$C" it will indeed find that decomposition is still possible, along the $ sign. It will thus throw. The problem occurs in case of Logger names like: "com.mplify.msgserver.ReceiverStickyPersistentStore$ReceiverStickyUpdateTransactionCallback.<clinit>" This was an acceptable name in 1.6 but causes an exception in 1.7.4 Splitting should probably be done with a modified function: static int getSeparatorIndexOf(String name, int fromIndex) { int i = name.indexOf(CoreConstants.DOT, fromIndex); int j = name.indexOf(CoreConstants.DOLLAR, fromIndex); if (i < 0) { return j; } else if (j < 0) { return i; } else { return (i < j) ? i : j; } } which splits along DOT and DOLLAR. Problem here: Properly recompositing the name from the logger chain will demand that one stores whether the preceding separator was DOT or DOLLAR. And are the names "A.B$C" and "A$B.C" actually equivalent? P.S. : Another problem: What about "A..B"? Should Logger.createChildByName(final String childName) not check that is not passed the empty string? Currently it does not. -- 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

[qos-ch/slf4j] 8be3de: typo fix
by Ceki Gulcu 16 Dec '12

16 Dec '12

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 8be3de03609c6d19f2d5296311aeb1dde3a4f910 https://github.com/qos-ch/slf4j/commit/8be3de03609c6d19f2d5296311aeb1dde3a4… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2012-12-16 (Sun, 16 Dec 2012) Changed paths: M slf4j-site/src/site/pages/manual.html Log Message: ----------- typo fix

1 0

[GIT] SLF4J: Simple Logging Facade for Java branch master updated. v_1.7.2-4-g8be3de0
by git-noreply＠pixie.qos.ch 16 Dec '12

16 Dec '12

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 8be3de03609c6d19f2d5296311aeb1dde3a4f910 (commit) from 30f8bf465e61bc127a14adc39243a9db52624ae2 (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=8be3de03609c6d19f2d5296311… http://github.com/ceki/slf4j/commit/8be3de03609c6d19f2d5296311aeb1dde3a4f910 commit 8be3de03609c6d19f2d5296311aeb1dde3a4f910 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sun Dec 16 22:47:44 2012 +0100 typo fix diff --git a/slf4j-site/src/site/pages/manual.html b/slf4j-site/src/site/pages/manual.html index 490bdb9..03c0888 100644 --- a/slf4j-site/src/site/pages/manual.html +++ b/slf4j-site/src/site/pages/manual.html @@ -45,7 +45,7 @@ <code>Object[]</code>. Thus, the Logger interface generated by the compiler is indistinguishable in 1.7.0 from its 1.6.0 counterpart. It follows that SLF4J version 1.7.0 is totally 100% - no-ifs-or-buts compatible with SLF4J version 1.6.x.q + no-ifs-or-buts compatible with SLF4J version 1.6.x. </p> <h3 class="doAnchor" name="hello_world">Hello World</h3> ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/manual.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0