Hi all,
We usually recommend users to have a perfect version alignment between
`log4j-api` and `log4j-core`. As reported by Dominik in [1], users of
Apache POI and other libraries that use Log4j API, often end up with
mismatched versions. The reason behind this is simple: `log4j-api` is a
**transitive** dependency for most users, while `log4j-core` is a
**direct** runtime dependency. If an application depends on Apache POI
and Log4j Core, the resolved version of `log4j-api` is managed by
Maven's conflict resolution.
Should we support and test Log4j with mismatched version of `log4j-api`
and `log4j-core`?
The general expectation for an API/implementation version compatibility
is that implementation 2.<n>.x is compatible with API 2.<m>.x whenever
<n> is at least <m>. For example an application that uses Servlet API
2.0, should be compatible with a Servlet API 2.4 server (actually it is
compatible with a Servlet API 4.0 server too). Should we provide a
similar compatibility guarantee for Log4j API and Log4j Core?
Of course the nice compatibility properties of Servlet API come from the
fact that even if an application is **compiled** using Servlet API 2.0,
at runtime the server will load the Servlet API version appropriate for
the server. A Servlet API server will accept applications written using
any previous version of the Servlet API as long as the Servlet API
itself has no breaking changes (like the `javax` to `jakarta` migration
;-)).
Logging APIs do not profit from the same mechanism and semantically
MINOR changes in the API (like the addition of a new
`LoggingEventBuilder` interface) break the compatibility of a logging
implementation with previous releases of the matching logging API. This
is for example the main reason why the SLF4J2-to-Log4j API bridge
(`log4j-slf4j2-impl`) does not work with SLF4J 1.7.x. If we want Log4j
Core `2.25.0` to work with Log4j API `2.24.0` we:
* Can not use in Log4j Core any new utility method that appears in Log4j
API `2.25.0`.
* The compatibility will be broken if we add a new type to the public
Log4j API (unlikely).
I think I can live with these restrictions. If we really feel that we
need to share some utility methods between the `log4j-core`,
`log4j-to-jul` and `log4j-to-slf4j` implementations, we can create a
`log4j-kit` artifact as we have done in Log4j Core 3.x.
What do you think? Can we guarantee that in the near future new versions
of Log4j Core will be compatible with Log4j API 2.24.x?
Piotr
[1] https://github.com/apache/logging-log4j2/issues/3196
