Please look at the OnStartupTriggeringPolicy - On Jul 13, 2016, at 5:44 AM,
Laurent Hasson <[email protected]> wrote:
<http://logging.apache.org/log4j/2.x/manual/appenders.html#OnStartup_Triggering_Policy>
Ralph
>
>
> 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:[email protected]]
> Sent: Tuesday, July 12, 2016 20:52
> To: Log4J Users List <[email protected]>
> 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 <[email protected]> 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, [email protected] 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:[email protected]]
>>> 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:
>>>> [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
> --
> Matt Sicker <[email protected]>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
