New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow specifying configurations for each logger #1092

Closed
wants to merge 8 commits into
base: master
from

Conversation

Projects
None yet
8 participants
@wakandan
Contributor

wakandan commented Jun 3, 2015

Dropwizard doesn't have the ability to specify configurations for individual loggers yet. With this patch user can do something like this:

logging:
  level: INFO
  loggers:
    wego.curiosity:
      level: DEBUG
      appenders: 
        - type: console
          target: stdout
          logFormat: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{16} - %msg%n"
          ...
  appenders:
    - type: file
     ...
    - type: console
      target: stdout
      logFormat: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{16} - %msg%n"
    - type: loggly
    ...
@earthling

This comment has been minimized.

Show comment
Hide comment
@earthling

earthling commented Jun 8, 2015

+1

@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jun 10, 2015

Contributor

do you think specifying debug level per appender per logger would be useful? I think it might be a bit overkill....

Contributor

wakandan commented Jun 10, 2015

do you think specifying debug level per appender per logger would be useful? I think it might be a bit overkill....

@earthling

This comment has been minimized.

Show comment
Hide comment
@earthling

earthling Jun 10, 2015

I would just like to have the logger reference appenders by name, as they could if logback were configured via xml or groovy. Really, I would just like the yml configuration to have feature parity with the xml configuration.

earthling commented Jun 10, 2015

I would just like to have the logger reference appenders by name, as they could if logback were configured via xml or groovy. Really, I would just like the yml configuration to have feature parity with the xml configuration.

@douzzi

This comment has been minimized.

Show comment
Hide comment
@douzzi

douzzi Jun 11, 2015

Contributor

+1

Being able to configure different loggers to log to different files is really important for many applications.

Contributor

douzzi commented Jun 11, 2015

+1

Being able to configure different loggers to log to different files is really important for many applications.

@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jun 11, 2015

Contributor

alright so this looks okay? How do I proceed? Thanks.

Contributor

wakandan commented Jun 11, 2015

alright so this looks okay? How do I proceed? Thanks.

@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Jun 11, 2015

Member

Sorry for the delay. I will take look at this today.

Member

arteam commented Jun 11, 2015

Sorry for the delay. I will take look at this today.

@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Jun 11, 2015

Member

Thanks for taking your time to implement this feature. Some observations, before we can proceed further:

  • Please, follow Dropwizard Contributing Guide in your contribution.
  • Rebase your change against master branch. It's not mergeable now.
  • Don't change spaces to tabs in the whole file. Dealing with different indentations across the project is a nightmare. Make your change focused.
  • Add some tests to verify that your change works and doesn't break anything. As far as I can tell, the proposed implementation is not compatibe with the current logger configuration format:
logging:
  level: INFO
  loggers:
    "com.example.app": DEBUG
Member

arteam commented Jun 11, 2015

Thanks for taking your time to implement this feature. Some observations, before we can proceed further:

  • Please, follow Dropwizard Contributing Guide in your contribution.
  • Rebase your change against master branch. It's not mergeable now.
  • Don't change spaces to tabs in the whole file. Dealing with different indentations across the project is a nightmare. Make your change focused.
  • Add some tests to verify that your change works and doesn't break anything. As far as I can tell, the proposed implementation is not compatibe with the current logger configuration format:
logging:
  level: INFO
  loggers:
    "com.example.app": DEBUG
@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jun 12, 2015

Contributor

@arteam thanks for you input. I'm gonna update my code 👍

Contributor

wakandan commented Jun 12, 2015

@arteam thanks for you input. I'm gonna update my code 👍

@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jun 15, 2015

Contributor

@arteam added tests and changed code styling

Contributor

wakandan commented Jun 15, 2015

@arteam added tests and changed code styling

@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Jun 18, 2015

Member

@wakandan You probably misunderstood me. Your contribution should be backward compatible.
People who use the current format

logging:
  level: INFO
  loggers:
    "com.example.app": DEBUG

should not update their configuration to

logging:
  level: INFO
  loggers:
    "com.example.app": 
        level: DEBUG

I don't think we could change the format of the field loggers at all, unless we must to.

I would more think about adding other field like advancedLoggers, that would override loggers, if it's present.

Member

arteam commented Jun 18, 2015

@wakandan You probably misunderstood me. Your contribution should be backward compatible.
People who use the current format

logging:
  level: INFO
  loggers:
    "com.example.app": DEBUG

should not update their configuration to

logging:
  level: INFO
  loggers:
    "com.example.app": 
        level: DEBUG

I don't think we could change the format of the field loggers at all, unless we must to.

I would more think about adding other field like advancedLoggers, that would override loggers, if it's present.

@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jun 19, 2015

Contributor

@arteam aaaahhhh. I understood now, never thought of that. Okay I will update my code 👍

Contributor

wakandan commented Jun 19, 2015

@arteam aaaahhhh. I understood now, never thought of that. Okay I will update my code 👍

@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jun 22, 2015

Contributor

@arteam I modified the code as you requested. "advancedLoggers" key can be read from the configuration file and it will override settings from "loggers" key. Please review. Thanks 👍

Contributor

wakandan commented Jun 22, 2015

@arteam I modified the code as you requested. "advancedLoggers" key can be read from the configuration file and it will override settings from "loggers" key. Please review. Thanks 👍

@nickbabcock

View changes

Show outdated Hide outdated ...d-logging/src/main/java/io/dropwizard/logging/DefaultLoggingFactory.java
@ryankennedy

This comment has been minimized.

Show comment
Hide comment
@ryankennedy

ryankennedy Jun 24, 2015

Member

advancedLoggers feels like a bit of a wart on the side of the configuration.

What if we extended the appenders, instead? Provide them with a "loggers" list property consisting of the loggers that should write to that appender. Default the list of loggers to all loggers. That would be backwards compatible and provide the intended functionality.

logging:
  level: INFO
  loggers:
    wego.curiosity: DEBUG
  appenders:
    - type: file
      loggers: [wego.curiosity]
     ...
    - type: console
      target: stdout
      logFormat: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{16} - %msg%n"
Member

ryankennedy commented Jun 24, 2015

advancedLoggers feels like a bit of a wart on the side of the configuration.

What if we extended the appenders, instead? Provide them with a "loggers" list property consisting of the loggers that should write to that appender. Default the list of loggers to all loggers. That would be backwards compatible and provide the intended functionality.

logging:
  level: INFO
  loggers:
    wego.curiosity: DEBUG
  appenders:
    - type: file
      loggers: [wego.curiosity]
     ...
    - type: console
      target: stdout
      logFormat: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{16} - %msg%n"
@glennmcallister

This comment has been minimized.

Show comment
Hide comment
@glennmcallister

glennmcallister Jun 24, 2015

Contributor

I'm happier with Ryan's approach, tbh.

On Wed, Jun 24, 2015 at 11:57 AM Ryan Kennedy notifications@github.com
wrote:

advancedLoggers feels like a bit of a wart on the side of the
configuration.

What if we extended the appenders, instead? Provide them with a "loggers"
list property consisting of the loggers that should write to that appender.
Default the list of loggers to all loggers. That would be backwards
compatible and provide the intended functionality.

logging:
level: INFO
loggers:
wego.curiosity: DEBUG
appenders:
- type: file
loggers: [wego.curiosity]
...
- type: console
target: stdout
logFormat: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{16} - %msg%n"


Reply to this email directly or view it on GitHub
#1092 (comment)
.

Contributor

glennmcallister commented Jun 24, 2015

I'm happier with Ryan's approach, tbh.

On Wed, Jun 24, 2015 at 11:57 AM Ryan Kennedy notifications@github.com
wrote:

advancedLoggers feels like a bit of a wart on the side of the
configuration.

What if we extended the appenders, instead? Provide them with a "loggers"
list property consisting of the loggers that should write to that appender.
Default the list of loggers to all loggers. That would be backwards
compatible and provide the intended functionality.

logging:
level: INFO
loggers:
wego.curiosity: DEBUG
appenders:
- type: file
loggers: [wego.curiosity]
...
- type: console
target: stdout
logFormat: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{16} - %msg%n"


Reply to this email directly or view it on GitHub
#1092 (comment)
.

@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Jun 24, 2015

Member

Probably is not good enough if we, for example, want to log wego.curiosity to a separate file.
Moreover, it seems wrong to me that appenders know about loggers. I always thought about them as entities that control where and how to log, but not what to log.

Member

arteam commented Jun 24, 2015

Probably is not good enough if we, for example, want to log wego.curiosity to a separate file.
Moreover, it seems wrong to me that appenders know about loggers. I always thought about them as entities that control where and how to log, but not what to log.

@ryankennedy

This comment has been minimized.

Show comment
Hide comment
@ryankennedy

ryankennedy Jun 24, 2015

Member

Why isn't it good enough to log wego.curiosity to a separate file? Create an appender for that file and add wego.curiosity to the loggers list for it. If the concern is that it would still be logging to the other appenders, we could have includedLoggers (defaulted to all loggers) and excludedLoggers (defaulted to no loggers) for each appender.

To play the other side of the coin, what if you want to log wego.curiosity and yougo.curiosity to the same file? Will you spec the appender twice (once for each logger)?

As for appenders knowing about loggers, I'm only talking about the relationship between loggers and appenders is configured. How the loggers get hooked up to appenders under the hood is (in my mind) separate from how the relationship gets configured in the YAML file.

Member

ryankennedy commented Jun 24, 2015

Why isn't it good enough to log wego.curiosity to a separate file? Create an appender for that file and add wego.curiosity to the loggers list for it. If the concern is that it would still be logging to the other appenders, we could have includedLoggers (defaulted to all loggers) and excludedLoggers (defaulted to no loggers) for each appender.

To play the other side of the coin, what if you want to log wego.curiosity and yougo.curiosity to the same file? Will you spec the appender twice (once for each logger)?

As for appenders knowing about loggers, I'm only talking about the relationship between loggers and appenders is configured. How the loggers get hooked up to appenders under the hood is (in my mind) separate from how the relationship gets configured in the YAML file.

@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Jun 24, 2015

Member

I have an idea to make the configuration more dynamic, so we can permit objects with different types for keys. For example:

level: INFO
loggers:
  "com.example.app": DEBUG
  "wego.curiosity":
      level: DEBUG
      appenders: 
        - type: console
          target: stdout
          logFormat: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{16} - %msg%n"

To map this to Java we need to change the type of the loggers field to ImmutableMap<String, JsonNode>. And then make a type check in runtime something like that:

for (Map.Entry<String, JsonNode> entry : loggers.entrySet()) {
    final Logger logger = loggerContext.getLogger(entry.getKey());

    final JsonNode jsonNode = entry.getValue();
    if (jsonNode.isTextual()) {
        // Just a level as a string
        Level level = Level.valueOf(jsonNode.asText());
        logger.setLevel(level);
    } else if (jsonNode.isObject()) {
        // Level and appender
        LoggerConfiguration configuration;
        try {
            configuration = Jackson.newObjectMapper().treeToValue(jsonNode, LoggerConfiguration.class);
        } catch (JsonProcessingException e) {
            throw new IllegalArgumentException("Wrong format of logger '" + entry.getKey() + "'", e);
        }
        logger.setLevel(configuration.getLevel());
        for (AppenderFactory appender : configuration.getAppenders()) {
            logger.addAppender(appender.build(loggerContext, name, null));
        }
    } else {
        throw new IllegalArgumentException("Unsupported format of logger '" + entry.getKey() + "'");
    }
}

Thoughts?

Member

arteam commented Jun 24, 2015

I have an idea to make the configuration more dynamic, so we can permit objects with different types for keys. For example:

level: INFO
loggers:
  "com.example.app": DEBUG
  "wego.curiosity":
      level: DEBUG
      appenders: 
        - type: console
          target: stdout
          logFormat: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{16} - %msg%n"

To map this to Java we need to change the type of the loggers field to ImmutableMap<String, JsonNode>. And then make a type check in runtime something like that:

for (Map.Entry<String, JsonNode> entry : loggers.entrySet()) {
    final Logger logger = loggerContext.getLogger(entry.getKey());

    final JsonNode jsonNode = entry.getValue();
    if (jsonNode.isTextual()) {
        // Just a level as a string
        Level level = Level.valueOf(jsonNode.asText());
        logger.setLevel(level);
    } else if (jsonNode.isObject()) {
        // Level and appender
        LoggerConfiguration configuration;
        try {
            configuration = Jackson.newObjectMapper().treeToValue(jsonNode, LoggerConfiguration.class);
        } catch (JsonProcessingException e) {
            throw new IllegalArgumentException("Wrong format of logger '" + entry.getKey() + "'", e);
        }
        logger.setLevel(configuration.getLevel());
        for (AppenderFactory appender : configuration.getAppenders()) {
            logger.addAppender(appender.build(loggerContext, name, null));
        }
    } else {
        throw new IllegalArgumentException("Unsupported format of logger '" + entry.getKey() + "'");
    }
}

Thoughts?

@earthling

This comment has been minimized.

Show comment
Hide comment
@earthling

earthling Jun 24, 2015

I like Ryan's idea. I also like @arteam's idea, though I don't think it makes sense to define appenders inline with the logger like that. I'd rather just let the appender have a name and let the 'advanced' logger configuration syntax reference the appender by name (much the same as a conventional logback.xml would do).

earthling commented Jun 24, 2015

I like Ryan's idea. I also like @arteam's idea, though I don't think it makes sense to define appenders inline with the logger like that. I'd rather just let the appender have a name and let the 'advanced' logger configuration syntax reference the appender by name (much the same as a conventional logback.xml would do).

@ryankennedy

This comment has been minimized.

Show comment
Hide comment
@ryankennedy

ryankennedy Jun 24, 2015

Member

I still think putting appenders in the loggers will lead to appenders being spec'd repeatedly and in multiple locations. I think either have the loggers refer to the appenders by name (something we don't have today…an appender name) that they want to be a part of or have appenders refer to the loggers they'll handle output for. Appenders are already an object, so the code change is minimal. Loggers would require either breaking compatibility (switch from level to an object); adding a new loggers property (the advancedLoggers suggestion), which I think looks wart-ish; or make loggers polymorphic, which I think impacts readability of the code (I refer to configuration classes often when I'm trying to figure out how to configure a thing…JsonNode isn't self-documenting).

My preference is to add the loggers list to the appenders because it requires the smallest change to the code/configuration format and because it avoids duplicating appender configuration and avoids having appenders configured in multiple locations.

Member

ryankennedy commented Jun 24, 2015

I still think putting appenders in the loggers will lead to appenders being spec'd repeatedly and in multiple locations. I think either have the loggers refer to the appenders by name (something we don't have today…an appender name) that they want to be a part of or have appenders refer to the loggers they'll handle output for. Appenders are already an object, so the code change is minimal. Loggers would require either breaking compatibility (switch from level to an object); adding a new loggers property (the advancedLoggers suggestion), which I think looks wart-ish; or make loggers polymorphic, which I think impacts readability of the code (I refer to configuration classes often when I'm trying to figure out how to configure a thing…JsonNode isn't self-documenting).

My preference is to add the loggers list to the appenders because it requires the smallest change to the code/configuration format and because it avoids duplicating appender configuration and avoids having appenders configured in multiple locations.

@earthling

This comment has been minimized.

Show comment
Hide comment
@earthling

earthling Jun 24, 2015

Would it be so terrible to change the configuration syntax?

Failing that, if the appenders reference loggers (which is reversed from logback configuration files), how would additivity be configured?

In case the default cumulative behavior turns out to be unsuitable for your needs, you can override it by setting the additivity flag to false. Thus, a branch in your logger tree may direct output to a set of appenders different from those of the rest of the tree.
http://logback.qos.ch/manual/configuration.html

For example, some loggers should log to all appenders, while other loggers should log to only one appender.

earthling commented Jun 24, 2015

Would it be so terrible to change the configuration syntax?

Failing that, if the appenders reference loggers (which is reversed from logback configuration files), how would additivity be configured?

In case the default cumulative behavior turns out to be unsuitable for your needs, you can override it by setting the additivity flag to false. Thus, a branch in your logger tree may direct output to a set of appenders different from those of the rest of the tree.
http://logback.qos.ch/manual/configuration.html

For example, some loggers should log to all appenders, while other loggers should log to only one appender.

@carlo-rtr

This comment has been minimized.

Show comment
Hide comment
@carlo-rtr

carlo-rtr Jun 25, 2015

Member

Something else to consider is that one could roll their own logger factory which reads from a provided logback.xml. This way we keep the current logging configuration simple and in yaml, which probably satisfies most users. If you really want complex configuration, then you have a way. My 2cs.

Member

carlo-rtr commented Jun 25, 2015

Something else to consider is that one could roll their own logger factory which reads from a provided logback.xml. This way we keep the current logging configuration simple and in yaml, which probably satisfies most users. If you really want complex configuration, then you have a way. My 2cs.

@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jun 25, 2015

Contributor

@carlo-rtr 's idea is actually not bad. I was thinking about doing the same thing since we have some logback configuration file. One thing the old-fashioned xml logback might be good for is that they can do scanning for changes in the xml file (during runtime, and reload config), which is very very handy for debugging in production.

@ryankennedy 's approach seems nice for both readability & backward compatibility. Should we proceed with that?

Contributor

wakandan commented Jun 25, 2015

@carlo-rtr 's idea is actually not bad. I was thinking about doing the same thing since we have some logback configuration file. One thing the old-fashioned xml logback might be good for is that they can do scanning for changes in the xml file (during runtime, and reload config), which is very very handy for debugging in production.

@ryankennedy 's approach seems nice for both readability & backward compatibility. Should we proceed with that?

@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Jun 26, 2015

Member

Sorry, but I have a firm opinion that we should not configure loggers in appenders.
Despite that it's easy to implement, such configuration is not conventional, and not obvious for users. The polymorphic solution seems to me as the lesser of two evils.

@dropwizard/committers, what is your opinion on this?

Member

arteam commented Jun 26, 2015

Sorry, but I have a firm opinion that we should not configure loggers in appenders.
Despite that it's easy to implement, such configuration is not conventional, and not obvious for users. The polymorphic solution seems to me as the lesser of two evils.

@dropwizard/committers, what is your opinion on this?

@nickbabcock

This comment has been minimized.

Show comment
Hide comment
@nickbabcock

nickbabcock Jun 29, 2015

Contributor

I think I like Carlo's idea of the logback.xml/groovy configuration. The YAML configuration should satisfy 95% of all use cases. In 5% of the use cases there should be an alternative mechansim to achieving the desired result (logback.xml). Dropwizard can't and shouldn't support all logging fantasies in the YAML. For instance, logback supports automatically scanning the file for changes and applying them. In my opinion, if someone wanted this in Dropwizard, they should be expected to into the logback.xml to configure it.

Since creating an uber jar messes with the class path, one can use logback.xml by invoking:

java -Dlogback.configurationFile=logback.xml -jar <jarfile> server config.yaml

However, one can't currently use this approach as all the configured appenders in logback.xml are killed on bootup by the following code:

final Logger root = LoggingUtil.getLoggerContext().getLogger(org.slf4j.Logger.ROOT_LOGGER_NAME);
root.detachAndStopAllAppenders();

I can't say why this is done (it's been this way for more than a couple of years). But I feel like maybe the optimal solution would be for logback.xml and the yaml to complement each other.

The next question, if this pull request should be in the 95% use case, from a user standpoint, I like Artem's solution of ImmutableMap<String, JsonNode> for the different type of keys. From a user point of view, everything is localized in the configuration.

Contributor

nickbabcock commented Jun 29, 2015

I think I like Carlo's idea of the logback.xml/groovy configuration. The YAML configuration should satisfy 95% of all use cases. In 5% of the use cases there should be an alternative mechansim to achieving the desired result (logback.xml). Dropwizard can't and shouldn't support all logging fantasies in the YAML. For instance, logback supports automatically scanning the file for changes and applying them. In my opinion, if someone wanted this in Dropwizard, they should be expected to into the logback.xml to configure it.

Since creating an uber jar messes with the class path, one can use logback.xml by invoking:

java -Dlogback.configurationFile=logback.xml -jar <jarfile> server config.yaml

However, one can't currently use this approach as all the configured appenders in logback.xml are killed on bootup by the following code:

final Logger root = LoggingUtil.getLoggerContext().getLogger(org.slf4j.Logger.ROOT_LOGGER_NAME);
root.detachAndStopAllAppenders();

I can't say why this is done (it's been this way for more than a couple of years). But I feel like maybe the optimal solution would be for logback.xml and the yaml to complement each other.

The next question, if this pull request should be in the 95% use case, from a user standpoint, I like Artem's solution of ImmutableMap<String, JsonNode> for the different type of keys. From a user point of view, everything is localized in the configuration.

@carlo-rtr

This comment has been minimized.

Show comment
Hide comment
@carlo-rtr

carlo-rtr Jul 6, 2015

Member

@nickbabcock The code you are referring to is in BootstrapLogging.bootstrap, which is called in the default constructor of Application. If someone rolls their own logger factory, then they just need to override the default constructor for the subclass of Application, and not call bootstrap.

Member

carlo-rtr commented Jul 6, 2015

@nickbabcock The code you are referring to is in BootstrapLogging.bootstrap, which is called in the default constructor of Application. If someone rolls their own logger factory, then they just need to override the default constructor for the subclass of Application, and not call bootstrap.

@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jul 15, 2015

Contributor

...so is there a consensus approach for this? I'm still interested in pushing for this feature if possible

Contributor

wakandan commented Jul 15, 2015

...so is there a consensus approach for this? I'm still interested in pushing for this feature if possible

@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Jul 15, 2015

Member

@wakandan, sorry for sitting on this so long.

I think we should proceed with the approach proposed in 115012595. It's less controversial than 114924378 and shouldn't be very hard to implement.

Member

arteam commented Jul 15, 2015

@wakandan, sorry for sitting on this so long.

I think we should proceed with the approach proposed in 115012595. It's less controversial than 114924378 and shouldn't be very hard to implement.

@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jul 16, 2015

Contributor

alright @arteam I will check that. Thanks for your comments 👍

Contributor

wakandan commented Jul 16, 2015

alright @arteam I will check that. Thanks for your comments 👍

@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jul 22, 2015

Contributor

@arteam updated

Contributor

wakandan commented Jul 22, 2015

@arteam updated

@arteam arteam closed this in 0f97349 Jul 22, 2015

arteam added a commit that referenced this pull request Jul 22, 2015

Allow specifying configurations for each logger
Add the ability to configure appenders for individual loggers.
We should not break backward compatibility, that's why we accept
both formats of configuration (the old one with a level as a string
and the new one with a `LoggerConfiguration` object).

Close #1092
@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Jul 22, 2015

Member

Thanks for your work on this, @wakandan!

Applied the patch to master with some improvements.

Member

arteam commented Jul 22, 2015

Thanks for your work on this, @wakandan!

Applied the patch to master with some improvements.

@wakandan

This comment has been minimized.

Show comment
Hide comment
@wakandan

wakandan Jul 22, 2015

Contributor

thanks! 👍

Contributor

wakandan commented Jul 22, 2015

thanks! 👍

arteam added a commit that referenced this pull request Jul 28, 2015

chrisholmes added a commit to chrisholmes/dropwizard that referenced this pull request Aug 14, 2015

Allow specifying configurations for each logger
Add the ability to configure appenders for individual loggers.
We should not break backward compatibility, that's why we accept
both formats of configuration (the old one with a level as a string
and the new one with a `LoggerConfiguration` object).

Close #1092

chrisholmes added a commit to chrisholmes/dropwizard that referenced this pull request Aug 14, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment