[jira] [Commented] (ARIES-1717) Untie Aries Blueprint Spring (extender) to specific Spring version

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARIES-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326837#comment-16326837 ] 

ASF subversion and git services commented on ARIES-1717:
--------------------------------------------------------

Commit 1821218 from [~gnt] in branch 'aries/trunk'
[ https://svn.apache.org/r1821218 ]

[ARIES-1717] Untie Aries Blueprint Spring (extender) to specific Spring version

> 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
>            Assignee: Guillaume Nodet
>            Priority: Critical
>             Fix For: blueprint-spring-0.6.0, blueprint-spring-extender-0.4.0
>
>         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
(v7.6.3#76005)