As far as I recall, the current JMX code was added in one commit long
time ago by a single developer with no preceding discussion about use
cases, design strategies, etc, little or no feedback after it was
introduced and no unit tests. Since it has been present in log4j
releases, the project can't make any changes that would break
compatibility.
Pretty much means that any serious work on JMX would need to be done
in an sandbox project using different package names, etc. Obviously,
this time we would want discussion, unit tests and the like. One of
my goals for log4j 2.0 development was to rethink the whole
configuration space and making it much more friendly to JMX or JMX-
centric. So if a JMX sandbox project starts up, the first thing to
look at is whether it wasn't to design for log4j 2.0 and then
possibly retrofit for log4j 1.2 or design for log4j 1.2. There has
been some previous discussion, so anyone interested could search at
the archives and the bug list for JMX.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
