logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joachim Kanbach" <jo...@gmx.de>
Subject How to consolidate Server and Application Logging in GlassFish?
Date Tue, 01 Mar 2016 14:19:36 GMT
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message