matchingBeans After getting the instance through the method, can we remove the filtering behavior of getting instance according to beanname

Comment From: pivotal-issuemaster

@huifer Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

Comment From: pivotal-issuemaster

@huifer Thank you for signing the Contributor License Agreement!

Comment From: quaff

I think your change breaks some behaviors at first glance, beans could be resolved later.

Comment From: huifer

It has been executed in findautowirecandidates descriptor.resolveCandidate And value is why the object needs to get the beanobject by name after getting the map

Comment From: sbrannen

Thanks for PR.

Unfortunately, the proposal changes the order in which the orderedPostProcessors and nonOrderedPostProcessors are instantiated which constitutes a breaking change.

In light of that, I am closing this PR.

Comment From: huifer

Can you explain why the loading order is disordered? My operation is only to get the name list ahead of time. Is there any specific example to illustrate @sbrannen

Comment From: ttddyy

Hi @huifer

I just looked at your change.

In PostProcessoreRegistrationDelegate, the loop you are in is to instantiate priority ordered BeanFactoryPostProcessor(BFPP) and at the same time gathering bean names for other BFPPs. You cannot simply instantiate(beanFactory.getBean(...)) other BFPP beans there because it will ignore ordering of creating PriorityOrdered, Ordered, and non-ordered BFPP beans.

For example, it will break the bean creation contract mentioned in PriorityOrdered javadoc:

  • Note: {@code PriorityOrdered} post-processor beans are initialized in
  • a special phase, ahead of other post-processor beans. This subtly
  • affects their autowiring behavior: they will only be autowired against
  • beans which do not require eager initialization for type matching.

Comment From: huifer

Hi @huifer

I just looked at your change.

In PostProcessoreRegistrationDelegate, the loop you are in is to instantiate priority ordered BeanFactoryPostProcessor(BFPP) and at the same time gathering bean names for other BFPPs. You cannot simply instantiate(beanFactory.getBean(...)) other BFPP beans there because it will ignore ordering of creating PriorityOrdered, Ordered, and non-ordered BFPP beans.

For example, it will break the bean creation contract mentioned in PriorityOrdered javadoc:

  • Note: {@code PriorityOrdered} post-processor beans are initialized in
  • a special phase, ahead of other post-processor beans. This subtly
  • affects their autowiring behavior: they will only be autowired against
  • beans which do not require eager initialization for type matching.

I looked for the link of getBean method, but I didn't find the processing related to ordered, If you can, can you tell me where the ordered interface is used in the getBean method