The rule above would *not* allow previously defined properties (in local scope) to be seen by SiftingJoranConfigurator. Users would be forced to define properties twice, once for SiftingAppender within SiftingAppender and once outside. I would probably better to simply inject currently defined properties into SiftingAppender so that it can inject it to its sub-components.
SiftAction could be modifed so that it can capture the properties in local scope and inject it into the SiftingAppender it's configuring. However, the InterpretationContext which contains the local properties does not expose a method for accessing all local properties. Such a method, say getCopyOfPropertyMap(), would need to be added. InterpretationContext implements the PropertyContainer interface. The Context interface extends PropertyContainer and ContextBase which most logback context's derive from, already implements the getCopyOfPropertyMap() method. I thus reckon that it would make sense to add getCopyOfPropertyMap() to the PropertyContainer interface.
This second solution is not significantly more complicated to implement but offers better usability.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Adding the following line into addInstanceRules() in ch.qos.logback.classic.sift.SiftingJoranConfigurator may be sufficient.
rs.addRule(new Pattern("configuration/property"), new PropertyAction());
This will allow writing
<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender">
<discriminator>
<key>threadId</key>
<defaultValue>unclassified</defaultValue>
</discriminator>
<sift>
<property name="LOG_HOME" value=".../>
<appender name="FILE-${threadId}" class="ch.qos.logback.core.FileAppender">
<file>${LOG_HOME}/thread-${threadId}.log</file>
<append>false</append>
<encoder><pattern>%d - %msg%n</pattern></encoder>
</appender>
</sift>
</appender>
The addition of this rule would also allow reading properties from files.Search for the example using variableSubstitution3.xml
in http://logback.qos.ch/manual/configuration.html#definingProps
solution 2)
The rule above would *not* allow previously defined properties (in local scope) to be seen by SiftingJoranConfigurator. Users would be forced to define properties twice, once for SiftingAppender within SiftingAppender and once outside. I would probably better to simply inject currently defined properties into SiftingAppender so that it can inject it to its sub-components.
SiftAction could be modifed so that it can capture the properties in local scope and inject it into the SiftingAppender it's configuring. However, the InterpretationContext which contains the local properties does not expose a method for accessing all local properties. Such a method, say getCopyOfPropertyMap(), would need to be added. InterpretationContext implements the PropertyContainer interface. The Context interface extends PropertyContainer and ContextBase which most logback context's derive from, already implements the getCopyOfPropertyMap() method. I thus reckon that it would make sense to add getCopyOfPropertyMap() to the PropertyContainer interface.
This second solution is not significantly more complicated to implement but offers better usability.