;known" to the Log4j appenders.
Has anyone found an elegant solution to this?
Best regards,
Joachim Kanbach
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
tionName} too.
I searched the changelog but couldn't find anything about it. Did someone else
encounter this bug?
Best regards,
Joachim Kanbach
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
foreseen for
"out-of-the-box" configuration of Log4j2 yet, since it only mentions servlet
container initialization?
Best regards,
Joachim Kanbach
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
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 impleme
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
R
Ok, I will write up my findings in some days. I still want to look into my
original plan first to split up the consolidated server.log into separate
files, based (e.g.) on Thread Context. It's only then that having replaced JUL
with Log4j2 in GlassFish creates a big benefit. But I have to work o
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 se
I just saw some information in the Log4j documentation that makes me believe
that my solution b) would actually work, particularly if I use a separate
configuration for each application that uses a RollingFileAppender writing to
the same file:
"While RolloverFileAppenders from different Configu
en I tried solution a) above, but at
least there's only one thread as long as I don't redeploy any of the
applications.
Best regards,
Joachim Kanbach
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org