[
https://issues.apache.org/jira/browse/CAMEL-17608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488078#comment-17488078
]
Zoran Regvart commented on CAMEL-17608:
---------------------------------------
Yeah, if folk provide the {{sObjectName}} that should be taken as is and
override the name derived from the body. It does change the behavior from what
we do for a long time, but I don't think it breaks the backward compatibility
for most folks as they would either use {{sObjectName}} or they would rely on
the class name; if both are specified and they differ this will, most likely,
break for folk, so it might be a good idea to either throw an exception or log
a warning. I suspect the logic as it stands today is in a number places so
changing this we'd need to be a bit careful to stay consistent.
> camel-salesforce: allow overriding sobject name when using DTOs
> ---------------------------------------------------------------
>
> Key: CAMEL-17608
> URL: https://issues.apache.org/jira/browse/CAMEL-17608
> Project: Camel
> Issue Type: Improvement
> Components: camel-salesforce
> Affects Versions: 3.15.0
> Reporter: Jeremy Ross
> Priority: Major
>
> When subclasses of the generated DTOs are used, Camel uses the name of the
> subclass as the sobject name, which won't work. Also, because instanceof
> check passes, camel ignores the sObjectName option. The solution would be for
> Camel to always honor the sObjectName option.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
