Allow GeoServer to play well in a container that controls logging

Here is a token patch to demonstrate interest in this issue...

It allows a user to turn off GeoServer-controlled logging and let the container manage the logs. I've primarily tested this with JBoss 4.0.3SP1 and log4j, however I believe it is possible to have pure Java logging by:
1. Removing LoggingStartupContextListener from the listener chain in web.xml
2. Explicitly routing Commons Logging routing to the Jdk14Logger (Acegi and Spring use Commons Logging), using commons-logging.properties in the class path.

The code follows the pattern of org.vfny.geoserver.global.GeoServerDataDirectory, defining RELINQUISH_LOGGING_CONTROL as a system property and as a web.xml context-param. It makes use of GeoServer.suppressLoggingConfiguration() which was originally designed for testing purposes only. The patch is against 1.6.4b.

I've also provided a context listener (SuppressLoggingConfigurationContextListener) that users can insert into their listener chain in web.xml – allowing a user with a stock 1.6.4b to tell GeoServer to relinquish logging control. This way, users can work around the issue now, without having to compile in a patch.

To use SuppressLoggingConfigurationContextListener, put SuppressLoggingConfigurationContextListener.class into WEB-INF/classes/org/geoserver/logging/ and modify WEB-INF/web.xml to add it to its listener list:

<listener>
<listener-class>org.geoserver.logging.SuppressLoggingConfigurationContextListener</listener-class>
</listener>

This should go after GeoserverInitStartupListener and LoggingStartupContextListener.

Justin, I was looking into LoggingInitializer and it seems to me that despite suppressLoggingConfiguration being true the logging subsystem is initialized at least once anyways.
Beside that, I'd like to make that class a little more flexible vs logging, in particular:

• would be nice to have a user setting allowing the user to specify the logging redirection (LOG4J or java logging?)
• would be nice to have a user setting allowing the user to decide wheter we mess with the log configuration as well.

These can be done in a way similar to the one suggested by Ryan, by checking web.xml and system properties.
As for the testing hack, we can have the testing set the required system variable instead and thus kill the static reference.
What do you think?

Hi Justin, I'm looking into implementing this one and I have a few questions.
The way to implement this in 1.7.x onwards seems to handle log disabling into the LoggingInitializer.
Now, to be able and read a configuration out of the web.xml file, I need the servlet context, which can be obtained in various way, for example by being a spring context listener.
The logging initializer is registered into the spring context, but has different roles depending on the branch:

• on trunk, it's just registered in the spring context, and then loaded by GeoServerLoader as a post process extension that comes to live after the catalog is loaded
• on 1.7.x, it's not registered in the Spring context and called directly

First off, the proper way is the 1.7.x one, at least timing wise: the logging must be initialized as the very first thing, because all of the other code does logging. If my memory serves me right, on 1.6.x it was configured at least partially by a listener configured in the web.xml for that very reason.

Yet, the 1.7.x way does not allow the initializer to access the WebApplicationContext, needed to read data from the servlet context, whilst the trunk way allows for one.

Ideas for an implementation:

• separate GeoServerInitializer into pre and post initializers that will be registered in the application context, make the logging one a pre one, and make sure the pre ones are executed before the catalog is loaded
• keep on using the 1.7.x way (direct call) and make GeoServerExtension serve out also the web.xml init parameters, something like GeoServerExtensions.getInitParameter("myParam"), and have that method look into the system properties, the enviroment, and the web.xml, so that all externally customizable params are read the same way (and then have GeoServerDataDirectory use this method, if possible, instead of its own findGeoServerDataDir(ServletContext): String.

So, to summarize, I would need two things:

• a suggestion on how to deal with the logging initialization so that it can be controlled from external variables (enviroment, system property, web.xml)
• an idea on why the trunk and 1.7.x are so different code wise (is it on purporse, or a commit is missing)?

So the code is so different because a number of things had to change to switch over to xstream based persistence on trunk. As for how to proceed with GeoServerInitializer, i really like your idea of breaking out two interfaces, one for pre and one for post. And then yes register it in the spring context to get a access to the servlet context, etc...

Full fix committed on trunk, with logging configuration in a listener that gets executed before everything else, and also the possibility to instruct GeoServer to redirect to java logging or to commons logging instead

Fix committed on 1.7.x as well. Now I only need back a usable wiki to update the docs.

Andrea, how does this relate to GEOS-2284. I have a fix for that but its sort of hackish... I am wondering if this patch somehow related to it.

Added documentation at http://geoserver.org/display/GEOSDOC/Delegate+logging+control+to+the+container