logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Consistency and compatibility between logging implementations
Date Tue, 10 May 2005 19:41:44 GMT
've had some thoughts on consistency and interoperability between the  
framework subprojects and thought that I would throw them out here to  
get a discussion going.

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"  
      <fileAppender id="A1" file="output/temp.A1" append="false">
             <patternLayout conversionPattern="%-5p %c{2} - %m%n"/>
      <fileAppender id="A2" file="output/temp.A2" append="false">
             <log4j:ttccLayout dateFormat="ISO8601"/>
      <logger name="org.apache.log4j.joran"><info/></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  

        <appender-ref ref="A1" />
       <appender-ref ref="A2" />


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"  

      <example:fooAppender barCount="2"/>

View raw message