Community
Participate
Working Groups
Build Identifier: 1.0.0.M1 I would like to use Eclipse Gemini in order to support blueprint XML similar to the following, which contains a custom scope: <?xml version="1.0"?> <blueprint xmlns:test="http://test.org" xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"> <bean id="fooService" class="fooServiceImpl" scope="test:foo"/> </blueprint> It should be possible to do this according to Section 121.5.5 of the Blueprint Specification, and also described in the Tscope type in the Blueprint XML schema. Unfortunately, the blueprint XML above currently does not work, as there is no way to configure a custom scope that is namespace qualified. In order to get this working I believe the following are required: 1) A way to register a BeanDefinitionDecorator such that its decorate() method will get called when the scope attribute contains a qualified value in the correct namespace, e.g. registerBeanDefinitionDecoratorForCustomScope(). 2) When the scope value is namespace qualified then the actual namespace value, must be saved as a part of the scope, and not just the prefix. In the example above this means that the correct value of the scope is "{http://test.org}foo" not "test:foo". Reproducible: Always
Assigned to upcoming milestone
I won't implement this change. Here is why: While the blueprint spec indeed allows arbitrary qualified names for bean scopes, it has no specification regarding the semantics of additional scope. Specifically, it states: "Implementations can provide additional scope types. However, these types must only be allowed when a defining namespace is included in the definitions and is actually used in the definitions to specify the dependency on this feature." [1] In the case of gemini-blueprint, parsing of the <bean> declaration is delegated to the Spring framework's BeanDefinitionParserDelegate [2] which thus forms the implementation mentioned by the blueprint specification. I do not consider it practical to attempt to augment Spring's capabilities for this case, even though I agree that it would be best practice to resolve the namespace and prefix scope attributes with it. However, I also believe that 99.9% of any use case should well be feasible by declaring a <bean> element in the spring beans namespace (http://www.springframework.org/schema/beans -> http://www.springframework.org/schema/beans/spring-beans-4.3.xsd) in combination with a CustomScopeConfigurer [3]. Closing as won't fix. [1] https://osgi.org/download/r5/osgi.cmpn-5.0.0.pdf [2] https://docs.spring.io/spring/docs/4.3.x/javadoc-api/org/springframework/beans/factory/xml/BeanDefinitionParserDelegate.html [3] https://docs.spring.io/spring/docs/4.3.x/javadoc-api/org/springframework/beans/factory/config/CustomScopeConfigurer.html
Released - closing.
