[Bug 203] New: BasicMDCAdapter is not thread safe
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@qos.ch ReportedBy: raimo.jarvi@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.
http://bugzilla.slf4j.org/show_bug.cgi?id=203 --- Comment #1 from Ceki Gulcu <listid@qos.ch> 2010-10-21 12:24:44 --- Other relevant context in http://www.qos.ch/pipermail/slf4j-user/2010-October/001014.html -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
Hello Heiko, Looking at logger.scala, I was wondering why the Logger trait was a trait and not a class. I understand that as a trait any class can mixin Logger and methods such as debug(), info() would be available in that class. However, there is already a trait caller Logging which allows the mixing class to write logger.debug("..."). It seems to me that the Logging trait is sufficient in most cases. I would like to propose to make Logger a class instead of a Trait and to get rid of DefaultLogger. This would make the code a little simpler without loss of "desired" flexibility. I don't think we should allow classes to write just debug("...") or should we? WDYT? -- Ceki
Ceki, I think you are right: There seems to be no need for an abstract Logger (trait or abstract class) and a default implementation. Better have a single concrete Logger class wrapping a SLF4JLogger instance. How shall we proceed? Wait some time and do the change then? Change it immediately? Heiko On 1 November 2010 22:28, Ceki Gülcü <ceki@qos.ch> wrote:
Hello Heiko,
Looking at logger.scala, I was wondering why the Logger trait was a trait and not a class. I understand that as a trait any class can mixin Logger and methods such as debug(), info() would be available in that class. However, there is already a trait caller Logging which allows the mixing class to write logger.debug("...").
It seems to me that the Logging trait is sufficient in most cases. I would like to propose to make Logger a class instead of a Trait and to get rid of DefaultLogger. This would make the code a little simpler without loss of "desired" flexibility. I don't think we should allow classes to write just debug("...") or should we?
WDYT?
-- Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger 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
Hi Heiko, Thanks for you quick reply. I'll go ahead and do agreed changes tomorrow (Wednesday). I'll probably add Marker and caller info support as well. Cheers, On 02.11.2010 09:20, Heiko Seeberger wrote:
Ceki,
I think you are right: There seems to be no need for an abstract Logger (trait or abstract class) and a default implementation. Better have a single concrete Logger class wrapping a SLF4JLogger instance.
How shall we proceed? Wait some time and do the change then? Change it immediately?
Heiko
On 1 November 2010 22:28, Ceki Gülcü <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Hello Heiko,
Looking at logger.scala, I was wondering why the Logger trait was a trait and not a class. I understand that as a trait any class can mixin Logger and methods such as debug(), info() would be available in that class. However, there is already a trait caller Logging which allows the mixing class to write logger.debug("...").
It seems to me that the Logging trait is sufficient in most cases. I would like to propose to make Logger a class instead of a Trait and to get rid of DefaultLogger. This would make the code a little simpler without loss of "desired" flexibility. I don't think we should allow classes to write just debug("...") or should we?
WDYT?
-- Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch <mailto:slf4j-dev@qos.ch> http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger
Company: weiglewilczek.com <http://weiglewilczek.com> Blog: heikoseeberger.name <http://heikoseeberger.name> Follow me: twitter.com/hseeberger <http://twitter.com/hseeberger> OSGi on Scala: scalamodules.org <http://scalamodules.org> Lift, the simply functional web framework: liftweb.net <http://liftweb.net> Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org <http://akkasource.org>
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
Cool! For marker you might want to take a look at Paul's contribution. You find it in the SLF4S repo at the marker branch. Heiko On Tuesday, November 2, 2010, Ceki Gulcu <ceki@qos.ch> wrote:
Hi Heiko,
Thanks for you quick reply. I'll go ahead and do agreed changes tomorrow (Wednesday). I'll probably add Marker and caller info support as well.
Cheers,
On 02.11.2010 09:20, Heiko Seeberger wrote:
Ceki,
I think you are right: There seems to be no need for an abstract Logger (trait or abstract class) and a default implementation. Better have a single concrete Logger class wrapping a SLF4JLogger instance.
How shall we proceed? Wait some time and do the change then? Change it immediately?
Heiko
On 1 November 2010 22:28, Ceki Gülcü <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Hello Heiko,
Looking at logger.scala, I was wondering why the Logger trait was a trait and not a class. I understand that as a trait any class can mixin Logger and methods such as debug(), info() would be available in that class. However, there is already a trait caller Logging which allows the mixing class to write logger.debug("...").
It seems to me that the Logging trait is sufficient in most cases. I would like to propose to make Logger a class instead of a Trait and to get rid of DefaultLogger. This would make the code a little simpler without loss of "desired" flexibility. I don't think we should allow classes to write just debug("...") or should we?
WDYT?
-- Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch <mailto:slf4j-dev@qos.ch> http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger
Company: weiglewilczek.com <http://weiglewilczek.com> Blog: heikoseeberger.name <http://heikoseeberger.name> Follow me: twitter.com/hseeberger <http://twitter.com/hseeberger> OSGi on Scala: scalamodules.org <http://scalamodules.org> Lift, the simply functional web framework: liftweb.net <http://liftweb.net> Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org <http://akkasource.org>
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger 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
participants (4)
-
bugzilla-daemon＠pixie.qos.ch -
Ceki Gulcu -
Ceki Gülcü
-
Heiko Seeberger