metadata for components, processors etc

[Tim Dudgeon <td...@gmail.com>]

Is there any mechanism for specifying metadata that describes what 
inputs and outputs components, processors ... can consume/produce.
I'm thinking of this from the perspective of a GUI builder tool that 
allows a route to be assembled so for this it's necessary to know which 
nodes are "compatible" with others. For instance if one produces bananas 
then it can't be directly piped into one that consumes oranges (of 
course TypeConverters need to be considered here).
For instance, is there an existing mechanism for providing @Consumes and 
@Produces annotations on components, processors etc.
Same question for routes, but I suspect that's much the same question.

Tim

Re: metadata for components, processors etc

[Claus Ibsen <cl...@gmail.com>]

Hi

Something like this
https://issues.apache.org/jira/browse/CAMEL-6543

On Mon, May 4, 2015 at 10:44 AM, Anton Hughes <ku...@gmail.com> wrote:
> Hi Claus
>
> Can you share the link to the jira? This sounds like a very interesting
> feature.
>
> On Fri, May 1, 2015 at 1:39 PM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> Hi
>>
>> No the components / endpoints dont provide meta-data what java types
>> and data formats they support. However we may get there in the longer
>> run. There is a JIRA ticket about this idea. And with the recent
>> component doc enhancements we have an instrument to provide the
>> details. So end users can annotate the endpoints with the details, and
>> then you can get that information at both design time for tooling, and
>> at runtime etc.
>>
>>
>> On Fri, May 1, 2015 at 9:35 AM, Tim Dudgeon <td...@gmail.com> wrote:
>> > Is there any mechanism for specifying metadata that describes what inputs
>> > and outputs components, processors ... can consume/produce.
>> > I'm thinking of this from the perspective of a GUI builder tool that
>> allows
>> > a route to be assembled so for this it's necessary to know which nodes
>> are
>> > "compatible" with others. For instance if one produces bananas then it
>> can't
>> > be directly piped into one that consumes oranges (of course
>> TypeConverters
>> > need to be considered here).
>> > For instance, is there an existing mechanism for providing @Consumes and
>> > @Produces annotations on components, processors etc.
>> > Same question for routes, but I suspect that's much the same question.
>> >
>> > Tim
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> Email: cibsen@redhat.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>> hawtio: http://hawt.io/
>> fabric8: http://fabric8.io/
>>



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/

Re: metadata for components, processors etc

[Anton Hughes <ku...@gmail.com>]

Hi Claus

Can you share the link to the jira? This sounds like a very interesting
feature.

On Fri, May 1, 2015 at 1:39 PM, Claus Ibsen <cl...@gmail.com> wrote:

> Hi
>
> No the components / endpoints dont provide meta-data what java types
> and data formats they support. However we may get there in the longer
> run. There is a JIRA ticket about this idea. And with the recent
> component doc enhancements we have an instrument to provide the
> details. So end users can annotate the endpoints with the details, and
> then you can get that information at both design time for tooling, and
> at runtime etc.
>
>
> On Fri, May 1, 2015 at 9:35 AM, Tim Dudgeon <td...@gmail.com> wrote:
> > Is there any mechanism for specifying metadata that describes what inputs
> > and outputs components, processors ... can consume/produce.
> > I'm thinking of this from the perspective of a GUI builder tool that
> allows
> > a route to be assembled so for this it's necessary to know which nodes
> are
> > "compatible" with others. For instance if one produces bananas then it
> can't
> > be directly piped into one that consumes oranges (of course
> TypeConverters
> > need to be considered here).
> > For instance, is there an existing mechanism for providing @Consumes and
> > @Produces annotations on components, processors etc.
> > Same question for routes, but I suspect that's much the same question.
> >
> > Tim
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

Re: metadata for components, processors etc

[Claus Ibsen <cl...@gmail.com>]

Hi

No the components / endpoints dont provide meta-data what java types
and data formats they support. However we may get there in the longer
run. There is a JIRA ticket about this idea. And with the recent
component doc enhancements we have an instrument to provide the
details. So end users can annotate the endpoints with the details, and
then you can get that information at both design time for tooling, and
at runtime etc.


On Fri, May 1, 2015 at 9:35 AM, Tim Dudgeon <td...@gmail.com> wrote:
> Is there any mechanism for specifying metadata that describes what inputs
> and outputs components, processors ... can consume/produce.
> I'm thinking of this from the perspective of a GUI builder tool that allows
> a route to be assembled so for this it's necessary to know which nodes are
> "compatible" with others. For instance if one produces bananas then it can't
> be directly piped into one that consumes oranges (of course TypeConverters
> need to be considered here).
> For instance, is there an existing mechanism for providing @Consumes and
> @Produces annotations on components, processors etc.
> Same question for routes, but I suspect that's much the same question.
>
> Tim



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/