Whoever said this is a 2.1 feature, I concur.
On Mon, Jul 29, 2013 at 5:45 PM, Ralph Goers <[email protected]>wrote: > I actually started to work on this myself several weeks ago and came to > the conclusion that I just couldn't grasp how it is better - with one > exception. You can reuse the MessageBuilder and replace the message or > arguments, etc. But that seems dangerous as it wouldn't be thread safe. > > Ralph > > On Jul 29, 2013, at 1:48 PM, Gary Gregory wrote: > > On Mon, Jul 29, 2013 at 4:39 PM, Nick Williams < > [email protected]> wrote: > >> I'm working on LOG4J2-242 to add the ability to log fluently. It's going >> to work something like this: >> >> interface Logger: >> + MessageBuilder trace(); >> + MessageBuilder debug(); >> + MessageBuilder info(); >> + MessageBuilder warn(); >> + MessageBuilder error(); >> + MessageBuilder fatal(); >> + MessageBuilder log(Level); >> >> + interface MessageBuilder: >> message(String); >> message(Object); >> message(String, Object...); >> marker(Marker); >> exception(Throwable); >> argument(Object); >> arguments(Object...); >> log(); >> >> Bruce (the requester) had suggested adding the methods that return >> MessageBuilder to a different interface (as opposed to Logger) to keep from >> cluttering the Logger API. The way I see it our options are: >> >> - Create a FluentLogger interface to house these methods. I don't like >> this option because A) it complicates things significantly, B) it makes >> users have to call a different method on LogManager (getFluentLogger) to >> get a FluentLogger, and C) it means users have to have a Logger and a >> FluentLogger if they want to use both APIs. >> >> - Create a FluentLogger interface that extends Logger. This option is >> much better. It avoids cluttering the Logger API if that's all someone >> wants to use, it doesn't require someone to have a Logger and FluentLogger >> if they want to use both APIs, and it doesn't complicate the implementation >> significantly (all implementations can just implement FluentLogger). It >> does still mean LogManager (and related classes/interfaces) need getLogger >> and getFluentLogger methods, which I don't necessarily like. >> >> - Just add these methods to Logger, which is what I intended to do from >> the get-go and is what I still think is the best option. >> > > - and there's option 4: Don't do it. > > At first glance, adding these methods to Logger looks confusing and > cluttered. The less messy solution seems to me FLogger extends Logger. > > Gary > > >> >> I'm going to proceed with #3 for now, but if someone has a strong opinion >> otherwise please voice it so that we can discuss before I complete this. >> >> Nick >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > -- Cheers, Paul
