Ordered list access for BeanFactory.getBeanProvider(), superseding ObjectProvider<List> [SPR-17272]

[spring-projects-issues]

Sébastien Deleuze opened SPR-17272 and commented

Unlike DependencyObjectProvider which seems to support this use case, the ObjectProvider implementation returned by DefaultListableBeanFactory#getBeanProvider(ResolvableType) does not seems to support List<Foo> correctly.

This test is green:

@Test
public void registerBeanAndGetBeanProvider() {
     GenericApplicationContext context = new GenericApplicationContext();
     context.registerBean(ViewResolver.class, () -> new MustacheViewResolver());
     assertNotNull(context.getDefaultListableBeanFactory().getBeanProvider(ResolvableType.forClass(ViewResolver.class)).getIfAvailable());
}

This test is red:

@Test
public void registerBeanAndGetBeanProviderList() {
     GenericApplicationContext context = new GenericApplicationContext();
     context.registerBean(ViewResolver.class, () -> new MustacheViewResolver());
     assertNotNull(context.getDefaultListableBeanFactory().getBeanProvider(ResolvableType.forClassWithGenerics(List.class, ViewResolver.class)).getIfAvailable());
}

This difference of behavior prevents Kofu configuration and Dave Syer FuncApplication to instantiate WebFluxAutoConfiguration.WebFluxConfig in a functional way and get view resolution support.

---

Affects: 5.1 RC3

Issue Links:

• ObjectProvider iterable/stream access for "beans of type" resolution in @Bean methods [SPR-11419] #16046 ObjectProvider iterable/stream access for "beans of type" resolution in @Bean methods
• Autowiring inconsistency: @Qualifier works with HashMap but not with Map [SPR-17197] #21731 Autowiring inconsistency: @Qualifier works with HashMap but not with Map

Referenced from: commits 65c8fa4, 41d4cb5, 7562761

0 votes, 8 watchers

[spring-projects-issues]

Juergen Hoeller commented

As per an initial analysis, this is intentional since programmatic configuration means to avoid the semantic overload of List<X> or Map<String, X> indicating a single bean of that particular collection type versus several X beans aggregated into a List/Map. Preferably, ObjectProvider stream access should be used for multiple elements, declaring the affected provider as just ObjectProvider<ViewResolver> and then calling .stream() on it (or simply iterating over it since the provider is an Iterable as well). And if a local List is really needed, the recommended solution is .stream().collect(Collectors.toList()).

[spring-projects-issues]

Andy Wilkinson commented

It's taken me a little while to get my head around this, but I like that ObjectProvider<ViewResolver> can be used to request something that can provide ViewResolver beans and then ObjectProvider<List<ViewResolver>> potentially being specifically for providing List<ViewResolver> beans. Removing the ambiguity around what injecting List<ViewResolver> means (a list of ViewResolver beans or a List<ViewResolver> bean) is compelling.

Having said that, the current implementation and javadoc appear to be at odds with this goal. The javadoc of stream() makes no mention of providing multiple beans and suggests that you'll only ever get one or none. There's also no discussion of ordering which is important when handling multiple beans. This leaves code that wants to work with multiple beans to use ObjectProvider but rely upon actually being given a DependencyObjectProvider to get the behaviour that's required. This will have a detrimental effect on the readability of the code and require a fairly deep understanding of Framework's internals to not be mislead by the documentation on ObjectProvider.

[spring-projects-issues]

Dave Syer commented

I wonder if anyone ever actually uses the default stream() implementation? I would think it is misleading and wrong since it doesn't really stick to the implied contract. The fact that the contract is not very tight (because of the javadoc?) is probably the issue here, and since this method is new in 5.1, this is a good time to tighten it up (before 5.1.0). I suggest that we change the javadoc and remove the default implementation of stream().

[spring-projects-issues]

Juergen Hoeller commented

Point taken, I'll revise the javadoc as part of this ticket. It currently documents the default implementation in the ObjectProvider interface itself which isn't really that useful since DependencyObjectProvider as well as getBeanProvider results override it with actual multi-element behavior.

Also, good point about ordering... There is currently no sorting of elements (like for a Set<ViewResolver>) for the lazily resolved stream, so it's effectively bean registration order. Maybe we should add an explicit toList() method on ObjectProvider itself with the usual @Order support.

[spring-projects-issues]

Juergen Hoeller commented

The idea behind the default implementation of stream() was simply to provide backwards compatibility with custom ObjectProvider implementations. That said, I agree the semantics are really not useful. I'll rather change it to a default implementation that throws an UnsupportedOperationException.

[spring-projects-issues]

Andy Wilkinson commented

Thanks. Some discussion of @Primary would be good too. Could the contract specify what stream() and iterator() will produce when there are multiple candidates and one is primary? Is it all candidates including the primary one, or just the primary? If you just consider the current contract in isolation, I don't think it's clear which you should expect.

[spring-projects-issues]

Juergen Hoeller commented

It'll be all matching instances, including the primary one. getIfAvailable() will give you the primary in this case, as before.

[spring-projects-issues]

Juergen Hoeller commented

BTW thanks for all the timely feedback here! This is the most important core container addition in 5.1, so we'd better take these extra cycles to refine it and document it based on common use cases...

[spring-projects-issues]

Juergen Hoeller commented

I've added an ObjectProvider.toList() method now, providing the same ordering guarantees as a reflective injection point for an aggregated List, and fully resolving all object instances at the time of the call. Stream access and iteration over an ObjectProvider has consistent lazy resolution of target instances now, between both kinds of provider types, following bean registration order.

[spring-projects-issues]

Phil Webb commented

I know I'm coming late to the party on this one, but what if we had two distinct interfaces for "single" vs "multiple" use? It feels like getObject, getIfAvailable and getIfUnique are useful if your intent is that there is a single useful bean, where as iterator and stream are only useful if your injecting into something that supports multiple beans.

Put another way, the user of the ObjectProvider needs to make the decision about if they support a single or multiple means. Having two different interfaces would make that intent much clearer. Perhaps ObjectProvider vs ObjectsProvider?

[spring-projects-issues]

Juergen Hoeller commented

That's by design: It's a single handle that allows for any kind of reasoning here. For a multi-element match, getObject may identify the primary object, potentially next to some reasoning about all available instances. Also, for a single target element found, stream access may be useful to filter it according to some criteria and see whether something remains, or to be prepared to encounter several instances at some later point but filter according to certain criteria that the current single target matches. All in all, this can be seen as a more flexible variant of qualifier matching and primary/uniqueness identification, all of which potentially operate on multiple elements but narrow to a single element based on standard criteria.

If there is really only a single element to reason about, I wouldn't use ObjectProvider to begin with. A plain ObjectFactory declaration or an @Lazy declaration gets you a long way if all you need is lazy retrieval. The availability/uniqueness business is an advanced use case already.

[spring-projects-issues]

Phil Webb commented

Perhaps we just have some fairly unique requirements in Spring Boot. We've quite often used ObjectProvider when we support zero or one (alone or primary) instance. Unfortunately ObjectProvider doesn't support that.

...or to be prepared to encounter several instances at some later point but filter according to certain criteria that the current single target matches

The decision about supporting multiple beans has to be taken when the ObjectProvider is used. I think it would be sensible that the multi-object variant would still support a stream of a single element if there happens to be just one.

I guess I'm kind of seeing usage patterns in Boot that kind of mirror Mono vs Flux. We need to either support 0..1 beans or 0..N.

[spring-projects-issues]

Juergen Hoeller commented

Another way of seeing it: ObjectProvider is a pre-typed handle for flexible bean retrieval, along the lines of the retrieval methods on ListableBeanFactory but avoiding to re-specify the type for several invocations... and avoiding to deal with bean names.

And since it exists next to ObjectFactory and JSR-330's Provider interface, I'd rather keep it as a single unified type for less conceptual surface. This also allows for a simple pair of lookup methods on BeanFactory: getBeanProvider(Class) and getBeanProvider(ResolvableType).

[spring-projects-issues]

Sébastien Deleuze commented

Phil Webb Not sure if that's relevant, but we tend to differentiate Mono versus Flux mainly for return types, for incoming parameter we tend to use them as Publisher data provider regardless the cardinality, and the usage I have seen in Boot is more as input parameter.

[spring-projects-issues]

Phil Webb commented

Ignore me, I see that methods like getIfUnique are in the 5.0 version which already sends a strong signal that ObjectProvider may represent multiple items.