[GitHub] camel pull request #1167: CAMEL-10308

[tivv]

Github user tivv closed the pull request at:

https://github.com/apache/camel/pull/1167


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Adding type awareness in Camel route

[Tomohisa Igarashi]

Hi Claus,

Thanks for the reply. Sure that's fine, I agree 3.0 would be better to be 
targeted than 2.x as this introduces some schema updates.

Including this one, I'm always looking for the chance to make any contribution 
to Camel. If there's anything I can help please let me know.

Thanks,
Tomo

On 09/17/2016 06:33 PM, Claus Ibsen wrote:

Hey

Can we take this discussion post Camel 2.18 release.

We are working on the last details to get it ready, and its our main
focus to get this new release out.

After this release we will pickup talks about the next releases
whether that is 2.19 or 3.0, and for the latter what the broad goals
of that is. What you talk about seems more of a 3.0 candidate to me,
than on 2.x.



On Fri, Sep 16, 2016 at 6:50 AM, Tomohisa Igarashi
 wrote:

Hi Camel developers,

I'd like to propose an enhancement on handling data types of Camel message
contents. To start a smooth discussion I implemented the idea first:
https://github.com/igarashitm/camel/tree/contract-based-type-awareness

And these testcases demonstrates the declarative transformer usage according
to the declared data types:
[Java DSL]
https://github.com/igarashitm/camel/commit/498c27d2ba99b04bbe7b90a93329d42b7c718a29#diff-c14a7e8e88a6e41492946e1537bfb1cf
[Spring DSL]
https://github.com/igarashitm/camel/commit/498c27d2ba99b04bbe7b90a93329d42b7c718a29#diff-b2506c84ddde91438fc6374039e21534

This adds input/output content type declaration on from and all other
processors. It also introduces well-known Exchange properties, INPUT_TYPE
and OUTPUT_TYPE which are used to specify the current message content type.
The data type is URN like string starts with scheme, like
java:org.example.ItemA or xml:{org.example.xml}ItemA.

If the content type is declared via inputType/outputType/contract, the
ContractProcessor wraps the actual processor and process
transformation/validation according to the type, say if INPUT_TYPE exchange
property has xml:{org.example.xml}ItemA and the declared inputType is
xml:{org.example.xml}ItemB, then it transforms xml:{org.example.xml}ItemA
content into xml:{org.example.xml}ItemB. The  element which is
introduced right under the  is the one to declare the mappings
between transformer implementation and those from/to data type. I
implemented only transformer first, but validator would be brought in in a
same way. This way allows users to make data types visible in the route
definition and keep the transformation/validation apart from route
definition itself.

The most important thing is that the ContractProcessor is involved only when
content type is explicitly declared in a route definition, so that it never
breaks existing camel routes. Ofcourse programatic
transformations/validations we're doing today are still fully available.
It's purely an addition to the existing camel features.

Any thoughts? Does it sound acceptable to get merged into camel? ANY
feedback would be really appreciated!

Thanks,
Tomo

Re: Camel 2.19 or 3.0 : lookup endpoint by custom id

[Luca Burgazzoli]

Ah great, thx Claus

On Saturday, 17 September 2016, Claus Ibsen  wrote:

> I managed to find the JIRA ticket
> https://issues.apache.org/jira/browse/CAMEL-7778
>
> On Sat, Sep 17, 2016 at 11:31 AM, Claus Ibsen  > wrote:
> > Hi
> >
> > Yeah we have a JIRA ticket about this, so the Camel endpoint reigistry
> > has an id as well.
> > Currently only the url is registered.
> >
> > Endpoints in Camel don't really have the notion of an id, only url.
> >
> > Its when you use Spring or Blueprint etc then they have an endpoint
> > factory that create endpoints and have an id associated to the factory
> > of the bean it creates. And then when you lookup an endpoint by an id,
> > you lookup in their registries and they find that bean instance.
> >
> > CDI has @Qualified and Spring has @Named to associate an id with the
> > bean when not using XML.
> >
> > Its more tricky to implement as those ids, can be harder to get hold
> > of in those factories AFAIR.
> >
> > But the JIRA ticket was about introducing the id natively on endpoint
> > and endpoint registry. I think this kind of change is better for Camel
> > 3.0.
> >
> >
> >
> > On Sat, Sep 17, 2016 at 11:03 AM, Luca Burgazzoli  > wrote:
> >> Hello everyone,
> >>
> >> I'm wondering if it could make sense to register enpoints in context's
> >> registry having an option so set theirs id;
> >>
> >> The aim is to have a common way to identify an endpoint other by uri,
> so that:
> >> - @Produce(ref = "myEndpontId") would work the same way in any context
> >> - People willing to integrate with camel using a producer template do
> >> not need to know the whole uri, i.e. in vertx-camel-bridge mapping
> >> between a vertx address and an endpoint could be done by id.
> >>
> >>
> >> I could elaborate it a little bit more if you think it could make sense.
> >>
> >>
> >> Best regards,
> >> Luca
> >>
> >>
> >> ---
> >> Luca Burgazzoli
> >
> >
> >
> > --
> > Claus Ibsen
> > -
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


-- 

---
Luca Burgazzoli

Re: Camel 2.19 or 3.0 : lookup endpoint by custom id

[Claus Ibsen]

I managed to find the JIRA ticket
https://issues.apache.org/jira/browse/CAMEL-7778

On Sat, Sep 17, 2016 at 11:31 AM, Claus Ibsen  wrote:
> Hi
>
> Yeah we have a JIRA ticket about this, so the Camel endpoint reigistry
> has an id as well.
> Currently only the url is registered.
>
> Endpoints in Camel don't really have the notion of an id, only url.
>
> Its when you use Spring or Blueprint etc then they have an endpoint
> factory that create endpoints and have an id associated to the factory
> of the bean it creates. And then when you lookup an endpoint by an id,
> you lookup in their registries and they find that bean instance.
>
> CDI has @Qualified and Spring has @Named to associate an id with the
> bean when not using XML.
>
> Its more tricky to implement as those ids, can be harder to get hold
> of in those factories AFAIR.
>
> But the JIRA ticket was about introducing the id natively on endpoint
> and endpoint registry. I think this kind of change is better for Camel
> 3.0.
>
>
>
> On Sat, Sep 17, 2016 at 11:03 AM, Luca Burgazzoli  
> wrote:
>> Hello everyone,
>>
>> I'm wondering if it could make sense to register enpoints in context's
>> registry having an option so set theirs id;
>>
>> The aim is to have a common way to identify an endpoint other by uri, so 
>> that:
>> - @Produce(ref = "myEndpontId") would work the same way in any context
>> - People willing to integrate with camel using a producer template do
>> not need to know the whole uri, i.e. in vertx-camel-bridge mapping
>> between a vertx address and an endpoint could be done by id.
>>
>>
>> I could elaborate it a little bit more if you think it could make sense.
>>
>>
>> Best regards,
>> Luca
>>
>>
>> ---
>> Luca Burgazzoli
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Adding type awareness in Camel route

[Claus Ibsen]

Hey

Can we take this discussion post Camel 2.18 release.

We are working on the last details to get it ready, and its our main
focus to get this new release out.

After this release we will pickup talks about the next releases
whether that is 2.19 or 3.0, and for the latter what the broad goals
of that is. What you talk about seems more of a 3.0 candidate to me,
than on 2.x.



On Fri, Sep 16, 2016 at 6:50 AM, Tomohisa Igarashi
 wrote:
> Hi Camel developers,
>
> I'd like to propose an enhancement on handling data types of Camel message
> contents. To start a smooth discussion I implemented the idea first:
> https://github.com/igarashitm/camel/tree/contract-based-type-awareness
>
> And these testcases demonstrates the declarative transformer usage according
> to the declared data types:
> [Java DSL]
> https://github.com/igarashitm/camel/commit/498c27d2ba99b04bbe7b90a93329d42b7c718a29#diff-c14a7e8e88a6e41492946e1537bfb1cf
> [Spring DSL]
> https://github.com/igarashitm/camel/commit/498c27d2ba99b04bbe7b90a93329d42b7c718a29#diff-b2506c84ddde91438fc6374039e21534
>
> This adds input/output content type declaration on from and all other
> processors. It also introduces well-known Exchange properties, INPUT_TYPE
> and OUTPUT_TYPE which are used to specify the current message content type.
> The data type is URN like string starts with scheme, like
> java:org.example.ItemA or xml:{org.example.xml}ItemA.
>
> If the content type is declared via inputType/outputType/contract, the
> ContractProcessor wraps the actual processor and process
> transformation/validation according to the type, say if INPUT_TYPE exchange
> property has xml:{org.example.xml}ItemA and the declared inputType is
> xml:{org.example.xml}ItemB, then it transforms xml:{org.example.xml}ItemA
> content into xml:{org.example.xml}ItemB. The  element which is
> introduced right under the  is the one to declare the mappings
> between transformer implementation and those from/to data type. I
> implemented only transformer first, but validator would be brought in in a
> same way. This way allows users to make data types visible in the route
> definition and keep the transformation/validation apart from route
> definition itself.
>
> The most important thing is that the ContractProcessor is involved only when
> content type is explicitly declared in a route definition, so that it never
> breaks existing camel routes. Ofcourse programatic
> transformations/validations we're doing today are still fully available.
> It's purely an addition to the existing camel features.
>
> Any thoughts? Does it sound acceptable to get merged into camel? ANY
> feedback would be really appreciated!
>
> Thanks,
> Tomo



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Camel 2.19 or 3.0 : lookup endpoint by custom id

[Claus Ibsen]

Hi

Yeah we have a JIRA ticket about this, so the Camel endpoint reigistry
has an id as well.
Currently only the url is registered.

Endpoints in Camel don't really have the notion of an id, only url.

Its when you use Spring or Blueprint etc then they have an endpoint
factory that create endpoints and have an id associated to the factory
of the bean it creates. And then when you lookup an endpoint by an id,
you lookup in their registries and they find that bean instance.

CDI has @Qualified and Spring has @Named to associate an id with the
bean when not using XML.

Its more tricky to implement as those ids, can be harder to get hold
of in those factories AFAIR.

But the JIRA ticket was about introducing the id natively on endpoint
and endpoint registry. I think this kind of change is better for Camel
3.0.



On Sat, Sep 17, 2016 at 11:03 AM, Luca Burgazzoli  wrote:
> Hello everyone,
>
> I'm wondering if it could make sense to register enpoints in context's
> registry having an option so set theirs id;
>
> The aim is to have a common way to identify an endpoint other by uri, so that:
> - @Produce(ref = "myEndpontId") would work the same way in any context
> - People willing to integrate with camel using a producer template do
> not need to know the whole uri, i.e. in vertx-camel-bridge mapping
> between a vertx address and an endpoint could be done by id.
>
>
> I could elaborate it a little bit more if you think it could make sense.
>
>
> Best regards,
> Luca
>
>
> ---
> Luca Burgazzoli



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Camel 2.19 or 3.0 : lookup endpoint by custom id

[Luca Burgazzoli]

Hello everyone,

I'm wondering if it could make sense to register enpoints in context's
registry having an option so set theirs id;

The aim is to have a common way to identify an endpoint other by uri, so that:
- @Produce(ref = "myEndpontId") would work the same way in any context
- People willing to integrate with camel using a producer template do
not need to know the whole uri, i.e. in vertx-camel-bridge mapping
between a vertx address and an endpoint could be done by id.


I could elaborate it a little bit more if you think it could make sense.


Best regards,
Luca


---
Luca Burgazzoli