Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Mon, 8 May 2017 14:56:04 +0000 (UTC)
From: "Luca Burgazzoli (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: <JIRA.13066357.1493043777000.152257.1494255364642@Atlassian.JIRA>
In-Reply-To: <JIRA.13066357.1493043777000@Atlassian.JIRA>
References: <JIRA.13066357.1493043777000@Atlassian.JIRA> <JIRA.13066357.1493043777144@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (CAMEL-11196) Camel connectors - Allow to
 configure in one place and let it figure out component vs endpoint level
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 08 May 2017 14:56:10 -0000


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

Luca Burgazzoli edited comment on CAMEL-11196 at 5/8/17 2:55 PM:
-----------------------------------------------------------------

We may generate something like:

{code}
component.component-name.option1 = default-option-1
component.component-name.option2 = default-option-2
component.component-name.configuration[my-component].my-option2 = not-default-anymore
{code}

Then the spring boot auto-configuration would:

- register and configure the component with ``component-name`` component as usual 
- register and configure number of bean according to the configuration map of the same type of the ``component-name`` but regitered with a different name so that they can be referenced by name as usual but with properties inherited from component-name (or maybe not) 

Of course the drawback is that the [my-component] won't get auto-completed y IDEs but this solution would give a good flexibility and you can get the name of the supported parameters, theirs default and the doc from the root configuration.
 

was (Author: lb):
We may generate something like:

{code}
component.component-name.option1 = default-option-1
component.component-name. = default-option-2
component.component-name.configuration[my-component].my-option2 = not-default-anymore
{code}

Then the spring boot auto-configuration would:

- register and configure the component with ``component-name`` component as usual 
- register and configure number of bean according to the configuration map of the same type of the ``component-name`` but regitered with a different name so that they can be referenced by name as usual but with properties inherited from component-name (or maybe not) 

Of course the drawback is that the [my-component] won't get auto-completed y IDEs but this solution would give a good flexibility and you can get the name of the supported parameters, theirs default and the doc from the root configuration.
 

> Camel connectors - Allow to configure in one place and let it figure out component vs endpoint level
> ----------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-11196
>                 URL: https://issues.apache.org/jira/browse/CAMEL-11196
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-connector
>            Reporter: Claus Ibsen
>             Fix For: 2.20.0
>
>
> A Camel connector can be configured on two levels
> - component
> - endpoint
> Just like a regular Camel component.
> But we should allow users to configure a connector in one place, and not worry about if its component or endpoint level. And then let camel-connector when it prepares the connector figure out all of this for you.
> This may require supporting loading configuration from external resource files such as .properties files etc. Or something else. But from end users we can make this easier.


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