Hi Martin,
Thanks very much for the feedback martin. Logging will be a topic at the
meeting and I will be sure to bring up your concerns.
Martin Desruisseaux wrote:
> I'm not sure to be able to attend to today IRC. I just moved from Canada to
> France and still looking for a place to stay, etc.
>
> As far as logging is concerned, internationalization is not a blocker issue.
> I
> can localize the message before to pass it to a logging API. The difference
> is
> that it will be formatted according the server's locale; there is no chance
> to
> get it formatted according the client locale (where the "client" may be
> somebody
> using the Java Monitoring framework).
>
> What I find a little bit more unfortunate is that common-logging API is very
> minimalist. The common-logging API is strictly limited to methods like:
>
> boolean isTraceable();
> void trace(String Message, Throwable t);
>
Agreed, but the whole point is to be as minimalist as possible in order
to leave decisions to the application. I agree that this has its
downsides as well.
> There is really nothing else. With Java logging, you can control more
> aspects,
> including (but not limited to) localization, source class name and source
> method
> name. I do modify the source method name very often, for the following
> reasons:
>
> * Sun warns that automatic detection of source method is unreliable,
> especially in a server environment, because of Hotspot optimizations.
> Specifying explicitly the source method/class name is more reliable
> and accurate.
I see, but 95% of logging code in geotools does not do this, am i
correct? So the code that is using java logging is subject to the same
limitition?
>
> * In many cases, the calling method is not the one we want to show as
> "source
> method name". Example:
>
> public myPublicMethod() {
> // ... do some processing ...
> log("My message", "myPublicMethod");
> }
>
> public anOtherPublicMethod() {
> // ... do some processing ...
> log("My other message", "anOtherPublicMethod");
> }
>
> private static log(String message, String sourceMethodName) {
> // Log the message to some logger common to every methods
> // in this class, maybe providing some additional information
> // related to this class state.
> }
>
> Without the ability to set explicitly the source method name, logs would
> be logged as if they were originating from the "log" method. But the
> "log"
> method is purely a private helper method; the real originators are
> "myPublicMethod" and "myOtherPublicMethod".
>
> With common-logging, there is no way to create log records with the level of
> accuracy and convenience (for the human reader) that java-logging provides.
> We
> are sure to get lower quality log records.
Hmm, from what I can see the logical mappings from java-logging to
commons-logging collapse FINE, and FINER into DEBUG, and CONFIG and INFO
into INFO. Everything else seems to map across nicley. However I do
agree that having a finer granularity would be nice.
However I realize that I'm probably
> the only one to use localization and explicit source method setting, and the
> vast majority of Geotools developers seem to want common logging. If this is
> the
> wish of Geotools PMC, I can abandon java logging. If we want to give a last
> chance to java logging, I can apply the changes proposed by Justin this
> week...
I see the patch as a mid-term solution, did you find them acceptable? I
really see the long-term solution to be the switch to commons logging.
>
> What peoples wish?
>
> Martin
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
