Interesting thread. So we are using Splunk as our log "viewer" and it has built in ability to map message ids to the localized strings. But, it's expensive for Splunk to do this (both in $ and processing time). So while its architecturally more pure it requires a good log viewer that everyone has access to.
On 6/10/11 10:45 PM, "Ralph Goers" <ralph.go...@dslextreme.com> wrote: >Actually, SLF4J's tie to Ceki's I18n project is one thing I really >dislike. IMO, localization should be done at the last possible moment. >If you really want an internationalized log then you should be logging >message ids and data and then doing the localization in your log viewer, >not as you are writing the records. > >Ralph > >On Jun 10, 2011, at 8:42 AM, Stephen Connolly wrote: > >> personally, there are a number of issues I have had with how >> slf4j/logback handles message formatting for i18n... other than the >> logging frameworks I have rolled myself, slf4j is the closest I've >> seen to logging done right... but it is still a bit far off the right >> path... >> >> Oh logging why do you have to be so fragmented and crap in java >> >> On 10 June 2011 16:28, John Casey <jdca...@commonjava.org> wrote: >>> >>> >>> On 6/10/11 3:48 AM, Mark Struberg wrote: >>>> >>>> We partly use slf4j internally already for tests, etc. >>>> But moving the whole Logger mess over to slf4j would be really great. >>>> There are lots of tests (I sadly also found productive code too) >>>>still using >>>> System.out.println. >>>> >>>> The question is if we (internally) drop >>>>org.codehaus.plexus.logging.Logger >>>> completely and use slf4j directly, or if we pimp up the plexus Logger >>>>and >>>> add various stuff. >>> >>> I've been thinking about this for some time now, actually. If you look >>>at >>> the MAE stuff in the sandbox, I'm pretty sure that's using log4j >>>directly. >>> >>> Personally, I don't understand what value the Plexus >>>logger/loggermanager >>> has, especially given the configurability of these other logging >>>frameworks. >>> >>> I'd be in favor of providing a "default" logging configuration file in >>> either the Maven app directory or in ~/.m2, and then letting people >>> customize from the command line to highlight specific >>>components/packages. >>> >>> Although, having said that, one of my pet peeves about the logging >>> frameworks is they haven't shifted to using String.format, >>> MessageFormat.format, or whatever under-the-covers as a way of limiting >>> string concatenation in cases where a particular log level has been >>> disabled. >>> >>> Even something as simple as the attached code would be a nice facade >>>for >>> logging, IMO...but it's more of a wish-list item than anything else. >>> >>> In short, yes, let's think about switching to a better logging >>>framework. We >>> can deprecate the plexus logger, and eventually get rid of it! >>> >>>> >>>> We would need to do some compat code anyway, but I'm not sure if it >>>>pays >>>> off to restrict ourself. At least not after I saw that even the >>>> LoggerManager uses System.err.println: >>>> >>>> // TODO: use a logger! >>>> System.err.println( "There was no such logger '" + key + "' " + >>>>hashCode() >>>> + "." ); >>>> >>>> dumdidum :) >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> --- On Fri, 6/10/11, Ralph Goers<ralph.go...@dslextreme.com> wrote: >>>> >>>>> From: Ralph Goers<ralph.go...@dslextreme.com> >>>>> Subject: Re: Get thee to the Core... >>>>> To: "Maven Developers List"<dev@maven.apache.org> >>>>> Date: Friday, June 10, 2011, 5:03 AM >>>>> >>>>> On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: >>>>> >>>>>> I'd like to offer a small suggestion. >>>>>> >>>>>> One of the big barriers to maven happiness is the >>>>> >>>>> difficulty of >>>>>> >>>>>> understanding, in some cases, why it does what it >>>>> >>>>> does. >>>>>> >>>>>> This suggests to me three efforts that might offer an >>>>> >>>>> opportunity to >>>>>> >>>>>> learn core code without drowning. >>>>>> >>>>>> 1: take up slf4j, and thus allow component (indeed >>>>> >>>>> class) by component >>>>>> >>>>>> log control as an alternative to the giant -X spew. >>>>> >>>>> Now that is an interesting idea. For the past year I have >>>>> been working on creating Log4j 2.0 pretty much by >>>>> myself. This would be a great way to integrate it into >>>>> something useful. >>>>> >>>>> Ralph >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> -- >>> John Casey >>> Developer, PMC Member - Apache Maven (http://maven.apache.org) >>> Blog: http://www.johnofalltrades.name/ >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
