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?
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.
The LoggingEvent constructor in response to a logging request is where the request gets all packed up assuming that it will be appended to something. Obviously, you want to delay that constructor until you are reasonably certain that an appender will actually do something with it. However, there has to be some threshold point where that cost is incurred (at least to keep the dispatch and appending code sane) and once you've reached that point, you might as well get it done with. The current implementation of log4cxx might be doing the constructor a little too early, but those things can be improved without affecting the API. However, I don't think that you can ever eliminate a threshold point where you really have to decide if you are logging or not.
