« Return to Thread: Some consideration on GeoServer logging
Re: Some consideration on GeoServer logging
by aaime
::
Rate this Message:
Martin Desruisseaux ha scritto:
> Andrea Aime a écrit :
>> 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.
That would not solve the problem. The problem is that building logging
messages is expensive, so lots of code has stuff like:
if(LOGGER.isLoggable(Level.FINE)) {
// do expensive log message building
}
That common logger class would have to work against a user provided set
of levels (the ones we grab by parsing the log4j file). Would it be
possible?
> 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.
That's not possible, this is J2EE, we cannot do anything that is VM
wide, only stuff that can be done:
a) while the vm is already running
b) that affects only the current web application and leaves the other
web applications running in the same VM alone.
>
>> 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.
Martin, I have the impression I'm not getting my point thru. Whatever
VM wide solution you come up with is not acceptable. Whatever solution
that requires to play with class loaders is not acceptable either.
>> 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.
>
> 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?
Seems like a good solution... is there any way I can control the
creation of those loggers so to assign the right logging level?
They need to answer to LOGGER.isLoggable(Level.XXX) in a way that
reflects the log4j configuraton file.
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
> Andrea Aime a écrit :
>> 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.
That would not solve the problem. The problem is that building logging
messages is expensive, so lots of code has stuff like:
if(LOGGER.isLoggable(Level.FINE)) {
// do expensive log message building
}
That common logger class would have to work against a user provided set
of levels (the ones we grab by parsing the log4j file). Would it be
possible?
> 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.
That's not possible, this is J2EE, we cannot do anything that is VM
wide, only stuff that can be done:
a) while the vm is already running
b) that affects only the current web application and leaves the other
web applications running in the same VM alone.
>
>> 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.
Martin, I have the impression I'm not getting my point thru. Whatever
VM wide solution you come up with is not acceptable. Whatever solution
that requires to play with class loaders is not acceptable either.
>> 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.
>
> 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?
Seems like a good solution... is there any way I can control the
creation of those loggers so to assign the right logging level?
They need to answer to LOGGER.isLoggable(Level.XXX) in a way that
reflects the log4j configuraton file.
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 |
