[
https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482425#comment-13482425
]
Ralph Goers commented on LOG4J2-100:
------------------------------------
I really should publish the use case which drove me to start working on Log4j 2
in the first place.
We have a similar need for audit logging and, as is good practice, our security
team does not want audit data stored in the web tier and any sensitive data has
to be encrypted when written to disk. Note that this is a bit different that
the paper you linked to as it avoids the problem of writing logs to untrusted
machines as much as possible.
So what we are doing is using Log4j 2 with the Flume Appender and sending our
events as StructuredDataMessages. Flume will write to disk temporarily to
provide guaranteed delivery and will encrypt the data until it is delivered, at
which time it is deleted. We then use Cassandra as our final repository.
Unfortunately, Cassandra has not yet incorporated encryption into the product
so we are using a full disk encryption solution on the file systems Cassandra
writes to.
Using encryption in the message itself is certainly workable but then the
consumer of the events has to be aware of how to unencrypt it.
While your use case is valid and absolutely one Log4j 2 needs to support, it
isn't clear to me how this supports the requirement that the LogEvent needs to
be able to be extended.
> 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]
