Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Mon, 26 Sep 2011 11:10:26 +0000 (UTC)
From: "Claus Ibsen (JIRA)" <jira@apache.org>
To: dev@camel.apache.org
Message-ID: 
 <165812986.12253.1317035426946.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1984365177.11916.1311264237942.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CAMEL-4256) Adding a EndpointConfiguration
 interface
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CAMEL-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114596#comment-13114596 ] 

Claus Ibsen commented on CAMEL-4256:
------------------------------------

{quote}
@Claus, this is a good place to discuss. Add your comments and suggestions here. This solution is backwards compatible and changes nothing for 3rd party components (already developed or not). It solves a couple of problems and introduces the validation feature. How would you make it more general?
{quote}

The code which is committed is not backwards compatible.

> 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.0, 3.0.0
>
>         Attachments: camel-4256.patch
>
>
> One of the key missing pieces from the API is the explicit concept of EndpointConfiguration. We use URIs for that, ant that's great, but we don't have 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 parameters. 
> This would solve problems related to URI uniqueness to a good extent as toUri() should always place parameters in the same order. The Endpoint interface 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 example, which may exclude them from toUri() (yes, there are some impacts, the id 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 exclude from the uri fields set on the default value (even if the filed was explicitly set) and so on.
> This would also make static validation possible unit testing configuration 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira