[
https://issues.apache.org/jira/browse/ARIES-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105936#comment-13105936
]
Rex Wang commented on ARIES-727:
--------------------------------
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
