Dell - Internal Use - Confidential Hi Ralph and Remko, Sorry for the delay in responding and thank you for your advice. I hope I entered the jira issue correctly. See https://issues.apache.org/jira/browse/LOG4J2-1462
I looked into the RoutingAppender and the "Injectable context properties" jira issue a bit and will look into it some more as time permits. Given the amount of legacy code we currently have in our product, I'm currently guessing this approach may not be feasible for us. I was really hoping that this issue was just a bug that had already been fixed in a newer version. Thanks for considering fixing this issue in a way that would allow us to continue to use just a basic RollingFileAppender. Regards, -Cheryl -----Original Message----- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Thursday, July 07, 2016 8:03 PM To: Log4J Users List Subject: Re: defer creation of RollingFileAppender log files when Logger and/or AppenderRef level attribute has a value of "OFF"? In addition, I would suggest creating a Jira issue describing this. I would think adding a deferOpen option to defer opening the OutputStream until the first write occurs might be possible. Ralph > On Jul 7, 2016, at 3:59 PM, Remko Popma wrote: > > Cheryl, > > Just thinking out loud, Log4j 2 has the ability to start logging to a new log > file that is not explicitly defined in configuration with the > RoutingAppender. See > https://logging.apache.org/log4j/2.x/faq.html#separate_log_files > > You may be able to use this feature, perhaps in combination with a custom > Filter. The Filter would usually DENY all log events, but would start to > ACCEPT events for certain products when these products were selected in some > admin gui. > > This solution would require that all log events have the relevant product ID > or something in their context map. Currently the only way to put data in the > LogEvent's context map is via the ThreadContext. (There is a ticket to make > this customizable: https://issues.apache.org/jira/browse/LOG4J2-1010). > > Can you think about whether these together can form a solution? Maybe > experiment a little with a test program, to see what obstacles come up. > > Remko > > Sent from my iPhone > >> On 2016/07/08, at 4:26, wrote: >> >> Dell - Internal Use - Confidential >> Hi, >> >> I am currently using Log4j version 2.3, but might be able to update to a >> newer version if that would help. >> >> I have a log4j2.xml file containing more than thirty RollingFileAppenders >> (one per product component). Most of these RollingFileAppenders will not be >> written to until the user turns on logging via our product's user interface. >> By default, the AppenderRefs that reference these RollingFileAppenders have >> the "level" attribute set to a value of "OFF". Once the user turns on >> logging from the user interface, the "level" attribute will be updated with >> a value of "INFO", "DEBUG", etc. And, once the updated log4j2.xml file is >> persisted, the code will then call LoggerContext.reconfigure() to get Log4j >> to read in the new log4j2.xml file, so the new log levels take effect. >> >> My question is whether there is a way to tell Log4j to defer log file >> creation when nothing will initially write to the file (e.g. all references >> to the Appender have a level of "OFF")? Having lots of zero sized log files >> is not that big of an issue, although not completely optimal. However, >> having too many open file handles that are not doing anything, could >> potentially become an issue. Note that I do not have control over the number >> of Appenders configured for the product. Each product component team >> contributes its Appender and Loggers to log4j2.xml. >> >> To work around the open file handle issue at server startup time, I am >> currently using the Log4j2 private core API calls to loop through the >> AppenderRefs to determine which ones are "OFF", and then I'm calling the >> RollingFileAppender.stop() method to close the output stream. If anyone has >> any ideas that would avoid creating and opening the log files in the first >> place, I'd love to hear your thoughts. >> >> Thanks and regards, >> >> -Cheryl >> >> p.s. for reference, the relevant log4j2.xml snippets follow: >> >> >> <RollingFile >> fileName="${sys:com.compellent.msaserviceDir}/etc/compservices/debuglogs/Scheduler/Scheduler.debuglog" >> filePattern="${sys:com.compellent.msaserviceDir}/etc/compservices/debuglogs/Scheduler/Scheduler_%i.debuglog.gz" >> name="debug.Scheduler"> >> >> %d{yyyy-MM-dd HH:mm:ss,SSS} %-5p {%C:%M} [%marker] (%t) - %msg%n >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
