Any way to tersely override portions of an included logback file?
I posted this question to StackOverflow: https://stackoverflow.com/questions/76427762/can-i-override-portions-of-an-a... . 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?
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-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?
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> 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-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?
_______________________________________________ logback-user mailing list logback-user@qos.ch https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user
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> 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> 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-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?
_______________________________________________ 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
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@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@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> 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-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?
_______________________________________________ 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
_______________________________________________ logback-user mailing list logback-user@qos.ch https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user
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)
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-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) _______________________________________________ logback-user mailing list logback-user@qos.ch https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user
participants (1)
-
logback users list