[logback-user] Any way to tersely override portions of an included logback file?

logback users list logback-user at qos.ch
Thu Jun 8 20:14:42 CEST 2023


Hello David,

Variables defined in logback.xml, or as system properties or as
environment variables are intended for substitution functionality
elsewhere in the logback config file. I suggest that you try simpler
examples to convince you of this.

It may be possible that the stackTrace element of
LoggingEventCompositeJsonEncoder does not perform variable look up.
However, this is an omission on the part of that component.

HTH,

-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

On 6/8/2023 7:49 PM, logback users list via logback-user wrote:
> I posted this question to
> StackOverflow: https://stackoverflow.com/questions/76427762/can-i-override-portions-of-an-appender-defined-in-a-logback-include-file <https://stackoverflow.com/questions/76427762/can-i-override-portions-of-an-appender-defined-in-a-logback-include-file> .
> 
> And I had posted a similar question several months ago. I didn't get a
> response to the original query, and I have a feeling I won't get one on
> the new query.
> 
> Basically, I have a few hundred services that have a "logback.xml" file
> that includes a "baselogback.xml" file that is defined in a common
> place.  That "baselogback.xml" defines an appender and an encoder in
> that appender, and inside that encoder, it defines a "stackTrace"
> element that constrains the size of the stacktrace in logs.
> 
> I'm trying to determine reasonable options for overriding those settings
> in the "logback.xml" of the service itself. I'd prefer options that
> don't require me to simply copy the entire appender definition from the
> base and paste it into the service's logback.xml and then modify it.  At
> this point, there are only specific settings I want to override.
> 
> Another not ideal option is providing multiple "baselogback.xml" files
> in the same common location (with slightly different names, obviously)
> which represent commonly requested variations, like
> "baselogback.fullstacktrace.xml", and have the service's logback.xml
> include that one instead.  That still requires copying code and having
> to maintain two copies, but at least it's still in a common place, and
> not littered in all the services.
> 
> Any other reasonable ideas that can make this flexible without a lot of
> duplications?
> 


More information about the logback-user mailing list