From logback-user at qos.ch Thu May 4 15:14:40 2023 From: logback-user at qos.ch (logback users list) Date: Thu, 4 May 2023 14:14:40 +0100 Subject: [logback-user] Getting duplicate messages when using a custom Configurator Message-ID: 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> iter = logger.iteratorForAppenders(); iter.hasNext(); ) {         Appender 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 ruleRegistry = (Map) lc.getObject(CoreConstants.PATTERN_RULE_REGISTRY); if (ruleRegistry == null) { ruleRegistry = new HashMap<>(); lc.putObject(CoreConstants.PATTERN_RULE_REGISTRY, ruleRegistry); } registerConverters(ruleRegistry); Appender 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> iter = logger.iteratorForAppenders(); iter.hasNext(); ) { Appender 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> iter = logger.iteratorForAppenders(); iter.hasNext(); ) { Appender 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From logback-user at qos.ch Thu May 4 15:52:32 2023 From: logback-user at qos.ch (logback users list) Date: Thu, 4 May 2023 14:52:32 +0100 Subject: [logback-user] Getting duplicate messages when using a custom Configurator In-Reply-To: References: Message-ID: Hi again, Of course, I sent the email after spending all morning on it and then I worked it out. The problem was in the method I didn't send: @Override @SuppressWarnings("unchecked") public ExecutionStatus configure(LoggerContext lc) { configure(lc, !Strings.isNullOrEmpty(System.getenv(KUBERNETES_ENV_KEY))); return ExecutionStatus.DO_NOT_INVOKE_NEXT_IF_ANY; } I was returning ExecutionStatus.NEUTRAL, which I think was allowing BasicConfigurator to run after mine. As things stand now it shouldn't matter what order Configurators are called in, if mine is called first no others will be invoked and if mine is called last it clears everything else out. Jim On 04/05/2023 14:14, logback users list via logback-user wrote: > > 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> iter = logger.iteratorForAppenders(); iter.hasNext(); ) { >         Appender 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 ruleRegistry = (Map) lc.getObject(CoreConstants.PATTERN_RULE_REGISTRY); > if (ruleRegistry == null) { > ruleRegistry = new HashMap<>(); > lc.putObject(CoreConstants.PATTERN_RULE_REGISTRY, ruleRegistry); > } > registerConverters(ruleRegistry); > > Appender 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> iter = logger.iteratorForAppenders(); iter.hasNext(); ) { > Appender 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> iter = logger.iteratorForAppenders(); iter.hasNext(); ) { > Appender 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 > > > > > > _______________________________________________ > 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 May 12 19:56:19 2023 From: logback-user at qos.ch (logback users list) Date: Fri, 12 May 2023 19:56:19 +0200 Subject: [logback-user] Announcing investment by the Sovereign Tech Fund Message-ID: 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 From logback-user at qos.ch Wed May 17 11:30:36 2023 From: logback-user at qos.ch (logback users list) Date: Wed, 17 May 2023 15:00:36 +0530 Subject: [logback-user] Clarification for deleting old log file 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} 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From logback-user at qos.ch Fri May 19 11:26:15 2023 From: logback-user at qos.ch (logback users list) Date: Fri, 19 May 2023 14:56:15 +0530 Subject: [logback-user] Error while creating logback files 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 logback-user at qos.ch Tue May 23 09:19:30 2023 From: logback-user at qos.ch (logback users list) Date: Tue, 23 May 2023 07:19:30 +0000 Subject: [logback-user] Question regarding Logback 1.3.6 issue in supporting Jetty 10.0.15 request/access log In-Reply-To: References: Message-ID: 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 ../jetty/resources/logback-access.xml 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: