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
>
> 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
