Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade to Log4j2 2.18.0 #31589

Closed
wilkinsona opened this issue Jul 7, 2022 · 7 comments
Closed

Upgrade to Log4j2 2.18.0 #31589

wilkinsona opened this issue Jul 7, 2022 · 7 comments
Labels
type: dependency-upgrade A dependency upgrade
Milestone

Comments

@wilkinsona
Copy link
Member

No description provided.

@wilkinsona wilkinsona added the type: dependency-upgrade A dependency upgrade label Jul 7, 2022
@wilkinsona wilkinsona added this to the 3.0.0-M4 milestone Jul 7, 2022
@grgrzybek
Copy link

grgrzybek commented Jul 14, 2022

@wilkinsona hello

Let me share some experience from ops4j/org.ops4j.pax.logging#484 where I've also upgraded to Log4j2 2.18.0.

Because of:

implementations of org.apache.logging.log4j.util.PropertySource need now to announce the properties they support/handle.

I'm running Spring Boot 2.7.1 with Log4j2 upgraded to 2.18.0 and I'm getting #26953 again.

org.springframework.boot.logging.log4j2.SpringBootPropertySource has to explicitly implement:

  • org.apache.logging.log4j.util.PropertySource#getPropertyNames()
  • org.apache.logging.log4j.util.PropertySource#getProperty()

otherwise, log4j.shutdownHookEnabled property won't be taken into account.

@wilkinsona
Copy link
Member Author

Thanks very much, @grgrzybek. Your integration tests for Log4j2 are evidently better than ours.

@wilkinsona wilkinsona reopened this Jul 14, 2022
@wilkinsona
Copy link
Member Author

It looks like implementing getProperty() and containsProperty() is sufficient. That's good news as those methods are available on the interface in 2.17 so we can address this in 2.6.x which will make it easy for those using Boot 2.x and overriding the version of Log4j2.

@wilkinsona
Copy link
Member Author

I've opened #31719.

@grgrzybek
Copy link

Exactly - implementation of these two default methods will be sufficient.

BTW, from GH issues maintenance perspective - how do you mark an issue to be resolved in more than one version? For example if you (would you?) would like to upgrade to Log4j2 2.18.0 in SB 2.7.x as well.

@wilkinsona
Copy link
Member Author

We assign the issue to the milestone for the earliest branch in which it'll be fixed. As part of merging the change forwards, issues are opened for the later branches into which the change is merged. We won't upgrade to Log4j2 2.18 in 2.7.x as we avoid minor dependency upgrades in maintenance releases, although we have made an exception in the past for CVEs.

@grgrzybek
Copy link

Thanks for clarification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: dependency-upgrade A dependency upgrade
Projects
None yet
Development

No branches or pull requests

2 participants