[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:28:07 CEST 2023
I actually think I've gotten something that will work, although I have
another question related to this that I think I'll post in a separate
question.
In our "baselogback.xml", I will change this:
<stackTrace>
<fieldName>exTrace</fieldName>
<throwableConverter
class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
<maxDepthPerThrowable>10</maxDepthPerThrowable>
<rootCauseFirst>false</rootCauseFirst>
<maxLength>10240</maxLength>
</throwableConverter>
</stackTrace>
To:
<stackTrace>
<fieldName>exTrace</fieldName>
<throwableConverter
class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
<maxDepthPerThrowable>${maxDepthPerThrowable:-10}</maxDepthPerThrowable>
<rootCauseFirst>${rootCauseFirst:-false}</rootCauseFirst>
<maxLength>${maxLength:-10240}</maxLength>
</throwableConverter>
</stackTrace>
And in each service's logback.xml, adding this line just before the include
of "baselogback.xml":
<property file="....logback-custom.properties"/>
Where the contents of this file might be:
maxDepthPerThrowable = 200
rootCauseFirst = false
maxLength = 10240
The ":-" markers in "baselogback.xml" set the defaults, so if a service
doesn't make any change, they will still get the defaults.
On Fri, Jun 9, 2023 at 10:18 AM logback users list via logback-user <
logback-user at qos.ch> wrote:
>
> 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:
>
> <configuration>
>
> <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
> %n</pattern>
> </encoder>
> </appender>
>
> <root level="DEBUG">
> <appender-ref ref="STDOUT" />
> </root>
> </configuration>
>
>
> 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)
> _______________________________________________
> 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/b9cad8b8/attachment.htm>
More information about the logback-user
mailing list