You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@logging.apache.org by Curt Arnold <ca...@apache.org> on 2005/05/10 21:41:44 UTC
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>
Re: Consistency and compatibility between logging implementations
Posted by Mark Womack <mw...@apache.org>.
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" <ca...@apache.org>
To: "Logging General" <ge...@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>
>
>
>
>
>