logging-log4j-dev mailing list archives

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

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

Bruce Brouwer commented on LOG4J2-242:

The reason why I thought the fluent api would be valuable is because it isn't completely clear
from the interface that the last parameter is the throwable. The fluent way makes it more
clear in my mind. 

In the end, fixing StringFormatMessage and MessageFormatMessage to detect a throwable as the
last parameter accomplishes what I need. 

My company was evaluating logging frameworks as we currently use Commons logging. With the
renewed effort in log4j I thought now would be a good time to switch. However, the company
has decided to not switch to log4j as the logging interface, so any changes you make regarding
this issue is not going to help me directly. I do think we will use log4j 2, though because
the async loggers sound very promising to me. 

I am still interested in this and I can definitely participate in this issue if you decide
to go through with it. I just don't have any personal urgency on this issue anymore. 
> 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