[
https://issues.apache.org/jira/browse/CAMEL-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114592#comment-13114592
]
james strachan commented on CAMEL-4256:
---------------------------------------
Endpoints are already beans you can configure yourself using Spring, Guice,
CDI, Java code or whatever and wire them into a CamelContext.
Dependency injection frameworks can already configure Endpoints today. No need
for a new magic interface and yet more work for component/endpoint developers
to have to create (which can soon get out of sync with the actual
implementation code).
Tools can use introspection already to figure out how to configure an Endpoint.
Just check out how Spring does this or tools based around Spring.
There could be some added annotations we could use to make it easier to add
extra metadata to tools; though where possible I think its better for the
community to stick to standards that exist around DI (CDI / Spring / Guice) or
around things like the Bean Validation Framework for adding things like min/max
validation annotations. Those annotations are already well defined - lets not
try reinvent DI / validation wheels.
http://jcp.org/en/jsr/detail?id=303
I'd say tools either go the URL option, or go the bean configuration option
using (say) spring/guice/CDI. The URI is always going to be a subset of the
actual configuration; if you really want to support full endpoint configuration
then the only real option is the full DI route; as there are things you can
configure though DI tooling you can't through URIs.
In terms of the EndpointConfiguration interface, fromUri() makes no sense -
since that is what a Component does. (Its really its main responsibility).
There's no point forcing implementors to do the same thing twice in 2 separate
APIs.
In terms of toUri() for an Endpoint; this is of dubious value IMHO; since its
easily possible to create an Endpoint, configure it and then not be able to
create a URI which truly reflects the configuration. Its way too easy to loose
information; so why even bother trying to turn an Endpoint bean back into a
URI? Just use the Endpoint object directly. Taking an Endpoint bean thats been
configured somehow and turning it back into a URI just seems to be asking for
trouble - when there's no real need to do that - just reuse the Endpoint object
as is.
> 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
