Hello, I would like to be able to add a pattern to the main logging file so that a new file is created each time my server is re-started. This is the guts of our config file:
<Properties> <Property name="log-path">C:\Projects\TomcatDevServer\logs\</Property> <Property name="now">${sys:startup}</Property> </Properties> <Appenders> <RollingFile name="FILES" fileName="${log-path}/capsico.log" filePattern="${log-path}/capsico.${now}.%i.log.gz"> <PatternLayout> <pattern>%d{MMdd.HHmmss.SSS}#%-3t %level{length=1} %15.15c{1}| %m%ex{20}%n</pattern> </PatternLayout> <Policies> <SizeBasedTriggeringPolicy size="100 MB" /> </Policies> <DefaultRolloverStrategy max="99999" compressionLevel="9"/> </RollingFile> <Async name="ASYNC"> <AppenderRef ref="FILES" /> </Async> </Appenders> I have tried to add a pattern to the "filename" property for <RollingFile> but without success. This means that right now, if the server is re-started, the logging continues right into the existing file (everything else regarding the rolling logic works as expected). All I'd want is for a simple timestamp to be added, like the filePattern, and if possibly, have the same timestamp of the system start reused. I think I am missing something quite basic here? I am on log4J 2.5 on Java 8. Laurent Hasson Co-Founder and CTO CapsicoHealth Inc. -----Original Message----- From: Matt Sicker [mailto:boa...@gmail.com] Sent: Tuesday, July 12, 2016 20:52 To: Log4J Users List <log4j-user@logging.apache.org> Subject: Re: defer creation of RollingFileAppender log files when Logger and/or AppenderRef level attribute has a value of "OFF"? Could be automatically added. My work email does that with an obnoxiously long signature. On 12 July 2016 at 18:44, Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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 > > -- Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org