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