camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <>
Subject Re: [DISCUSS] Should camel enforce usage of proper URIs?
Date Wed, 20 Jun 2012 08:22:32 GMT
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

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.
> Raúl.
> On 19 Jun 2012, at 22:08, Ioannis Canellos <> wrote:
>> Do we have a brief estimate of how many components do not use clean URIs?
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource <>
>> **
>> Blog:
>> **
>> Twitter: iocanel
>> *

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message