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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo
