[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:15:15 CEST 2023


Ah, got it:
https://logback.qos.ch/manual/configuration.html#defaultValuesForVariables .

On Fri, Jun 9, 2023 at 10:10 AM logback users list via logback-user <
logback-user at qos.ch> 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> 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> 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
>>>
>>> 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?
>>> >
>>> _______________________________________________
>>> logback-user mailing list
>>> logback-user at qos.ch
>>> https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user
>>
>> _______________________________________________
>> logback-user mailing list
>> logback-user at qos.ch
>> https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user
>
> _______________________________________________
> logback-user mailing list
> logback-user at qos.ch
> https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20230609/ff280786/attachment.htm>


More information about the logback-user mailing list