Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Thu, 19 Apr 2012 10:04:42 +0000 (UTC)
From: =?utf-8?Q?=C5=81ukasz_Dywicki_=28Updated=29_=28JIRA=29?=
 <jira@apache.org>
To: issues@camel.apache.org
Message-ID: 
 <1353209421.5563.1334829882963.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (CAMEL-4256) Adding a EndpointConfiguration
 interface
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/CAMEL-4256?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

=C5=81ukasz Dywicki updated CAMEL-4256:
----------------------------------

    Attachment: CAMEL-4256-core.diff

Small changes in EndpointConfiguration interface. Usage of IntrospectionSup=
port in ConfigurationHelper. New constructor for DefaultEndpoint.
               =20
> Adding a EndpointConfiguration interface
> ----------------------------------------
>
>                 Key: CAMEL-4256
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4256
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-core
>    Affects Versions: 2.8.0
>            Reporter: Hadrian Zbarcea
>            Assignee: Hadrian Zbarcea
>             Fix For: 2.9.3
>
>         Attachments: CAMEL-4256-2.patch, CAMEL-4256-core.diff, CAMEL-4256=
-test.diff, camel-4256.patch
>
>
> One of the key missing pieces from the API is the explicit concept of End=
pointConfiguration. We use URIs for that, ant that's great, but we don't ha=
ve it in the API. Some components do have an informal version though.
> I am proposing adding an EndpointConfiguration interface:
> {code}
> public interface EndpointConfiguration {
>   void fromUri(String uri);
>   String toUri();
> }
> {code}
> and maybe other methods, we could also use URI instead of string for pre-=
parsing. Same as with other concepts the default implementation would be in=
 impl and components would extend that and add fields for configuration par=
ameters.=20
> This would solve problems related to URI uniqueness to a good extent as t=
oUri() should always place parameters in the same order. The Endpoint inter=
face would change though.
> The main advantage would be that we can annotate parameters and use javax=
.validation to specify if a field is @ProducerOnly, @ConsumerOnly for examp=
le, which may exclude them from toUri() (yes, there are some impacts, the i=
d uri would be different than the config uric). We could annotate them with=
 @Secret to indicate that at least the value should not appear in clear in =
the uri, etc. We could also add an @Default("value"), allowing us to exclud=
e from the uri fields set on the default value (even if the filed was expli=
citly set) and so on.
> This would also make static validation possible unit testing configuratio=
n would be vastly simplified and we could improve coverage. We can do it in=
 an incremental way without a big impact on existing components (especially=
 outside camel) via changes in DefaultEndpoint. I am working on a prototype=
, but feedback is highly appreciated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira