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 <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 7, 2008 at 3:41 AM, Claus Ibsen <[EMAIL PROTECTED]> wrote:
>> On Sat, Dec 6, 2008 at 8:50 PM, William Tam <[EMAIL PROTECTED]> wrote:
>>> On Sat, Dec 6, 2008 at 8:25 AM, Claus Ibsen <[EMAIL PROTECTED]> wrote:
>>>> On Sat, Dec 6, 2008 at 2:18 PM, Ramon Buckland <[EMAIL PROTECTED]> 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
>>
>
