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
|
