Ok, once again I have to correct myself only moments later.
Actually, the CronTriggeringPolicy defined in the GlassFish log4j2.xml
configuration DOES still trigger like before, AND the RollingFileManager
performs the rollover.
But the reason why it works makes me think I'm exploiting an implementation
detail. I debugged the running server instance and found that when the
CronTriggeringPolicy fires, it directly calls RollingFileManager.rollover().
The fact that this RollingFileManager has a TriggeringPolicy field that does
NOT include the CronTriggeringPolicy has no effect, the content of the field is
not used on this control flow.
On the other hand, when a log event occurs, control flows from the class
AppenderControl to RollingFileManager.checkRollover(event). And here, the
triggeringPolicy IS actually evaluated:
public synchronized void checkRollover(final LogEvent event) {
if (triggeringPolicy.isTriggeringEvent(event)) {
rollover();
}
}
So the SizeBasedTriggeringPolicy defined in my applications' configuration does
override the one defined at the server level, but the CronBasedTriggeringPolicy
doesn't.
I can live with this for the moment, but it appears fragile to me.
> I'm afraid I was talking too soon: the reason that the other threads went
> away is because my CronTriggeringPolicy was removed from the
> RollingFileManager. I debugged and looked at the source; both the
> RolloverStrategy and the TriggeringPolicy are stored with the
> RollingFileManager and NOT the RollingFileAppender. So when my applications
> got deployed, their configuration overwrote the shared RollingFileManager's
> TriggeringPolicy, i.e. no cron triggering occurs anymore. I'll have to find a
> different solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
