Spring Framework
  1. Spring Framework
  2. SPR-3542

scope (& similar attributes) on abstract beans should be inherited in child beans, or not permitted

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1 M2
    • Fix Version/s: 3.0 RC2
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      Hi,

      given this config:

      <bean id="parent" scope="prototype" abstract="true">
      <property name="prop" ref="prop" />
      .....
      </bean>

      <bean id="child1" parent="parent" class="X" />
      <bean id="child2" parent="parent" class="X" />
      <bean id="child3" parent="parent" scope="singleton" class="X" />

      the prototype attribute on the abstract parent does not carry down to any child beans. So child1 & 2 here are scoped singleton, wouldn't it make sense to inherit that? I am not sure, just throwing this out there for someone to consider. If it does, the child beans could also override scope and the similar attributes.

      If it doesn't make sense, abstract="true" & scope="*" should probably generate an xml error since they will be a waste of typing.

        Issue Links

          Activity

          Hide
          Dave Syer added a comment -

          The scope= attribute is somewhat special in this and other respects (and that of course is surprising). It also turns out that setting the scope in an inner bean has no effect for similar reasons. Isn't that just as bad or worse?

          Show
          Dave Syer added a comment - The scope= attribute is somewhat special in this and other respects (and that of course is surprising). It also turns out that setting the scope in an inner bean has no effect for similar reasons. Isn't that just as bad or worse?
          Hide
          Stéphane Nicoll added a comment -

          Can you implement this or do you welcome patches maybe? T

          This would reduce a lot the XMLs in specific use cases (for instance, we have a bunch of prototype beans that we and our customers have to define. It's so easy to forget to define this value ...)

          Show
          Stéphane Nicoll added a comment - Can you implement this or do you welcome patches maybe? T This would reduce a lot the XMLs in specific use cases (for instance, we have a bunch of prototype beans that we and our customers have to define. It's so easy to forget to define this value ...)
          Hide
          Liam Knox added a comment -

          I think scope on the abstract should either throw an explicit exception or be supported.
          We now have an issue in production where parallel behaviour has disapeared due to a abstract bean refactor

          Show
          Liam Knox added a comment - I think scope on the abstract should either throw an explicit exception or be supported. We now have an issue in production where parallel behaviour has disapeared due to a abstract bean refactor
          Hide
          Juergen Hoeller added a comment -

          Good news: A child bean definition's scope attribute will finally be inherited from its parent bean definition by default now!

          There is a noteworthy side effect: BeanDefinition.getScope() will return null for such a child bean definition until it is being merged with its parent definition. This might potentially break some post-processors which do not expect the scope String to ever be null; should be easy enough to fix on their side though.

          Juergen

          Show
          Juergen Hoeller added a comment - Good news: A child bean definition's scope attribute will finally be inherited from its parent bean definition by default now! There is a noteworthy side effect: BeanDefinition.getScope() will return null for such a child bean definition until it is being merged with its parent definition. This might potentially break some post-processors which do not expect the scope String to ever be null; should be easy enough to fix on their side though. Juergen

            People

            • Assignee:
              Juergen Hoeller
              Reporter:
              John Newman
              Last updater:
              Trevor Marshall
            • Votes:
              8 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                4 years, 23 weeks, 1 day ago