Attribute 'additivity' is not allowed to appear in element 'Logger'

[jorge683]

According to https://logging.apache.org/xml/ns/log4j-config-2.23.1.xsd , "additivity" is not allowed in "Logger." This is why I'm receiving a WARN from my IDE. Is this a bug?

[ppkarwasz]

Hi @jorge683,

Yes, this is indeed a bug — tracked here: apache/logging-log4j-tools#135 — in the Log4j Docgen tool, 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. 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, 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, 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), 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 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!

[vy]

Because of these limitations, XML validation errors in Log4j configuration files should be taken with a grain of salt

@ppkarwasz, this is a very nice and elaborate response. I think users would find it helpful to have a (diet version of?) this explanation in the XML configuration features page. AFAICT, the message we will get across should be "Use XML and XSD – this is the recommended combo. Yet be aware that XSD is neither exhaustive, nor 100% accurate."