Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Thu, 13 Oct 2016 12:10:20 +0000 (UTC)
From: "Luca Burgazzoli (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: <JIRA.13008177.1475056550000.816050.1476360620494@Atlassian.JIRA>
In-Reply-To: <JIRA.13008177.1475056550000@Atlassian.JIRA>
References: <JIRA.13008177.1475056550000@Atlassian.JIRA> <JIRA.13008177.1475056550763@arcas>
Subject: [jira] [Commented] (CAMEL-10352) Optionally delegate to Aries
 PropertyEvaluator services in BlueprintPropertiesParser
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 13 Oct 2016 12:10:22 -0000


    [ https://issues.apache.org/jira/browse/CAMEL-10352?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D155=
71731#comment-15571731 ]=20

Luca Burgazzoli commented on CAMEL-10352:
-----------------------------------------

[~davsclaus] [~gzres]

I had a second look at the code and I think we can implement this thing in =
a better and less intrusive way, some background:

- BlueprintPropertiesParser invokes AbstractPropertyPlaceholder::getPropert=
y via reflection (as it is protected) and this method does not take into ac=
count PropertyEvaluator
- DefaultPropertiesParser tries to resolve a placeholder using registered f=
unctions then it check if the placeholder has a default value before to cal=
l doGetPropertyValue so if you have a placeholder named prefix:something, y=
ou'll get doGetPropertyValue invoked with prefix

To let PropertyEvaluators be taken into account, we could:

- Invoke AbstractPropertyPlaceholder::retrieveValue which eventually invoke=
s a PropertyEvaluator
- Invoke doGetPropertyValue in DefaultPropertiesParser::getPropertyValue al=
so before searching for the default so that you can give a change to the sp=
ecific subclass ((in our case BlueprintPropertiesParser) to resolve the pla=
ceholder as it is , if no result are returned we then go ahead as today sea=
rching for a default and so on.


By doing so we relies on Aries for property resolution so we do not need to=
 care about PropertyEvaluators or any other stuff that may land in aries in=
 the future and we do not need to add a new prefix resolution in BlueprintP=
ropertiesParser.


[Here|https://github.com/apache/camel/compare/master...lburgazzoli:CAMEL-10=
352] you can wee the required changes

Let me know what you think.


Links:
1) https://github.com/apache/camel/blob/master/components/camel-blueprint/s=
rc/main/java/org/apache/camel/blueprint/BlueprintPropertiesParser.java#L99
2) https://github.com/apache/camel/blob/master/components/camel-blueprint/s=
rc/main/java/org/apache/camel/blueprint/BlueprintPropertiesParser.java#L138
3) https://github.com/apache/camel/blob/master/camel-core/src/main/java/org=
/apache/camel/component/properties/DefaultPropertiesParser.java#L213-L234=
=C3=B9
4) https://github.com/apache/camel/blob/master/camel-core/src/main/java/org=
/apache/camel/component/properties/DefaultPropertiesParser.java#L237-L241


> Optionally delegate to Aries PropertyEvaluator services in BlueprintPrope=
rtiesParser
> -------------------------------------------------------------------------=
-----------
>
>                 Key: CAMEL-10352
>                 URL: https://issues.apache.org/jira/browse/CAMEL-10352
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-blueprint, osgi
>            Reporter: Grzegorz Grzybek
>            Assignee: Luca Burgazzoli
>


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)