[jira] [Issue Comment Edited] (ARIES-727) support syntax : ${a+b} in blueprint-cm

["Rex Wang (JIRA)" <ji...@apache.org>]

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

Rex Wang edited comment on ARIES-727 at 9/16/11 8:06 AM:
---------------------------------------------------------

Just uploaded ARIES-727-new-draft-fixes-in-blueprint-ext.patch
The patch is trying to implement the new idea suggested by Alasdair in mail list, which is modifying the blueprint-ext schema so that we do not need add a new namespace.

This is still a draft patch for review. Some issues are:
(1) I temply move jexl parser to a separate folder instead of stripping out it from blueprint-core so that I can easily test it in the itests. After all are done, the jexl parse should be in a separate bundle.

(2) I am not sure if the currently solution meets the state from Alasdair: "The namespace handler then inserts a synthetic service dependency on a
service of type PropertyProcessor with the service property 'type=jexl'". 
The corresponding code in ExtNamespaceHandler I implemented is:
String evaluator = element.hasAttribute(EVALUATOR_ATTRIBUTE) ? element.getAttribute(EVALUATOR_ATTRIBUTE) : null;
        if (evaluator != null) {
            metadata.addProperty("evaluator", createReference(context, evaluator));
        }

This will add a <reference interface="org.apache.aries.blueprint.ext.PropertyEvaluator" filter="(evaluator.type=xxx)"> like metadata to the target blueprint container, but it will lead the target bundle hard depends on class "org.apache.aries.blueprint.ext.PropertyEvaluator", which means it need import the org.apache.aries.blueprint.ext package explicitly. 

Any ideas? 

(3). There are 2 itests, named xxxxBTCustomizerTest, always fail after the change. I don't figure out why...

-Rex



      was (Author: rwonly):
    Just uploaded ARIES-727-new-draft-fixes-in-blueprint-ext.patch
The patch is trying to implement the new idea suggested by Alasdair in mail list, which is modifying the blueprint-ext schema so that we do not need add a new namespace.

This is still a draft patch for review. Some issues are:
(1) I temply move jexl parser to a separate folder instead of stripping out it from blueprint-core so that I can easily test it in the itests. After all are done, the jexl parse should be in a separate bundle.

(2) I am not sure if the currently solution meets the state from Alasdair: "The namespace handler then inserts a synthetic service dependency on a
service of type PropertyProcessor with the service property 'type=jexl'". 
The corresponding code in ExtNamespaceHandler I implemented is:
String evaluator = element.hasAttribute(EVALUATOR_ATTRIBUTE) ? element.getAttribute(EVALUATOR_ATTRIBUTE) : null;
        if (evaluator != null) {
            metadata.addProperty("evaluator", createReference(context, evaluator));
        }

This will add a <reference interface="org.apache.aries.blueprint.ext.PropertyEvaluator" filter="(evaluator.type=xxx)"> like metadata to the target blueprint container, but it will lead the target bundle hard depends on class "org.apache.aries.blueprint.ext.PropertyEvaluator", which means it need import the org.apache.aries.blueprint.ext package explicitly. 

Any ideas? 

3. There are 2 itests, named xxxxBTCustomizerTest, always fail after the change. I don't figure out why...

-Rex


  
> support syntax : ${a+b} in blueprint-cm 
> ----------------------------------------
>
>                 Key: ARIES-727
>                 URL: https://issues.apache.org/jira/browse/ARIES-727
>             Project: Aries
>          Issue Type: New Feature
>          Components: Blueprint
>    Affects Versions: blueprint-0.3.1, blueprint-0.4.0
>            Reporter: Rex Wang
>            Assignee: Rex Wang
>             Fix For: blueprint-0.4.0
>
>         Attachments: ARIES-727-blueprint-cm.patch, ARIES-727-fixes-in-blueprint-ext.patch, ARIES-727-new-draft-fixes-in-blueprint-ext.patch
>
>
> I am wondering if Aries blueprint-cm support such scenario:
> <cm:property-placeholder id="property-placeholder" persistent-id="o.a.b.com" placeholder-prefix="${" placeholder-suffix="}">
>         <cm:default-properties>
>             <cm:property name="port" value="12345"/>
>             <cm:property name="offset" value="10"/>
>         </cm:default-properties>
> </cm:property-placeholder>
> <xxx:conn name="loc" uri="http://localhost:${port+offset}"/>
> I have a test, but seems the ${port+offset} can not be replaced with value "12355".
> -Rex
> -----------------------
> Hi Rex,
> to my knowledge (substantiated with a quick code inspection) the placeholders in Aries today support no operators or arithmetic like that. But please do raise an Improvement JIRA for the future :)
> Regards,
> Valentin
> -----------------------
> When we support this, we need to perform a 'plus' or string concatenate
> operation based on the variable type:).
> Therefore. when specifying the property in the blueprint xml, the explicit
> type should be specified if not string.
> Regards,
> Emily
> -----------------------
> I _think_ I wrote something like this for xbean-blueprint since it didn't look like blueprint supported it.  IIRC I used the same calculation engine as the geronimo config substitutions.  I think you can infer what kind of calculation to do (addition or concatenation) from the type of the property you end up setting.
> thanks
> david jencks

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira