I'd also add that as long as log4j is going to continue to support
multiple LoggerRepository's per JVM the log4j JMX must fully support this.
The lack of such a capability was the clincher for me not using the
existing log4j JMX classes. There were other bugs/issues as well.
Beyond this I also really didn't like the fact that various things that
are logically data collections had each element modeled as a JMX
attribute. I'm not against dynamic attributes -- they make perfect
sense for reflection based coverage of Appender and Layout
implementations, but there were cases [whose details I forget,
unfortunately], where a logical list of data was converted into a
dynamic attribute set -- to ill effect. I used child MBeans for such
cases -- which also allowed for broader/deeper configuration coverage.
--
Jess Holle
Curt Arnold (JIRA) wrote:
log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
----------------------------------------------------------------------------
Key: LOG4J2-9
URL: https://issues.apache.org/jira/browse/LOG4J2-9
Project: Log4j 2
Issue Type: Wish
Components: Configurators
Reporter: Curt Arnold
log4j 2.0 should avoid implementing its own configuration framework in
preference to being compatible with commonly used configuration frameworks and
services. Compatibility with existing log4j 1.2 configuration files might be
accomplished by XSLT transforms that convert the legacy format into the
equivalent with the selected configuration framework. log4j 2.0 should be
readily configurable with JMX and a JMX centric design for configuration may be
desirable.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
