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.