camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Tam" <email.w...@gmail.com>
Subject Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options
Date Mon, 08 Dec 2008 01:45:52 GMT
On Sun, Dec 7, 2008 at 3:41 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
> On Sat, Dec 6, 2008 at 8:50 PM, William Tam <email.wtam@gmail.com> wrote:
>> On Sat, Dec 6, 2008 at 8:25 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>>> On Sat, Dec 6, 2008 at 2:18 PM, Ramon Buckland <ramon@thebuckland.com>
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
>

Mime
View raw message