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-a... <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-a... <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)