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

Luca Burgazzoli edited comment on CAMEL-10031 at 5/9/17 7:01 AM:
-----------------------------------------------------------------

Would it make sense to have an hook on the component to inject an "endpoint 
options processor" ? Because not all the endpoints have a getter/setter for the 
options (most of the new component have a configuration class instead) the auto 
configuration task may not be trivial.

As far as I remember there was  also a discussion on how to assign an id to an 
endpoint and if we can make that we can do something like:

{code:java}
from("ftp://bar@myserver/path?id=test";)
  .to("...")
{code}

{code:java}
// Defaults for all the endpoints
camel.component.ftp.endpoint.password = secret

// Use the dot notation for maps as the [] may not work
// in some properties back-end (i.e. k8s' configmaps/secrets)
camel.component.ftp.endpoints.test.password = secret
{code}

The hook (which is added by spring-boot auto configuration) will then inspect 
the components option for an id field and adds the options from spring-boot 
related to such id. If no id is found the hook can maybe enrich the parameters 
map with default values i.e. from camel.component.ftp.endpoint.

For xml we can leverage the id on the element.
 
The hook may be triggered between:
{code:java} Endpoint createEndpoint(String uri) {code}

And:
{code:java} Endpoint createEndpoint(String uri, String remaining, 
Map<String,Object> parameters) {code}

An interesting side effect of this implementation is that secrets like username 
and password may be provided by the vault back-end or i.e. kubernetes secrets 
for application that have spring-cloud-kubernetes without requiring to create 
the endpoints outside the route.


was (Author: lb):
Would it make sense to have an hook on the component to inject an "endpoint 
options processor" ? Because not all the endpoints have a getter/setter for the 
options (most of the new component have a configuration class instead) the auto 
configuration task may not be trivial.

As far as I remember there was  also a discussion on how to assign an id to an 
endpoint and if we can make that we can do something like:

{code:java}
from("ftp://bar@myserver/path?id=test";)
  .to("...")
{code}

{code:java}
// Use the dot notation for maps as the [] may not work
// in some properties back-end (i.e. k8s' configmaps/secrets)
camel.component.ftp.endpoints.test..password = secret
{code}

The hook (which is added by spring-boot auto configuration) will then inspect 
the components option for an id field and adds the options from spring-boot 
related to such id.
For xml we can leverage the id on the element.
 
The hook may be triggered between:
{code:java} Endpoint createEndpoint(String uri) {code}

And:
{code:java} Endpoint createEndpoint(String uri, String remaining, 
Map<String,Object> parameters) {code}

An interesting side effect of this implementation is that secrets like username 
and password may be provided by the vault back-end or i.e. kubernetes secrets 
for application that have spring-cloud-kubernetes without requiring to create 
the endpoints outside the route.

> camel-spring-boot - Add endpoint options as type-safe configuration properties
> ------------------------------------------------------------------------------
>
>                 Key: CAMEL-10031
>                 URL: https://issues.apache.org/jira/browse/CAMEL-10031
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-spring-boot
>            Reporter: Claus Ibsen
>            Assignee: Nicola Ferraro
>
> See CAMEL-9419.
> We can now configure this for all the components. But for endpoints its a bit 
> more as you can have many endpoints with different configuration.
> So either you assign an id to the endpoint you configure, and then need to 
> refer to the endpoint by id, in the camel routes. Or we figure out something 
> else. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to