Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-15532

Consistent overriding for all variants of init/destroy method inheritance

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Complete
    • Affects Version/s: 4.3.8, 5.0 RC1
    • Fix Version/s: 5.0 RC4
    • Component/s: Core:DI
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      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

      https://github.com/spring-projects/spring-framework/blob/8d707eb5304e42babe3d680c5cd3880869cfabe2/spring-beans/src/main/java/org/springframework/beans/factory/xml/BeanDefinitionParserDelegate.java#L356

      in the initialization of defaults.

      that it sets defaults regardless of parent settings

        Activity

        Hide
        juergen.hoeller Juergen Hoeller added a comment -

        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.

        Show
        juergen.hoeller Juergen Hoeller added a comment - 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.

          People

          • Assignee:
            juergen.hoeller Juergen Hoeller
            Reporter:
            helpmepro1@gmail.com Shimon Doodkin
            Last updater:
            St├ęphane Nicoll
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              7 weeks, 3 days ago