[logback-dev] [JIRA] Updates for LOGBACK-1732: Log file pollution when using the <include> in a conditional block

[logback developers list]

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 at 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">
      <!-- I placed the variable on the scope "system" as this is another bug. https://jira.qos.ch/browse/LOGBACK-1731 -->
      <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 at 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)