Yes, makes sense to me.
Remko
Sent from my iPhone
> On Jan 27, 2017, at 3:32, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> Hi All:
>
> Just like in our SMTP appender, I have a custom Appender which needs to track
> LogEvents. To do this without falling prey to all of our no-GC epic
> cleverness, the SMTP appender does this:
>
> public void add(LogEvent event) {
> if (event instanceof Log4jLogEvent && event.getMessage() instanceof
> ReusableMessage) {
> ((Log4jLogEvent) event).makeMessageImmutable();
> } else if (event instanceof MutableLogEvent) {
> event = ((MutableLogEvent) event).createMemento();
> }
> buffer.add(event);
> }
>
> The code in my Appender is functionally identical, I just use a different
> buffer type.
>
> This kind of Appender code is impossible to write correctly first IMO.
>
> My first implementation was just:
>
> public void add(LogEvent event) {
> buffer.add(event);
> }
>
> After a bug hunt by a colleague of mine, I thought the fix for our use case
> was 'simple':
>
> public void add(LogEvent event) {
> buffer.add(event instanceof MutableLogEvent ? ((MutableLogEvent)
> event).createMemento() : event);
> }
>
> But that was not complete!
>
> Our Appender now does the same thing the SMTP Appender does.
>
> Should we allow LogEvent to express this more cleanly? Maybe:
>
> public void add(LogEvent event) {
> buffer.add(event.asImmutableLogEvent());
> }
>
> Where MutableLogEvent.asImmutableLogEvent() just calls createMemento() and
> LogEvent changes its internal state by calling makeMessageImmutable() and
> returns 'this' since creating a new LogEvent is not needed.
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
