strictxml sandbox

[Curt Arnold <ca...@apache.org>]

I've committed a minimally functional strict XMLConfigurator to the  
sandbox and updated the sample files and schemas before putting that  
experiment to rest for a while.  I was thinking that if things fell  
in place fast enough, it might give me an option for reworking the  
DOMConfigurator in log4cxx.  However, while I like a lot of things  
about the approach and hope to work it into log4j 2.0, it isn't going  
to help me with the log4cxx DOMConfigurator.

To check out:

svn co http://svn.apache.org/repos/asf/logging/sandbox/strictxml  
strictxml

Builds with Maven 2 and Ant, but I didn't work an XSLT step into the  
Maven build so you have to manually run "ant preprocess" or the Maven  
unit tests will fail.



 From the STATUS file:

2 March 2006

The project is currently an early experimental prototype of a strict  
XML configurator.

The configuration language is not compatible with existing log4j  
configuration files.
The language is designed so that schema-aware editors or other tools  
can identify
most configuration errors and guide the user to create valid  
configurations.
The schema is also intended to support generation of user  
documentation for the
configuration language, either through generic schema documentation  
tools or
possibly through custom XSLT transforms.

The schemas and configurators support multiple namespaces.  The  
general logging
configuration namespace attempts to only support those features that  
have common
semantics between log4j, log4cxx and log4net.  The product specific  
namespaces
support product specific features.  The schemas are constructed from  
a core
set of definitions in src/xsd/common.xml that is included in the  
generic,
log4j and log4cxx schemas.  Many schema aware processors do not  
tolerate this
document structure, "ant preprocess" will generate schema files in the
target directory that have the external entity (like an include file)  
expanded.

The configurator attempts to report errors as quickly as possible and
do no configuration until the entire configuration has been processed  
without
error.  The configurator by default is strict, but a lax and  
forgiving configuration
can be performed by providing a SAXErrorHandler and suppressing  
errors by
not throwing an exception on calls to error(SAXParseException).

The ability for the configurator to report errors is limited by  
log4j's internal
consumption of errors.  Likely log4j 2.0 will provide API methods  
that report errors.

Unlike current log4j configuration files, relative file paths in  
configuration files
are relative to the configuration file, not to the current working  
directory.  To
specify a path relative to the current working directory, use "$ 
{user.dir}/relative.log"
and pass System.getProperties() as the properties parameter.

Currently, only a subset of the available appenders (file and  
console), filters
and layouts are provided.  The unit tests check that valid  
configuration files
are processed without false errors, but there are no tests ensuring  
that the
result configuration matches expectations.  Many filters are only  
placeholders
at this time.

Examples of configuration files can be found in src/test/resources/ 
valid.