- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1717) Reduce the memory footprint with GraalVM native image
by logback developers list 04 Apr '23

04 Apr '23

1 0

[JIRA] (LOGBACK-1717) Reduce the memory footprint with GraalVM native image
by logback developers list 04 Apr '23

04 Apr '23

1 0

[JIRA] Updates for LOGBACK-1732: Log file pollution when using the <include> in a conditional block
by logback developers list 03 Apr '23

03 Apr '23

logback / LOGBACK-1732 [Open] Log file pollution when using the <include> in a conditional block ============================== 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-1732 ============================== Issue created ------------------------------ Terry van der Griend created this issue on 03/Apr/23 11:45 Summary: Log file pollution when using the <include> in a conditional block Issue Type: Bug Affects Versions: 1.4.6 Assignee: Logback dev list Components: logback-classic Created: 03/Apr/23 11:45 Environment: spring boot application 3.x.x Labels: conditional include Priority: Major Reporter: Terry van der Griend Description: We are migration from Logback 1.2.11 to 1.4.7 and stumbled upon some log pollution. When a <include> element is used the and it is not able to resolve the file two entries are added to the log. {code:java} 11:00:18,521 |-INFO in ch.qos.logback.core.joran.util.ConfigurationWatchListUtil@43ed0ff3 - Adding [file:/C:/dev/include_IS_UNDEFINED] to configuration watch list. 11:00:18,522 |-WARN in ch.qos.logback.core.joran.action.IncludeAction - Failed to open [file:/C:/dev/include_IS_UNDEFINED] {code} This is correct as the variable is currently undefined and logback is not able to include it yet. So yes I would expect to see these statement in the log. However when placing an <include> element inside an <if> block I would not expect these statement to be included, as it should try to read the configuration. h3. Reproduction configuration: {code:java} <configuration debug="true">  <variable scope="system" name="include" value="C:/dev/include.xml"/> <if condition='isDefined("include")'> <then> <include file="${include}"/> </then> </if> </configuration> {code} Using the following configuration will result into the following log statements: {code:java} 11:15:44,779 |-INFO in ch.qos.logback.core.joran.util.ConfigurationWatchListUtil@6de54b40 - Adding [file:/C:/dev/include_IS_UNDEFINED] to configuration watch list. 11:15:44,779 |-WARN in ch.qos.logback.core.joran.action.IncludeAction - Failed to open [file:/C:/dev/include_IS_UNDEFINED] 11:15:45,593 |-INFO in ch.qos.logback.core.model.processor.conditional.IfModelHandler - Condition [isDefined("include")] evaluated to true on line 3 {code} What we have noticed is that the IncludeAction is processed before the variable is set. I would expect that the <include> element is only processed when the condition has been met. In the first line we see that <include> element is already being processed before the Condition or Variable have been processed. Now in the second line it is trying to open the file which it can't. On the third line we can see that the Condition actually is succeeding as the Variable has now been processed. h3. Expectations: I would expect that the IncludeAction would take place in the order of definition: # Variable "include" is set # If condition is processed and matches # File include is executed But what we see is the following: # File include is executed # Variable "include" is set # If condition is processed and matches This would result into lesser log statements, ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for LOGBACK-1731: <include> element only seems to be substituting variables which are on scope "system"
by logback developers list 03 Apr '23

03 Apr '23

logback / LOGBACK-1731 [Open] <include> element only seems to be substituting variables which are on scope "system" ============================== 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-1731 ============================== Issue created ------------------------------ Terry van der Griend created this issue on 03/Apr/23 11:07 Summary: <include> element only seems to be substituting variables which are on scope "system" Issue Type: Bug Affects Versions: 1.4.6 Assignee: Logback dev list Components: logback-core Created: 03/Apr/23 11:07 Environment: Spring boot application 3.x.x Labels: include substitution variable Priority: Major Reporter: Terry van der Griend Description: {code:java} // code placeholder {code} We are migration from Logback 1.2.11 to 1.4.7 and stumbled upon on an issues regarding the <include file=""> element. When the <include file=""> element is used in combination with a <variable> as its value, it is not able to include the file when the variable is not on the scope "system". Logback will keep trying to add the file to the ConfigurationWatchListUtil with the "_IS_UNDEFINED" replacement. h3. Our case: We are using logback via spring to load a file, this is done based on the configured file location using a <springProperty>. When investigating further we have noticed that this issue is not unique to the <springProperty> but also includes the <variable> and <property> elements. h3. Reproduction configuration: {code:java} <configuration debug="true"> <variable name="include" value="<other file location>.xml"/> <include file="${include}"/> </configuration> {code} When using the provided configuration the "include" variable is not substituted in the file element. It tries to substitute it, but it is not able to resolve its value. However when using the following configuration: {code:java} <configuration debug="true"> <variable scope="system" name="include" value="<other file location>.xml"/> <include file="${include}"/> </configuration> {code} Now the file will be included. Using any other scope then "system" will result into an "_IS_UNDEFINED" file inclusion. h3. Workaround: For now we have found a workaround which we are not very keen on to keep using. By offloading the original variable onto a system scoped variable we are able to include the file. This does mean that we are exposing unwanted variable on the system properties which we would rather not. Offloading a <springProperty> to a <variable> with the system scope also seems to work. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1727) Logback: After upgrading to 1.3.6 with SLF4J 2.0.4, logs are being written to unknown.log file.
by logback developers list 29 Mar '23

29 Mar '23

1 0

[JIRA] (LOGBACK-1711) Deadlock when using Virtual Threads
by logback developers list 27 Mar '23

27 Mar '23

1 0

[JIRA] (LOGBACK-1713) AppenderFactory not set in SiftingAppender
by logback developers list 24 Mar '23

24 Mar '23

1 0

[JIRA] (LOGBACK-1581) logback-access should not use Request.getParameterNames
by logback developers list 23 Mar '23

23 Mar '23

1 0

[JIRA] Updates for LOGBACK-1730: logback-classic exports obsolete/removed package 'org.slf4j.impl' in OSGi runtimes
by logback developers list 23 Mar '23

23 Mar '23

logback / LOGBACK-1730 [Open] logback-classic exports obsolete/removed package 'org.slf4j.impl' in OSGi runtimes ============================== 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-1730 ============================== Issue created ------------------------------ Hannes Wellmann created this issue on 23/Mar/23 17:48 Summary: logback-classic exports obsolete/removed package 'org.slf4j.impl' in OSGi runtimes Issue Type: Bug Affects Versions: 1.3.6, 1.4.6 Assignee: Logback dev list Components: logback-classic Created: 23/Mar/23 17:48 Priority: Minor Reporter: Hannes Wellmann Description: Since SLF4J 2 the connection between SLFJ4 and its providers is established via the Service Loader mechanism, which is enabled in OSGi runtimes using a Service Loader Mediator. The package 'org.slf4j.impl' no longer exists in the logback-classic bundle and therefore can not and need no longer be exported. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1729) Add OSGi Service Loader Mediator entries to load logback Configurators
by logback developers list 23 Mar '23

23 Mar '23

1 0