Improvement to ConstructorResolver [SPR-5522]

[spring-projects-issues]

Yan Pujante opened SPR-5522 and commented

When an exception is thrown in ClassConstructor it bubles up the chain and is getting caught in a different class thus reporting the wrong bean being causing the problem. Here is how I 'fixed' it for now to see the real bean causing the problem:

// line 165+
// Take specified constructors, if any.
// #YP modified
// Constructor[] candidates =
// (chosenCtors != null ? chosenCtors : mbd.getBeanClass().getDeclaredConstructors());
Constructor[] candidates;
try
{
candidates = (chosenCtors != null ? chosenCtors : mbd.getBeanClass().getDeclaredConstructors());
}
catch(NoClassDefFoundError e)
{
throw new RuntimeException("NoClassDefFoundError for bean " + beanName +
" while getting declared constructors of class " +
mbd.getBeanClassName() + " using class loader " +
mbd.getBeanClass().getClassLoader(), e);
}

It should be wrapped in an exception of some sort with a clear message showing which bean is causing the issue. It is even more problematic in OSGi where this kind of issue happens all the time.

---

Affects: 2.5.6

Referenced from: commits 092de01

[spring-projects-issues]

Juergen Hoeller commented

Good point... In complex ClassLoader scenarios, this may fail quite often at first try, and we should deliver a descriptive exception in such a case. Addressed in 3.0 M2.

Juergen