JMX package

[Alex Osmakoff <al...@thelma.com.au>]

Hi All,
 
I've fixed the existing JMX package and wrote a HTML adapter on the top
of SUN implementation to control logging configuration at the runtime.
It proved to be quite handy for our integration testing (that runs
application on remote machine).
 
Is this of any interest to you?
 
Cheers,
 
Alex Osmakoff 

Re: JMX package

[Jess Holle <je...@ptc.com>]

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

Re: JMX package

[Jess Holle <je...@ptc.com>]

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

Re: JMX package

[Curt Arnold <ca...@apache.org>]

On Jul 8, 2006, at 2:41 PM, Jacob Kjome wrote:
> At 07:40 PM 7/5/2006, you wrote:
>> Hi All,
>>
>> I've fixed the existing JMX package and wrote a HTML adapter on  
>> the top of SUN implementation to control logging configuration at  
>> the runtime.
>> It proved to be quite handy for our integration testing (that runs  
>> application on remote machine).
>>
>> Is this of any interest to you?
>>
>> Cheers,
>>
>> Alex Osmakoff
>
>


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 believe the current JMX related code allows some manipulation of  
the logging configuration at run time.  One things that seemed  
potentially interesting is to have a JMX appender that would allow  
log4j calls to generate JMX events.

Would appreciate any and all comments.




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Re: JMX package

[Jacob Kjome <ho...@visi.com>]

I would suggest creating an enhancement report in Bugzilla (or are we 
using Jira now?) and attaching the fixed code to that report.  That 
should get more traction than an email to the list.

Jake

At 07:40 PM 7/5/2006, you wrote:
>Hi All,
>
>I've fixed the existing JMX package and wrote a HTML adapter on the 
>top of SUN implementation to control logging configuration at the runtime.
>It proved to be quite handy for our integration testing (that runs 
>application on remote machine).
>
>Is this of any interest to you?
>
>Cheers,
>
>Alex Osmakoff


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org