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
