spring-framework

Spring Framework

Chris Beams 53bf88ebaa Further compensation for STS version mismatch Current STS version of Spring (3.0.5) does not contain the BeanUtils.instantiateClass(Class<?>, Class<T>) signature that was added in 3.1.0, therefore NoSuchMethodErrors are being thrown when STS classloads and delegates to 3.1.0 NamespaceHandler and BeanDefinitionParser implementations on the user project classpath. In this case, it's AbstractSpecificationBeanDefinitionParser doing the calling to the unknown new method. In this specific example, reverting back to the old single-arg signature is actually not a problem, because it does accept Class<T> and returns an instance of type T, which was the desired behavior in the first place. The newer signature remains in order to accommodate callers who do not know the generic type of the Class to be instantiated (i.e. Class<?>), but do know the type that it should be assignable to -- this becomes the second argument Class<T>, and an instance of type T is returned (if indeed it is assignable to the specified type; otherwise IllegalArgumentException. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@3992 50f2f4bb-b051-0410-bef5-90022cba6387		15 years ago
..
.settings	Merge 3.1.0 development branch into trunk	15 years ago
src	Further compensation for STS version mismatch	15 years ago
.classpath	moved cache abstraction from context.support to context	15 years ago
.project	SPR-6158: Initial implementation and tests for @ImportXml	16 years ago
.springBeans	Introduce FeatureSpecification support	15 years ago
build.xml	+ upgrade to AspectJ 1.6.8	16 years ago
context.iml	moved cache abstraction from context.support to context	15 years ago
ivy.xml	moved cache abstraction from context.support to context	15 years ago
pom.xml	Sync pom.xml deps with ivy.xml changes since 3.0.5	15 years ago
template.mf	moved cache abstraction from context.support to context	15 years ago