You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Das Archive (JIRA)" <ji...@apache.org> on 2012/10/16 16:39:02 UTC
[jira] [Created] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Das Archive created LOG4J2-100:
----------------------------------
Summary: 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
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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481232#comment-13481232 ]
Ralph Goers commented on LOG4J2-100:
------------------------------------
OK - here is one other idea for you to think about.
I can envision a WrapperMessage that takes another argument on its constructor along with a Map or something else. The Wrapper would be a Java Proxy that exposes all the interfaces of the orginal message and simply routes calls to those methods to the wrapped object. However, the other data could then be added to the Message without the original Message being aware of it. You could then have a WrappedMessageRewritePolicy to accomplish the wrapping.
> 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
[jira] [Updated] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Das Archive (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Das Archive updated LOG4J2-100:
-------------------------------
Attachment: ClassChangingAppender.java
Added a minimal Example how the subclassing can be done.
> 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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Das Archive (JIRA)" <ji...@apache.org>.
[ 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Jan Alsenz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482577#comment-13482577 ]
Jan Alsenz commented on LOG4J2-100:
-----------------------------------
Hi!
Maybe my post was misleading, I did not explicitly support the LogEvent extensibility, but wanted to give a possible use case and throw the option of extending the Message into the discussion.
I have no idea, which option is the best to implement the requirement...
> 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
[jira] [Updated] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Das Archive (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Das Archive updated LOG4J2-100:
-------------------------------
Attachment: allow_log_event_subclass_serialization.patch
Added the patch
> 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
[jira] [Comment Edited] (LOG4J2-100) Allow Log4jLogEvent
serialization with subclasses
Posted by "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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477229#comment-13477229 ]
Ralph Goers commented on LOG4J2-100:
------------------------------------
Before focusing on the solution I'd like to focus on the problem and see if there are other alternatives. Would adding a Serializable field to the LogEvent (and the constructor of course) satisfy your needs? If not, can you provide more information on what you need? I assume you are creating your own LogEvent in a RewritePolicy? The ability to do that does seem interesting and might make your patch worthwhile even if adding a Serializable field would meet the needs.
> 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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Gary Gregory (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490022#comment-13490022 ]
Gary Gregory commented on LOG4J2-100:
-------------------------------------
Don't be discouraged, we're all busy, I know I am ;)
> 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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Das Archive (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481054#comment-13481054 ]
Ralph Goers commented on LOG4J2-100:
------------------------------------
Can you provide some examples of what you would do with what you are proposing? The idea that the "attachment map" would be transient is a possibility but I'd really like to understand what you would like to do.
LOG4J2-28 mentions adding properties to the LogEvent. This was done in Log4j 1.x by using a RewritePolicy to add properties to the mdc map in the event. I'm working on adding that and the ability to configure properties right on the Logger. Because they are effectively added on to the ThreadContextMap the values would only be allowed to be Strings. I'm wondering if this would meet your needs or be of any value to you.
> 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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480800#comment-13480800 ]
Ralph Goers commented on LOG4J2-100:
------------------------------------
After looking at the patch and thinking about this I'm leaning away from allowing the LogEvent to be extended for two reasons.
1. As you point out MapRewritePolicy will have a problem rewriting any event that isn't a Log4jLogEvent. Currently MapRewritePolicy is the only RewritePolicy but this problem will occur with any RewritePolicy.
2. Having multiple variations of LogEvents will cause problems for applications that accept serialized LogEvents as they will need to have the various classes needed to deserialize the events. This is an area I would really like Joern's and Scott's feedback on as they have been dealing with Lillith and Chainsaw and presumably understand the issues better than me.
Even adding a new field that allows arbitrary serializable objects to be added to the event could have the same impact as item 2, so before anything is done with this I would really like to get more feedback.
> 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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "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 commented on LOG4J2-100:
------------------------------------
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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Das Archive (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481256#comment-13481256 ]
Das Archive commented on LOG4J2-100:
------------------------------------
Yes, but then AsynchAppender and the normal RewritePolicy would have to be aware of such WrapperMessages, or the attachment will be lost during their processing.
Which is basically why I came up with my original patch. Wrapper and Subclass share the same problems in this regard.
> 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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482609#comment-13482609 ]
Ralph Goers commented on LOG4J2-100:
------------------------------------
OK, thanks Jan. If you need some help implementing your use case please feel free to start a discussion on the dev or user's lists. I'd love to hear what you have in mind.
> 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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Jan Alsenz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490015#comment-13490015 ]
Jan Alsenz commented on LOG4J2-100:
-----------------------------------
After the underwhelming feedback to my mail on dev, should I repost on user?
> 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
[jira] [Commented] (LOG4J2-100) Allow Log4jLogEvent serialization
with subclasses
Posted by "Jan Alsenz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482391#comment-13482391 ]
Jan Alsenz commented on LOG4J2-100:
-----------------------------------
Hello!
Maybe I can help out with a use-case:
I was recently looking for an secure audit-logging facility for Java (something like http://www.schneier.com/paper-secure-logs.html ) and didn't come up with anything useful, so I am now considering building a Log4j 2 plugin to do it.
The requirements match the one mentioned here pretty closely: the message MAC/Encryption must be done only once, or the hash chain breaks and it is relatively expensive.
Since I want to be able to output both, encrypted and unencrypted log-entries, both versions must be communicated to appenders (conversions) saving the logs.
I'm currently investigating using custom Message objects to do this, but am not yet sure if it will work as expected.
> 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