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">
      <!-- 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@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)

_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-dev

Reply via email to