Re: No Virtual Destructor for LoggingEvent

On Dec 9, 2004, at 7:53 PM, Barak Simon wrote:

> Because I need the information (an event-id) to be on a  
> *logging-message* level,
> not a thread or global.
>
> Using MDC (if at all possible) for pushing a per-message id (those ids  
> are kept in an internal configuration file and are mapped to
> a level and a format string, so that production support can easily  
> change them) seems a large overkill.
> Why we need to log these ids is of course a different matter  
> altogether (we need these ids in order to generate (together with the  
> full logger-name) a unique event-id
> in order to populate an internal syslog format)
>
> In all events (no pun intended), as long as the properties map inside  
> LoggingEvent will keep being supported in further releases, I can  
> probably use it
> quite easily, and assumingly with a lesser overhead than an MDC-based  
> solution.


That situation sounds very similar to an approach that I've used for  
localization of log messages  
(http://www.mail-archive.com/log4j-user@xxxxxxxxxxxxxxxxxx/ 
msg00479.html) in a project using log4net.  If you were careful on how  
you constructed your messages (for example, start with fixed content  
instead of variable content, did not allow your conversions to be  
affected by the default locale), you could create a fairly efficient  
localization (or in your case customization) mechanism by having a  
layout that would match the "generic" message and transform it into an  
appropriate localized content based on an external document containing  
regex patterns and substitutions.

Since all that information was already embedded into the rendered  
message, it did not require any changes to the API or hacks to the  
dispatcher.  Just a well designed layout implementation that used a  
hash map to narrow the considered regex's to avoid brute force  
searches.

If there is enough info in the logging event to generate what you need,  
then it is simplest to generate at the layout or appender instead of  
trying to generate it before it hits the dispatcher and add it to the  
logging event.  If there isn't enough info in the message already, then  
you need to have some mechanism to add it which is where I'd look at  
using the MDC or NDC, but could also be accomplished in several other  
ways.