Difficulty because of nested 'if' support removal

[bresalio-nagy-dynata]

I'd like to initiate a discussion about the fact that you no more support nested 'if'-s under , and elements since 1.3 version.

I used to have a log config in logback-spring.xml file, the appender in which looked like this:

<appender class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <springProfile name="local">
                <jsonGeneratorDecorator
                        class="net.logstash.logback.decorate.PrettyPrintingJsonGeneratorDecorator"/>
            </springProfile>

            <!-- many other configs that are independent of springProfile -->
        </encoder>
</appender>

The LogstashEncoder declares many configs that are independent of springProfile, and it defines 1 config, pretty printing, which should take effect only if springProfile is "local".

Until not long ago, this worked fine. However, since upgrading the app to Spring 3, which uses 1.4.7 logback version instead of 1.2.11, we receive an error message that the no longer supports nested 'if'-s (including ), and this can yield unexpected results.

In the doc where you write about this new requirement, you make the argument that everything that was solved with a nested 'if' before, can be solved with an external 'if'. And I understand that this is theoretically true.

However, I experience that in practice, this results in code duplications. In my situation, if I define the element externally, then I need to define 2 appenders - one of them containing the extra config for pretty printing, the other not -, to be referred from the different springProfiles, while they are common in every other config. And if I later decide to change a config that's common between all springProfiles (e.g. a timestamp format, or field's name in the output JSON), then I will have to rewrite it at 2 places. So the 2 copies of the same encoder, differing in just 1 config (pretty printing), are difficult to maintain.

I'm asking your advice about what workaround could be applied in such a situation: whether it's possible to resolve the error message without having to duplicate the appender.

Of course, a trivial solution would be if you switched back to supporting nested 'if'-s in the future versions. But I guess you stopped doing so intentionally, so I assume this won't happen.

And what I can also imagine, would be to support extending encoders from each other. (Like Java classes, but without having to write custom Java code - it would be important to keep being able to configure every logging-related stuff from just XML.) Then the appender that should contain the extra config for "local" springProfile, should not copy the common configs, it should just extend the basic encoder, and it would inherit its configs, and also in case of future changes, it would be enough to rewrite in just the parent.

Please answer how (and whether) it could be solved somehow now, and what you plan for the future versions. ^_^

[bresalio-nagy-dynata]

Update: we found a NullJsonGeneratorDecorator class, with which - by making the decorator class a springProfile-dependent property - we managed to solve the need (to use pretty printing conditionally) without having to duplicate the appender.