Curt Arnold wrote:


On Aug 27, 2004, at 1:21 PM, Jack Strohm wrote:

I was thinking about making a customized LoggingEvent (a BlobEvent?) that supported what I need (blobs and properties with primitive data types) and then my own Appender to transport it. I guess it wouldn't be something anyone else would want to use, but I think it would get the job done for me. So the normal appenders could treat it normally but the blob specific portion of the event could be handled by our speciallized appender.

Yeah, I'm already using the macro's, but the concern is to reduce the time it takes to generate a message if possible (so no int to string conversions if it is not necessary).


Pain, much pain. To the best of my knowledge, the logging event is a concrete class in all the log4j variants and not ameniable to extension. log4j does things like serialize the LoggingEvent in the socket appender and transport the bits across the wire to Chainsaw. For log4cxx especially, the internals are unfrozen and will be changing and your fork could very easily become unsupportable.

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. 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.



Some things, like floating point numbers and dates, are very expensive to format in legible forms (aka 3.1415926 or 27 Aug 2004). However, spitting out a hex representation, which contains the same info in a much less legible form, can be pretty darn cheap.

Yes, I've also thought about hexing the binary data and putting it into a string for transport, but I have a fealing the developers I'm working with would frown on that. But it still remains an option.



You might consider logging the blobs to a separate logger (or hiearchy). That would allow the blob log to be disabled without disabling the general application log.


Yes, that's another option I've thought about.

Thanks a lot for all your suggestions

- jack






Reply via email to