Lack of separation between consumer and producer configuration is really hard. Many of Configuration objects we have is one big bag with properties. Some of them are exclusive or similar and should not be set at the same type, eg. replyTo and replyToType in JmsConfiguration. Most of properties are not documented in code so for every property users must visit camel page to check what it does. For example with bean validation there is possibility to create groups of fields and valid against given group (Component, Producer or Consumer interface can be a group discriminator).
I can imagine also situation when we extend JSR 303 for conditional expressions (eg using simple dialect to don't bring additional dependencies) to check if there is no collision in properties set by user. Best regards, Lukasz Dywicki -- Code-House http://code-house.org Wiadomość napisana przez Raul Kripalani w dniu 20 cze 2012, o godz. 00:46: > I know that the discussion at hand is not exactly related to what I'm > going to propose. But I'll blurt out my idea just to enrich the debate > ;) > > Endpoint options can be applicable to producers, consumers or both. > > Currently, the validation of the applicability is done in code - if > lucky. I even luckier, the component page will tag options according > to what they are applicable to. Unfortunately, it's not always the > case. Look at camel-jms for instance. > > I suggest that we add annotations to the API to decorate the fields > representing the options in the Endpoint class, to indicate what they > are applicable to. > > We can then add some automatic validation logic and reporting based on > the annotations. > > WDYT? > > Raúl. > > On 19 Jun 2012, at 22:08, Ioannis Canellos <ioca...@gmail.com> wrote: > >> Do we have a brief estimate of how many components do not use clean URIs? >> >> -- >> *Ioannis Canellos* >> * >> FuseSource <http://fusesource.com> >> >> ** >> Blog: http://iocanel.blogspot.com >> ** >> Twitter: iocanel >> *
