[PROPOSAL] - Camel 2.0 - support # syntax in URI options

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROPOSAL] - Camel 2.0 - support # syntax in URI options

Claus Ibsen-2
Hi

For background see CAMEL-895 and this thread by James
http://www.nabble.com/-2.0--simplifying-annotations%2C-DSL-and-XML-to-remove-uri-%2B-ref--tp20775864s22882p20775864.html

Motivation
=======
Currently the URI configuration of camel endpoints is used a lot. It's
fast, precise and intuitive for end-users. And it supports most of
their use-cases.
The URI options is given as string parameters just like http. Camel
will then parse this and type convert and call the correct setter on
the concrete xxxEndpoint object.
Camel can do the traditional type converts for numeric, boolean,
string, enum and what not. However the problem is...

The problem
=========
That we can not set complex objects on endpoint using URI options.
Each individual component need to add special code to support this and
it's irritating me. Why can't we do it smarter.
And if we do it smarter then we get this out-of-the-box so suddenly
*all* components support this.

The idea
======
The idea is to support the # syntax for URI options (I think Apache
CXF has this as well).

So if you want to set a complex object type on a given endpoint you
can refer to a bean in the registry using the # notation. An example:
     file://inbox/?idempotent=true&idempotentRepository=#myJpaRepo

Then end users can configure the myJapRepo in the Spring XML using
standard spring bean ids.

Benefits
======
- It's easy for end users as they can look at the xxEndpoint and see
which properties it has (setters). And they can use the # notation to
set it for complex objects as well.
- When you add options to an endpoint you get this notation for free,
no need to add special code to the xxxComponent to do the lookup
yourself
- Even some options on default endpoints is now exposed and
configurable, such as the executorService
- We can reduce existing code
- Easier for end users to understand that # is for regestry lookup
instead of inventing our own custom names such as:
idempotentRepositoryRef
- And as a real bonus we don't have to wiki document the special
options idempotentRepositoryRef. We get all this for free with # so we
can just document the idempotentRepository option

Any thoughts?


/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

Ramon Buckland
+1 I like it.

Would a feature such as auto-wiring be of any use also ?
so .. uri="foo:something?autowire=byname"

This way, any bean available it the context is then auto-wired in ?

one other point, if #beanName is to be used, make sure the fallback of
attempting to set the String '#someString' still works as it would be
iritating if a #someString is needed but can't be because it is reserved for
bean wiring.

r.

On Sun, Dec 7, 2008 at 00:08, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> For background see CAMEL-895 and this thread by James
>
> http://www.nabble.com/-2.0--simplifying-annotations%2C-DSL-and-XML-to-remove-uri-%2B-ref--tp20775864s22882p20775864.html
>
> Motivation
> =======
> Currently the URI configuration of camel endpoints is used a lot. It's
> fast, precise and intuitive for end-users. And it supports most of
> their use-cases.
> The URI options is given as string parameters just like http. Camel
> will then parse this and type convert and call the correct setter on
> the concrete xxxEndpoint object.
> Camel can do the traditional type converts for numeric, boolean,
> string, enum and what not. However the problem is...
>
> The problem
> =========
> That we can not set complex objects on endpoint using URI options.
> Each individual component need to add special code to support this and
> it's irritating me. Why can't we do it smarter.
> And if we do it smarter then we get this out-of-the-box so suddenly
> *all* components support this.
>
> The idea
> ======
> The idea is to support the # syntax for URI options (I think Apache
> CXF has this as well).
>
> So if you want to set a complex object type on a given endpoint you
> can refer to a bean in the registry using the # notation. An example:
>     file://inbox/?idempotent=true&idempotentRepository=#myJpaRepo
>
> Then end users can configure the myJapRepo in the Spring XML using
> standard spring bean ids.
>
> Benefits
> ======
> - It's easy for end users as they can look at the xxEndpoint and see
> which properties it has (setters). And they can use the # notation to
> set it for complex objects as well.
> - When you add options to an endpoint you get this notation for free,
> no need to add special code to the xxxComponent to do the lookup
> yourself
> - Even some options on default endpoints is now exposed and
> configurable, such as the executorService
> - We can reduce existing code
> - Easier for end users to understand that # is for regestry lookup
> instead of inventing our own custom names such as:
> idempotentRepositoryRef
> - And as a real bonus we don't have to wiki document the special
> options idempotentRepositoryRef. We get all this for free with # so we
> can just document the idempotentRepository option
>
> Any thoughts?
>
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

Claus Ibsen-2
On Sat, Dec 6, 2008 at 2:18 PM, Ramon Buckland <[hidden email]> wrote:
> +1 I like it.
>
> Would a feature such as auto-wiring be of any use also ?
> so .. uri="foo:something?autowire=byname"
>
> This way, any bean available it the context is then auto-wired in ?
Good idea. But is this autowire used much in pure spring? Personally I
have always used explicit wiring.

>
> one other point, if #beanName is to be used, make sure the fallback of
> attempting to set the String '#someString' still works as it would be
> iritating if a #someString is needed but can't be because it is reserved for
> bean wiring.
Good catch. So if there is a String setter and NO bean in registry it
should fallback to set the string?
We do have options that support multiple types such as an expression
that can be string based and thus there is a setter that accepts a
String.
But we have overloaded the option with Expresison type as well. So we
should be lenient on the String settable options ;)

>
> r.
>
> On Sun, Dec 7, 2008 at 00:08, Claus Ibsen <[hidden email]> wrote:
>
>> Hi
>>
>> For background see CAMEL-895 and this thread by James
>>
>> http://www.nabble.com/-2.0--simplifying-annotations%2C-DSL-and-XML-to-remove-uri-%2B-ref--tp20775864s22882p20775864.html
>>
>> Motivation
>> =======
>> Currently the URI configuration of camel endpoints is used a lot. It's
>> fast, precise and intuitive for end-users. And it supports most of
>> their use-cases.
>> The URI options is given as string parameters just like http. Camel
>> will then parse this and type convert and call the correct setter on
>> the concrete xxxEndpoint object.
>> Camel can do the traditional type converts for numeric, boolean,
>> string, enum and what not. However the problem is...
>>
>> The problem
>> =========
>> That we can not set complex objects on endpoint using URI options.
>> Each individual component need to add special code to support this and
>> it's irritating me. Why can't we do it smarter.
>> And if we do it smarter then we get this out-of-the-box so suddenly
>> *all* components support this.
>>
>> The idea
>> ======
>> The idea is to support the # syntax for URI options (I think Apache
>> CXF has this as well).
>>
>> So if you want to set a complex object type on a given endpoint you
>> can refer to a bean in the registry using the # notation. An example:
>>     file://inbox/?idempotent=true&idempotentRepository=#myJpaRepo
>>
>> Then end users can configure the myJapRepo in the Spring XML using
>> standard spring bean ids.
>>
>> Benefits
>> ======
>> - It's easy for end users as they can look at the xxEndpoint and see
>> which properties it has (setters). And they can use the # notation to
>> set it for complex objects as well.
>> - When you add options to an endpoint you get this notation for free,
>> no need to add special code to the xxxComponent to do the lookup
>> yourself
>> - Even some options on default endpoints is now exposed and
>> configurable, such as the executorService
>> - We can reduce existing code
>> - Easier for end users to understand that # is for regestry lookup
>> instead of inventing our own custom names such as:
>> idempotentRepositoryRef
>> - And as a real bonus we don't have to wiki document the special
>> options idempotentRepositoryRef. We get all this for free with # so we
>> can just document the idempotentRepository option
>>
>> Any thoughts?
>>
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

Ramon Buckland
> Good idea. But is this autowire used much in pure spring? Personally I
> have always used explicit wiring.


Yes, personally myself also. I have always considered it (potentially)
harmful, so perhaps it can be left off.


> Good catch. So if there is a String setter and NO bean in registry it
> should fallback to set the string?


Yes, something like that. I would figure ..


>
> We do have options that support multiple types such as an expression
> that can be string based and thus there is a setter that accepts a
> String.
> But we have overloaded the option with Expresison type as well. So we
> should be lenient on the String settable options ;)
>

 .. that as above, it is very implementation and current code specific as to
how it is done :-)
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

Claus Ibsen-2
Hi

I have attached a patch to the ticket CAMEL-895 and fixed some unit
tests for the file component to demonstrate the # notation.

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Sat, Dec 6, 2008 at 2:46 PM, Ramon Buckland <[hidden email]> wrote:

>> Good idea. But is this autowire used much in pure spring? Personally I
>> have always used explicit wiring.
>
>
> Yes, personally myself also. I have always considered it (potentially)
> harmful, so perhaps it can be left off.
>
>
>> Good catch. So if there is a String setter and NO bean in registry it
>> should fallback to set the string?
>
>
> Yes, something like that. I would figure ..
>
>
>>
>> We do have options that support multiple types such as an expression
>> that can be string based and thus there is a setter that accepts a
>> String.
>> But we have overloaded the option with Expresison type as well. So we
>> should be lenient on the String settable options ;)
>>
>
>  .. that as above, it is very implementation and current code specific as to
> how it is done :-)
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

William Tam
In reply to this post by Claus Ibsen-2
On Sat, Dec 6, 2008 at 8:25 AM, Claus Ibsen <[hidden email]> wrote:

> On Sat, Dec 6, 2008 at 2:18 PM, Ramon Buckland <[hidden email]> wrote:
>> +1 I like it.
>>
>> Would a feature such as auto-wiring be of any use also ?
>> so .. uri="foo:something?autowire=byname"
>>
>> This way, any bean available it the context is then auto-wired in ?
> Good idea. But is this autowire used much in pure spring? Personally I
> have always used explicit wiring.
>
>>
>> one other point, if #beanName is to be used, make sure the fallback of
>> attempting to set the String '#someString' still works as it would be
>> iritating if a #someString is needed but can't be because it is reserved for
>> bean wiring.
> Good catch. So if there is a String setter and NO bean in registry it
> should fallback to set the string?
> We do have options that support multiple types such as an expression
> that can be string based and thus there is a setter that accepts a
> String.
> But we have overloaded the option with Expresison type as well. So we
> should be lenient on the String settable options ;)
>

if we fails to resolve a bean because of user's typo, it may be more
helpful to produce some descent error message than automatically
assume the value is a literal String.  Another potential problem is
the reverse scenario.  If the user means a literal string value, say
"#abc", and "abc" happens to be a resolved bean id (the user may not
know it), then the user won't be able to set the value to the literal
value.  Imagine the user has tested the URI and everything is happy.
The problem suddenly manifests itself when a bean is added.

So, if we make '#' a special character, I wonder we should provide a
way to escape the '#' character for users who do mean the literal
value.  That way, we don't need to try and error. The code can run a
bit faster.  The downside is, it can break existing configuration that
contains literal string value with '#' as the first character.

Another thought is, we can consider putting the meta information in
the key of the query rather than in the value.

For example, we put "bean:" in front of the key name as:

    file://inbox/?idempotent=true&bean:idempotentRepository=myJpaRepo

When we see "bean:" prefixing a key, then we treat myJpaRepo as bean
id.  If it can not be resolved, we will flag an error.  If "bean:" is
not there, the value is a string "myJpaRepo".  Since ':' is not a
valid Java variable name, we don't have to worry about "bean:"
clashing with key name.


>>
>> r.
>>
>> On Sun, Dec 7, 2008 at 00:08, Claus Ibsen <[hidden email]> wrote:
>>
>>> Hi
>>>
>>> For background see CAMEL-895 and this thread by James
>>>
>>> http://www.nabble.com/-2.0--simplifying-annotations%2C-DSL-and-XML-to-remove-uri-%2B-ref--tp20775864s22882p20775864.html
>>>
>>> Motivation
>>> =======
>>> Currently the URI configuration of camel endpoints is used a lot. It's
>>> fast, precise and intuitive for end-users. And it supports most of
>>> their use-cases.
>>> The URI options is given as string parameters just like http. Camel
>>> will then parse this and type convert and call the correct setter on
>>> the concrete xxxEndpoint object.
>>> Camel can do the traditional type converts for numeric, boolean,
>>> string, enum and what not. However the problem is...
>>>
>>> The problem
>>> =========
>>> That we can not set complex objects on endpoint using URI options.
>>> Each individual component need to add special code to support this and
>>> it's irritating me. Why can't we do it smarter.
>>> And if we do it smarter then we get this out-of-the-box so suddenly
>>> *all* components support this.
>>>
>>> The idea
>>> ======
>>> The idea is to support the # syntax for URI options (I think Apache
>>> CXF has this as well).
>>>
>>> So if you want to set a complex object type on a given endpoint you
>>> can refer to a bean in the registry using the # notation. An example:
>>>     file://inbox/?idempotent=true&idempotentRepository=#myJpaRepo
>>>
>>> Then end users can configure the myJapRepo in the Spring XML using
>>> standard spring bean ids.
>>>
>>> Benefits
>>> ======
>>> - It's easy for end users as they can look at the xxEndpoint and see
>>> which properties it has (setters). And they can use the # notation to
>>> set it for complex objects as well.
>>> - When you add options to an endpoint you get this notation for free,
>>> no need to add special code to the xxxComponent to do the lookup
>>> yourself
>>> - Even some options on default endpoints is now exposed and
>>> configurable, such as the executorService
>>> - We can reduce existing code
>>> - Easier for end users to understand that # is for regestry lookup
>>> instead of inventing our own custom names such as:
>>> idempotentRepositoryRef
>>> - And as a real bonus we don't have to wiki document the special
>>> options idempotentRepositoryRef. We get all this for free with # so we
>>> can just document the idempotentRepository option
>>>
>>> Any thoughts?
>>>
>>>
>>> /Claus Ibsen
>>> Apache Camel Committer
>>> Blog: http://davsclaus.blogspot.com/
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

Claus Ibsen-2
On Sat, Dec 6, 2008 at 8:50 PM, William Tam <[hidden email]> wrote:

> On Sat, Dec 6, 2008 at 8:25 AM, Claus Ibsen <[hidden email]> wrote:
>> On Sat, Dec 6, 2008 at 2:18 PM, Ramon Buckland <[hidden email]> wrote:
>>> +1 I like it.
>>>
>>> Would a feature such as auto-wiring be of any use also ?
>>> so .. uri="foo:something?autowire=byname"
>>>
>>> This way, any bean available it the context is then auto-wired in ?
>> Good idea. But is this autowire used much in pure spring? Personally I
>> have always used explicit wiring.
>>
>>>
>>> one other point, if #beanName is to be used, make sure the fallback of
>>> attempting to set the String '#someString' still works as it would be
>>> iritating if a #someString is needed but can't be because it is reserved for
>>> bean wiring.
>> Good catch. So if there is a String setter and NO bean in registry it
>> should fallback to set the string?
>> We do have options that support multiple types such as an expression
>> that can be string based and thus there is a setter that accepts a
>> String.
>> But we have overloaded the option with Expresison type as well. So we
>> should be lenient on the String settable options ;)
>>
>
> if we fails to resolve a bean because of user's typo, it may be more
> helpful to produce some descent error message than automatically
> assume the value is a literal String.  Another potential problem is
> the reverse scenario.  If the user means a literal string value, say
> "#abc", and "abc" happens to be a resolved bean id (the user may not
> know it), then the user won't be able to set the value to the literal
> value.  Imagine the user has tested the URI and everything is happy.
> The problem suddenly manifests itself when a bean is added.
If Camel fails to resolve the parameter you will still get an error.
So if you type a mistake in either the parameter name or the key you
get an exception (just using xxx as example)

    file://inbox/?idempotent=true&xxxidempotentRepository=myJpaRepo
    file://inbox/?idempotent=true&idempotentRepository=xxxmyJpaRepo

In both situations you get an exception:
1) There are no properties on FileEndpoint that is named xxxidempotentRepository
2) There are no bean in the registry with the id xxxmyJpaRepo, and
idempotentRepository has setter that accepts a String type, so the
parameter is not successfully resolved


>
> So, if we make '#' a special character, I wonder we should provide a
> way to escape the '#' character for users who do mean the literal
> value.  That way, we don't need to try and error. The code can run a
> bit faster.  The downside is, it can break existing configuration that
> contains literal string value with '#' as the first character.
>
> Another thought is, we can consider putting the meta information in
> the key of the query rather than in the value.
>
> For example, we put "bean:" in front of the key name as:
>
>    file://inbox/?idempotent=true&bean:idempotentRepository=myJpaRepo
>
> When we see "bean:" prefixing a key, then we treat myJpaRepo as bean
> id.  If it can not be resolved, we will flag an error.  If "bean:" is
> not there, the value is a string "myJpaRepo".  Since ':' is not a
> valid Java variable name, we don't have to worry about "bean:"
> clashing with key name.

Yeah the bean: convention is also nice at it clearly highlights that
it's a bean reference, and no problems if end users want a string
literal starting with #.

When I first thought of this I used the convetion that if the
parameter name ended with Ref then it was a bean reference. So it
should be:
    file://inbox/?idempotent=true&idempotentRepositoryRef=myJpaRepo

That is why currently we have the xxxRef options added manually on
some of the components.


However what do other frameworks do? I haven't seen a good convention
for this. Maybe if we had a EL parser on top of the URI options? Using
the simple syntax ${ }, could be supported:
    file://inbox/?idempotent=true&idempotentRepository=${myJpaRepo}

What does Spring 3.0 have on the roadmap?


/Claus
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

William Tam
On Sun, Dec 7, 2008 at 3:41 AM, Claus Ibsen <[hidden email]> wrote:

> On Sat, Dec 6, 2008 at 8:50 PM, William Tam <[hidden email]> wrote:
>> On Sat, Dec 6, 2008 at 8:25 AM, Claus Ibsen <[hidden email]> wrote:
>>> On Sat, Dec 6, 2008 at 2:18 PM, Ramon Buckland <[hidden email]> wrote:
>>>> +1 I like it.
>>>>
>>>> Would a feature such as auto-wiring be of any use also ?
>>>> so .. uri="foo:something?autowire=byname"
>>>>
>>>> This way, any bean available it the context is then auto-wired in ?
>>> Good idea. But is this autowire used much in pure spring? Personally I
>>> have always used explicit wiring.
>>>
>>>>
>>>> one other point, if #beanName is to be used, make sure the fallback of
>>>> attempting to set the String '#someString' still works as it would be
>>>> iritating if a #someString is needed but can't be because it is reserved for
>>>> bean wiring.
>>> Good catch. So if there is a String setter and NO bean in registry it
>>> should fallback to set the string?
>>> We do have options that support multiple types such as an expression
>>> that can be string based and thus there is a setter that accepts a
>>> String.
>>> But we have overloaded the option with Expresison type as well. So we
>>> should be lenient on the String settable options ;)
>>>
>>
>> if we fails to resolve a bean because of user's typo, it may be more
>> helpful to produce some descent error message than automatically
>> assume the value is a literal String.  Another potential problem is
>> the reverse scenario.  If the user means a literal string value, say
>> "#abc", and "abc" happens to be a resolved bean id (the user may not
>> know it), then the user won't be able to set the value to the literal
>> value.  Imagine the user has tested the URI and everything is happy.
>> The problem suddenly manifests itself when a bean is added.
> If Camel fails to resolve the parameter you will still get an error.
> So if you type a mistake in either the parameter name or the key you
> get an exception (just using xxx as example)
>
>    file://inbox/?idempotent=true&xxxidempotentRepository=myJpaRepo
>    file://inbox/?idempotent=true&idempotentRepository=xxxmyJpaRepo
>
> In both situations you get an exception:
> 1) There are no properties on FileEndpoint that is named xxxidempotentRepository
> 2) There are no bean in the registry with the id xxxmyJpaRepo, and
> idempotentRepository has setter that accepts a String type, so the
> parameter is not successfully resolved
>
>
Sorry, I didn't read the patch.   I think I am a bit more clear now.
My comment is around 2).  Suppose my URI is:
   file://inbox/?idempotent=true&idempotentRepository=#oopsMadeATypoRepo
And because of my typo in the bean name, Camel can't find the bean
from the registry.   It then would precede with introspection and set
properties on the endpoint as before.   It won't succeed.  But,
instead of an error like "bean ref not found",  I may be getting some
error like "string cannot be assign to class XYZ".   I guess it is
really minor.  People rely on stack trace anyway.  :-)

>>
>> So, if we make '#' a special character, I wonder we should provide a
>> way to escape the '#' character for users who do mean the literal
>> value.  That way, we don't need to try and error. The code can run a
>> bit faster.  The downside is, it can break existing configuration that
>> contains literal string value with '#' as the first character.
>>
>> Another thought is, we can consider putting the meta information in
>> the key of the query rather than in the value.
>>
>> For example, we put "bean:" in front of the key name as:
>>
>>    file://inbox/?idempotent=true&bean:idempotentRepository=myJpaRepo
>>
>> When we see "bean:" prefixing a key, then we treat myJpaRepo as bean
>> id.  If it can not be resolved, we will flag an error.  If "bean:" is
>> not there, the value is a string "myJpaRepo".  Since ':' is not a
>> valid Java variable name, we don't have to worry about "bean:"
>> clashing with key name.
>
> Yeah the bean: convention is also nice at it clearly highlights that
> it's a bean reference, and no problems if end users want a string
> literal starting with #.
>
> When I first thought of this I used the convetion that if the
> parameter name ended with Ref then it was a bean reference. So it
> should be:
>    file://inbox/?idempotent=true&idempotentRepositoryRef=myJpaRepo
>
> That is why currently we have the xxxRef options added manually on
> some of the components.
>
>
> However what do other frameworks do? I haven't seen a good convention
> for this. Maybe if we had a EL parser on top of the URI options? Using
> the simple syntax ${ }, could be supported:
>    file://inbox/?idempotent=true&idempotentRepository=${myJpaRepo}
>
> What does Spring 3.0 have on the roadmap?
>
>
> /Claus
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

William Tam
The '#' convention is simple and adopted by at least one other
framework (CXF).  +1

On Sun, Dec 7, 2008 at 8:45 PM, William Tam <[hidden email]> wrote:

> On Sun, Dec 7, 2008 at 3:41 AM, Claus Ibsen <[hidden email]> wrote:
>> On Sat, Dec 6, 2008 at 8:50 PM, William Tam <[hidden email]> wrote:
>>> On Sat, Dec 6, 2008 at 8:25 AM, Claus Ibsen <[hidden email]> wrote:
>>>> On Sat, Dec 6, 2008 at 2:18 PM, Ramon Buckland <[hidden email]> wrote:
>>>>> +1 I like it.
>>>>>
>>>>> Would a feature such as auto-wiring be of any use also ?
>>>>> so .. uri="foo:something?autowire=byname"
>>>>>
>>>>> This way, any bean available it the context is then auto-wired in ?
>>>> Good idea. But is this autowire used much in pure spring? Personally I
>>>> have always used explicit wiring.
>>>>
>>>>>
>>>>> one other point, if #beanName is to be used, make sure the fallback of
>>>>> attempting to set the String '#someString' still works as it would be
>>>>> iritating if a #someString is needed but can't be because it is reserved for
>>>>> bean wiring.
>>>> Good catch. So if there is a String setter and NO bean in registry it
>>>> should fallback to set the string?
>>>> We do have options that support multiple types such as an expression
>>>> that can be string based and thus there is a setter that accepts a
>>>> String.
>>>> But we have overloaded the option with Expresison type as well. So we
>>>> should be lenient on the String settable options ;)
>>>>
>>>
>>> if we fails to resolve a bean because of user's typo, it may be more
>>> helpful to produce some descent error message than automatically
>>> assume the value is a literal String.  Another potential problem is
>>> the reverse scenario.  If the user means a literal string value, say
>>> "#abc", and "abc" happens to be a resolved bean id (the user may not
>>> know it), then the user won't be able to set the value to the literal
>>> value.  Imagine the user has tested the URI and everything is happy.
>>> The problem suddenly manifests itself when a bean is added.
>> If Camel fails to resolve the parameter you will still get an error.
>> So if you type a mistake in either the parameter name or the key you
>> get an exception (just using xxx as example)
>>
>>    file://inbox/?idempotent=true&xxxidempotentRepository=myJpaRepo
>>    file://inbox/?idempotent=true&idempotentRepository=xxxmyJpaRepo
>>
>> In both situations you get an exception:
>> 1) There are no properties on FileEndpoint that is named xxxidempotentRepository
>> 2) There are no bean in the registry with the id xxxmyJpaRepo, and
>> idempotentRepository has setter that accepts a String type, so the
>> parameter is not successfully resolved
>>
>>
> Sorry, I didn't read the patch.   I think I am a bit more clear now.
> My comment is around 2).  Suppose my URI is:
>   file://inbox/?idempotent=true&idempotentRepository=#oopsMadeATypoRepo
> And because of my typo in the bean name, Camel can't find the bean
> from the registry.   It then would precede with introspection and set
> properties on the endpoint as before.   It won't succeed.  But,
> instead of an error like "bean ref not found",  I may be getting some
> error like "string cannot be assign to class XYZ".   I guess it is
> really minor.  People rely on stack trace anyway.  :-)
>
>>>
>>> So, if we make '#' a special character, I wonder we should provide a
>>> way to escape the '#' character for users who do mean the literal
>>> value.  That way, we don't need to try and error. The code can run a
>>> bit faster.  The downside is, it can break existing configuration that
>>> contains literal string value with '#' as the first character.
>>>
>>> Another thought is, we can consider putting the meta information in
>>> the key of the query rather than in the value.
>>>
>>> For example, we put "bean:" in front of the key name as:
>>>
>>>    file://inbox/?idempotent=true&bean:idempotentRepository=myJpaRepo
>>>
>>> When we see "bean:" prefixing a key, then we treat myJpaRepo as bean
>>> id.  If it can not be resolved, we will flag an error.  If "bean:" is
>>> not there, the value is a string "myJpaRepo".  Since ':' is not a
>>> valid Java variable name, we don't have to worry about "bean:"
>>> clashing with key name.
>>
>> Yeah the bean: convention is also nice at it clearly highlights that
>> it's a bean reference, and no problems if end users want a string
>> literal starting with #.
>>
>> When I first thought of this I used the convetion that if the
>> parameter name ended with Ref then it was a bean reference. So it
>> should be:
>>    file://inbox/?idempotent=true&idempotentRepositoryRef=myJpaRepo
>>
>> That is why currently we have the xxxRef options added manually on
>> some of the components.
>>
>>
>> However what do other frameworks do? I haven't seen a good convention
>> for this. Maybe if we had a EL parser on top of the URI options? Using
>> the simple syntax ${ }, could be supported:
>>    file://inbox/?idempotent=true&idempotentRepository=${myJpaRepo}
>>
>> What does Spring 3.0 have on the roadmap?
>>
>>
>> /Claus
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

Claus Ibsen-2
Hi

This is the exception you get

#2
            component.createEndpoint("foo://?special=#dummy");
Note: This is for a unit test where I use Expression as the 'complex'
object, and special as the parameter name:

java.lang.IllegalArgumentException: Could not find a suitable setter
for property: special as there isn't a setter method with same type:
java.lang.String nor type convertion possbile: No type converter
available to convert from type: class java.lang.String to the required
type: org.apache.camel.Expression with value #dummy
        at org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:217)




/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Mon, Dec 8, 2008 at 4:32 AM, William Tam <[hidden email]> wrote:

> The '#' convention is simple and adopted by at least one other
> framework (CXF).  +1
>
> On Sun, Dec 7, 2008 at 8:45 PM, William Tam <[hidden email]> wrote:
>> On Sun, Dec 7, 2008 at 3:41 AM, Claus Ibsen <[hidden email]> wrote:
>>> On Sat, Dec 6, 2008 at 8:50 PM, William Tam <[hidden email]> wrote:
>>>> On Sat, Dec 6, 2008 at 8:25 AM, Claus Ibsen <[hidden email]> wrote:
>>>>> On Sat, Dec 6, 2008 at 2:18 PM, Ramon Buckland <[hidden email]> wrote:
>>>>>> +1 I like it.
>>>>>>
>>>>>> Would a feature such as auto-wiring be of any use also ?
>>>>>> so .. uri="foo:something?autowire=byname"
>>>>>>
>>>>>> This way, any bean available it the context is then auto-wired in ?
>>>>> Good idea. But is this autowire used much in pure spring? Personally I
>>>>> have always used explicit wiring.
>>>>>
>>>>>>
>>>>>> one other point, if #beanName is to be used, make sure the fallback of
>>>>>> attempting to set the String '#someString' still works as it would be
>>>>>> iritating if a #someString is needed but can't be because it is reserved for
>>>>>> bean wiring.
>>>>> Good catch. So if there is a String setter and NO bean in registry it
>>>>> should fallback to set the string?
>>>>> We do have options that support multiple types such as an expression
>>>>> that can be string based and thus there is a setter that accepts a
>>>>> String.
>>>>> But we have overloaded the option with Expresison type as well. So we
>>>>> should be lenient on the String settable options ;)
>>>>>
>>>>
>>>> if we fails to resolve a bean because of user's typo, it may be more
>>>> helpful to produce some descent error message than automatically
>>>> assume the value is a literal String.  Another potential problem is
>>>> the reverse scenario.  If the user means a literal string value, say
>>>> "#abc", and "abc" happens to be a resolved bean id (the user may not
>>>> know it), then the user won't be able to set the value to the literal
>>>> value.  Imagine the user has tested the URI and everything is happy.
>>>> The problem suddenly manifests itself when a bean is added.
>>> If Camel fails to resolve the parameter you will still get an error.
>>> So if you type a mistake in either the parameter name or the key you
>>> get an exception (just using xxx as example)
>>>
>>>    file://inbox/?idempotent=true&xxxidempotentRepository=myJpaRepo
>>>    file://inbox/?idempotent=true&idempotentRepository=xxxmyJpaRepo
>>>
>>> In both situations you get an exception:
>>> 1) There are no properties on FileEndpoint that is named xxxidempotentRepository
>>> 2) There are no bean in the registry with the id xxxmyJpaRepo, and
>>> idempotentRepository has setter that accepts a String type, so the
>>> parameter is not successfully resolved
>>>
>>>
>> Sorry, I didn't read the patch.   I think I am a bit more clear now.
>> My comment is around 2).  Suppose my URI is:
>>   file://inbox/?idempotent=true&idempotentRepository=#oopsMadeATypoRepo
>> And because of my typo in the bean name, Camel can't find the bean
>> from the registry.   It then would precede with introspection and set
>> properties on the endpoint as before.   It won't succeed.  But,
>> instead of an error like "bean ref not found",  I may be getting some
>> error like "string cannot be assign to class XYZ".   I guess it is
>> really minor.  People rely on stack trace anyway.  :-)
>>
>>>>
>>>> So, if we make '#' a special character, I wonder we should provide a
>>>> way to escape the '#' character for users who do mean the literal
>>>> value.  That way, we don't need to try and error. The code can run a
>>>> bit faster.  The downside is, it can break existing configuration that
>>>> contains literal string value with '#' as the first character.
>>>>
>>>> Another thought is, we can consider putting the meta information in
>>>> the key of the query rather than in the value.
>>>>
>>>> For example, we put "bean:" in front of the key name as:
>>>>
>>>>    file://inbox/?idempotent=true&bean:idempotentRepository=myJpaRepo
>>>>
>>>> When we see "bean:" prefixing a key, then we treat myJpaRepo as bean
>>>> id.  If it can not be resolved, we will flag an error.  If "bean:" is
>>>> not there, the value is a string "myJpaRepo".  Since ':' is not a
>>>> valid Java variable name, we don't have to worry about "bean:"
>>>> clashing with key name.
>>>
>>> Yeah the bean: convention is also nice at it clearly highlights that
>>> it's a bean reference, and no problems if end users want a string
>>> literal starting with #.
>>>
>>> When I first thought of this I used the convetion that if the
>>> parameter name ended with Ref then it was a bean reference. So it
>>> should be:
>>>    file://inbox/?idempotent=true&idempotentRepositoryRef=myJpaRepo
>>>
>>> That is why currently we have the xxxRef options added manually on
>>> some of the components.
>>>
>>>
>>> However what do other frameworks do? I haven't seen a good convention
>>> for this. Maybe if we had a EL parser on top of the URI options? Using
>>> the simple syntax ${ }, could be supported:
>>>    file://inbox/?idempotent=true&idempotentRepository=${myJpaRepo}
>>>
>>> What does Spring 3.0 have on the roadmap?
>>>
>>>
>>> /Claus
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

Claus Ibsen-2
PS: I am fixing the spelling mistake in the exception:convertion
possbile => conversion possible

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Mon, Dec 8, 2008 at 8:09 AM, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> This is the exception you get
>
> #2
>            component.createEndpoint("foo://?special=#dummy");
> Note: This is for a unit test where I use Expression as the 'complex'
> object, and special as the parameter name:
>
> java.lang.IllegalArgumentException: Could not find a suitable setter
> for property: special as there isn't a setter method with same type:
> java.lang.String nor type convertion possbile: No type converter
> available to convert from type: class java.lang.String to the required
> type: org.apache.camel.Expression with value #dummy
>        at org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:217)
>
>
>
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
>
>
> On Mon, Dec 8, 2008 at 4:32 AM, William Tam <[hidden email]> wrote:
>> The '#' convention is simple and adopted by at least one other
>> framework (CXF).  +1
>>
>> On Sun, Dec 7, 2008 at 8:45 PM, William Tam <[hidden email]> wrote:
>>> On Sun, Dec 7, 2008 at 3:41 AM, Claus Ibsen <[hidden email]> wrote:
>>>> On Sat, Dec 6, 2008 at 8:50 PM, William Tam <[hidden email]> wrote:
>>>>> On Sat, Dec 6, 2008 at 8:25 AM, Claus Ibsen <[hidden email]> wrote:
>>>>>> On Sat, Dec 6, 2008 at 2:18 PM, Ramon Buckland <[hidden email]> wrote:
>>>>>>> +1 I like it.
>>>>>>>
>>>>>>> Would a feature such as auto-wiring be of any use also ?
>>>>>>> so .. uri="foo:something?autowire=byname"
>>>>>>>
>>>>>>> This way, any bean available it the context is then auto-wired in ?
>>>>>> Good idea. But is this autowire used much in pure spring? Personally I
>>>>>> have always used explicit wiring.
>>>>>>
>>>>>>>
>>>>>>> one other point, if #beanName is to be used, make sure the fallback of
>>>>>>> attempting to set the String '#someString' still works as it would be
>>>>>>> iritating if a #someString is needed but can't be because it is reserved for
>>>>>>> bean wiring.
>>>>>> Good catch. So if there is a String setter and NO bean in registry it
>>>>>> should fallback to set the string?
>>>>>> We do have options that support multiple types such as an expression
>>>>>> that can be string based and thus there is a setter that accepts a
>>>>>> String.
>>>>>> But we have overloaded the option with Expresison type as well. So we
>>>>>> should be lenient on the String settable options ;)
>>>>>>
>>>>>
>>>>> if we fails to resolve a bean because of user's typo, it may be more
>>>>> helpful to produce some descent error message than automatically
>>>>> assume the value is a literal String.  Another potential problem is
>>>>> the reverse scenario.  If the user means a literal string value, say
>>>>> "#abc", and "abc" happens to be a resolved bean id (the user may not
>>>>> know it), then the user won't be able to set the value to the literal
>>>>> value.  Imagine the user has tested the URI and everything is happy.
>>>>> The problem suddenly manifests itself when a bean is added.
>>>> If Camel fails to resolve the parameter you will still get an error.
>>>> So if you type a mistake in either the parameter name or the key you
>>>> get an exception (just using xxx as example)
>>>>
>>>>    file://inbox/?idempotent=true&xxxidempotentRepository=myJpaRepo
>>>>    file://inbox/?idempotent=true&idempotentRepository=xxxmyJpaRepo
>>>>
>>>> In both situations you get an exception:
>>>> 1) There are no properties on FileEndpoint that is named xxxidempotentRepository
>>>> 2) There are no bean in the registry with the id xxxmyJpaRepo, and
>>>> idempotentRepository has setter that accepts a String type, so the
>>>> parameter is not successfully resolved
>>>>
>>>>
>>> Sorry, I didn't read the patch.   I think I am a bit more clear now.
>>> My comment is around 2).  Suppose my URI is:
>>>   file://inbox/?idempotent=true&idempotentRepository=#oopsMadeATypoRepo
>>> And because of my typo in the bean name, Camel can't find the bean
>>> from the registry.   It then would precede with introspection and set
>>> properties on the endpoint as before.   It won't succeed.  But,
>>> instead of an error like "bean ref not found",  I may be getting some
>>> error like "string cannot be assign to class XYZ".   I guess it is
>>> really minor.  People rely on stack trace anyway.  :-)
>>>
>>>>>
>>>>> So, if we make '#' a special character, I wonder we should provide a
>>>>> way to escape the '#' character for users who do mean the literal
>>>>> value.  That way, we don't need to try and error. The code can run a
>>>>> bit faster.  The downside is, it can break existing configuration that
>>>>> contains literal string value with '#' as the first character.
>>>>>
>>>>> Another thought is, we can consider putting the meta information in
>>>>> the key of the query rather than in the value.
>>>>>
>>>>> For example, we put "bean:" in front of the key name as:
>>>>>
>>>>>    file://inbox/?idempotent=true&bean:idempotentRepository=myJpaRepo
>>>>>
>>>>> When we see "bean:" prefixing a key, then we treat myJpaRepo as bean
>>>>> id.  If it can not be resolved, we will flag an error.  If "bean:" is
>>>>> not there, the value is a string "myJpaRepo".  Since ':' is not a
>>>>> valid Java variable name, we don't have to worry about "bean:"
>>>>> clashing with key name.
>>>>
>>>> Yeah the bean: convention is also nice at it clearly highlights that
>>>> it's a bean reference, and no problems if end users want a string
>>>> literal starting with #.
>>>>
>>>> When I first thought of this I used the convetion that if the
>>>> parameter name ended with Ref then it was a bean reference. So it
>>>> should be:
>>>>    file://inbox/?idempotent=true&idempotentRepositoryRef=myJpaRepo
>>>>
>>>> That is why currently we have the xxxRef options added manually on
>>>> some of the components.
>>>>
>>>>
>>>> However what do other frameworks do? I haven't seen a good convention
>>>> for this. Maybe if we had a EL parser on top of the URI options? Using
>>>> the simple syntax ${ }, could be supported:
>>>>    file://inbox/?idempotent=true&idempotentRepository=${myJpaRepo}
>>>>
>>>> What does Spring 3.0 have on the roadmap?
>>>>
>>>>
>>>> /Claus
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

jstrachan
In reply to this post by Claus Ibsen-2
+1 I like it!


On 06/12/2008, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> For background see CAMEL-895 and this thread by James
> http://www.nabble.com/-2.0--simplifying-annotations%2C-DSL-and-XML-to-remove-uri-%2B-ref--tp20775864s22882p20775864.html
>
> Motivation
> =======
> Currently the URI configuration of camel endpoints is used a lot. It's
> fast, precise and intuitive for end-users. And it supports most of
> their use-cases.
> The URI options is given as string parameters just like http. Camel
> will then parse this and type convert and call the correct setter on
> the concrete xxxEndpoint object.
> Camel can do the traditional type converts for numeric, boolean,
> string, enum and what not. However the problem is...
>
> The problem
> =========
> That we can not set complex objects on endpoint using URI options.
> Each individual component need to add special code to support this and
> it's irritating me. Why can't we do it smarter.
> And if we do it smarter then we get this out-of-the-box so suddenly
> *all* components support this.
>
> The idea
> ======
> The idea is to support the # syntax for URI options (I think Apache
> CXF has this as well).
>
> So if you want to set a complex object type on a given endpoint you
> can refer to a bean in the registry using the # notation. An example:
>      file://inbox/?idempotent=true&idempotentRepository=#myJpaRepo
>
> Then end users can configure the myJapRepo in the Spring XML using
> standard spring bean ids.
>
> Benefits
> ======
> - It's easy for end users as they can look at the xxEndpoint and see
> which properties it has (setters). And they can use the # notation to
> set it for complex objects as well.
> - When you add options to an endpoint you get this notation for free,
> no need to add special code to the xxxComponent to do the lookup
> yourself
> - Even some options on default endpoints is now exposed and
> configurable, such as the executorService
> - We can reduce existing code
> - Easier for end users to understand that # is for regestry lookup
> instead of inventing our own custom names such as:
> idempotentRepositoryRef
> - And as a real bonus we don't have to wiki document the special
> options idempotentRepositoryRef. We get all this for free with # so we
> can just document the idempotentRepository option
>
> Any thoughts?
>
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>


--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

Claus Ibsen-2
I have committed it now.
It's the # notation that we can do in Camel 2.0. There might be a few
components that have special options to Ref a bean we can remove and
use the # syntax instead.

Updated wiki at: how do I configure endpoints. Are the other relevant
pages at wiki to add this?


/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Mon, Dec 8, 2008 at 11:56 AM,  <[hidden email]> wrote:

> +1 I like it!
>
>
> On 06/12/2008, Claus Ibsen <[hidden email]> wrote:
>> Hi
>>
>> For background see CAMEL-895 and this thread by James
>> http://www.nabble.com/-2.0--simplifying-annotations%2C-DSL-and-XML-to-remove-uri-%2B-ref--tp20775864s22882p20775864.html
>>
>> Motivation
>> =======
>> Currently the URI configuration of camel endpoints is used a lot. It's
>> fast, precise and intuitive for end-users. And it supports most of
>> their use-cases.
>> The URI options is given as string parameters just like http. Camel
>> will then parse this and type convert and call the correct setter on
>> the concrete xxxEndpoint object.
>> Camel can do the traditional type converts for numeric, boolean,
>> string, enum and what not. However the problem is...
>>
>> The problem
>> =========
>> That we can not set complex objects on endpoint using URI options.
>> Each individual component need to add special code to support this and
>> it's irritating me. Why can't we do it smarter.
>> And if we do it smarter then we get this out-of-the-box so suddenly
>> *all* components support this.
>>
>> The idea
>> ======
>> The idea is to support the # syntax for URI options (I think Apache
>> CXF has this as well).
>>
>> So if you want to set a complex object type on a given endpoint you
>> can refer to a bean in the registry using the # notation. An example:
>>      file://inbox/?idempotent=true&idempotentRepository=#myJpaRepo
>>
>> Then end users can configure the myJapRepo in the Spring XML using
>> standard spring bean ids.
>>
>> Benefits
>> ======
>> - It's easy for end users as they can look at the xxEndpoint and see
>> which properties it has (setters). And they can use the # notation to
>> set it for complex objects as well.
>> - When you add options to an endpoint you get this notation for free,
>> no need to add special code to the xxxComponent to do the lookup
>> yourself
>> - Even some options on default endpoints is now exposed and
>> configurable, such as the executorService
>> - We can reduce existing code
>> - Easier for end users to understand that # is for regestry lookup
>> instead of inventing our own custom names such as:
>> idempotentRepositoryRef
>> - And as a real bonus we don't have to wiki document the special
>> options idempotentRepositoryRef. We get all this for free with # so we
>> can just document the idempotentRepository option
>>
>> Any thoughts?
>>
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

Hiram Chirino
In reply to this post by Claus Ibsen-2
>>
>> When we see "bean:" prefixing a key, then we treat myJpaRepo as bean
>> id.  If it can not be resolved, we will flag an error.  If "bean:" is
>> not there, the value is a string "myJpaRepo".  Since ':' is not a
>> valid Java variable name, we don't have to worry about "bean:"
>> clashing with key name.
>
> Yeah the bean: convention is also nice at it clearly highlights that
> it's a bean reference, and no problems if end users want a string
> literal starting with #.
>
> When I first thought of this I used the convetion that if the
> parameter name ended with Ref then it was a bean reference. So it
> should be:
>    file://inbox/?idempotent=true&idempotentRepositoryRef=myJpaRepo
>
> That is why currently we have the xxxRef options added manually on
> some of the components.
>


I like where this is going.  My personal preference would be to use a
"key:ref=value" syntax.  That way you avoid the escaping issues with #
in the value and you avoid the property name clash issues with the
Property name.  Plus is reads nicely.

 example:
 file://inbox/?idempotent=true&idempotentRepository:ref=myJpaRepo

--
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options

Claus Ibsen-2
On Mon, Dec 8, 2008 at 7:56 PM, Hiram Chirino <[hidden email]> wrote:

>>>
>>> When we see "bean:" prefixing a key, then we treat myJpaRepo as bean
>>> id.  If it can not be resolved, we will flag an error.  If "bean:" is
>>> not there, the value is a string "myJpaRepo".  Since ':' is not a
>>> valid Java variable name, we don't have to worry about "bean:"
>>> clashing with key name.
>>
>> Yeah the bean: convention is also nice at it clearly highlights that
>> it's a bean reference, and no problems if end users want a string
>> literal starting with #.
>>
>> When I first thought of this I used the convetion that if the
>> parameter name ended with Ref then it was a bean reference. So it
>> should be:
>>    file://inbox/?idempotent=true&idempotentRepositoryRef=myJpaRepo
>>
>> That is why currently we have the xxxRef options added manually on
>> some of the components.
>>
>
>
> I like where this is going.  My personal preference would be to use a
> "key:ref=value" syntax.  That way you avoid the escaping issues with #
> in the value and you avoid the property name clash issues with the
> Property name.  Plus is reads nicely.
>
>  example:
>  file://inbox/?idempotent=true&idempotentRepository:ref=myJpaRepo
Yeah that is a nice idea as well. It's a variation of the xxxRef
syntax but much more clearly state this is a reference to both end
user can Camel as well. Using this Camel knows its 100% a reference
and can use mandatoryLookup as the bean should be there in the
registry.

BTW: The # escaping, in my point of view is not an issue. With the
current # syntax Camel will try to find a bean in the registry, and
only if there is:
- a bean found
- AND a setter on the endpoint with the given parameter type of the
bean, then it will call the setXXX method
        Example if there is such a method:
(setIdempotentRepository(IdempotentRepository repo)

- If NOT iIt fall backs to regular introspection properties setter
that will call the String setter with the #value.
        Example: If there is such a method:
(setIdempotentRepository(String repo)



>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>