[
https://issues.apache.org/jira/browse/ARIES-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aede van der Weij updated ARIES-1717:
-------------------------------------
Description:
We want to reduce the usage of Spring and replace Spring DM in favor of Aries
Blueprint. The blueprint-spring and blueprint-spring-extender bundles could be
used to achieve this rather easily.
We're stuck with Spring 3.x version and this does not play well with the
earlier mention blueprint bundles. The following problems are encountered:
- when the temp blueprint configuration files are created from the Spring
beans, the xsd version is set to 4.2 (which are not present because we're using
a different version)
- when creating a Spring ParserContext
XmlBeanDefinitionReader.createReaderContext is called but this is protected in
Spring 3.x and results in NoSuchMethodError.
- when importing bean definitions XmlReaderContext.getEnvironment is called
(from BeansNamespaceHandler$BeanDefinitionReader) but this method does not
exists in Spring 3.x. In Spring 4.x this method is introduced and acts as a
shortcut by redirecting the call to the member variable reader. The call is
simply replaced with XmlReaderContext.getReader.getEnvironment
A patch is attached that solves these problems. For the xsd version a lookup is
executed and the version is resolved at run time. The other problem is solved
by creating a private inner class that extends XmlBeanDefinitionReader and
makes createReaderContext available that simply delegates the call to its super
class (XmlBeanDefinitionReader)
was:
We want to reduce the usage of Spring and replace Spring DM in favor of Aries
Blueprint. The blueprint-spring and blueprint-spring-extender bundles could be
used to achieve this rather easily.
We're stuck with Spring 3.x version and this does not play well with the
earlier mention blueprint bundles. The following problems are encountered:
- when the temp blueprint configuration files are created from the Spring
beans, the xsd version is set to 4.2 (which are not present because we're using
a different version)
- when creating a Spring ParserContext
XmlBeanDefinitionReader.createReaderContext is called but this is protected in
Spring 3.x and results in NoSuchMethodError.
A patch is attached that solves these problems. For the xsd version a lookup is
executed and the version is resolved at run time. The other problem is solved
by creating a private inner class that extends XmlBeanDefinitionReader and
makes createReaderContext available that simply delegates the call to its super
class (XmlBeanDefinitionReader)
> Untie Aries Blueprint Spring (extender) to specific Spring version
> ------------------------------------------------------------------
>
> Key: ARIES-1717
> URL: https://issues.apache.org/jira/browse/ARIES-1717
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
> Affects Versions: blueprint-spring-extender-0.1.0, blueprint-spring-0.3.0
> Reporter: Aede van der Weij
> Priority: Critical
> Attachments: aries-1717.patch
>
>
> We want to reduce the usage of Spring and replace Spring DM in favor of Aries
> Blueprint. The blueprint-spring and blueprint-spring-extender bundles could
> be used to achieve this rather easily.
> We're stuck with Spring 3.x version and this does not play well with the
> earlier mention blueprint bundles. The following problems are encountered:
> - when the temp blueprint configuration files are created from the Spring
> beans, the xsd version is set to 4.2 (which are not present because we're
> using a different version)
> - when creating a Spring ParserContext
> XmlBeanDefinitionReader.createReaderContext is called but this is protected
> in Spring 3.x and results in NoSuchMethodError.
> - when importing bean definitions XmlReaderContext.getEnvironment is called
> (from BeansNamespaceHandler$BeanDefinitionReader) but this method does not
> exists in Spring 3.x. In Spring 4.x this method is introduced and acts as a
> shortcut by redirecting the call to the member variable reader. The call is
> simply replaced with XmlReaderContext.getReader.getEnvironment
> A patch is attached that solves these problems. For the xsd version a lookup
> is executed and the version is resolved at run time. The other problem is
> solved by creating a private inner class that extends XmlBeanDefinitionReader
> and makes createReaderContext available that simply delegates the call to its
> super class (XmlBeanDefinitionReader)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
