Curt Arnold wrote:
For the blob events I would build my own appender but if it was derived from LoggingEvent and didn't overide or change any of the functionality I would think it would work fine.
Why derive a class If it doesn't override or change functionality?
Sorry, I mean I wouldn't change the existing functionality, just add a new data member.
Even if it was transported, everything in the log event (minus the blob) should transport fine. So I could have some appenders sending it to files without the blob and other appenders that could inspect the class, realize it's a BlobEvent and extract and handle the blob.
Inspecting the class would require RTTI. There is not a virtual destructor, so if the log event was deleted by log4cxx, the new fields would not be destructed. Copy constructors are used to buffer logging events for asynchronous logging.
Too much of the framework depends on a concrete implementation of LoggingEvent to be easily circumvented.
Hmmm, that could be a problem.
