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