The problem with log4j-api 2.24.1 is it can return null Logger instances when used with log4j-core 2.24.0 leading to NullPointerExceptions. Most users do not expect that patch releases shouldn't cause this level of compatibility issue. The NPEs happen at runtime and users may not do enough testing of the jar changes before going to production.
If you are going to recommend that log4j-api and log4j-core must use the exact same version, could you add a version check that kicks in at class initialization time, so that cursory testing is more likely to catch the version mismatch? On 2024/11/14 18:50:15 Gary Gregory wrote: > I don't even want to try and explain that... it sounds backwards. I'll just > keep everything nice and simple in my explanations to people: match is nice. > > Gary > > On Thu, Nov 14, 2024, 1:47 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > Log4j core has a version compatibility comparison just for this reason. If > > core is updated to require some new feature in the API then the version it > > checks for needs to be updated and Log4j-API needs to update its version > > when it adds new features. > > > > Ralph > > > > > On Nov 14, 2024, at 3:25 AM, Piotr P. Karwasz <pi...@mailing.copernik.eu> > > wrote: > > > > > > 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 > > > > > > > >
