[logback-dev] [JIRA] (LOGBACK-1331) Programatically Control Logger Hierarchy

[QOS.CH (JIRA)]

buko created LOGBACK-1331:
-----------------------------

             Summary: Programatically Control Logger Hierarchy
                 Key: LOGBACK-1331
                 URL: https://jira.qos.ch/browse/LOGBACK-1331
             Project: logback
          Issue Type: New Feature
          Components: logback-classic
    Affects Versions: 1.2.3
            Reporter: buko
            Assignee: Logback dev list


We would like to be able to programatically control the hierarchy of Loggers. Logback classic allows the ability to programatically configure Loggers but it does not allow the ability to programatically control the Logger hierarchy - that is, there's no way to force one Logger object to become the parent of another Logger object.

Currently the hierarchy model is essentially hardcoded in the LoggerContext.getLogger(String) method. This method parses the string out based on '.' and '$' characters to create a hierarchy of Loggers.

We would like to implement our own Logger hierarchy logic. We have two loggers, Logger('node://mesh.context/') and Logger('node://mesh.context/identity') and the first should be parent of the second. 

There are a couple of ways this could be done:

 

1) Make the Logger(String,Logger,LoggerContext) constructor public. This would allow people to create Loggers using any hierarchy they want.

2) Provide a new methods:

 LoggerContext.getLoggerOpaque(String name);

 LoggerContext.getLoggerOpaque(String name, Logger parent);

 

These methods would allow clients to create Loggers with OPAQUE names. No attempt would be made to parse the logger's name and interpret it as an hierarchy. It would also allow the user to implement her own hierarchy model by explicitly passing a parent logger.

3) Provide a Logger.setParent(Logger) method.

 

Our preference is on #2.

 

Note that currently we can hack around this by reflectively invoking the package-private Logger ctor using the setAccessible method. This is not a stable workaround and will probably stop working with Java 9.

 



--
This message was sent by Atlassian JIRA
(v7.3.1#73012)