logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-242) Make Messages more fluent
Date Thu, 30 May 2013 15:46:21 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13670430#comment-13670430

Gary Gregory commented on LOG4J2-242:

Just don't _force_ users to use a fluent API.
> Make Messages more fluent
> -------------------------
>                 Key: LOG4J2-242
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-242
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.0-beta5
>            Reporter: Bruce Brouwer
> I really like the feature were we can pass in a Message object into the logger methods.
However, it bugs me that some of the implementations of Message provide vararg constructors,
and others only provide an Object[] parameter. I really would like to write this code:
>     log.info(new ParameterizedMessage("abc: {} xyz: {}", abc, xyz), throwable);
> I realize that this particular example would work with this code by default:
>     log.info("abc: {} xyz: {}", abc, xyz, throwable);
> But the other Message implementations don't provide a vararg constructor, nor do they
try to detect the last parameter as a Throwable.
> [LOG4J2-48] addresses some of the complexity of having varargs with the last vararg being
an implicit final parameter, but again, this only works with ParameterizedMessage. But I would
like this to be more consistent across the board. One idea that I had was this:
>     log.info(new ParameterizedMessage("abc: {} xyz: {}", abc, xyz).throwing(throwable));
> Now all of the message constructors (not just ParameterizedMessage) could have varargs
with none of them providing a Throwable parameter in the constructor, but provided through
a more fluent API. I don't know that it would warrant adding it to the Message interface,
but we could go further with it by adding these methods:
>     Message withParameters(Object... parameters);
>     Message throwing(Throwable throwable);
> It wouldn't be absolutely necessary as the concrete implementations could define that
and work in my case.
> Another idea that I had was maybe a bit more impactful to the Logger API. What if I wrote
my code like this:
>     log.with(exception).info("abc: {} xyz: {}", abc, xyz);
>     // or maybe this
>     log.message("abc: {} xyz: {}", abc, xyz).with(exception).info();
> That would necessitate something like a LogBuilder interface, maybe tie it into the MessageFactory
classes. This LogBuilder interface could have these methods:
>     LogBuilder message(String pattern, Object... params);
>     LogBuilder with(Throwable t);
>     LogBuilder marker(Marker marker);
>     LogBuilder level(Level level);
>     void info(); // and others like it
>     void info(String pattern, Object... params); // and others like it
> I'm not exactly sure what the best way would be to go and implement this as I'm sure
you don't want to have objects created all over the place. 
> Is this an idea worth pursuing a bit further?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message