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: [email protected]
For additional commands, e-mail: [email protected]
