[ 
https://issues.apache.org/jira/browse/CAMEL-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Grzybek reassigned CAMEL-6543:
---------------------------------------

    Assignee: Grzegorz Grzybek

> provide a way to expose common header names, types and payload types for 
> endpoints
> ----------------------------------------------------------------------------------
>
>                 Key: CAMEL-6543
>                 URL: https://issues.apache.org/jira/browse/CAMEL-6543
>             Project: Camel
>          Issue Type: Improvement
>            Reporter: james strachan
>            Assignee: Grzegorz Grzybek
>
> Given a configuration of an Endpoint, it'd be nice if there was a way for 
> endpoints to expose what a consumer will receive up front (at design time, 
> before it actually runs), in terms of headers (their name & types) and the 
> payload type.
> Most of this is documented on the wiki in places already - its useful stuff 
> to konw; but there's no way to introspect an endpoint and know this (so we 
> can, for example, visualise the things exposed by an endpoint - or provide 
> better validation of what can connect to what, what will work or fail; what 
> type conversions could be done after consuming from an endpoint, what headers 
> are available by default in expression languages and so forth.
> I guess other steps in a camel flow can change this data too (e.g. 
> adding/removing headers, changing the payload value).
> But as a start - and endpoint consumer specific plugin would be great.
> e.g. maybe we can add a new method to ComponentConfiguration which allows 
> endpoints to return the header/payload metadata (if its known)
> https://cwiki.apache.org/confluence/display/CAMEL/ComponentConfiguration
> We could maybe add some annotations, metadata or code which could then be 
> introspected by the generated endpoint documentation:
> https://cwiki.apache.org/confluence/display/CAMEL/Endpoint+Annotations
> afterall we often define constants for the header values already for a 
> component; so it would be easy to add an annotation and have them discovered; 
> its mostly just being able to find all the headers exposed by default (and 
> which are optional I guess) on messages from an endpoint.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to