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