Hi all, I'm trying to achieve the following setup:
1) Replace the JUL logging used by all Java EE implementations in GlassFish 4.1 with Log4j2 2) Deploy multiple web applications to GlassFish and have both the server log and all application log(s) be written to the same file (server.log) The reason why I want to merge the server and application log is (for example) to have the JPA generated SQL statement debug output go along with the application log. Otherwise, one would have to look up the corresponding SQL statements in server.log based on the timestamps from the application log. Ultimately, I want to split the consolidated server/application log to different files again, using the Thread Context feature and fish tagging or something similar. I've achieved 1) by using SLF4J with the Log4j2 binding implementation. I also tried to use the JUL adapter provided by Log4j2, but that led to the problem that the log messages were not resolved with the resource bundles anymore, i.e. the log output contained only those internal message codes used by GlassFish/the various Java EE specification implementations, like "AS-WEB-GLUE-00198" etc., but no human-readable text. So I placed jul-to-slf4j-1.7.13.jar, slf4j-api-1.7.13.jar, log4j-api-2.5.jar, log4j-core-2.5.jar, and log4j-slf4j-impl-2.5.jar in the folder [...]/glassfish/domains/domain1/lib/ext and modified the GlassFish logging.properties to use the SLF4JBridgeHandler. I also created a log4j2.xml configuration, which I specify in the system properties for starting up GlassFish. This all works nicely, all the JUL output including the server initialization is redirected to Log4j2 now. But I think the way I've (seemingly) solved 2) is wrong: a) At first, I used the single log4j2.xml configuration file used by GlassFish itself for all my application modules, i.e. I didn't explicitly specify a different configuration in my web.xml files. I deployed log4j-web-2.5.jar with each application module. This approach had two problems: for one, all applications shared a single LoggerContext, which caused irritating output in the Log4j status logging upon deployment of the applications. The name of that LoggerContext was basically determined by the last application deployed. When re-deploying an application (from my IDE Eclipse), things were apparently screwed up even more because new LoggerContexts would sometimes be created then. For two, logging did not work during the shutdown process. I tried playing around with the shutdownHook attribute, but that made no difference. b) Then I added a context-param to each web.xml, defining the log4jConfiguration: I pointed them all to the same configuration file used by GlassFish itself. Now all my applications have their own, properly named LoggerContext and all the logging (still) goes to the single appender I defined, which writes to server.log. Also, logging continues to work during the shutdown process (e.g. if I redeploy an application module). But I believe that this is merely by chance since I must have different appender instances now that write to a single file concurrently. Or is Log4j2 able to handle this, after all the API and core classes are all loaded by the same classloader ...? If not, can someone think of another way to achieve this server/application logging consolidation? On top of this, I have another problem: I use a RollingFile appender that performs daily rotation. Because I want to keep empty log files upon rotation, I made a little extension that I posted here: http://stackoverflow.com/questions/32378201/in-log4j2-how-to-configure-renameemptyfiles-to-be-false-for-the-rollingfile-app/34791646#34791646. Placing this in a JAR file in [...]/glassfish/domains/domain1/lib works fine (this can't go to /ext because I also use some Java EE classes in it for controlling the rollover of the GlassFish HTTP access log). But if I use solution b) from above, now I have one "Log4j2-Log4jScheduled-X" thread for each application. This seems logical to me, as every LoggerContext apparently has its own RollingFile appender instance now. However, I don't understand why each redeployment of one of the applications leads to a new running "Log4j2-Log4jScheduled-X" thread. The Log4j status log even says "DEBUG Stopping Log4j2Scheduled threads.", but those old threads simply don't go away. This also happened when 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
