[ 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