Re: Compatibility between Log4j API and implementation

2024-11-29 Thread Piotr P. Karwasz
Hi Gary, On 28.11.2024 23:06, Piotr P. Karwasz wrote: On 28.11.2024 16:00, Gary Gregory wrote: This is beyond confusing and a new kind of "soft" jar hell IMO. I read this twice and I have no idea how a user would make sense of this. Log4j 2.x should be all in sync, all jars should be released

Re: Compatibility between Log4j API and implementation

2024-11-28 Thread Gary Gregory
This is beyond confusing and a new kind of "soft" jar hell IMO. I read this twice and I have no idea how a user would make sense of this. Log4j 2.x should be all in sync, all jars should be released with each version and match. Period. IMO. Gary On Thu, Nov 28, 2024, 9:52 AM Piotr P. Karwasz w

Re: Compatibility between Log4j API and implementation

2024-11-28 Thread Piotr P. Karwasz
Hi Ralph, On 14.11.2024 19:46, Ralph Goers 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 fea

Re: Compatibility between Log4j API and implementation

2024-11-14 Thread Piotr P. Karwasz
Hi PJ, On 14.11.2024 21:29, PJ Fanning 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. That is a bug in `log4j-api` 2.24.1 and it should affect both users of `log4j-core` 2.24.0 and 2.24.1. The

Re: Compatibility between Log4j API and implementation

2024-11-14 Thread Gary Gregory
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 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 N

Re: Compatibility between Log4j API and implementation

2024-11-14 Thread PJ Fanning
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 testi

Re: Compatibility between Log4j API and implementation

2024-11-14 Thread Gary Gregory
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 wrote: > Log4j core has a version compatibility comparison just for this reason. If > core is u

Re: Compatibility between Log4j API and implementation

2024-11-14 Thread Ralph Goers
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

Re: Compatibility between Log4j API and implementation

2024-11-14 Thread Remko Popma
I agree with Gary. That is a good reason to release every module with every release, to save people the headache of figuring out compatible versions. On Thu, Nov 14, 2024 at 9:41 PM Gary Gregory wrote: > I think you keep it simple: versions must match. > > Versions that are unmatched are not sup

Re: Compatibility between Log4j API and implementation

2024-11-14 Thread Gary Gregory
I think you keep it simple: versions must match. Versions that are unmatched are not supported. That's what I tell people at work and anyone who asks. Simple ;-) Gary On Thu, Nov 14, 2024, 5:25 AM Piotr P. Karwasz wrote: > Hi all, > > We usually recommend users to have a perfect version alignm

Compatibility between Log4j API and implementation

2024-11-14 Thread Piotr P. Karwasz
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 **t