I think I've found a solution to this that solves all of my problems: I defined a RollingFileAppender in each application's separate log4j2.xml configuration file, all of which point to the same file (server.log) like the log4j2.xml used by GlassFish. I found from the source code that in this setup, all RollingFileAppenders do share the same RollingFileManager indeed, so concurrent writing to the file is no issue. To prevent one of the applications' appenders from actually performing a rollover and instead let the GlassFish appender do that, I defined a SizeBasedTriggeringPolicy in the applications' log4j2.xml with an exceedingly large size.
This has the positive side effect that only a single "Log4j2-Log4j2Scheduled-X" ever exists, regardless how often I redeploy any of the applications. Sorry for spamming the list with my work-in-progress thoughts, but maybe this is helpful for others facing similar problems. :) > But how could I then achieve that there's only a single thread that takes > care of the daily log rotation (the one defined in the log4j2.xml > configuration used as a system parameter for GlassFish) without screwing all > the other appenders? Could I use plain FileAppenders in the application > configurations? Or could I use RollingFileAppenders without any rotation > policies defined? --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
