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