[
https://issues.apache.org/jira/browse/CAMEL-11096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16004318#comment-16004318
]
Luca Burgazzoli commented on CAMEL-11096:
-----------------------------------------
I'm doing some experiments on CAMEL-11196 and this is a related topic.
About endpoints as today we have different elements in the json:
- endpointOptions
- endpointValues
- endpointOverrides
[~davsclaus] would it make sense to remove endpointOverrides and enhance
endpointValues with something like:
{code}
"endpointValues" : {
"operationName" : {
"value": "upsertSObject",
"readOnly" : true
},,
"sObjectIdName" : {
"required" : true
},
"synchronous" : {
"value": "false"
}
}
{code}
So:
- *operationName* value is set to upsertSObject and ca't be overridden
- *sObjectIdName* is required and no default value is provided
- *synchronous* has a default value but can be overridden
Same logic can be applied for componentOptions.
Thoughts ?
> Connector semantics with respect to default values
> --------------------------------------------------
>
> Key: CAMEL-11096
> URL: https://issues.apache.org/jira/browse/CAMEL-11096
> Project: Camel
> Issue Type: Task
> Components: camel-connector
> Affects Versions: 2.19.0
> Reporter: Roland Huss
> Priority: Minor
>
> I would like to discuss the semantics of default parameters for connectors.
> Currently a user can override 'frozen' (== pre-configured) component options
> when [creating the
> endpoint|https://github.com/apache/camel/blob/bc9d07700678604ae43754a32519898c47bb9529/connectors/camel-connector/src/main/java/org/apache/camel/component/connector/DefaultConnectorComponent.java#L261]
> I wonder whether this is the desired behaviour ? E.g. when creating a
> `salesforce-upsert-connector` and letting override the "operationName" (which
> was preconfigured in the connector) defeats its purpose imo. (Although it was
> just quite helpful in my case ;-)
> Of course the ideal solution would be to mark options as overridable or not.
> What do you think ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)