May 2022 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1639) simplify declaration of models in relation with processor phases
by QOS.CH (JIRA) 11 May '22

11 May '22

1 0

[JIRA] Updates for LOGBACK-1639: simplify declaration of models in relation with processor phases
by QOS.CH (JIRA) 11 May '22

11 May '22

logback / LOGBACK-1639 [Open] simplify declaration of models in relation with processor phases ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1639 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 11/May/22 5:49 PM Summary: simplify declaration of models in relation with processor phases Issue Type: Task Assignee: Logback dev list Created: 11/May/22 5:49 PM Fix Versions: 1.3.0-alpha16 Priority: Major Reporter: Ceki Gülcü Description: Models now have to be manually added to phase filters. This is quite cumbersome as most (95%) of Models are handled in the first model processing phase. It would be cleaner if models in the second phase could be declared as such with an appropriate annotation. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1638: Second phase filtering should be done by annotation
by QOS.CH (JIRA) 09 May '22

09 May '22

logback / LOGBACK-1638 [Open] Second phase filtering should be done by annotation ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1638 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 09/May/22 10:03 PM Summary: Second phase filtering should be done by annotation Issue Type: Sub-task Assignee: Logback dev list Components: Joran Created: 09/May/22 10:03 PM Fix Versions: 1.3.0-alpha16 Priority: Major Reporter: Ceki Gülcü Description: Since most Handlers are enabled in the first phase, it makes sense for the smaller groups of handlers enabled in the second phase to be filtered by annotation. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1637: Restore support for new configuration rules
by QOS.CH (JIRA) 06 May '22

06 May '22

logback / LOGBACK-1637 [Open] Restore support for new configuration rules ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1637 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 06/May/22 10:10 PM Summary: Restore support for new configuration rules Issue Type: Bug Assignee: Logback dev list Components: Joran Created: 06/May/22 10:10 PM Fix Versions: 1.3.0-alpha15 Priority: Major Reporter: Ceki Gülcü ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1625) Add support for conditional processing
by QOS.CH (JIRA) 06 May '22

06 May '22

1 0

[JIRA] (LOGBACK-1625) Add support for conditional processing
by QOS.CH (JIRA) 06 May '22

06 May '22

1 0

[JIRA] Updates for LOGBACK-1636: Dynamic MDC Properties
by QOS.CH (JIRA) 03 May '22

03 May '22

logback / LOGBACK-1636 [Open] Dynamic MDC Properties ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1636 ============================== Issue created ------------------------------ Tobias G created this issue on 03/May/22 6:36 PM Summary: Dynamic MDC Properties Issue Type: New Feature Assignee: Logback dev list Created: 03/May/22 6:36 PM Environment: I would like to see a feature similar to the Log4j2's {{ContextDataProvider:}} {{[https://logging.apache.org/log4j/2.x/manual/extending.html#:~:text=Custom%20ContextDataProvider]}} This would be extremely helpful for tracing and injecting trace id, span id and other tracing context information. Priority: Major Reporter: Tobias G ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1635: No way to override bundled logback.xml with local file
by QOS.CH (JIRA) 03 May '22

03 May '22

logback / LOGBACK-1635 [Open] No way to override bundled logback.xml with local file ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1635 ============================== Issue created ------------------------------ Roland Tepp created this issue on 03/May/22 10:17 AM Summary: No way to override bundled logback.xml with local file Issue Type: Bug Affects Versions: 1.3.0-alpha14 Assignee: Logback dev list Components: logback-classic Created: 03/May/22 10:17 AM Environment: My environment: Labels: configuration default Priority: Minor Reporter: Roland Tepp Description: The code that is responsible for loading default log configuration makes it awkward to bundle a default `logback.xml` configuration and have a way to override this by dropping `logback.xml` in the work directory of the application. I just took logback classic version `1.3.0-alpha14` for a test drive on a smallish project and after having configured the sane production defaults for the `logback.xml` in the bundled resources, found that I needed more verbose output. To my dissapointment, when I dropped a slightly modified copy in the work directory of the launched application, I did not see any change in the log ouytput, so I went and digged in to the Logback configuration resolution algorithm and to my horror, I found that files bundled in the classpath are strictly preferred over files provided in the work directory. The algorithm currently goes this way: # findConfigFileURLFromSystemProperties(myClassLoader{color:#cc7832}, {color}updateStatus){color:#cc7832};{color} ## Given {color:#6a8759}logback.configurationFile{color} system property ## try to load resource from url ## if not a url, try loading it from classpath ## if that does not succeed, try loading configuration from filesystem # getResource({color:#9876aa}TEST_AUTOCONFIG_FILE{color}{color:#cc7832}, {color}myClassLoader{color:#cc7832}, {color}updateStatus){color:#cc7832};{color} # getResource({color:#9876aa}AUTOCONFIG_FILE{color}{color:#cc7832}, {color}myClassLoader{color:#cc7832}, {color}updateStatus){color:#cc7832};{color} {{getResource}} is implemented as a call to {{ClassLoader.getResource(...)}}, so effectively, the only way to override logging configuration of the application at deployment time is by specifying a file: url in {color:#6a8759}logback.configurationFile{color} system property with exact path to the configuration file. The expected behavior would be to consult filesystem for configuration file before trying classpath. That way, the simplest way to override logging configuration would be just dropping a file in the file system and have logback pick that up at initialization time. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1612) jul LevelChangePropagator is inconsistent with SLF4JBridgeHandler
by QOS.CH (JIRA) 01 May '22

01 May '22

1 0