Spring Framework
  1. Spring Framework
  2. SPR-6253

Allow to define autowired collections and array elements order

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 3.0 RC1
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      Spring defines a contract for autowiring arrays and type collections (3.4.5 Autowiring collaborators, 3.9.2 @Autowired and @Inject).

      However, there is a possible use-case that a user wants to define particular order for autowired collection/array. It looks obvious in the case of autowiring typed lists (the client may want to preserve particular order for the list elements) but the same idea may be spread easily to sets/maps/arrays.

      I suggest the following rules to be used during examining the order for two elements:

      • if both classes of compared object are marked by Ordered the one with lower value is considered to be less than another;
      • if class of one element is marked by Ordered and class of another is not marked by Ordered the former is considered to be less than the later;
      • if both classes of compared elements are not marked by Ordered but implement Comparable with consisting type parameter they are compared via Comparable#compareTo(Object);

      Please note that the rules above may be applied to all elements of autowired collection/array in order to define particular for them.

      Implementation

      That feature may be optional and defaults to perform ordering. It seems that most natural to allow to define it via additional method of @Autowired annotation.

      So, it can be implemented easily via minor AutowiredAnnotationBeanPostProcessor modification - the argument to be injected is just sorted if necessary.

      Attached archive contains either feature implementation (classes from 'org.springframework.beans.factory.annotation' package) or usage example (classes from 'com.spring.example' package and its subpackages).

        Issue Links

          Activity

          Hide
          Denis Zhdanov added a comment -

          Sorry, didn't define priority for the ticket (it is 'Major' by default). Suggest to change it to 'Minor'

          Show
          Denis Zhdanov added a comment - Sorry, didn't define priority for the ticket (it is 'Major' by default). Suggest to change it to 'Minor'
          Hide
          Denis Zhdanov added a comment -

          One more note - ticket text says about 'Ordered' annotation - should be replaced to 'Order' (the links are correct).

          Show
          Denis Zhdanov added a comment - One more note - ticket text says about 'Ordered' annotation - should be replaced to 'Order' (the links are correct).
          Hide
          mck added a comment -

          I haven't checked your patch, but i reckon the third approach should only work on SortedSet and SortedMap.
          If autowired can already work on SortedSet and SortedMap

          //for example code like
          @Autowired
          private SortedSet<?> set;

          wouldn't this already implement this feature?

          Show
          mck added a comment - I haven't checked your patch, but i reckon the third approach should only work on SortedSet and SortedMap. If autowired can already work on SortedSet and SortedMap // for example code like @Autowired private SortedSet<?> set; wouldn't this already implement this feature?
          Hide
          Denis Zhdanov added a comment -

          The point is to allow to define sorting rule via @Ordered. I.e. there is a possible situation that I have a number of different classes that, say, conform to the same interface and don't know anything about each other. I don't want to explicitly push that knowledge by introducing compareTo() to them. I want just configure fine-grained autowiring rules at the very similar way to standard Spring facilities.

          Show
          Denis Zhdanov added a comment - The point is to allow to define sorting rule via @Ordered. I.e. there is a possible situation that I have a number of different classes that, say, conform to the same interface and don't know anything about each other. I don't want to explicitly push that knowledge by introducing compareTo() to them. I want just configure fine-grained autowiring rules at the very similar way to standard Spring facilities.
          Hide
          mck added a comment -

          Yes i understand and value both points one and two (and your last comment). They certainly are a required addition to Spring imho and already have my vote.

          My questioning was solely around your third point:
          "if both classes of compared elements are not marked by Ordered but implement Comparable with consisting type parameter"

          I didn't understand the need for this because it already works in Spring.
          For example

          class AbcService implements Comparable<AbcService>{...}
          
          class MyClass{
              @Autowired
              SortedSet<AbcService> abcServices;
          }

          already works in Spring and does not need the code you've added in AutowiredElementsComparator.compare(...)

          But i see here you're actually talking about the possibility to blend @Order and Comparable in the one sorting process? This sounds a bit scary to me... would people be expecting Autowired Lists to be sorted by their natural order (since that is what SortedSet is used for), and how would this effect backward-compatibility? If it were to be done, so that "@Order fell back onto natural sorting", then i would expect that the sorting between two identical @Order values also fell back to the natural sorting if available (here this would mean changing AutowiredElementsComparator:47 to

          if (a1 != null && a1.value() != a2.value()) {
          Show
          mck added a comment - Yes i understand and value both points one and two (and your last comment). They certainly are a required addition to Spring imho and already have my vote. My questioning was solely around your third point: "if both classes of compared elements are not marked by Ordered but implement Comparable with consisting type parameter" I didn't understand the need for this because it already works in Spring. For example class AbcService implements Comparable<AbcService>{...} class MyClass{ @Autowired SortedSet<AbcService> abcServices; } already works in Spring and does not need the code you've added in AutowiredElementsComparator.compare(...) But i see here you're actually talking about the possibility to blend @Order and Comparable in the one sorting process? This sounds a bit scary to me... would people be expecting Autowired Lists to be sorted by their natural order (since that is what SortedSet is used for), and how would this effect backward-compatibility? If it were to be done, so that "@Order fell back onto natural sorting", then i would expect that the sorting between two identical @Order values also fell back to the natural sorting if available (here this would mean changing AutowiredElementsComparator:47 to if (a1 != null && a1.value() != a2.value()) {
          Hide
          Denis Zhdanov added a comment -

          Oh, I see your point now.

          My idea was to allow to define ordering during autowiring mixed collections, i.e. collections that consist from both @Ordered or non-@Ordered objects.

          Agreed that it looks more consistent to fall back to natural ordering in case of equal @Order-implied values.

          Unfortunately, it looks like Spring guys don't pay to much attention to this patch.

          Show
          Denis Zhdanov added a comment - Oh, I see your point now. My idea was to allow to define ordering during autowiring mixed collections, i.e. collections that consist from both @Ordered or non-@Ordered objects. Agreed that it looks more consistent to fall back to natural ordering in case of equal @Order-implied values. Unfortunately, it looks like Spring guys don't pay to much attention to this patch.
          Hide
          David Erickson added a comment -

          I would love to see this feature as well, I was a little disappointed it wasn't already implemented given everything else I can dream up already works

          Show
          David Erickson added a comment - I would love to see this feature as well, I was a little disappointed it wasn't already implemented given everything else I can dream up already works
          Hide
          Chris Beams added a comment -

          Duplicates SPR-5574. Please watch that issue to be notified of changes.

          Show
          Chris Beams added a comment - Duplicates SPR-5574 . Please watch that issue to be notified of changes.

            People

            • Assignee:
              Chris Beams
              Reporter:
              Denis Zhdanov
              Last updater:
              Trevor Marshall
            • Votes:
              8 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 41 weeks, 5 days ago

                Time Tracking

                Estimated:
                Original Estimate - 10d
                10d
                Remaining:
                Remaining Estimate - 10d
                10d
                Logged:
                Time Spent - Not Specified
                Not Specified