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

Curt Arnold wrote:

Every part in the chain believes that it can treat the messages as text. A file appender, for example, would possibly apply a character set encoding conversion before outputting a file. It would be unlikely that your binary extraction code would work reliably if the user reconfigured the output encoding. Whatever you put in the message has to be unaffected by encoding changes.

If your concern is avoid unnecessary conversions . Use the LOG4CXX_DEBUG etc macros and a ToString method.


// some stringizing method for Foo std::string ToString(const Foo&) { ... }

...

Foo myFoo();

//   ToString is not executed unless logger->isDebugEnabled() == true
LOG4CXX_DEBUG(logger, ToString(myFoo));







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

In my application I might be generating a very large number of log events. Most times I don't want to know what's in the blob, but for a small percentage of these messages I may decide that I want to convert the blob into a string (or use some viewer to display what is in the blob). So while I may end up converting it to a human readable string I can delay that until I know I want to look at the event.

As for binary properties I could see that would make writing filters more efficnet, instead of doing a ton of string compares I can compare primitive data types.

What do you think?  Am I approaching this wrong?

Ceki G�lc� wrote:






Reply via email to