camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen" <claus.ib...@gmail.com>
Subject Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options
Date Mon, 08 Dec 2008 07:20:31 GMT
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 <claus.ibsen@gmail.com> 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 <email.wtam@gmail.com> 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 <email.wtam@gmail.com> wrote:
>>> 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