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

Closed
spring-issuemaster opened this issue May 10, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

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

Attachments:

Referenced from: commits ac5e259

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.