NPE in ResolvableType.hasUnresolvableGenerics [SPR-11034]

[spring-projects-issues]

Artem Bilan opened SPR-11034 and commented

Now Spring Data tests works, but we got another issue:

Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private org.springframework.integration.file.remote.session.SessionFactory org.springframework.integration.sftp.outbound.SftpServerOutboundTests.sessionFactory; nested exception is java.lang.NullPointerException
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:505)
at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:87)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288)
... 45 more
Caused by: java.lang.NullPointerException
at org.springframework.core.ResolvableType.hasUnresolvableGenerics(ResolvableType.java:368)
at org.springframework.beans.factory.support.GenericTypeAwareAutowireCandidateResolver.checkGenericTypeMatch(GenericTypeAwareAutowireCandidateResolver.java:103)

In this case we ingect to the test class a mock of our generic interface.
The GenericTypeAwareAutowireCandidateResolver#checkGenericTypeMatch gets targetType for this bean from ResolvableType.forMethodReturnType(rbd.getResolvedFactoryMethod()) as a value:

targetType = {org.springframework.core.ResolvableType@2680}"?"
type = {com.sun.proxy.$Proxy11@2690}"T"
typeProvider = {org.springframework.core.SerializableTypeWrapper$MethodParameterTypeProvider@2691}
variableResolver = {org.springframework.core.ResolvableType$DefaultVariableResolver@2692}
isResolved = true
resolved = null
componentType = null

and further #checkGenericTypeMatch calls targetType.hasUnresolvableGenerics(), who ends up with NPE after resolve(), which, in turn, does fallback to null, because it is resolved and doesn't have a value for resolved property.
Unfortunately, I can't say which solution should right: do null check, or change something in the ResolvableType...

So, I reopen an issue, because the solution doesn't cover all cases

---

Affects: 4.0 RC1

Issue Links:

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

0 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

A not-null check is appropriate there. Pushed to master now.

Juergen

[spring-projects-issues]

Artem Bilan commented

Thanks, Juergen!

But actualy it doesn't help.
The interface:

package org.springframework.integration.file.remote.session;

public interface SessionFactory<F> {

	Session<F> getSession();
}

Config:

<bean id="ftpSessionFactory" class="org.mockito.Mockito" factory-method="mock">
	<constructor-arg value="org.springframework.integration.file.remote.session.SessionFactory" />
</bean>

Test class:

@ContextConfiguration
@RunWith(SpringJUnit4ClassRunner.class)
public class SftpServerOutboundTests {

	@SuppressWarnings("rawtypes")
	@Autowired
	private SessionFactory sessionFactory;
....
}

The result:

Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private org.springframework.integration.file.remote.session.SessionFactory org.springframework.integration.sftp.outbound.SftpServerOutboundTests.sessionFactory; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.integration.file.remote.session.SessionFactory] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:508)
	at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:87)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:289)
	... 45 more
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.integration.file.remote.session.SessionFactory] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoSuchBeanDefinitionException(DefaultListableBeanFactory.java:1065)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:925)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:820)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:480)
	... 47 more

Sorry, but what is wrong?
Neither SessionFactory<?>, nor @Qualifier("ftpSessionFactory") help.

[spring-projects-issues]

Gary Russell commented

Just to clarify...

@ContextConfiguration
@RunWith(SpringJUnit4ClassRunner.class)
public class SftpServerOutboundTests {

	@Autowired
	private SessionFactory<?> sessionFactory;
....
}

worked with 4.0.0.M3; we had to remove the <?> when switching to the snapshot last week.

[spring-projects-issues]

Juergen Hoeller commented

Hmm, in this case the problem won't be in hasUnresolvableGenerics but rather in the factory method introspection part. I can at least partially reproduce this locally; looking into it...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I found two issues in the present code, one of them a regression in the last iteration. Fixed now, with all tests passing (including ones for the <?> scenario and the @Autowired + mock scenario). To be pushed to master in a few minutes; I hope this finally fixes all the issues in your scenario.

Juergen

[spring-projects-issues]

Artem Bilan commented

So, for our scenario this works now:

@Autowired
private SessionFactory sessionFactory;

but this SessionFactory<?> or this SessionFactory<SftpFileInfo>(the original code on SPR 3.1) doesn't.

Is it OK, or is there still some regression?
Does it mean that we now can't inject objects with the same type, but with different generics?

Thanks

[spring-projects-issues]

Juergen Hoeller commented

All of those scenarios should work now. I've just played around with variants of the unit tests here (see testGenericsBasedFieldInjectionWithSimpleMatchAndMock in AutowiredAnnotationBeanPostProcessorTests), and they all pass. This is against my local state but there are no significant changes since build 416.

So I'm afraid there's something special about your scenario that we're not catching yet. Please double-check that you're running against a recent enough build, but then it's really up for debugging... Let me know if you find anything; I can look into it tonight if necessary. There are still 3 days to go until RC1 :-)

Juergen

[spring-projects-issues]

Artem Bilan commented

Well, here is a test case on the latest SPR master: https://gist.github.com/artembilan/7180242
And the result is:

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.test.context.Spr11034Tests$Repository] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoSuchBeanDefinitionException(DefaultListableBeanFactory.java:1065)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:925)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:820)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:480)

Without generics (<?>) it works.

Out off topic: is there somewhere instructions how to build and debug SPR from IDEA? Now I have an issue about aspectj dependency. But from Gradle everything works good.

Thanks

[spring-projects-issues]

Juergen Hoeller commented

Artem, that test fails for me locally as well. Interestingly, an analogous test in our regular unit test suite - even a variant of it that points to Mockito directly, like yours - doesn't fail. I'm currently investigating where the difference comes from.

As for IDEA, that's a bit improvised at the moment. Personally, I'm using a few local modifications to the generated IDEA setup. And I'm usually not building the entire project in IDEA; I'm using a command line side-by-side and always verify via Gradle.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Got it: It's the use of XML which produces TypedStringValue wrappers for String arguments; so it's not the generic type matching that fails but the new version of our generic factory method resolution algorithm. I've added a TypedStringValue check there, now it all passes... Pushed to master already. Might be all sorted out now :-)

Juergen

[spring-projects-issues]

Artem Bilan commented

Juergen, thanks!

Now that tests case work.

With latest change we caught several ClassNotFoundException on our test configs, where there are really no such classes.

There is left one regression case (I hope :)) - inner classes as beans' constructor values.
Returning to my test-case, this works:

<bean id="repository" class="org.mockito.Mockito" factory-method="mock">
	<constructor-arg value="org.springframework.test.context.Spr11034Tests$Repository" />
</bean>

But this doesn't:

<bean id="repository" class="org.mockito.Mockito" factory-method="mock">
	<constructor-arg value="org.springframework.test.context.Spr11034Tests.Repository" />
</bean>

We end with ClassNotFoundException on at org.springframework.beans.factory.support.AutowireUtils.resolveReturnTypeForFactoryMethod(AutowireUtils.java:257).
Of course, I prefere to use it with $, but we have in Spring Integration many cases with .. And I think not only we have something similar.
From other side why don't use ClassUtils.forName(className, classLoader) in the AutowireUtils#resolveReturnTypeForFactoryMethod instead of just classLoader.loadClass(className)?
It solves the issue. And I tested it for entire Spring project.

WDYT?

[spring-projects-issues]

Juergen Hoeller commented

Good point about ClassUtils.forName; after all, we're using that in all other such places in the core factory as well.

As for the ClassNotFoundExceptions, that's actually a bug in its own right: The factory needs to be lenient towards non-working bean definitions when searching for type matches, not least of it all for 'optional' bean definitions that might not actually be used in the current deployment scenario. As a consequence, the factory is just logging those exceptions now.

Pushed to master already. Let me know if you find more issues. Thanks a lot BTW; this comes just in time for 4.0 RC1!

Juergen

[spring-projects-issues]

Artem Bilan commented

Thanks, Juergen!

Now everything works fine, even after restoring previous state of our tests. I mean we have the same results with SRP-4.0.0 as they were with 3.1.x and 3.2.x

Artem