- logback-user - mailman3.qos.ch

Release of logback versions 1.3.7 and 1.4.7
by Ceki Gülcü 13 Jun '23

13 Jun '23

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ü

1 0

[LOGBACK] : broken symlink in linux
by Arnaud B. 13 Jun '23

13 Jun '23

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/<PID>/fd/<NUM> 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/<PID>/fd/<NUM>" 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 : <appender name="GENERAL_APPENDER" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/application/test/log/applicatif.log</file> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>TRACE</level> </filter> <encoder> <Pattern>%d;%level;%X{adresseIp};%X{sessionId};%X{Art ifactId};%X{Version};%logger;%marker;%m%n%ex{full}</Pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>/appli/test/log/applicatif.log.%i</fileNamePattern> <minIndex>1</minIndex> <maxIndex>5</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>10MB</maxFileSize> </triggeringPolicy> </appender>

1 0

Automatic reload works for "include"d files, but not property files
by logback users list 09 Jun '23

09 Jun '23

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?

1 1

Re: [logback-user] Any way to tersely override portions of an included logback file?
by logback users list 09 Jun '23

09 Jun '23

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 <davidmichaelkarr(a)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(a)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(a)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(a)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-… >> < >> https://stackoverflow.com/questions/76427762/can-i-override-portions-of-an-…> >> < >> https://stackoverflow.com/questions/76427762/can-i-override-portions-of-an-… >> < >> https://stackoverflow.com/questions/76427762/can-i-override-portions-of-an-…>> >> . >> > > >> > > 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(a)qos.ch >> https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-user > >

1 0

Any way to tersely override portions of an included logback file?
by logback users list 09 Jun '23

09 Jun '23

I posted this question to StackOverflow: https://stackoverflow.com/questions/76427762/can-i-override-portions-of-an-… . 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?

1 6

Question regarding Logback 1.3.6 issue in supporting Jetty 10.0.15 request/access log
by logback users list 23 May '23

23 May '23

Dear Logback team, This is Wenbin from OpenText. Hope this Email finds you well. As we are using Logback for our logging system. It was working perfectly before our latest upgrade from Jetty 9.4 to Jetty 10.0.15. For this upgrade, we upgraded Logback into compatible version 1.3.6. But we encountered one issue around Jetty request log, which did NOT log anything. We configured the logback as proposed to add the following part in jetty.xml. and configured well the logback-access.xml as before while using Jetty 9.4 <Set name="requestLog"> <New class="ch.qos.logback.access.jetty.RequestLogImpl" id="LogbackAccess"> <Set name="fileName">../jetty/resources/logback-access.xml</Set> </New> </Set> Would you help to advise? Is there any known issue in supporting Jetty 10.0.15 request/access log in logback 1.3.6? Looking forward to your early reply and thanks in advance! Regards, Wenbin

1 0

Error while creating logback files
by logback users list 19 May '23

19 May '23

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. <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${LOGS}/archived/spring-boot-logger.%d{yyy-MM-dd_HH-mm}_%d{HHmmss,aux}.log </fileNamePattern> <maxhistory>10</maxhistory> </rolling policy> 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

1 0

Clarification for deleting old log file
by logback users list 17 May '23

17 May '23

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. <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${LOGS}/archived/spring-boot-logger.%d{yyy-MM-dd_HH-mm}_%d{HHmmss,aux}.log </fileNamePattern> <maxhistory>10</maxhistory> </rolling policy> issue : when I have this %d{HHmmss,aux} then maxhistory property doesn't work (it won't delete old logs) and keeps generating in the server. When I remove %d{HHmmss} this command it delete log files as expected. Here i want nameing pattern like this {YYY-MM-dd-HH-mm-ss} and want to delete file worth 10mins

1 0

Announcing investment by the Sovereign Tech Fund
by logback users list 12 May '23

12 May '23

Hello all, In addition to preexisting support from companies such as Google, Exolab and Spotify R&D, we are excited to announce a sustained and multi-year investment from the Sovereign Tech Fund (STF) for the maintenance and improvement of logback, SLF4J and reload4j projects [1]. In 2006, we founded the SLF4J and logback projects and continue to maintain them until this day. Cumulatively, the artifacts of these two projects are downloaded over 4 billion times per year. Given the sheer volume of users, maintaining the SLF4J and logback projects can be rather time consuming. In 2022, we started the reload4j project with the goal of fixing critical security issues in log4j 1.x. We wish to continue providing the most reliable, fast and flexible logging framework for Java developers and heartily thank the STF for choosing to invest in our projects. The Sovereign Tech Fund supports the development, improvement and maintenance of digital infrastructure. Their goal is to sustainably strengthen the open source ecosystem, with a focus on security, resilience, technological diversity, and the people behind the projects. As Cailean Osborne aptly put it [2]: “As one of the first governmental funds dedicated to OSS, the STF is spearheading a critical shift in how governments invest in the long-term viability of OSS and digital public goods." In our own experience, even the tiniest token of support counts. It goes without saying that a larger multi-year investment counts all the more. We would like to express our gratitude to the Sovereign Tech Fund for their support and for paving the way for this historical change. [1] https://tinyurl.com/stfLogback [2] https://tinyurl.com/stfCaileanOsborne -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

1 0

Getting duplicate messages when using a custom Configurator
by logback users list 04 May '23

04 May '23

Hi, I have a custom Configurator installed via META_INF.services in a bunch of different services. I do it this way because I was finding that managing logback.xml files across a lot of different services was awkward and unnecessary log levels were leaking into production. I also have a custom class for changing specific log levels based on env vars or system properties, and a vertx router for changing them dynamically at runtime. All of this has been working work a few years, but I have recently found that in some circumstances I'm getting duplicate messages (at first it was just in some builds, but now it's in production so I need to do something about it). I've added a load of debug spew to my classes, but it appears that the default configuration is being applied after my custom Configurator and I can't work out what is causing that. And, of course, right now I can only reproduce this by executing a jar on the command line, rather than in a unit test. My main method looks like this: public static void main(String[] args) { Main main = new Main(args); logger.info("Starting ({})", LoggerFactory.getILoggerFactory()); LoggerContext lc = ((LoggerContext) LoggerFactory.getILoggerFactory()); System.out.println(lc.getName()); for (ch.qos.logback.classic.Logger logger : lc.getLoggerList()) { System.out.println("\t" + logger.getName()); for (Iterator<Appender<ILoggingEvent>> iter = logger.iteratorForAppenders(); iter.hasNext(); ) { Appender<ILoggingEvent> a = iter.next(); System.out.println("\t\t" + a.getName()); } } // irrelevant stuff here } and my custom Configurator is this: /** * Perform the configuration. * @param lc The LoggerContext to configure. * @param asJson If true then logs will be recorded as JSON. */ public void configure(LoggerContext lc, boolean asJson) { @SuppressWarnings("unchecked") Map<Object, Object> ruleRegistry = (Map<Object, Object>) lc.getObject(CoreConstants.PATTERN_RULE_REGISTRY); if (ruleRegistry == null) { ruleRegistry = new HashMap<>(); lc.putObject(CoreConstants.PATTERN_RULE_REGISTRY, ruleRegistry); } registerConverters(ruleRegistry); Appender<ILoggingEvent> appender; if (asJson) { appender = configureJsonOutput(lc, createConsoleAppender(lc)); } else { appender = configureMultiLineOutput(lc, createConsoleAppender(lc)); } appender.start(); System.out.println(lc.getName()); for (Logger logger : lc.getLoggerList()) { System.out.println("\t" + logger.getName()); for (Iterator<Appender<ILoggingEvent>> iter = logger.iteratorForAppenders(); iter.hasNext(); ) { Appender<ILoggingEvent> a = iter.next(); System.out.println("\t\t" + a.getName()); } logger.detachAndStopAllAppenders(); } Logger rootLogger = lc.getLogger(Logger.ROOT_LOGGER_NAME); rootLogger.addAppender(appender); rootLogger.setLevel(Level.INFO); rootLogger.setAdditive(true); System.out.println(lc.getName()); for (Logger logger : lc.getLoggerList()) { System.out.println("\t" + logger.getName()); for (Iterator<Appender<ILoggingEvent>> iter = logger.iteratorForAppenders(); iter.hasNext(); ) { Appender<ILoggingEvent> a = iter.next(); System.out.println("\t\t" + a.getName()); } } } The output from this is: NOTE: Picked up JDK_JAVA_OPTIONS: -server -XX:-OmitStackTraceInFastThrow default ROOT default ROOT STDOUTPUT 2023-05-04 12:55:18.653 [main] c.groupgti.shared.configservice.Main INFO - Starting (ch.qos.logback.classic.LoggerContext[default]) 13:55:18.653 [main] INFO com.groupgti.shared.configservice.Main -- Starting (ch.qos.logback.classic.LoggerContext[default]) default ROOT STDOUTPUT console com com.groupgti com.groupgti.shared com.groupgti.shared.configservice com.groupgti.shared.configservice.Main + more packages So my custom Configurator is running, but then (I think when the static loggers are created) the console appender is being added to the ROOT logger. I tried naming my appender "console", that just resulted in two appenders called "console" :) How can I stop the default "console" appender being added to root? Thanks Jim

1 1