[
https://issues.apache.org/jira/browse/LOG4J2-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239727#comment-15239727
]
Remko Popma commented on LOG4J2-1365:
-------------------------------------
I'm not being facetious; I really can't see why you want to do this. We
discussed reducing data copies in LOG4J2-1329, but you must have noticed while
implementing this that reusable messages must re-initialize the returned
CharSequence each time this method is called. So there's no benefit over
StringBuilderFormattable in terms of copy reduction.
On the other hand, there are drawbacks of doing this. I don't like that the all
messages now need to maintain a mutable buffer (seems like a lot of changes
only to benefit one Layout). Also, as you point out in the code, it is not
thread safe.
It also means there would be two mechanisms to accomplish the same thing:
StringBuilderFormattable with its {{formatTo(StringBuilder)}} method and your
proposal. This is confusing so we need a good reason for doing this: why do we
need two? Which one should Messages implement and what are the trade-offs? Same
for Layouts: if a Message implements both mechanisms, which should they choose
and why?
> Add CharSequenceFormattable interface for Messages to improve performance of
> Layouts
> ------------------------------------------------------------------------------------
>
> Key: LOG4J2-1365
> URL: https://issues.apache.org/jira/browse/LOG4J2-1365
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
> Affects Versions: 2.5
> Reporter: Mikael Ståldal
> Assignee: Mikael Ståldal
> Priority: Minor
>
> {code}
> public interface CharSequenceFormattable {
> CharSequence getFormattedCharSequence();
> }
> {code}
> This can be implemented by Messages where it makes sense and used by Layouts
> where it makes sense.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
