[Geoserver-devel] GSIP-13 wrapup

GeoServer GeoServer Developer
1

Hello all,
So GSIP 13 has wrapped up and is now commited to trunk. At this time, I'm not working on porting it back to 1.5.x, although if it turns out to be so wonderful that no-one can live without it on 1.5.x, I could probably be convinced to do so.

Big changes:

1) Instead of a system-wide 'Log Level' there are now 'Logging Profiles'. A logging profile is a log4j properties file specifying logging rules. The profile is known by the name of the file. Five profiles ship with GeoServer right now. They are:

VERBOSE_LOGGING - this enables DEBUG level logging on org.geotools.* org.geoserver.* and org.vfny.*

GEOTOOLS_DEVELOPER_LOGGING - this enables DEBUG logging on org.geotools.* and INFO logging on org.geoserver.* and org.vfny.*

GEOSERVER_DEVELOPER_LOGGING - DEBUG on org.vfny.* and org.geotools.*, INFO on org.geotools.* (except some really chatty packages which get WARN)

DEFAULT_LOGGING - enable INFO on all gt/gs levels (except the chatty geotools packages which get WARN)

PRODUCTION_LOGGING - enables WARN on all gt/gs levels

Please note that these settings are NOT set in stone. If people think there should be different levels set in these five profiles, or if people think different profiles should be made available, that can be very very easily done. I figure as we get more and more user bug reports we can fine-tune exactly which portions of geoserver need the most visibility in the various profiles.

2) Log to file is *always* active now. Generally, expect to see most of your geoserver output in the DATA_DIR/logs/geoserver.log file (change it in the UI)

3) StdOut/Console logging is now disable-able. Check the 'suppress stdout logging' and geoserver won't pollute your container-wide System.out log any more. This is a bigger deal for folks who run geoserver along with other applications in a large J2EE container (like jboss or websphere)

4) If you want to debug just one bit of code, you can use a trick to enable a non-standard logging profile. Here are the steps:

a. Copy DEFAULT_LOGGING.properties to CUSTOM_LOGGING.properties (or whatever you want to call it)
b. Modify your CUSTOM_LOGGING.properties file to reflect excatly the level of logging you want to have. For example, maybe you want to print the geotools arcsde DB queries, but nothing else. Add lines like:

log4j.category.org.geotools.arcsde.data.ArcSDEQuery=DEBUG
log4j.category.org.geotools=INFO

c. In your server.xml file, change the log profile to "CUSTOM_LOGGING.properties" (or whatever you called your custom log4j file)
d. When you next start up geoserver, that logging profile will be enabled, and you can directly control your logging using that log4j logging file. Just don't change anything in the "server" UI tab and then hit 'Save'.

If you find any strageness or bugs in the rejiggered logging system, let me know. I'll open JIRAs and track them down as we go through the 1.6.x beta process.

This information is also available in the developers guide. See here:
http://docs.codehaus.org/display/GEOSDOC/Logging

Thanks much
--saul

2

Farber, Saul (EEA) ha scritto:

Hello all, So GSIP 13 has wrapped up and is now commited to trunk.
At this time, I'm not working on porting it back to 1.5.x, although
if it turns out to be so wonderful that no-one can live without it on
1.5.x, I could probably be convinced to do so.

Well, most of new developments are done on trunk and then backported,
so I guess you won't get a shower of requests from developers. Users, we'll see. I guess that would become yet another reason for people
to switch to 1.6.x

Big changes:

1) Instead of a system-wide 'Log Level' there are now 'Logging
Profiles'. A logging profile is a log4j properties file specifying
logging rules. The profile is known by the name of the file. Five
profiles ship with GeoServer right now. They are:

VERBOSE_LOGGING - this enables DEBUG level logging on org.geotools.*
org.geoserver.* and org.vfny.*

GEOTOOLS_DEVELOPER_LOGGING - this enables DEBUG logging on
org.geotools.* and INFO logging on org.geoserver.* and org.vfny.*

GEOSERVER_DEVELOPER_LOGGING - DEBUG on org.vfny.* and org.geotools.*,
INFO on org.geotools.* (except some really chatty packages which get
WARN)

DEFAULT_LOGGING - enable INFO on all gt/gs levels (except the chatty
geotools packages which get WARN)

PRODUCTION_LOGGING - enables WARN on all gt/gs levels

Please note that these settings are NOT set in stone. If people
think there should be different levels set in these five profiles, or
if people think different profiles should be made available, that can
be very very easily done. I figure as we get more and more user bug
reports we can fine-tune exactly which portions of geoserver need the
most visibility in the various profiles.

Looks good. I'm wondering if we should spend time to lower the log
level of the chatty packages in the code.

2) Log to file is *always* active now. Generally, expect to see
most of your geoserver output in the DATA_DIR/logs/geoserver.log file
(change it in the UI)

Hmm, nice but I wonder how much this impacts performance. I kind of
remember there was the possibility, with log4j, to have delayed logging,
that is, log messages be written in a temporary buffer and flushed
on disk on bigger batches and by a low priority thread.

4) If you want to debug just one bit of code, you can use a trick to
enable a non-standard logging profile. Here are the steps:

a. Copy DEFAULT_LOGGING.properties to CUSTOM_LOGGING.properties (or
whatever you want to call it) b. Modify your
CUSTOM_LOGGING.properties file to reflect excatly the level of
logging you want to have. For example, maybe you want to print the
geotools arcsde DB queries, but nothing else. Add lines like:

log4j.category.org.geotools.arcsde.data.ArcSDEQuery=DEBUG log4j.category.org.geotools=INFO

c. In your server.xml file, change the log profile to
"CUSTOM_LOGGING.properties" (or whatever you called your custom log4j
file) d. When you next start up geoserver, that logging profile will
be enabled, and you can directly control your logging using that
log4j logging file. Just don't change anything in the "server" UI
tab and then hit 'Save'.

server.xml? Or you mean services.xml?

Thanks for the hard work Saul :slight_smile:
Andrea

3

Big changes:

1) Instead of a system-wide 'Log Level' there are now 'Logging
Profiles'. A logging profile is a log4j properties file specifying
logging rules. The profile is known by the name of the file. Five
profiles ship with GeoServer right now. They are:

VERBOSE_LOGGING - this enables DEBUG level logging on org.geotools.*
org.geoserver.* and org.vfny.*

GEOTOOLS_DEVELOPER_LOGGING - this enables DEBUG logging on
org.geotools.* and INFO logging on org.geoserver.* and org.vfny.*

GEOSERVER_DEVELOPER_LOGGING - DEBUG on org.vfny.* and org.geotools.*,
INFO on org.geotools.* (except some really chatty packages which get
WARN)

DEFAULT_LOGGING - enable INFO on all gt/gs levels (except the chatty
geotools packages which get WARN)

PRODUCTION_LOGGING - enables WARN on all gt/gs levels

Please note that these settings are NOT set in stone. If people
think there should be different levels set in these five profiles, or
if people think different profiles should be made available, that can
be very very easily done. I figure as we get more and more user bug
reports we can fine-tune exactly which portions of geoserver need the
most visibility in the various profiles.

Looks good. I'm wondering if we should spend time to lower the log
level of the chatty packages in the code.

Great question. I'm generally pretty in-favor of the idea that more logging messages is an OK thing, but I agree that some of the logging in geotools can be a bit verbose.

2) Log to file is *always* active now. Generally, expect to see
most of your geoserver output in the DATA_DIR/logs/geoserver.log file
(change it in the UI)

Hmm, nice but I wonder how much this impacts performance. I kind of
remember there was the possibility, with log4j, to have delayed logging,
that is, log messages be written in a temporary buffer and flushed
on disk on bigger batches and by a low priority thread.

That's another good point. I'll look into 'delayed' or 'prioritized' logging and see if there's a place for a switch that changes logging from 'synchronous' to 'asynchronous' logging.

Also, I'll add a JIRA to try and optimize things a bit more at the Java Logging level. Right now all java logging levels are set to ALL so that they can be filtered by log4j, but I could probably read the log4j config file directly and set the Java Logging levels appropriately based on that info. I'll see if I can get that done before beta2 goes out.

4) If you want to debug just one bit of code, you can use a trick to
enable a non-standard logging profile. Here are the steps:

a. Copy DEFAULT_LOGGING.properties to CUSTOM_LOGGING.properties (or
whatever you want to call it) b. Modify your
CUSTOM_LOGGING.properties file to reflect excatly the level of
logging you want to have. For example, maybe you want to print the
geotools arcsde DB queries, but nothing else. Add lines like:

log4j.category.org.geotools.arcsde.data.ArcSDEQuery=DEBUG
log4j.category.org.geotools=INFO

c. In your server.xml file, change the log profile to
"CUSTOM_LOGGING.properties" (or whatever you called your custom log4j
file) d. When you next start up geoserver, that logging profile will
be enabled, and you can directly control your logging using that
log4j logging file. Just don't change anything in the "server" UI
tab and then hit 'Save'.

server.xml? Or you mean services.xml?

Oops. Yep, I meant services.xml

Thanks for the hard work Saul :slight_smile:

Meh, not that hard of work. Just annoying to change the UI!

4

Farber, Saul (EEA) ha scritto:

Also, I'll add a JIRA to try and optimize things a bit more at the
Java Logging level. Right now all java logging levels are set to ALL
so that they can be filtered by log4j, but I could probably read the
log4j config file directly and set the Java Logging levels
appropriately based on that info.

Uag, bad, some logs are pretty expensive to generate (there's a reason
why many log statements are guarded by if(Log.isLoggable(level)).

I'll see if I can get that done before beta2 goes out.

Hem... I'm about to release it. But I can wait another day, in fact
I noticed the slowness and was wondering why.
Cheers
Andrea