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

Consistent overriding for all variants of init/destroy method inheritance [SPR-15532] #20091

spring-projects-issues opened this issue May 10, 2017 · 1 comment
in: core type: enhancement


Copy link

spring-projects-issues commented May 10, 2017

Shimon Doodkin opened SPR-15532 and commented

beans default settings are set to each bean regardless of parent settings, parent init destroy method not called, when beans default init destroy method exists

my guess is that the bug is here

in the initialization of defaults.

that it sets defaults regardless of parent settings

Affects: 4.3.8, 5.0 RC1


Referenced from: commits ac5e259

Copy link
Collaborator Author

spring-projects-issues commented Aug 3, 2017

Juergen Hoeller commented

While the semantics are indeed debatable, I'm afraid there is no easy way out of it: Parent/child merging happens at a later point within the factory itself, since parent bean definitions may be declared in other files or even other configuration formats... So when parsing a particular XML bean definition file, all we can do is to apply the defaults as declared in that file, just like if the init/destroy method was locally declared on each bean element. I'm afraid you simply shouldn't try to mix and match default declarations with parent/child inheritance there.

That said, I discovered an inconsistency in our handling between init methods and destroy methods: While the overriding of default declarations works through empty String values for init and destroy methods, the same only works for destroy methods in a parent/child inheritance scenario. There's no good reason why this shouldn't work the same for init methods, so I'm adding that for 5.0 RC4 now, repurposing this improvement request towards that. While this may not be what you were aiming for, it's at least consistent in its semantics across all scenarios now.

@spring-projects-issues spring-projects-issues added type: enhancement in: core labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.0 RC4 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core type: enhancement
None yet

No branches or pull requests

2 participants