Re: Some consideration on GeoServer logging

Hello all

Every issues raided by Andrea are of course legitimates. I will post some
possible paths below.

As Justin point out, commons-logging is widely used in server applications. But
this is one community; other communities (e.g. scientists) use different
frameworks. For example UCAR's NetCDF library uses SLF4J. UCAR provides a JAR
that redirect NetCDF loggings to java.util.logging, but they do not provide a
JAR that redirect them to common-login; we have to get it elswhere (SLF4J web
site provides a migration path *away* from commons-login).

Commons-login is reputed to have class-loader problems that other framework
don't have: http://www.qos.ch/logging/classloader.jsp

There is also the logging events sent by the JVM itself, which use Java logging.
Of course we can decide that JVM logs are not of interest.

Also, are you sure that common-loging would work with Glassfish? This guys seems
to had a lot of trouble getting Log4J to work with Glassfish (please take also a
look at the comments):

http://weblogs.java.net/blog/schaefa/archive/2007/08/to_the_hell_wit_1.html

I would like to quote "whartung"'s comment from the above page. He explain well
my view (again I'm not critizing common-login goals; I question the solution
that Apache choose for reaching those goals):

    "Commons-logging took the wrong approach layering on top of the
     various logging systems, when it should have simply changed the
     plumbing that JDK Logging provides, and then provide a sugary
     layer on top of JDK Logging."

Note that this is actually what JULI started to do (unfortunatly a little bit
late). I believe that JULI is a good approach that commons-loggin should have
taken right from the begining...

--------------------------------------------------------------------

Now some possible approachs:

If we really want to use something like commons-login, maybe we should
investigate first if SLF4J could be a better replacement. Note that SLF4J may
suffer the same problems than common-login regarding JVM and Glassfish loggings.

My personal preference is of course to fix the issues we have with java login.
The easiest fix is to create a java.util.logging.Logger subclass which redirect
everything to commons-login - it is easier and much more straightforward to
implement (so much easier to understand and debug) than the existing
org.geotools.util.CommonHandler and I believe that it would fix most of Andrea's
issue. The only problem (maybe a big one - we need to investigate) is to get our
own LogManager to be registered. We can do that with the following command-line
option:

   -Djava.util.logging.config.class=org.geotools.util.CommonLogManager

For packages other than Geotools and Geoserver, this manager would redirect to
Apache's JULI if present, or the default Java log manager otherwise.

Would it be acceptable to suggest users to put this property configuration? I
would put CommonLogManager and CommonHandler in a very small standalone JAR so
users don't get a big dependency toward Geotools. The CommonHandler would stay
around for providing less-than-ideal (but better than nothing) fallback for
users would don't set this property.

        Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel