On Mon, Jul 29, 2013 at 4:54 PM, Paul Benedict <[email protected]> wrote:
> Flogger. Very nice... or painful. > It was just shorthand, but I'm not a fan of a fluent interface here, so I would not want it to clutter the API, especially when I think of crowding an auto-complete pop-up in an IDE. I am wondering how necessary this is ATM, compared to other bug fixing. It seems like it could be added in 2.1 if more than one person (or a handful) asks for it. Gary On Jul 29, 2013 3:48 PM, "Gary Gregory" <[email protected]> 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 >> > -- 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
