- 17 2月, 2012 3 次提交
-
-
由 Chris Beams 提交于
Previously, a user could specify an empty array of resource locations to the @PropertySource annotation, which amounts to a meaningless no-op. ConfigurationClassParser now throws IllegalArgumentException upon encountering any such misconfiguration.
-
由 Chris Beams 提交于
Prior to this commit, specifying a named @PropertySource with multiple values would not work as expected. e.g.: @PropertySource( name = "ps", value = { "classpath:a.properties", "classpath:b.properties" }) In this scenario, the implementation would register a.properties with the name "ps", and subsequently register b.properties with the name "ps", overwriting the entry for a.properties. To fix this behavior, a CompositePropertySource type has been introduced which accepts a single name and a set of PropertySource objects to iterate over. ConfigurationClassParser's @PropertySource parsing routine has been updated to use this composite approach when necessary, i.e. when both an explicit name and more than one location have been specified. Note that if no explicit name is specified, the generated property source names are enough to distinguish the instances and avoid overwriting each other; this is why the composite wrapper is not used in these cases. Issue: SPR-9127
-
由 Juergen Hoeller 提交于
-
- 16 2月, 2012 3 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Chris Beams 提交于
Issue: SPR-9090
-
由 Chris Beams 提交于
-
- 15 2月, 2012 11 次提交
-
-
由 Chris Beams 提交于
Since the introduction of the AnnotationConfig(Web)ApplicationContext types in Spring 3.0, it has been possible to specify a custom bean name generation strategy via the #setBeanNameGenerator methods available on each of these classes. If specified, that BeanNameGenerator was delegated to the underlying AnnotatedBeanDefinitionReader and ClassPathBeanDefinitionScanner. This meant that any @Configuration classes registered or scanned directly from the application context, e.g. via #register or #scan methods would respect the custom name generation strategy as intended. However, for @Configuration classes picked up via @Import or implicitly registered due to being nested classes would not be aware of this strategy, and would rather fall back to a hard-coded default AnnotationBeanNameGenerator. This change ensures consistent application of custom BeanNameGenerator strategies in the following ways: - Introduction of AnnotationConfigUtils#CONFIGURATION_BEAN_NAME_GENERATOR singleton If a custom BeanNameGenerator is specified via #setBeanNameGenerator the AnnotationConfig* application contexts will, in addition to delegating this object to the underlying reader and scanner, register it as a singleton bean within the enclosing bean factory having the constant name mentioned above. ConfigurationClassPostProcessor now checks for the presence of this singleton, falling back to a default AnnotationBeanNameGenerator if not present. This singleton-based approach is necessary because it is otherwise impossible to parameterize CCPP, given that it is registered as a BeanDefinitionRegistryPostProcessor bean definition in AnnotationConfigUtils#registerAnnotationConfigProcessors - Introduction of ConfigurationClassPostProcessor#setBeanNameGenerator As detailed in the Javadoc for this new method, this allows for customizing the BeanNameGenerator via XML by dropping down to direct registration of CCPP as a <bean> instead of using <context:annotation-config> to enable @Configuration class processing. - Smarter defaulting for @ComponentScan#beanNameGenerator Previously, @ComponentScan's #beanNameGenerator attribute had a default value of AnnotationBeanNameGenerator. The value is now the BeanNameGenerator interface itself, indicating that the scanner dedicated to processing each @ComponentScan should fall back to an inherited generator, i.e. the one originally specified against the application context, or the original default provided by ConfigurationClassPostProcessor. This means that name generation strategies will be consistent with a single point of configuration, but that individual @ComponentScan declarations may still customize the strategy for the beans that are picked up by that particular scanning. Issue: SPR-9124
-
由 Chris Beams 提交于
Prior to this commit, and based on earlier changes supporting SPR-9023, ConfigurationClassBeanDefinitionReader employed a simplistic strategy for extracting the 'value' attribute (if any) from @Configuration in order to determine the bean name for imported and nested configuration classes. An example case follows: @Configuration("myConfig") public class AppConfig { ... } This approach is too simplistic however, given that it is possible in 'configuration lite' mode to specify a @Component-annotated class with @Bean methods, e.g. @Component("myConfig") public class AppConfig { @Bean public Foo foo() { ... } } In this case, it's the 'value' attribute of @Component, not @Configuration, that should be consulted for the bean name. Or indeed if it were any other stereotype annotation meta-annotated with @Component, the value attribute should respected. This kind of sophisticated discovery is exactly what AnnotationBeanNameGenerator was designed to do, and ConfigurationClassBeanDefinitionReader now uses it in favor of the custom approach described above. To enable this refactoring, nested and imported configuration classes are no longer registered as GenericBeanDefinition, but rather as AnnotatedGenericBeanDefinition given that AnnotationBeanNameGenerator falls back to a generic strategy unless the bean definition in question is assignable to AnnotatedBeanDefinition. A new constructor accepting AnnotationMetadata has been added to AnnotatedGenericBeanDefinition in order to support the ASM-based approach in use by configuration class processing. Javadoc has been updated for both AnnotatedGenericBeanDefinition and its now very similar cousin ScannedGenericBeanDefinition to make clear the semantics and intention of these two variants. Issue: SPR-9023
-
由 Chris Beams 提交于
Prior to this commit, an infinite recursion would occur if a @Configuration class were nested within its superclass, e.g. abstract class Parent { @Configuration static class Child extends Parent { ... } } This is because the processing of the nested class automatically checks the superclass hierarchy for certain reasons, and each superclass is in turn checked for nested @Configuration classes. The ConfigurationClassParser implementation now prevents this by keeping track of known superclasses, i.e. once a superclass has been processed, it is never again checked for nested classes, etc. Issue: SPR-8955
-
由 Chris Beams 提交于
-
由 Rossen Stoyanchev 提交于
Issues: SPR-8983
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
- 14 2月, 2012 3 次提交
-
-
由 Juergen Hoeller 提交于
Resource "contentLength()" implementations work with OSGi bundle resources and JBoss VFS resources (SPR-9118)
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
- 13 2月, 2012 7 次提交
-
-
由 Chris Beams 提交于
Prior to changes in commit 57851de8, AbstractResource#getFilename threw IllegalStateException unless overridden by a subclass. Following that change, this method now throws null instead, but ResourceTests#testAbstractResourceExceptions had not been updated to reflect, resulting in a false negative failure. This has now been fixed. Issue: SPR-9043
-
由 Chris Beams 提交于
Eclipse allows autoboxing on type inference; Sun javac does not. This means that variables assigned from calls to AnnotationAttributes#getNumber should consistently use object wrappers as opposed to number primitives. There was only one such instance anyway, and has now been updated accordingly.
-
由 Chris Beams 提交于
Prior to JDK 7, java.beans.Introspector registered indexed write methods irrespective of return type, for example either of the following methods were legal void setFoo(int i, Foo foo) Object setFoo(int i, Foo foo) This was considered a bug and disallowed starting with JDK 7, such that only the former signature is a candidate. Supporting non-void returning setter methods is exactly what ExtendedBeanInfo was designed to do, and prior to this commit, the implementation of ExtendedBeanInfo assumed this (somewhat surprising) behavior from the underlying Introspector, and because it worked out of the box, took no extra steps to recognize and register these methods. For this reason, non-void returning indexed write methods were not registered under JDK 7+, causing test failures in ExtendedBeanInfoTests. Now the implementation is careful to detect these methods without any assumption about Introspector behavior, such that they are registered in exactly the same fashion across JDK versions. Issue: SPR-9014
-
由 Chris Beams 提交于
Prior to this commit, ExtendedBeanInfo would add non-indexed write methods without consideration for the presence of indexed read/write methods, which is invalid per the JavaBeans spec and per the behavior of java.beans.Introspector. That is, a method with the signature void setFoo(Foo foo) Should never be registered as a write method if the following method signature is also present in the class void setFoo(int i, Foo foo) In most cases, this oversight caused no problems, but in certain situations where a bean actually contains such a mismatch of methods, "type mismatch" errors were thrown when ExtendedBeanInfo attempted the illegal addition against the underlying property descriptor. The implementation is now more careful about checking the parameter type of write methods -- if the property descriptor in question is an IndexedPropertyDescriptor, i.e. has an indexed write method, then any non-indexed write method candidate must have a single *array* parameter, which conforms to the spec and to Introspector behavior. Issue: SPR-8937
-
由 Chris Beams 提交于
ExtendedBeanInfo - Reduce log messages from warn to debug - Remove now-incorrect comment indicating underlying property descriptors are never modified (they actually are as of SPR-8806) ExtendedBeanInfoTests - Consolidate SPR-8949 tests - Eliminate compiler warnings Issue: SPR-8949, SPR-8806
-
由 Chris Beams 提交于
- Drop 'expectedType' parameter from #getClass and #getEnum methods and rely on compiler inference based on type of assigned variable, e.g. public @interface Example { Color color(); Class<? extends UserType> userType(); int order() default 0; } AnnotationAttributes example = AnnotationUtils.getAnnotationAttributes(Example.class, true, true); Color color = example.getEnum("color"); Class<? extends UserType> userType = example.getClass("userType"); or in cases where there is no variable assignment (and thus no inference possible), use explicit generic type, e.g. bean.setColor(example.<Color>getEnum("color")); - Rename #get{Int=>Number} and update return type from int to <N extends Number>, allowing invocations such as: int order = example.getNumber("order"); These changes reduce the overall number of methods exposed by AnnotationAttributes, while at the same time providing comprehensive access to all possible annotation attribute types -- that is, instead of requiring explicit #getInt, #getFloat, #getDouble methods, the single #getNumber method is capabable of handling them all, and without any casting required. And the obvious additional benefit is more concise invocation as no redundant 'expectedType' parameters are required.
-
由 Rossen Stoyanchev 提交于
Issues: SPR-9111
-
- 12 2月, 2012 9 次提交
-
-
由 jhoeller 提交于
SQL exception translation enhancements
-
由 jhoeller 提交于
Fixes for SimpleJdbcInsert [SPR-9006]
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
clarified Resource's "getFilename" method to consistently return null if resource type does not have a filename (SPR-9043)
-
由 Juergen Hoeller 提交于
-
- 11 2月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 10 2月, 2012 3 次提交
-
-
由 Chris Beams 提交于
Recent changes in ExtendedBeanInfo involve invoking ClassUtils#getMostSpecificMethod when determining JavaBeans get/set pairs; if Java security settings control disallow reflective access, this results in an AccessControlException. This change defends against this (comparatively rare) scenario by catching the exception and falling back to returning the method originally supplied by the user. This change was a result of noticing CallbacksSecurityTests failing following the ExtendedBeanInfo modifications mentioned above Issue: SPR-8949
-
由 Thomas Risberg 提交于
The username is usually not null, but it could be for some embedded databases. Always setting generatedKeysColumnNameArraySupported to false when getGeneratedKeysSupported is false, since it can't be supported without having generated keys supported. This change only affects logging messages. Issue: SPR-9006
-
由 Thomas Risberg 提交于
Adding a static CustomSQLExceptionTranslatorRegistry and a CustomSQLExceptionTranslatorRegistrar that can be used to register custom SQLExceptionTranslator implementations for specific databases from any application context. This can be used in application contexts like this: <bean class="org.springframework.jdbc.support.CustomSQLExceptionTranslatorRegistrar"> <property name="sqlExceptionTranslators"> <map> <entry key="H2"> <bean class="com.yourcompany.data.CustomSqlExceptionTranslator"/> </entry> </map> </property> </bean> Issue: SPR-7675
-