On 2023-02-16 at 03:53 Frank Upgang wrote:

Hello,

we noticed the same bug using a SiftingAppender in Spring Boot applications. We make use of <include>, too. But the problem also arises without inclusion.

The following test case (inspired by SimpleRuleStoreTest) shows that no matching action is found for configuration/springProfile/appender/sift :

    @Test
    void sift() {
        SimpleRuleStore srs = new SimpleRuleStore(new ContextBase());

        // as in logbacks JoranConfiguratorBase
        srs.addRule(new ElementSelector("configuration/appender/sift"), () -> new XAction());
        srs.addTransparentPathPart("sift");

        // as in Spring Boots SpringBootJoranConfigurator
        srs.addRule(new ElementSelector("*/springProfile"), () -> new XAction());
        srs.addTransparentPathPart("springProfile");

        Supplier<Action> supplier = srs.matchActions(new ElementPath("configuration/springProfile/appender/sift"));
        assertNotNull(supplier); // supplier is null
    }

The SimpleRuleStore's matching algorithm implementation may be the problem here. After there is no exact math, no suffix and no prefix match the transparent path parts are removed.

In this case these are springProfile and sift. Thus the cleaned element path is configuration/appender.

This does not match any action in the above test case and no action for the sifting appender in our real use case.

Perhaps the transparent paths should be removed stepwise (from left to right), thus matching configuration/appender/sift (after removing springProfile) in a first iteration.

If desired I could help with a pull request.
In this case please further specify the expected behavior for handling transparent paths.

Thank you!