logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laurent Hasson" <...@CapsicoHealth.com>
Subject Add a pattern to the first rolling file created...
Date Wed, 13 Jul 2016 12:44:32 GMT
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:boards@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.goers@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_Mrozienski@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.goers@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-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >>
> >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>


--
Matt Sicker <boards@gmail.com>


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message