[ http://jira.qos.ch/browse/LBCLASSIC-102?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-102: ----------------------------------------- This should be fixed in http://github.com/huxi/logback/tree/LBCLASSIC-102 In addition to '.' LoggerContext is now also looking out for '$' as separator. I haven't checked this in any way but the change is very trivial and all logback-classic tests are still running.

Suggestion: Change logger name of inner classes. ------------------------------------------------

Key: LBCLASSIC-102 URL: http://jira.qos.ch/browse/LBCLASSIC-102 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.15 Reporter: Joern Huxhorn Assignee: Logback dev list

At the moment, the logger name of inner classes is OuterClass$InnerClass. Because of that, the logging level of OuterClass isn't inherited by InnerClass at the moment. If LoggerFactory changed the logger name to OuterClass.InnerClass instead, InnerClass would inherit the logging level of OuterClass which seems intuitively correct. I'd suggest to accept both $InnerClass and .InnerClass style in logback configurations for compatibility and usability reasons.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.qos.ch/browse/LBCLASSIC-102?page=com.atlassian.jira.plugin.syste... ] Syvalta commented on LBCLASSIC-102: ----------------------------------- We are appending an id to the logger name like this (id could be an user id for example): log = org.slf4j.LoggerFactory.getLogger(this.getClass().getName() + "." + id); After upgrading to Logback 0.9.18 we started to see the following exceptions (when the class happens to be an inner class): java.lang.IllegalArgumentException: For logger [foo.bar] child name [foo.bar.SomeClass$SomeInnerClass passed as parameter, may not include '.' after index8 at ch.qos.logback.classic.Logger.createChildByName(Logger.java:381) at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:148) at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:48) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249)

Suggestion: Change logger name of inner classes. ------------------------------------------------

Key: LBCLASSIC-102 URL: http://jira.qos.ch/browse/LBCLASSIC-102 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.15 Reporter: Joern Huxhorn Assignee: Logback dev list Fix For: 0.9.18

At the moment, the logger name of inner classes is OuterClass$InnerClass. Because of that, the logging level of OuterClass isn't inherited by InnerClass at the moment. If LoggerFactory changed the logger name to OuterClass.InnerClass instead, InnerClass would inherit the logging level of OuterClass which seems intuitively correct. I'd suggest to accept both $InnerClass and .InnerClass style in logback configurations for compatibility and usability reasons.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.qos.ch/browse/LBCLASSIC-102?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-102 at 12/14/09 11:28 AM: ----------------------------------------------------------------- The code assumes that '$' is always the last separator character and that no '.' can follow it. This is a reasonable assumption as long as the logger name strictly follows the name of the host class convention. You are using a different convention where the aforementioned assumption does not hold. As you are in principle allowed to follow any convention, the logback code needs to be changed to accommodate other naming conventions. Having said that, I was wondering why instead of appending "."+id to the logger name, you are not making use of the many features logback offers, such as markers or MDC to add additional data to your log statement. For one, one created a logger lives as long as the application. What do you actually do with the "id"? was (Author: noreply.ceki@qos.ch): Re opening

Suggestion: Change logger name of inner classes. ------------------------------------------------

Key: LBCLASSIC-102 URL: http://jira.qos.ch/browse/LBCLASSIC-102 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.15 Reporter: Joern Huxhorn Assignee: Logback dev list Fix For: 0.9.18

At the moment, the logger name of inner classes is OuterClass$InnerClass. Because of that, the logging level of OuterClass isn't inherited by InnerClass at the moment. If LoggerFactory changed the logger name to OuterClass.InnerClass instead, InnerClass would inherit the logging level of OuterClass which seems intuitively correct. I'd suggest to accept both $InnerClass and .InnerClass style in logback configurations for compatibility and usability reasons.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.qos.ch/browse/LBCLASSIC-102?page=com.atlassian.jira.plugin.syste... ] Ralph Goers commented on LBCLASSIC-102: --------------------------------------- Having each instance vary the logger name is going to eat up a ton of memory as you will be creating a new logger for each one. Loggers typically are typically cached forever since they are likely to be reused.

Suggestion: Change logger name of inner classes. ------------------------------------------------

Key: LBCLASSIC-102 URL: http://jira.qos.ch/browse/LBCLASSIC-102 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.15 Reporter: Joern Huxhorn Assignee: Ceki Gulcu Fix For: 0.9.18

At the moment, the logger name of inner classes is OuterClass$InnerClass. Because of that, the logging level of OuterClass isn't inherited by InnerClass at the moment. If LoggerFactory changed the logger name to OuterClass.InnerClass instead, InnerClass would inherit the logging level of OuterClass which seems intuitively correct. I'd suggest to accept both $InnerClass and .InnerClass style in logback configurations for compatibility and usability reasons.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.qos.ch/browse/LBCLASSIC-102?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-102 at 12/14/09 4:23 PM: ---------------------------------------------------------------- Markers may be a better choice for two reasons. First, they can be arranged in a tree (graph without cycles). Second, they can be garbage-collected if created in detached mode. So assume you have object a0 creating child object b00 and b01, and object a1 creating children b10 and b11. Here is how you would track the various objects: class A { void foo() { Marker aMarker = MarkerFactory.getDetatchedMarker("A-"+this.getId()); Logger logger = LoggerFactory.getLogger(A.class); logger.debug(aMarker, "in A.foo()"); } } class B { // assume that the parent's marker is somehow passed to // to this B instance Marker aMarker = ....; void bar() { Marker bMarker = MarkerFactory.getDetatchedMarker("B-"+this.getId()); // have b's marker reference its parent's (a) marker bMarker.add(aMarker); Logger logger = LoggerFactory.getLogger(B.class); logger.debug(bMarker, "in B.bar()"); } } Here the assumption is that you were somehow able to pass/inject the parent marker (aMarker) to instances of B at some point in time, possibly at creation time. Also note that since logback supports Markers, you would only need to use the %marker conversion pattern in PatternLayout to have the log output contain marker data. The marker data will contain all references. HTH, was (Author: noreply.ceki@qos.ch): Markers may be a better choice for two reasons. First, they can be arranged in a tree (graph without cycles). Second, they can be garbage-collected if created in detached mode. So assume you have object a0 creating child object b00 and b01, and object a1 creating children b10 and b11. Here is how you would track the various object: class A { void foo() { Marker aMarker = MarkerFactory.getDetatchedMarker(this.getId()); Logger logger = LoggerFactory.getLogger(A.class); logger.debug(aMarker, "in A.foo()"); } } class B { // assume that the parent's marker is somehow passed to // to this B instance Marker aMarker = ....; void bar() { Marker bMarker = MarkerFactory.getDetatchedMarker(this.getId()); // b's marker now references its parent a bMarker.add(aMarker); Logger logger = LoggerFactory.getLogger(B.class); logger.debug(bMarker, "in B.bar()"); } } Here the assumption is that you were somehow able to pass/inject the parent marker (aMarker) to B instances at some point in time, possibly at creation time. Also note that since logback supports Markers, you would only need to use the %marker conversion pattern in PatternLayout to have the log output contain marker data. The marker data will contain all references. HTH,

Suggestion: Change logger name of inner classes. ------------------------------------------------

Key: LBCLASSIC-102 URL: http://jira.qos.ch/browse/LBCLASSIC-102 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.15 Reporter: Joern Huxhorn Assignee: Ceki Gulcu Fix For: 0.9.18

At the moment, the logger name of inner classes is OuterClass$InnerClass. Because of that, the logging level of OuterClass isn't inherited by InnerClass at the moment. If LoggerFactory changed the logger name to OuterClass.InnerClass instead, InnerClass would inherit the logging level of OuterClass which seems intuitively correct. I'd suggest to accept both $InnerClass and .InnerClass style in logback configurations for compatibility and usability reasons.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.qos.ch/browse/LBCLASSIC-102?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-102: -------------------------------------- No, it's certainly not a bug, at least not one which can be adequately addressed by a WeakHashMap. This behavior allows loggers to be configured at init time and referenced later, which is an essential feature.

Suggestion: Change logger name of inner classes. ------------------------------------------------

Key: LBCLASSIC-102 URL: http://jira.qos.ch/browse/LBCLASSIC-102 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.15 Reporter: Joern Huxhorn Assignee: Ceki Gulcu Fix For: 0.9.18

At the moment, the logger name of inner classes is OuterClass$InnerClass. Because of that, the logging level of OuterClass isn't inherited by InnerClass at the moment. If LoggerFactory changed the logger name to OuterClass.InnerClass instead, InnerClass would inherit the logging level of OuterClass which seems intuitively correct. I'd suggest to accept both $InnerClass and .InnerClass style in logback configurations for compatibility and usability reasons.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.qos.ch/browse/LBCLASSIC-102?page=com.atlassian.jira.plugin.syste... ] Syvalta commented on LBCLASSIC-102: ----------------------------------- In my use case there is limited number of instances (normally no more than couple of thousands) and they basically live the whole lifetime of the application. I think memory usage shouldn't be a major issue in this case. About markers, they seems to have one major downside: you need to include the marker in every single log statement. Perhaps some kind of lightweight and garbage collectible wrapper delegating to the actual log instance could be a generic solution to this "include instance id" problem?

Suggestion: Change logger name of inner classes. ------------------------------------------------

Key: LBCLASSIC-102 URL: http://jira.qos.ch/browse/LBCLASSIC-102 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.15 Reporter: Joern Huxhorn Assignee: Ceki Gulcu Fix For: 0.9.18

At the moment, the logger name of inner classes is OuterClass$InnerClass. Because of that, the logging level of OuterClass isn't inherited by InnerClass at the moment. If LoggerFactory changed the logger name to OuterClass.InnerClass instead, InnerClass would inherit the logging level of OuterClass which seems intuitively correct. I'd suggest to accept both $InnerClass and .InnerClass style in logback configurations for compatibility and usability reasons.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira