GitHub user ppkarwasz added a comment to the discussion: Attribute 'additivity' is not allowed to appear in element 'Logger'
Hi @jorge683, Yes, this is indeed a bug — tracked here: apache/logging-log4j-tools#135 — in the [Log4j Docgen tool](https://logging.apache.org/log4j/tools/log4j-docgen.html), which we use to generate the XML Schema from source code. It's important to note that Log4j configuration files are inherently **schema-less** by design. Here’s why: * **Extensibility via Plugins**: Log4j Core is highly extensible — all components are implemented as [Log4j Plugins](https://logging.apache.org/log4j/2.x/manual/plugins.html). This means users can define custom plugins that the official schema won’t recognize. The published schema only includes plugins maintained by the Apache Logging Services project. * **Conditional Configuration with Arbiters**: Log4j supports a feature called [arbiters](https://logging.apache.org/log4j/2.x/manual/configuration.html#arbiters), which allows XML elements to be conditionally included at runtime. Because arbiters can introduce arbitrary structure, we’ve chosen to exclude them from the schema entirely — they simply can’t be reliably validated. * **Property Substitution in Attributes**: XML attributes in Log4j configurations always accept [property substitution expressions](https://logging.apache.org/log4j/2.x/manual/configuration.html#property-substitution), which are evaluated at configuration time. Technically, this means all attributes must be treated as strings, which limits the benefits of schema-based validation or IDE auto-completion. A user proposed using XML union types as a workaround (see [apache/logging-log4j-tools#136](https://github.com/apache/logging-log4j-tools/issues/136)), but this hasn’t yet been implemented. Because of these limitations, XML validation errors in Log4j configuration files should be taken with a grain of salt — your configuration may be perfectly valid and still trigger schema validation errors. Conversely, a configuration that passes validation might still fail at runtime if the required [Log4j Core component JARs](https://logging.apache.org/log4j/2.x/components.html) are missing. In the long term, we’re considering simplifying the schema generation process to allow users to generate a tailored XML Schema based on the specific Log4j libraries available at runtime. This would improve both the accuracy and usefulness of schema validation in real-world setups. Unfortunately, we currently don't have the bandwidth to implement this, but community contributions to improve Log4j Docgen are always welcome! GitHub link: https://github.com/apache/logging-log4j2/discussions/3696#discussioncomment-13308231 ---- This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
