[jira] [Comment Edited] (LOG4J2-100) Allow Log4jLogEvent serialization with subclasses

["Das Archive (JIRA)" <ji...@apache.org>]

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

Das Archive edited comment on LOG4J2-100 at 10/17/12 7:52 AM:
--------------------------------------------------------------

Yes, adding a (non-final) field to LogEvent would also be a solution to my problem. But if adding a field is an option I would suggest extending the idea to be compatible with multiple users:
Object/Serializable getAttachment(String)
void addAttachment(String, Object/Serializable)
internally backed by a Map, which is created only on demand.

In my example I created a custom Appender to change to the subclass, but doing this in a RewritePolicy makes much more sense (I can't remember why I didn't do this).

By the way, as changing core code is still an option:
- The subclassing mechanisms could be moved up one level to LogEvent and (a new) AbstractLogEvent to generalize the approach to not require Log4jLogEvent specific code in the appenders
- the compatibility problem with MapRewritePolicy could be solved by introducing a mutable "processingMap" to LogEvent which shadows the MDC
                
      was (Author: dasarchive):
    Yes, adding a (non-final) field to LogEvent would also be a solution to my problem. But if adding a field is an option I would suggest extending the idea to be compatible with multiple users:
Object/Serializable getAttachment(String)
void addAttachment(String, Object/Serializable)
internally backed by a Map, which is created only on demand.

In my example I created a custom Appender to change to the subclass, but doing this in a RewritePolicy make much more sense (I can't remember why I didn't do this).

By the way, as changing core code is still an option:
- The subclassing mechanisms could be moved up one level to LogEvent and (a new) AbstractLogEvent to generalize the approach to not require Log4jLogEvent specific code in the appenders
- the compatibility problem with MapRewritePolicy could be solved by introducing a mutable "processingMap" to LogEvent which shadows the MDC
                  
> Allow Log4jLogEvent serialization with subclasses
> -------------------------------------------------
>
>                 Key: LOG4J2-100
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-100
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Appenders, Core
>    Affects Versions: 2.0-beta2
>            Reporter: Das Archive
>            Priority: Minor
>              Labels: patch
>         Attachments: allow_log_event_subclass_serialization.patch, ClassChangingAppender.java
>
>
> Hello!
> I am working on an extension which requires adding content to log events. As the method of adding it to the mdc has quite some overhead and the data I want to add is not really context-related, I was looking for an alternative and thought about subclassing Log4jLogEvent.
> But as AsynchAppender uses the Log4jLogEvent serialize/deserialize methods this didn't work.
> So I extended the serialize/deserialize methods to also work with subclasses.
> I'll quickly explain the the changes in the patch (in order):
> Log4jLogEvent.java:
> - not related to the improvement: ndc is never written
> - added a clone constructor to allow easy creation of subclasses Events based on Log4jLogEvents
> - make "serialize" a dynamic method as we always have an Event to serialize and it allows overwriting the method in subclasses
> - make use of the existing "readResolve" method instead of rinventing the weel
> - LogEventProxy private -> protected to allow subclassing this inner class in subclasses
> - change all instance field from private to protected to make life easier in subclasses
> - I didn't see a reason why "readResolve" should return an Object instead of "Log4jLogEvent"
> AsynchAppender.java:
> - this is actually the only change necessary to make the changes work with the existing code-base
> The only instance where subclassing still doesn't work (i.e. the subclass is removed) is in the MapRewritePolicy, but I don't think this will be a big issue and apart from adding a function to allow changing the Map in Log4jLogEvent I couldn't think of a way to solve this.
> Please note, that I haven't had the time to actually test the modified code yet!
> Best Regards,
> Das

--
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