Improve Constructor Resolver Diagnostics [SPR-12543]

[spring-projects-issues]

Gary Russell opened SPR-12543 and commented

throw new BeanCreationException(mbd.getResourceDescription(), beanName,
		"Could not resolve matching constructor " +
		"(hint: specify index/type/name arguments for simple parameters to avoid type ambiguities)");

It would be helpful if the above exception (in ConstuctorResolver ) included the argument types in argToUse.

---

Affects: 4.1.3

Issue Links:

• Consistent resolution of factory method exceptions [SPR-13985] #18557 Consistent resolution of factory method exceptions

Referenced from: commits d55af2b

[spring-projects-issues]

Stéphane Nicoll commented

out of curiosity how did you manage to reach that exception?

[spring-projects-issues]

Gary Russell commented

Janne hit the problem in XD (https://gist.github.com/jvalkeal/cee35c9d0ddfe63fb25b). That turned out to be a class path problem, but I just thought it would be helpful to have included the types we were trying to wire in.

It's not entirely clear to me why it manifested itself this way; after further debugging Janne Valkealahti found the bean (a factory bean) had a field defined with a class that was not on the class path. So I don't know why he didn't get a simple ClassNotFoundException when trying to construct the factory bean.

[spring-projects-issues]

Stéphane Nicoll commented

Thanks Gary! - ping Juergen Hoeller

[spring-projects-issues]

Janne Valkealahti commented

When I was tracking the problem without first knowing it to be a classpath issue, ConstuctorResolver around line 188 is eating the exception which is not propagated to end-user unless trace is enabled.

catch (UnsatisfiedDependencyException ex) {
  if (this.beanFactory.logger.isTraceEnabled()) {
    this.beanFactory.logger.trace(
      "Ignoring constructor [" + candidate + "] of bean '" + beanName + "': " + ex);
}

Above catch had(if I remember location/line correctly):

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'ls.gateway': Unsatisfied dependency expressed through constructor argument with index 0 of type [java.lang.Class]: Could not convert constructor argument value of type [java.lang.String] to required type [java.lang.Class]: Failed to convert value of type 'java.lang.String' to required type 'java.lang.Class'; nested exception is java.lang.IllegalArgumentException: Cannot find class [org.springframework.batch.integration.x.RemoteFilePartitioner$Gateway]

Indeed it'd be nice to see this immediately without going so deep into core debugging.

[spring-projects-issues]

Juergen Hoeller commented

The discrepancy is with whether there are additional constructors - with fewer parameters, e.g. a default constructor - around. In such cases, we would run into the general BeanCreationException code path, not the preferable "throw the last UnsatisfiedDependencyException" one.

I've revised our algorithm to always handle recorded causes from previous resolution attempts right before we resort to BeanCreationException, consistently throwing the last UnsatisfiedDependencyException if possible.

Juergen