September 2022 - logback-dev

[JIRA] (LOGBACK-1677) EnvUtil.getVersion does not work under JMPS
by QOS.CH (JIRA) 14 Sep '22

14 Sep '22

1 0

[JIRA] Updates for LOGBACK-1676: logback-access cannot be used with Jetty 9.4.48.v20220622
by QOS.CH (JIRA) 13 Sep '22

13 Sep '22

logback / LOGBACK-1676 [Open] logback-access cannot be used with Jetty 9.4.48.v20220622 ============================== 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-1676 ============================== Issue created ------------------------------ Dr. Domagoj Ćosić created this issue on 13/Sep/22 9:27 PM Summary: logback-access cannot be used with Jetty 9.4.48.v20220622 Issue Type: Bug Affects Versions: 1.3.0 Assignee: Logback dev list Components: logback-access Created: 13/Sep/22 9:27 PM Priority: Major Reporter: Dr. Domagoj Ćosić Description: There two flaws preventing usage wir that version, despite of dependencies page in the documentation declaring the compatibility: # logback-access declares dependency on Servlet API 4.0.0 (manifest) or 4.0.1 (documentation). Jetty 9.4.48 provides only a Servlet API 3.1 compliant implementation (see https://www.eclipse.org/jetty/) Is 4.x a real requirement? # logback-access specifies version=“9.4.48.v20220622” for all Jetty packages in Import-Package. Jetty 9.4.48.v20220622 declares *bundle-version*=“9.4.48.v20220622” for all packages in Export-Package but *version*=“9.4.48”. Version “9.4.48” < “9.4.48.v20220622” when it comes to comparing, so the requirement cannot be matched. Jetty packages cannot be wired. Loading Jetty classes by logback-access thus fails (but not the resolution prior to it, dependencies are optional). ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1675: Fluff in logback-parent pom.xml
by QOS.CH (JIRA) 13 Sep '22

13 Sep '22

logback / LOGBACK-1675 [Open] Fluff in logback-parent pom.xml ============================== Here's what changed in this issue in the last few minutes. This issue has been created View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1675 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 13/Sep/22 5:22 PM Summary: Fluff in logback-parent pom.xml Issue Type: Task Affects Versions: 1.4.0 Assignee: Ceki Gülcü Created: 13/Sep/22 5:22 PM Priority: Major Reporter: Ceki Gülcü ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1675) Fluff in logback-parent pom.xml
by QOS.CH (JIRA) 13 Sep '22

13 Sep '22

1 0

[JIRA] (LOGBACK-1673) Unreferenced appenders cause elements containing them to be ignored with logback 1.3.0
by QOS.CH (JIRA) 09 Sep '22

09 Sep '22

1 0

[JIRA] Updates for LOGBACK-1674: Nested Appenders within AsyncAppender no longer work
by QOS.CH (JIRA) 07 Sep '22

07 Sep '22

logback / LOGBACK-1674 [Open] Nested Appenders within AsyncAppender no longer work ============================== 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-1674 ============================== Issue created ------------------------------ Luke Stephenson created this issue on 07/Sep/22 2:57 PM Summary: Nested Appenders within AsyncAppender no longer work Issue Type: Bug Affects Versions: 1.3.0, 1.4.0 Assignee: Logback dev list Created: 07/Sep/22 2:57 PM Priority: Major Reporter: Luke Stephenson Description: Previously in older versions of logback the following was valid: {code:java} <configuration> <appender name="STDOUT-ASYNC" class="ch.qos.logback.classic.AsyncAppender"> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="com.foo.SomeEncoder"/> </appender> </appender> <root level="${ROOT_LOG_LEVEL:-info}"> <appender-ref ref="STDOUT-ASYNC"/> </root> </configuration> {code} With logback 1.3.0 and 1.4.0 this fails with: {code:java} 22:49:33,671 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [STDOUT-ASYNC] 22:49:33,671 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [ch.qos.logback.classic.AsyncAppender] 22:49:33,673 |-WARN in ch.qos.logback.core.model.processor.AppenderModelHandler - Appender named [STDOUT] not referenced. Skipping further processing. 22:49:33,673 |-ERROR in ch.qos.logback.classic.AsyncAppender[STDOUT-ASYNC] - No attached appenders found. {code} To get it to work, I have to switch to the "appender-ref" style. {code:java} <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="com.zendesk.logging.JsonLogEncoder"/> </appender> <appender name="STDOUT-ASYNC" class="ch.qos.logback.classic.AsyncAppender"> <appender-ref ref="STDOUT" /> </appender> <root level="${ROOT_LOG_LEVEL:-info}"> <appender-ref ref="STDOUT-ASYNC"/> </root> </configuration> {code} Not sure if this an intentional change to drop support for the format we used earlier, or a bug. Thanks ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1668) RollingCalendarTest#testCollisionFreeness failing on "my machine"
by QOS.CH (JIRA) 04 Sep '22

04 Sep '22

1 0

[JIRA] (LOGBACK-1558) Fix for code that fails existing tests
by QOS.CH (JIRA) 04 Sep '22

04 Sep '22

1 0

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

04 Sep '22

1 0

[JIRA] Updates for LOGBACK-1673: Unreferenced appenders cause elements containing them to be ignored with logback 1.3.0
by QOS.CH (JIRA) 02 Sep '22

02 Sep '22

logback / LOGBACK-1673 [Open] Unreferenced appenders cause elements containing them to be ignored with logback 1.3.0 ============================== 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-1673 ============================== Issue created ------------------------------ Juan Pablo Santos Rodríguez created this issue on 02/Sep/22 12:50 PM Summary: Unreferenced appenders cause elements containing them to be ignored with logback 1.3.0 Issue Type: Bug Affects Versions: 1.3.0 Assignee: Logback dev list Components: logback-core Created: 02/Sep/22 12:50 PM Priority: Major Reporter: Juan Pablo Santos Rodríguez Description: having some sort of configuration like {code} <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>[%date{HH:mm:ss.SSS}][%5level][%logger{40}][%msg]%n%rootException</pattern> </encoder> </appender> <logger name="org.perrycorp" level="INFO"> <appender-ref ref="STDOUT" /> <appender-ref ref="DOES_NOT_EXIST" /> </logger> </configuration> {code} does not apply any appenders to {{org.perrycorp}} logger. Behaviour on 1.2.X was to apply known appenders, ignoring not existing appenders. We have more complex use cases where we define some appenders based on some properties being passed, applying one or another: {code} <logger name="org.perrycorp" level="INFO"> <if condition='!isNull( "logback.logstash.destinations" )'><then> <appender-ref ref="LOGSTASH_APPENDER" /> </then></if> <if condition='isNull( "logback.logstash.destinations" )'><then> <appender-ref ref="STDOUT" /> </then></if> </logger> {code} in these kind of cases one of the two appenders isn't going to be declared which, with Logback 1.3.0, causes the configuration to not attach any appender to {{org.perrycorp}} logger. Same thing occurs on custom appenders like the one noted on LOGBACK-551. Workaround for the last case is to provide dummy appenders and overwrite instead of define the appenders inside the corresponding {{<if>}} elements (doable but not funny for us, so we'd appreciate if the old behaviour could be brought back) ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0