camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Tam" <>
Subject Re: [PROPOSAL] - Camel 2.0 - support # syntax in URI options
Date Sat, 06 Dec 2008 19:50:32 GMT
On Sat, Dec 6, 2008 at 8:25 AM, Claus Ibsen <> wrote:
> On Sat, Dec 6, 2008 at 2:18 PM, Ramon Buckland <> 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.

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:


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.

>> r.
>> On Sun, Dec 7, 2008 at 00:08, Claus Ibsen <> wrote:
>>> Hi
>>> For background see CAMEL-895 and this thread by James
>>> Motivation
>>> =======
>>> Currently the URI configuration of camel endpoints is used a lot. It's
>>> fast, precise and intuitive for end-users. And it supports most of
>>> their use-cases.
>>> The URI options is given as string parameters just like http. Camel
>>> will then parse this and type convert and call the correct setter on
>>> the concrete xxxEndpoint object.
>>> Camel can do the traditional type converts for numeric, boolean,
>>> string, enum and what not. However the problem is...
>>> The problem
>>> =========
>>> That we can not set complex objects on endpoint using URI options.
>>> Each individual component need to add special code to support this and
>>> it's irritating me. Why can't we do it smarter.
>>> And if we do it smarter then we get this out-of-the-box so suddenly
>>> *all* components support this.
>>> The idea
>>> ======
>>> The idea is to support the # syntax for URI options (I think Apache
>>> CXF has this as well).
>>> So if you want to set a complex object type on a given endpoint you
>>> can refer to a bean in the registry using the # notation. An example:
>>>     file://inbox/?idempotent=true&idempotentRepository=#myJpaRepo
>>> Then end users can configure the myJapRepo in the Spring XML using
>>> standard spring bean ids.
>>> Benefits
>>> ======
>>> - It's easy for end users as they can look at the xxEndpoint and see
>>> which properties it has (setters). And they can use the # notation to
>>> set it for complex objects as well.
>>> - When you add options to an endpoint you get this notation for free,
>>> no need to add special code to the xxxComponent to do the lookup
>>> yourself
>>> - Even some options on default endpoints is now exposed and
>>> configurable, such as the executorService
>>> - We can reduce existing code
>>> - Easier for end users to understand that # is for regestry lookup
>>> instead of inventing our own custom names such as:
>>> idempotentRepositoryRef
>>> - And as a real bonus we don't have to wiki document the special
>>> options idempotentRepositoryRef. We get all this for free with # so we
>>> can just document the idempotentRepository option
>>> Any thoughts?
>>> /Claus Ibsen
>>> Apache Camel Committer
>>> Blog:

View raw message