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

logback users list logback-user at qos.ch
Fri Jun 9 19:18:12 CEST 2023

Can  you provide a super simplified example of what you wish to
accomplish? In your example please use ConsoleAppender.

By the way, which version of logback are you using?

Here is a start:


  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
      <pattern>%-4relative [%thread] %-5level %logger{35} -%kvp- %msg

  <root level="DEBUG">
    <appender-ref ref="STDOUT" />

On 6/9/2023 7:09 PM, logback users list via logback-user wrote:
> Because, for instance, I can add a "property" element to the
> "baselogback.xml" to define the property and its value, but then it
> appears that any attempt to override that value from the "logback.xml"
> in the service is ignored.
> On Fri, Jun 9, 2023 at 8:13 AM logback users list via logback-user
> <logback-user at qos.ch <mailto:logback-user at qos.ch>> wrote:
>     I've managed to verify a setup where my "stacktrace" element in the
>     "baselogback.xml" references properties, and my "logback.xml" in a
>     service first specifies a properties file before including
>     "baselogback.xml". That lets me control the properties in that
>     element in the "baselogback.xml" from properties in the service.
>     Now I'm looking at the situation where if the "baselogback.xml" is
>     changed in this way, but the service's "logback.xml" is NOT changed,
>     then those properties don't have values, which doesn't cause a
>     failure, it just appears to set them to their default values.  Is
>     there some way, in the "baselogback.xml", I can set the default
>     values for those properties, so that if the service's logback.xml
>     doesn't set them, they will use the defaults instead?
>     On Thu, Jun 8, 2023 at 11:14 AM logback users list via logback-user
>     <logback-user at qos.ch <mailto:logback-user at qos.ch>> wrote:
>         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
>         <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> <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?
>         >
>         ______________________________

Support Team
QOS.CH Sarl (Switzerland)

More information about the logback-user mailing list