RoutingAppender with parameterized pattern/nested RollingFileAppender/evaluateOnStartup

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RoutingAppender with parameterized pattern/nested RollingFileAppender/evaluateOnStartup

Joachim Kanbach
Hi all,

I'm using a configuration with two nested RoutingAppenders like this:

<Routing name="ApplicationRouting">
  <Routes pattern="$${ctx:applicationName}">
    <Route key="SomeApplication">
      <Routing name="ThreadRouting">
        <Routes pattern="$${ctx:threadId}">
          <Route>
            <RollingFile name="SomeApplicationLog"
                  fileName="${sys:com.sun.aas.instanceRoot}/logs/someapplication/${ctx:applicationName}-${ctx:threadId}.log"
                  filePattern="${sys:com.sun.aas.instanceRoot}/logs/someapplication/${ctx:applicationName}-${ctx:threadId}.log.$${date:yyyyMMdd}">
                  <Policies>
                    <CronTriggeringPolicy schedule="0 0 0 * * ?" evaluateOnStartup="true"/>
                  </Policies>
                </RollingFile>
              </Route>
            </Routes>
          </Routing>
        </Route>
       
      [...]

So the idea is to split log files for different applications running on this Payara instance (hence the com.sun.aas.instanceRoot references), and then again for different processing threads.

This works all nicely, including rollover. The only thing that doesn't work, and I'm not surprised by that, is the evaluateOnStartup attribute. Due to the dynamic patterns, Log4j obviously has no chance of knowing which files to rollover if the JVM is restarted. As long as it keeps running, the appenders apparently keep track of those files and therefore perform the rollover.

Another related issue is that even for files that would not need to be rolled over on startup because they were modified on the same day still, those files that don't get written to again after startup will also not be picked up by the next rollover. Again, Log4j can't know about those files.

As for files that would need to be rolled on startup; I could write some application code that scans for files matching my expected pattern(s) and simulates the rollover. But in the second case, it appears to me that I would need to use some tricks like triggering output to all log files in order to make them "known" to the Log4j appenders.

Has anyone found an elegant solution to this?


Best regards,
Joachim Kanbach

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...