[
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 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.
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:
{code}
log.info(new ParameterizedMessage("abc: {} xyz: {}", abc, xyz), throwable);
{code}
I realize that this particular example would work with this code by default:
{code}
log.info("abc: {} xyz: {}", abc, xyz, throwable);
{code}
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:
{code}
log.info(new ParameterizedMessage("abc: {} xyz: {}", abc,
xyz).throwing(throwable));
{code}
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:
{code}
Message withParameters(Object... parameters);
Message throwing(Throwable throwable);
{code}
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:
{code}
log.with(exception).info("abc: {} xyz: {}", abc, xyz);
// or maybe this
log.message("abc: {} xyz: {}", abc, xyz).with(exception).info();
{code}
That would necessitate something like a MessageBuilder interface, maybe tie it
into the MessageFactory classes. This MessageBuilder interface could have these
methods:
{code}
MessageBuilder message(String pattern, Object... params);
MessageBuilder with(Throwable t);
{code}
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 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.
--
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]
