aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet (JIRA)" <>
Subject [jira] [Assigned] (ARIES-1717) Untie Aries Blueprint Spring (extender) to specific Spring version
Date Tue, 16 Jan 2018 07:34:00 GMT


Guillaume Nodet reassigned ARIES-1717:

    Assignee: Guillaume Nodet

> Untie Aries Blueprint Spring (extender) to specific Spring version
> ------------------------------------------------------------------
>                 Key: ARIES-1717
>                 URL:
>             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
>         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
> 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

View raw message