camel-infinispan : change the uri syntax from infinispan:hostName to infinispan:cacheName

[Luca Burgazzoli]

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

[Andrea Cosentino]

+1 from my side. It makes sense. --Andrea Cosentino 
--Apache Camel PMC MemberApache Karaf 
CommitterApache Servicemix PMC MemberEmail: ancosen1985@yahoo.comTwitter: 
@oscerd2Github: oscerd 

On Wednesday, April 5, 2017 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


   

Re: camel-infinispan : change the uri syntax from infinispan:hostName to infinispan:cacheName

[Claus Ibsen]

+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

WildFy-Camel-4.6.0 released

[Thomas Diesler]

Dear Folks,

WildFly-Camel 4.6.0 provides Camel-2.18.3 integration with WildFly-10.1.0

This is another upgrade release for supported Camel components, which now 
brings the total up to 112, with 35 components still planned 

 for future releases. All data formats and languages are fully supported. 

We also upgraded cloud integration to OpenShift-3.4 and had strong focus on the 
AIX and Windows platform. This is also the first release with makes every 
component, data format and language available as WildFly-Swarm Fraction 
.   

Additional components in the supported set 
 are:

* camel-amq
* camel-rabitmq
* camel-sjms-batch
* camel-snmp
* camel-splunk
* camel-spring-batch
* camel-spring-integration
* camel-spring-ldap
* camel-spring-redis

Component upgrades include

* Camel-2.18.3
* HawtIO-1.5.0
* OpenShift-3.4

In addition to that, we also resolved a number of other tasks and bugfixes 
.

For details please see the 4.6.0 Milestone 
.

Enjoy

[GitHub] camel pull request #1591: Remove dependency on OpenTracing contrib GlobalTra...

[objectiser]

Github user objectiser closed the pull request at:

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


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

Re: camel-infinispan : change the uri syntax from infinispan:hostName to infinispan:cacheName

[Nicola Ferraro]

+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-infinispan : change the uri syntax from infinispan:hostName to infinispan:cacheName

[Luca Burgazzoli]

+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
>>

[GitHub] camel pull request #1596: CAMEL-11107: Create a new camel-grpc component

[dmvolod]

GitHub user dmvolod opened a pull request:

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

CAMEL-11107: Create a new camel-grpc component

Create a new camel-grpc component which allows to do Remote Procedure Call 
(RPC) Protocol Buffers (protobuf)] format over HTTP/2 transport.
Stage 1 - Producer with basic parameters and calling sync and async methods

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dmvolod/camel CAMEL-11107

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1596.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1596


commit efbd65919ba8a7de8261a869756bed109254db1a
Author: Dmitry Volodin 
Date:   2017-04-05T09:25:13Z

CAMEL-11107: Create a new camel-grpc component

commit cf6173668c4562090f383737aab8127d31eb43ea
Author: Dmitry Volodin 
Date:   2017-04-05T09:38:37Z

CAMEL-11107: Changing camel-grpc documentation




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

[GitHub] camel pull request #1588: CAMEL-11098: lets make FacebookEndpointConfigurati...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] camel pull request #1593: Update camel-context.xml

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] camel pull request #1597: CAMEL-11111: added unit test for throwExceptionOnF...

[scranton]

GitHub user scranton opened a pull request:

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

CAMEL-1: added unit test for throwExceptionOnFailure

Test case for camel-undertow showing issue, and same test case working in 
camel-netty4-http

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/scranton/camel CAMEL-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1597.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1597


commit e493cf03964571497a0a946bad2016ff35f89397
Author: Scott Cranton 
Date:   2017-04-05T11:49:04Z

CAMEL-1: added unit test for throwExceptionOnFailure




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

Re: Camel 2.19 Roadmap

[Claus Ibsen]

Hi Gregor

Yeah its April so we should get the 2.19.0 release out the door.

We have just setup a 2.20.0 version in JIRA and folks should start
moving their tickets to that version if its something that they cannot
finish in time. Also we should refrain from doing bigger work at this
time as we should close down on last tickets, bug fixes, and get the
CI tests in good order, etc.

I will look at the JIRAs later this week and cleanup a bit so we have
a better overview of what work is yet to be done.

As April has the easter holidays. I wonder what you time schedule looks like?

Maybe if you have time to help with the release after the holidays?

Week 16 and 17 are the last 2 weeks in April after the holidays.
If we could maybe cut the RC in week 16 then that would be good.





On Mon, Apr 3, 2017 at 2:14 PM, Gregor Zurowski
 wrote:
> Hi,
>
> Are we getting closer to build a 2.19.0 release?  I would volunteer
> for creating the release, just wanted to check when would be a good
> time to do so.
>
> Thanks,
> Gregor
>
>
> On Wed, Mar 15, 2017 at 9:29 AM, Claus Ibsen  wrote:
>> Hi
>>
>> Just wanted to bring up that we are closing in on a good time for
>> doing a new release.
>>
>> For example in mid April it would be around 6 months since the last
>> 2.18.0 release.
>>
>> Therefore we should start closing down and fixing bugs, and make sure
>> the CI servers and tests are in good shape.
>> This morning we have fixed a number of recent test failures and are
>> down to only 1 test failure now.
>>
>>
>>
>> On Mon, Jan 16, 2017 at 10:28 AM, 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
>>
>>
>>
>> --
>> 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

[GitHub] camel pull request #1598: CAMEL-11113 Camel catalog's asEndpointUri mangles ...

[zregvart]

GitHub user zregvart opened a pull request:

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

CAMEL-3 Camel catalog's asEndpointUri mangles endpoint URIs for unequal 
number of tokens

**Work in progress, please don't merge**

This illustrates a number of issues when constructing the endpoint URI from 
Camel catalog.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zregvart/camel CAMEL-3

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1598.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1598


commit 9780195a4da306373d874552e92f9b0c80e8e3c5
Author: Zoran Regvart 
Date:   2017-04-05T14:01:33Z

CAMEL-3 added unit tests




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

[GitHub] camel pull request #1599: CAMEL-11117: Fix searchTerm error with unseen and ...

[lio-p]

GitHub user lio-p opened a pull request:

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

CAMEL-7: Fix searchTerm error with unseen and subjectOrBody



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/lio-p/camel CAMEL-7-FIX

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1599.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1599






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