From logback-user at qos.ch Thu Jun 8 19:49:10 2023 From: logback-user at qos.ch (logback users list) Date: Thu, 8 Jun 2023 10:49:10 -0700 Subject: [logback-user] Any way to tersely override portions of an included logback file? Message-ID: I posted this question to StackOverflow: 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From logback-user at qos.ch Thu Jun 8 20:14:42 2023 From: logback-user at qos.ch (logback users list) Date: Thu, 8 Jun 2023 20:14:42 +0200 Subject: [logback-user] Any way to tersely override portions of an included logback file? In-Reply-To: References: Message-ID: 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-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? > From logback-user at qos.ch Fri Jun 9 17:12:44 2023 From: logback-user at qos.ch (logback users list) Date: Fri, 9 Jun 2023 08:12:44 -0700 Subject: [logback-user] Any way to tersely override portions of an included logback file? In-Reply-To: References: Message-ID: 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> 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-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? > > > _______________________________________________ > 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: From logback-user at qos.ch Fri Jun 9 19:09:47 2023 From: logback-user at qos.ch (logback users list) Date: Fri, 9 Jun 2023 10:09:47 -0700 Subject: [logback-user] Any way to tersely override portions of an included logback file? In-Reply-To: References: Message-ID: 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> 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> 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-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? >> > >> _______________________________________________ >> logback-user mailing list >> logback-user at qos.ch >> https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user > > _______________________________________________ > 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: From logback-user at qos.ch Fri Jun 9 19:15:15 2023 From: logback-user at qos.ch (logback users list) Date: Fri, 9 Jun 2023 10:15:15 -0700 Subject: [logback-user] Any way to tersely override portions of an included logback file? In-Reply-To: References: Message-ID: 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 at 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 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> 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-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? >>> > >>> _______________________________________________ >>> logback-user mailing list >>> logback-user at qos.ch >>> https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user >> >> _______________________________________________ >> logback-user mailing list >> logback-user at qos.ch >> https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user > > _______________________________________________ > 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: From logback-user at qos.ch Fri Jun 9 19:18:12 2023 From: logback-user at qos.ch (logback users list) Date: Fri, 9 Jun 2023 19:18:12 +0200 Subject: [logback-user] Any way to tersely override portions of an included logback file? In-Reply-To: References: Message-ID: 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: %-4relative [%thread] %-5level %logger{35} -%kvp- %msg %n 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 > > 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 > > 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-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) From logback-user at qos.ch Fri Jun 9 19:28:07 2023 From: logback-user at qos.ch (logback users list) Date: Fri, 9 Jun 2023 10:28:07 -0700 Subject: [logback-user] Any way to tersely override portions of an included logback file? In-Reply-To: References: Message-ID: 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: exTrace 10 false 10240 To: exTrace ${maxDepthPerThrowable:-10} ${rootCauseFirst:-false} ${maxLength:-10240} And in each service's logback.xml, adding this line just before the include of "baselogback.xml": 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: > > > > > > %-4relative [%thread] %-5level %logger{35} -%kvp- %msg > %n > > > > > > > > > > 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 > > > 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 > > > 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-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: From logback-user at qos.ch Fri Jun 9 19:31:44 2023 From: logback-user at qos.ch (logback users list) Date: Fri, 9 Jun 2023 10:31:44 -0700 Subject: [logback-user] Any way to tersely override portions of an included logback file? In-Reply-To: References: Message-ID: 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 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: > > > exTrace > class="net.logstash.logback.stacktrace.ShortenedThrowableConverter"> > 10 > false > 10240 > > > > To: > > > exTrace > class="net.logstash.logback.stacktrace.ShortenedThrowableConverter"> > > ${maxDepthPerThrowable:-10} > > ${rootCauseFirst:-false} > ${maxLength:-10240} > > > > And in each service's logback.xml, adding this line just before the > include of "baselogback.xml": > > > > 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: >> >> >> >> >> >> %-4relative [%thread] %-5level %logger{35} -%kvp- %msg >> %n >> >> >> >> >> >> >> >> >> >> 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 >> > > 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 >> > > 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-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: From logback-user at qos.ch Fri Jun 9 19:32:25 2023 From: logback-user at qos.ch (logback users list) Date: Fri, 9 Jun 2023 10:32:25 -0700 Subject: [logback-user] Automatic reload works for "include"d files, but not property files Message-ID: Using logback 1.2.9. While testing some changes for overriding property values, I noticed that if I save a change to my "logback.xml" or in an xml file that I "include" from that file, logback will automatically reload with the specified interval. However, if I defined a "property" element referring to a properties file in that "logback.xml", and I save a change to that file, no automatic reload happens. Is that intended? -------------- next part -------------- An HTML attachment was scrubbed... URL: From logback-user at qos.ch Fri Jun 9 19:37:20 2023 From: logback-user at qos.ch (logback users list) Date: Fri, 9 Jun 2023 19:37:20 +0200 Subject: [logback-user] Automatic reload works for "include"d files, but not property files In-Reply-To: References: Message-ID: Not intentional but an omission. Please create a jira issue asking for this feature. Thank you for your recent sponsorship! -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 6/9/2023 7:32 PM, logback users list via logback-user wrote: > Using logback 1.2.9. > > While testing some changes for overriding property values, I noticed > that if I save a change to my "logback.xml" or in an xml file that I > "include" from that file, logback will automatically reload with the > specified interval.  However, if I defined a "property" element > referring to a properties file in that "logback.xml", and I save a > change to that file, no automatic reload happens.  Is that intended? > From logback-user at qos.ch Mon Jun 12 18:15:54 2023 From: logback-user at qos.ch (logback users list) Date: Mon, 12 Jun 2023 18:15:54 +0200 Subject: [logback-user] Logback in an OSGi application Message-ID: I develop an OSGi application and I like to upgrade the logging to slf4j 2.0.x and logback 1.4.7. Now I I can't get my application to work because logback shows the message 'Unresolved requirement: Require-Capability: osgi.serviceloader; osgi.serviceloader="ch.qos.logback.classic.spi.Configurator"'. How can I configure my application to satisfy this message? What bundle can I use that provide the requested Configurator? Best; Benno Luthiger -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceki at qos.ch Tue Jun 13 13:33:03 2023 From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=) Date: Tue, 13 Jun 2023 13:33:03 +0200 Subject: [logback-user] Logback in an OSGi application In-Reply-To: References: Message-ID: Hi Benno, I suspect this issue was fixed in LOGBACK-1736. See https://jira.qos.ch/browse/LOGBACK-1736 The fix is available in logback releases 1.3.8 and 1.4.8. Please let us know if it works for you. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 6/12/2023 6:15 PM, logback users list via logback-user wrote: > I develop an OSGi application and I like to upgrade the logging to slf4j > 2.0.x and logback 1.4.7. Now I > I can't get my application to work because logback shows the message > 'Unresolved requirement: Require-Capability: osgi.serviceloader; > osgi.serviceloader="ch.qos.logback.classic.spi.Configurator"'. How can I > configure my application to satisfy this message? What bundle can I use > that provide the requested Configurator? > > Best; > Benno Luthiger > > From boinarnaud at gmail.com Tue Jun 13 15:08:43 2023 From: boinarnaud at gmail.com (Arnaud B.) Date: Tue, 13 Jun 2023 15:08:43 +0200 Subject: [logback-user] [LOGBACK] : broken symlink in linux Message-ID: Hello, I need your help in creating log files by LOGBACK on LINUX environment, version 1.1.4. When starting the application server, it generates symbolic links between /proc//fd/ to /appli/test/log/server_fonc.log, appli/test/log/application.log, ... When using the LOGBACK rollover, for example, on the hast file, the application.log.5 file is deleted but it nevertheless generated a symbolic link between "/proc//fd/" and "/appli/test/log/application.log.5". Suddenly, I end up with a broken symbolic link and a message "/appli/test/log/application.log.5 (deleted)" via the command "lsof -nP +L1 | grep java" For what? Is this a logback issue? Or, an OS problem? Thank you in advance for your help ;) Example Configuration Logback for server_fonc.log : /application/test/log/applicatif.log TRACE %d;%level;%X{adresseIp};%X{sessionId};%X{Art ifactId};%X{Version};%logger;%marker;%m%n%ex{full} /appli/test/log/applicatif.log.%i 1 5 10MB -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceki at qos.ch Tue Jun 13 16:23:20 2023 From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=) Date: Tue, 13 Jun 2023 16:23:20 +0200 Subject: [logback-user] Release of logback versions 1.3.7 and 1.4.7 Message-ID: <7c01a6a4-fefa-1519-fe1e-4970c4417915@qos.ch> Hello all, I am happy to announce the simultaneous release of logback versions 1.3.8 and 1.4.8. Both versions require slf4j-api version 2.0.x or later. In addition to fixing several outstanding bugs, these releases add JsonEncoder which outputs logging events in Newline delimited JSON (ndjson) format. For more details, please refer to the the news page: http://logback.qos.ch/news.html We thank the Sovereign Tech Fund for kindly championing these releases. https://sovereigntechfund.de/en/ Why two simultaneous releases? Given that downstream users are likely to depend on either Java EE (in the javax namespace) or on Jakarta EE (in the jakarta namespace) in their projects, it was deemed important for logback to support both EE alternatives. As such, logback 1.3.x supports Java EE whereas logback 1.4.x supports Jakarta EE, otherwise the two versions are feature identical. Both 1.3.x and 1.4.x series require the fluent-API introduced in SLF4J 2.0.x. The 1.3.x series requires Java 8 at runtime. If you wish to build logback from source, you will need Java 9. The 1.4.x series requires Java 11 at build time and at runtime. Groovy configuration: Support for Groovy configuration was dropped for security reasons but was recovered by Tucker Pelletier (virtualdogbert). See: https://github.com/virtualdogbert/logback-groovy-config Benchmarks: For benchmarking figures please see: http://logback.qos.ch/performance.html Reproducible builds: Recent logback releases are reproducible. This means that anyone checking out the code corresponding to the release version from github and building that local copy, will get obtain an identical binary to the binary found on Maven central. Note that due to issue MJAR-275 with the module-info.java produced in earlier java versions, reproducible builds require Java 19. Donations and sponsorship You can also support SLF4J/logback/reload4j projects via donations and sponsorship. We thank our current supporters and sponsors for their continued contributions and in particular The Sovereign Tech Fund, Spotify R&D and Exoscale. Sponsorship link: https://github.com/sponsors/qos-ch Announcement mailing list: You can receive SLF4J/logback/reload4j related announcements by subscribing QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce Enjoy, -- Ceki Gülcü From luthiger at gmail.com Tue Jun 13 18:08:24 2023 From: luthiger at gmail.com (Benno Luthiger) Date: Tue, 13 Jun 2023 18:08:24 +0200 Subject: [logback-user] Logback in an OSGi application In-Reply-To: References: Message-ID: Dear Ceki Thanks for the hint. Using release 1.4.8 helped indeed. Best, Benno On Tue, 13 Jun 2023 at 13:33, Ceki Gülcü via logback-user < logback-user at qos.ch> wrote: > > > Hi Benno, > > I suspect this issue was fixed in LOGBACK-1736. > > See https://jira.qos.ch/browse/LOGBACK-1736 > > The fix is available in logback releases 1.3.8 and 1.4.8. > > Please let us know if it works for you. > > -- > Ceki Gülcü > > Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch > > > On 6/12/2023 6:15 PM, logback users list via logback-user wrote: > > I develop an OSGi application and I like to upgrade the logging to slf4j > > 2.0.x and logback 1.4.7. Now I > > I can't get my application to work because logback shows the message > > 'Unresolved requirement: Require-Capability: osgi.serviceloader; > > osgi.serviceloader="ch.qos.logback.classic.spi.Configurator"'. How can I > > configure my application to satisfy this message? What bundle can I use > > that provide the requested Configurator? > > > > Best; > > Benno Luthiger > > > > > _______________________________________________ > 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: From supraja286 at gmail.com Wed Jun 14 11:29:21 2023 From: supraja286 at gmail.com (supraja prabhakaran) Date: Wed, 14 Jun 2023 14:59:21 +0530 Subject: [logback-user] Error while deleting logback Message-ID: Am using logback.xml to generate logs.Trying to delete the created logfile greater than 10 ( will have 10 logs files ) and delete oldest file from server. Creating the log file for every min. ${LOGS}/archived/spring-boot-logger.%d{yyy-MM-dd_HH-mm}_%d{HHmmss,aux}.log 10 issue : when I have this %d{HHmmss,aux} the log file are not deleting and keeps generating in the server. After I remove that command it deleting files -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceki at qos.ch Sat Jun 17 21:30:48 2023 From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=) Date: Sat, 17 Jun 2023 21:30:48 +0200 Subject: [logback-user] Error while deleting logback In-Reply-To: References: Message-ID: <9c1f01d1-c51f-0eca-27e1-6465cc548ff3@qos.ch> Hello Supraja, Here is what the documentation states: ------------------------ Multiple %d specifiers It is possible to specify multiple %d specifiers but only one of which can be primary, i.e. used to infer the rollover period. All other tokens must be marked as auxiliary by passing the 'aux' parameter (see examples below). Multiple %d specifiers allow you to organize archive files in a folder structure different than that of the roll-over period. For example, the file name pattern shown below organizes log folders by year and month but roll-over log files every day at midnight. /var/log/%d{yyyy/MM, aux}/myapplication.%d{yyyy-MM-dd}.log ---------------- Source: https://logback.qos.ch/manual/appenders.html#tbrpFileNamePattern Notice that the secondary (aux) %d specifier given before the primary specifier. The secondary specifier is used to create folders. Have you tried that? -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 6/14/2023 11:29 AM, supraja prabhakaran via logback-user wrote: > Am using logback.xml to generate logs.Trying to delete the created > logfile greater than 10 ( will have 10 logs files ) and delete oldest > file from server. Creating the log file for every min. > > > > > ${LOGS}/archived/spring-boot-logger.%d{yyy-MM-dd_HH-mm}_%d{HHmmss,aux}.log > > 10 > > > issue : when I have this %d{HHmmss,aux} the log file are not deleting > and keeps generating in the server. After I remove that command it > deleting files > From luthiger at gmail.com Sun Jun 18 17:35:10 2023 From: luthiger at gmail.com (Benno Luthiger) Date: Sun, 18 Jun 2023 17:35:10 +0200 Subject: [logback-user] ServletContainerInitializer cannot be found by ch.qos.logback.classic_1.4.8 (in OSGi application) Message-ID: Hello everybody, In my OSGi application, I use *ch.qos.logback.classic* (1.4.8) for logging. For this reason I have included, among others, the bundle ch.qos.logback.classic_1.4.8. However, this leads to the following error message: *java.lang.ClassNotFoundException: jakarta.servlet.ServletContainerInitializer cannot be found by ch.qos.logback.classic_1.4.8* I get this error even when I have started the bundle jakarta.servlet-api_6.0.0 (containing jakarta.servlet.ServletContainerInitializer). How should I proceed to solve this problem? Best, Benno -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceki at qos.ch Sun Jun 18 18:35:20 2023 From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=) Date: Sun, 18 Jun 2023 18:35:20 +0200 Subject: [logback-user] ServletContainerInitializer cannot be found by ch.qos.logback.classic_1.4.8 (in OSGi application) In-Reply-To: References: Message-ID: <5c1ecad5-6c7c-847b-9ea2-f751c0266b98@qos.ch> Hello Benno, jakarta.servlet.ServletContainerInitializer is a service declaration found under logback-classic/META-INF/services/. It contains a reference to the ch.qos.logback.classic.servlet.LogbackServletContainerInitializer class. This class ships with logback-classic. There is also an instruction in logback-classic/pom.xml for the maven-bundle-plugin declaring jakarta.servlet.ServletContainerInitializer as a a service provided by LogbackServletContainerInitializer. This is a recapitulation of the intended state and things should work reasonably well in a OSGi environment. Which OSGi platform/application are you using? -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 6/18/2023 5:35 PM, Benno Luthiger via logback-user wrote: > Hello everybody, > > In my OSGi application, I use /ch.qos.logback.classic/ (1.4.8) for logging. > > For this reason I have included, among others, the bundle ch.qos.logback.classic_1.4.8. However, this leads to the following error message: > > /java.lang.ClassNotFoundException: > jakarta.servlet.ServletContainerInitializer cannot be found by > ch.qos.logback.classic_1.4.8/ > > I get this error even when I have started the bundle jakarta.servlet-api_6.0.0 (containing jakarta.servlet.ServletContainerInitializer). > > How should I proceed to solve this problem? > > Best, > Benno > > From luthiger at gmail.com Mon Jun 19 00:14:40 2023 From: luthiger at gmail.com (Benno Luthiger) Date: Mon, 19 Jun 2023 00:14:40 +0200 Subject: [logback-user] ServletContainerInitializer cannot be found by ch.qos.logback.classic_1.4.8 (in OSGi application) In-Reply-To: <5c1ecad5-6c7c-847b-9ea2-f751c0266b98@qos.ch> References: <5c1ecad5-6c7c-847b-9ea2-f751c0266b98@qos.ch> Message-ID: Dear Ceki > Which OSGi platform/application are you using? I use Eclipse Equinox (*org.eclipse.osgi_3.18.300.v20230220-1352.jar*) as container for my OSGi application. Best, Benno On Sun, 18 Jun 2023 at 18:35, Ceki Gülcü via logback-user < logback-user at qos.ch> wrote: > > Hello Benno, > > jakarta.servlet.ServletContainerInitializer is a service declaration > found under logback-classic/META-INF/services/. It contains a reference > to the > ch.qos.logback.classic.servlet.LogbackServletContainerInitializer class. > This class ships with logback-classic. > > There is also an instruction in logback-classic/pom.xml for the > maven-bundle-plugin declaring > jakarta.servlet.ServletContainerInitializer as a a service provided by > LogbackServletContainerInitializer. > > This is a recapitulation of the intended state and things should work > reasonably well in a OSGi environment. > > Which OSGi platform/application are you using? > > -- > Ceki Gülcü > > Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch > > On 6/18/2023 5:35 PM, Benno Luthiger via logback-user wrote: > > Hello everybody, > > > > In my OSGi application, I use /ch.qos.logback.classic/ (1.4.8) for > logging. > > > > For this reason I have included, among others, the bundle > ch.qos.logback.classic_1.4.8. However, this leads to the following error > message: > > > > /java.lang.ClassNotFoundException: > > jakarta.servlet.ServletContainerInitializer cannot be found by > > ch.qos.logback.classic_1.4.8/ > > > > I get this error even when I have started the bundle > jakarta.servlet-api_6.0.0 (containing > jakarta.servlet.ServletContainerInitializer). > > > > How should I proceed to solve this problem? > > > > Best, > > Benno > > > > > _______________________________________________ > 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: From bruno.ballekens at waylay.io Tue Jun 20 20:46:40 2023 From: bruno.ballekens at waylay.io (Bruno Ballekens) Date: Tue, 20 Jun 2023 20:46:40 +0200 Subject: [logback-user] JsonEncoder Message-ID: Hi, i like very much the JsonEncoder that you've added to 1.4.8. Previously we worked with ch.qos.logback.contrib.jackson.JacksonJsonFormatter, but great to see it now natively supported. However, i've stumbled upon the fact that it does not put the "formatted message" in the json payload. It puts the message and the argument array. Some of the libs we use, dolog using the message format based methods, which now look strange in our log aggregation system (sometimes we even see {} as the message with then the actual message as the single member of the argument array). I checked the code of the JsonEncoder and do not see any configuration based way of having the formatted in the json payload (preferably with the "message" key). Do you foresee something like this in the future ? Or do we need to subclass the JsonEncoder ? Thanks Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From boinarnaud at gmail.com Wed Jun 21 10:38:55 2023 From: boinarnaud at gmail.com (Arnaud B.) Date: Wed, 21 Jun 2023 10:38:55 +0200 Subject: [logback-user] HELP! Need help while deleting logback file (broken symlink - Linux) Message-ID: Hello, I need your help in creating log files by LOGBACK (v 1.1.4) on LINUX environment. When starting the application server, it generates symbolic links between /proc//fd/ to /appli/test/log/server_fonc.log, appli/test/log/application.log, ... When using the LOGBACK rollover, for example, on the hast file, the application.log.5 file is deleted but it nevertheless generated a symbolic link between "/proc//fd/" and "/appli/test/log/application.log.5". Suddenly, I end up with a broken symbolic link and a message "/appli/test/log/application.log.5 (deleted)" via the command "lsof -nP +L1 | grep java" For what? Is this a logback issue? Or, an OS problem? Any solution? Thank you in advance for your help ;) Example Configuration Logback for server_fonc.log : /application/test/log/applicatif.log TRACE %d;%level;%X{adresseIp};%X{sessionId};%X{Art ifactId};%X{Version};%logger;%marker;%m%n%ex{full} /appli/test/log/applicatif.log.%i 1 5 10MB Best, Arnaud BOIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceki at qos.ch Wed Jun 21 10:55:40 2023 From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=) Date: Wed, 21 Jun 2023 10:55:40 +0200 Subject: [logback-user] HELP! Need help while deleting logback file (broken symlink - Linux) In-Reply-To: References: Message-ID: <332299f2-980a-3af7-7298-5552bddddbfc@qos.ch> Hi Arnaud, I suggest that rolling be made using TimeBasedRollingPolicy [1] or with SizeAndTimeBasedRollingPolicy [2]. These two rolling policies do NOT rename or move files so that the issues you describe do not occur. In contrast, FixedWindowRollingPolicy renames files which can cause problems such as the one you describe. [1] https://logback.qos.ch/manual/appenders.html#TimeBasedRollingPolicy [2] https://logback.qos.ch/manual/appenders.html#SizeAndTimeBasedRollingPolicy -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 6/21/2023 10:38 AM, Arnaud B. via logback-user wrote: > Hello, > > I need your help in creating log files by LOGBACK (v 1.1.4) on LINUX > environment. > > When starting the application server, it generates symbolic links between > /proc//fd/ to /appli/test/log/server_fonc.log, > appli/test/log/application.log, ... > > When using the LOGBACK rollover, for example, on the hast file, the > application.log.5 file is deleted but it nevertheless generated a symbolic > link between "/proc//fd/" and "/appli/test/log/application.log.5". > > Suddenly, I end up with a broken symbolic link and a message > "/appli/test/log/application.log.5 (deleted)" via the command "lsof -nP > +L1 | grep java" > > For what? Is this a logback issue? Or, an OS problem? Any solution? > Thank you in advance for your help ;) > > Example Configuration Logback for server_fonc.log : >       name="GENERAL_APPENDER" class="ch.qos.logback.core.rolling.RollingFileAppender"> >              /application/test/log/applicatif.log >                >                    TRACE >                 >               >                    %d;%level;%X{adresseIp};%X{sessionId};%X{Art > ifactId};%X{Version};%logger;%marker;%m%n%ex{full} >                     >                 >               >   >                     > /appli/test/log/applicatif.log.%i >                     1  >                     5  >                 >                 > >                         10MB  >                   >         > > Best, > > Arnaud BOIN > From ceki at qos.ch Wed Jun 21 11:27:49 2023 From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=) Date: Wed, 21 Jun 2023 11:27:49 +0200 Subject: [logback-user] JsonEncoder In-Reply-To: References: Message-ID: Hello Bruno, Thank you for your kind words. They are much appreciated. Can you please create the a jira issue asking for a formatted message in JsonEncoder as an option? Regards, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 6/20/2023 8:46 PM, Bruno Ballekens via logback-user wrote: > Hi, > > i like very much the JsonEncoder that you've added to 1.4.8. > Previously we worked with > ch.qos.logback.contrib.jackson.JacksonJsonFormatter, but great to see it > now natively supported. > > However, i've stumbled upon the fact that it does not put the "formatted > message" in the json payload. It puts the message and the argument array. > Some of the libs we use, dolog using the message format based methods, > which now look strange in our log aggregation system (sometimes we even > see {} as the message with then the actual message as the single member > of the argument array). > > I checked the code of the JsonEncoder and do not see any configuration > based way of having the formatted in the json payload (preferably with > the "message" key). > Do you foresee something like this in the future ?  > Or do we need to subclass the JsonEncoder ? > > Thanks > Regards > >