- 05 9月, 2012 1 次提交
-
-
由 Juergen Hoeller 提交于
added Field context variant to TypeConverter interface in beans module; @Value injection works in combination with formatting rules such as @DateTimeFormat Issue: SPR-9637
-
- 31 1月, 2012 1 次提交
-
-
由 Chris Beams 提交于
This renaming more intuitively expresses the relationship between subprojects and the JAR artifacts they produce. Tracking history across these renames is possible, but it requires use of the --follow flag to `git log`, for example $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history up until the renaming event, where $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history for all changes to the file, before and after the renaming. See http://chrisbeams.com/git-diff-across-renamed-directories
-
- 27 9月, 2011 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
[SPR-8178] @Ignore-ing testPrintNull() until it is determined why changes to GenericConversionService broke this test.
-
- 14 6月, 2011 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 25 5月, 2011 1 次提交
-
-
由 Keith Donald 提交于
-
- 10 2月, 2011 1 次提交
-
-
由 Juergen Hoeller 提交于
removed ConversionService/TypeConverter convenience methods in order to restore 3.0's SPI (for backwards compatibility with implementers)
-
- 08 2月, 2011 1 次提交
-
-
由 Chris Beams 提交于
Introduce FeatureSpecification interface and implementations FeatureSpecification objects decouple the configuration of spring container features from the concern of parsing XML namespaces, allowing for reuse in code-based configuration (see @Feature* annotations below). * ComponentScanSpec * TxAnnotationDriven * MvcAnnotationDriven * MvcDefaultServletHandler * MvcResources * MvcViewControllers Refactor associated BeanDefinitionParsers to delegate to new impls above The following BeanDefinitionParser implementations now deal only with the concern of XML parsing. Validation is handled by their corresponding FeatureSpecification object. Bean definition creation and registration is handled by their corresponding FeatureSpecificationExecutor type. * ComponentScanBeanDefinitionParser * AnnotationDrivenBeanDefinitionParser (tx) * AnnotationDrivenBeanDefinitionParser (mvc) * DefaultServletHandlerBeanDefinitionParser * ResourcesBeanDefinitionParser * ViewControllerBeanDefinitionParser Update AopNamespaceUtils to decouple from XML (DOM API) Methods necessary for executing TxAnnotationDriven specification (and eventually, the AspectJAutoProxy specification) have been added that accept boolean arguments for whether to proxy target classes and whether to expose the proxy via threadlocal. Methods that accepted and introspected DOM Element objects still exist but have been deprecated. Introduce @FeatureConfiguration classes and @Feature methods Allow for creation and configuration of FeatureSpecification objects at the user level. A companion for @Configuration classes allowing for completely code-driven configuration of the Spring container. See changes in ConfigurationClassPostProcessor for implementation details. See Feature*Tests for usage examples. FeatureTestSuite in .integration-tests is a JUnit test suite designed to aggregate all BDP and Feature* related tests for a convenient way to confirm that Feature-related changes don't break anything. Uncomment this test and execute from Eclipse / IDEA. Due to classpath issues, this cannot be compiled by Ant/Ivy at the command line. Introduce @FeatureAnnotation meta-annotation and @ComponentScan impl @FeatureAnnotation provides an alternate mechanism for creating and executing FeatureSpecification objects. See @ComponentScan and its corresponding ComponentScanAnnotationParser implementation for details. See ComponentScanAnnotationIntegrationTests for usage examples Introduce Default[Formatting]ConversionService implementations Allows for convenient instantiation of ConversionService objects containing defaults appropriate for most environments. Replaces similar support originally in ConversionServiceFactory (which is now deprecated). This change was justified by the need to avoid use of FactoryBeans in @Configuration classes (such as FormattingConversionServiceFactoryBean). It is strongly preferred that users simply instantiate and configure the objects that underlie our FactoryBeans. In the case of the ConversionService types, the easiest way to do this is to create Default* subtypes. This also follows convention with the rest of the framework. Minor updates to util classes All in service of changes above. See diffs for self-explanatory details. * BeanUtils * ObjectUtils * ReflectionUtils
-
- 07 1月, 2011 1 次提交
-
-
由 Keith Donald 提交于
-
- 13 7月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 09 6月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 08 6月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 18 4月, 2010 1 次提交
-
-
由 Keith Donald 提交于
-
- 16 12月, 2009 1 次提交
-
-
由 Keith Donald 提交于
-
- 15 12月, 2009 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 08 12月, 2009 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 27 11月, 2009 1 次提交
-
-
由 Juergen Hoeller 提交于
FormatterRegistry extends ConverterRegistry now; FormattingConversionService extends GenericConversionService
-
- 14 11月, 2009 1 次提交
-
-
由 Keith Donald 提交于
-
- 12 11月, 2009 2 次提交
-
-
由 Keith Donald 提交于
-
由 Keith Donald 提交于
-
- 10 11月, 2009 1 次提交
-
-
由 Keith Donald 提交于
-
- 05 11月, 2009 4 次提交
-
-
由 Keith Donald 提交于
Renamed org.springframework.ui.format package to simply org.springframework.format package; 'ui' is not adding any value - it makes the package name longer and also discourages use of formatters outside in other "non ui" environments where localized formatting of field values is needed.
-
由 Keith Donald 提交于
-
由 Keith Donald 提交于
-
由 Keith Donald 提交于
-
- 04 11月, 2009 1 次提交
-
-
由 Keith Donald 提交于
-
- 31 10月, 2009 1 次提交
-
-
由 Keith Donald 提交于
ui.format system refining from RC1 feedback: Support for one format annotation applying to multiple field types, Printer/Parser building blocks for more flexibility, full Joda time formatting support, FormattingService as a service entry-point for clients to use
-