[jira] [Comment Edited] (CAMEL-10352) Optionally delegate to Aries PropertyEvaluator services in BlueprintPropertiesParser
[ https://issues.apache.org/jira/browse/CAMEL-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15571731#comment-15571731 ] Luca Burgazzoli edited comment on CAMEL-10352 at 10/14/16 11:54 AM: [~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::getProperty via reflection (as it is protected) and this method does not take into account PropertyEvaluator - DefaultPropertiesParser tries to resolve a placeholder using registered functions then it check if the placeholder has a default value before to call doGetPropertyValue so if you have a placeholder named prefix:something, you'll get doGetPropertyValue invoked with prefix To let PropertyEvaluators be taken into account, we could: - Invoke AbstractPropertyPlaceholder::retrieveValue which eventually invokes a PropertyEvaluator - Invoke parseProperty in DefaultPropertiesParser::getPropertyValue before searching for the default so that you can give a change to the specific subclass ((in our case BlueprintPropertiesParser) to resolve the placeholder as it is , if no result are returned we then go ahead as today searching 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 BlueprintPropertiesParser. [Here|https://github.com/apache/camel/compare/master...lburgazzoli:CAMEL-10352] you can wee the required changes Let me know what you think. Links: 1) https://github.com/apache/camel/blob/master/components/camel-blueprint/src/main/java/org/apache/camel/blueprint/BlueprintPropertiesParser.java#L99 2) https://github.com/apache/camel/blob/master/components/camel-blueprint/src/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ù 4) https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/component/properties/DefaultPropertiesParser.java#L237-L241 was (Author: lb): [~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::getProperty via reflection (as it is protected) and this method does not take into account PropertyEvaluator - DefaultPropertiesParser tries to resolve a placeholder using registered functions then it check if the placeholder has a default value before to call doGetPropertyValue so if you have a placeholder named prefix:something, you'll get doGetPropertyValue invoked with prefix To let PropertyEvaluators be taken into account, we could: - Invoke AbstractPropertyPlaceholder::retrieveValue which eventually invokes a PropertyEvaluator - Invoke doGetPropertyValue in DefaultPropertiesParser::getPropertyValue also before searching for the default so that you can give a change to the specific subclass ((in our case BlueprintPropertiesParser) to resolve the placeholder as it is , if no result are returned we then go ahead as today searching 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 BlueprintPropertiesParser. [Here|https://github.com/apache/camel/compare/master...lburgazzoli:CAMEL-10352] you can wee the required changes Let me know what you think. Links: 1) https://github.com/apache/camel/blob/master/components/camel-blueprint/src/main/java/org/apache/camel/blueprint/BlueprintPropertiesParser.java#L99 2) https://github.com/apache/camel/blob/master/components/camel-blueprint/src/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ù 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 > BlueprintPropertiesParser > > > 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 >
[jira] [Comment Edited] (CAMEL-10352) Optionally delegate to Aries PropertyEvaluator services in BlueprintPropertiesParser
[ https://issues.apache.org/jira/browse/CAMEL-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529276#comment-15529276 ] Luca Burgazzoli edited comment on CAMEL-10352 at 9/28/16 11:07 AM: --- It depends on the implementation, I would say that the default should be to return the same value as the one given was (Author: lb): It depends on the implementation, it returns the same value as the one given > Optionally delegate to Aries PropertyEvaluator services in > BlueprintPropertiesParser > > > 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)
[jira] [Comment Edited] (CAMEL-10352) Optionally delegate to Aries PropertyEvaluator services in BlueprintPropertiesParser
[
https://issues.apache.org/jira/browse/CAMEL-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529157#comment-15529157
]
Grzegorz Grzybek edited comment on CAMEL-10352 at 9/28/16 10:19 AM:
Currently, in Blueprint Camel contexts we can do
({{useBlueprintPropertyResolver="true"}} is default):
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{greeting}} ${body}
{code}
useBlueprintPropertyResolver="true" makes PropertiesComponent aware of Aries
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} instances, like
{{}} or {{}}.
There's however another feature of Blueprint property placeholder resolvers:
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}}.
This evaluator is used ONLY when postprocessing blueprint CDR (component
definition registry) - similar to Spring's BeanFactoryPostprocessors.
So if we have something like this in Blueprint XML:
{code:xml}
{code}
evaluator will be used, because {{$x.y.z}} is resolved at
_component registry postprocessing time_. But it won't be used here:
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{x.y.z}}
{code}
because even if Camel's PropertiesComponent will delegate to Blueprint (from
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}} call
to e.g., {{org.apache.aries.blueprint.ext.PropertyPlaceholder#getProperty()}}),
Blueprint won't use PropertyEvaluator any more.
h2. Possible solution
If we add another attribute to
{{http//camel.apache.org/schema/blueprintcamelContext}}, like
this (defaults to {{false}}):
{code:xml}
http://camel.apache.org/schema/blueprint;
useBlueprintPropertyResolver="true" useBlueprintPropertyEvaluator="true">
{code}
and enhance
{{org.apache.camel.blueprint.BlueprintPropertiesParser#lookupPropertyPlaceholderIds()}}
to lookup beans with
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}} class (in
addition to {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}}),
these additional property resolvers could be used in
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}}.
So, {{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}}
could use two _for_ loops:
* one over _property sources_ (current behavior):
{code:xml}
for (AbstractPropertyPlaceholder placeholder : placeholders) {
...
{code}
* new one over _property evaluators_ (new behavior):
{code:xml}
for (org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator evaluator :
evaluators {
...
String answer = evaluator.evaluate(key, ...);
{code}
what do you think?
was (Author: gzres):
Currently, in Blueprint Camel contexts we can do
({{useBlueprintPropertyResolver="true"}} is default):
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{greeting}} ${body}
{code}
useBlueprintPropertyResolver="true" makes PropertiesComponent aware of Aries
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} instances, like
{{}} or {{}}.
There's however another feature of Blueprint property placeholder resolvers:
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}}.
This evaluator is used ONLY when postprocessing blueprint CDR (component
definition registry) - similar to Spring's BeanFactoryPostprocessors.
So if we have something like this in Blueprint XML:
{code:xml}
{code}
evaluator will be used, because {{$x.y.z}} is resolved at
_component registry postprocessing time_. But it won't be used here:
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{x.y.z}}
{code}
because even if Camel's PropertiesComponent will delegate to Blueprint (from
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}} call
to e.g., {{org.apache.aries.blueprint.ext.PropertyPlaceholder#getProperty()}}),
Blueprint won't use PropertyEvaluator any more.
h2. Possible solution
If we add another attribute to
{{httpx3a;//camel.apache.org/schema/blueprintcamelContext}},
like this (defaults to {{false}}):
{code:xml}
http://camel.apache.org/schema/blueprint;
useBlueprintPropertyResolver="true" useBlueprintPropertyEvaluator="true">
{code}
and enhance
{{org.apache.camel.blueprint.BlueprintPropertiesParser#lookupPropertyPlaceholderIds()}}
to lookup beans with
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}} class (in
addition to {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}}),
these additional property resolvers could be used in
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}}.
So, {{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}}
could use two _for_ loops:
* one over _property sources_ (current behavior):
{code:xml}
for
[jira] [Comment Edited] (CAMEL-10352) Optionally delegate to Aries PropertyEvaluator services in BlueprintPropertiesParser
[
https://issues.apache.org/jira/browse/CAMEL-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529157#comment-15529157
]
Grzegorz Grzybek edited comment on CAMEL-10352 at 9/28/16 10:16 AM:
Currently, in Blueprint Camel contexts we can do
({{useBlueprintPropertyResolver="true"}} is default):
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{greeting}} ${body}
{code}
useBlueprintPropertyResolver="true" makes PropertiesComponent aware of Aries
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} instances, like
{{}} or {{}}.
There's however another feature of Blueprint property placeholder resolvers:
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}}.
This evaluator is used ONLY when postprocessing blueprint CDR (component
definition registry) - similar to Spring's BeanFactoryPostprocessors.
So if we have something like this in Blueprint XML:
{code:xml}
{code}
evaluator will be used, because {{$x.y.z}} is resolved at
_component registry postprocessing time_. But it won't be used here:
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{x.y.z}}
{code}
because even if Camel's PropertiesComponent will delegate to Blueprint (from
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}} call
to e.g., {{org.apache.aries.blueprint.ext.PropertyPlaceholder#getProperty()}}),
Blueprint won't use PropertyEvaluator any more.
h2. Possible solution
If we add another attribute to
{{httpx3a;//camel.apache.org/schema/blueprintcamelContext}},
like this (defaults to {{false}}):
{code:xml}
http://camel.apache.org/schema/blueprint;
useBlueprintPropertyResolver="true" useBlueprintPropertyEvaluator="true">
{code}
and enhance
{{org.apache.camel.blueprint.BlueprintPropertiesParser#lookupPropertyPlaceholderIds()}}
to lookup beans with
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}} class (in
addition to {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}}),
these additional property resolvers could be used in
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}}.
So, {{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}}
could use two _for_ loops:
* one over _property sources_ (current behavior):
{code:xml}
for (AbstractPropertyPlaceholder placeholder : placeholders) {
...
{code}
* new one over _property evaluators_ (new behavior):
{code:xml}
for (org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator evaluator :
evaluators {
...
String answer = evaluator.evaluate(key, ...);
{code}
what do you think?
was (Author: gzres):
Currently, in Blueprint Camel contexts we can do
({{useBlueprintPropertyResolver="true"}} is default):
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{greeting}} ${body}
{code}
useBlueprintPropertyResolver="true" makes PropertiesComponent aware of Aries
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} instances, like
{{}} or {{}}.
There's however another feature of Blueprint property placeholder resolvers:
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}}.
This evaluator is used ONLY when postprocessing blueprint CDR (component
definition registry) - similar to Spring's BeanFactoryPostprocessors.
So if we have something like this in Blueprint XML:
{code:xml}
{code}
evaluator will be used, because {{$x.y.z}} is resolved at
_component registry postprocessing time_. But it won't be used here:
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{x.y.z}}
{code}
because even if Camel's PropertiesComponent will delegate to Blueprint (from
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}} call
to e.g., {{org.apache.aries.blueprint.ext.PropertyPlaceholder#getProperty()}}),
Blueprint won't use PropertyEvaluator any more.
h2. Possible solution
If we add another attribute to
{{http://camel.apache.org/schema/blueprintcamelContext}}, like this
(defaults to {{false}}):
{code:xml}
http://camel.apache.org/schema/blueprint;
useBlueprintPropertyResolver="true" useBlueprintPropertyEvaluator="true">
{code}
and enhance
{{org.apache.camel.blueprint.BlueprintPropertiesParser#lookupPropertyPlaceholderIds()}}
to lookup beans with
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}} class (in
addition to {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}}),
these additional property resolvers could be used in
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}}.
So, {{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}}
could use two _for_ loops:
* one over _property sources_ (current behavior):
{code:xml}
for
[jira] [Comment Edited] (CAMEL-10352) Optionally delegate to Aries PropertyEvaluator services in BlueprintPropertiesParser
[
https://issues.apache.org/jira/browse/CAMEL-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529157#comment-15529157
]
Grzegorz Grzybek edited comment on CAMEL-10352 at 9/28/16 10:13 AM:
Currently, in Blueprint Camel contexts we can do
({{useBlueprintPropertyResolver="true"}} is default):
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{greeting}} ${body}
{code}
useBlueprintPropertyResolver="true" makes PropertiesComponent aware of Aries
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} instances, like
{{}} or {{}}.
There's however another feature of Blueprint property placeholder resolvers:
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}}.
This evaluator is used ONLY when postprocessing blueprint CDR (component
definition registry) - similar to Spring's BeanFactoryPostprocessors.
So if we have something like this in Blueprint XML:
{code:xml}
{code}
evaluator will be used, because {{$x.y.z}} is resolved at
_component registry postprocessing time_. But it won't be used here:
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{x.y.z}}
{code}
because even if Camel's PropertiesComponent will delegate to Blueprint (from
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}} call
to e.g., {{org.apache.aries.blueprint.ext.PropertyPlaceholder#getProperty()}}),
Blueprint won't use PropertyEvaluator any more.
h2. Possible solution
If we add another attribute to
{{http://camel.apache.org/schema/blueprintcamelContext}}, like this
(defaults to {{false}}):
{code:xml}
http://camel.apache.org/schema/blueprint;
useBlueprintPropertyResolver="true" useBlueprintPropertyEvaluator="true">
{code}
and enhance
{{org.apache.camel.blueprint.BlueprintPropertiesParser#lookupPropertyPlaceholderIds()}}
to lookup beans with
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}} class (in
addition to {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}}),
these additional property resolvers could be used in
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}}.
So, {{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}}
could use two _for_ loops:
* one over _property sources_ (current behavior):
{code:xml}
for (AbstractPropertyPlaceholder placeholder : placeholders) {
...
{code}
* new one over _property evaluators_ (new behavior):
{code:xml}
for (org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator evaluator :
evaluators {
...
String answer = evaluator.evaluate(key, ...);
{code}
what do you think?
was (Author: gzres):
Currently, in Blueprint Camel contexts we can do
({{useBlueprintPropertyResolver="true"}} is default):
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{greeting}} ${body}
{code}
useBlueprintPropertyResolver="true" makes PropertiesComponent aware of Aries
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} instances, like
{{}} or {{}}.
There's however another feature of Blueprint property placeholder resolvers:
{{org.apache.aries.blueprint.ext.evaluator.PropertyEvaluator}}.
This evaluator is used ONLY when postprocessing blueprint CDR (component
definition registry) - similar to Spring's BeanFactoryPostprocessors.
So if we have something like this in Blueprint XML:
{code:xml}
{code}
evaluator will be used, because {{$x.y.z}} is resolved at
_component registry postprocessing time_. But it won't be used here:
{code:xml}
http://camel.apache.org/schema/blueprint;>
{{x.y.z}}
{code}
because even if Camel's PropertiesComponent will delegate to Blueprint (from
{{org.apache.camel.blueprint.BlueprintPropertiesParser#parseProperty()}} call
to e.g., {{org.apache.aries.blueprint.ext.PropertyPlaceholder#getProperty()}}),
Blueprint won't use PropertyEvaluator any more.
h2. Possible solution
> Optionally delegate to Aries PropertyEvaluator services in
> BlueprintPropertiesParser
>
>
> 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)
