[
https://issues.apache.org/jira/browse/CAMEL-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078645#comment-13078645
]
Claus Ibsen commented on CAMEL-4256:
------------------------------------
I would suggest to start a [DISCUSS] on dev about this. It seems there is a
more broad perspective to this. For example you can configure EIPs, components,
endpoints, consumers, producers, data formats, etc. So we may want to take the
time to look into a long term and more general solution.
Also for 3rd party component developers its been so easy so far, as all they
have to care about is Component, Endpoint, and Producer/Consumer. So we should
ensure it still is dead simple to create custom components. I would really
dislike if any API changes causes this to be more complicated.
> 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
