[
https://issues.apache.org/jira/browse/CAMEL-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115331#comment-13115331
]
Claus Ibsen commented on CAMEL-4256:
------------------------------------
I can see from one point a value in a light weight POJO configuration class.
However as James also says, ppl can configure endpoints in any way they like
- uris
- IoC
- Java code with new XXX and then invoke the appropriate setters
- etc.
And I guess there are situations where you cannot fully configure using uris
solely. However I guess 95%+ currently can.
And most end users use uri configurations as of today.
If every Endpoint have a default no-arg ctr, then you could also consider the
endpoint as a POJO, which have getter/setter for all the options it support.
And thus also from a tooling point of view, it would be just as easy to
configure, as a xxxConfiguration class would be. Creating an Endpoint using a
default no-arg ctr, will of course not cause the Endpoint to be enlisted in
registry and whatnot. And since its not started using start() it does not have
side-effects.
Some of the Camel components have a configuration POJO such as the
JmsConfiguration, MailConfiguration etc. The latter has a clone() which is
needed when people can overlay default configurations by overriding options in
endpoint uris. So each endpoint need to clone the default xxxConfiguration. And
then set the options from the endpoint uri. This allows people to configure
default configuration on the xxxComponent, and then still be able to adjust by
overriding in endpoint uris.
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
