[
https://issues.apache.org/jira/browse/CAMEL-11132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16067071#comment-16067071
]
Dhiraj Bokde commented on CAMEL-11132:
--------------------------------------
Will this support dynamic discovery of types at runtime? Salesforce allows
users to define custom relational tables, which means that objects supported by
the component are dependent on user's salesforce instance. Even Salesforce
defined default objects can be customized to add user defined fields. There can
even be differences in schema depending on the underlying Salesforce version.
So runtime discovery of schema is critical for Salesforce. At present this is
supported using a camel-salesforce-maven-plugin which generates POJO classes
from Salesforce schema. There are open issues for adding support for generating
json schema and handling simple json strings as input/output fields.
> Provide type metadata for each Components/DataFormats
> -----------------------------------------------------
>
> Key: CAMEL-11132
> URL: https://issues.apache.org/jira/browse/CAMEL-11132
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Tomohisa Igarashi
> Assignee: Tomohisa Igarashi
> Fix For: 2.20.0
>
>
> CAMEL-10447 has introduced InputType/OutputType declaration and declarative
> Transformer/Validator based on those types declared on a route.
> Next step is to provide type metadata for each Components/DataFormats:
> * Let components/DataFormats provide metadata about what data types are
> supported so that app developer can see
> * Narrow down the possible data types (i.e. exclude unsupported types) and
> transformers when writing a route in IDE, allow IDE to show those candidates
> as a hint so that app developer can choose from. Also maven plugin could
> leverage those metadata
> * Provide such facility from camel side so that the maven plugin and/or IDE
> can leverage it
> Annotation would be an option, but it only provides static types. For example
> xslt component only consumes/produces XML so "XML" could be provided via
> annotation. But dozer component consumes/produces arbitrary data formats and
> the actual type to be used is determined via configuration, so it cannot be
> provided via annotation. It would need a common way to calculate possible
> input types and output types on a component/endpoint and dataformat from its
> configuration.
> Sometimes even body of the input message would affect the possible output
> types. To visualize this we'll need some kind of simulation with a test
> message.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
