About Component options, where and how

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

About Component options, where and how

Claus Ibsen-2
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.




/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: About Component options, where and how

jstrachan
2008/12/8 Claus Ibsen <[hidden email]>:

> 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/
Reply | Threaded
Open this post in threaded view
|

Re: About Component options, where and how

Claus Ibsen-2
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 <[hidden email]> wrote:

> 2008/12/8 Claus Ibsen <[hidden email]>:
>> 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/
>