[ 
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

        

Reply via email to