logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Womack" <mwom...@apache.org>
Subject Re: Consistency and compatibility between logging implementations
Date Wed, 11 May 2005 04:32:42 GMT
Wow, Curt, there is a lot in this message!  I am very interested to hear 
what others have to say about this.  I have the following thoughts:

1) I like the idea of having some level of API consistency, especially at 
the client level of reporting messages.  Not being intimate with other log4X 
implementations, I just wonder how possible it is across all of the 
implementations.

2) Implementation consistency does not seem like a big deal to me.  It is 
more important that if we sell the idea of api consistency that the behavior 
of the log4X system be consistent.  But how it is implemented should be 
appropriate to the language/OS.

3) I like the idea of a shared xml configuration schema.  I think that 
having a common configuration format across languages/implementations would 
be a big plus.  I think there should still be allowance for defining an 
specific class/whatever for the specific implementation.  Allowing that in 
the schema as an attribute or element seems doable to me.

4) I think we need to better explore what it means for the log4X 
implementations to be "interoperable".  Maybe I am behind the times, but it 
seems like the current "interoperableness" comes from the XML format that is 
being passed around.  Maybe we should define a common wire protocol that 
would be more efficient?  What else does it mean to be interoperable?

And, of course, there would be a suite of test cases to ensure the above 
items.  While the implementations of the test cases would be specific to the 
log4X, they would share the same set of test case files, etc.  And there 
should be test cases to test the passing of logging events/data across the 
implementations to ensure data fidelity.

-Mark

----- Original Message ----- 
From: "Curt Arnold" <carnold@apache.org>
To: "Logging General" <general@logging.apache.org>
Sent: Tuesday, May 10, 2005 12:41 PM
Subject: Consistency and compatibility between logging implementations


> '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" 
> 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>
>
>
>
>
> 



Mime
View raw message