Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: =?iso-8859-2?Q?=A3ukasz_Dywicki?= <luke@code-house.org>
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_7905F1B1-A1A2-4C5A-860A-40A9E0AB4E26"
Subject: Re: [DISCUSS] Should camel enforce usage of proper URIs?
Date: Wed, 20 Jun 2012 10:22:32 +0200
In-Reply-To: <8268579648358125089@unknownmsgid>
To: dev@camel.apache.org
References: <4FD60168.5090009@gmail.com>
 <0C5DF527-A2CC-442B-911C-25020791607D@code-house.org>
 <CADHGh9WL7oy3yUJGFXEKQEE+SjDext7zocz4-Oa6kV0GjPNx3Q@mail.gmail.com>
 <8268579648358125089@unknownmsgid>
Message-Id: <F4C1792D-9C69-4F6F-98FE-3787469B3829@code-house.org>

--Apple-Mail=_7905F1B1-A1A2-4C5A-860A-40A9E0AB4E26
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-2

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=B6=E6 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
> ;)
>=20
> Endpoint options can be applicable to producers, consumers or both.
>=20
> 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.
>=20
> 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.
>=20
> We can then add some automatic validation logic and reporting based on
> the annotations.
>=20
> WDYT?
>=20
> Ra=FAl.
>=20
> On 19 Jun 2012, at 22:08, Ioannis Canellos <iocanel@gmail.com> wrote:
>=20
>> Do we have a brief estimate of how many components do not use clean =
URIs?
>>=20
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource <http://fusesource.com>
>>=20
>> **
>> Blog: http://iocanel.blogspot.com
>> **
>> Twitter: iocanel
>> *


--Apple-Mail=_7905F1B1-A1A2-4C5A-860A-40A9E0AB4E26--