[
https://issues.apache.org/jira/browse/LOG4J2-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Brouwer updated LOG4J2-242:
---------------------------------
Description:
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?
was:
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 MessageBuilder interface, maybe tie it
into the MessageFactory classes. This MessageBuilder interface could have these
methods:
MessageBuilder message(String pattern, Object... params);
MessageBuilder with(Throwable t);
To avoid excessive object creation, you could probably simply have
ParameterizedMessage and the like implement MessageBuilder and simply return
themselves, and make them a little less immutable.
> 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: [email protected]
For additional commands, e-mail: [email protected]
