Skip to end of metadata
Go to start of metadata


Allow redirection to alternate logging API


Andrea Aime Martin Desruisseaux



You are debugging GeoTools, in a J2EE application, do you know where your logs are?


GeoTools currently uses Java Logging directly and allows for redirection to other logging systems using a handler, CommonHandler, redirecting log statements to commons logging, but not allowing to control the log level accurately. The downsides of this approach are discussed in these two threads:

The proposal here is to extend the org.geotools.util.Logging class with the following method:

And provide a global configuration option to change the kind of Logger produced:

Where the LoggerFactory interface generates the user desired Logger:

This factory class will return the most appropriate Logger implementation depending on the redirection set up:

  • when no redirection is in place, a standard java.util.logging.Logger will be returned.
  • when asking for redirection onto Log4j an special subclass of Logger will be returned that delegates everything to a wrapped Log4j logger, bypassing completely the java logging subsystem, and thus using directly handlers and logging levels as configured in Log4j. This is similar to providing an implementation of org.apache.commons.logging.Log interface except that instead of implementing every methods in an Apache's interface, we override every methods in a core Java class. More subclasses may be created in order to setup other redirections.

In order to have the above work, all GeoTools classes will have to switch to use org.geotools.util.Logging.getLogger(name) (this can be done by performing a search and replace on files). Applications depending on GeoTools will be able to use the same redirection mechanism.

The initial implementation will introduce two log factories:

  • CommonsLogger.Factory that will generate Commons-logging Log instances. These will delegate to Commons-logging;
  • Log4JLogger.Factory that will generate Log4J Logger instances. These will delegate directly to Log4J;
  • (not really an implementation) null, which is supposed to be the default, means to generate java logging loggers.

Users are then free to add their own redirection factories mimicking the code provided in CommonsLogger.Factory and Log4JLogger.Factory


This proposal is ready for discussion.




no progress






lack mandate/funds/time


volunteer needed

GeoTools 2.5 and 2.4:

API Changes


This example shows how redirection to Log4J is setup and how logging is used.
The example talks about commons logging, but since commons logging by default can redirect to java logging (no point in doing that) or to Log4J, we assume that commons logging is really used to redirect logging to Log4J.


Documentation Changes

  • 02 Integration Basics - including logging redirection in the steps needed to run GeoTools inside a J2EE environment
  • Logging - example of how to configure logging.
    Optional: provide a note explaining the why of the GeoTools logger factory with a link to Integration Basics
  • 5.1.3 Logging - code example of what must be done inside the library.
    Optional: provide a note explaining the why and how of the GeoTools logger factory.
  • No labels


  1. -1 vote for reasons voiced in previous IRC session. I favor the alternative of having geotools use a "de facto" logging facade, commons-logging or sl4j, as opposed to roll its own.

  2. Commons-Logging may be problematic (ClassLoaders issues, Hibernate, Jetty), but SLF4J could be an alternative. However my objection against SLF4J is the same one than against Commons-Logging: it is not a standard API. Only Java Logging is standard and bundled in every JVM 1.4+ distributions. Note that I'm pushing for the use of Java Logging API, not Java Logging implementation - I fully agree with letting peoples choose whatever implementation they like, but we need to agree on a standard API for that.

    My feeling is that Commons-Logging has been designed partially on emotional ground (except if Apache wanted Commons-Logging to run on pre-1.4 JVM). On a pure technical point on view, Apache could have overriden the Java Logger class instead of writting their own Log interface. But the fact that Sun created their own logging API instead of incorporating Log4J has been a source of frustration for some.

    Given that Java Logging API provides similar functionalities than Log4J (again I'm talking about API, not the range of available implementations - Log4J has implementations that Java Logging don't have, for example for logging through the network, etc.), maybe in a more object-oriented way (Log4J tends to be parameterized a little bit more through configuration Strings), and given that Java Logging is core Java API, it seems natural to me to adopt it as the standard API for logging in GeoTools. From that point, by creating Logger subclasses, we are simply doing what Apache should have done in the first place.