Hi all,
here is the proposal:
http://docs.codehaus.org/display/GEOTOOLS/Allow+redirection+to+alternate+logging+API
Given the amount of discussion the topic has received I feel it's
ready for voting, but feel free to discuss it again if you need to.
I'm cc'ing GeoServer too since to make everything work fine we'll have
to switch all Logger.getLogger(xxx) calls to Logging.getLogger(xxx) in
GeoServer code as well.
Cheers
Andrea
Two questions Andrea:
- Confirmation - Logging.getLogger(String) still returns a java.util.logging.logger
- the class GeoTools is being used (by me at least) for all GeoTools integration concerns (intergrate GeoTools library with container JNDI, global Hints settings etc...); it would be nice if the redirectToLog4j() methods could be added to this class instead; you may wish to add the getLogger method as well.
AFTER:
import java.util.logging.Logger;
import org.geotools.util.GeoTools;
...
private static final Logger LOGGER = GeoTools.getLogger("org.geotools.rendering");
}
Cheers,
Jody
Hi all,
here is the proposal:
http://docs.codehaus.org/display/GEOTOOLS/Allow+redirection+to+alternate+logging+APIGiven the amount of discussion the topic has received I feel it's
ready for voting, but feel free to discuss it again if you need to.I'm cc'ing GeoServer too since to make everything work fine we'll have
to switch all Logger.getLogger(xxx) calls to Logging.getLogger(xxx) in
GeoServer code as well.
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Jody Garnett ha scritto:
Two questions Andrea:
- Confirmation - Logging.getLogger(String) still returns a java.util.logging.logger
Either it directly, or a subclass of it in case of redirection.
- the class GeoTools is being used (by me at least) for all GeoTools integration concerns (intergrate GeoTools library with container JNDI, global Hints settings etc...); it would be nice if the redirectToLog4j() methods could be added to this class instead; you may wish to add the getLogger method as well.
Hmm.... the redirect method for the old commons logging redirection
was in Logging as well as other logging utility methods.
Anyways, I'm ok about putting the stuff in GeoTools as well...
Martin?
Cheers
Andrea
Andrea Aime wrote:
Hmm.... the redirect method for the old commons logging redirection
was in Logging as well as other logging utility methods.
Anyways, I'm ok about putting the stuff in GeoTools as well...
I would prefer the use of a single class for all these integration concerns
I started collecting help pages that will be effected by your change:
- http://docs.codehaus.org/display/GEOTDOC/02+Intergration+Basics
- http://docs.codehaus.org/display/GEOTDOC/Logging
- http://docs.codehaus.org/display/GEOT/5.1.3+Logging
Martin?
Cheers
Andrea
Andrea Aime a écrit :
Hmm.... the redirect method for the old commons logging redirection
was in Logging as well as other logging utility methods.
Anyways, I'm ok about putting the stuff in GeoTools as well...
Martin?
For CommonHandler, we did a mix:
- Logging class contains method with a clear role (one method = one task).
Example: redirectToCommonLogging().
- GeoTools contains a init() method which invokes a bunch of methods
believed to be wanted in many usage. For example init() invokes
redirectToCommonLogging() and some other methods I forget. So it is
a black box that break the "one method = one task" rule.
I suggests to do the same that what we did in CommonHandler:
- Put redirectToLog4J in Logging.
- Invoke redirectToLog4J from GeoTools.init(), together with other
typical convenience methods.
Martin
Hi Andrea; now that the page is in place I am having a better idea of what is involved. I had an idea which you may
want to consider - or shoot down.
It would be nice to let the host application supply the logger class (rather than simply supply a list of out of the box
magic methods to accomplish log4j / sl4j / commons logging integration.
What about something like:
GeoToools.setLoggerFactory( LoggerFactory factory );
The benifit for me would be the ability to supply an implementation from uDig that hooks into the
Eclipse RCP trace system.
Jody
Hi all,
here is the proposal:
http://docs.codehaus.org/display/GEOTOOLS/Allow+redirection+to+alternate+logging+APIGiven the amount of discussion the topic has received I feel it's
ready for voting, but feel free to discuss it again if you need to.I'm cc'ing GeoServer too since to make everything work fine we'll have
to switch all Logger.getLogger(xxx) calls to Logging.getLogger(xxx) in
GeoServer code as well.
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Martin Desruisseaux ha scritto:
Andrea Aime a écrit :
Hmm.... the redirect method for the old commons logging redirection
was in Logging as well as other logging utility methods.
Anyways, I'm ok about putting the stuff in GeoTools as well...
Martin?For CommonHandler, we did a mix:
- Logging class contains method with a clear role (one method = one task).
Example: redirectToCommonLogging().- GeoTools contains a init() method which invokes a bunch of methods
believed to be wanted in many usage. For example init() invokes
redirectToCommonLogging() and some other methods I forget. So it is
a black box that break the "one method = one task" rule.I suggests to do the same that what we did in CommonHandler:
- Put redirectToLog4J in Logging.
- Invoke redirectToLog4J from GeoTools.init(), together with other
typical convenience methods.
That GeoTools.setFactory(LogFactory factory) proposal from Jody
sounds nice in that it's extensible...
I really don't understand why GeoTooos.init() should call redirectToCommonLogging() thought?
Cheers
Andrea
Andrea Aime a écrit :
That GeoTools.setFactory(LogFactory factory) proposal from Jody
sounds nice in that it's extensible...
Yes I like that. We can plug that in the usual plugin factory mechanism.
I really don't understand why GeoTooos.init() should call
redirectToCommonLogging() thought?
Only because it was a user demand. I never use GeoTools.init() myself, but some
other peoples like to have everything in a single place.
I would not mind to put "redirectToLog4J()" in GeoTools if it was the only
logging-related method. But we have others (e.g. Logging.unexpectedException
which is just a convenience method that I use for logging an unexpected but
recoverable exception), and I guess that we may want to add more in the future
(maybe addLoggerFactory(...) following Jody's proposal?). So a dedicaced class
holding the logging-related methods may be nice.
Martin
Martin Desruisseaux ha scritto:
Andrea Aime a écrit :
That GeoTools.setFactory(LogFactory factory) proposal from Jody
sounds nice in that it's extensible...Yes I like that. We can plug that in the usual plugin factory mechanism.
Hmmm... I'm not sure I understand the need of SPI here... I mean, how
do you decide which one of the implementations to use? If you have
to provide a hint of some kind, then you may well pass the actual
factory and be done with it no?
Cheers
Andrea
Ok, I'm trying to get a handle on this issue.
One question, what's the objection to just using SFL4J ?
It seems to meet Justin's criteria of using a standard library, it'll work with sfl4j/jetty 
(for Andrea), and Martin likes it a lot better than commons logging.
I imagine I just missed what the objection was, but I'm curious to hear it.
Chris
Chris Holmes ha scritto:
Ok, I'm trying to get a handle on this issue.
One question, what's the objection to just using SFL4J ?
It seems to meet Justin's criteria of using a standard library, it'll work with sfl4j/jetty
I imagine I just missed what the objection was, but I'm curious to hear it.
sfl4j is just a facade like commons logging. Now, in Jetty by default
they put an implementation of the library that redirects to "simple
logging". Given that it's the first element in the classpath it'll
override whatever implementation we put in our library, meaning that
we would not be able to force log4j usage unless we manually change
the jars in the Jetty container (remember, slf4j way of doing redirections is to implement exactly the same classes in the different
jars and have classloading decide which one gets used).
I guess the second problem is timing, the slf4j is different enough
from java logging (http://www.slf4j.org/api/org/slf4j/Logger.html) that
manual changes will have to be performed manually instead of using
a single search and replace, especially in the modules managed
by Martin.
Cheers
Andrea
Chris Holmes ha scritto:
Ok, I'm trying to get a handle on this issue.
One question, what's the objection to just using SFL4J ?
It seems to meet Justin's criteria of using a standard library, it'll work with sfl4j/jetty
I imagine I just missed what the objection was, but I'm curious to hear it.
Oh, for an idea of how hard the switch might be have a look at
the differences between java logggin and commons logging:
http://www.slf4j.org/api/org/slf4j/Logger.html
(you'll notice that some cases aren't covered 1:1 by slf4j
either, thought probably it's possible to handle them by using
that Marker thing they have there).
Cheers
Andrea
Andrea Aime wrote:
Chris Holmes ha scritto:
Ok, I'm trying to get a handle on this issue.
One question, what's the objection to just using SFL4J ?
It seems to meet Justin's criteria of using a standard library, it'll work with sfl4j/jetty
I imagine I just missed what the objection was, but I'm curious to hear it.
sfl4j is just a facade like commons logging. Now, in Jetty by default
they put an implementation of the library that redirects to "simple
logging". Given that it's the first element in the classpath it'll
override whatever implementation we put in our library, meaning that
we would not be able to force log4j usage unless we manually change
the jars in the Jetty container (remember, slf4j way of doing redirections is to implement exactly the same classes in the different
jars and have classloading decide which one gets used).
But GeoServer isn't relying on any log4g usage, right? Why would we want to force it?
I guess the second problem is timing, the slf4j is different enough
from java logging (http://www.slf4j.org/api/org/slf4j/Logger.html) that
manual changes will have to be performed manually instead of using
a single search and replace, especially in the modules managed
by Martin.
Hmmm... Let's see what he says.
What about GeoServer using sfl4j and geotools continue to use java logging? Would that help solve things?
Chris
Cheers
Andrea!DSPAM:4005,472776d522262143011171!
I really think this conversation needs to move to the IRC meeting.
There are LOTS of things to say, and I can't send my emails fast enough
to keep up with the changing discussion.
3:00. Be there or be square!
--saul
On Tue, 2007-10-30 at 14:30 -0400, Chris Holmes wrote:
Andrea Aime wrote:
> Chris Holmes ha scritto:
>> Ok, I'm trying to get a handle on this issue.
>>
>> One question, what's the objection to just using SFL4J ?
>>
>> It seems to meet Justin's criteria of using a standard library, it'll
>> work with sfl4j/jetty
>> better than commons logging.
>>
>> I imagine I just missed what the objection was, but I'm curious to
>> hear it.
>
> sfl4j is just a facade like commons logging. Now, in Jetty by default
> they put an implementation of the library that redirects to "simple
> logging". Given that it's the first element in the classpath it'll
> override whatever implementation we put in our library, meaning that
> we would not be able to force log4j usage unless we manually change
> the jars in the Jetty container (remember, slf4j way of doing
> redirections is to implement exactly the same classes in the different
> jars and have classloading decide which one gets used).
But GeoServer isn't relying on any log4g usage, right? Why would we
want to force it?>
> I guess the second problem is timing, the slf4j is different enough
> from java logging (http://www.slf4j.org/api/org/slf4j/Logger.html) that
> manual changes will have to be performed manually instead of using
> a single search and replace, especially in the modules managed
> by Martin.
>
Hmmm... Let's see what he says.
What about GeoServer using sfl4j and geotools continue to use java
logging? Would that help solve things?Chris
> Cheers
> Andrea
>
> !DSPAM:4005,472776d522262143011171!
>
-------------------------------------------------------------------------
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Chris Holmes ha scritto:
Andrea Aime wrote:
Chris Holmes ha scritto:
Ok, I'm trying to get a handle on this issue.
One question, what's the objection to just using SFL4J ?
It seems to meet Justin's criteria of using a standard library, it'll work with sfl4j/jetty
I imagine I just missed what the objection was, but I'm curious to hear it.
sfl4j is just a facade like commons logging. Now, in Jetty by default
they put an implementation of the library that redirects to "simple
logging". Given that it's the first element in the classpath it'll
override whatever implementation we put in our library, meaning that
we would not be able to force log4j usage unless we manually change
the jars in the Jetty container (remember, slf4j way of doing redirections is to implement exactly the same classes in the different
jars and have classloading decide which one gets used).But GeoServer isn't relying on any log4g usage, right? Why would we want to force it?
You must have lost some episodes of the logging saga 
GeoServer is using log4j since Saul switched GeoServer to use it,
and 1.6 configures the logging levels using log4j configuration files.
So yes, either 1.6 uses log4j or it has no control on the logging levels
whatsoever.
It's just that at the moment we're using the java logging api, which
redirects to commons logging, which redirects to log4j, and the
logging level setup is simply not working.
Cheers
Andrea
There is no real objection to this, except that it's a "hard"
cut-and-paste problem to go and re-do every logging statement in every
class everywhere.
Once Andrea and Martin decided to go directly with log4j (or
whatever...they just picked log4j because it made sense to them) they
decided that the EASY way to get every class everywhere using log4j (or
whatever) was to use a syntactic change like so:
OLD CODE: Logger _logger =
java.util.logging.Logger.getLogger("classname");
NEW CODE: Logger _logger =
org.geotools.util.Logging.getLogger("classname");
This was deemed (rightly in my eyes!) as an easier change to make across
the entire geotools codebase, and an easy one to document and implement.
Now what would this org.geotools.util.Logging.getLogger(String) method
return?
Well, it would return a subclass of "java.util.logger.Logger" that just
straight redirects EVERYTHING to log4j (or slf4j or whatever). It would
just call straight through, mapping all the relevant calls including the
EXTREMELY important "isLoggable()" call, right through to whatever the
underlying logging mechanism is.
This way we don't have to do an enormous amount of re-coding inside
geotools, all the code stays largely the same, and the end result is
almost exactly the same.
The added bonus is that we can make the
"org.geotools.util.Logging.getLogger(string)" method return various
different Logger subclasses. It could return a Logger that sends
everything straight through to log4j. It could return a Logger that
sends everything straight through to slf4j. It could return a logger
that sends everything straight through to Eclipse RCP trace events.
Etc.
Here's the short recap:
1) java.util.logging.* has a VERY rich interface for supporting lots of
log-related things like i18n, resourcebundles and stack traces.
2) No other logging framework has everything that java.util.logging.*
has (probably for a good reason!)
3...and this one's the clincher) Geotools USES lots of the stuff from 1
(like all of Martin's code).
The specific wins of Andreas and Martin's proposal is this:
* Dumping 1 and going to 2 is a painful CODING process. Not just a
cut-n-paste (in my opinion) or a sed/awk experience.
* Andrea and Martin's solution is simply an acceptance of the fact that
lots of Geotools code uses java.util.logging.* classes, and it would be
a lot of grunt search-and-replace to fix it. We've got enough grunt
search-and-replace(-and-test) coding on our plates already (filters,
featuremodel, geoapi, gce).
In the end I think the biggest concern is about hacks. Is subclassing
java.util.logging.Logger in this way a hack?
I'd say that with the clean redirect to a backend logging system, it
isn't any more of a hack than any other configurable logging facade
system (log4j, slf4j, commons-logging, etc). They're all just facade
systems that run to a back-end logger. We've picked a facade, it's all
in the code, now let's stick to it.
See you all in the GS IRC meeting!
--saul
On Tue, 2007-10-30 at 14:17 -0400, Chris Holmes wrote:
Ok, I'm trying to get a handle on this issue.
One question, what's the objection to just using SFL4J ?
It seems to meet Justin's criteria of using a standard library, it'll
work with sfl4j/jetty
than commons logging.I imagine I just missed what the objection was, but I'm curious to hear it.
Chris
-------------------------------------------------------------------------
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/
_______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Andrea Aime wrote:
Chris Holmes ha scritto:
Andrea Aime wrote:
Chris Holmes ha scritto:
Ok, I'm trying to get a handle on this issue.
One question, what's the objection to just using SFL4J ?
It seems to meet Justin's criteria of using a standard library, it'll work with sfl4j/jetty
I imagine I just missed what the objection was, but I'm curious to hear it.
sfl4j is just a facade like commons logging. Now, in Jetty by default
they put an implementation of the library that redirects to "simple
logging". Given that it's the first element in the classpath it'll
override whatever implementation we put in our library, meaning that
we would not be able to force log4j usage unless we manually change
the jars in the Jetty container (remember, slf4j way of doing redirections is to implement exactly the same classes in the different
jars and have classloading decide which one gets used).But GeoServer isn't relying on any log4g usage, right? Why would we want to force it?
You must have lost some episodes of the logging saga
GeoServer is using log4j since Saul switched GeoServer to use it,
and 1.6 configures the logging levels using log4j configuration files.
So yes, either 1.6 uses log4j or it has no control on the logging levels
whatsoever.
Ah, right. Yeah, I missed that episode. Ok, just ignore me, I have nothing productive to add 
In the unproductive vein, however: 'this stuff sucks!' And thank you all for doing your best to figure out a solution that works.
Chris
It's just that at the moment we're using the java logging api, which
redirects to commons logging, which redirects to log4j, and the
logging level setup is simply not working.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/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel!DSPAM:4005,4727795931781431913854!
Andrea Aime a écrit :
Hmmm... I'm not sure I understand the need of SPI here... I mean, how
do you decide which one of the implementations to use? If you have
to provide a hint of some kind, then you may well pass the actual
factory and be done with it no?
Yes, you are right. Please forget about my SPI proposal.
Martin
Chris Holmes a écrit :
It seems to meet Justin's criteria of using a standard library, it'll
work with sfl4j/jetty
than commons logging.
SLF4J has more capabilities than Commons-Logging for sure. But the most standard
(while maybe not the most used) API stay Java Logging, since it is bundled in
core Java. It is also the less troublesome (because of its priviligied position
in core Java, compared to other framework) for those who are willing to accept
its limitations, especially if we want to use GeoServer inside Glassfish.
Commons-Logging seems to be slowly dying because of ClassLoader issues
(Hibernate is moving from Commons-Logging to SLF4J because of that, and a
similar move in Jetty (from version 5 to version 6) trigged this logging thread).
I admit that Java Logging has less capabilities than Log4J, which is why it is
important to allow peoples to use other implementations. In order to lets people
choose whatever implementation they want, we need to agree on an API. I suggest
Java Logging API (note: API, not necessarly implementation) because it is core Java.
Writting our own java.util.logging.Logger facade should not be long. I expect
that by the time we get the PMC okay, it will be done the day after. Doing that
in GeoTools allows us to redirect to Log4J or SLF4J, as we wish even if the
container tries to redirect us elsewhere.
As a bonus (not sure if it is useful), we get for free the ability to redirect
different loggers to different Logging framework (e.g. "org.geotools.render"
to Log4J, "org.geotools.filter" to Java logging...)
Martin