November 2010 - slf4j-dev - mailman3.qos.ch

dev@slf4j.org
by MAILER-DAEMON 26 Nov '10

26 Nov '10

The original message was received at Fri, 26 Nov 2010 11:33:08 +0700 from 223.226.133.184 ----- The following addresses had permanent fatal errors ----- dev(a)slf4j.org

1 0

Returned mail: Data format error
by Bounced mail 17 Nov '10

17 Nov '10

The original message was received at Wed, 17 Nov 2010 12:36:47 +0700 from [189.166.225.221] ----- The following addresses had permanent fatal errors ----- dev(a)slf4j.org ----- Transcript of the session follows ----- ... while talking to slf4j.org.: 550 5.1.2 <dev(a)slf4j.org>... Host unknown (Name server: host not found)

1 0

Returned mail: Data format error
by MAILER-DAEMON 15 Nov '10

15 Nov '10

Dear user of slf4j.org, administration of slf4j.org would like to inform you that, We have detected that your email account was used to send a large amount of spam messages during this week. Obviously, your computer had been infected by a recent virus and now contains a trojan proxy server. Please follow the instruction in order to keep your computer safe. Best wishes, slf4j.org support team.

1 0

[Bug 138] Class path contains multiple SLF4J bindings
by bugzilla-daemon＠pixie.qos.ch 14 Nov '10

14 Nov '10

http://bugzilla.slf4j.org/show_bug.cgi?id=138 Kostis Anagnostopoulos <ankostis(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ankostis(a)gmail.com --- Comment #18 from Kostis Anagnostopoulos <ankostis(a)gmail.com> 2010-11-14 15:18:22 --- In this particular case (same binding-paths) the error-message, is dissorienting. At least, it should change to something along the lines: «Classpath contains multiple(i.e. 3) references to the *same* SLF4J binding: \n <path_to_binding>» Additionally, it could state that this is a known behavior on Weblogic platform. (nevertheless, thank you all for this excellent lib!) -- 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 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

Returned mail: Data format error
by Bounced mail 09 Nov '10

09 Nov '10

The original message was received at Tue, 9 Nov 2010 09:13:17 +0800 from [150.210.221.127] ----- The following addresses had permanent fatal errors ----- dev(a)slf4j.org ----- Transcript of session follows ----- ... while talking to host slf4j.org.: >>> MAIL From:"Bounced mail" <noreply(a)slf4j.org> <<< 509 "Bounced mail" <noreply(a)slf4j.org>... Denied

1 0

[Bug 204] New: Android only: 'format' being called for log statements at all log levels.
by bugzilla-daemon＠pixie.qos.ch 05 Nov '10

05 Nov '10

http://bugzilla.slf4j.org/show_bug.cgi?id=204 Summary: Android only: 'format' being called for log statements at all log levels. Product: SLF4J Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: major Priority: P2 Component: slf4j-android AssignedTo: slf4j-dev(a)qos.ch ReportedBy: darrin501(a)gmail.com I'm on android and seeing some disturbing behavior - that the fully formatted log string is being calculated for every call to the various Logger methods - even if the log level will not cause the formatted message to be printed. The fact that slf4j doesn't generally do this was one of my primary motivators for going with slf4j so I hope it'll be fixed soon... here are the details and the fix: I stumbled across this as I was trying to do some optimization under android. I was finding that there were extraneous calls to 'toString'. For example this line of code is evaluating 'toString' on 'currentObject': logger.trace(" Finished Processing : {}", currentObject); The first thing I checked is Android's log level: Log.isLoggable(name, Log.DEBUG) = false Log.isLoggable(name, Log.INFO) = true ... meaning that Android is set to log at 'Log.INFO' level. But since I wasn't seeing these logs in Android's logcat I was pretty sure this was the case. Next, I grabbed the source and tracked this issue to this code in the 1.6.1 release candidate for Android (though it was a problem at least as far back to 1.5.8 so it's probably always been a problem): /* @see org.slf4j.Logger#trace(java.lang.String, java.lang.Object) */ public void trace(final String format, final Object param1) { Log.v(name, format(format, param1, null)); } The problem is that in the above statement 'format' will ALWAYS BE EVALUATED and in turn will always cause toString to be evaluated even if the result will not be used. To fix this each of the various logger methods will need to be enclosed in a Log.isLoggable conditionals... so the fix for the trace method above is something like this: /* @see org.slf4j.Logger#trace(java.lang.String, java.lang.Object) */ public void trace(final String format, final Object param1) { if (Log.isLoggable(name, Log.VERBOSE)) { Log.v(name, format(format, param1, null)); } } As painful as it is - the workaround is of course to surround each time expensive log operations with the relevant test. For the example above I have to use this: if (logger.isTraceEnabled()) { logger.trace("populateWebListView with url = '{}'", ami); } I see this as an easy fix - and I'm hoping we can see it in the 1.6.1 release... I may put together a patch to resolve this locally soon and if I do - I'll add it here. Thanks in advance, -Darrin -- 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

Returned mail: Data format error
by Mail Delivery Subsystem 04 Nov '10

04 Nov '10

This message was undeliverable due to the following reason: Your message was not delivered because the destination computer was unreachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message could not be delivered within 6 days: Server 117.18.112.63 is not responding. The following recipients could not receive this message: <dev(a)slf4j.org> Please reply to postmaster(a)slf4j.org if you feel this message to be in error.

1 0

OSGi support in slf4j
by Heiko Seeberger 03 Nov '10

03 Nov '10

Hi, My recent changes to the POM of the slf4j-scala-api module show how we should IMHO be doing OSGi in every module: Don't write the whole manifest manually, but let the Maven Bundle plugin generate it. Looking at the manifest of slf4j-api there are several issues: - There is no Bundle-Version - The bundle symbolic name does not follow "well recognized OSGi conventions": It should follow the reverse domain naming convention, i.e. org.slf4j.api - I guess that SLF4J is compiled to target 1.5. At least for the JUL module it has to be 1.4 at minimum. Therefore I doubt that the 1.3 execution environment ist the correct setting - I think the import for org.slf4j.impl should be optional, but I have to play with that one - There is no uses directive for the exported packages. Well, that cannot be done manually (see Maven Bundle plugin above) I suggest I give it a try and change the slf4j-api module to also use the Maven Bundle plugin. Thoughts? Heiko Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org

5 19

[Bug 203] New: BasicMDCAdapter is not thread safe
by bugzilla-daemon＠pixie.qos.ch 02 Nov '10

02 Nov '10

http://bugzilla.slf4j.org/show_bug.cgi?id=203 Summary: BasicMDCAdapter is not thread safe Product: SLF4J Version: 1.6.x Platform: All OS/Version: All Status: NEW Severity: major Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: raimo.jarvi(a)gmail.com org.slf4j.helpers.BasicMDCAdapter is not thread safe, because a thread may inherit parent thread's context map. Since HashMap is not synchronized, this is not thread safe. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

4 5