Well, I could use feedback on https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/
On Jun 10, 2011, at 8:43 AM, Stephen Connolly wrote: > lest anyone think I'm doing NIH, the logging frameworks I have > implemented myself (they were under commercial license for previous > employer) were less than perfect, but having seen my mistakes I think > I have a better handle on the right path to take! > > On 10 June 2011 16:42, Stephen Connolly <stephen.alan.conno...@gmail.com> > 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 >
