Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Date: Sun, 21 Oct 2012 19:54:12 +0000 (UTC)
From: "Das Archive (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <803015270.7671.1350849252498.JavaMail.jiratomcat@arcas>
In-Reply-To: <462649049.51548.1350398343253.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
 with subclasses
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Das Archive commented on LOG4J2-100:
------------------------------------

The serialization case is one I didn't think about before...
If this is of such importance and subclassing may break many things, why not move all the code from Log4jLogEevent to LogEvent and make it a final class?

My solution for the attachment map would be to not serialize it by default. Rationale being, that those attachments are intended for processing inside one the logging environment only.
A flag (system property?) could be introduced to activate serialization of the attachment map. The custom de-serialization could catch ClassNotFound Exceptions and ignore such entries.

If there is interest I could provide a patch that implements this.
                
> 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