From: Andrea A. <aa...@op...> - 2007-03-26 16:57:03
|
Hi, in the last couple of geotools and geoserver meetings the commons logging request was raised again (not by me this time, but I still support it). See the logs: http://docs.codehaus.org/display/GEOS/2007/03/14/IRC+Logs+March+13 http://docs.codehaus.org/display/GEOTOOLS/2007/03/19/IRC+Meeting+-+19+March+2007 Unfortunately in the last meeting we missed Martin, so there was no much point discussing it (other developers explicitly favouring commons logging afaik, that is, Justin, Gabriel, Saul and me, we did not hear from Jody, Jesse and Cory). I guess the topic will be raised again in today's meeting, so be prepared :-) Cheers Andrea |
From: Jody G. <jga...@re...> - 2007-03-26 17:47:48
|
Andrea can we get a formal proposal on this one - and get it sorted and out of the way. The proposal thing has a two week grace period for review etc... There is going to be a lot of this kind of work happening over the course of the year (cleaning up GeoTools so it can be used in more situations). Let's get cracking :-) Jody Andrea Aime wrote: > Hi, > in the last couple of geotools and geoserver meetings > the commons logging request was raised again (not by > me this time, but I still support it). > > See the logs: > http://docs.codehaus.org/display/GEOS/2007/03/14/IRC+Logs+March+13 > http://docs.codehaus.org/display/GEOTOOLS/2007/03/19/IRC+Meeting+-+19+March+2007 > > Unfortunately in the last meeting we missed Martin, so there > was no much point discussing it (other developers explicitly > favouring commons logging afaik, that is, Justin, Gabriel, Saul > and me, we did not hear from Jody, Jesse and Cory). > > I guess the topic will be raised again in today's meeting, so be > prepared :-) > Cheers > Andrea > > ------------------------------------------------------------------------- > 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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
From: Justin D. <jde...@op...> - 2007-03-26 17:59:13
|
I think a proposal at this point is premature. There has been much discussion about this in the past without a resolution. To be blunt we really need to get Martin on board or else there is nothing we can do, and working on a proposal will be a waste of time. -Justin Jody Garnett wrote: > Andrea can we get a formal proposal on this one - and get it sorted and > out of the way. The proposal thing > has a two week grace period for review etc... > > There is going to be a lot of this kind of work happening over the > course of the year (cleaning up GeoTools > so it can be used in more situations). > > Let's get cracking :-) > Jody > Andrea Aime wrote: >> Hi, >> in the last couple of geotools and geoserver meetings >> the commons logging request was raised again (not by >> me this time, but I still support it). >> >> See the logs: >> http://docs.codehaus.org/display/GEOS/2007/03/14/IRC+Logs+March+13 >> http://docs.codehaus.org/display/GEOTOOLS/2007/03/19/IRC+Meeting+-+19+March+2007 >> >> Unfortunately in the last meeting we missed Martin, so there >> was no much point discussing it (other developers explicitly >> favouring commons logging afaik, that is, Justin, Gabriel, Saul >> and me, we did not hear from Jody, Jesse and Cory). >> >> I guess the topic will be raised again in today's meeting, so be >> prepared :-) >> Cheers >> Andrea >> >> ------------------------------------------------------------------------- >> 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 >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > ------------------------------------------------------------------------- > 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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira The Open Planning Project http://topp.openplans.org |
From: Jody G. <jga...@re...> - 2007-03-26 18:05:12
|
I see - I viewed a proposal as the venue for discussion and resolution. As I understand it we have tried a couple of compromises already; if a proposal page reviewed the current state of play it would at least help me get my head around where we are and where we need to go. Not to discount anyones direction on this topic; I simply would like the background to a constructive voice on this one. Cheers, Jody Justin Deoliveira wrote: > I think a proposal at this point is premature. There has been much > discussion about this in the past without a resolution. To be blunt we > really need to get Martin on board or else there is nothing we can do, > and working on a proposal will be a waste of time. > > -Justin > > Jody Garnett wrote: >> Andrea can we get a formal proposal on this one - and get it sorted >> and out of the way. The proposal thing >> has a two week grace period for review etc... >> >> There is going to be a lot of this kind of work happening over the >> course of the year (cleaning up GeoTools >> so it can be used in more situations). >> >> Let's get cracking :-) >> Jody >> Andrea Aime wrote: >>> Hi, >>> in the last couple of geotools and geoserver meetings >>> the commons logging request was raised again (not by >>> me this time, but I still support it). >>> >>> See the logs: >>> http://docs.codehaus.org/display/GEOS/2007/03/14/IRC+Logs+March+13 >>> http://docs.codehaus.org/display/GEOTOOLS/2007/03/19/IRC+Meeting+-+19+March+2007 >>> >>> >>> Unfortunately in the last meeting we missed Martin, so there >>> was no much point discussing it (other developers explicitly >>> favouring commons logging afaik, that is, Justin, Gabriel, Saul >>> and me, we did not hear from Jody, Jesse and Cory). >>> >>> I guess the topic will be raised again in today's meeting, so be >>> prepared :-) >>> Cheers >>> Andrea >>> >>> ------------------------------------------------------------------------- >>> >>> 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 >>> Geo...@li... >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >> >> >> ------------------------------------------------------------------------- >> >> 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 >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > |
From: Martin D. <mar...@ge...> - 2007-03-26 18:05:38
|
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); 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. * 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. 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... What peoples wish? Martin |
From: Justin D. <jde...@op...> - 2007-03-26 18:22:09
|
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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira The Open Planning Project http://topp.openplans.org |
From: Newcomb, Michael-P. <Mic...@gd...> - 2007-03-26 18:26:33
|
Please check out www.slf4j.org before deciding on commons logging... Thanks, Michael -----Original Message----- From: geo...@li... [mailto:geo...@li...] On Behalf Of Martin Desruisseaux Sent: Monday, March 26, 2007 2:06 PM To: Andrea Aime Cc: Geotools-Devel list Subject: Re: [Geotools-devel] Geotools logging (again) 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); 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. * 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. 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... 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Geotools-devel mailing list Geo...@li... https://lists.sourceforge.net/lists/listinfo/geotools-devel |
From: Newcomb, Michael-P. <Mic...@gd...> - 2007-03-26 18:30:11
|
Particularly: http://www.slf4j.org/faq.html=20 -----Original Message----- From: geo...@li... [mailto:geo...@li...] On Behalf Of Newcomb, Michael-P57487 Sent: Monday, March 26, 2007 2:26 PM To: Geotools-Devel list Subject: Re: [Geotools-devel] Geotools logging (again) Please check out www.slf4j.org before deciding on commons logging... Thanks, Michael -----Original Message----- From: geo...@li... [mailto:geo...@li...] On Behalf Of Martin Desruisseaux Sent: Monday, March 26, 2007 2:06 PM To: Andrea Aime Cc: Geotools-Devel list Subject: Re: [Geotools-devel] Geotools logging (again) 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); 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. * 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. 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... 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Geotools-devel mailing list Geo...@li... https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------ - 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Geotools-devel mailing list Geo...@li... https://lists.sourceforge.net/lists/listinfo/geotools-devel |
From: Jody G. <jga...@re...> - 2007-03-26 18:40:03
|
Thanks for the link - these are the issues that have us looking at the problem at all. Do you mind checking the proposal page when they have it up (to be sure slf4j is represented - proposal page may need code examples). Jody Newcomb, Michael-P57487 wrote: > Particularly: > > http://www.slf4j.org/faq.html > > -----Original Message----- > From: geo...@li... > [mailto:geo...@li...] On Behalf Of > Newcomb, Michael-P57487 > Sent: Monday, March 26, 2007 2:26 PM > To: Geotools-Devel list > Subject: Re: [Geotools-devel] Geotools logging (again) > > Please check out www.slf4j.org before deciding on commons logging... > > Thanks, > Michael > > -----Original Message----- > From: geo...@li... > [mailto:geo...@li...] On Behalf Of > Martin Desruisseaux > Sent: Monday, March 26, 2007 2:06 PM > To: Andrea Aime > Cc: Geotools-Devel list > Subject: Re: [Geotools-devel] Geotools logging (again) > > 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); > > 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. > > * 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. > 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... > > 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=DEVDE > V > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > ------------------------------------------------------------------------ > - > 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=DEVDE > V > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > ------------------------------------------------------------------------- > 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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
From: Martin D. <mar...@ge...> - 2007-03-26 18:29:26
|
Justin Deoliveira a écrit : > 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? Yes, except for the modules that I maintain (metadata, referencing, some parts of coverage and go): I explicitly set the source method name most of the time. But I realize that I'm probably the only one to do that. > 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. I'm completly fine with the patch. Martin |
From: Jody G. <jga...@re...> - 2007-03-26 18:38:34
|
Martin if this is a common problem then asking people to set the source parameters should be "Recommended practice" as part of the proposal. Put it as something we ask of supported modules etc... Cheers, Jody Martin Desruisseaux wrote: > Justin Deoliveira a écrit : > >> 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? >> > > Yes, except for the modules that I maintain (metadata, referencing, some parts > of coverage and go): I explicitly set the source method name most of the time. > But I realize that I'm probably the only one to do that. > > > >> 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. >> > > I'm completly fine with the patch. > > 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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |