I do not think that greater LS user community expects equivalent feature sets, but they have a legitimate strong interest for consistency and a desire for interoperability within the log4 family. It is alright that an individual log4X innovate but it would be beneficial if we avoid, for example, inconsistent log4j and log4net expression language (unless that was driven by some platform issue). This could arise due to either simultaneous independent development or the initial implementation making architecture decisions that are impractical for the others to follow.
While innovation can come from anywhere, I'd suspect that all log4net and log4cxx developers are also decent Java developers would likely prefer to use log4j as the vehicle for innovation as long as the innovation fits within the log4X metaphor. If it is a significant conception departure from log4X, then it would be best to be done as a subproject distinct from the log4X family and then the implementation language is up to that team.
Interoperability is frequently mentioned, but I think API consistency is more significant concern to our user communities. Here are some definitions of ways that the frameworks can be compared:
Implementation Consistency: Primarily of value to developers who work on multiple implementations. Not a core value of the user community other than how it affects the usefulness of the product.
API consistency: A core concern of users who use more than one framework since it minimizes conceptual shifts when shifting between languages. This allows a developer to start with the log4X appropriate for his current project and then shift to the log4X consistent to the subsequent projects. FYI: I started with log4net for a .NET project, then log4j and now log4cxx. Implementation consistency of the unit tests is a good metric for this.
Configuration consistency: It is desirable that configuration files be consistent.
Interoperability: Two radically different approaches to logging could share the same XML representation or wire format of a log message.
Currently log4cxx and log4j have, in my opinion, a moderate but increasing level of implementation consistency, a relatively high level of API consistency and configuration consistency and a moderate level of interoperability (the main problem being SocketAppender's wire format). It has been a long time since I looked at log4net and won't venture an opinion there.
Having an XML Schema for the configuration file was suggested as a good step for configuration consistency. I had started working on a configuration schema within log4j and would expect to pick it up again when I look addressing namespace related issues and at porting Joran to log4cxx (having a SAX based configuration would allow log4cxx to drop platform-specific dependencies on MSXML and libxml2). The process that I started was to develop unit tests that allow sample configuration to be tested against a schema and then evolve the schema as more sample docs are added to the test suite. The tests are in place, but the schema present is a hack that is just well developed enough to accept all the good configurations and reject all the bad in the small test suite and is not representative of a schema that approaches accepting all valid configurations and rejecting a high fraction of bad configurations. FYI: I was an annoyingly interested outside observer on W3C XML Schema effort and was a contributor to earlier schema efforts.
A configuration schema is a good documentation for the configuration format and a guide to creation when used by schema aware tools, but it is not a test of configuration consistency. A message schema on the other hand may be a good test of interoperability.
There are a couple of glaring issues in the current XML configuration file (at least as supported by log4j and log4cxx):
1. Appender types are identified by identified by the corresponding class name in log4j.
2. Configuration files are weakly typed, they are not much more than bags of key/value pairs that XML Schema will not be able to type- check or significantly assist in editing.
A more neutral and stronger typed configuration file might looks something like (transliteration of tests/input/xml/DOMTest1.xml):
<configuration xmlns="http://logging.apache.org/configuration"; xmlns:log4j="http://logging.apache.org/configuration/log4j";>
<fileAppender id="A1" file="output/temp.A1" append="false">
<patternLayout conversionPattern="%-5p %c{2} - %m%n"/>
</fileAppender>
<fileAppender id="A2" file="output/temp.A2" append="false">
<log4j:ttccLayout dateFormat="ISO8601"/>
</fileAppender>
<logger name="org.apache.log4j.joran"><info/></logger>
<logger name="org.apache.log4j.joran.action.PriorityAction"><error/></logger>
<logger name="org.apache.log4j.config"><info/></logger>
<logger name="org.apache.log4j.FileAppender"><info/></logger>
<logger name="org.apache.log4j.xml"><info/><appender-ref ref="A1"/></logger>
<root>
<debug/>
<appender-ref ref="A1" />
<appender-ref ref="A2" />
</root></configuration>
Elements in the http://logging.apache.org/configuration namespace would correspond to a fixed definition shared by all the log4X's (like consoleAppender) while each implementation can also introduce elements from its own namespace. The implementation would need to know how map the XML qualified name to the implementing class name. User-supplied appenders or layouts would be configured by elements from arbitrary namespaces, but some mechanism to map qualified name to class name would need to be supplied. An explicit mapping might look something like:
<configuration xmlns="http://logging.apache.org/configuration"; xmlns:example="http://www.example.com/logging";>
<log4j:classes>
<example:fooAppender classname="com.example.logging.FooAppender"/>
</log4j:classes>
<log4net:classes>
<example:fooAppender classname="Example.Logging.FooAppender"/>
</log4net:classes>
<example:fooAppender barCount="2"/> </configuration>
