Java8 DSL (CAMEL-7831)
Hello everyone, I've started working on CAMEL-7831 to create a Java8 example to use Expressions and I've ended up with a simple example - see [1]. Of course it is only for demonstrative purpose. Java8 lambda support to Expressions has been added to - ExpressionClause to avoid adding overload method for every method accepting an Expressions definition - ExpressionBuilder so you can use something like transform(function(e -> ...)) There are some additional functional interfaces to select the argument of the lambda - ExchangeFunction - MessageFunction - BodyFunction Any feedback would be really appreciated. Regards, Luca [1] https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java --- Luca Burgazzoli
Re: Java8 DSL (CAMEL-7831)
In line comments. --- Luca Burgazzoli On Wed, Sep 7, 2016 at 10:34 AM, Claus Ibsen wrote: > Hi Luca > > Good to see some experiments with this. > > The OUT functions is not needed as end users would only work with the > IN message in the routes. We have deprecated OUT stuff in the Java DSL > in some places. > Removed out and reduced to a single function method, this requires to explicit set the type like: function((Message m) -> m.getBody() ) function((Exchange e) -> e.getIn()) Is that ok ? > Just a mind that the goal of Camel 2.18 is to be a gentle Java8 > upgrade where the APIs are backwards compatible, so end users can take > any existing Java 7 based Camel 2.17 or older and compile as Java 8 > and run on Camel 2.18 as-is. > > Therefore we have so far only done Java 8 stuff internally in Camel, > eg inside component implementations and so on. > > But your changes seems non invasive and can be a candidate to include. > But we could consider marking that as "experimental" so we can do API > changes for the next release, and when we get more hands down on Camel > 3.0 where the APIs can be more Java 8 aggressive. > Is there an annotation or documentation convention for that ? > Also mind that a goal of the DSL is also to let Java and XML be 1:1 so > end users can use the same EIPs in either one, and usually an easy > migration between them, as they are similar. Just be more cautious > when working on Java DSL that you dont end up in a situation with > something that is not possible to do in XML. I think in xml it will be more about bean binding/method reference so it should work out of the box but I will test it before merging. > Also we should avoid turning the Java DSL into un-readable and > cluttered/complex DSL as the Spring Integration Java DSL: > https://github.com/spring-projects/spring-integration-samples/blob/master/dsl/cafe-dsl/src/main/java/org/springframework/integration/samples/dsl/cafe/lambda/Application.java > > But this is a great start, and like that its gentle and only about > doing lambda style functions as Camel expressions. > > > > > > > > On Tue, Sep 6, 2016 at 5:37 PM, Luca Burgazzoli wrote: >> Hello everyone, >> I've started working on CAMEL-7831 to create a Java8 example to use >> Expressions and I've ended up with a simple example - see [1]. >> Of course it is only for demonstrative purpose. >> >> Java8 lambda support to Expressions has been added to >> - ExpressionClause to avoid adding overload method for every method >> accepting an Expressions definition >> - ExpressionBuilder so you can use something like transform(function(e -> >> ...)) >> >> There are some additional functional interfaces to select the argument >> of the lambda >> - ExchangeFunction >> - MessageFunction >> - BodyFunction >> >> >> Any feedback would be really appreciated. >> >> Regards, >> Luca >> >> >> [1] >> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java >> >> >> --- >> Luca Burgazzoli > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: Java8 DSL (CAMEL-7831)
--- Luca Burgazzoli On Wed, Sep 7, 2016 at 12:00 PM, Claus Ibsen wrote: > On Wed, Sep 7, 2016 at 11:39 AM, Luca Burgazzoli > wrote: >> In line comments. >> >> --- >> Luca Burgazzoli >> >> >> On Wed, Sep 7, 2016 at 10:34 AM, Claus Ibsen wrote: >>> Hi Luca >>> >>> Good to see some experiments with this. >>> >>> The OUT functions is not needed as end users would only work with the >>> IN message in the routes. We have deprecated OUT stuff in the Java DSL >>> in some places. >>> >> >> Removed out and reduced to a single function method, this requires to >> explicit >> set the type like: >> >>function((Message m) -> m.getBody() ) >>function((Exchange e) -> e.getIn()) >> >> Is that ok ? >> > > I think we need to tweak this a bit to find the right balance. Would > like if we could omit the type for normal use-cases. Working on > Message is a bit shorter than Exchange as you can call getBody / > getHeader asap. And if you need Exchange there is a getExchange > method. > Agree, so we could complete remove the Exchange variant, an additional option would be - but I'm thinking aloud here - to override calls such - body() - exchange() - inMessage() So we then may have something like: transform() .inMessage(m -> ...) transform() .body(b -> ...) transform() .body(Bean.class, b -> ...) transform() .body(Bean.class, (b, h) -> ...) > > > >>> Just a mind that the goal of Camel 2.18 is to be a gentle Java8 >>> upgrade where the APIs are backwards compatible, so end users can take >>> any existing Java 7 based Camel 2.17 or older and compile as Java 8 >>> and run on Camel 2.18 as-is. >>> >>> Therefore we have so far only done Java 8 stuff internally in Camel, >>> eg inside component implementations and so on. >>> >>> But your changes seems non invasive and can be a candidate to include. >>> But we could consider marking that as "experimental" so we can do API >>> changes for the next release, and when we get more hands down on Camel >>> 3.0 where the APIs can be more Java 8 aggressive. >>> >> >> Is there an annotation or documentation convention for that ? >> > > No we dont have that, but we can add to javadoc that its "work in > progress" or "subject for change" or something. Just so we have > freedom to change it in the following release(s). > > > >>> Also mind that a goal of the DSL is also to let Java and XML be 1:1 so >>> end users can use the same EIPs in either one, and usually an easy >>> migration between them, as they are similar. Just be more cautious >>> when working on Java DSL that you dont end up in a situation with >>> something that is not possible to do in XML. >> >> I think in xml it will be more about bean binding/method reference so it >> should work out of the box but I will test it before merging. >> >> >>> Also we should avoid turning the Java DSL into un-readable and >>> cluttered/complex DSL as the Spring Integration Java DSL: >>> https://github.com/spring-projects/spring-integration-samples/blob/master/dsl/cafe-dsl/src/main/java/org/springframework/integration/samples/dsl/cafe/lambda/Application.java >>> >>> But this is a great start, and like that its gentle and only about >>> doing lambda style functions as Camel expressions. >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Sep 6, 2016 at 5:37 PM, Luca Burgazzoli >>> wrote: >>>> Hello everyone, >>>> I've started working on CAMEL-7831 to create a Java8 example to use >>>> Expressions and I've ended up with a simple example - see [1]. >>>> Of course it is only for demonstrative purpose. >>>> >>>> Java8 lambda support to Expressions has been added to >>>> - ExpressionClause to avoid adding overload method for every method >>>> accepting an Expressions definition >>>> - ExpressionBuilder so you can use something like transform(function(e -> >>>> ...)) >>>> >>>> There are some additional functional interfaces to select the argument >>>> of the lambda >>>> - ExchangeFunction >>>> - MessageFunction >>>> - BodyFunction >>>> >>>> >>>> Any feedback would be really appreciated. >>>> >>>> Regards, >>>> Luca >>>> >>>> >>>> [1] >>>> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java >>>> >>>> >>>> --- >>>> 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: Java8 DSL (CAMEL-7831)
Vitalii, it was the first iteration just to have some feedbacks ;)
I've added something more now as experiment so your suggestions should
have been covered now.
By extending ExpressionClause built-in body/inMessage/etc, we could
have something like:
from("timer:simple?period=503")
.id("simple-route")
.transform()
.exchange(this::dateToTime)
.choice()
.when()
.body(Integer.class, b -> (b & 1) == 0)
.log("Received even number")
.when()
.body(Integer.class, (b, h) -> h.containsKey("skip") ?
false : (b & 1) == 0)
.log("Received odd number")
.when()
.body(b -> b instanceof Number)
.log("Received a number number")
.when()
.inMessage(m -> m.getBody() == null)
.log("Received null body")
.when()
.body(Integer.class, b -> (b & 1) == 0)
.log("Received odd number")
.endChoice();
---
Luca Burgazzoli
On Wed, Sep 7, 2016 at 2:16 PM, Vitalii Tymchyshyn wrote:
> Hi.
>
> Why BodyFunction is a BiFunction? It would be great to have some method to
> pass any Functional interface (any function) that would receive body as
> parameter and result would be stored as an answer. This would allow to use
> tons of existing functional method.
> E.g. something like this would be possible:
> .transform(function(String.class, String::toUpperCase))
> Another thing is that often body type is not needed, e.g.
> .transform(onBody(String::toUpperCase)) looks more readable.
> i'd also rename other "function" calls with something that gives more
> information like "onExchange", "onMessage" (or even simply body(),
> exchange(), message()). This would also make casting unnesessary.
>
> Best regards, Vitalii Tymchyshyn
>
> Вт, 6 вер. 2016 о 11:38 Luca Burgazzoli пише:
>
>> Hello everyone,
>> I've started working on CAMEL-7831 to create a Java8 example to use
>> Expressions and I've ended up with a simple example - see [1].
>> Of course it is only for demonstrative purpose.
>>
>> Java8 lambda support to Expressions has been added to
>> - ExpressionClause to avoid adding overload method for every method
>> accepting an Expressions definition
>> - ExpressionBuilder so you can use something like transform(function(e ->
>> ...))
>>
>> There are some additional functional interfaces to select the argument
>> of the lambda
>> - ExchangeFunction
>> - MessageFunction
>> - BodyFunction
>>
>>
>> Any feedback would be really appreciated.
>>
>> Regards,
>> Luca
>>
>>
>> [1]
>> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java
>>
>>
>> ---
>> Luca Burgazzoli
>>
Re: Java8 DSL (CAMEL-7831)
Yep, need to add an additional method to ExpressionClause
---
Luca Burgazzoli
On Wed, Sep 7, 2016 at 2:32 PM, Claus Ibsen wrote:
> Hi
>
> This starts to look really good.
>
> I would suggest renaming
>
> .inMessage(m -> m.getBody() == null)
>
> To just message
>
> .message(m -> m.getBody() == null)
>
> On Wed, Sep 7, 2016 at 2:22 PM, Luca Burgazzoli wrote:
>> Vitalii, it was the first iteration just to have some feedbacks ;)
>>
>> I've added something more now as experiment so your suggestions should
>> have been covered now.
>> By extending ExpressionClause built-in body/inMessage/etc, we could
>> have something like:
>>
>> from("timer:simple?period=503")
>> .id("simple-route")
>> .transform()
>> .exchange(this::dateToTime)
>> .choice()
>> .when()
>> .body(Integer.class, b -> (b & 1) == 0)
>> .log("Received even number")
>> .when()
>> .body(Integer.class, (b, h) -> h.containsKey("skip") ?
>> false : (b & 1) == 0)
>> .log("Received odd number")
>> .when()
>> .body(b -> b instanceof Number)
>> .log("Received a number number")
>> .when()
>> .inMessage(m -> m.getBody() == null)
>> .log("Received null body")
>> .when()
>> .body(Integer.class, b -> (b & 1) == 0)
>> .log("Received odd number")
>> .endChoice();
>>
>>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Wed, Sep 7, 2016 at 2:16 PM, Vitalii Tymchyshyn wrote:
>>> Hi.
>>>
>>> Why BodyFunction is a BiFunction? It would be great to have some method to
>>> pass any Functional interface (any function) that would receive body as
>>> parameter and result would be stored as an answer. This would allow to use
>>> tons of existing functional method.
>>> E.g. something like this would be possible:
>>> .transform(function(String.class, String::toUpperCase))
>>> Another thing is that often body type is not needed, e.g.
>>> .transform(onBody(String::toUpperCase)) looks more readable.
>>> i'd also rename other "function" calls with something that gives more
>>> information like "onExchange", "onMessage" (or even simply body(),
>>> exchange(), message()). This would also make casting unnesessary.
>>>
>>> Best regards, Vitalii Tymchyshyn
>>>
>>> Вт, 6 вер. 2016 о 11:38 Luca Burgazzoli пише:
>>>
>>>> Hello everyone,
>>>> I've started working on CAMEL-7831 to create a Java8 example to use
>>>> Expressions and I've ended up with a simple example - see [1].
>>>> Of course it is only for demonstrative purpose.
>>>>
>>>> Java8 lambda support to Expressions has been added to
>>>> - ExpressionClause to avoid adding overload method for every method
>>>> accepting an Expressions definition
>>>> - ExpressionBuilder so you can use something like transform(function(e ->
>>>> ...))
>>>>
>>>> There are some additional functional interfaces to select the argument
>>>> of the lambda
>>>> - ExchangeFunction
>>>> - MessageFunction
>>>> - BodyFunction
>>>>
>>>>
>>>> Any feedback would be really appreciated.
>>>>
>>>> Regards,
>>>> Luca
>>>>
>>>>
>>>> [1]
>>>> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java
>>>>
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Java8 DSL (CAMEL-7831)
@Clauss
- I've removed intermediate funtional interfaces like ExchangeFunction
- added simple message(...)
Result here:
https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java
@Vitalii
It may be nice to support existing expressions, like:
transform().body(
String.class,
String::indexOf,
header("toFindHeader", String.class)
)
Maybe this deserve an additional JIRA
---
Luca Burgazzoli
On Wed, Sep 7, 2016 at 2:45 PM, Vitalii Tymchyshyn wrote:
> Sure, I really appreciate the effort, especially since I am now also
> working on making Camel more J8-friendly (in the reactive programming part).
> Please don't forget ".mandatoryBody", it's extremely useful. It produces
> much nicer exception instead of just NPE if your body is of wrong type or
> null. I'd even vote for making .body(Class, Function) calling mandatoryBody
> on exchange, since .getBody(class) gives much confusion in error cases when
> body of a wrong type, but I am not sure if it would be consistent with
> existing code.
> Also talking about BiFunctions, consider passing not only map, but also
> exact header or property as again it makes it very easy to use tons of
> 2-parameter preexisting methods, may be even something like this can be
> done:
> transform().body(BiFunction).withHeader("headerName")
> transform().body(BiFunction).withProperty("propertyName")
>
> that would make something like the next possible:
> transform().body(String::indexOf).withHeader("toFindHeader")
>
> BTW: It would be great to have async versions, like .asyncBody(Class,
> Function)
>
> Best regards, Vitalii Tymchyshyn
>
> Ср, 7 вер. 2016 о 08:22 Luca Burgazzoli пише:
>
>> Vitalii, it was the first iteration just to have some feedbacks ;)
>>
>> I've added something more now as experiment so your suggestions should
>> have been covered now.
>> By extending ExpressionClause built-in body/inMessage/etc, we could
>> have something like:
>>
>> from("timer:simple?period=503")
>> .id("simple-route")
>> .transform()
>> .exchange(this::dateToTime)
>> .choice()
>> .when()
>> .body(Integer.class, b -> (b & 1) == 0)
>> .log("Received even number")
>> .when()
>> .body(Integer.class, (b, h) -> h.containsKey("skip") ?
>> false : (b & 1) == 0)
>> .log("Received odd number")
>> .when()
>> .body(b -> b instanceof Number)
>> .log("Received a number number")
>> .when()
>> .inMessage(m -> m.getBody() == null)
>> .log("Received null body")
>> .when()
>> .body(Integer.class, b -> (b & 1) == 0)
>> .log("Received odd number")
>> .endChoice();
>>
>>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Wed, Sep 7, 2016 at 2:16 PM, Vitalii Tymchyshyn wrote:
>> > Hi.
>> >
>> > Why BodyFunction is a BiFunction? It would be great to have some method
>> to
>> > pass any Functional interface (any function) that would receive body as
>> > parameter and result would be stored as an answer. This would allow to
>> use
>> > tons of existing functional method.
>> > E.g. something like this would be possible:
>> > .transform(function(String.class, String::toUpperCase))
>> > Another thing is that often body type is not needed, e.g.
>> > .transform(onBody(String::toUpperCase)) looks more readable.
>> > i'd also rename other "function" calls with something that gives more
>> > information like "onExchange", "onMessage" (or even simply body(),
>> > exchange(), message()). This would also make casting unnesessary.
>> >
>> > Best regards, Vitalii Tymchyshyn
>> >
>> > Вт, 6 вер. 2016 о 11:38 Luca Burgazzoli пише:
>> >
>> >> Hello everyone,
>> >> I've started working on CAMEL-7831 to create a Java8 example to use
>> >> Expressions and I've ended up with a simple example - see [1].
>> >> Of course it is only for demonstrative purpose.
>> >>
>> >> Java8 lambda support to Expressions has been added to
>> >> - ExpressionClause to avoid adding overload method for every method
>> >> accepting an Expressions definition
>> >> - ExpressionBuilder so you can use something like transform(function(e
>> ->
>> >> ...))
>> >>
>> >> There are some additional functional interfaces to select the argument
>> >> of the lambda
>> >> - ExchangeFunction
>> >> - MessageFunction
>> >> - BodyFunction
>> >>
>> >>
>> >> Any feedback would be really appreciated.
>> >>
>> >> Regards,
>> >> Luca
>> >>
>> >>
>> >> [1]
>> >>
>> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java
>> >>
>> >>
>> >> ---
>> >> Luca Burgazzoli
>> >>
>>
Re: Java8 DSL (CAMEL-7831)
Would it make sense to add also a ProcessClause (later on) to have
something similar for process ?
process()
.exchange(e -> ...) // not needed but for consistency
process()
.message(m -> ...)
process()
.body(b -> ... ) // should return the body
---
Luca Burgazzoli
On Wed, Sep 7, 2016 at 4:02 PM, Claus Ibsen wrote:
> On Wed, Sep 7, 2016 at 3:47 PM, Luca Burgazzoli wrote:
>> @Clauss
>>
>> - I've removed intermediate funtional interfaces like ExchangeFunction
>> - added simple message(...)
>>
>> Result here:
>> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java
>>
>
> Yay looks much nicer and simpler.
>
>> @Vitalii
>> It may be nice to support existing expressions, like:
>>
>> transform().body(
>> String.class,
>> String::indexOf,
>> header("toFindHeader", String.class)
>> )
>>
>> Maybe this deserve an additional JIRA
>>
>
> Yeah lets avoid making the first version too complex and to many bells
> and whistles.
> It just becomes too confusing with functional lambdas extreme here,
> and then regular DSL with EIPs not as functional.
>
>
>
>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Wed, Sep 7, 2016 at 2:45 PM, Vitalii Tymchyshyn wrote:
>>> Sure, I really appreciate the effort, especially since I am now also
>>> working on making Camel more J8-friendly (in the reactive programming part).
>>> Please don't forget ".mandatoryBody", it's extremely useful. It produces
>>> much nicer exception instead of just NPE if your body is of wrong type or
>>> null. I'd even vote for making .body(Class, Function) calling mandatoryBody
>>> on exchange, since .getBody(class) gives much confusion in error cases when
>>> body of a wrong type, but I am not sure if it would be consistent with
>>> existing code.
>>> Also talking about BiFunctions, consider passing not only map, but also
>>> exact header or property as again it makes it very easy to use tons of
>>> 2-parameter preexisting methods, may be even something like this can be
>>> done:
>>> transform().body(BiFunction).withHeader("headerName")
>>> transform().body(BiFunction).withProperty("propertyName")
>>>
>>> that would make something like the next possible:
>>> transform().body(String::indexOf).withHeader("toFindHeader")
>>>
>>> BTW: It would be great to have async versions, like .asyncBody(Class,
>>> Function)
>>>
>>> Best regards, Vitalii Tymchyshyn
>>>
>>> Ср, 7 вер. 2016 о 08:22 Luca Burgazzoli пише:
>>>
>>>> Vitalii, it was the first iteration just to have some feedbacks ;)
>>>>
>>>> I've added something more now as experiment so your suggestions should
>>>> have been covered now.
>>>> By extending ExpressionClause built-in body/inMessage/etc, we could
>>>> have something like:
>>>>
>>>> from("timer:simple?period=503")
>>>> .id("simple-route")
>>>> .transform()
>>>> .exchange(this::dateToTime)
>>>> .choice()
>>>> .when()
>>>> .body(Integer.class, b -> (b & 1) == 0)
>>>> .log("Received even number")
>>>> .when()
>>>> .body(Integer.class, (b, h) -> h.containsKey("skip") ?
>>>> false : (b & 1) == 0)
>>>> .log("Received odd number")
>>>> .when()
>>>> .body(b -> b instanceof Number)
>>>> .log("Received a number number")
>>>> .when()
>>>> .inMessage(m -> m.getBody() == null)
>>>> .log("Received null body")
>>>> .when()
>>>> .body(Integer.class, b -> (b & 1) == 0)
>>>> .log("Received odd number")
>>>> .endChoice();
>>>>
>>>>
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Wed, Sep 7, 2016 at 2:16 PM, Vitalii Tymchyshyn wrote:
>>>> > Hi.
>>>> >
>>>> > Why BodyFunction is a BiFunction? It would be great to have some method
>>>> to
>>>
Re: Java8 DSL (CAMEL-7831)
Yep, but it is all about exchange
---
Luca Burgazzoli
On Wed, Sep 7, 2016 at 6:54 PM, Vitalii Tymchyshyn wrote:
> Process is already working nice
> E.g process(e-> e.setBody("aaa")) works fine.
>
> Ср, 7 вер. 2016 10:44 користувач Luca Burgazzoli
> пише:
>
>> Would it make sense to add also a ProcessClause (later on) to have
>> something similar for process ?
>>
>> process()
>> .exchange(e -> ...) // not needed but for consistency
>> process()
>> .message(m -> ...)
>> process()
>> .body(b -> ... ) // should return the body
>>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Wed, Sep 7, 2016 at 4:02 PM, Claus Ibsen wrote:
>> > On Wed, Sep 7, 2016 at 3:47 PM, Luca Burgazzoli
>> wrote:
>> >> @Clauss
>> >>
>> >> - I've removed intermediate funtional interfaces like ExchangeFunction
>> >> - added simple message(...)
>> >>
>> >> Result here:
>> >>
>> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java
>> >>
>> >
>> > Yay looks much nicer and simpler.
>> >
>> >> @Vitalii
>> >> It may be nice to support existing expressions, like:
>> >>
>> >> transform().body(
>> >> String.class,
>> >> String::indexOf,
>> >> header("toFindHeader", String.class)
>> >> )
>> >>
>> >> Maybe this deserve an additional JIRA
>> >>
>> >
>> > Yeah lets avoid making the first version too complex and to many bells
>> > and whistles.
>> > It just becomes too confusing with functional lambdas extreme here,
>> > and then regular DSL with EIPs not as functional.
>> >
>> >
>> >
>> >
>> >>
>> >> ---
>> >> Luca Burgazzoli
>> >>
>> >>
>> >> On Wed, Sep 7, 2016 at 2:45 PM, Vitalii Tymchyshyn wrote:
>> >>> Sure, I really appreciate the effort, especially since I am now also
>> >>> working on making Camel more J8-friendly (in the reactive programming
>> part).
>> >>> Please don't forget ".mandatoryBody", it's extremely useful. It
>> produces
>> >>> much nicer exception instead of just NPE if your body is of wrong type
>> or
>> >>> null. I'd even vote for making .body(Class, Function) calling
>> mandatoryBody
>> >>> on exchange, since .getBody(class) gives much confusion in error cases
>> when
>> >>> body of a wrong type, but I am not sure if it would be consistent
>> with
>> >>> existing code.
>> >>> Also talking about BiFunctions, consider passing not only map, but also
>> >>> exact header or property as again it makes it very easy to use tons of
>> >>> 2-parameter preexisting methods, may be even something like this can be
>> >>> done:
>> >>> transform().body(BiFunction).withHeader("headerName")
>> >>> transform().body(BiFunction).withProperty("propertyName")
>> >>>
>> >>> that would make something like the next possible:
>> >>> transform().body(String::indexOf).withHeader("toFindHeader")
>> >>>
>> >>> BTW: It would be great to have async versions, like .asyncBody(Class,
>> >>> Function)
>> >>>
>> >>> Best regards, Vitalii Tymchyshyn
>> >>>
>> >>> Ср, 7 вер. 2016 о 08:22 Luca Burgazzoli пише:
>> >>>
>> >>>> Vitalii, it was the first iteration just to have some feedbacks ;)
>> >>>>
>> >>>> I've added something more now as experiment so your suggestions should
>> >>>> have been covered now.
>> >>>> By extending ExpressionClause built-in body/inMessage/etc, we could
>> >>>> have something like:
>> >>>>
>> >>>> from("timer:simple?period=503")
>> >>>> .id("simple-route")
>> >>>> .transform()
>> >>>> .exchange(this::dateToTime)
>> >>>> .choice()
>> >>>> .when()
>> >>>> .body(Integer.class, b -> (b & 1) == 0)
>> >>>> .log("Rec
Re: Java8 DSL (CAMEL-7831)
---
Luca Burgazzoli
On Wed, Sep 7, 2016 at 8:00 PM, Claus Ibsen wrote:
> On Wed, Sep 7, 2016 at 4:44 PM, Luca Burgazzoli wrote:
>> Would it make sense to add also a ProcessClause (later on) to have
>> something similar for process ?
>>
>> process()
>> .exchange(e -> ...) // not needed but for consistency
>> process()
>> .message(m -> ...)
>> process()
>> .body(b -> ... ) // should return the body
>>
>
> Yeah this allows to do inlined processors quickly. And sometimes you
> just want to do a bit of code at that spot in the route.
>
> And even to do a system out println, and can't you do something like this now?
>
> .body(System.out::println)
>
Yep you''ll be able to do so
>
>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Wed, Sep 7, 2016 at 4:02 PM, Claus Ibsen wrote:
>>> On Wed, Sep 7, 2016 at 3:47 PM, Luca Burgazzoli
>>> wrote:
>>>> @Clauss
>>>>
>>>> - I've removed intermediate funtional interfaces like ExchangeFunction
>>>> - added simple message(...)
>>>>
>>>> Result here:
>>>> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java
>>>>
>>>
>>> Yay looks much nicer and simpler.
>>>
>>>> @Vitalii
>>>> It may be nice to support existing expressions, like:
>>>>
>>>> transform().body(
>>>> String.class,
>>>> String::indexOf,
>>>> header("toFindHeader", String.class)
>>>> )
>>>>
>>>> Maybe this deserve an additional JIRA
>>>>
>>>
>>> Yeah lets avoid making the first version too complex and to many bells
>>> and whistles.
>>> It just becomes too confusing with functional lambdas extreme here,
>>> and then regular DSL with EIPs not as functional.
>>>
>>>
>>>
>>>
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Wed, Sep 7, 2016 at 2:45 PM, Vitalii Tymchyshyn wrote:
>>>>> Sure, I really appreciate the effort, especially since I am now also
>>>>> working on making Camel more J8-friendly (in the reactive programming
>>>>> part).
>>>>> Please don't forget ".mandatoryBody", it's extremely useful. It produces
>>>>> much nicer exception instead of just NPE if your body is of wrong type or
>>>>> null. I'd even vote for making .body(Class, Function) calling
>>>>> mandatoryBody
>>>>> on exchange, since .getBody(class) gives much confusion in error cases
>>>>> when
>>>>> body of a wrong type, but I am not sure if it would be consistent with
>>>>> existing code.
>>>>> Also talking about BiFunctions, consider passing not only map, but also
>>>>> exact header or property as again it makes it very easy to use tons of
>>>>> 2-parameter preexisting methods, may be even something like this can be
>>>>> done:
>>>>> transform().body(BiFunction).withHeader("headerName")
>>>>> transform().body(BiFunction).withProperty("propertyName")
>>>>>
>>>>> that would make something like the next possible:
>>>>> transform().body(String::indexOf).withHeader("toFindHeader")
>>>>>
>>>>> BTW: It would be great to have async versions, like .asyncBody(Class,
>>>>> Function)
>>>>>
>>>>> Best regards, Vitalii Tymchyshyn
>>>>>
>>>>> Ср, 7 вер. 2016 о 08:22 Luca Burgazzoli пише:
>>>>>
>>>>>> Vitalii, it was the first iteration just to have some feedbacks ;)
>>>>>>
>>>>>> I've added something more now as experiment so your suggestions should
>>>>>> have been covered now.
>>>>>> By extending ExpressionClause built-in body/inMessage/etc, we could
>>>>>> have something like:
>>>>>>
>>>>>> from("timer:simple?period=503")
>>>>>> .id("simple-route")
>>>>>> .transform()
>>>>>> .exchange(this::dateToTime)
>>>>>> .choice()
>>>>>> .when()
>>>>>>
Re: Java8 DSL (CAMEL-7831)
I'll merge it before eow as well as an archetype and example --- Luca Burgazzoli On Thu, Sep 8, 2016 at 3:26 PM, Claus Ibsen wrote: > Looks good Luca. > > Great to have this experimental DSL in the release so we can show it > to end users and get feedback. > > Would be good with a camel-example-java8 as an example using the DSL. > > > On Tue, Sep 6, 2016 at 5:37 PM, Luca Burgazzoli wrote: >> Hello everyone, >> I've started working on CAMEL-7831 to create a Java8 example to use >> Expressions and I've ended up with a simple example - see [1]. >> Of course it is only for demonstrative purpose. >> >> Java8 lambda support to Expressions has been added to >> - ExpressionClause to avoid adding overload method for every method >> accepting an Expressions definition >> - ExpressionBuilder so you can use something like transform(function(e -> >> ...)) >> >> There are some additional functional interfaces to select the argument >> of the lambda >> - ExchangeFunction >> - MessageFunction >> - BodyFunction >> >> >> Any feedback would be really appreciated. >> >> Regards, >> Luca >> >> >> [1] >> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-7831/examples/camel-example-dsl-java8/src/main/java/org/apache/camel/example/dsl/java8/MyRoute.java >> >> >> --- >> Luca Burgazzoli > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Camel 3.0 ideas : LeaderPolicy
Hello everyone, I've been working on some master/slave RoutePolicy and I'm wondering if we can have a proper LeaderPolicy with a standardized implementation in Camel 3.0 so one has only to notify when a leadership is taken In addition it may be nice to have: - a support for Leader election from the CmelContext so the routes are started when the context become leader. - an option to warm-up routes or to keep them stopped while not leader Make sense ? --- Luca Burgazzoli
Re: Apache Camel 2.16.4 release
+1 --- Luca Burgazzoli On Thu, Sep 15, 2016 at 8:03 AM, Andrea Cosentino wrote: > +1, Thanks a lot Gregor! > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix Committer > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > On Wednesday, September 14, 2016 8:36 PM, Gregor Zurowski > wrote: > Hi Everyone: > > As previously discussed on the list, we should get a final Camel > 2.16.4 release out the door. If everyone agrees, I will create a > release candidate this week. What do you think? > > Thanks, > Gregor
Re: Camel 3.0 ideas : LeaderPolicy
Yep I'd like something like an open LeaderElection API a user can implement from scratch (i.e. one may want to gahve multipel eladers) or you can define just the leadership part and the default implementation does everything else for you. --- Luca Burgazzoli On Thu, Sep 15, 2016 at 8:34 AM, Andrea Cosentino wrote: > Maybe we can also give the possibility to end user to implement their own > leader election policy. > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix Committer > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > On Thursday, September 15, 2016 8:33 AM, Claus Ibsen > wrote: > On Thu, Sep 15, 2016 at 8:14 AM, Luca Burgazzoli > wrote: >> Hello everyone, >> >> I've been working on some master/slave RoutePolicy and I'm wondering >> if we can have a proper LeaderPolicy with a standardized >> implementation in Camel 3.0 so one has only to notify when a >> leadership is taken >> >> In addition it may be nice to have: >> - a support for Leader election from the CmelContext so the routes are >> started when the context become leader. >> - an option to warm-up routes or to keep them stopped while not leader >> >> >> Make sense ? >> > > Yes it sure does. There may be an older JIRA ticket about something > like this already. But it does not hurt to log a new JIRA either and > mark it for 3.0 so its not forgotten. > > We got a bunch of components now with the route policy for this > master/slave stuff, but IMHO could really benefit from a proper > cluster API. > > Then we can also make it exposed in JMX so tooling are able to detect > which are current master and slaves, and whatnot. > > >> --- >> 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
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
Re: Camel 2.19 or 3.0 : lookup endpoint by custom id
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: Getting ready for Apache Camel 2.18 Release
Hi Claus, upgrade to Saxon 9.7 will be merged today. Luca --- Luca Burgazzoli On Wed, Sep 21, 2016 at 11:31 AM, Claus Ibsen wrote: > Hi > > Just a quick update. > > Nicola has now merged his great work on making Camel and Spring Boot > work well together with a curated list of -starter components that > works. > > There is another Camel SB ticket merged about nested configuration > which we need a bit time to improved/fix etc. > > And also upgrading to SB 1.4.1 which has just been released, but we > assume its a straightforward upgrade. > > > And I think Luca has a bit work on upgrading to Saxon 9.7. > > But those are IMHO the last bigger things we need to finish before > closing down and cutting a release. > > > As usual keep eye on CI server build server > https://builds.apache.org/view/A-D/view/Camel/ > > And the last JIRA tickets for 2.18.0 to be resolved > https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.18.0%20AND%20resolution%20%3D%20Unresolved > > > The new camel-test-karaf module is ongoing work and in this release as > a kind of preview where we want community feedback and then continue > working on this for the next 2.19.0 release to be in good shape. > > > > > > > On Fri, Sep 16, 2016 at 11:01 AM, Nicola Ferraro wrote: >> Hi Claus, I started working on that this morning. >> I think I'll provide the new BOM and related updates early next week. >> >> >> >> >> >> On Fri, Sep 16, 2016 at 9:38 AM, Claus Ibsen wrote: >> >>> Hi Nicola >>> >>> How does your calendar look like? I wonder if you have time to work >>> more on this Camel and Spring Boot stuff? >>> >>> I am afraid this one is the major task we have left before we can get >>> started on the Camel 2.18 release and IMHO first class Spring Boot >>> support is a major win/goal for Camel. >>> >>> So the work is very important, and its been awesome what you have >>> done. Really love that we have integration tests, and also separated >>> the auto stuff code from the existing components so there is clean >>> separation. >>> >>> >>> >>> >>> On Wed, Sep 14, 2016 at 3:32 PM, Nicola Ferraro >>> wrote: >>> > Well, it was one of the drawbacks of the approach. Forcing users to >>> include >>> > *only* the camel BOM allows us to completely control the dependencies, >>> but >>> > it's probably a too strict requirement for users. >>> > >>> > We can also provide a option 1+2: i.e. a auto-generated Camel BOM without >>> > any conflict with the spring-boot one (conflicts verified by eg. a maven >>> > plugin). >>> > Users will be able to import it in any order but, of course, some >>> > components will not work because we cannot override what's in the >>> > spring-boot BOM (unless the users force a different version in their pom, >>> > but it's up to them). >>> > >>> > It makes more sense.. >>> > What do you think about it? >>> > >>> > >>> > >>> > On Wed, Sep 14, 2016 at 9:46 AM, Claus Ibsen >>> wrote: >>> > >>> >> Hi Nicola >>> >> >>> >> Great work on all this Spring Boot starter stuff. >>> >> >>> >> I would like to discuss/hear more about the #1 option you listed on >>> >> https://github.com/apache/camel/pull/1164 >>> >> >>> >> I think that end users would really prefer their Spring Boot >>> >> applications to be "pure" spring boot by having the Spring Boot BOM >>> >> first and then possible the Camel BOM imported as 2nd. >>> >> >>> >> I am okay if there is some Camel components that would not work with >>> >> Spring Boot such as Cassandra or others. For ActiveMQ then Camel only >>> >> uses that for testing camel-jms component and do not have a strong >>> >> dependency on the version. So end users should likely use the Spring >>> >> Boot ActiveMQ starter. >>> >> >>> >> >>> >> >>> >> On Mon, Sep 12, 2016 at 11:10 AM, Nicola Ferraro >>> >> wrote: >>> >> > I've worked on the spring-boot starters and BOM topic and opened a PR >>> >> > recently. You can find a summary here [ >>> >> > https://issues.apache.org/jira/browse/CAMEL-
Re: [DISCUSS] Upgrade Camel to Karaf 4
+1 --- Luca Burgazzoli On Fri, Sep 23, 2016 at 4:17 PM, Andrea Cosentino wrote: > I agree with Daniel. > > Anyway this is something we can surely work on for the next release. > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix Committer > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > On Friday, September 23, 2016 4:15 PM, Daniel Kulp wrote: > > I think it’s too late to do this for 2.18 (trying to get that out soon). > Might make sense for 2.19. > > Dan > > > >> On Sep 23, 2016, at 4:21 AM, Guillaume Nodet wrote: >> >> I'd like to start a discussion around upgrading Camel karaf support to >> Karaf 4. >> Karaf 4 has brought a number of changes that could be leveraged : >> * no strong dependency on blueprint >> * complete feature validation at build time >> * more fine grained feature so that all dependencies can be expressed >> >> I'd like to leverage those for Camel. This can be achieved either by >> dropping support for Karaf 2 and 3, or by keeping both (effectively >> duplicating the integration code in platforms/karaf to platforms/karaf4). >> >> Also, it would make sense to upgrade to cxf 3.2-SNAPSHOT which I'm also >> upgrading to Karaf 4. >> >> Thoughts ? >> Guillaume Nodet > > -- > Daniel Kulp > dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog > <http://dankulp.com/blog> > Talend Community Coder - http://coders.talend.com <http://coders.talend.com/ >>
Re: New Apache Camel Logo
+1 --- Luca Burgazzoli On Thu, Sep 29, 2016 at 4:50 PM, Andrea Cosentino wrote: > Absolutely +1. > > We need a new logo! > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix Committer > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > On Thursday, September 29, 2016 4:47 PM, Claus Ibsen > wrote: > Hi > > The old Apache Camel logo is a bit out dated, and we have in the past > talked about a new logo. > > Then Jakub Korab posed this tweet > https://twitter.com/jakekorab/status/780333769358184449 > > Seems like there is a design team that did a great logo for bash. > > So maybe we can ask if they would consider try to do an Apache Camel logo. > > Of course anyone else is welcome to attempt to do a better logo. > > It would be good if the logo can be in vector and bitmap. > So with vector we can do a SVG and for bitmap we can have a PNG / JPEG etc. > Also maybe for vector we can try to do a little .ico file for web browser. > > > Any comments or thoughts? > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: [VOTE] Release Apache Camel 2.18.0
+1 (binding) --- Luca Burgazzoli On Thu, Oct 6, 2016 at 8:03 AM, Thomas Diesler wrote: > +1 (wildfly-camel <https://github.com/wildfly-extras/wildfly-camel>) > >> On 05 Oct 2016, at 16:54, Gregor Zurowski wrote: >> >> Hi Everyone: >> >> This is a vote to release Apache Camel 2.18.0, the first release that >> requires Java 8, comes with a much-improved Spring Boot support, and >> ships with numerous new features and improvements. (For further >> details please see >> http://www.davsclaus.com/2016/06/apache-camel-218-highlights-of-what-is.html.) >> >> Release notes: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334759&projectId=12311211 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecamel-1059/ >> >> Tarballs: >> https://repository.apache.org/content/repositories/orgapachecamel-1059/org/apache/camel/apache-camel/2.18.0/ >> >> Tag: >> https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=e278cf0a1fe689d43e913009e88688c591e291b2 >> >> Please test this release candidate and cast your vote. >> [ ] +1 Release the binary as Apache Camel 2.18.0 >> [ ] -1 Veto the release (provide specific comments) >> >> The vote is open for at least 72 hours. Due to the bigger changes >> introduced with this release, it would be beneficial if we could get >> as many Camel riders involved in testing this RC as possible. >> >> Thanks, >> Gregor >
Camel master branch version
Hello everyone, I've just noticed that the master branch of camel is still using 2.18.0-SNAPSHOT as version, shouldn't it be 2.19.0-SNAPSHOT ? --- Luca Burgazzoli
Re: Camel master branch version
would be awesome, thanks Gregor --- Luca Burgazzoli On Tue, Oct 11, 2016 at 11:16 AM, Gregor Zurowski wrote: > Hi, > > This happened because I branched off 2.18.x before performing the > release, so the Maven release plugin did not update the version on the > master branch. I can make the necessary changes on the master branch > later today. > > Thanks, > Gregor > > > On Tue, Oct 11, 2016 at 11:15 AM, Claus Ibsen wrote: >> Hi >> >> Yes it should be 2.19.0-SNAPSHOT. >> >> Anyone welcome to update all the pom.xml files. >> >> >> On Tue, Oct 11, 2016 at 10:02 AM, Luca Burgazzoli >> wrote: >>> Hello everyone, >>> >>> I've just noticed that the master branch of camel is still using >>> 2.18.0-SNAPSHOT as version, shouldn't it be 2.19.0-SNAPSHOT ? >>> >>> >>> >>> --- >>> Luca Burgazzoli >> >> >> >> -- >> Claus Ibsen >> - >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2
Enhance ObjectHelper's after/before/between
Hello,
I've sometime had the need to find a string after a separator, lookup
an object based on the result value and then use it to process
something, like:
String after = ObjectHelper.after(key, ":");
if (after != null) {
MyStuff s = cache.get(after)
if (s != null) {
s.doSomething(exchange)
}
}
So I wonder whether it makes sense to add a 'fluent' variant to these
functions to impement such pattern, like:
Optional after(String value, String delimiter,
Function function)
The we could do something like:
ObjectHelper.after(key, ":", cache::get).ifPresent(s ->
s.doSomething(exchange));
Make sense ?
---
Luca Burgazzoli
Re: Enhance ObjectHelper's after/before/between
An option would be to move before/after/between in StringHelper and
wrapping them in ObjectHelper with @Deprecated annotation, the
proposed new methods should go straight to StringHelper.
---
Luca Burgazzoli
On Fri, Oct 14, 2016 at 2:25 PM, Antonin Stefanutti
wrote:
> Hi Luca,
>
> Make sense to me. As I refactored Camel CDI with Java 8 in Camel 2.18.0, I
> found using Optional as return type of internal util methods quite useful in
> term of client conciseness / readability compared to null handling.
>
> I’m wondering whether that should be added to StringHelper instead of
> ObjectHelper though the existing methods are in the later so probably a
> trade-off between consistency / locality and relevancy.
>
> Antonin
>
>> On 14 Oct 2016, at 14:11, Luca Burgazzoli wrote:
>>
>> Hello,
>>
>> I've sometime had the need to find a string after a separator, lookup
>> an object based on the result value and then use it to process
>> something, like:
>>
>>String after = ObjectHelper.after(key, ":");
>>if (after != null) {
>>MyStuff s = cache.get(after)
>>if (s != null) {
>>s.doSomething(exchange)
>>}
>>}
>>
>>
>> So I wonder whether it makes sense to add a 'fluent' variant to these
>> functions to impement such pattern, like:
>>
>> Optional after(String value, String delimiter,
>> Function function)
>>
>>
>> The we could do something like:
>>
>>ObjectHelper.after(key, ":", cache::get).ifPresent(s ->
>> s.doSomething(exchange));
>>
>>
>> Make sense ?
>>
>>
>> ---
>> Luca Burgazzoli
>
Re: Enhance ObjectHelper's after/before/between
I've logged two JIRA:
- https://issues.apache.org/jira/browse/CAMEL-10389 --> Move some
function to Stringhelper (target 2.19)
- https://issues.apache.org/jira/browse/CAMEL-10390 --> Enhance
before/after/between (target 2.18.1)
---
Luca Burgazzoli
On Fri, Oct 14, 2016 at 2:38 PM, Antonin Stefanutti
wrote:
>
>> On 14 Oct 2016, at 14:35, Luca Burgazzoli wrote:
>>
>> An option would be to move before/after/between in StringHelper and
>> wrapping them in ObjectHelper with @Deprecated annotation, the
>> proposed new methods should go straight to StringHelper.
>
> I didn’t dare to propose you that but that’s exactly what I had in mind ;-)
> That being said, I don’t have the historic being this so there may be a good
> reason.
>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Fri, Oct 14, 2016 at 2:25 PM, Antonin Stefanutti
>> wrote:
>>> Hi Luca,
>>>
>>> Make sense to me. As I refactored Camel CDI with Java 8 in Camel 2.18.0, I
>>> found using Optional as return type of internal util methods quite useful
>>> in term of client conciseness / readability compared to null handling.
>>>
>>> I’m wondering whether that should be added to StringHelper instead of
>>> ObjectHelper though the existing methods are in the later so probably a
>>> trade-off between consistency / locality and relevancy.
>>>
>>> Antonin
>>>
>>>> On 14 Oct 2016, at 14:11, Luca Burgazzoli wrote:
>>>>
>>>> Hello,
>>>>
>>>> I've sometime had the need to find a string after a separator, lookup
>>>> an object based on the result value and then use it to process
>>>> something, like:
>>>>
>>>> String after = ObjectHelper.after(key, ":");
>>>> if (after != null) {
>>>> MyStuff s = cache.get(after)
>>>> if (s != null) {
>>>> s.doSomething(exchange)
>>>> }
>>>> }
>>>>
>>>>
>>>> So I wonder whether it makes sense to add a 'fluent' variant to these
>>>> functions to impement such pattern, like:
>>>>
>>>>Optional after(String value, String delimiter,
>>>> Function function)
>>>>
>>>>
>>>> The we could do something like:
>>>>
>>>> ObjectHelper.after(key, ":", cache::get).ifPresent(s ->
>>>> s.doSomething(exchange));
>>>>
>>>>
>>>> Make sense ?
>>>>
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>
>
Re: Camel 3.0 ideas: Remove throws Exception from API signatures and use unchecked exceptions
This may be an interesting read: https://vanilla-java.github.io/2016/06/21/Reviewing-Exception-Handling.html --- Luca Burgazzoli On Thu, Oct 27, 2016 at 12:47 PM, Nicola Ferraro wrote: > Of course, if this targets 3.0 and so we don't have to care much about > backward compatibility, removing checked exception from the API is > something worth doing. > > On Thu, Oct 27, 2016 at 12:37 PM, Nicola Ferraro > wrote: > >> My 2 cents. >> >> A fake "throws Exception" put in place "for future usage" can be removed >> IMO. But turning an exception into a RuntimeException may affect a route >> behaviour if the Camel API you're talking about is available for the end >> users in DSL (eg. error handling policies). >> >> So, we should analyze it case by case. >> >> On the other hand, I see that some functional transformations (eg. >> https://github.com/apache/camel/blob/master/camel-core/ >> src/main/java/org/apache/camel/builder/ExpressionClause.java#L155-L161) >> can also accept a checked function or supplier. >> >> I mean, we can solve the problem almost like the Javaslang guys did >> (greatly !) for the Java collections: https://github. >> com/javaslang/javaslang/blob/master/javaslang/src/main/ >> java/javaslang/control/Try.java#L728-L743. >> >> >> >> On Wed, Oct 26, 2016 at 6:47 PM, Antonin Stefanutti > > wrote: >> >>> Hi, >>> >>> Would you think that makes sense to remove the 'throws Exception' from a >>> number of Camel API signatures as well as using unchecked exceptions >>> instead? >>> >>> While this may be a matter of opinion still debated, there are a couple >>> resources that gives some guidelines on the topic and that may help >>> answering that question: >>> >>> - "How to Design a Good API and Why it Matters" presentation and >>> "Effective Java" from Joshua Bloch >>> - https://docs.oracle.com/javase/tutorial/essential/exceptions >>> /runtime.html >>> >>> I raise the question as I've encountered yet another case where checked >>> exceptions fail to deliver on their promises, that is with functional >>> interfaces (stream, lambda, ...) introduced in Java 8. There is a lot of >>> resources out there describing the problem in details: >>> >>> - http://stackoverflow.com/questions/27644361/how-can-i-throw- >>> checked-exceptions-from-inside-java-8-streams. >>> - http://literatejava.com/exceptions/checked-exceptions-javas- >>> biggest-mistake/ >>> >>> Hence the question. WDYT? >>> >>> Antonin >> >> >>
Re: Camel 2.19 - Java 8 DSL
Hi Claus, do you have any simple use case to be used as reference to prototype new Java 8 DSL extensions ? --- Luca Burgazzoli On Tue, Nov 1, 2016 at 12:09 PM, Claus Ibsen wrote: > Hi > > I would like to see if we could experiment with continue improving the > Java DSL for Java 8 to see if we can make it more Java 8'ish for > Content Enricher and Aggregator EIP. They require using the > AggregationStrategy interface when you need to merge the 2 exchanges. > And it has a POJO binding that allows you to build custom POJO classes > without implementing this interface but following a convention. See > more at: http://camel.apache.org/aggregator2 in the bottom. > > And there may be other areas we could ponder about. But the > AggregationStrategy has always been one I would like to see can be > done simpler when you have simpler use-cases, and hence the POJOs or > the FlexibleAggregationStragegyBuilder we have in camel-core > somewhere. > > This is just a quick email to get this though out. > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 2.19 - Java 8 DSL
Something like:
public void configure() throws Exception {
from("direct:start")
.aggregate()
.always()
.body(String.class, (existing, next) -> next + existing)
.completionSize(3)
.to("mock:result");
}
---
Luca Burgazzoli
On Tue, Nov 1, 2016 at 7:44 PM, Claus Ibsen wrote:
> Hi
>
> Not yet, but maybe some of those POJO examples in the aggregator EIP.
> For example to supply a function as a lambda that is used for
> aggregation. For example how would it look like if it was just a basic
> function for String concat?
>
> For example this example
>
> public void configure() throws Exception {
> from("direct:start")
> .aggregate(constant(true),
> AggregationStrategies.bean(MyBodyAppender.class, "append"))
> .completionSize(3)
> .to("mock:result");
> }
>
>
> Also wonder if the lambda can cope with either working with exchange
> vs message body only. A bit like what you can do today for message
> transformation you did.
>
>
> On Tue, Nov 1, 2016 at 1:00 PM, Luca Burgazzoli wrote:
>> Hi Claus,
>>
>> do you have any simple use case to be used as reference to prototype
>> new Java 8 DSL extensions ?
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Tue, Nov 1, 2016 at 12:09 PM, Claus Ibsen wrote:
>>> Hi
>>>
>>> I would like to see if we could experiment with continue improving the
>>> Java DSL for Java 8 to see if we can make it more Java 8'ish for
>>> Content Enricher and Aggregator EIP. They require using the
>>> AggregationStrategy interface when you need to merge the 2 exchanges.
>>> And it has a POJO binding that allows you to build custom POJO classes
>>> without implementing this interface but following a convention. See
>>> more at: http://camel.apache.org/aggregator2 in the bottom.
>>>
>>> And there may be other areas we could ponder about. But the
>>> AggregationStrategy has always been one I would like to see can be
>>> done simpler when you have simpler use-cases, and hence the POJOs or
>>> the FlexibleAggregationStragegyBuilder we have in camel-core
>>> somewhere.
>>>
>>> This is just a quick email to get this though out.
>>>
>>>
>>>
>>> --
>>> 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: Camel 2.19 - Java 8 DSL
Yep, "always()" was how my mind translated "constant(true)", do not
know how it ended up in the mail :O
What about:
aggregate()
.correlation()
.body(String.class, b -> b.substring(0, 3))
.strategy()
.body(String.class, (existing, next) -> next + existing))
.completionSize(3)
---
Luca Burgazzoli
On Wed, Nov 2, 2016 at 12:07 PM, Claus Ibsen wrote:
> On Tue, Nov 1, 2016 at 4:15 PM, Luca Burgazzoli wrote:
>> Something like:
>>
>> public void configure() throws Exception {
>> from("direct:start")
>> .aggregate()
>> .always()
>> .body(String.class, (existing, next) -> next + existing)
>> .completionSize(3)
>> .to("mock:result");
>> }
>>
>
> Yeah that seems really good. And I guess always is a shorthand for
> constant(true). For that we may need to ponder if we want to have
> these in the Java DSL as they are not in XML DSL, so people cannot map
> from Java <-> XML as easily.
>
> So its maybe
>
> aggregate()
> .constant(true)
> .withStrategy(body(String.class, (existing, next) -> next + existing))
> .completionSize(3)
>
> And for Content Enricher
>
> enrich("http://foobar";)
> .withStrategy(body(String.class, (existing, next) -> next + existing))
>
>
>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Tue, Nov 1, 2016 at 7:44 PM, Claus Ibsen wrote:
>>> Hi
>>>
>>> Not yet, but maybe some of those POJO examples in the aggregator EIP.
>>> For example to supply a function as a lambda that is used for
>>> aggregation. For example how would it look like if it was just a basic
>>> function for String concat?
>>>
>>> For example this example
>>>
>>> public void configure() throws Exception {
>>> from("direct:start")
>>> .aggregate(constant(true),
>>> AggregationStrategies.bean(MyBodyAppender.class, "append"))
>>> .completionSize(3)
>>> .to("mock:result");
>>> }
>>>
>>>
>>> Also wonder if the lambda can cope with either working with exchange
>>> vs message body only. A bit like what you can do today for message
>>> transformation you did.
>>>
>>>
>>> On Tue, Nov 1, 2016 at 1:00 PM, Luca Burgazzoli
>>> wrote:
>>>> Hi Claus,
>>>>
>>>> do you have any simple use case to be used as reference to prototype
>>>> new Java 8 DSL extensions ?
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Tue, Nov 1, 2016 at 12:09 PM, Claus Ibsen wrote:
>>>>> Hi
>>>>>
>>>>> I would like to see if we could experiment with continue improving the
>>>>> Java DSL for Java 8 to see if we can make it more Java 8'ish for
>>>>> Content Enricher and Aggregator EIP. They require using the
>>>>> AggregationStrategy interface when you need to merge the 2 exchanges.
>>>>> And it has a POJO binding that allows you to build custom POJO classes
>>>>> without implementing this interface but following a convention. See
>>>>> more at: http://camel.apache.org/aggregator2 in the bottom.
>>>>>
>>>>> And there may be other areas we could ponder about. But the
>>>>> AggregationStrategy has always been one I would like to see can be
>>>>> done simpler when you have simpler use-cases, and hence the POJOs or
>>>>> the FlexibleAggregationStragegyBuilder we have in camel-core
>>>>> somewhere.
>>>>>
>>>>> This is just a quick email to get this though out.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 2.19 - Java 8 DSL
And with some love for the completion too:
aggregate()
.correlation()
.body(String.class, b -> b.substring(0, 3))
.strategy()
.body(String.class, (existing, next) -> next + existing))
.completion()
.body(String.class, b -> b.size() > 30)
---
Luca Burgazzoli
On Wed, Nov 2, 2016 at 12:28 PM, Luca Burgazzoli wrote:
> Yep, "always()" was how my mind translated "constant(true)", do not
> know how it ended up in the mail :O
>
> What about:
>
> aggregate()
> .correlation()
> .body(String.class, b -> b.substring(0, 3))
> .strategy()
> .body(String.class, (existing, next) -> next + existing))
> .completionSize(3)
>
> ---
> Luca Burgazzoli
>
>
> On Wed, Nov 2, 2016 at 12:07 PM, Claus Ibsen wrote:
>> On Tue, Nov 1, 2016 at 4:15 PM, Luca Burgazzoli
>> wrote:
>>> Something like:
>>>
>>> public void configure() throws Exception {
>>> from("direct:start")
>>> .aggregate()
>>> .always()
>>> .body(String.class, (existing, next) -> next + existing)
>>> .completionSize(3)
>>> .to("mock:result");
>>> }
>>>
>>
>> Yeah that seems really good. And I guess always is a shorthand for
>> constant(true). For that we may need to ponder if we want to have
>> these in the Java DSL as they are not in XML DSL, so people cannot map
>> from Java <-> XML as easily.
>>
>> So its maybe
>>
>> aggregate()
>> .constant(true)
>> .withStrategy(body(String.class, (existing, next) -> next + existing))
>> .completionSize(3)
>>
>> And for Content Enricher
>>
>> enrich("http://foobar";)
>> .withStrategy(body(String.class, (existing, next) -> next + existing))
>>
>>
>>
>>> ---
>>> Luca Burgazzoli
>>>
>>>
>>> On Tue, Nov 1, 2016 at 7:44 PM, Claus Ibsen wrote:
>>>> Hi
>>>>
>>>> Not yet, but maybe some of those POJO examples in the aggregator EIP.
>>>> For example to supply a function as a lambda that is used for
>>>> aggregation. For example how would it look like if it was just a basic
>>>> function for String concat?
>>>>
>>>> For example this example
>>>>
>>>> public void configure() throws Exception {
>>>> from("direct:start")
>>>> .aggregate(constant(true),
>>>> AggregationStrategies.bean(MyBodyAppender.class, "append"))
>>>> .completionSize(3)
>>>> .to("mock:result");
>>>> }
>>>>
>>>>
>>>> Also wonder if the lambda can cope with either working with exchange
>>>> vs message body only. A bit like what you can do today for message
>>>> transformation you did.
>>>>
>>>>
>>>> On Tue, Nov 1, 2016 at 1:00 PM, Luca Burgazzoli
>>>> wrote:
>>>>> Hi Claus,
>>>>>
>>>>> do you have any simple use case to be used as reference to prototype
>>>>> new Java 8 DSL extensions ?
>>>>>
>>>>> ---
>>>>> Luca Burgazzoli
>>>>>
>>>>>
>>>>> On Tue, Nov 1, 2016 at 12:09 PM, Claus Ibsen
>>>>> wrote:
>>>>>> Hi
>>>>>>
>>>>>> I would like to see if we could experiment with continue improving the
>>>>>> Java DSL for Java 8 to see if we can make it more Java 8'ish for
>>>>>> Content Enricher and Aggregator EIP. They require using the
>>>>>> AggregationStrategy interface when you need to merge the 2 exchanges.
>>>>>> And it has a POJO binding that allows you to build custom POJO classes
>>>>>> without implementing this interface but following a convention. See
>>>>>> more at: http://camel.apache.org/aggregator2 in the bottom.
>>>>>>
>>>>>> And there may be other areas we could ponder about. But the
>>>>>> AggregationStrategy has always been one I would like to see can be
>>>>>> done simpler when you have simpler use-cases, and hence the POJOs or
>>>>>> the FlexibleAggregationStragegyBuilder we have in camel-core
>>>>>> somewhere.
>>>>>>
>>>>>> This is just a quick email to get this though out.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>
>>
>>
>> --
>> Claus Ibsen
>> -
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 2.19 - Java 8 DSL
I've created this issue https://issues.apache.org/jira/browse/CAMEL-10438
I'll try to prototype some stuffs later this week
---
Luca Burgazzoli
On Wed, Nov 2, 2016 at 2:33 PM, Luca Burgazzoli wrote:
> And with some love for the completion too:
>
> aggregate()
> .correlation()
> .body(String.class, b -> b.substring(0, 3))
> .strategy()
> .body(String.class, (existing, next) -> next + existing))
> .completion()
> .body(String.class, b -> b.size() > 30)
>
> ---
> Luca Burgazzoli
>
>
> On Wed, Nov 2, 2016 at 12:28 PM, Luca Burgazzoli
> wrote:
>> Yep, "always()" was how my mind translated "constant(true)", do not
>> know how it ended up in the mail :O
>>
>> What about:
>>
>> aggregate()
>> .correlation()
>> .body(String.class, b -> b.substring(0, 3))
>> .strategy()
>> .body(String.class, (existing, next) -> next + existing))
>> .completionSize(3)
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Wed, Nov 2, 2016 at 12:07 PM, Claus Ibsen wrote:
>>> On Tue, Nov 1, 2016 at 4:15 PM, Luca Burgazzoli
>>> wrote:
>>>> Something like:
>>>>
>>>> public void configure() throws Exception {
>>>> from("direct:start")
>>>> .aggregate()
>>>> .always()
>>>> .body(String.class, (existing, next) -> next + existing)
>>>> .completionSize(3)
>>>> .to("mock:result");
>>>> }
>>>>
>>>
>>> Yeah that seems really good. And I guess always is a shorthand for
>>> constant(true). For that we may need to ponder if we want to have
>>> these in the Java DSL as they are not in XML DSL, so people cannot map
>>> from Java <-> XML as easily.
>>>
>>> So its maybe
>>>
>>> aggregate()
>>> .constant(true)
>>> .withStrategy(body(String.class, (existing, next) -> next + existing))
>>> .completionSize(3)
>>>
>>> And for Content Enricher
>>>
>>> enrich("http://foobar";)
>>> .withStrategy(body(String.class, (existing, next) -> next + existing))
>>>
>>>
>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Tue, Nov 1, 2016 at 7:44 PM, Claus Ibsen wrote:
>>>>> Hi
>>>>>
>>>>> Not yet, but maybe some of those POJO examples in the aggregator EIP.
>>>>> For example to supply a function as a lambda that is used for
>>>>> aggregation. For example how would it look like if it was just a basic
>>>>> function for String concat?
>>>>>
>>>>> For example this example
>>>>>
>>>>> public void configure() throws Exception {
>>>>> from("direct:start")
>>>>> .aggregate(constant(true),
>>>>> AggregationStrategies.bean(MyBodyAppender.class, "append"))
>>>>> .completionSize(3)
>>>>> .to("mock:result");
>>>>> }
>>>>>
>>>>>
>>>>> Also wonder if the lambda can cope with either working with exchange
>>>>> vs message body only. A bit like what you can do today for message
>>>>> transformation you did.
>>>>>
>>>>>
>>>>> On Tue, Nov 1, 2016 at 1:00 PM, Luca Burgazzoli
>>>>> wrote:
>>>>>> Hi Claus,
>>>>>>
>>>>>> do you have any simple use case to be used as reference to prototype
>>>>>> new Java 8 DSL extensions ?
>>>>>>
>>>>>> ---
>>>>>> Luca Burgazzoli
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 1, 2016 at 12:09 PM, Claus Ibsen
>>>>>> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> I would like to see if we could experiment with continue improving the
>>>>>>> Java DSL for Java 8 to see if we can make it more Java 8'ish for
>>>>>>> Content Enricher and Aggregator EIP. They require using the
>>>>>>> AggregationStrategy interface when you need to merge the 2 exchanges.
>>>>>>> And it has a POJO binding that allows you to build custom POJO classes
>>>>>>> without implementing this interface but following a convention. See
>>>>>>> more at: http://camel.apache.org/aggregator2 in the bottom.
>>>>>>>
>>>>>>> And there may be other areas we could ponder about. But the
>>>>>>> AggregationStrategy has always been one I would like to see can be
>>>>>>> done simpler when you have simpler use-cases, and hence the POJOs or
>>>>>>> the FlexibleAggregationStragegyBuilder we have in camel-core
>>>>>>> somewhere.
>>>>>>>
>>>>>>> This is just a quick email to get this though out.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
camel-properties enhancements
Hi everyone, I've been working on a blueprint based applications for soem weeks and I had to deal with a number of properties placeholders so I've used camel-properties and I found some issues/limitation for which I've raised the following JIRA: 1. CAMEL-10352: Optionally delegate to Aries PropertyEvaluator services in BlueprintPropertiesParser 2. CAMEL-10393: Add an option to disable using default value if a property does not exists 3. CAMEL-10417: Support adding location using child nodes of propertyPlaceholder element 4. CAMEL-10419: Allow to individually set whether to silently ignore a missing location CAMEL-10352 and CAMEL-10393 have already been merged and I've just completed the implementation of CAMEL-10417 and CAMEL-10419 which you can find in my fork: https://github.com/lburgazzoli/apache-camel/tree/camel-properties Before merge it I'd like to have your opinion as there are some small changes about the XML configuration I'm going to highlight here: 1. As today, you can customize the property placeholders with the tag propertyPlaceholder where the attribute location is mandatory and that is fine untill you just want to register your own function in blueprint which lead to something like that: So you may think that you have no locations set but that is not true because by default camel-blueprint detects OSGi blueprint property placeholders services and add them to the mix. Of course you can disable such behavior but I found this a little bit confusing so I made it not more mandatory (in fact that is the same behavior you'd have if you define a PropertiesComponent bean instead of using the propertyPlaceholder tag) and now you can now write it as: 2. As today to add new properties placeholder locations you need to set them with the location attribute using comma as separator and this work just fine but it may result confusing if you need to deal with a number of properties files. In addition you can't set which location is required and which may be missing as the option to ignore missing location is global so I've enhanced the propertyPlaceholder tag in a way you can add locations as: Note that the attribute resolver and optional are not mandatory and have classpath and false as default value respectivley. Of course setting locations via location attribute is still supported and it has been enhanced to support additional attributes, i.e.: Note that the locations defined by the propertiesLocation tag are added to those defined in location attribute. Any objection/suggestion on such implementation ? Regards, Luca --- Luca Burgazzoli
Re: Contributing file in Apache Camel
+1 --- Luca Burgazzoli On Fri, Nov 25, 2016 at 9:59 AM, Andrea Cosentino wrote: > +1. > > Love the idea. > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix Committer > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > On Friday, November 25, 2016 9:58 AM, Jean-Baptiste Onofré > wrote: > +1 > > Good idea. > > Regards > JB > > > On Nov 25, 2016, 09:49, at 09:49, Claus Ibsen wrote: >>Hi >> >>I would like if we could add a CONTRIBUTING.adoc file in the root of >>Apache Camel source code as that is a common way of providing such >>information to users, how they can contribute to the project. >> >>Projects at github often do this, and also the github points users to >>this file. >> >>https://help.github.com/articles/setting-guidelines-for-repository-contributors/ >> >>We do have some information at >>http://camel.apache.org/contributing >> >>Which we can polish and add the good parts to this file. >> >> >>We can also find inspiration at sister ASF projects where some of them >>have this file >>https://github.com/apache/spark >> >> >> >>-- >>Claus Ibsen >>- >>http://davsclaus.com @davsclaus >>Camel in Action 2: https://www.manning.com/ibsen2
Re: [VOTE] Release Apache Camel 2.17.4
+1 --- Luca Burgazzoli On Mon, Nov 28, 2016 at 4:52 AM, Willem Jiang wrote: > +1. > > Willem Jiang > > Blog: http://willemjiang.blogspot.com (English) > http://jnn.iteye.com (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > -- Forwarded message -- > From: Christian Müller > Date: Sat, Nov 26, 2016 at 10:02 PM > Subject: Re: [VOTE] Release Apache Camel 2.17.4 > To: dev@camel.apache.org > > > +1 > > Best regards, > Christian > > Am 24.11.2016 9:05 vorm. schrieb "Gregor Zurowski" >: > >> Hi Everyone: >> >> This is a vote to release Apache Camel 2.17.4, a new patch release >> that includes 40+ fixes and improvements. >> >> Release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa? >> version=12338067&projectId=12311211 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecamel-1060/ >> >> Tarballs: https://repository.apache.org/content/repositories/ >> orgapachecamel-1060/org/apache/camel/apache-camel/2.17.4/ >> >> Tag: https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h= >> a4ab2f6d773a0d988a58c14c0aa32fcf0667dd1e >> >> Please test this release candidate and cast your vote. >> [ ] +1 Release the binary as Apache Camel 2.17.4 >> [ ] -1 Veto the release (provide specific comments) >> >> The vote is open for at least 72 hours. >> >> Thanks, >> Gregor >>
Re: [VOTE] Release Apache Camel 2.18.1
+1 --- Luca Burgazzoli On Mon, Nov 28, 2016 at 6:12 PM, Christian Müller wrote: > +1 > > Best regards, > Christian > > > > On Sun, Nov 27, 2016 at 9:50 PM, Gregor Zurowski > wrote: > >> Hi Everyone: >> >> This is a vote to release Apache Camel 2.18.1, a new patch release >> that includes ~68 fixes and improvements. >> >> Release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa? >> version=12338295&projectId=12311211 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecamel-1061/ >> >> Tarballs: https://repository.apache.org/content/repositories/ >> orgapachecamel-1061/org/apache/camel/apache-camel/2.18.1/ >> >> Tag: https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h= >> 94bd0782872c813a0d4c0d0a4bf753be24b9ad15 >> >> Please test this release candidate and cast your vote. >> [ ] +1 Release the binary as Apache Camel 2.18.1 >> [ ] -1 Veto the release (provide specific comments) >> >> The vote is open for at least 72 hours. >> >> Thanks, >> Gregor >>
camel spring-boot starter changes
Hello, I've implemented the following JIRA related to camel and spring-boot in my own fork: 1. https://issues.apache.org/jira/browse/CAMEL-10550 2. https://issues.apache.org/jira/browse/CAMEL-10551 3. https://issues.apache.org/jira/browse/CAMEL-10552 So now you have an option to turn on/off dataformats, languages and components as you have for most of the spring-boot components i.e: you can turn off all the data-formats except yaml-snakeyaml: camel-dataformat.enable = false camel-dataformat.yaml-snakeyaml = true Dataformats and languages auto configured beans are now annotated with prototype scope, this is required untill CAMEL-10542 is fixed on camel-core so we avoid having undefined behaviors if one mixes spring-boot and xml routes. Component auto configured beans are annotated as lazy so that they are created when needed. You can find a comparison between my fork and master here: https://github.com/apache/camel/compare/master...lburgazzoli:CAMEL-10550 Let me know if you have any objection to merge it. Best regards, Luca --- Luca Burgazzoli
Deprecated components / code JIRA
Hello everyone, would it make sense to open a JIRA to track the deprecated components and code we want to remove for next camel release (2.19 or 3.0) ? So people can know in advance what will be removed and we can easily list them in the change-log ? --- Luca Burgazzoli
Move spring-boot starters to platforms/spring-boot
Hello everyone, as components-starter is platform specific (spring-boot), would it make sense to move it to platforms/spring-boot ? --- Luca Burgazzoli
Re: Move spring-boot starters to platforms/spring-boot
I know, that was also my concern. However I think that to highlight how nicely camel plays with other tecnologies we should rely on a better landing page rather than the repository layout. On Fri, 16 Dec 2016 at 20:00, Claus Ibsen wrote: > As long the artifactId is not change then its okay to move where the > > source code is. > > > > SB is so popular and having components-starter in the root highlights > > that Camel has great SB support. > > > > So its both good and bad. > > > > > > On Fri, Dec 16, 2016 at 5:52 PM, Luca Burgazzoli > wrote: > > > Hello everyone, > > > > > > as components-starter is platform specific (spring-boot), would it > > > make sense to move it to platforms/spring-boot ? > > > > > > --- > > > Luca Burgazzoli > > > > > > > > -- > > Claus Ibsen > > - > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > -- -- Luca Burgazzoli
Re: [VOTE] Apache Camel 2.16.5
+1 (binding) --- Luca Burgazzoli On Sun, Dec 18, 2016 at 10:17 PM, Christian Müller wrote: > +1 > > Best, > Christian > > Christian > - > > Software Integration Specialist > > Apache Member > V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer > Apache Incubator PMC Member > > https://www.linkedin.com/pub/christian-mueller/11/551/642 > > On Fri, Dec 16, 2016 at 8:18 PM, Daniel Kulp wrote: > >> >> This is a vote to release Apache Camel 2.16.5, a new patch release that >> includes a couple high importance fixes. >> >> Release notes: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa? >> version=12338575&projectId=12311211 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecamel-1062/ >> >> Tarballs: >> https://repository.apache.org/content/repositories/ >> orgapachecamel-1062/org/apache/camel/apache-camel/2.16.5/ >> >> Tag: >> https://git1-us-west.apache.org/repos/asf?p=camel.git;a=tag;h= >> 0f4562325af958139b82917342a2eb82305467bd >> >> Please test this release candidate and cast your vote. >> [ ] +1 Release the binary as Apache Camel 2.16.5 >> [ ] -1 Don’t release (provide specific comments) >> >> The vote is open for at least 72 hours. >> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >>
Re: Move spring-boot starters to platforms/spring-boot
Done: https://issues.apache.org/jira/browse/CAMEL-10622 --- Luca Burgazzoli On Tue, Dec 20, 2016 at 9:30 AM, Claus Ibsen wrote: > I suggest to log a JIRA so this is not forgotten, and target it for 2.19 > > On Sun, Dec 18, 2016 at 10:03 AM, Claus Ibsen wrote: >> On Sat, Dec 17, 2016 at 1:54 PM, Luca Burgazzoli >> wrote: >>> I know, that was also my concern. >>> >>> However I think that to highlight how nicely camel plays with other >>> tecnologies we should rely on a better landing page rather than the >>> repository layout. >>> >> >> Yeah sure that is part of the effort to do a new website and >> documentation as well. But its a long tough work to get there. >> >> Its okay to move the starters to platforms/spring-boot/component-starters. >> >> Mind there is some work to do besides the move, to adjust various >> maven tooling that rely on the current directory location, which would >> need to be adjusted. Also for camel-catalog that gathers which SB >> starters we have. >> >> >> >>> >>> On Fri, 16 Dec 2016 at 20:00, Claus Ibsen wrote: >>> >>>> As long the artifactId is not change then its okay to move where the >>>> >>>> source code is. >>>> >>>> >>>> >>>> SB is so popular and having components-starter in the root highlights >>>> >>>> that Camel has great SB support. >>>> >>>> >>>> >>>> So its both good and bad. >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Dec 16, 2016 at 5:52 PM, Luca Burgazzoli >>>> wrote: >>>> >>>> > Hello everyone, >>>> >>>> > >>>> >>>> > as components-starter is platform specific (spring-boot), would it >>>> >>>> > make sense to move it to platforms/spring-boot ? >>>> >>>> > >>>> >>>> > --- >>>> >>>> > Luca Burgazzoli >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Claus Ibsen >>>> >>>> - >>>> >>>> http://davsclaus.com @davsclaus >>>> >>>> Camel in Action 2: https://www.manning.com/ibsen2 >>>> >>>> -- >>> -- >>> 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: Tests failure
One seems related to something I did, will have a look soon --- Luca Burgazzoli On Fri, Jan 13, 2017 at 11:05 AM, Andrea Cosentino wrote: > It looks like we aren't green at the moment > > https://builds.apache.org/job/Camel.trunk.fulltest.java8/1107/ > > > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix Committer > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd
Re: Camel 2.19 Roadmap
4) done 5) I should start working on auto config for the service call soon On Mon, 16 Jan 2017 at 10:29, Claus Ibsen wrote: > Hi > > > > There is a bunch of stuff which we can/should have on the roadmap to > > complete for the Camel 2.19 release. > > > > Here is on top of my head > > > > 1) > > Finish migrating the wiki documentation to adoc files. I think its > > most of the EIP patterns that are missing. There is a basic list of > > EIPs here: > https://github.com/apache/camel/blob/master/camel-core/readme-eip.adoc > > > > 2) > > Generate documentation and website. Maybe documentation first and then > > we come up with a modern website later - when we have a new logo as > > well. > > > > 3) > > Mark more stuff to @deprecate so we dont drag them into Camel 3.0. > > This is both components / and other artifacts. > > And as well the camel-core APIs where there is maybe more we can deprecate. > > For example the old stuff that was created prior to the component docs > > we do now with the apt plugin at build time instead of this old code > > with runtime that dont really pan out anyway. > > > > 4) > > Move spring-boot starters into the platforms folder. There is a ticket > > about this. > > > > 5) > > More improvements to spring boot auto configuration. We have a bunch > > of tickets on that. > > > > 6) > > Look at the health check API and see if there is something we can get > > started on. > > Possible some API to integrate with spring boot actuators (when using > > SB) and allow each component to provide their own checks so they can > > be implemented ad-hoc. There is a ticket about this. > > > > 7) > > Possible some more teaks to camel-catalog based on feedback from IDEA > > plugin and the maven validate goal. > > > > 8) > > That CDI JEE transaction PR on github. > > Ideally we would have had a transaction API in camel-core and then one > > impl for camel-spring, and then another for camel-cdi-jee. But that > > may require too much work. > > > > 9) > > Work on the Java 8 DSL such as get more community feedback, and then > > resolve the TODOs with the documentation updates and look into other > > areas where the API can benefit from Java 8 lambdas and whatnot. I > > dont think we have a ticket about this. > > > > 10) > > Karaf users may want to improve/finish up the camel-test-karaf module > > so its more usable and end users can use it to test integration tests > > with Camel and Karaf. > > > > 11) > > Introduce Camel Connectors (more about this later) > > > > > > Anything else? > > > > > > > > > > > > -- > > Claus Ibsen > > - > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > -- -- Luca Burgazzoli
Re: [VOTE] Release Apache Camel 2.17.5
+1 --- Luca Burgazzoli On Wed, Jan 18, 2017 at 8:49 AM, Gregor Zurowski wrote: > Hi Everyone: > > This is a vote to release Apache Camel 2.17.5, a new patch release > that includes 20+ fixes and improvements. > > Release notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12338762&projectId=12311211 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachecamel-1063/ > > Tarballs: > https://repository.apache.org/content/repositories/orgapachecamel-1063/org/apache/camel/apache-camel/2.17.5/ > > Tag: > https://git-wip-us.apache.org/repos/asf?p=camel.git;a=commit;h=a08cc255d6fd9148d652be52c25a4e95dcbff600 > > Please test this release candidate and cast your vote. > [ ] +1 Release the binary as Apache Camel 2.17.5 > [ ] -1 Veto the release (provide specific comments) > > The vote is open for at least 72 hours. > > Thanks, > Gregor
Re: Camel 2.19 Roadmap
9) I'm currently going through the examples and tests trying to re-implement them using java 8 and see which part of the dsl can benefit from lambdas & co, I should open a new JIRA soon --- Luca Burgazzoli On Tue, Jan 17, 2017 at 9:48 AM, Nicola Ferraro wrote: > 5) I started taking some tickets about spring-boot auto configuration > > I also plan to finish the component for reactive streams before we release. > > On Tue, Jan 17, 2017 at 9:44 AM, Antonin Stefanutti > wrote: > >> >> > On 16 Jan 2017, at 10:28, Claus Ibsen wrote: >> > >> > 8) >> > That CDI JEE transaction PR on github. >> > Ideally we would have had a transaction API in camel-core and then one >> > impl for camel-spring, and then another for camel-cdi-jee. But that >> > may require too much work. >> >> I may be able to work on it unless anybody else want to take it. >> >> Antonin >> >> >>
Re: [VOTE] Release Apache Camel 2.18.2
+1 --- Luca Burgazzoli On Fri, Jan 27, 2017 at 8:32 AM, Nicola Ferraro wrote: > +1 (non-binding) > > Nicola > > Il 27 gen 2017 7:18 AM, "Claus Ibsen" ha scritto: > >> Hi >> >> Okay log a JIRA and provide a PR so it can be fixed for 2.18.3. >> >> Its an easy workaround for users to setup what version to use in their >> pom.xml >> >> On Fri, Jan 27, 2017 at 1:34 AM, Mark Mindenhall >> wrote: >> > –1 (non-binding) >> > >> > I went to test 2.18.1 (then 2.18.2-SNAPSHOT) on my project, and >> discovered a problem with the camel-ahc component. It’s complicated…but >> here’s what’s happening. >> > >> > AsyncHttpClient 2.0.15 (used by Camel 2.18.2-SNAPSHOT) depends on netty >> 4.0.41.Final. AsyncHttpClient 2.0.15 was using the io.netty.util.internal >> package (which presumably is so named because netty intends it for internal >> use only). In the latest netty (4.1.7.Final, backported to 4.0.43.Final), >> netty refactored the code that AsyncHttpClient was using. >> > >> > The problem here arises when there are multiple modules within the >> project with dependencies on netty, and maven dependency resolution chooses >> the latest version referenced by any pom. In the case of my project, the >> dependency tree shows version 4.1.7.Final is used, which breaks >> AsyncHttpClient 2.0.15. >> > >> > AsyncHttpClient has fixed this problem, so I think (hope) updating >> ahc-version to 2.0.27 in parent/pom.xml will resolve this problem. >> > >> > Thanks, >> > Mark >> > >> > >> > On January 22, 2017 at 3:26:54 PM, Gregor Zurowski ( >> gre...@list.zurowski.org<mailto:gre...@list.zurowski.org>) wrote: >> > >> > Hi Everyone: >> > >> > This is a vote to release Apache Camel 2.18.2, a new patch release >> > that includes 68+ fixes and improvements. >> > >> > Release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa? >> version=12338705&projectId=12311211 >> > >> > Staging repository: >> > https://repository.apache.org/content/repositories/orgapachecamel-1066/ >> > >> > Tarballs: https://repository.apache.org/content/repositories/ >> orgapachecamel-1066/org/apache/camel/apache-camel/2.18.2/ >> > >> > Tag: https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h= >> 20ea3627daba0bc0e0759bcecb6cf0d7ee0c542c >> > >> > Please test this release candidate and cast your vote. >> > [ ] +1 Release the binary as Apache Camel 2.18.2 >> > [ ] -1 Veto the release (provide specific comments) >> > >> > The vote is open for at least 72 hours. >> > >> > Thanks, >> > Gregor >> >> >> >> -- >> Claus Ibsen >> - >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 >>
Hierarchical registry for CamelContext
Hello everyone, I'm wondering if it would make sense to have a sort of hierarchical registry where the root registry is always created by the CamelContext then the specific container registry adds its own registry on top and the lookup would be top down. The motivation is that there are some beans that are only used by camel and the registry is always involved so it does not make much sense to have them available also on the container, i.e. the ServiceCall and Hystrix configured through XML. This would reduce the complexity to add new definitions to the XML as one do not need to create a container specific parser (blueprint, spring, cdi) for object that are strictly camel-context related. What do you think ? --- Luca Burgazzoli
Re: Hierarchical registry for CamelContext
Yes an easy way to register beans that are not really meaningful outside the camel context and maybe beans we do not want to make available through dependency injection so they can't be easily modified outside. The hierarchical nature is only to make it transparent for consumer i.e. a service call / hystrix implementation would search in the registry and do not care were the bean come from. Indeed I'm not sure it is the best option, still need to experiment about it. --- Luca Burgazzoli On Fri, Feb 3, 2017 at 2:11 PM, Claus Ibsen wrote: > Hi > > So are you referring to some configuration for service call / hystrix etc? > > The problem with the registry being hierarchical is that its backed by > different implementations and then the user experience is different > depending on which beans you get. For example CDI/spring has all kind > of dependency injection magic, where as a basic map registry cannot do > anything. > > So it sounds more like you are looking for an internal generic registry? > > > > > On Thu, Feb 2, 2017 at 6:21 PM, Luca Burgazzoli wrote: >> Hello everyone, >> >> I'm wondering if it would make sense to have a sort of hierarchical >> registry where the root registry is always created by the CamelContext >> then the specific container registry adds its own registry on top and >> the lookup would be top down. >> >> The motivation is that there are some beans that are only used by >> camel and the registry is always involved so it does not make much >> sense to have them available also on the container, i.e. the >> ServiceCall and Hystrix configured through XML. >> >> This would reduce the complexity to add new definitions to the XML as >> one do not need to create a container specific parser (blueprint, >> spring, cdi) for object that are strictly camel-context related. >> >> What do you think ? >> >> --- >> Luca Burgazzoli > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: Hierarchical registry for CamelContext
Well, what we have as today is just fine but sometime it requires a
little bit of additional work and maintenance even it is not strictly
needed.
Let's take as example hystrix and service call stuffs we added recently:
1. hystrix configuration is retrieved from the registry but work in
spring only as blueprint and cdi support is not implemented and would
require additional work, even the spring support is a little limited.
2. service call configurations can be retrieved from the camel context
(via getter method) or from the registry but configurations you add to
the camel context element are added to the context, not the registry
so the behavior is a little different and it pollute the camel context
with additional methods.
3. Add support for service-call to spring & co may require to write a
custom bean factory
4. hystrix and service-call configurations are not supposed to be used
outside the camel context, so having them available for DI in
spring/blueprint/cdi does not make much sense
The proposed solution aim to harmonize such things by adding them to a
camel contex own registry.
Of course the container specific registry can still be used to
configure hystrix/service-call and it is used first, something like:
registry.lookupByName(String name, Class type) {
Object answer = containerRegistry.lookupByName(name);
if (answer == null) {
answer = contextRegistry,.lookupByName(name);
}
return answer;
}
---
Luca Burgazzoli
On Fri, Feb 3, 2017 at 4:27 PM, Paul Gale wrote:
> Luca,
>
> Can you outline either some particular business problem that you're trying
> to solve or some current impediment to a solution that would be remedied by
> your proposed design change?
>
> Perhaps a few use case scenarios might help demonstrate the need. Just a
> thought.
>
> Thanks,
> Paul
>
> On Fri, Feb 3, 2017 at 8:39 AM, Luca Burgazzoli
> wrote:
>
>> Yes an easy way to register beans that are not really meaningful
>> outside the camel context and maybe beans we do not want to make
>> available through dependency injection so they can't be easily
>> modified outside.
>> The hierarchical nature is only to make it transparent for consumer
>> i.e. a service call / hystrix implementation would search in the
>> registry and do not care were the bean come from.
>>
>> Indeed I'm not sure it is the best option, still need to experiment about
>> it.
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Fri, Feb 3, 2017 at 2:11 PM, Claus Ibsen wrote:
>> > Hi
>> >
>> > So are you referring to some configuration for service call / hystrix
>> etc?
>> >
>> > The problem with the registry being hierarchical is that its backed by
>> > different implementations and then the user experience is different
>> > depending on which beans you get. For example CDI/spring has all kind
>> > of dependency injection magic, where as a basic map registry cannot do
>> > anything.
>> >
>> > So it sounds more like you are looking for an internal generic registry?
>> >
>> >
>> >
>> >
>> > On Thu, Feb 2, 2017 at 6:21 PM, Luca Burgazzoli
>> wrote:
>> >> Hello everyone,
>> >>
>> >> I'm wondering if it would make sense to have a sort of hierarchical
>> >> registry where the root registry is always created by the CamelContext
>> >> then the specific container registry adds its own registry on top and
>> >> the lookup would be top down.
>> >>
>> >> The motivation is that there are some beans that are only used by
>> >> camel and the registry is always involved so it does not make much
>> >> sense to have them available also on the container, i.e. the
>> >> ServiceCall and Hystrix configured through XML.
>> >>
>> >> This would reduce the complexity to add new definitions to the XML as
>> >> one do not need to create a container specific parser (blueprint,
>> >> spring, cdi) for object that are strictly camel-context related.
>> >>
>> >> What do you think ?
>> >>
>> >> ---
>> >> Luca Burgazzoli
>> >
>> >
>> >
>> > --
>> > Claus Ibsen
>> > -
>> > http://davsclaus.com @davsclaus
>> > Camel in Action 2: https://www.manning.com/ibsen2
>>
Camel endpoint cloud registration
Hi,
as today we have a ServiceCall EIP that makes it easy to call external
services in a cloud environment leveraging external service registry
such as kubernetes, consul, etcd & co so I'm thinking about adding a
way for a route to register itself in such registries and be available
as a service for other to consume.
Something like:
// programmatic config
from("jetty:http://0.0.0.0:8001/service1";)
.serviceRegistry()
.name("service-1")
.host("")
.port(8001)
.meta("camel.protocol", "http")
.meta("camel.component", "jetty")
.meta("camel.context.path", "/service1")
.end()
.to("direct:service-1")
// Inherit from a global config and eventually override it
from("jetty:http://0.0.0.0:8002/service2";)
.serviceRegistry("service-2")
.configRef("service-registry-conf")
.port(8002)
.to("direct:service-2")
// Smart auto configuration
from("jetty:http://0.0.0.0:8003/service3";)
.serviceRegistry("service-3")
.to("direct:service-3")
Beside making camel play better in cloud environment, you can use the
service call to connect camel based micro services with minimal
configuration as the registration may provide some additional meta
data that the service call can use for auto-configuration (of course
not all the registries can do it).
The future Health API/Service may then also be configured to remove
or invalidate the service if the route is reported as not healthy.
Make sense for you ?
---
Luca Burgazzoli
Re: Camel endpoint cloud registration
Yeah, I will log this enhancement and yeah, this comes after the
health check stuffs.
---
Luca Burgazzoli
On Mon, Feb 6, 2017 at 5:05 PM, Claus Ibsen wrote:
> Hi Luca
>
> Yeah good idea, can you maybe log a JIRA about this.
>
> The health-check ticket is frankly a bit more important to get started
> on. So I wonder if you will get time to maybe help with this, and help
> lead that effort? Andrea has also posted interrest on this ticket. It
> has a few nuances and also ties into your great effort with this Camel
> cloud stuff.
>
> We can talk on this in another @dev or on the JIRA ticket for health-check.
>
>
>
> On Mon, Feb 6, 2017 at 10:50 AM, Luca Burgazzoli
> wrote:
>> Hi,
>>
>> as today we have a ServiceCall EIP that makes it easy to call external
>> services in a cloud environment leveraging external service registry
>> such as kubernetes, consul, etcd & co so I'm thinking about adding a
>> way for a route to register itself in such registries and be available
>> as a service for other to consume.
>>
>> Something like:
>>
>> // programmatic config
>> from("jetty:http://0.0.0.0:8001/service1";)
>> .serviceRegistry()
>> .name("service-1")
>> .host("")
>> .port(8001)
>> .meta("camel.protocol", "http")
>> .meta("camel.component", "jetty")
>> .meta("camel.context.path", "/service1")
>> .end()
>> .to("direct:service-1")
>>
>> // Inherit from a global config and eventually override it
>> from("jetty:http://0.0.0.0:8002/service2";)
>> .serviceRegistry("service-2")
>> .configRef("service-registry-conf")
>> .port(8002)
>> .to("direct:service-2")
>>
>> // Smart auto configuration
>> from("jetty:http://0.0.0.0:8003/service3";)
>> .serviceRegistry("service-3")
>> .to("direct:service-3")
>>
>> Beside making camel play better in cloud environment, you can use the
>> service call to connect camel based micro services with minimal
>> configuration as the registration may provide some additional meta
>> data that the service call can use for auto-configuration (of course
>> not all the registries can do it).
>>
>> The future Health API/Service may then also be configured to remove
>> or invalidate the service if the route is reported as not healthy.
>>
>>
>> Make sense for you ?
>>
>> ---
>> Luca Burgazzoli
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel endpoint cloud registration
yeah, this isn't just more than a raw dump of some ideas I had in mind
but the service/object entitled to perform the registration to the
cloud registry should have a sort of pluggable
"local-address-resolver"
---
Luca Burgazzoli
On Tue, Feb 7, 2017 at 1:52 AM, Willem Jiang wrote:
> I just have a security littler concern of the 0.0.0.0 which could bind all
> the possible network interface according to recent malicious attacks on
> unsecured instances of MongoDB.
>
> Maybe we can add a feature to let the serviceRegistry to look up a certain
> address for access.
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Feb 6, 2017 at 5:50 PM, Luca Burgazzoli
> wrote:
>
>> Hi,
>>
>> as today we have a ServiceCall EIP that makes it easy to call external
>> services in a cloud environment leveraging external service registry
>> such as kubernetes, consul, etcd & co so I'm thinking about adding a
>> way for a route to register itself in such registries and be available
>> as a service for other to consume.
>>
>> Something like:
>>
>> // programmatic config
>> from("jetty:http://0.0.0.0:8001/service1";)
>> .serviceRegistry()
>> .name("service-1")
>> .host("")
>> .port(8001)
>> .meta("camel.protocol", "http")
>> .meta("camel.component", "jetty")
>> .meta("camel.context.path", "/service1")
>> .end()
>> .to("direct:service-1")
>>
>> // Inherit from a global config and eventually override it
>> from("jetty:http://0.0.0.0:8002/service2";)
>> .serviceRegistry("service-2")
>> .configRef("service-registry-conf")
>> .port(8002)
>> .to("direct:service-2")
>>
>> // Smart auto configuration
>> from("jetty:http://0.0.0.0:8003/service3";)
>> .serviceRegistry("service-3")
>> .to("direct:service-3")
>>
>> Beside making camel play better in cloud environment, you can use the
>> service call to connect camel based micro services with minimal
>> configuration as the registration may provide some additional meta
>> data that the service call can use for auto-configuration (of course
>> not all the registries can do it).
>>
>> The future Health API/Service may then also be configured to remove
>> or invalidate the service if the route is reported as not healthy.
>>
>>
>> Make sense for you ?
>>
>> ---
>> Luca Burgazzoli
>>
Camel Saxon and xslt
Hi everyone, I've recently been working on camel-saxon and camel-xslt to enable saxon specific stuffs in camel-xslt and this required some little reflection hacks which could make it harder to detect potential api breaks when updating saxon and could be problematic for java 9 if saxon does not properly configure the modules system so I'm wondering if it could make sense to create a saxon-xslt component (to be done after 2.19) which inherit from xslt component and adds saxon specifc stuffs without reflection hacks. So with component: - xslt --> you can still use saxon but can't confiugre saxon specific features - saxon-xslt --> same as xslt but you can configure/use saxon specific features Thoughts ? --- Luca Burgazzoli
Re: Camel Saxon and xslt
going to raise a ticket then --- Luca Burgazzoli On Fri, Feb 10, 2017 at 1:16 PM, Claus Ibsen wrote: > Hi > > Yeah it can make sense. It also ensures that users are not in doubt if > they use saxon or not. Usually Saxon offers more advanced features > that you dont have from the JDK. > > And maybe we can add something so users can install the commercial > saxon and unlock xslt 3.0 functionality or what else is exclusive in > their commercial product. > > > > On Fri, Feb 10, 2017 at 12:24 PM, Luca Burgazzoli > wrote: >> Hi everyone, >> >> I've recently been working on camel-saxon and camel-xslt to enable >> saxon specific stuffs in camel-xslt and this required some little >> reflection hacks which could make it harder to detect potential api >> breaks when updating saxon and could be problematic for java 9 if >> saxon does not properly configure the modules system so I'm wondering >> if it could make sense to create a saxon-xslt component (to be done >> after 2.19) which inherit from xslt component and adds saxon specifc >> stuffs without reflection hacks. >> >> So with component: >> - xslt --> you can still use saxon but can't confiugre saxon specific >> features >> - saxon-xslt --> same as xslt but you can configure/use saxon specific >> features >> >> Thoughts ? >> >> --- >> Luca Burgazzoli > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Integration of Suppliers in Java 8 DSL
Hi,
I'm working to make the Java DSL more Java 8 friedly adding missing
pieces from the previous Java 8 round and one of the thing that was
missing was the possibility to use Suppliers to provides objects to
the routes.
As today:
from("direct:start")
.idempotentConsumer()
.header("messageId")
.messageIdRepository(createRepo())
.to("mock:result");
With suppliers:
from("direct:start")
.idempotentConsumer()
.header("messageId")
.messageIdRepository(this::createRepo)
.to("mock:result");
Adding that does not result in such a big improvement for the DSL but
it adds some overhead to the underlying definitions as we may need to
add additional variables to hold the suppliers and other stuffs to
convert suppliers i.e. to expression clause so I'm unsure if we should
add such things in 2.19 or maybe delay to 3.0 (where we may have the
chance to do a deeper refactor and suppliers may play better),
What do you think ?
---
Luca Burgazzoli
Re: camel git commit: CAMEL-10724: Improve Java DSL support for Java 8
Should be fixed now
---
Luca Burgazzoli
On Thu, Feb 16, 2017 at 8:01 PM, Claus Ibsen wrote:
> Hi Luca
>
> This happens also for me. There is a little secret that if you change
> the Message API then the Scala DSL needs to be changed accordingly.
>
> The camel-scala can not be compiled now.
>
> On Thu, Feb 16, 2017 at 6:10 PM, wrote:
>> Repository: camel
>> Updated Branches:
>> refs/heads/master 8e0e3083e -> 8bc8484b1
>>
>>
>> CAMEL-10724: Improve Java DSL support for Java 8
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/camel/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/camel/commit/8bc8484b
>> Tree: http://git-wip-us.apache.org/repos/asf/camel/tree/8bc8484b
>> Diff: http://git-wip-us.apache.org/repos/asf/camel/diff/8bc8484b
>>
>> Branch: refs/heads/master
>> Commit: 8bc8484b1914f5cb29191e7b91fe48e02ca1f636
>> Parents: 8e0e308
>> Author: lburgazzoli
>> Authored: Wed Jan 18 18:09:08 2017 +0100
>> Committer: lburgazzoli
>> Committed: Thu Feb 16 18:10:22 2017 +0100
>>
>> --
>> .../src/main/java/org/apache/camel/Message.java | 16 -
>> .../org/apache/camel/impl/DefaultMessage.java | 31 +
>> .../apache/camel/model/AggregateDefinition.java | 20 ++
>> .../model/IdempotentConsumerDefinition.java | 9 +--
>> .../apache/camel/model/MulticastDefinition.java | 26 +++
>> .../apache/camel/model/ProcessorDefinition.java | 66 +-
>> .../org/apache/camel/util/ExchangeHelper.java | 18 +
>> .../apache/camel/util/function/Suppliers.java | 43
>> .../apache/camel/impl/DefaultExchangeTest.java | 5 ++
>> .../camel/processor/DynamicRouter4Test.java | 58
>> .../processor/IdempotentConsumerDslTest.java| 53 ++
>> .../apache/camel/processor/LoopDoWhileTest.java | 23 ++-
>> .../camel/processor/MulticastDslTest.java | 69 +++
>> .../camel/processor/RoutingSlipDslTest.java | 49 +
>> .../camel/processor/ThrottlerDslTest.java | 72
>> .../processor/aggregator/AggregateDslTest.java | 41 +--
>> 16 files changed, 582 insertions(+), 17 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/camel/blob/8bc8484b/camel-core/src/main/java/org/apache/camel/Message.java
>> --
>> diff --git a/camel-core/src/main/java/org/apache/camel/Message.java
>> b/camel-core/src/main/java/org/apache/camel/Message.java
>> index 8cfeae0..a0e9c4d 100644
>> --- a/camel-core/src/main/java/org/apache/camel/Message.java
>> +++ b/camel-core/src/main/java/org/apache/camel/Message.java
>> @@ -18,7 +18,7 @@ package org.apache.camel;
>>
>> import java.util.Map;
>> import java.util.Set;
>> -
>> +import java.util.function.Supplier;
>> import javax.activation.DataHandler;
>>
>> /**
>> @@ -88,6 +88,13 @@ public interface Message {
>> Object getHeader(String name, Object defaultValue);
>>
>> /**
>> + * TODO: document
>> + * Note: this is experimental and subject to changes in future releases.
>> + *
>> + */
>> +Object getHeader(String name, Supplier defaultValueSupplier);
>> +
>> +/**
>> * Returns a header associated with this message by name and specifying
>> the
>> * type required
>> *
>> @@ -112,6 +119,13 @@ public interface Message {
>> T getHeader(String name, Object defaultValue, Class type);
>>
>> /**
>> + * TODO: document
>> + * Note: this is experimental and subject to changes in future releases.
>> + *
>> + */
>> + T getHeader(String name, Supplier defaultValueSupplier,
>> Class type);
>> +
>> +/**
>> * Sets a header on the message
>> *
>> * @param name of the header
>>
>> http://git-wip-us.apache.org/repos/asf/camel/blob/8bc8484b/camel-core/src/main/java/org/apache/camel/impl/DefaultMessage.java
>> --
>> diff --git
>> a/camel-core/src/main/java/org/apache/camel/impl/DefaultMessage.java
>> b/camel-core/src/main/java/org/apache/camel/impl/DefaultMessage.java
>> index 848586a..1e49766 100644
>> --- a/camel-core/src/main/java/org/apache/camel/impl/DefaultMessage.java
>&
Re: [DISCUSS] - New Apache Camel Logo - Move on with the procedure
Fine with me --- Luca Burgazzoli On Thu, Feb 23, 2017 at 10:08 AM, Andrea Cosentino wrote: > +1. End of March is ok. > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix Committer > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > On Thursday, February 23, 2017 10:07 AM, Claus Ibsen > wrote: > Hi > > I suggest that we get this procedure going again. > > 1) > Set a deadline in approx 4 weeks (eg monday March 27th) for people to > submit logo proposals. > > People can follow the guides in this JIRA how to submit: > https://issues.apache.org/jira/browse/CAMEL-10543 > > 2) > Put out the word about this in the community / Camel front page > > 3) > After deadline have a vote about the logos > > 4) > Let the outcome of the vote influence the Camel PMC in their decision > to change the logo. > > > Any comments? > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Deprecate camel-scala and camel-groovy DSL ?
+1 to move them on camel-extra --- Luca Burgazzoli On Thu, Feb 23, 2017 at 9:12 AM, Christian Müller wrote: > +1 > > Best, > Christian > > Am 22.02.2017 9:51 vorm. schrieb "Claus Ibsen" : > >> Hi >> >> 99% of Camel users are using Java / Java8 / XML DSLs. And they are all >> up to date and aligned. >> >> We have camel-groovy with a little Camel DSL that adds a bit of >> integration with groovy closures etc - but they are not really much in >> use / maintained etc. >> >> For camel-scala the DSL is overly complex to maintain and it was >> created many years ago when Scala became hot, and some developers want >> to use every nifty feature in Scala as an experiment - and created the >> initial camel-scala module. >> >> Scala or Groovy users can just as well use the standard DSL from Java >> / Java8 as well as these languages are inter-operable with regular >> Java. >> >> >> Should we deprecate these and drop them from Camel 3.0 onwards? >> >> If we do so and if there are some users whom want to maintain them, we >> can move the code to camel-extra or some place on github etc. >> >> >> Any comments? >> >> >> >> -- >> Claus Ibsen >> - >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 >>
Re: [DISCUSS] - New Apache Camel Logo - Move on with the procedure
+1 --- Luca Burgazzoli On Mon, Feb 27, 2017 at 11:09 AM, Andrea Cosentino wrote: > +1 > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix Committer > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > On Monday, February 27, 2017 11:06 AM, Claus Ibsen > wrote: > Hi > > Okay so I suggest to post this on the front page and mailing lists. > > Any comments? > > > > New Apache Camel Logo - Open for proposals > > > The Apache Camel logo is a bit out dated so we have discussed in the > Camel PMC and community to come up with a new one. > We encourage anyone to participate by submitting a logo proposal > and/or share thoughts > > The logo can be submitted by either: > > - a PR on GitHub (preferred) > - file attachment to JIRA ticket: > https://issues.apache.org/jira/browse/CAMEL-10543 > > And each logo should be: > > - images should be added to docs/img > - each PR should contains a single logo > > We are looking for a new logo that has two parts > > - graphical logo > - The name: Apache Camel > > So we can use the logo without the word Apache Camel, but also as a > combination of the two of them, eg as logo on the Camel front page. > Also if the logo can be vector based it would be a benefit, so it can > scale up and down nicely. > > You can find details here how to contribute to the project and how to > work on the source code. > Such as how to do a github PR: http://camel.apache.org/contributing > > > The period is open until Monday 27th March 2017. > > > After the period the submitted logos will be in a public vote, and the > outcome of that vote will influence the decision on which logo to use > as the official Apache Camel logo. > > > At this time of writing there are two proposals submitted at PRs: > > https://github.com/apache/camel/pull/1369 > https://github.com/apache/camel/pull/1494 > > More information and questions can be asked at the JIRA ticket: > https://issues.apache.org/jira/browse/CAMEL-10543 > > > > > On Thu, Feb 23, 2017 at 10:06 AM, Claus Ibsen wrote: >> Hi >> >> I suggest that we get this procedure going again. >> >> 1) >> Set a deadline in approx 4 weeks (eg monday March 27th) for people to >> submit logo proposals. >> >> People can follow the guides in this JIRA how to submit: >> https://issues.apache.org/jira/browse/CAMEL-10543 >> >> 2) >> Put out the word about this in the community / Camel front page >> >> 3) >> After deadline have a vote about the logos >> >> 4) >> Let the outcome of the vote influence the Camel PMC in their decision >> to change the logo. >> >> >> Any comments? >> >> >> -- >> 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
Component documentation : UriParam Vs UriPath
Hello,
today I noticed that there is a little difference between the
documentation we are making as asciidoc and the confluence one i.e.:
for the camel-http4 component, the asciidoc one lists httpUri among
the endpoint options whereas the confluence one doesn't.
I think confluence doc is correct here as the httpUri is an UriPath
[1] so it shouldn't show up as endpoint option otherwise one could
think that it could use it as option, i.e:
to('http4://www.google.com?httpUri=http://camel-apache.org')
But that would fail.
Should we exclude all the UriPath from the endpoint options ?
Regards,
Luca
[1]
https://github.com/apache/camel/blob/master/components/camel-http-common/src/main/java/org/apache/camel/http/common/HttpCommonEndpoint.java#L36-L37
---
Luca Burgazzoli
Re: [HEADS UP] - Deprecate stuff on Apache Camel 2.x
+1 btw, should we have a sort of "camel dormant" repository were we can put stuffs that are not actively maintained ? --- Luca Burgazzoli On Fri, Mar 3, 2017 at 2:30 PM, Claus Ibsen wrote: > Hi > > I propose to deprecate camel-guice. That module has never really been > in much use / attention / maintained. And over the years guice has > been pain to support / guice itself was in trouble when the leaders > left and google didnt do any releases and whatnot. > > > > On Wed, Mar 1, 2017 at 9:33 AM, Claus Ibsen wrote: >> Hi >> >> As part of CAMEL-10735: https://issues.apache.org/jira/browse/CAMEL-10735 >> >> We are deprecating code on 2.x that we anticipate to be removed in >> Camel 3.0 onwards. >> We have marked code as deprecated over the years, but recently got >> more aggressive and deprecated more in camel-core. >> >> We have also marked components and other artifacts as deprecated, >> which you can see in the overview on the readme file in github >> https://github.com/apache/camel/blob/master/components/readme.adoc >> >> We have also decided to deprecate the Scala and Groovy DSL which will >> be moved to camel-extra as their new home. Ticket about this: >> https://issues.apache.org/jira/browse/CAMEL-10909 >> >> >> For example camel-script allows to run python, php and some other >> "exotic" languages. However these can be used as security attack >> vectors when these libraries have issues. And because they are very >> seldom used, we could maybe deprecate some of these languages and then >> allow using javaScript (nashhorn from JDK) which should offer >> sufficient scripting languge. And there is always groovy as well. >> >> We also think about deprecating components that wont support Java 9 or >> are tricky to support there, for example jibx have some issues. >> >> >> There are potential more to be deprecated, so we welcome any feedback >> from the community. >> >> >> >> -- >> 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: [VOTE] Release Apache Camel 2.17.6
+1 --- Luca Burgazzoli On Mon, Mar 6, 2017 at 9:13 AM, Claus Ibsen wrote: > +1 > > On Sun, Mar 5, 2017 at 2:33 PM, Gregor Zurowski > wrote: >> Hi Everyone: >> >> This is a vote to release Apache Camel 2.17.6, a new patch release >> that includes 17 fixes and improvements. >> >> Release notes: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12339170&projectId=12311211 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecamel-1068/ >> >> Tarballs: >> https://repository.apache.org/content/repositories/orgapachecamel-1068/org/apache/camel/apache-camel/2.17.6/ >> >> Tag: >> https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=168e6c362dfeb6166a0b33c28c54027514ea5a27 >> >> Please test this release candidate and cast your vote. >> [ ] +1 Release the binary as Apache Camel 2.17.6 >> [ ] -1 Veto the release (provide specific comments) >> >> The vote is open for at least 72 hours. >> >> Thanks, >> Gregor > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: [VOTE] Release Apache Camel 2.18.3
+1 --- Luca Burgazzoli On Mon, Mar 6, 2017 at 9:39 AM, Christian Schneider wrote: > +1 > > Christian > > On 05.03.2017 09:07, Gregor Zurowski wrote: >> >> Hi Everyone: >> >> This is a vote to release Apache Camel 2.18.3, a new patch release >> that includes 37 fixes and improvements. >> >> Release notes: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12339161&projectId=12311211 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecamel-1067/ >> >> Tarballs: >> https://repository.apache.org/content/repositories/orgapachecamel-1067/org/apache/camel/apache-camel/2.18.3/ >> >> Tag: >> https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=a1b029f3ca314ac20953f69818c9ae2b07eff4dc >> >> Please test this release candidate and cast your vote. >> [ ] +1 Release the binary as Apache Camel 2.18.3 >> [ ] -1 Veto the release (provide specific comments) >> >> The vote is open for at least 72 hours. >> >> Thanks, >> Gregor > > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
Re: [VOTE] Release Apache Camel 2.18.3 (Attempt #2)
+1 (binding) --- Luca Burgazzoli On Thu, Mar 9, 2017 at 10:58 AM, Andrea Cosentino wrote: > +1 (binding). > > Tested against personal projects. > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix Committer > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > On Thursday, March 9, 2017 8:49 AM, Gregor Zurowski > wrote: > Hi Everyone: > > This is the second vote to release Apache Camel 2.18.3, a new patch > release that includes 38 fixes and improvements. The initial vote has > been cancelled due to a major issue with Spring Boot (see [1]). As > the Camel project seeks for best integration with Spring Boot, we > decided to recreate a new release candidate that includes a fix for > this issue. > > Release notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12339161&projectId=12311211 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachecamel-1069/ > > Tarballs: > https://repository.apache.org/content/repositories/orgapachecamel-1069/org/apache/camel/apache-camel/2.18.3/ > > Tag: > https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=ce3c3100ee019ea4aae371ea77820d202295bc84 > > Please test this release candidate and cast your vote. > [ ] +1 Release the binary as Apache Camel 2.18.3 > [ ] -1 Veto the release (provide specific comments) > > The vote is open for at least 72 hours. > > Thanks, > Gregor > > [1] https://issues.apache.org/jira/browse/CAMEL-10951
Add a "vault" for secrets to camel
Hello,
would it make sense to have a sort of "vault service" in camel to
store/retrieve secrets with support for common patterns ?
i.e.
- we can store an auth tokens and delegate to the vault to be notified
about its expiration or to renew it when needed (by registering some
functions/callbacks)
- we can provide different backends to provide secrets like for
kubernetes secrets, hashicorp's vault, etc (with support for
notification if the backend supports it)
- we can use the vault as properties source if someone prefix a
property with vault like {{vault:db.password}}
---
Luca Burgazzoli
Re: Add a "vault" for secrets to camel
Logged a JIRA https://issues.apache.org/jira/browse/CAMEL-1103 for the next release. I would like to have a way for components to register functionalities for the vault like backends or flows (i.e. we may create a camel-jwt to support JSON Web Token flow) etc so feel free to add subtasks for specific flows/functionalities. --- Luca Burgazzoli On Thu, Mar 16, 2017 at 11:46 PM, Zoran Regvart wrote: > Luca, > > I think this is a great idea, would love to contribute to it. > > zoran > -- > Zoran Regvart
Re: [HEADS UP] - Deprecate stuff on Apache Camel 2.x
+1 --- Luca Burgazzoli On Thu, Mar 16, 2017 at 8:16 PM, Claus Ibsen wrote: > Hi > > I wonder if we shall deprecate more stuff on OSGi as its one of the > most problematic platforms to support. > > Ideally only OSGi Blueprint is the best supported we have. > > We should consider deprecating on OSGi > > - camel-scr > - camel-cdi (use CDI outside OSGi like JEE, Weld/OpenWebBeans or > anywhere else but OSGi) > > > > On Wed, Mar 1, 2017 at 9:33 AM, Claus Ibsen wrote: > > Hi > > > > As part of CAMEL-10735: https://issues.apache.org/ > jira/browse/CAMEL-10735 > > > > We are deprecating code on 2.x that we anticipate to be removed in > > Camel 3.0 onwards. > > We have marked code as deprecated over the years, but recently got > > more aggressive and deprecated more in camel-core. > > > > We have also marked components and other artifacts as deprecated, > > which you can see in the overview on the readme file in github > > https://github.com/apache/camel/blob/master/components/readme.adoc > > > > We have also decided to deprecate the Scala and Groovy DSL which will > > be moved to camel-extra as their new home. Ticket about this: > > https://issues.apache.org/jira/browse/CAMEL-10909 > > > > > > For example camel-script allows to run python, php and some other > > "exotic" languages. However these can be used as security attack > > vectors when these libraries have issues. And because they are very > > seldom used, we could maybe deprecate some of these languages and then > > allow using javaScript (nashhorn from JDK) which should offer > > sufficient scripting languge. And there is always groovy as well. > > > > We also think about deprecating components that wont support Java 9 or > > are tricky to support there, for example jibx have some issues. > > > > > > There are potential more to be deprecated, so we welcome any feedback > > from the community. > > > > > > > > -- > > 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 >
Undertow uri syntax
Hello, I've recently worked on some examples related to the service-call eip using undertow as underlying component to see how complex is to go beyond the defaults and it worked nice, the only downside is that you cannot simply swap the component as undertow expect also the protocol (http/https) to be provided in the uri syntax: undertow:http://hostname[:port][/resourceUri][?options] When using component like camel-http or camel-http4 the scheme is not needed which make the integration with the service-call eip much simpler. So I'm wondering if it could make sense to let camel-undertow also to handle uri like: undertow:hostname[:port][/resourceUri][?options] where: - by default the scheme is http - https can be derived by the port number or presence of the ssl options - of course one can set the full uri as today As I do not know camel-undertow in depth I may have missed something so any feedback would be appreciated. --- Luca Burgazzoli
Re: Undertow uri syntax
Great ! I would be really nice if we can swap http component without much changes, for service call + spring-boot this would be lovely as one can swap the component via spring's properties and no code change. --- Luca Burgazzoli On Fri, Mar 24, 2017 at 9:10 AM, Zoran Regvart wrote: > Hi Luca, > yes, I think that would be a good idea. IMHO all HTTP components > should behave similarly, this helps users to migrate between them as > they see fit. We should probably push as much of the code into > camel-http-common where it makes sense, > > zoran > > On Fri, Mar 24, 2017 at 7:33 AM, Luca Burgazzoli > wrote: >> Hello, >> >> I've recently worked on some examples related to the service-call eip >> using undertow as underlying component to see how complex is to go >> beyond the defaults and it worked nice, the only downside is that you >> cannot simply swap the component as undertow expect also the protocol >> (http/https) to be provided in the uri syntax: >> >> undertow:http://hostname[:port][/resourceUri][?options] >> >> When using component like camel-http or camel-http4 the scheme is not >> needed which make the integration with the service-call eip much >> simpler. >> >> So I'm wondering if it could make sense to let camel-undertow also to >> handle uri like: >> >> undertow:hostname[:port][/resourceUri][?options] >> >> where: >> >> - by default the scheme is http >> - https can be derived by the port number or presence of the ssl options >> - of course one can set the full uri as today >> >> As I do not know camel-undertow in depth I may have missed something >> so any feedback would be appreciated. >> >> >> >> --- >> Luca Burgazzoli > > > > -- > Zoran Regvart
Re: Migrate camel-pubnub component
We love contributions so feel free to open a JIRA and a PR :) --- Luca Burgazzoli On Thu, Mar 23, 2017 at 9:25 PM, Preben.Asmussen wrote: > Hi > > Some time ago I created a camel component for PubNub in the Rhiot project. > https://github.com/rhiot/rhiot/tree/master/datastream/components/camel-pubnub > > The Rhiot project is no longer maintained, so I was thinking if it would > make any sense to polish the component, and move it to the apache camel > project to give it a proper home. > The pubnub java sdk is MIT licensed > https://github.com/pubnub/java/blob/master/LICENSE > > The component is described here > https://rhiot.gitbooks.io/rhiotdocumentation/content/cloudplatform/camel_components/camel_pubnub_component.html > > Best, > Preben > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Migrate-camel-pubnub-component-tp5796056.html > Sent from the Camel Development mailing list archive at Nabble.com.
camel-infinispan : change the uri syntax from infinispan:hostName to infinispan:cacheName
Hi everyone, I've opened an issue [1] to change the uri syntax of camel-infinispan so that it will be similar to the other cache implementations we have in camel (hazelcast, ehcache, jcache). As additional benefit it would make it easy to perform auto configuration of the component in spring-boot maybe leveraging infinsipan's spring-boot starter [2] when we'll migrate to infinispan 9.0 Is there anything I missed that would make this change not possible ? [1] https://issues.apache.org/jira/browse/CAMEL-11108 [2] https://github.com/infinispan/infinispan-spring-boot --- Luca Burgazzoli
Re: camel-infinispan : change the uri syntax from infinispan:hostName to infinispan:cacheName
+1 for the cache dsl
:)
---
Luca Burgazzoli
On Wed, Apr 5, 2017 at 11:12 AM, Nicola Ferraro wrote:
> +1
> I've found local caches very useful in multiple scenarios.
>
>
>
> OT:
> I was also thinking to standardize caches in order to create a sort of
> short-circuit mechanism, e.g. to avoid overloading external systems with
> repeated queries. Something like...
>
> ```
> from("xxx")
> .cache().on("${header.yyy}").ttl(60) // caches the body
> .to("http4://
> a-service-that-makes-me-pay-for-each-request.com/api/expensive-endpoint")
> .transform().zzz()
> .to("http4://
> or-a-service-that-i-can-call-few-times-a-day.com/api/limited-endpoint")
> .unmarshal()
> .endCache()
> ```
> But also to protect internal services when I'm using Camel e.g. as a
> api-gateway (almost what hystrix does in case of failure of the target
> host).
>
>
> On Wed, Apr 5, 2017 at 9:59 AM, Claus Ibsen wrote:
>
>> +1
>>
>> Yeah better to have it be like the other components.
>>
>>
>> On Wed, Apr 5, 2017 at 9:47 AM, Luca Burgazzoli
>> wrote:
>> > Hi everyone,
>> >
>> > I've opened an issue [1] to change the uri syntax of camel-infinispan
>> > so that it will be similar to the other cache implementations we have
>> > in camel (hazelcast, ehcache, jcache). As additional benefit it would
>> > make it easy to perform auto configuration of the component in
>> > spring-boot maybe leveraging infinsipan's spring-boot starter [2] when
>> > we'll migrate to infinispan 9.0
>> >
>> > Is there anything I missed that would make this change not possible ?
>> >
>> > [1] https://issues.apache.org/jira/browse/CAMEL-11108
>> > [2] https://github.com/infinispan/infinispan-spring-boot
>> >
>> >
>> > ---
>> > Luca Burgazzoli
>>
>>
>>
>> --
>> Claus Ibsen
>> -
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
Re: Camel 2.19 Roadmap
Hi, I have one little refactoring (rename LoadBalancer in camel cloud package to avoid confusion with LoadBalancer processor) and a little doc update that I'm trying to make by end of day. --- Luca Burgazzoli On Wed, Apr 19, 2017 at 1:39 PM, Claus Ibsen wrote: > Hi > > So the @Generated and Java 9 ought to be fixed now. > > There is a new version of Spring Boot 1.5.3 on the way. It may be > beneficial to wait for that to be released so we are running on > latest. > > On Wed, Apr 19, 2017 at 9:54 AM, Claus Ibsen wrote: >> Hi >> >> Okay so there is some last minute issues with the @Generated >> annotations we need to look into >> https://issues.apache.org/jira/browse/CAMEL-11165 >> >> And an unforseen effect on java 9 builds >> https://issues.apache.org/jira/browse/CAMEL-11166 >> >> The full test is passing now. And the Spring Boot and Karaf tests has >> also passed but failed recently due some maven download error or some >> other weird error. So lets kick new builds when we get the 2 tickets >> resolved above. >> >> >> >> >> On Tue, Apr 18, 2017 at 9:45 AM, Claus Ibsen wrote: >>> Hi >>> >>> Things start to look good. There is a itest that fails with spring >>> boot which we need to look at and get fixed >>> https://issues.apache.org/jira/browse/CAMEL-11154 >>> >>> The other tests was all passing recently and they ought to become blue >>> again. But lets keep an eye on them: >>> https://builds.apache.org/view/A-D/view/Camel/ >>> >>> >>> On Thu, Apr 13, 2017 at 1:50 PM, Claus Ibsen wrote: >>>> Hi >>>> >>>> Thanks Antonin that sounds great. >>>> >>>> The JIRA tickets are down to 3 >>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.19.0%20AND%20resolution%20%3D%20Unresolved >>>> >>>> We have recently fixed up the missing component docs and fixed broken >>>> links from browsing on github. >>>> >>>> We should keep an eye on the CI servers and output from the >>>> camel-catalog report, to see if it reports more missing stuff. >>>> It currently has a false positive on some missing docs for some of the >>>> test components. I will try to fix this later today. >>>> >>>> However thats not all. At all time feel free to have fun and work on >>>> anything you like on Camel. There is still time for small improvements >>>> etc. But bigger stuff we should really defer to the next release. >>>> >>>> >>>> On Wed, Apr 12, 2017 at 3:35 PM, Antonin Stefanutti >>>> wrote: >>>>> >>>>>> On 12 Apr 2017, at 15:22, Claus Ibsen wrote: >>>>>> >>>>>> Hi >>>>>> >>>>>> Just a heads up that we plan to cut the RC for Camel 2.19 next week. >>>>>> >>>>>> So we are closing down on the last tickets, bugs, features etc to get >>>>>> the code base in shape. >>>>>> >>>>>> The JIRA has 9 tickets >>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.19.0%20AND%20resolution%20%3D%20Unresolved >>>>>> >>>>>> But you are of course welcome to work on other tickets etc but just >>>>>> mind any big functionality is likely better to wait for next release. >>>>>> >>>>>> There is however the expected transaction stuff for CDI as a PR in the >>>>>> works, and also a new iot component >>>>>> https://github.com/apache/camel/pulls >>>>> >>>>> The CDI transaction support PR should be merged by end of week. >>>>> >>>>> https://github.com/apache/camel/pull/1390 >>>>> >>>>>> We should keep an eye on the CI servers to see how they are and fix >>>>>> any test failures etc. Recently we got them to build and test the OSGi >>>>>> and spring-boot specific tests so we should be able to better keep an >>>>>> eye on this now and in the future. >>>>>> https://builds.apache.org/view/A-D/view/Camel/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 7, 2017 at 8:45 AM, Gregor Zurowski >>>>>> wrote: >>>>>>> Hi Claus, >>>
Re: Camel 2.19 Roadmap
Hi Gregor, I'm running a local build to see if there is any blocking issue some JIRA I'd like to include [1][2][3], it should not take too much and I'll post here as son as I have merged my work on master. [1] https://issues.apache.org/jira/browse/CAMEL-11190 [2] https://issues.apache.org/jira/browse/CAMEL-11191 [3] https://issues.apache.org/jira/browse/CAMEL-11192 --- Luca Burgazzoli On Mon, Apr 24, 2017 at 11:11 AM, Gregor Zurowski wrote: > Hi Claus, > > Alright, I guess this is the best we can do for now. I also agree on > removing the regular examples from the release. I would actually also > move them into a separate artifact group. Currently they use the > group ID org.apache.camel, so we could move them into > org.apache.camel.example or similar. > > I will re-cut the release candidate tonight. > > Thanks, > Gregor > > > On Mon, Apr 24, 2017 at 10:49 AM, Claus Ibsen wrote: >> Hi Gregor >> >> So we have now fixed this by turning of those connector examples as >> they should not be in the release. >> >> We will later re-organize this and see what to do if any of this is >> needed as releases JAR in maven central. >> You could consider the same for the regular examples, they should >> maybe not be released either to maven central. >> But its a talk for another day. >> >> The master branch should be ready for a re-cut of the release. >> >> Let us know when you are able to work on this again. Thanks a lot for >> helping with the releases. >> >> >> >> >> >> >> >> >> On Mon, Apr 24, 2017 at 10:22 AM, Claus Ibsen wrote: >>> Hi Gregor >>> >>> Okay so the connector examples are not yet intended for release (if >>> they ever would be). >>> So I have skipped them. >>> >>> People can try them from the source code as they do with the other >>> examples. That works fine. >>> >>> For a release process we may also need to add some extra logic so the >>> SNAPSHOT versions in the json files etc are replaced as part of a >>> release build. AFAIR you need to run 2 x build, to make it updated, >>> which you can't usually. >>> >>> >>> >>> On Sun, Apr 23, 2017 at 10:25 PM, Gregor Zurowski >>> wrote: >>>> Hi Everyone: >>>> >>>> I have finally managed to resolve all memory-related and >>>> machine-related issues, but I am hitting another road block in the >>>> release process. The process fails when the new connector examples >>>> are about to get pushed to the artifact repository: >>>> >>>> [INFO] [ERROR] Failed to execute goal >>>> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy >>>> (default-deploy) on project beverage-component: Failed to deploy >>>> artifacts: Could not transfer artifact >>>> org.foo:beverage-component:jar:2.19.0 from/to apache.releases.https >>>> (https://repository.apache.org/service/local/staging/deploy/maven2): >>>> Failed to transfer file: >>>> https://repository.apache.org/service/local/staging/deploy/maven2/org/foo/beverage-component/2.19.0/beverage-component-2.19.0.jar. >>>> Return code is: 400, ReasonPhrase: Bad Request. -> [Help 1] >>>> >>>> This is likely caused by the group ID "org.foo" that is used in these >>>> modules, which will not be accepted by the Apache artifact repository. >>>> >>>> I could easily change the group ID of these examples to something like >>>> "org.apache.camel.example.connector". While attempting to change >>>> this, I realized that there are JSON files in the example directories >>>> that directly reference these artifacts, for example in >>>> /salesforce-upsert-contact-connector/src/main/resources/camel-connector.json: >>>> >>>> "groupId" : "org.foo", >>>> "artifactId" : "salesforce-upsert-contact-connector", >>>> "version" : "2.19.0-SNAPSHOT" >>>> >>>> I can update the group ID here as well, but the release process is not >>>> prepared to handle any of these JSON files for updating the version >>>> elements, i.e. 2.19.0-SNAPSHOT should have been rewritten to 2.19.0 >>>> within the release preparation step. >>>> >>>> Please let me know how to proceed here. Once we resolve this, I will >>>> restart the release. >>>> >>>&
Re: Camel 2.19 Roadmap
Hi Gregor, I've committed my fixes. --- Luca Burgazzoli On Mon, Apr 24, 2017 at 6:10 PM, Luca Burgazzoli wrote: > Hi Gregor, > > I'm running a local build to see if there is any blocking issue some > JIRA I'd like to include [1][2][3], it should not take too much and > I'll post here as son as I have merged my work on master. > > > [1] https://issues.apache.org/jira/browse/CAMEL-11190 > [2] https://issues.apache.org/jira/browse/CAMEL-11191 > [3] https://issues.apache.org/jira/browse/CAMEL-11192 > > > --- > Luca Burgazzoli > > > On Mon, Apr 24, 2017 at 11:11 AM, Gregor Zurowski > wrote: >> Hi Claus, >> >> Alright, I guess this is the best we can do for now. I also agree on >> removing the regular examples from the release. I would actually also >> move them into a separate artifact group. Currently they use the >> group ID org.apache.camel, so we could move them into >> org.apache.camel.example or similar. >> >> I will re-cut the release candidate tonight. >> >> Thanks, >> Gregor >> >> >> On Mon, Apr 24, 2017 at 10:49 AM, Claus Ibsen wrote: >>> Hi Gregor >>> >>> So we have now fixed this by turning of those connector examples as >>> they should not be in the release. >>> >>> We will later re-organize this and see what to do if any of this is >>> needed as releases JAR in maven central. >>> You could consider the same for the regular examples, they should >>> maybe not be released either to maven central. >>> But its a talk for another day. >>> >>> The master branch should be ready for a re-cut of the release. >>> >>> Let us know when you are able to work on this again. Thanks a lot for >>> helping with the releases. >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Apr 24, 2017 at 10:22 AM, Claus Ibsen wrote: >>>> Hi Gregor >>>> >>>> Okay so the connector examples are not yet intended for release (if >>>> they ever would be). >>>> So I have skipped them. >>>> >>>> People can try them from the source code as they do with the other >>>> examples. That works fine. >>>> >>>> For a release process we may also need to add some extra logic so the >>>> SNAPSHOT versions in the json files etc are replaced as part of a >>>> release build. AFAIR you need to run 2 x build, to make it updated, >>>> which you can't usually. >>>> >>>> >>>> >>>> On Sun, Apr 23, 2017 at 10:25 PM, Gregor Zurowski >>>> wrote: >>>>> Hi Everyone: >>>>> >>>>> I have finally managed to resolve all memory-related and >>>>> machine-related issues, but I am hitting another road block in the >>>>> release process. The process fails when the new connector examples >>>>> are about to get pushed to the artifact repository: >>>>> >>>>> [INFO] [ERROR] Failed to execute goal >>>>> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy >>>>> (default-deploy) on project beverage-component: Failed to deploy >>>>> artifacts: Could not transfer artifact >>>>> org.foo:beverage-component:jar:2.19.0 from/to apache.releases.https >>>>> (https://repository.apache.org/service/local/staging/deploy/maven2): >>>>> Failed to transfer file: >>>>> https://repository.apache.org/service/local/staging/deploy/maven2/org/foo/beverage-component/2.19.0/beverage-component-2.19.0.jar. >>>>> Return code is: 400, ReasonPhrase: Bad Request. -> [Help 1] >>>>> >>>>> This is likely caused by the group ID "org.foo" that is used in these >>>>> modules, which will not be accepted by the Apache artifact repository. >>>>> >>>>> I could easily change the group ID of these examples to something like >>>>> "org.apache.camel.example.connector". While attempting to change >>>>> this, I realized that there are JSON files in the example directories >>>>> that directly reference these artifacts, for example in >>>>> /salesforce-upsert-contact-connector/src/main/resources/camel-connector.json: >>>>> >>>>> "groupId" : "org.foo", >>>>> "artifactId" : "salesforce-upsert-contact-connector", >>>>> "ve
Re: [VOTE] Release Apache Camel 2.19.0
+1 --- Luca Burgazzoli On Wed, Apr 26, 2017 at 6:59 PM, Gary Brown wrote: > If there is another build, would appreciate if CAMEL-11198 fix could be > included. > > Regards > Gary > > - Original Message - >> On Wed, Apr 26, 2017 at 3:24 PM, Nicola Ferraro wrote: >> > -1 (non-binding) >> > >> > Found an issue with the new camel-reactive-streams component in spring-boot >> > default config (https://issues.apache.org/jira/browse/CAMEL-11201), that >> > prevents application startup. >> > If we decide to do another build, I'll include the fix in the 2.19.x >> > branch. >> > >> >> IMHO a bit low priority as its a new component. A blocker is more >> existing functionality where users upgrade and it breaks something. >> >> Keep testing and lets see if we find other issues. >> >> And if we re-cut a release we may want to do it from master branch to >> get the other small bits included. >> We usually wait with doing big changes on master while a release is in >> VOTE so we can easily recut from master again. >> >> >> >> >> >> > Nicola >> > >> > >> > >> > On Wed, Apr 26, 2017 at 10:14 AM, Gary Brown wrote: >> > >> >> No that is fine. Thanks. >> >> >> >> - Original Message - >> >> > Hi Gary, >> >> > >> >> > The opentracing component is already listed. Do you miss any specific >> >> > information regarding this component? >> >> > >> >> > Thanks, >> >> > Gregor >> >> > >> >> > >> >> > On Wed, Apr 26, 2017 at 9:26 AM, Gary Brown wrote: >> >> > > Hi >> >> > > >> >> > > Can the opentracing component also be added to the wiki? >> >> > > >> >> > > Thanks. >> >> > > >> >> > > Regards >> >> > > Gary >> >> > > >> >> > > - Original Message - >> >> > >> Hi >> >> > >> >> >> > >> Gregor I think we updated that wiki page at more or less the same >> >> time. >> >> > >> >> >> > >> New components should be added in the section that says - new >> >> > >> component, and not in the top, so I moved them down there. >> >> > >> >> >> > >> On Wed, Apr 26, 2017 at 8:20 AM, Dmitry Volodin >> >> wrote: >> >> > >> > Hi Gregor! >> >> > >> > >> >> > >> > Please also add following new components to the wiki page: >> >> > >> > camel-olingo4 (https://issues.apache.org/jira/browse/CAMEL-11056) >> >> > >> > camel-grpc (https://issues.apache.org/jira/browse/CAMEL-11107) >> >> > >> > >> >> > >> > -- >> >> > >> > Best regards, >> >> > >> > Dmitry >> >> > >> > >> >> > >> > 2017-04-25 22:50 GMT+03:00 Gregor Zurowski < >> >> gre...@list.zurowski.org>: >> >> > >> > >> >> > >> >> Hi Everyone: >> >> > >> >> >> >> > >> >> This is a vote to release Apache Camel 2.19.0, a new minor release >> >> > >> >> with over 670 new features, improvements and bug fixes. A summary >> >> of >> >> > >> >> the changes is available in the Camel wiki: >> >> > >> >> https://cwiki.apache.org/confluence/display/CAMEL/ >> >> Camel+2.19+Release. >> >> > >> >> >> >> > >> >> Release notes: https://issues.apache.org/ >> >> jira/secure/ReleaseNote.jspa? >> >> > >> >> version=12337871&projectId=12311211 >> >> > >> >> >> >> > >> >> Staging repository: >> >> > >> >> https://repository.apache.org/content/repositories/ >> >> orgapachecamel-1073/ >> >> > >> >> >> >> > >> >> Tarballs: https://repository.apache.org/content/repositories/ >> >> > >> >> orgapachecamel-1073/org/apache/camel/apache-camel/2.19.0/ >> >> > >> >> >> >> > >> >> Tag: https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h= >> >> > >> >> 0898c94e5225532f9cf0665d8349eaba5ec0fe25 >> >> > >> >> >> >> > >> >> Please test this release candidate and cast your vote. >> >> > >> >> [ ] +1 Release the binary as Apache Camel 2.19.0 >> >> > >> >> [ ] -1 Veto the release (provide specific comments) >> >> > >> >> >> >> > >> >> The vote is open for at least 72 hours. >> >> > >> >> >> >> > >> >> Due to the many changes introduced with this new release, it would >> >> be >> >> > >> >> beneficial if we could get as many Camel riders involved in >> >> > >> >> testing >> >> > >> >> this release candidate as possible. :) >> >> > >> >> >> >> > >> >> Thanks, >> >> > >> >> Gregor >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> -- >> >> > >> 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: [VOTE] Release Apache Camel 2.19.0 (Attempt #2)
+1 (binding) --- Luca Burgazzoli On Tue, May 2, 2017 at 1:36 PM, Zoran Regvart wrote: > +1 > > I've run integration tests for the Salesforce component against those > artifacts > > zoran > -- > Zoran Regvart
Spring boot starter code generation
Hello, as today the camel-package-maven-plugin is responsible to generate component starters so it generates the properties configuration class as well of the auto configuration one which is good but there may be some cases in which one may want to further tweak the bean creation process, i.e. for stuffs like ehcache/infinispan/hazelcast I'd like to find out if we can integrate with spring caching so you can configure the cache the spring way and reuse it in camel. What would be the best option to keep the auto generation awesomeness and at the same time have a way to tweak the process ? --- Luca Burgazzoli
Re: [VOTE] Release Apache Camel 2.17.7
+1 (binding) --- Luca Burgazzoli On Tue, May 16, 2017 at 11:19 AM, Claus Ibsen wrote: > +1 (binding) > > On Sun, May 14, 2017 at 12:01 PM, Gregor Zurowski > wrote: >> Hi Everyone: >> >> This is a vote for releasing Apache Camel 2.17.7, a new patch release >> that includes 15 bugfixes and improvements. This will likely be our >> last official patch release for the 2.17.x branch >> (https://git-wip-us.apache.org/repos/asf?p=camel.git;a=shortlog;h=refs/heads/camel-2.17.x). >> >> Release notes: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12339843&projectId=12311211 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecamel-1076/ >> >> Tarballs: >> https://repository.apache.org/content/repositories/orgapachecamel-1076/org/apache/camel/apache-camel/2.17.7/ >> >> Tag: >> https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=42784c47116a91902cd34871b63a33315f5d030b >> >> Please test this release candidate and cast your vote. >> [ ] +1 Release the binary as Apache Camel 2.17.7 >> [ ] -1 Veto the release (provide specific comments) >> >> The vote is open for at least 72 hours. >> >> Thanks, >> Gregor > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: Compilation error in camel-ehcache-starter
Will have a look --- Luca Burgazzoli On Wed, May 17, 2017 at 9:06 AM, Claus Ibsen wrote: > Hi > > On master branch we get these compilation errors > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile > (default-compile) on project camel-ehcache-starter: Compilation > failure: Compilation failure: > [ERROR] > /Users/davsclaus/workspace/camel/platforms/spring-boot/components-starter/camel-ehcache-starter/src/main/java/org/apache/camel/component/ehcache/springboot/EhcacheComponentConfiguration.java:[59,32] > cannot find symbol > [ERROR] symbol: class K > [ERROR] location: class > org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration > [ERROR] > /Users/davsclaus/workspace/camel/platforms/spring-boot/components-starter/camel-ehcache-starter/src/main/java/org/apache/camel/component/ehcache/springboot/EhcacheComponentConfiguration.java:[59,35] > cannot find symbol > [ERROR] symbol: class V > [ERROR] location: class > org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration > [ERROR] > /Users/davsclaus/workspace/camel/platforms/spring-boot/components-starter/camel-ehcache-starter/src/main/java/org/apache/camel/component/ehcache/springboot/EhcacheComponentConfiguration.java:[97,31] > cannot find symbol > [ERROR] symbol: class K > [ERROR] location: class > org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration > [ERROR] > /Users/davsclaus/workspace/camel/platforms/spring-boot/components-starter/camel-ehcache-starter/src/main/java/org/apache/camel/component/ehcache/springboot/EhcacheComponentConfiguration.java:[97,34] > cannot find symbol > [ERROR] symbol: class V > [ERROR] location: class > org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration > [ERROR] > /Users/davsclaus/workspace/camel/platforms/spring-boot/components-starter/camel-ehcache-starter/src/main/java/org/apache/camel/component/ehcache/springboot/EhcacheComponentConfiguration.java:[102,32] > cannot find symbol > [ERROR] symbol: class K > [ERROR] location: class > org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration > [ERROR] > /Users/davsclaus/workspace/camel/platforms/spring-boot/components-starter/camel-ehcache-starter/src/main/java/org/apache/camel/component/ehcache/springboot/EhcacheComponentConfiguration.java:[102,35] > cannot find symbol > [ERROR] symbol: class V > [ERROR] location: class > org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration > [ERROR] -> [Help 1] > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: Spring boot starter code generation
Yeah that's something I was thinking about but then I ended up with testing something different, do not know if it is the best way :) So the camel-package-maven-plugin would generate: - org.apache.camel.component.ehcache.springboot.EhcacheComponentAutoConfiguration - org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration - org.apache.camel.component.ehcache.springboot.EhcacheComponentConfigurer - org.apache.camel.component.ehcache.springboot.configurer.DefaultConfigurer Then EhcacheComponentAutoConfiguration applies all the configurer (type EhcacheComponentConfigurer) it can found to the EhcacheComponent it is setting up and there will be at least one that is the DefaultConfigurer that simply apply the properties from EhcacheComponentConfiguration. The advantage of this method is that we can use standard spring annotation to include/exclude configurer without having to manually write all the conditions. I've created a simple example here: https://github.com/lburgazzoli/camel-ehcache-starter --- Luca Burgazzoli On Tue, May 16, 2017 at 11:19 PM, Zoran Regvart wrote: > Hi Luca, > > On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli > wrote: >> What would be the best option to keep the auto generation awesomeness >> and at the same time have a way to tweak the process ? > > BeanDefinitionRegistryPostProcessor can remove and add bean > definitions, so you can do pretty much anything you need. > > So perhaps a BeanDefinitionRegistryPostProcessor to load custom SPI to > perform additional post processing of the bean definition registry, > then have this BeanDefinitionRegistryPostProcessor and SPI interface > in camel-spring-boot, and the implementation of the SPI in the > component starter. The SPI implementation can be loaded using > FactoryFinder. > > zoran > -- > Zoran Regvart
Re: Spring boot starter code generation
Yes that is the idea so users and developers can hook into the auto configuration process without impacting the code generation awesomeness. Will raise a JIRA. --- Luca Burgazzoli On Wed, May 17, 2017 at 12:50 PM, Claus Ibsen wrote: > Hi > > Is the idea to still run the maven plugin to auto generate the spring > boot starter skeleton code, and then be able to write addition source > code for extra stuff? > > If so I would suggest to use separate packages so the auto generated > code and the manual code are separated. > > But yeah good idea for such a functionality as the more we learn and > use spring boot the more we can make it more awesome. > > > > On Wed, May 17, 2017 at 12:29 PM, Luca Burgazzoli > wrote: >> Yeah that's something I was thinking about but then I ended up with >> testing something different, do not know if it is the best way :) >> >> So the camel-package-maven-plugin would generate: >> >> - >> org.apache.camel.component.ehcache.springboot.EhcacheComponentAutoConfiguration >> - org.apache.camel.component.ehcache.springboot.EhcacheComponentConfiguration >> - org.apache.camel.component.ehcache.springboot.EhcacheComponentConfigurer >> - org.apache.camel.component.ehcache.springboot.configurer.DefaultConfigurer >> >> Then EhcacheComponentAutoConfiguration applies all the configurer >> (type EhcacheComponentConfigurer) it can found to the EhcacheComponent >> it is setting up and there will be at least one that is the >> DefaultConfigurer that simply apply the properties from >> EhcacheComponentConfiguration. The advantage of this method is that we >> can use standard spring annotation to include/exclude configurer >> without having to manually write all the conditions. >> >> I've created a simple example here: >> https://github.com/lburgazzoli/camel-ehcache-starter >> >> --- >> Luca Burgazzoli >> >> >> On Tue, May 16, 2017 at 11:19 PM, Zoran Regvart wrote: >>> Hi Luca, >>> >>> On Tue, May 16, 2017 at 6:23 PM, Luca Burgazzoli >>> wrote: >>>> What would be the best option to keep the auto generation awesomeness >>>> and at the same time have a way to tweak the process ? >>> >>> BeanDefinitionRegistryPostProcessor can remove and add bean >>> definitions, so you can do pretty much anything you need. >>> >>> So perhaps a BeanDefinitionRegistryPostProcessor to load custom SPI to >>> perform additional post processing of the bean definition registry, >>> then have this BeanDefinitionRegistryPostProcessor and SPI interface >>> in camel-spring-boot, and the implementation of the SPI in the >>> component starter. The SPI implementation can be loaded using >>> FactoryFinder. >>> >>> zoran >>> -- >>> Zoran Regvart > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: Spring boot starter code generation
The configurer I'm working on as today are only supposed to post-process our spring-boot auto magics so there's not side effects for a end user but yes it could be extended later on to any component/language/dataformat in the registry. And yes I'm also taking into account an option to enable/disable configurer on different level (always in spring boot), i.e. disable all configurer for a component/language/dataformat or just disable a single one. Let me see what we can have and how it works in this first round then we can discuss the next steps. --- Luca Burgazzoli On Thu, May 18, 2017 at 9:31 AM, Zoran Regvart wrote: > Great discussion :) > > On Thu, May 18, 2017 at 9:24 AM, Nicola Ferraro wrote: >> I wonder (before this goes too far and we add more stuff) if we should add >> a easy way to disable a configurer (also a configurer defined by Camel). > > I think that if this is all at configuration time (before component > starts), then you have an option to opt-out by not including the > configurer on the classpath and to provide your own configurer that > rollbacks prevous configurer's changes; so perhaps just something like > Ordered interface in Spring? > > zoran > -- > Zoran Regvart
Re: [HELP] - Profile camel-core for optimization and faster startup
It may be worth adding a small number of JMH micro benchmarks - not to be used as performances metrics - on camel core so we can spot potential regressions. --- Luca Burgazzoli On Sun, May 28, 2017 at 11:31 AM, Claus Ibsen wrote: > Hi > > I have found some more spots for optimisations which I have committed > over the last couple of days. > > Its been several years since we last did such things last, and I have > to admit we have introduced some code that add more object allocation > and a few performance drawbacks since then. > > So with the help of profilers we should be able to improve the > situation for the Camel 2.20 release. > > I have to give credit to Luca for bring this idea up about making > Camel startup faster and look into the number of objects allocated > etc. Usually Camel has negligible performance overhead in the grand > scheme of things. But we have more fine grained performance statistics > today which records the time taken in every step messages are routed. > This uses the StopWatch object which we frankly create too many new > instances. So by reducing those we can reduce the object allocations > and therefore the JVM GC characteristics. > > In the stuff I have optimised you can find the JIRA tickets with > Optimise as prefix. I usually have attached some screenshots from the > profiler so you can see before vs after situations). > > > We have two areas that can be improved > > 1) startup Camel faster (jndi registry, caffine lru cache, and the > uuid generator is a bit slow in their constructors) > 2) faster routing per message at runtime (potential optimise by > reducing object allocations, turn off some features less/seldom in > use, optimise code logic in hot-spot areas, reduce size of internal > state objects, avoid thread contention from synchronized methods, > etc.) > > > > On Fri, May 26, 2017 at 3:59 PM, Claus Ibsen wrote: >> Hi >> >> We have found a few spots to optimize the camel-core source code for >> thread contention and something else. >> >> You can use a profile tool such as YourKit which is excellent at >> identifying spots and visualizing what goes on in the JVM. >> >> We have used it in the past to optimise stuff. However recently Luca >> asked about making Camel startup faster: >> https://issues.apache.org/jira/browse/CAMEL-11321 >> >> And although fast startup is not excatly the same as runtime >> performance then they are still related. A profile can help identify >> places for improvements. >> >> I have pushed a sample project at >> https://github.com/davsclaus/camel-profile-sample >> >> You can then run this via >> >>mvn spring-boot:run >> >> And then attach YourKit profiler. >> >> However if you use IDEA then you can start YourKit, then from YourKit >> you can choose Integrate with IDE ... and then chose IDEA and then say >> ok even if IDEA is also running. >> >> In IDEA you should see a YourKit icon if you right-click on the >> SampleCamelApplication to run this application, then you can chose >> that to profile, and it run the app with profiler. >> >> You then switch to YourKit and you should start see data. >> To check for thread contention, then select the "Monitor Usage" tab, >> and then click the gear button with the play icon "Start Monitor >> Profile" which then starts capture data. >> >> For YourKit you can request a trial license that works for 2 weeks. >> >> >> -- >> 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
Master/Leader RoutePolicy deprecation/fix
Hello, I did a small review of the RoutePolicy we have for having one route master and one slave and all have an issue as they are invoked after the route is started so the consumer may have the time to consume some data before the policy kicks in [1]. There is now a zookeeper-master component and some work is in in progress [2] in such area so wondering if we should deprecate such policies once [2] is done with or without fixing them. If we decide to fix them we could make the route to not auto start on policy initialization so then the policy could take care to start/stop the routes it is supposed to manage, an example of such behaviour can be see in my experimental branch [3] and in CuratorLeaderPolicy [4]. Thoughts ? [1] https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/impl/RouteService.java#L213-L232 [2] https://issues.apache.org/jira/browse/CAMEL-10320 [3] https://github.com/lburgazzoli/apache-camel/blob/route-policy/components/camel-infinispan/src/main/java/org/apache/camel/component/infinispan/policy/InfinispanRoutePolicy.java [4] https://github.com/apache/camel/blob/master/components/camel-zookeeper/src/main/java/org/apache/camel/component/zookeeper/policy/CuratorLeaderRoutePolicy.java --- Luca Burgazzoli
Re: Master/Leader RoutePolicy deprecation/fix
Make sense, will raise the JIRAs soon to create the LeaderElectionService which can the be leveraged by Dhiraj on CAMEL-10320 and route policies. --- Luca Burgazzoli On Mon, May 29, 2017 at 5:48 PM, Nicola Ferraro wrote: > To me it seems that the route policy has everything needed to create > master/slave routes. The autostartup=false flag can be forced on the > "onInit" callback method as done in [3]. I think it's ok doing so, because > it's responsibility of the policy to change standard behavior of the route. > > I've seen some leader election policies implemented in Camel and I think > they are pretty similar. So I was thinking why we don't define just a > single LeaderElectionRoutePolicy in Camel core. It will manage the burden > of starting/stopping consumers (that is a delicate task and needs to take > care of many details) and will be notified by a specific > "LeaderElectionService" when gaining or losing the leadership (a callback > method with a boolean argument). This way, each leader election "algorithm" > needs just to implement the "LeaderElectionService" interface and just > decide when he is the leader (and when he's no more), nothing else. > > This will also allow us to re-use leader election easily outside the > purpose of starting/stopping camel routes. And it is a good thing for us > developing Camel, but we can also expose leader election services directly > to users, because creating a cluster-wide singleton service is not a > trivial task, but Camel can to it easily. > > In conclusion, for me: > - RoutePolicy wins over master > - Better having just 1 generic LeaderRoutePolicy and a specific > LeaderElectionService for each "algorithm" > > > Nicola > > On Mon, May 29, 2017 at 4:57 PM, Claus Ibsen wrote: > >> Hi >> >> Yeah the set auto startup=false seems like a good idea. >> >> On Mon, May 29, 2017 at 4:44 PM, Luca Burgazzoli >> wrote: >> > Hello, >> > >> > I did a small review of the RoutePolicy we have for having one route >> > master and one slave and all have an issue as they are invoked after >> > the route is started so the consumer may have the time to consume some >> > data before the policy kicks in [1]. >> > >> > There is now a zookeeper-master component and some work is in in >> > progress [2] in such area so wondering if we should deprecate such >> > policies once [2] is done with or without fixing them. >> > >> > If we decide to fix them we could make the route to not auto start on >> > policy initialization so then the policy could take care to start/stop >> > the routes it is supposed to manage, an example of such behaviour can >> > be see in my experimental branch [3] and in CuratorLeaderPolicy [4]. >> > >> > Thoughts ? >> > >> > [1] https://github.com/apache/camel/blob/master/camel-core/ >> src/main/java/org/apache/camel/impl/RouteService.java#L213-L232 >> > [2] https://issues.apache.org/jira/browse/CAMEL-10320 >> > [3] https://github.com/lburgazzoli/apache-camel/blob/ >> route-policy/components/camel-infinispan/src/main/java/org/ >> apache/camel/component/infinispan/policy/InfinispanRoutePolicy.java >> > [4] https://github.com/apache/camel/blob/master/components/ >> camel-zookeeper/src/main/java/org/apache/camel/component/zookeeper/policy/ >> CuratorLeaderRoutePolicy.java >> > >> > --- >> > Luca Burgazzoli >> >> >> >> -- >> Claus Ibsen >> - >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 >>
[HEADS UP] Camel clustering bits
Hello, I've been working on CAMEL-11362 to create a leader election service in recent times and I've ended up with some initial bits of a potential clustering service for Camel [1]. So fare there are a few simple interfaces: - CamelClusterService - CamelClusterView - CamelClusterMember The CamelClusterService is just a regular camel service and is responsible to create views of the cluster; a view is like a "group" with its own set of resources like a leader/services/etc and i.e. broadcast of messages should not go beyond its borders, etc; how the view is mapped then depends on the underlying technology used so it can be a group in atomix/jgroups, a path in zk/etcd, a map in hazelcast/infinispan, etc. As today the View API is limited to leader election and topology events (member joining/leaving the view) and I've build a generic RoutePolicy and RoutePolicyFactory on top of them [2][3]. A future work may be to add support for service discovery, load balancing ad more. I also started the implementation of camel-atomix based on the atomix.io project which offers some easy to use APIs for distributed systems so an implementation of the API can be found here [4] and a test here [5]. Feedback is very welcome. [1] https://github.com/lburgazzoli/apache-camel/tree/CAMEL-11362/camel-core/src/main/java/org/apache/camel/ha [2] https://github.com/lburgazzoli/apache-camel/blob/CAMEL-11362/camel-core/src/main/java/org/apache/camel/impl/ha/ClusteredRoutePolicy.java [3] https://github.com/lburgazzoli/apache-camel/blob/CAMEL-11362/camel-core/src/main/java/org/apache/camel/impl/ha/ClusteredRoutePolicyFactory.java [4] https://github.com/lburgazzoli/apache-camel/tree/CAMEL-11362/components/camel-atomix/src/main/java/org/apache/camel/component/atomix/ha [5] https://github.com/lburgazzoli/apache-camel/blob/CAMEL-11362/components/camel-atomix/src/test/java/org/apache/camel/component/atomix/ha/AtomixRoutePolicyTest.java --- Luca Burgazzoli
Re: [HEADS UP] Camel clustering bits
First bits merged --- Luca Burgazzoli On Thu, Jun 15, 2017 at 11:05 AM, Nicola Ferraro wrote: > +1 > > Really a great work Luca. It's completely separated from the route policy > so that we can also implement the generic master component on top of it. > But it can also be used for other purposes by just implementing a listener > interface. The cluster view is also a clean way to monitor the cluster > status. > > You have also shown how to clusterize the whole context (all routes) using > the route policy factory, and route policies can also be set at route level. > > So, merge it and I'll implement the Kubernetes cluster service with this > new spec! > > > > On Wed, Jun 14, 2017 at 3:49 PM, Claus Ibsen wrote: > >> +1 >> >> Great work Luca. Its good to see this coming in camel-core, as we now >> have many more Camel components that does clustering and leader >> elections. It makes good benefit to have some common reusable code >> from camel-core. >> >> >> >> On Wed, Jun 14, 2017 at 11:36 AM, Luca Burgazzoli >> wrote: >> > Hello, >> > >> > I've been working on CAMEL-11362 to create a leader election service >> > in recent times and I've ended up with some initial bits of a >> > potential clustering service for Camel [1]. >> > >> > So fare there are a few simple interfaces: >> > - CamelClusterService >> > - CamelClusterView >> > - CamelClusterMember >> > >> > The CamelClusterService is just a regular camel service and is >> > responsible to create views of the cluster; a view is like a "group" >> > with its own set of resources like a leader/services/etc and i.e. >> > broadcast of messages should not go beyond its borders, etc; how the >> > view is mapped then depends on the underlying technology used so it >> > can be a group in atomix/jgroups, a path in zk/etcd, a map in >> > hazelcast/infinispan, etc. >> > >> > As today the View API is limited to leader election and topology >> > events (member joining/leaving the view) and I've build a generic >> > RoutePolicy and RoutePolicyFactory on top of them [2][3]. A future >> > work may be to add support for service discovery, load balancing ad >> > more. >> > >> > I also started the implementation of camel-atomix based on the >> > atomix.io project which offers some easy to use APIs for distributed >> > systems so an implementation of the API can be found here [4] and a >> > test here [5]. >> > >> > >> > Feedback is very welcome. >> > >> > >> > [1] https://github.com/lburgazzoli/apache-camel/tree/ >> CAMEL-11362/camel-core/src/main/java/org/apache/camel/ha >> > [2] https://github.com/lburgazzoli/apache-camel/blob/ >> CAMEL-11362/camel-core/src/main/java/org/apache/camel/ >> impl/ha/ClusteredRoutePolicy.java >> > [3] https://github.com/lburgazzoli/apache-camel/blob/ >> CAMEL-11362/camel-core/src/main/java/org/apache/camel/impl/ha/ >> ClusteredRoutePolicyFactory.java >> > [4] https://github.com/lburgazzoli/apache-camel/tree/ >> CAMEL-11362/components/camel-atomix/src/main/java/org/ >> apache/camel/component/atomix/ha >> > [5] https://github.com/lburgazzoli/apache-camel/blob/ >> CAMEL-11362/components/camel-atomix/src/test/java/org/ >> apache/camel/component/atomix/ha/AtomixRoutePolicyTest.java >> > >> > >> > --- >> > Luca Burgazzoli >> >> >> >> -- >> Claus Ibsen >> - >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 >>
Re: Compile error in camel-atomix-starter
Should have been fixed --- Luca Burgazzoli On Sat, Jun 17, 2017 at 8:08 AM, Claus Ibsen wrote: > Hi > > Latest code cannot compile at > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile > (default-compile) on project camel-atomix-starter: Compilation > failure: Compilation failure: > [ERROR] > /Users/davsclaus/workspace/camel/platforms/spring-boot/components-starter/camel-atomix-starter/src/main/java/org/apache/camel/component/atomix/client/map/springboot/AtomixClientMapComponentConfiguration.java:[42,13] > cannot find symbol > [ERROR] symbol: class C > [ERROR] location: class > org.apache.camel.component.atomix.client.map.springboot.AtomixClientMapComponentConfiguration > [ERROR] > /Users/davsclaus/workspace/camel/platforms/spring-boot/components-starter/camel-atomix-starter/src/main/java/org/apache/camel/component/atomix/client/map/springboot/AtomixClientMapComponentConfiguration.java:[63,12] > cannot find symbol > [ERROR] symbol: class C > [ERROR] location: class > org.apache.camel.component.atomix.client.map.springboot.AtomixClientMapComponentConfiguration > [ERROR] > /Users/davsclaus/workspace/camel/platforms/spring-boot/components-starter/camel-atomix-starter/src/main/java/org/apache/camel/component/atomix/client/map/springboot/AtomixClientMapComponentConfiguration.java:[67,34] > cannot find symbol > [ERROR] symbol: class C > [ERROR] location: class > org.apache.camel.component.atomix.client.map.springboot.AtomixClientMapComponentConfiguration > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with > the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :camel-atomix-starter > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Apache Camel 2.20 release after summer
+1 --- Luca Burgazzoli On Mon, Jul 10, 2017 at 8:11 PM, Gregor Zurowski wrote: > Hi, > > I would be available for cutting the 2.20 release in September, if > everyone agrees. > > Also +1 for creating minor releases more frequently. > > Thanks, > Gregor > > > On Sat, Jul 8, 2017 at 9:58 AM, Claus Ibsen wrote: >> Hi >> >> I think it can benefit the community if we try to get a 2.20 release >> out after the summer break, such as in early/mid September. >> >> The reason is that this release has some internal optimisations, >> reduced object allocations, and faster startup that would benefit >> Camel end users. Also end users can plugin the camel-headersmap module >> to use a slightly faster map implementation for case-insensitive keys. >> >> There has also been work on improving the startup/shutdown sequence of >> Camel when running in Spring so this happens better. >> >> On the same page I would also like to see us being able to do a bit >> more frequent releases of Camel minor releases (eg 2.19, 2.20, 2.21 >> etc) than only 2 times per year. If we can get the momentum up to >> 2.5-3.5 times per year then that would be better. >> >> Any thoughts? >> >> >> -- >> Claus Ibsen >> - >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2
Camel 3.0 : make default camel context "modular"
Hello devs, not sure if it make sense for everyone but after working a little bit on the default camel context for CAMEL-11443 I think we should try to break it into logical components to make it easy to evolve and improve it so for camel 3.0 I was thinking something like: - Add a concept of RouteLoader which is in charge of building the route definitions from a source, to eventually monitor the source for changes and then refresh the contex so i.e. we can move the current process of loading routes from xml to a dedicated XMLRouteLoader. It should be possible to add more loaders so one can load routes from different sources (yaml, json, groovy) - Add a concept of RouteControler which is in charge of routes' life-cycle, this is partially done by CAMEL-11443 but for 2.x it will be more a placeholder that an concrete implementation as the life-cycle of routes involves quite a bit of code and it is quite hard to introduce a proper life-cycle manager without breaking the things. In my mind the camel context should be a bridge between RouteLoader and the RouteController then the specific route controller can do its job like: - start routes in parallel - handle reoutes dependencies (CAMEL-8599) - restart failing routes - etc - Have a single and complete source fo events, as today we can listen for events using different concepts: - LifecycleStrategy - StartupListener - EventNotifier - RoutePolicy Some of them seems overlapping a little so we may create 'contextual' listeners like RouteEventListener, ExchangeEventListener, etc and then i.e. the RoutePolicy could extend only what make sense for the context so for the camel context prospective only an event has to be fired. Listeenrs can eventually throw an uncheckd "VetoedException" if the operation should not be done (i.e. a policy may prevent to stop or start a route if certain circumstances). I know it is not a simple task but I think it is wort at least try to do it. Thoughts ? --- Luca Burgazzoli
Re: Camel 3.0 : make default camel context "modular"
It is still quite risky now too :) That's why I just implemented a very tiny RouteController. I Was too scared to eventually introduce nasty an unpredictable regression. Thinking aloud: we may have a "reactive" change so the route loader is a subscriber of the reload strategy so when the strategy emits a signal, the loader does its job asynchronously and we can put some intermediate steps like throttling the changes so that only the last one get taken into account. --- Luca Burgazzoli On Wed, Jul 19, 2017 at 9:10 AM, Claus Ibsen wrote: > Hi Luca > > Yes sounds like good ideas. > > I do agree that the loading/startup of routes logic in > DefaultCamelContext would have benefitted from being refactored many > years ago, but then doing bigger refactoring in such a core > functionality was also a bit "risky". The notion of a RouteLoader is a > good idea, there is also the ReloadStrategy which we should think > about how that may work with the RouteLoader and how it can watch some > external system for changes and then trigger a reload. > > > > > On Mon, Jul 17, 2017 at 1:23 PM, Luca Burgazzoli > wrote: >> Hello devs, >> >> not sure if it make sense for everyone but after working a little bit on >> the default camel context for CAMEL-11443 I think we should try to break >> it into logical components to make it easy to evolve and improve it so >> for camel 3.0 I was thinking something like: >> >> - Add a concept of RouteLoader which is in charge of building the route >> definitions from a source, to eventually monitor the source for >> changes and then refresh the contex so i.e. we can move the current >> process of loading routes from xml to a dedicated XMLRouteLoader. It >> should be possible to add more loaders so one can load routes from >> different sources (yaml, json, groovy) >> >> - Add a concept of RouteControler which is in charge of routes' >> life-cycle, this is partially done by CAMEL-11443 but for 2.x it will >> be more a placeholder that an concrete implementation as the >> life-cycle of routes involves quite a bit of code and it is quite hard >> to introduce a proper life-cycle manager without breaking the things. >> In my mind the camel context should be a bridge between RouteLoader >> and the RouteController then the specific route controller can do its >> job like: >> >> - start routes in parallel >> - handle reoutes dependencies (CAMEL-8599) >> - restart failing routes >> - etc >> >> - Have a single and complete source fo events, as today we can listen >> for events using different concepts: >> >> - LifecycleStrategy >> - StartupListener >> - EventNotifier >> - RoutePolicy >> >> Some of them seems overlapping a little so we may create 'contextual' >> listeners like RouteEventListener, ExchangeEventListener, etc and >> then i.e. the RoutePolicy could extend only what make sense for the >> context so for the camel context prospective only an event has to be >> fired. Listeenrs can eventually throw an uncheckd "VetoedException" >> if the operation should not be done (i.e. a policy may prevent to >> stop or start a route if certain circumstances). >> >> I know it is not a simple task but I think it is wort at least try to >> do it. >> >> >> Thoughts ? >> >> >> --- >> Luca Burgazzoli > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Component Extensions
Hello, I've recently been working on CAMEL-11550 [1] aimed to introduce the concept of "Component Extensions" which are functionalities not directly targeting Camel runtime but that can provide some useful stuffs as example for tooling. You can find the implementation on my camel fork [2] which include: - Core API for ComponentExtensions - Refactor of the ComponentVerifier to be exposed as extension and deprecation of the old VerifiableComponent - Creation of a MetaDataExtension for ServivceNow aimed to retrieve a Json Schema definition for the ServiceNow objects - Creation of a maven plugin to generate POJOs for the ServiceNow objects leveraging the MetaDataExtension As this new "Component Extension" concept has some minor impacts on camel-core I'd like to have your opinion before merging it. Regards, Luca [1] https://issues.apache.org/jira/browse/CAMEL-11550 [2] https://github.com/lburgazzoli/apache-camel/tree/component-extensions --- Luca Burgazzoli
Re: Component Extensions
Would be nice to make @Metadata repeatable so we can better express
multiple concepts like:
@Metadata(label = "extensions", types = { A.class, B.class, ...})
@Metadata(label = "cloud,saas")
class MyComponent extends DefaultComponent {
}
---
Luca Burgazzoli
On Fri, Aug 4, 2017 at 1:35 PM, Claus Ibsen wrote:
> Hey Luca
>
> Just took a bit of look, especially the first commit about the changes
> involving camel-core.
>
> I really like this, great work, its more cleaner and the code is
> separated into that component.extension package.
>
> +1
>
> Down the road we should have the some metadata on @Metadata or
> something so we can harvest this via the camel apt compiler plugin and
> generate in the json metadata file which extensions a component
> provides, so tooling can be aware of this. We can then have a list of
> known extensions such as the verifier, and metadata etc.
>
>
>
> On Fri, Aug 4, 2017 at 11:50 AM, Luca Burgazzoli
> wrote:
>> Hello,
>>
>> I've recently been working on CAMEL-11550 [1] aimed to introduce the
>> concept of "Component Extensions" which are functionalities not directly
>> targeting Camel runtime but that can provide some useful stuffs as
>> example for tooling.
>>
>> You can find the implementation on my camel fork [2] which include:
>>
>> - Core API for ComponentExtensions
>> - Refactor of the ComponentVerifier to be exposed as extension and
>> deprecation of the old VerifiableComponent
>> - Creation of a MetaDataExtension for ServivceNow aimed to retrieve
>> a Json Schema definition for the ServiceNow objects
>> - Creation of a maven plugin to generate POJOs for the ServiceNow
>> objects leveraging the MetaDataExtension
>>
>> As this new "Component Extension" concept has some minor impacts on
>> camel-core I'd like to have your opinion before merging it.
>>
>>
>> Regards,
>> Luca
>>
>>
>> [1] https://issues.apache.org/jira/browse/CAMEL-11550
>> [2] https://github.com/lburgazzoli/apache-camel/tree/component-extensions
>>
>>
>> ---
>> Luca Burgazzoli
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Health Check API
Hello, I've been working a little on the Health Check API [1] implementation an the code is available in my Apache Camel fork [2]. There is now a a new package [3] that defines the following concepts: - HealthCheck this represent an health check and defines the some basic contract i.e the response; - HealthCheckConfiguration this is a basic coonfiguration object that holds some basic settings like the minimum delay between calls, the number of time a service may be reported as unhealthy before meking the check as failed; beside those simple options, is then responsability of the check impl. to eventually implement further limitations; - HealthCheckRegistry this is just a registry, it doesn't have any method to trigger checks and it has intentionally been kept simple as in the future it may be superseeded by an internal camel registry [4]; - HealthCheckRepository this is a simple interface to define health check providers and by default there is one that grabs all the checks available in the registry so you can add your own check i.e. istantiating your bean in spring/spring-boot; components can provide theirs own repository. - HealthCheckService this is a simple service that runs in the background and invokes the checks according to a schedule. The default camel context sets-up a default implementation of the health check registry which you can override by putting your own implementation in the camel registry as usual. Check are not active by default so you need to explicit enable/configure them. The current implementation has a number of limitations: - it is spring-boot oriented for demostration purpose so you can't access health checks using JMX (but it is planned); - it is focused on monitoring the status of external systems so there are a few implementations based on the Component verifier extension: 1. a ServiceNow instance check to report if an instances is alive 2. a simple undertow based http check that issue an http get to an http endpoint There is also a simple consul repository that let you to reuse consul checks [5] so i.e. you can have a single check to monitor the status of twitter and reuse it in all your microservices. An example can be found in my fork [6] My next goals are: 1. define some core checks to monitor the health of the camel context i.e. fail if there is an excessive number of errors, if the latency is too high, etc. 2. expose check through JMX. 3. use health checks for ServiceCall EIP 4. use health checks in Clustering/Superving route controller Any feedback is very welcome, Luca [1] https://issues.apache.org/jira/browse/CAMEL-10026 [2] https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc [3] https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc/camel-core/src/main/java/org/apache/camel/health [4] https://issues.apache.org/jira/browse/CAMEL-10792 [5] https://www.consul.io/docs/agent/checks.html [6] https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks --- Luca Burgazzoli
Re: Health Check API
Correct spring boot here is used for demonstration purpose only to make it easy to configure health checks and to consume them using i.e. curl but the core check is pure camel :) --- Luca Burgazzoli On Mon, Sep 4, 2017 at 5:16 PM, Claus Ibsen wrote: > Hi Luca > > I will take a closer look tomorrow, I just peaked a bit today. > > Just to be sure, the implementation of the logic that performs the > actual health check is agnostic? i.e. its not tied to must be using > Spring Boot. And that logic is if possible reusing the "ping check" > (i.e. verifier extension). > > So the spring boot health check is currently for making it easier for > end users to configure it via spring boot configuration? > > > > On Mon, Sep 4, 2017 at 4:01 PM, Luca Burgazzoli wrote: >> Hello, >> >> I've been working a little on the Health Check API [1] implementation an >> the code is available in my Apache Camel fork [2]. There is now a a new >> package [3] that defines the following concepts: >> >> - HealthCheck >> >> this represent an health check and defines the some basic contract i.e >> the response; >> >> - HealthCheckConfiguration >> >> this is a basic coonfiguration object that holds some basic settings >> like the minimum delay between calls, the number of time a service may >> be reported as unhealthy before meking the check as failed; beside >> those simple options, is then responsability of the check impl. to >> eventually implement further limitations; >> >> - HealthCheckRegistry >> >> this is just a registry, it doesn't have any method to trigger checks >> and it has intentionally been kept simple as in the future it may be >> superseeded by an internal camel registry [4]; >> >> - HealthCheckRepository >> >> this is a simple interface to define health check providers and by >> default there is one that grabs all the checks available in the >> registry so you can add your own check i.e. istantiating your bean >> in spring/spring-boot; components can provide theirs own repository. >> >> - HealthCheckService >> >> this is a simple service that runs in the background and invokes the >> checks according to a schedule. >> >> The default camel context sets-up a default implementation of the health >> check registry which you can override by putting your own implementation >> in the camel registry as usual. Check are not active by default so you >> need to explicit enable/configure them. >> >> The current implementation has a number of limitations: >> >> - it is spring-boot oriented for demostration purpose so you can't >> access health checks using JMX (but it is planned); >> - it is focused on monitoring the status of external systems so there >> are a few implementations based on the Component verifier extension: >> >> 1. a ServiceNow instance check to report if an instances is alive >> 2. a simple undertow based http check that issue an http get to an >> http endpoint >> >> There is also a simple consul repository that let you to reuse consul >> checks [5] so i.e. you can have a single check to monitor the status >> of twitter and reuse it in all your microservices. >> >> An example can be found in my fork [6] >> >> My next goals are: >> >> 1. define some core checks to monitor the health of the camel context >>i.e. fail if there is an excessive number of errors, if the latency >>is too high, etc. >> 2. expose check through JMX. >> 3. use health checks for ServiceCall EIP >> 4. use health checks in Clustering/Superving route controller >> >> >> Any feedback is very welcome, >> Luca >> >> >> [1] https://issues.apache.org/jira/browse/CAMEL-10026 >> [2] https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc >> [3] >> https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc/camel-core/src/main/java/org/apache/camel/health >> [4] https://issues.apache.org/jira/browse/CAMEL-10792 >> [5] https://www.consul.io/docs/agent/checks.html >> [6] >> https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks >> >> >> --- >> Luca Burgazzoli > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: Health Check API
--- Luca Burgazzoli On Tue, Sep 5, 2017 at 2:17 PM, Claus Ibsen wrote: > Hi Luca > > Looks really good. > > There is a few typo's and the likes in the source code I looked at. > Will try to do a github comment so you can see them as well later, or > when the code is merged later. > > 1) > For the doCall implementation when you implement a health check, then > what would happen if that methods throws an runtime exception? I think > we need to clarify on the javadoc what the contract is, and if an > exception would then render the check to be status = DOWN or what? > I'd expect the implementation to wrap it and decide if the service is healthy or not so yeah, I'll make it clear. > > 2) > I think the spring boot auto configuration prefixes for the health > checks for the components such as undertow, servicenow etc should all > be under the same prefix as the component itself, eg > > eg > camel.undertow.health.checks[spring-health].interval = 5s > > should be > camel.component.undertow.health.checks[spring-health].interval = 5s > > Then everything you can configure in the undertow component is with > the same prefix and its consistent. > Agree. > > 3) > To implement a custom health check and have spring boot auto > configuration, then you would have to write that configuration code > yourself / manually? > At the moment yes as the layout is not defined but it may be eventually auto generated like the starters. > > 4) > I wonder in the servicenow health check where you configure the > instance id, username etc again, whether you may want to be able to > just refer to the existing configuration so you do not repeat > yourself? > > https://github.com/lburgazzoli/apache-camel/blob/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks/application/src/main/resources/application.properties#L66 > Yeah, that was an example non properly cleaned up/explained but by default the servicenow reuse component's configuration. > > 5) > In this example it is a bit confusing that the comment say the health > check is enabled and then the value below is false > https://github.com/lburgazzoli/apache-camel/blob/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks/application/src/main/resources/application.properties#L36 > > 6) > ... and as well there is 2 indicator.enabled in that example. Yeah, it definitively need to be cleaned up. > > > > On Mon, Sep 4, 2017 at 5:16 PM, Claus Ibsen wrote: >> Hi Luca >> >> I will take a closer look tomorrow, I just peaked a bit today. >> >> Just to be sure, the implementation of the logic that performs the >> actual health check is agnostic? i.e. its not tied to must be using >> Spring Boot. And that logic is if possible reusing the "ping check" >> (i.e. verifier extension). >> >> So the spring boot health check is currently for making it easier for >> end users to configure it via spring boot configuration? >> >> >> >> On Mon, Sep 4, 2017 at 4:01 PM, Luca Burgazzoli >> wrote: >>> Hello, >>> >>> I've been working a little on the Health Check API [1] implementation an >>> the code is available in my Apache Camel fork [2]. There is now a a new >>> package [3] that defines the following concepts: >>> >>> - HealthCheck >>> >>> this represent an health check and defines the some basic contract i.e >>> the response; >>> >>> - HealthCheckConfiguration >>> >>> this is a basic coonfiguration object that holds some basic settings >>> like the minimum delay between calls, the number of time a service may >>> be reported as unhealthy before meking the check as failed; beside >>> those simple options, is then responsability of the check impl. to >>> eventually implement further limitations; >>> >>> - HealthCheckRegistry >>> >>> this is just a registry, it doesn't have any method to trigger checks >>> and it has intentionally been kept simple as in the future it may be >>> superseeded by an internal camel registry [4]; >>> >>> - HealthCheckRepository >>> >>> this is a simple interface to define health check providers and by >>> default there is one that grabs all the checks available in the >>> registry so you can add your own check i.e. istantiating your bean >>> in spring/spring-boot; components can provide theirs own repository. >>> >>> - HealthCheckService >>> >>> this is a simple service that runs in the background and invokes th
Re: Hierarchical registry for CamelContext
Hi,
I was thinking if instead we could have the camel context have its own
registry and end users can add their own "bean repository", like
context.addBeanRepository(new SpringBeanRepository())
context.addBeanRepository(new JNDIRepositoy())
Then when asking the registry to lookup beans, it will go through the
repositories according to their order and if it does not find any its
internal repositories which can then be used to add internal stuffs
like rest/service-call/etc configurations and so on.
Would that make sense ?
---
Luca Burgazzoli
On Mon, Feb 6, 2017 at 10:41 AM, Claus Ibsen wrote:
> Hi
>
> Yeah the idea of having it internal and named as containerRegistry, or
> maybe better named as contextRegistry or internalRegistry or
> camelInternalRegistry to make it stand out its not for Camel end users
> per see.
>
> A side bonus can be that we could make this internal registry
> available for unit testing Camel where users sometimes have a little
> trouble adding beans to the registry when using spring / cdi / java /
> karaf et all. There is a couple of JIRAs about this. Then the APIs on
> camel-test could offer a way to register custom beans that take
> priority over the regular registry.
>
>
>
>
>
>
> On Mon, Feb 6, 2017 at 10:13 AM, Luca Burgazzoli
> wrote:
>> Well, what we have as today is just fine but sometime it requires a
>> little bit of additional work and maintenance even it is not strictly
>> needed.
>> Let's take as example hystrix and service call stuffs we added recently:
>>
>> 1. hystrix configuration is retrieved from the registry but work in
>> spring only as blueprint and cdi support is not implemented and would
>> require additional work, even the spring support is a little limited.
>> 2. service call configurations can be retrieved from the camel context
>> (via getter method) or from the registry but configurations you add to
>> the camel context element are added to the context, not the registry
>> so the behavior is a little different and it pollute the camel context
>> with additional methods.
>> 3. Add support for service-call to spring & co may require to write a
>> custom bean factory
>> 4. hystrix and service-call configurations are not supposed to be used
>> outside the camel context, so having them available for DI in
>> spring/blueprint/cdi does not make much sense
>>
>> The proposed solution aim to harmonize such things by adding them to a
>> camel contex own registry.
>> Of course the container specific registry can still be used to
>> configure hystrix/service-call and it is used first, something like:
>>
>> registry.lookupByName(String name, Class type) {
>> Object answer = containerRegistry.lookupByName(name);
>> if (answer == null) {
>> answer = contextRegistry,.lookupByName(name);
>> }
>>
>> return answer;
>> }
>>
>>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Fri, Feb 3, 2017 at 4:27 PM, Paul Gale wrote:
>>> Luca,
>>>
>>> Can you outline either some particular business problem that you're trying
>>> to solve or some current impediment to a solution that would be remedied by
>>> your proposed design change?
>>>
>>> Perhaps a few use case scenarios might help demonstrate the need. Just a
>>> thought.
>>>
>>> Thanks,
>>> Paul
>>>
>>> On Fri, Feb 3, 2017 at 8:39 AM, Luca Burgazzoli
>>> wrote:
>>>
>>>> Yes an easy way to register beans that are not really meaningful
>>>> outside the camel context and maybe beans we do not want to make
>>>> available through dependency injection so they can't be easily
>>>> modified outside.
>>>> The hierarchical nature is only to make it transparent for consumer
>>>> i.e. a service call / hystrix implementation would search in the
>>>> registry and do not care were the bean come from.
>>>>
>>>> Indeed I'm not sure it is the best option, still need to experiment about
>>>> it.
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Fri, Feb 3, 2017 at 2:11 PM, Claus Ibsen wrote:
>>>> > Hi
>>>> >
>>>> > So are you referring to some configuration for service call / hystrix
>>>> etc?
>>>> >
>>>> > The problem with the registry being hierarchical is that its backed by
>>>> > different implementations and then the user experience is different
>>
Re: Hierarchical registry for CamelContext
Yeah this is for 3.0 :)
Posted so I won't forget
---
Luca Burgazzoli
On Fri, Sep 8, 2017 at 11:02 AM, Claus Ibsen wrote:
> On Fri, Sep 8, 2017 at 10:38 AM, Luca Burgazzoli
> wrote:
>> Hi,
>>
>> I was thinking if instead we could have the camel context have its own
>> registry and end users can add their own "bean repository", like
>>
>> context.addBeanRepository(new SpringBeanRepository())
>> context.addBeanRepository(new JNDIRepositoy())
>>
>> Then when asking the registry to lookup beans, it will go through the
>> repositories according to their order and if it does not find any its
>> internal repositories which can then be used to add internal stuffs
>> like rest/service-call/etc configurations and so on.
>>
>> Would that make sense ?
>>
>
> Maybe can we talk about this later.
> We have a 2.20.0 release to get done first.
>
>
>>
>> ---
>> Luca Burgazzoli
>>
>>
>> On Mon, Feb 6, 2017 at 10:41 AM, Claus Ibsen wrote:
>>> Hi
>>>
>>> Yeah the idea of having it internal and named as containerRegistry, or
>>> maybe better named as contextRegistry or internalRegistry or
>>> camelInternalRegistry to make it stand out its not for Camel end users
>>> per see.
>>>
>>> A side bonus can be that we could make this internal registry
>>> available for unit testing Camel where users sometimes have a little
>>> trouble adding beans to the registry when using spring / cdi / java /
>>> karaf et all. There is a couple of JIRAs about this. Then the APIs on
>>> camel-test could offer a way to register custom beans that take
>>> priority over the regular registry.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Feb 6, 2017 at 10:13 AM, Luca Burgazzoli
>>> wrote:
>>>> Well, what we have as today is just fine but sometime it requires a
>>>> little bit of additional work and maintenance even it is not strictly
>>>> needed.
>>>> Let's take as example hystrix and service call stuffs we added recently:
>>>>
>>>> 1. hystrix configuration is retrieved from the registry but work in
>>>> spring only as blueprint and cdi support is not implemented and would
>>>> require additional work, even the spring support is a little limited.
>>>> 2. service call configurations can be retrieved from the camel context
>>>> (via getter method) or from the registry but configurations you add to
>>>> the camel context element are added to the context, not the registry
>>>> so the behavior is a little different and it pollute the camel context
>>>> with additional methods.
>>>> 3. Add support for service-call to spring & co may require to write a
>>>> custom bean factory
>>>> 4. hystrix and service-call configurations are not supposed to be used
>>>> outside the camel context, so having them available for DI in
>>>> spring/blueprint/cdi does not make much sense
>>>>
>>>> The proposed solution aim to harmonize such things by adding them to a
>>>> camel contex own registry.
>>>> Of course the container specific registry can still be used to
>>>> configure hystrix/service-call and it is used first, something like:
>>>>
>>>> registry.lookupByName(String name, Class type) {
>>>> Object answer = containerRegistry.lookupByName(name);
>>>> if (answer == null) {
>>>> answer = contextRegistry,.lookupByName(name);
>>>> }
>>>>
>>>> return answer;
>>>> }
>>>>
>>>>
>>>>
>>>> ---
>>>> Luca Burgazzoli
>>>>
>>>>
>>>> On Fri, Feb 3, 2017 at 4:27 PM, Paul Gale wrote:
>>>>> Luca,
>>>>>
>>>>> Can you outline either some particular business problem that you're trying
>>>>> to solve or some current impediment to a solution that would be remedied
>>>>> by
>>>>> your proposed design change?
>>>>>
>>>>> Perhaps a few use case scenarios might help demonstrate the need. Just a
>>>>> thought.
>>>>>
>>>>> Thanks,
>>>>> Paul
>>>>>
>>>>> On Fri, Feb 3, 2017 at 8:39 AM, Luca Burgazzoli
>>>>> wrote:
>>>>>
>>>>>> Yes an easy way to register beans that are not really mean
Re: Health Check API
Hello, I've just pushed some bits to my fork to cleanup the implementation and implement some basic checks for routes status. In addition, to make it suitable to be included in camel 2.20, I've reduced the scope of the implementation to be almost limited to core/internal health checks and to provide a good foundation for people to write their own advanced checks if needed (component checks such as those for undertow and servicenow has been removed). Any feedback is really appreciated. --- Luca Burgazzoli On Tue, Sep 5, 2017 at 2:25 PM, Luca Burgazzoli wrote: > --- > Luca Burgazzoli > > > On Tue, Sep 5, 2017 at 2:17 PM, Claus Ibsen wrote: >> Hi Luca >> >> Looks really good. >> >> There is a few typo's and the likes in the source code I looked at. >> Will try to do a github comment so you can see them as well later, or >> when the code is merged later. >> >> 1) >> For the doCall implementation when you implement a health check, then >> what would happen if that methods throws an runtime exception? I think >> we need to clarify on the javadoc what the contract is, and if an >> exception would then render the check to be status = DOWN or what? >> > > I'd expect the implementation to wrap it and decide if the service is > healthy or not so yeah, I'll make it clear. > >> >> 2) >> I think the spring boot auto configuration prefixes for the health >> checks for the components such as undertow, servicenow etc should all >> be under the same prefix as the component itself, eg >> >> eg >> camel.undertow.health.checks[spring-health].interval = 5s >> >> should be >> camel.component.undertow.health.checks[spring-health].interval = 5s >> >> Then everything you can configure in the undertow component is with >> the same prefix and its consistent. >> > > Agree. > >> >> 3) >> To implement a custom health check and have spring boot auto >> configuration, then you would have to write that configuration code >> yourself / manually? >> > > At the moment yes as the layout is not defined but it may be > eventually auto generated like the starters. > >> >> 4) >> I wonder in the servicenow health check where you configure the >> instance id, username etc again, whether you may want to be able to >> just refer to the existing configuration so you do not repeat >> yourself? >> >> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks/application/src/main/resources/application.properties#L66 >> > > Yeah, that was an example non properly cleaned up/explained but by > default the servicenow reuse component's configuration. > >> >> 5) >> In this example it is a bit confusing that the comment say the health >> check is enabled and then the value below is false >> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks/application/src/main/resources/application.properties#L36 >> >> 6) >> ... and as well there is 2 indicator.enabled in that example. > > Yeah, it definitively need to be cleaned up. > >> >> >> >> On Mon, Sep 4, 2017 at 5:16 PM, Claus Ibsen wrote: >>> Hi Luca >>> >>> I will take a closer look tomorrow, I just peaked a bit today. >>> >>> Just to be sure, the implementation of the logic that performs the >>> actual health check is agnostic? i.e. its not tied to must be using >>> Spring Boot. And that logic is if possible reusing the "ping check" >>> (i.e. verifier extension). >>> >>> So the spring boot health check is currently for making it easier for >>> end users to configure it via spring boot configuration? >>> >>> >>> >>> On Mon, Sep 4, 2017 at 4:01 PM, Luca Burgazzoli >>> wrote: >>>> Hello, >>>> >>>> I've been working a little on the Health Check API [1] implementation an >>>> the code is available in my Apache Camel fork [2]. There is now a a new >>>> package [3] that defines the following concepts: >>>> >>>> - HealthCheck >>>> >>>> this represent an health check and defines the some basic contract i.e >>>> the response; >>>> >>>> - HealthCheckConfiguration >>>> >>>> this is a basic coonfiguration object that holds some basic settings >>>> like the minimum delay between calls, the number of time a service may
Re: Health Check API
Hello, I've added some info through JMX, would you mind review it before merging ? Regards, Luca --- Luca Burgazzoli On Fri, Sep 8, 2017 at 4:20 PM, Luca Burgazzoli wrote: > Hello, > > I've just pushed some bits to my fork to cleanup the implementation > and implement some basic checks for routes status. In addition, to > make it suitable to be included in camel 2.20, I've reduced the scope > of the implementation to be almost limited to core/internal health > checks and to provide a good foundation for people to write their own > advanced checks if needed (component checks such as those for undertow > and servicenow has been removed). > > Any feedback is really appreciated. > > > --- > Luca Burgazzoli > > > On Tue, Sep 5, 2017 at 2:25 PM, Luca Burgazzoli wrote: >> --- >> Luca Burgazzoli >> >> >> On Tue, Sep 5, 2017 at 2:17 PM, Claus Ibsen wrote: >>> Hi Luca >>> >>> Looks really good. >>> >>> There is a few typo's and the likes in the source code I looked at. >>> Will try to do a github comment so you can see them as well later, or >>> when the code is merged later. >>> >>> 1) >>> For the doCall implementation when you implement a health check, then >>> what would happen if that methods throws an runtime exception? I think >>> we need to clarify on the javadoc what the contract is, and if an >>> exception would then render the check to be status = DOWN or what? >>> >> >> I'd expect the implementation to wrap it and decide if the service is >> healthy or not so yeah, I'll make it clear. >> >>> >>> 2) >>> I think the spring boot auto configuration prefixes for the health >>> checks for the components such as undertow, servicenow etc should all >>> be under the same prefix as the component itself, eg >>> >>> eg >>> camel.undertow.health.checks[spring-health].interval = 5s >>> >>> should be >>> camel.component.undertow.health.checks[spring-health].interval = 5s >>> >>> Then everything you can configure in the undertow component is with >>> the same prefix and its consistent. >>> >> >> Agree. >> >>> >>> 3) >>> To implement a custom health check and have spring boot auto >>> configuration, then you would have to write that configuration code >>> yourself / manually? >>> >> >> At the moment yes as the layout is not defined but it may be >> eventually auto generated like the starters. >> >>> >>> 4) >>> I wonder in the servicenow health check where you configure the >>> instance id, username etc again, whether you may want to be able to >>> just refer to the existing configuration so you do not repeat >>> yourself? >>> >>> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks/application/src/main/resources/application.properties#L66 >>> >> >> Yeah, that was an example non properly cleaned up/explained but by >> default the servicenow reuse component's configuration. >> >>> >>> 5) >>> In this example it is a bit confusing that the comment say the health >>> check is enabled and then the value below is false >>> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks/application/src/main/resources/application.properties#L36 >>> >>> 6) >>> ... and as well there is 2 indicator.enabled in that example. >> >> Yeah, it definitively need to be cleaned up. >> >>> >>> >>> >>> On Mon, Sep 4, 2017 at 5:16 PM, Claus Ibsen wrote: >>>> Hi Luca >>>> >>>> I will take a closer look tomorrow, I just peaked a bit today. >>>> >>>> Just to be sure, the implementation of the logic that performs the >>>> actual health check is agnostic? i.e. its not tied to must be using >>>> Spring Boot. And that logic is if possible reusing the "ping check" >>>> (i.e. verifier extension). >>>> >>>> So the spring boot health check is currently for making it easier for >>>> end users to configure it via spring boot configuration? >>>> >>>> >>>> >>>> On Mon, Sep 4, 2017 at 4:01 PM, Luca Burgazzoli >>>> wrote: >>>>> Hello, >>>>> >>>>> I've
