Jess Holle wrote:
> Curt Arnold wrote:
>> One things that seemed potentially interesting is to have a JMX
>> appender that would allow log4j calls to generate JMX events.
> That would seem to be trivial.
>
> My approach has been to do any/all JMX notification in prior to and/or
> in parallel to logging. I do have JMX notification listeners that can
> log the notification.
>
> To some degree, a log4j JMX notification appender seems like a
> workaround for old code that really should be JMX instrumented and
> doing notifications but which one does not own. [For one thing,
> though log4j allows the message to be an Object, which is very good,
> the Object generally will not be a JMX open type (e.g. CompositeData
> or TabularData), which JMX notification user data really should be --
> and thus it is probable that data structure loss will occur when a
> general message Object is sent in a notification via logging -- at
> least prior to Java 6 where more open-type conversion is automated.]
> On the other hand, unless dealing in open source or doing consulting
> your customers don't have your code, don't necessarily have the skill
> to do the changes in any case, and may see needs for such
> notifications that you cannot see initially. For such cases, such an
> appender seems like a very good thing.
>
> Dumb question along these lines: how does one reliably get the entire
> MDC for a logging event, e.g. as a Map/Hashtable, from within an
> appender? I can see how to do everything else easily enough, but
> that's one little nit.
I figured out the MDC stuff -- at least a reasonable if not foolproof
approach -- and got everything working. I did the code on company time,
so I can't share it, but I can say that it is only about 400 lines total
including the extra verbosity of shoving everything possible into the
notification's user data as CompositeData and plenty of comments.
--
Jess Holle
|