Re: Some consideration on GeoServer logging

Andrea Aime a écrit :
> JULI is a tomcat specific thing that requires you to control class
> loading. It's not a solution for a library

Sure. I cited JULI only as an illustration of an Apache project following a path
that they could have taken in common-logging.


[...about improving our redirection to java logging...]

> I'm not sure how it would solve the logging level configuration problem

We could override java.util.logging.Logger that way:

class CommonLogger extends Logger {
    private final Log commonLogger = ...

    @Override
    public void info(String message) {
        commonLogger.info(message);
    }
    // etc...
}

so we bypass completly all Java logging checks. This is equivalent to the
solution you proposed in your previous email (set java logging to FINEST or ALL
and lets common logger do the filtering itself), but more efficiently since we
pass the call immediately to common-logger.

This redirection would be performed only for Geotools and Geoserver logger (or
any other logger listed by the users). Other loggers would stay the default ones.

The only condition for being able to to that is to get our own LogManager class
instantiated at JVM startup time, i.e. being able to ask to users to provide the
-D option mentioned in my previous email.


> For example, how can I have two
> GeoServer instances running in the same web container but using
> different logging levels

We have a choice:
- This is not possible with the default java logging as it currently
  stand in Java 6.

- It is possible with JULI extension to java logging, which was
  created especially for that purpose in my understanding.

- I think (but I'm not sure) that it would be possible with my above-cited
  proposal without JULI since the log would be forwarded directly to common-
  logging with all java logging code bypassed. If it doesn't work for some
  reason, I think it would work with my proposal + JULI.



It may be the best compromise. Actually, there is no need to create
org.geotools.logging.Logger/Level class. We could do the following:

- Create the above cited CommonLogger class as in my above proposal
  (package-privated class).

- Adds the following method in the current org.geotools.util.Logging
  class: getLogger(String).

- Replaces every occurence of
      java.util.logging.Logger.getLogger(name);
  by
      org.geotools.util.Logging.getLogger(name);
  in the GeoTools code base. Remainding API (Logger, LogRecord, Level...)
  stay unchanged.

- Maybe delete CommonHandler if we don't need it anymore.


It would produce the same effect than my above proposal, except that there is no
need to register a LogManager if all GeoTools code get the logger through a call
to Logging.getLogger instead of Logger.getLogger.

What do you think?

        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