I've been thinking about JMX too. While I agree that we should allow
commercial extensions to manage log4j (enterprise customers perfer to use
their current commercial vendor to manage everything), outfitting log4j
with JMX would help facilitate this.
I added a servlet to the appserver package that will init and startup and
configure log4j without all the classpath path hassles people have been
having. It does all its work in the init and will throw an exception if
invoked directly. I considered this a security measure. But then I
wondered if I should make this last behavior configurable. This would
allow the configuration servlet to be invoked by a browser (or anything
that can talk HTTP).
- Paul
Paul Glezen
IT Specialist
Software Services
818 539 3321
>Some things I have in mind for log4j 1.2 (just IDEA's, so comments
please):
>- configuration of log4j via JMX
I am expecting to see commercial log4j extensions to implement management
related functionality as this is quite a big piece.
I suggest that we concentrate our efforts on core log4j API. For instance,
LV2 is quite interesting to look at. See
http://www.swzoo.org/log2/documents/ and
http://www.swzoo.org/documents/miscellaneous/jsr047/
-log4j configuration via a servlet (runtime)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
