I hope we don't duplicate the little turds slf4j leaves on your console when it finds this or that on your class path 😉
Gary On Thu, Nov 14, 2024, 3:31 PM PJ Fanning <fannin...@apache.org> wrote: > 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 > > > > > > > > > > > > >
