Re: JMX package

[Jess Holle]

Curt Arnold wrote: I suggested a log4j-JMX project as a potential Summer of Code project, but there were no proposals.  I've skimmed this issue before, but never in depth. I don't recall finding any archived discussions on the goals, design, status of the existing JMX code within log4j.  It just seemed to appear in the CVS fully formed and have had little (if any) subsequent development.  I recall seeing some discussion that had been designed with an early JMX version and was either not compatible or less than optimal with current releases of JMX. I assume that we would be eventually be interested in the code.  But it would be first good to know what specifically is wrong or less than optimal with the current JMX related code and have an outline of the options to fix the problems.  If you have specific things that are broken in the JMX implementation, it would be great if you could create bug reports for each specific flaw and ideally associated patches with each.  Much better to have multiple bug reports instead of a "Fix broken JMX code" bug report that addresses multiple issues. I'm not sure what Jacob addressed either -- that would be good to know. I know I ended up finding enough items myself that I wrote a new log4j JMX package -- based on the original but fairly distinct from it. Some issues as I recall: Some data (I forget which exactly, it's been a while) was provided as attributes such that the list of attribute names of a single MBean could (1) vary during runtime and (2) was not necessarily consistent between different runs.  The first of these issues messes up anything that caches MBeanInfo.  The latter makes programmatic use of this data unnecessarily difficult. The ObjectName's used for the MBeans were hard-wired and did not allow for use of multiple LoggerRepository's in a single JVM.  This was an absolute showstopper for me and is an issue that is spread throughout the code.  This more than anything else prompted me to start over.  In my scheme I now register an MBean for a given LoggerRepository with my own selected ObjectName and MBeans related to that repository are registered/ObjectNamed with respect to that MBean. I vaguely recall that there were numerous smaller issues as well. I believe the current JMX related code allows some manipulation of the logging configuration at run time. That is my recollection as well.  However, I suggest someone on the log4j team make a serious attempt to use the log4j MBeans first just on an attribute-by-attribute  / operation-by-operation unit test basis, second with multiple LoggerRepository's, and third with flexible base ObjectName'ing requirements.  You'll see the issues. 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. -- Jess Holle