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.
