logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: JMX package
Date Mon, 10 Jul 2006 11:40:11 GMT
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 

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

View raw message