- 10 2月, 2011 1 次提交
-
-
由 Chris Beams 提交于
Revert changes to ParserContext, ReaderContext, and XmlReaderContext These changes cause cross-version incompatibilities at tooling time -- for instance, an STS version that ships with Spring 3.0.5 classloads the ParserContext defined in that version, whereas it classloads NamespaceHandlers and BeanDefinitionParsers (by default) from the user application classpath, which may be building against 3.1.0. If so, the changes introduced to these types in 3.1.0 are incompatible with expectations in the 3.0.5 world and cause all manner of problems. In this case, it was NoSuchMethodError due to the newly-added XmlReaderContext.getProblemReporter() method; also IncompatibleClassChangeError due to the introduction of the ComponentRegistrar interface on ParserContext. Each of these problems have been mitigated, though the solutions are not ideal. The method mentioned has been removed, and instead the problemReporter field is now accessed reflectively. ParserContext now no longer implements ComponentRegistrar, and rather a ComponentRegistrarAdapter class has been introduced that passes method calls through to a ParserContext delegate. Introduce AbstractSpecificationBeanDefinitionParser AbstractSpecificationBeanDefinitionParser has been introduced in order to improve the programming model for BeanDefinitionParsers that have been refactored to the new FeatureSpecification model. This new base class and it's template method implementation of parse/doParse ensure that common concerns like (1) adapting a ParserContext into a SpecificationContext, (2) setting source and source name on the specification, and (3) actually executing the specification are all managed by the base class. The subclass implementation of doParse need only actually parse XML, populate and return the FeatureSpecification object. This change removed the many duplicate 'createSpecificationContext' methods that had been lingering. Minor improvement to BeanDefinitionReaderUtils API Introduced new BeanDefinitionReaderUtils#registerWithGeneratedName variant that accepts BeanDefinition as opposed to AbstractBeanDefinition, as BeanDefinition is all that is actually necessary to satisfy the needs of the method implementation. The latter variant accepting AbstractBeanDefinition has been deprecated but remains intact and delegates to the new variant in order to maintain binary compatibility.
-
- 09 2月, 2011 1 次提交
-
-
由 Chris Beams 提交于
This change broke binary compatibility as evidenced by running the greenhouse test suite and finding that Spring Integration's AbstractConsumerEndpointParser.parseInternal fails with NoSuchMethodError when trying to invoke.
-
- 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
-