Cheryl, From the looks of things you created it correctly. FWiW, the Dell - Internal Use stuff at the top of your message really should be deleted. This is a public message list archived for all time, so nothing is confidential here.
Ralph > On Jul 12, 2016, at 3:02 PM, cheryl_mrozien...@dell.com wrote: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
