Autowiring of types narrows with generics does not work [SPR-11004]

[spring-projects-issues]

nebhale opened SPR-11004 and commented

Note that this applies to the current 4.0 snapshots, not the actual RC1 release.

Currently autowiring a bean of a type that could have a generic declaration but doesn't (e.g. List instead of List<String>) does not work when that bean should be autowired to a type that has the generic declaration (e.g. List<String>). And example is that the following wiring would not work:

@Bean
List list() {
  return new ArrayList();
}

@Bean
Object listConsumer(List<String> list) {
  return list;
}

This is useful in cases where a framework (saw spring-data-jpa) automatically creates a type (say PagedResourcesAssembler) that could be generified, but isn't. Then a consumer attempts to autowire that type, but with the generics (to quiet the compiler) and cannot get a wiring.

I've attached a test case that replicates the issue. Simply run mvm clean package && java -jar target/test.jar.

---

Affects: 4.0 RC1

Reference URL: f29092d#commitcomment-4368780

Attachments:

• test.zip (1.63 kB)
• test-2.zip (1.99 kB)

Issue Links:

• Generic autowiring should support wiring of components with unresolved type variables [SPR-10993] #15621 Generic autowiring should support wiring of components with unresolved type variables
• NPE in ResolvableType.hasUnresolvableGenerics [SPR-11034] #15662 NPE in ResolvableType.hasUnresolvableGenerics
• DATACMNS-388 Improve generics declaration in HateoasAwareSpringDataWebConfiguration

[spring-projects-issues]

Juergen Hoeller commented

This is covered by the fix for #15621 now, although it is actually slightly different: There it was about unresolved type variables in the target class itself whereas it is about a raw target type in this case. Anyway, it's basically covered by the same change, just with a slightly extended detection check.

[spring-projects-issues]

nebhale commented

I just checked this against the latest set of snapshots (about 10 hours after the fix was committed) including spring-core-4.0.0.BUILD-20131026.032844-327. I don't believe that this issue has yet been fixed based on the attached sample application.

[spring-projects-issues]

Juergen Hoeller commented

Ben, did that piece of code actually work before? It fails because the List<String> argument is considered a request for finding all beans of type String... and I'm pretty sure it would have done that before as well.

So if I'm not missing something here, this is actually a separate issue: @Autowired's handling of List and Map is a bit special, and we currently have no solution in place that allows for specific searches for beans that are of type List/Map themselves. I might experiment with that a bit though.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

FYI, in the follow-up comments to #15662, we found a regression in the last iteration. Please re-test once this is in master (which it will be in a few minutes).

The general scenario above should work fine then, even if the concrete List scenario won't work (as discussed above).

Juergen

[spring-projects-issues]

nebhale commented

You're absolutely right about the List example; I should have known better. I've attached a more accurate example as test-2.zip above and it still appears not to work against SPR-PUB-416.

Looking more deeply into my issue (it was around the HateoasAwareSpringDataWebConfiguration) a better representation looks like:

@Bean
GenericType<Object> producer() {
  return new GenericType<Object>();
}

@Bean
Object consumer(GenericType<String> genericType) {
  return genericType;
}

I'll be honest and say that I have a lot of trouble reasoning around this bit of generics, but my instinct is that this (and the declaration in HateoasAwareSpringDataWebConfiguration shouldn't actually work. Should the producer declaration actually be for GenericType<? extends Object> instead?

[spring-projects-issues]

Juergen Hoeller commented

Indeed, that shouldn't work: It would have to be GenericType<?> (or <? extends Object> ) instead.

That test does pass for a GenericType/GenericType<?> returning scenario for me now, against my local state (with no noteworthy changes since build 416).

Juergen

[spring-projects-issues]

nebhale commented

Agreed. I'll talk with Oliver about getting a fix to the Spring Data code. Thanks for your help.

[spring-projects-issues]

Oliver Drotbohm commented

I've filed and fixed DATACMNS-388 for the upcoming Codd M1 and the 1.6.x bugfix branch.