[logback-dev] [JIRA] Issue Comment Edited: (LBCLASSIC-102) Suggestion: Change logger name of inner classes.

[Ceki Gulcu (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11444#action_11444 ] 

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 at 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