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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
