[
https://issues.apache.org/jira/browse/ARIES-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved ARIES-315.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.0
Fixed in rev http://svn.apache.org/viewvc?rev=1364832&view=rev
> Blueprint-cm and the cm-properties element
> ------------------------------------------
>
> Key: ARIES-315
> URL: https://issues.apache.org/jira/browse/ARIES-315
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
> Environment: I was using Aries that I built myself. I had used source
> code from the trunk.
> Reporter: Bartosz Kowalewski
> Assignee: Guillaume Nodet
> Fix For: 1.0
>
>
> I used to employ Spring Extender when implementing enterprise applications to
> be deployed onto an OSGi container. I've recently moved to Blueprint and it
> turned out that I'm now NOT able to do what was previously possible (with
> Spring Extender). I'm not sure if this is a bug or blueprint-cm behaves as
> designed. Let me explain ...
> I tried to use Blueprint similarly to what I did in Spring:
> {code}
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0">
> <bean id="registry"
> class="com.bartek.tests.paxtests.blueprint.cm.ConfigurableMock">
> <property name="properties" ref="testProps" />
> </bean>
> <cm:cm-properties id="testProps" persistent-id="testProps" />
> </blueprint>
> {code}
> What I really want to do is to inject all the properties for a given
> persistent id into a field of my bean. This was possible for Spring Extender.
> I analyzed the Blueprint source code, because I wanted to provide a patch for
> this issue, but it turned out that there are several reasons why this cannot
> work:
> 1. blueprint-cm xsd does not allow using the 'id' attribute on the
> cm-properties element
> 2. CmNamespaceHandler is prepared to parse neither top level cm-properties
> elements, nor cm-properties inlined as a value for a property of a bean
> manager
> 3. the CmNamespaceHandler 's decorateCmProperties method and especially the
> contents of the CmProperties class suggest that cm-properties were not
> designed to be used the way I would like to use them; it is designed to
> provide a way to update properties of a registered service;
> While I can definitely patch it, so that it works the way I want :), I would
> like to know if such a usage is allowed by the spec. My first impression
> (especially after I found out how CmProperties work - #3 above) is that this
> feature of Spring DM was dropped.
> One more thing: Is there any draft of the spec that covers the blueprint-cm
> schema? I found it difficult to understand the semantics behind the
> bluepring-cm elements only provided with the xsd file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira