Sorry, I forgot the other question you asked. We're using logback 1.2.9.
On Fri, Jun 9, 2023 at 10:28 AM David Karr <davidmichaelk...@gmail.com>
wrote:
> 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@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@qos.ch <mailto:logback-user@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@qos.ch <mailto:logback-user@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@qos.ch
>> https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user
>
>
_______________________________________________
logback-user mailing list
logback-user@qos.ch
https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user
