[
https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481223#comment-13481223
]
Das Archive commented on LOG4J2-100:
------------------------------------
No problem, but unfortunately I'm not allowed to disclose what I'm currently
working on, so I'll try to give a broad idea and find different use cases.
First , what I'm looking for is not static during an execution, but unique for
each event. And in most cases it will be largely independent of the application
being logged and it needs to be communicated between different parts of the
logging system (e.g. from rewrite-policy to conversion). Plus it would be nice
to not have impact on other logging behaviour (like adding it to MDC, which is
additionally restricted to Strings).
Some examples I came up with are:
- computationally expensive operations, like public key encryption. These could
be done in a conversion, but then the computation would be executed for every
appender.
- operation which must only be done once per Event, like a unique sequence
number or a hash chain.
I know, that a modified MDC could be (mis)used in must cases to communicate
between the components, but since the MDC transports event context (i.e.
application context) and what I am proposing is logging context I'd consider
using the MDC a hack (which may even be difficult to implement for some types
of information).
> 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: [email protected]
For additional commands, e-mail: [email protected]
