Curt Arnold wrote:
Sorry hadn't followed that one. It seems like a good replacement for
some not ready for primetime code that has been in log4j for a while.
However, since it is all new code and not any modifications to
existing log4j classes, it would make a good candidate for a log4j
companion. In a perfect world, they should be able to rev faster than
the main log4j release.
I'll see about packing that up in the sandbox as a companion and see
if we can get any feedback on it.
Agreed. I'd long since given up on this being fixed and written my own
JMX monitoring classes for log4j.
Given use cases like usage of log4j on the client, I'd rather not shove
new JMX monitoring classes into the main log4j jar. Instead providing
these in an optional companion jar makes much more sense.
[For that matter given the state of the JMX classes that /are/ present,
it would be good to remove those...]
--
Jess Holle
