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: About Component options, where and how
Date Mon, 08 Dec 2008 17:14:24 GMT
Hi James

You newest commits on the camel-jms component does excactly what I
kinda want as well. You exposed all the options from the
JmsConfiguration as getter/setters on the jms endpoint. This allows as
you have shown in the spring xml sample to let end users configure the
endpoint using pure spring XML.

What I would like to add is the 3 options we have for the scheduled
poll consumer:
- initial delay
- delay
- and another I cant remember

So you can configure these as well using the same spring XML syntax as
you sample.

So what you have done and what I was trying to write is more or less
the going for the same goal.


/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Mon, Dec 8, 2008 at 3:41 PM, James Strachan <james.strachan@gmail.com> wrote:
> 2008/12/8 Claus Ibsen <claus.ibsen@gmail.com>:
>> Hi
>>
>> I am starting to conclude that I prefer to have all options a given
>> endpoint supports defined on the endpoint itself with getter/setters.
>>
>> Pros
>> ===
>> - One place to look what a endpoint/component supports
>> - End user can instantiate an endpoint using: URI options, Manual in
>> Java Code and use setters, Spring XML syntax as plain spring bean id,
>> etc. etc.
>> - Camel can automatic create consumers and producers for routes even
>> for endpoints defined by end user manually
>> - We can get rid of the consumer. prefix that you need to use for
>> delay that is confusing
>> - And more cumbersome to code with as we have options in several classes
>> - End user doesn't need to mess with manual java code to set option
>> that today must be set on the consumer manually, if he manually
>> creates the endpoint also
>> - Endpoint URI's is smaller as consumer. prefix should not be used
>>
>> Cons
>> ====
>> - Will break backwards compability if we move options from consumer to
>> endpoint (do not use consumer.) prefix
>>
>> We have a few tickets to improve/more ease the configuration of
>> endpoints, created by James. To allow end users to create endpoints
>> and configure/wire them in spring XML is what they are used to.
>>
>> Sadly some of the components I have messed with during my committer
>> carer has this flaw with mixed options, and even some options is not
>> visible at all from getter/setters (mina springs to my mind).
>>
>> So I wanted to remedy this as a big task for Camel 2.0, but want to
>> have the feedback from the other Camel riders and the community as
>> well.
>
> I do generally like having all the configuration on the endpoint
> (maybe allowing folks to override it on a producer/consumer if they
> really really need to). Its just lots easier that way. I kinda like
> having configuration flow down from
>
> component -> endpoint -> producer/consumer
>
> as you can then just configure, say, the JMS component then have loads
> of endpoints/producers/consumers not needing zillions of
> configuration.
>
> The downside I guess is that its not immediately obvious what
> properties are used for producers and what are consumers; but then
> thats where documentation comes in I guess?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

Mime
View raw message