« Return to Thread: Some consideration on GeoServer logging
Re: Some consideration on GeoServer logging
by aaime
::
Rate this Message:
Martin Desruisseaux ha scritto:
> 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
I'm aware of that. But it's way less problematic than the VM wide
configuration issues that java logging carries, at least in the
enterprise java space.
> 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...
JULI is a tomcat specific thing that requires you to control class
loading. It's not a solution for a library, nor is for GeoServer (which
strives to be container independent and ships, in its binary
incarnation, with Jetty).
> --------------------------------------------------------------------
>
> 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.
Seeing that Wicket uses it gives me some hope. Yet seeing their site say
that Hibernate uses it whilst it's not true takes away some of the
confidence (I've just downloaded the latest hibernate release, still
uses commons logging).
> 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.
I'm not sure how it would solve the logging level configuration problem
and the VM wide parameter settings. For example, how can I have two
GeoServer instances running in the same web container but using
different logging levels (not a made up case, think having two geoserver
inside the same web container, one configured for production and the
other for testing).
Can you explain?
> 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.
Having to use the above stuff is not a viable option for the same
reasons I've been repeating over and over. GeoServer ships both
as a WAR and as a binary. In the binary version we are stand alone and
we could do the above. In the war version GeoServer is supposed to be
included in the web container of users choice (may be tomcat, may be
Oracle Application Server) and the above would be a VM wide setting,
and one you may not be able to force in containers such as WebLogic for
example (they are quite fragile vm configuraiton wise usually, provided
you find any way to pass the VM a config parameter to start with).
One problem to consider in whatever solution we choose is how to handle
the switch of the logging API (given that java logging is structurally
broken for web serving, unless you can prove otherwise).
Say we switch to SL4J. We would have to hunt down every single logging
statement and fix it. I was thinking of an easier path.
Say we roll out our replacement classes that are bit by bit compatibile
with java logging method wise:
org.geotools.logging.Logger
org.geotools.logging.Level
Switching to those classes would be a matter of replacing import
statements, a task that "sed" could do efficiently and without
mistakes.
Inside those classes we could then relay to SL4J or to log4j or
to java logging. In a sense it would mean making our commons logging
(I don't like this idea very much) but at the same time I have the
impression it would make the switch to whatever we want possible
in a very short time. I don't know, it's just an idea.
What do you think?
Cheers
Andrea
-------------------------------------------------------------------------
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
> 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
I'm aware of that. But it's way less problematic than the VM wide
configuration issues that java logging carries, at least in the
enterprise java space.
> 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...
JULI is a tomcat specific thing that requires you to control class
loading. It's not a solution for a library, nor is for GeoServer (which
strives to be container independent and ships, in its binary
incarnation, with Jetty).
> --------------------------------------------------------------------
>
> 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.
Seeing that Wicket uses it gives me some hope. Yet seeing their site say
that Hibernate uses it whilst it's not true takes away some of the
confidence (I've just downloaded the latest hibernate release, still
uses commons logging).
> 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.
I'm not sure how it would solve the logging level configuration problem
and the VM wide parameter settings. For example, how can I have two
GeoServer instances running in the same web container but using
different logging levels (not a made up case, think having two geoserver
inside the same web container, one configured for production and the
other for testing).
Can you explain?
> 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.
Having to use the above stuff is not a viable option for the same
reasons I've been repeating over and over. GeoServer ships both
as a WAR and as a binary. In the binary version we are stand alone and
we could do the above. In the war version GeoServer is supposed to be
included in the web container of users choice (may be tomcat, may be
Oracle Application Server) and the above would be a VM wide setting,
and one you may not be able to force in containers such as WebLogic for
example (they are quite fragile vm configuraiton wise usually, provided
you find any way to pass the VM a config parameter to start with).
One problem to consider in whatever solution we choose is how to handle
the switch of the logging API (given that java logging is structurally
broken for web serving, unless you can prove otherwise).
Say we switch to SL4J. We would have to hunt down every single logging
statement and fix it. I was thinking of an easier path.
Say we roll out our replacement classes that are bit by bit compatibile
with java logging method wise:
org.geotools.logging.Logger
org.geotools.logging.Level
Switching to those classes would be a matter of replacing import
statements, a task that "sed" could do efficiently and without
mistakes.
Inside those classes we could then relay to SL4J or to log4j or
to java logging. In a sense it would mean making our commons logging
(I don't like this idea very much) but at the same time I have the
impression it would make the switch to whatever we want possible
in a very short time. I don't know, it's just an idea.
What do you think?
Cheers
Andrea
-------------------------------------------------------------------------
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
« Return to Thread: Some consideration on GeoServer logging
| Free embeddable forum powered by Nabble | Forum Help |
