[
https://issues.apache.org/jira/browse/CAMEL-11132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131873#comment-18131873
]
Claus Ibsen commented on CAMEL-11132:
-------------------------------------
Done by CAMEL-24961 for 4.24.0: the Camel catalog has body types (the bodyTypes
section) for every component, data format and language. Each says the Java
carrier and the format of the body a step needs and leaves, per side (consumer,
producer, marshal, unmarshal, expression), and how options change it.
CAMEL-25928 adds them for the EIPs and the data type transformers. The
component, data format and language pages show them in a Message Body section,
and the YAML validator and the Camel CLI tools read them. See the Message Body
Types page of the user manual (body-types.adoc).
_Claude Code on behalf of davsclaus_
> Provide type metadata for each Components/DataFormats
> -----------------------------------------------------
>
> Key: CAMEL-11132
> URL: https://issues.apache.org/jira/browse/CAMEL-11132
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Reporter: Tomohisa Igarashi
> Assignee: Tomohisa Igarashi
> Priority: Major
> Fix For: 4.24.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
(v10.3.26#10030026)
