[jira] [Comment Edited] (CAMEL-11762) Add Karaf Feature for ASN.1 DataFormat

[JIRA]

[ 
https://issues.apache.org/jira/browse/CAMEL-11762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158942#comment-16158942
 ] 

Önder Sezgin edited comment on CAMEL-11762 at 9/8/17 5:09 PM:
--

I guess i need a bit of help about this issue because my osgi knowledge is 
limited :/ Any help appreciated. I want to learn more about OSGI in Camel. 
Thanks.


was (Author: onders):
I guess i need a bit of help about this issue because my osgi knowledge is 
limited :/ Any help appreciated. I want to learn more about OSGI. Thanks.

> Add Karaf Feature for ASN.1 DataFormat
> --
>
> Key: CAMEL-11762
> URL: https://issues.apache.org/jira/browse/CAMEL-11762
> Project: Camel
>  Issue Type: Sub-task
>Affects Versions: 2.20.0
>Reporter: Önder Sezgin
>Assignee: Önder Sezgin
>Priority: Minor
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11762) Add Karaf Feature for ASN.1 DataFormat

[JIRA]

[ 
https://issues.apache.org/jira/browse/CAMEL-11762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158942#comment-16158942
 ] 

Önder Sezgin commented on CAMEL-11762:
--

I guess i need a bit of help about this issue because my osgi knowledge is 
limited :/ Any help appreciated. I want to learn more about OSGI. Thanks.

> Add Karaf Feature for ASN.1 DataFormat
> --
>
> Key: CAMEL-11762
> URL: https://issues.apache.org/jira/browse/CAMEL-11762
> Project: Camel
>  Issue Type: Sub-task
>Affects Versions: 2.20.0
>Reporter: Önder Sezgin
>Assignee: Önder Sezgin
>Priority: Minor
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11699) HealthCheck : grab service status from external service status repository

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-11699:

Issue Type: Sub-task  (was: New Feature)
Parent: CAMEL-10026

> HealthCheck : grab service status from external service status repository
> -
>
> Key: CAMEL-11699
> URL: https://issues.apache.org/jira/browse/CAMEL-11699
> Project: Camel
>  Issue Type: Sub-task
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>  Labels: health-check
> Fix For: 2.20.0
>
>
> There should be possible to retrieve service status from external source so 
> i.e. the twitter status is checked externally from camel and made available 
> to camel whiteout having every camel instance to check for twitter status.
> i.e. 
> # we can have a ConsulHealthCheckRegistry that grab service status from 
> consul exposing them to camel as standard HealthCheck so the check call will 
> ends up in simply grabbing the status from consul
> # we can have an AggregatingHealthCheckRegistry that aggregates multiple 
> registri in a single view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11717) HealthCheck : create a consul based health check repository

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-11717:

Issue Type: Sub-task  (was: New Feature)
Parent: CAMEL-10026

> HealthCheck : create a consul based health check repository
> ---
>
> Key: CAMEL-11717
> URL: https://issues.apache.org/jira/browse/CAMEL-11717
> Project: Camel
>  Issue Type: Sub-task
>  Components: camel-consul
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
>  Labels: health-check
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11717) HealthCheck : create a consul based health check repository

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-11717:

Issue Type: New Feature  (was: Sub-task)
Parent: (was: CAMEL-11699)

> HealthCheck : create a consul based health check repository
> ---
>
> Key: CAMEL-11717
> URL: https://issues.apache.org/jira/browse/CAMEL-11717
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-consul
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
>  Labels: health-check
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11689) HealthCheck : add health check support for camel-servicenow

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-11689:

Issue Type: Sub-task  (was: New Feature)
Parent: CAMEL-10026

> HealthCheck : add health check support for camel-servicenow
> ---
>
> Key: CAMEL-11689
> URL: https://issues.apache.org/jira/browse/CAMEL-11689
> Project: Camel
>  Issue Type: Sub-task
>  Components: camel-servicenow
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
>  Labels: health-check
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11624) REST DSL/component method Uppercase

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-11624.
-
Resolution: Fixed

> REST DSL/component method Uppercase
> ---
>
> Key: CAMEL-11624
> URL: https://issues.apache.org/jira/browse/CAMEL-11624
> Project: Camel
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.19.1
>Reporter: Paolo Lizarazu
>Assignee: Claus Ibsen
> Fix For: 2.19.4, 2.20.0
>
>
> when we are using rest component we need to set the method in uppercase 
> otherwise this will return error 405
> bad example : String requestResponse = 
> testProducer.requestBody("rest:get:health?host=$activityHost:$activityPort", 
> null, String.class)
> working example
> String requestResponse = 
> testProducer.requestBody("rest:GET:health?host=$activityHost:$activityPort", 
> null, String.class)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11765) camel-undertow - Consumer adds duplicate headers

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-11765.
-
Resolution: Fixed

> camel-undertow - Consumer adds duplicate headers
> 
>
> Key: CAMEL-11765
> URL: https://issues.apache.org/jira/browse/CAMEL-11765
> Project: Camel
>  Issue Type: Bug
>  Components: camel-undertow
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> You get HTTP_METHOD with [GET, GET] or its duplicate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11695) Add security and advanced properties to the camel-grpc component

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158633#comment-16158633
 ] 

ASF GitHub Bot commented on CAMEL-11695:


Github user asfgit closed the pull request at:

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


> Add security and advanced properties to the camel-grpc component
> 
>
> Key: CAMEL-11695
> URL: https://issues.apache.org/jira/browse/CAMEL-11695
> Project: Camel
>  Issue Type: Sub-task
>  Components: camel-grpc
>Reporter: Dmitry Volodin
>Assignee: Dmitry Volodin
>Priority: Minor
> Fix For: 2.20.0
>
>
> Add advanced properties available in gRPC library as well as security (auth, 
> SSL, etc.)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CAMEL-11693) HealthCheck : add health check support for camel-undertow

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli closed CAMEL-11693.
---
Resolution: Won't Do

> HealthCheck : add health check support for camel-undertow
> -
>
> Key: CAMEL-11693
> URL: https://issues.apache.org/jira/browse/CAMEL-11693
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-undertow
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>  Labels: health-check
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11765) camel-undertow - Consumer adds duplicate headers

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11765:

Fix Version/s: 2.19.3
   2.18.5

> camel-undertow - Consumer adds duplicate headers
> 
>
> Key: CAMEL-11765
> URL: https://issues.apache.org/jira/browse/CAMEL-11765
> Project: Camel
>  Issue Type: Bug
>  Components: camel-undertow
>Reporter: Claus Ibsen
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> You get HTTP_METHOD with [GET, GET] or its duplicate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CAMEL-11765) camel-undertow - Consumer adds duplicate headers

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-11765:
---

Assignee: Claus Ibsen

> camel-undertow - Consumer adds duplicate headers
> 
>
> Key: CAMEL-11765
> URL: https://issues.apache.org/jira/browse/CAMEL-11765
> Project: Camel
>  Issue Type: Bug
>  Components: camel-undertow
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> You get HTTP_METHOD with [GET, GET] or its duplicate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11695) Add security and advanced properties to the camel-grpc component

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158612#comment-16158612
 ] 

ASF GitHub Bot commented on CAMEL-11695:


GitHub user dmvolod opened a pull request:

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

CAMEL-11695: fix Karaf feature for test

@oscerd please look at fix.

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

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

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

https://github.com/apache/camel/pull/1925.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 #1925


commit ebf97ee1aeecb7a29090ab03e59a87b643bb9bd5
Author: Dmitry Volodin 
Date:   2017-09-08T13:03:51Z

CAMEL-11695: fix Karaf feature test




> Add security and advanced properties to the camel-grpc component
> 
>
> Key: CAMEL-11695
> URL: https://issues.apache.org/jira/browse/CAMEL-11695
> Project: Camel
>  Issue Type: Sub-task
>  Components: camel-grpc
>Reporter: Dmitry Volodin
>Assignee: Dmitry Volodin
>Priority: Minor
> Fix For: 2.20.0
>
>
> Add advanced properties available in gRPC library as well as security (auth, 
> SSL, etc.)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11249) camel-core - Extend split() capabilities with pluggable splitters

[Nicola Ferraro (JIRA)]

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

Nicola Ferraro updated CAMEL-11249:
---
Fix Version/s: (was: 2.20.0)
   2.21.0

> camel-core - Extend split() capabilities with pluggable splitters
> -
>
> Key: CAMEL-11249
> URL: https://issues.apache.org/jira/browse/CAMEL-11249
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Nicola Ferraro
>Assignee: Nicola Ferraro
> Fix For: 2.21.0
>
>
> Currently a "split().body()" processor will work with a limited set of value 
> types.
> This is an excerpt from ObjectHelper.createIterator(value):
> {code}
>  * Creates an iterator over the value if the value is a collection, an
>  * Object[], a String with values separated by comma,
>  * or a primitive type array; otherwise to simplify the caller's code,
>  * we just create a singleton collection iterator over a single value
>  * 
>  * Will default use comma for String separating String values.
>  * This method does not allow empty values
> {code}
> New libraries (reactive-streams, grpc, but also java 8 collections) make 
> heavy use of streams, not only standard java collections.
> In order to support a wide range of streams types, we can make the split 
> algorithm pluggable, e.g. by providing custom conversions from a specific 
> type to a "CamelStreamingObject" (tbd).
> This way we can convert any kind of streaming object (e.g. Publisher) into 
> its content by putting a ".split().body()". 
> In Camel 2.19.0, users should include a "UnwrapStreamProcessor" in their 
> routes to do this conversion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11249) camel-core - Extend split() capabilities with pluggable splitters

[Nicola Ferraro (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158608#comment-16158608
 ] 

Nicola Ferraro commented on CAMEL-11249:


Yeah, but if we just don't use the SPLIT_COMPLETE header, parent exchanges 
would remain in-flight forever in the metrics. Let's move to 2.21 for now.

> camel-core - Extend split() capabilities with pluggable splitters
> -
>
> Key: CAMEL-11249
> URL: https://issues.apache.org/jira/browse/CAMEL-11249
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Nicola Ferraro
>Assignee: Nicola Ferraro
> Fix For: 2.21.0
>
>
> Currently a "split().body()" processor will work with a limited set of value 
> types.
> This is an excerpt from ObjectHelper.createIterator(value):
> {code}
>  * Creates an iterator over the value if the value is a collection, an
>  * Object[], a String with values separated by comma,
>  * or a primitive type array; otherwise to simplify the caller's code,
>  * we just create a singleton collection iterator over a single value
>  * 
>  * Will default use comma for String separating String values.
>  * This method does not allow empty values
> {code}
> New libraries (reactive-streams, grpc, but also java 8 collections) make 
> heavy use of streams, not only standard java collections.
> In order to support a wide range of streams types, we can make the split 
> algorithm pluggable, e.g. by providing custom conversions from a specific 
> type to a "CamelStreamingObject" (tbd).
> This way we can convert any kind of streaming object (e.g. Publisher) into 
> its content by putting a ".split().body()". 
> In Camel 2.19.0, users should include a "UnwrapStreamProcessor" in their 
> routes to do this conversion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-11765) camel-undertow - Consumer adds duplicate headers

[Claus Ibsen (JIRA)]

Claus Ibsen created CAMEL-11765:
---

 Summary: camel-undertow - Consumer adds duplicate headers
 Key: CAMEL-11765
 URL: https://issues.apache.org/jira/browse/CAMEL-11765
 Project: Camel
  Issue Type: Bug
  Components: camel-undertow
Reporter: Claus Ibsen
 Fix For: 2.20.0


You get HTTP_METHOD with [GET, GET] or its duplicate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11236) camel-grpc - improve streaming capabilities to bridge reactive streams

[Nicola Ferraro (JIRA)]

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

Nicola Ferraro resolved CAMEL-11236.

Resolution: Fixed

> camel-grpc - improve streaming capabilities to bridge reactive streams
> --
>
> Key: CAMEL-11236
> URL: https://issues.apache.org/jira/browse/CAMEL-11236
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-grpc
>Reporter: Nicola Ferraro
>Assignee: Nicola Ferraro
> Fix For: 2.20.0
>
>
> We have grpc producer-only capabilities at the moment. After the 
> implementation of the grpc consumer side, it would be interesting to 
> investigate how we can make it easy to use grpc as transport for reactive 
> streams across network in different JVMs.
> Something like this from the sending side:
> {code}
> from("reactive-streams:datasource")
> to("grpc:my.Data?mehod=stream=xxx=yyy");
> {code}
> And this from the receiving side:
> {code}
> from("grpc:my.Data?mehod=stream=yyy")
> to("reactive-streams:datasink");
> {code}
> Then from a RX implementation one can send a stream of data to *datasource* 
> and receive it using the *datasink* stream in the other JVM.
> We can leverage the streaming capabilities of grpc (payloads and return types 
> can be "streams" of data).
> Grpc has also an internal way to handle backpressure using a bounded internal 
> buffer. We can "bridge" the grpc backpressure mechanism to the 
> reactive-streams one, to have a proper flow control.
> We should give to reactive-streams subscriptions an identifier to distinguish 
> between a new method call or a continuation of the current stream (something 
> like this is reported in CAMEL-11140).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CAMEL-11257) Provide AS2 component to support Business Data Interchange Using HTTP

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-11257:
---

Assignee: William Collins

> Provide AS2 component to support Business Data Interchange Using HTTP
> -
>
> Key: CAMEL-11257
> URL: https://issues.apache.org/jira/browse/CAMEL-11257
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.19.1
>Reporter: William Collins
>Assignee: William Collins
> Fix For: 2.21.0
>
>
> AS2 Camel component should provide MIME-Based Secure Peer-to-Peer Business 
> Data Interchange Using HTTP as per RFC4120



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11257) Provide AS2 component to support Business Data Interchange Using HTTP

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11257:

Fix Version/s: (was: 2.20.0)
   2.21.0

> Provide AS2 component to support Business Data Interchange Using HTTP
> -
>
> Key: CAMEL-11257
> URL: https://issues.apache.org/jira/browse/CAMEL-11257
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.19.1
>Reporter: William Collins
> Fix For: 2.21.0
>
>
> AS2 Camel component should provide MIME-Based Secure Peer-to-Peer Business 
> Data Interchange Using HTTP as per RFC4120



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CAMEL-11624) REST DSL/component method Uppercase

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-11624:
---

Assignee: Claus Ibsen

> REST DSL/component method Uppercase
> ---
>
> Key: CAMEL-11624
> URL: https://issues.apache.org/jira/browse/CAMEL-11624
> Project: Camel
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.19.1
>Reporter: Paolo Lizarazu
>Assignee: Claus Ibsen
> Fix For: 2.19.4, 2.20.0
>
>
> when we are using rest component we need to set the method in uppercase 
> otherwise this will return error 405
> bad example : String requestResponse = 
> testProducer.requestBody("rest:get:health?host=$activityHost:$activityPort", 
> null, String.class)
> working example
> String requestResponse = 
> testProducer.requestBody("rest:GET:health?host=$activityHost:$activityPort", 
> null, String.class)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11257) Provide AS2 component to support Business Data Interchange Using HTTP

[William Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158568#comment-16158568
 ] 

William Collins commented on CAMEL-11257:
-

[~davsclaus] this work has been delayed by other tasks. I am back working on it 
but still some time till I am finished. Best to move this to the next release.

> Provide AS2 component to support Business Data Interchange Using HTTP
> -
>
> Key: CAMEL-11257
> URL: https://issues.apache.org/jira/browse/CAMEL-11257
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.19.1
>Reporter: William Collins
> Fix For: 2.20.0
>
>
> AS2 Camel component should provide MIME-Based Secure Peer-to-Peer Business 
> Data Interchange Using HTTP as per RFC4120



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11482) SSLContextParameters settings are not properly copied to SslContextFactory

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158563#comment-16158563
 ] 

Claus Ibsen commented on CAMEL-11482:
-

Roman, are you working on this?

> SSLContextParameters settings are not properly copied to SslContextFactory
> --
>
> Key: CAMEL-11482
> URL: https://issues.apache.org/jira/browse/CAMEL-11482
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jetty
>Affects Versions: 2.19.0, 2.19.1
> Environment: Max OS X, Java 8 Update 131
> Ubuntu 14.04 LTS, Java 8 Update 111
> Camel 2.19.0
> Jetty9 9.4.5v20170502 and 9.3.14.v20161028
>Reporter: Roman Vottner
> Fix For: 2.19.4, 2.20.0
>
>
> Jetty 9.3+ excludes unsecure ciphers which end on either MD5, SHA or SHA1 by 
> default now. This will however remove all ciphers that are used by either 
> TLSv1 or TLSv1.1 and thus no ciphers remain in order to agree on a cipher for 
> TLSv1 or TLSv1.1 connection attempts. (Further reading: 
> https://github.com/eclipse/jetty.project/issues/860)
> The Jetty 9 SSL configuration documentation 
> (https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html) 
> states that this exclusion cipher suites can be customized by providing an 
> own exclusion list. On specifying SSLContextParameters like below however 
> will not correctly propagate this exclution cipher suites to the 
> SslContextFactory of Jetty and thus use the default setting which prevents 
> TLSv1 and TLSv1.1 connections.
> {code:title=SSLContextParameters Spring Config|borderStyle=solid}
>   @Bean(name = "sslContextParameters")
>   public SSLContextParameters sslContextParameters() {
> String keyStore = env.getProperty("ssl.keyStore.resource");
> URL keyStoreUrl = this.getClass().getResource(keyStore);
> // http://camel.apache.org/jetty.html
> KeyStoreParameters ksp = new KeyStoreParameters();
> ksp.setResource(keyStoreUrl.getPath());
> ksp.setPassword(env.getProperty("ssl.keyStore.password"));
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyStore(ksp);
> kmp.setKeyPassword(env.getProperty("ssl.key.password"));
> SSLContextParameters scp = new SSLContextParameters();
> scp.setKeyManagers(kmp);
> // Jetty 9.3+ support only TLSv1.2 by default hence clients not 
> supporting this protocol will fail
> List supportedSslProtocols = Arrays.asList("TLSv1", "TLSv1.1", 
> "TLSv1.2");
> SecureSocketProtocolsParameters protocolsParameters = new 
> SecureSocketProtocolsParameters();
> protocolsParameters.setSecureSocketProtocol(supportedSslProtocols);
> scp.setSecureSocketProtocols(protocolsParameters);
> // TLS 1.0 / 1.1 have been disabled by jetty 9.3
> // this is a first attempt to re-enable them
> // see
> // - 
> https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html
> // - https://github.com/eclipse/jetty.project/issues/860
> // - http://camel.apache.org/camel-configuration-utilities.html
> FilterParameters cipherParameters = new FilterParameters();
> cipherParameters.getInclude().add(".*");
> cipherParameters.getExclude().add("^.*_(MD5|SHA1)$");
> scp.setCipherSuitesFilter(cipherParameters);
> return scp;
>   }
> {code}
> A workaround is to use a custom JettyHttpComponent9 implementation that sets 
> the excludedCipherSuites manually like depicted below:
> {code:title=Workaround|borderStyle=solid}
>   /**
>* A custom jetty http component which explicitly sets the 
> excludedCipherSuites during creation of
>* the jetty connector.
>*
>* Why? It seems camel does not push included/excluded cipherSuites from 
> {@link
>* SSLContextParameters} to the {@link SslContextFactory} nor does push 
> explicitly listed cipher
>* suites (i.e. like TLS_RSA_WITH_AES_256_CBC_SHA) to the Jetty 
> SSL context factory.
>*/
>   public static class HackedJettyHttpComponent extends JettyHttpComponent9 {
> @Override
> protected AbstractConnector createConnectorJettyInternal(Server server,
>  
> JettyHttpEndpoint endpoint,
>  
> SslContextFactory sslcf) {
>   sslcf.setExcludeCipherSuites("^.*_(MD5|SHA1)$");
>   return super.createConnectorJettyInternal(server, endpoint, sslcf);
> }
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11282) Camel components should extend DefaultComponent

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11282:

Fix Version/s: (was: 2.20.0)
   3.0.0

> Camel components should extend DefaultComponent
> ---
>
> Key: CAMEL-11282
> URL: https://issues.apache.org/jira/browse/CAMEL-11282
> Project: Camel
>  Issue Type: Improvement
>Reporter: Claus Ibsen
> Fix For: 3.0.0
>
>
> We should extend the plain DefaultComponent (the UriEndpointComponent is 
> deprecated) ensure there is a plain default no-arg constructor so it makes 
> using and configuring components easier.
> See eg SO
> http://stackoverflow.com/questions/43918252/how-to-increase-or-configure-maxthreads-in-apache-came-restlet?noredirect=1#comment74982775_43918252
> If it was just a plain no-arg constructor then the bean style would have 
> worked. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11219) Upgrade to RxJava 2.1.x

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-11219.
-
Resolution: Won't Fix

> Upgrade to RxJava 2.1.x
> ---
>
> Key: CAMEL-11219
> URL: https://issues.apache.org/jira/browse/CAMEL-11219
> Project: Camel
>  Issue Type: Task
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11731) Servlet Component isn't really async

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11731:

Fix Version/s: (was: 2.20.0)
   Future

> Servlet Component isn't really async
> 
>
> Key: CAMEL-11731
> URL: https://issues.apache.org/jira/browse/CAMEL-11731
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-servlet
>Affects Versions: 2.18.4, 2.19.2
> Environment: All
>Reporter: Nick Houghton
> Fix For: Future
>
>
> So my assumption reading the servlet component doco is that with 2.18+ and a 
> Servlet 3+ container, the component supports async, which it kind of does 
> with the async=true init config, and there is even a method in CamelServlet 
> called "doServiceAsync" but from what i can tell it doesn't really do it in a 
> asynchronous manner, where there are no blocked threads while a request is 
> awaiting an async operation (like an AHC call for example).
> Looking at:
> https://github.com/apache/camel/blob/master/components/camel-http-common/src/main/java/org/apache/camel/http/common/CamelServlet.java
> While processing a request, we check if we are in async mode and call 
> doServiceAsync..
> {code:java}
>  @Override
> protected final void service(HttpServletRequest req, HttpServletResponse 
> resp) throws ServletException, IOException {
> if (isAsync()) {
> final AsyncContext context = req.startAsync();
> //run async
> context.start(() -> doServiceAsync(context));
> } else {
> doService(req, resp);
> }
> }
> {code}
> then in doServiceAsync() we call doService().. and then we call 
> getProcessor().process(exchange), not process(exchange, asyncCallback) which 
> is the proper async method..
> {code:java}
> try {
> if (log.isTraceEnabled()) {
> log.trace("Processing request for exchangeId: {}", 
> exchange.getExchangeId());
> }
> // process the exchange
> consumer.getProcessor().process(exchange);
> } catch (Exception e) {
> exchange.setException(e);
> }
> {code}
> So the actual behaviour is an inbound request in async mode that ends up just 
> blocking waiting for the request to complete, in a totally sync manner. I 
> presume this is not the desired behaviour?
> It seems the fix would be to move the doService() logic to doServiceAsync() 
> and have doService() call it and use the AsyncProcessorConverterHelper. Or 
> the other alternative would be to update the documentation to explicitly note 
> that it is actually not async at all.
> I can probably PR it in, just wanted to get thoughts on the actual intention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11567) ServiceNow : add suport for Jakarta release

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-11567:

Fix Version/s: (was: 2.20.0)
   2.21.0

> ServiceNow : add suport for Jakarta release
> ---
>
> Key: CAMEL-11567
> URL: https://issues.apache.org/jira/browse/CAMEL-11567
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-servicenow
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
> Fix For: 2.21.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11567) ServiceNow : add suport for Jakarta release

[Luca Burgazzoli (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158495#comment-16158495
 ] 

Luca Burgazzoli commented on CAMEL-11567:
-

it is another release, the component should have support for each release. 
moving to 2.21

> ServiceNow : add suport for Jakarta release
> ---
>
> Key: CAMEL-11567
> URL: https://issues.apache.org/jira/browse/CAMEL-11567
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-servicenow
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
> Fix For: 2.21.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-9008) Contributing GRPC / Thrift support to Camel

[Dmitry Volodin (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158493#comment-16158493
 ] 

Dmitry Volodin commented on CAMEL-9008:
---

Claus, just one feature is missing - security capabilities for Thrift.
I will finish it till end of September.

> Contributing GRPC / Thrift support to Camel
> ---
>
> Key: CAMEL-9008
> URL: https://issues.apache.org/jira/browse/CAMEL-9008
> Project: Camel
>  Issue Type: New Feature
>Reporter: Andrew Harmel-Law
>Assignee: Dmitry Volodin
> Fix For: 2.20.0
>
>
> Hi,
> We're building Microservices with Camel, predominantly producing from REST 
> DSL components and have got to the point where having an easy way to swap in 
> GRPC [1] / Thrift [2] endpoints and clients would be of great help.
> We wondered if this was already on the cards for a future release, and if we 
> might be able to work on it, and if not, if it would be something we could 
> work on and contribute (with guidance to smooth the design and 
> implementation)?
> Kind regards, the Capgemini UK and Indian Camel teams
> [1] http://www.grpc.io/
> [2] https://thrift.apache.org/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (CAMEL-11653) Camel-Nagios: Switch to jsendnsca ported library

[Andrea Cosentino (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158491#comment-16158491
 ] 

Andrea Cosentino edited comment on CAMEL-11653 at 9/8/17 11:27 AM:
---

Yes, it has been released but something is still missing. So for the moment we 
can go the wrapped jar.


was (Author: ancosen):
Yes, it has been released but something is still missing. So for the moment we 
can go the wrapped one.

> Camel-Nagios: Switch to jsendnsca ported library
> 
>
> Key: CAMEL-11653
> URL: https://issues.apache.org/jira/browse/CAMEL-11653
> Project: Camel
>  Issue Type: Task
>  Components: camel-nagios
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.20.0
>
>
> Currently the library is at 2.1.1
> https://github.com/jsendnsca/jsendnsca/
> We'll need a new OSGi bundle too, for the moment we will wrap the jar.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11653) Camel-Nagios: Switch to jsendnsca ported library

[Andrea Cosentino (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158491#comment-16158491
 ] 

Andrea Cosentino commented on CAMEL-11653:
--

Yes, it has been released but something is still missing. So for the moment we 
can go the wrapped one.

> Camel-Nagios: Switch to jsendnsca ported library
> 
>
> Key: CAMEL-11653
> URL: https://issues.apache.org/jira/browse/CAMEL-11653
> Project: Camel
>  Issue Type: Task
>  Components: camel-nagios
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.20.0
>
>
> Currently the library is at 2.1.1
> https://github.com/jsendnsca/jsendnsca/
> We'll need a new OSGi bundle too, for the moment we will wrap the jar.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11762) Add Karaf Feature for ASN.1 DataFormat

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158489#comment-16158489
 ] 

Claus Ibsen commented on CAMEL-11762:
-

Can you install the bundles in OSGi for ASN.1 or do we need to have SMX 
released bundles?

> Add Karaf Feature for ASN.1 DataFormat
> --
>
> Key: CAMEL-11762
> URL: https://issues.apache.org/jira/browse/CAMEL-11762
> Project: Camel
>  Issue Type: Sub-task
>Affects Versions: 2.20.0
>Reporter: Önder Sezgin
>Assignee: Önder Sezgin
>Priority: Minor
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11567) ServiceNow : add suport for Jakarta release

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158486#comment-16158486
 ] 

Claus Ibsen commented on CAMEL-11567:
-

Oh there is another ticket about Istanbul release. Can you clean up those 
tickets so we only have the right one

> ServiceNow : add suport for Jakarta release
> ---
>
> Key: CAMEL-11567
> URL: https://issues.apache.org/jira/browse/CAMEL-11567
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-servicenow
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11553) Upgrade to Brave 4

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-11553.
-
Resolution: Fixed
  Assignee: Andrea Cosentino

We have upgraded to brave 4 in CAMEL-10725
io.zipkin.brave:brave-core:jar:4.5.2:compile

> Upgrade to Brave 4
> --
>
> Key: CAMEL-11553
> URL: https://issues.apache.org/jira/browse/CAMEL-11553
> Project: Camel
>  Issue Type: Task
>  Components: camel-zipkin
>Affects Versions: 2.19.1
>Reporter: Radek Mensik
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.20.0
>
>
> It would be nice to have up to date library not using deprecated code, 
> because:
> Brave v. 4 allows you to use _brave.Tracing_ so one can easily register 
> https://github.com/openzipkin/brave/tree/master/context/slf4j which allows 
> you to have in each log line info about spans:
> {code:java}
> 2017-07-17 17:44:08.526  INFO [proxy,b805c5edbe362a7c,b805c5edbe362a7c,true]
> {code}
> Then it is easy to copy and use span id to zipkin UI in case of debugging. 
> (btw currently there is Long value of span instead of Hexadecimal printed).
> There is possibility to overlap with version 3 and 4 -> 
> https://github.com/openzipkin/brave/tree/master/brave#upgrading-from-brave-3 
> so this could be good start.
> Also _brave.sampler.Sampler_ should be used in stead of 
> _com.github.kristofa.brave.Sampler_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11653) Camel-Nagios: Switch to jsendnsca ported library

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158487#comment-16158487
 ] 

Claus Ibsen commented on CAMEL-11653:
-

Andrea, is an OSGi bundle on the way?

> Camel-Nagios: Switch to jsendnsca ported library
> 
>
> Key: CAMEL-11653
> URL: https://issues.apache.org/jira/browse/CAMEL-11653
> Project: Camel
>  Issue Type: Task
>  Components: camel-nagios
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.20.0
>
>
> Currently the library is at 2.1.1
> https://github.com/jsendnsca/jsendnsca/
> We'll need a new OSGi bundle too, for the moment we will wrap the jar.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11532) java 8 dsl : allow to set the body using a supplier

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11532:

Fix Version/s: (was: 2.20.0)
   2.21.0

> java 8 dsl : allow to set the body using a supplier 
> 
>
> Key: CAMEL-11532
> URL: https://issues.apache.org/jira/browse/CAMEL-11532
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
> Fix For: 2.21.0
>
>
> Example:
> {code:java}
> from("timer")
>   .setBody(User::new);
> from("timer")
>   .trasform()
>   .body(User::new);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11700) HealthCheck : it should be possible to bind a check to a route so its health is determined by the status of the selected checks

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-11700:

Fix Version/s: (was: 2.20.0)
   2.21.0

> HealthCheck : it should be possible to bind a check to a route so its health 
> is determined by the status of the selected checks
> ---
>
> Key: CAMEL-11700
> URL: https://issues.apache.org/jira/browse/CAMEL-11700
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>  Labels: health-check
> Fix For: 2.21.0, Future
>
>
> It would be nice to have a DSl like:
> {code:java}
> from("...")
> .health()
> .check()
> .id("my-check")
> .check()
> .group("my-group")
> .end()
> {code}
> NOTE: a shorter for like check("group", "my-check") should/may also be 
> provided.
> NOTE: it should also be nice to have a way to set critical checks on 
> camel-contex.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11286) Imported Xquery modules will not resolve using classpath - Regression

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11286:

Fix Version/s: (was: 2.20.0)
   Future

> Imported Xquery modules will not resolve using classpath - Regression
> -
>
> Key: CAMEL-11286
> URL: https://issues.apache.org/jira/browse/CAMEL-11286
> Project: Camel
>  Issue Type: Bug
>  Components: camel-saxon
>Affects Versions: 2.15.0, 2.19.0
>Reporter: Jeremy Gosling
>Priority: Minor
> Fix For: Future
>
>
> In Camel 2.15.0 the camel-saxon component was refactored to include an 
> XQueryEndpoint class which now instanciates the XQueryBuilder object in the 
> doStart() method.  It then sets the values of various properties on this 
> object, but misses out the moduleURIResolver.  This is therefore null when 
> the query is evaluated and not used by the 
> net.sf.saxon.query.XQueryExpression to resolve xquery module imports as 
> original described in CAMEL-4285. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-10748) ServiceNow : add support for Instambul release

[Luca Burgazzoli (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158481#comment-16158481
 ] 

Luca Burgazzoli commented on CAMEL-10748:
-

moved to next release

> ServiceNow : add support for Instambul release
> --
>
> Key: CAMEL-10748
> URL: https://issues.apache.org/jira/browse/CAMEL-10748
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-servicenow
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
> Fix For: 2.21.0
>
>
> https://docs.servicenow.com/category/istanbul
> https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/integrate/inbound-rest/concept/c_RESTAPI.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11367) Provide equivalent support for XML REST DSL

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11367:

Fix Version/s: (was: 2.20.0)
   2.21.0

> Provide equivalent support for XML REST DSL
> ---
>
> Key: CAMEL-11367
> URL: https://issues.apache.org/jira/browse/CAMEL-11367
> Project: Camel
>  Issue Type: Sub-task
>  Components: tooling
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
> Fix For: 2.21.0
>
>
> The general purpose {{swagger-rest-dsl-generator}} should be extended to 
> support XML DSL generation, much in the same way the Java DSL is now 
> supported.
> This will enable the graphical tooling to use it as well as the Maven users 
> that prefer XML DSL over Java DSL.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-10748) ServiceNow : add support for Instambul release

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-10748:

Fix Version/s: (was: 2.20.0)
   2.21.0

> ServiceNow : add support for Instambul release
> --
>
> Key: CAMEL-10748
> URL: https://issues.apache.org/jira/browse/CAMEL-10748
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-servicenow
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
> Fix For: 2.21.0
>
>
> https://docs.servicenow.com/category/istanbul
> https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/integrate/inbound-rest/concept/c_RESTAPI.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-9751) Add support for security requirements to swagger java component

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-9751:
---
Fix Version/s: (was: 2.20.0)
   2.21.0

> Add support for security requirements to swagger java component
> ---
>
> Key: CAMEL-9751
> URL: https://issues.apache.org/jira/browse/CAMEL-9751
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-swagger
>Reporter: Tim Dudgeon
>Priority: Minor
> Fix For: 2.21.0
>
>
> Swagger Java component does not currently allow security requirements to be 
> specified. Would be useful to be able to do so.
> But as security is usually applied at the container level its not clear what 
> the best approach would be. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11669) Routes : add 'group'

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-11669:

Fix Version/s: (was: 2.20.0)
   2.21.0

> Routes : add 'group'
> 
>
> Key: CAMEL-11669
> URL: https://issues.apache.org/jira/browse/CAMEL-11669
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.21.0
>
>
> It would be nice to have an option to set mark a route being part of a 
> logical group:
> {code:java}
> from('...')
> .routeGroup('clustered')
> .routeId('route-1')
> .to(...)
> {code}
> This is useful for clustered/supervised routes so one can filter out routes 
> to be managed by a routes controller by group.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-10837) Migrate EIP patterns to adoc

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10837:

Fix Version/s: (was: 2.20.0)
   2.21.0

> Migrate EIP patterns to adoc
> 
>
> Key: CAMEL-10837
> URL: https://issues.apache.org/jira/browse/CAMEL-10837
> Project: Camel
>  Issue Type: Task
>  Components: camel-core
>Reporter: Sébastien COL
>Priority: Minor
>  Labels: documentation
> Fix For: 2.21.0
>
>
> Task 1 of the Camel 2.19 Roadmap:
> 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
> I create this issue so I can submit a PR of my ongoing work. Still working on 
> it but I wanted to check that what I do is what's expected.
> Regards,
> Sebastien



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11651) Component Extension : load extensions from classpath/service-loader

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-11651:

Fix Version/s: (was: 2.20.0)
   2.21.0

> Component Extension : load extensions from classpath/service-loader
> ---
>
> Key: CAMEL-11651
> URL: https://issues.apache.org/jira/browse/CAMEL-11651
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>  Labels: component-extensions
> Fix For: 2.21.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11669) Routes : add 'group'

[Luca Burgazzoli (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158477#comment-16158477
 ] 

Luca Burgazzoli commented on CAMEL-11669:
-

not yet, moving to 2.21


> Routes : add 'group'
> 
>
> Key: CAMEL-11669
> URL: https://issues.apache.org/jira/browse/CAMEL-11669
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.21.0
>
>
> It would be nice to have an option to set mark a route being part of a 
> logical group:
> {code:java}
> from('...')
> .routeGroup('clustered')
> .routeId('route-1')
> .to(...)
> {code}
> This is useful for clustered/supervised routes so one can filter out routes 
> to be managed by a routes controller by group.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-10748) ServiceNow : add support for Instambul release

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158478#comment-16158478
 ] 

Claus Ibsen commented on CAMEL-10748:
-

Luca what is the status of this?

> ServiceNow : add support for Instambul release
> --
>
> Key: CAMEL-10748
> URL: https://issues.apache.org/jira/browse/CAMEL-10748
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-servicenow
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
> Fix For: 2.20.0
>
>
> https://docs.servicenow.com/category/istanbul
> https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/integrate/inbound-rest/concept/c_RESTAPI.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-10324) Create camel-cbor data format

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10324:

Fix Version/s: (was: 2.20.0)
   2.21.0

> Create camel-cbor data format
> -
>
> Key: CAMEL-10324
> URL: https://issues.apache.org/jira/browse/CAMEL-10324
> Project: Camel
>  Issue Type: New Feature
>Reporter: Luca Burgazzoli
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.21.0
>
>
> Data format for CBOR
> See http://cbor.io/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-10474) Aggregator - Allow aggregate/preAggregate to force complete group

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10474:

Fix Version/s: (was: 2.20.0)
   2.21.0

> Aggregator - Allow aggregate/preAggregate to force complete group
> -
>
> Key: CAMEL-10474
> URL: https://issues.apache.org/jira/browse/CAMEL-10474
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 2.21.0
>
>
> We should add support for end users to specify a special header in the 
> returned message that will force the group to be complete, such as
> Exchange.AGGREGATE_FORCE_COMPLETE, true
> This can help the use case as described here
> http://stackoverflow.com/questions/40546189/aggregate-only-consecutive-exchanges-with-same-correlation-key



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-10793) camel cloud: expose routes as a service

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-10793:

Fix Version/s: (was: 2.20.0)

> camel cloud: expose routes as a service
> ---
>
> Key: CAMEL-10793
> URL: https://issues.apache.org/jira/browse/CAMEL-10793
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.21.0
>
>
> 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 It could maje sense to add a way for a route 
> to register itself in such registries and be available as a service for other 
> to consume.
> Something like:
> {code:java}
> // 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")
> {code}
> 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.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11700) HealthCheck : it should be possible to bind a check to a route so its health is determined by the status of the selected checks

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158476#comment-16158476
 ] 

Claus Ibsen commented on CAMEL-11700:
-

Lets move DSL changes like this to the next release

> HealthCheck : it should be possible to bind a check to a route so its health 
> is determined by the status of the selected checks
> ---
>
> Key: CAMEL-11700
> URL: https://issues.apache.org/jira/browse/CAMEL-11700
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>  Labels: health-check
> Fix For: 2.20.0, Future
>
>
> It would be nice to have a DSl like:
> {code:java}
> from("...")
> .health()
> .check()
> .id("my-check")
> .check()
> .group("my-group")
> .end()
> {code}
> NOTE: a shorter for like check("group", "my-check") should/may also be 
> provided.
> NOTE: it should also be nice to have a way to set critical checks on 
> camel-contex.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-10793) camel cloud: expose routes as a service

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli updated CAMEL-10793:

Fix Version/s: 2.21.0

> camel cloud: expose routes as a service
> ---
>
> Key: CAMEL-10793
> URL: https://issues.apache.org/jira/browse/CAMEL-10793
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.21.0
>
>
> 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 It could maje sense to add a way for a route 
> to register itself in such registries and be available as a service for other 
> to consume.
> Something like:
> {code:java}
> // 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")
> {code}
> 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.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11669) Routes : add 'group'

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158475#comment-16158475
 ] 

Claus Ibsen commented on CAMEL-11669:
-

Luca, did you not add group to the DSL ?

> Routes : add 'group'
> 
>
> Key: CAMEL-11669
> URL: https://issues.apache.org/jira/browse/CAMEL-11669
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.20.0
>
>
> It would be nice to have an option to set mark a route being part of a 
> logical group:
> {code:java}
> from('...')
> .routeGroup('clustered')
> .routeId('route-1')
> .to(...)
> {code}
> This is useful for clustered/supervised routes so one can filter out routes 
> to be managed by a routes controller by group.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11651) Component Extension : load extensions from classpath/service-loader

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158474#comment-16158474
 ] 

Claus Ibsen commented on CAMEL-11651:
-

Can this be moved to 2.21

> Component Extension : load extensions from classpath/service-loader
> ---
>
> Key: CAMEL-11651
> URL: https://issues.apache.org/jira/browse/CAMEL-11651
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>  Labels: component-extensions
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11598) camel-spring-boot - actuator endpoints - Make it read-only by default

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11598:

Fix Version/s: (was: 2.20.0)
   2.21.0

> camel-spring-boot - actuator endpoints - Make it read-only by default
> -
>
> Key: CAMEL-11598
> URL: https://issues.apache.org/jira/browse/CAMEL-11598
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-spring-boot
>Reporter: Claus Ibsen
> Fix For: 2.21.0
>
>
> We should make these commands read-only by default, as you can today stop and 
> start routes. This can be a little bit problematic. It may be nice to have 
> read-only actions to get route statistics etc.
> We can then add some option the user must set to allow to control the routes
> Maybe it should be named read-only and be true by default?
> endpoints.camelroutes.read-only = true|false
> Or we can come up with a better name. And allow to specify which actions to 
> turn on
> endpoints.camelroutes.allow=info
> endpoints.camelroutes.allow=info,start,stop
> endpoints.camelroutes.allow=*
> I am not sure what spring-boot may come OOTB in this regard, they may have 
> something also, for user roles to allow invoking certain operations etc.
> But it would be nice with read-only OOTB so you can see the state of all your 
> routes always.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11459) Upgrade CXF to 3.2

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11459:

Fix Version/s: (was: 2.20.0)
   2.21.0

> Upgrade CXF to 3.2
> --
>
> Key: CAMEL-11459
> URL: https://issues.apache.org/jira/browse/CAMEL-11459
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cxf
>Reporter: Guillaume Nodet
> Fix For: 2.21.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11325) Upgrade to Apache Spark 2.x

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11325:

Fix Version/s: (was: 2.20.0)
   2.21.0

> Upgrade to Apache Spark 2.x
> ---
>
> Key: CAMEL-11325
> URL: https://issues.apache.org/jira/browse/CAMEL-11325
> Project: Camel
>  Issue Type: Task
>  Components: camel-spark
>Reporter: Claus Ibsen
> Fix For: 2.21.0
>
>
> We currently are on 1.x, and there is a newer 2.x release out which we should 
> upgrade to.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11257) Provide AS2 component to support Business Data Interchange Using HTTP

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158473#comment-16158473
 ] 

Claus Ibsen commented on CAMEL-11257:
-

Bill, how is it going? We are closing down on a 2.20 release so we may need to 
move this to the next release if its not complete in the near future

> Provide AS2 component to support Business Data Interchange Using HTTP
> -
>
> Key: CAMEL-11257
> URL: https://issues.apache.org/jira/browse/CAMEL-11257
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.19.1
>Reporter: William Collins
> Fix For: 2.20.0
>
>
> AS2 Camel component should provide MIME-Based Secure Peer-to-Peer Business 
> Data Interchange Using HTTP as per RFC4120



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11262) camel-google-pubsub - Improve to work with streaming mode

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11262:

Fix Version/s: (was: 2.20.0)
   2.21.0

> camel-google-pubsub - Improve to work with streaming mode
> -
>
> Key: CAMEL-11262
> URL: https://issues.apache.org/jira/browse/CAMEL-11262
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-google-pubsub
>Affects Versions: 2.19.0
>Reporter: Claus Ibsen
> Fix For: 2.21.0
>
>
> The pubsub component
> https://github.com/apache/camel/tree/master/components/camel-google-pubsub
> Can likely be improved to work better with streaming mode and use Camel 
> asynchronous processing. 
> There may be other things.
> Ray Tsang from Google has some ideas and want to help out.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11249) camel-core - Extend split() capabilities with pluggable splitters

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158471#comment-16158471
 ] 

Claus Ibsen commented on CAMEL-11249:
-

I suggest to move to 2.21

> camel-core - Extend split() capabilities with pluggable splitters
> -
>
> Key: CAMEL-11249
> URL: https://issues.apache.org/jira/browse/CAMEL-11249
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Nicola Ferraro
>Assignee: Nicola Ferraro
> Fix For: 2.20.0
>
>
> Currently a "split().body()" processor will work with a limited set of value 
> types.
> This is an excerpt from ObjectHelper.createIterator(value):
> {code}
>  * Creates an iterator over the value if the value is a collection, an
>  * Object[], a String with values separated by comma,
>  * or a primitive type array; otherwise to simplify the caller's code,
>  * we just create a singleton collection iterator over a single value
>  * 
>  * Will default use comma for String separating String values.
>  * This method does not allow empty values
> {code}
> New libraries (reactive-streams, grpc, but also java 8 collections) make 
> heavy use of streams, not only standard java collections.
> In order to support a wide range of streams types, we can make the split 
> algorithm pluggable, e.g. by providing custom conversions from a specific 
> type to a "CamelStreamingObject" (tbd).
> This way we can convert any kind of streaming object (e.g. Publisher) into 
> its content by putting a ".split().body()". 
> In Camel 2.19.0, users should include a "UnwrapStreamProcessor" in their 
> routes to do this conversion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11236) camel-grpc - improve streaming capabilities to bridge reactive streams

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158469#comment-16158469
 ] 

Claus Ibsen commented on CAMEL-11236:
-

Is there more work needed on this?

> camel-grpc - improve streaming capabilities to bridge reactive streams
> --
>
> Key: CAMEL-11236
> URL: https://issues.apache.org/jira/browse/CAMEL-11236
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-grpc
>Reporter: Nicola Ferraro
>Assignee: Nicola Ferraro
> Fix For: 2.20.0
>
>
> We have grpc producer-only capabilities at the moment. After the 
> implementation of the grpc consumer side, it would be interesting to 
> investigate how we can make it easy to use grpc as transport for reactive 
> streams across network in different JVMs.
> Something like this from the sending side:
> {code}
> from("reactive-streams:datasource")
> to("grpc:my.Data?mehod=stream=xxx=yyy");
> {code}
> And this from the receiving side:
> {code}
> from("grpc:my.Data?mehod=stream=yyy")
> to("reactive-streams:datasink");
> {code}
> Then from a RX implementation one can send a stream of data to *datasource* 
> and receive it using the *datasink* stream in the other JVM.
> We can leverage the streaming capabilities of grpc (payloads and return types 
> can be "streams" of data).
> Grpc has also an internal way to handle backpressure using a bounded internal 
> buffer. We can "bridge" the grpc backpressure mechanism to the 
> reactive-streams one, to have a proper flow control.
> We should give to reactive-streams subscriptions an identifier to distinguish 
> between a new method call or a continuation of the current stream (something 
> like this is reported in CAMEL-11140).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11162) camel-rest - Should we add content-type check for server side

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11162:

Fix Version/s: (was: 2.20.0)
   2.21.0

> camel-rest - Should we add content-type check for server side
> -
>
> Key: CAMEL-11162
> URL: https://issues.apache.org/jira/browse/CAMEL-11162
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
> Fix For: 2.21.0
>
>
> For example setting up a rest-dsl which consumes application/json and then a 
> client calls it with text/plain or application/xml, should we then automatic 
> let rest consumer detect this and return a HTTP status 415 (unsuported media 
> type)
> Not all the HTTP server components does this today, eg jetty etc. But when 
> using restlet which is more natual REST it would do so.
> We could then add an option to turn this on|off. 
> The check is only if the media-type is within the list that may have been 
> specified on consumes in the rest-dsl.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11186) Upgrade dropwizard metrics

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11186:

Fix Version/s: (was: 2.20.0)
   2.21.0

> Upgrade dropwizard metrics
> --
>
> Key: CAMEL-11186
> URL: https://issues.apache.org/jira/browse/CAMEL-11186
> Project: Camel
>  Issue Type: Task
>  Components: camel-metrics
>Reporter: Claus Ibsen
> Fix For: 2.21.0
>
>
> There is a newer 3.2.x release and we are on 3.1.x. But it failed an test in 
> the spring boot integration tests. So we need to find out why.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11231) JSON Api Dataformat

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11231:

Fix Version/s: (was: 2.20.0)
   2.21.0

> JSON Api Dataformat
> ---
>
> Key: CAMEL-11231
> URL: https://issues.apache.org/jira/browse/CAMEL-11231
> Project: Camel
>  Issue Type: New Feature
>Reporter: Charles Moulliard
> Fix For: 2.21.0
>
>
> Implement a new DataFormat to support to serialize/deserialize JSONApi 
> Objects/Strings as defined within the spec : http://jsonapi.org/
> Potential candidate projects to be evaluated :
> - https://github.com/jasminb/jsonapi-converter
> - https://github.com/faogustavo/JSONApi



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-10816) Figure out how to enable the Camel Azure component tests

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10816:

Component/s: tests

> Figure out how to enable the Camel Azure component tests
> 
>
> Key: CAMEL-10816
> URL: https://issues.apache.org/jira/browse/CAMEL-10816
> Project: Camel
>  Issue Type: Task
>  Components: tests
>Reporter: Sergey Beryozkin
> Fix For: Future
>
>
> So far the possible options include:
> - requesting from the Azure team to release the Azure emulator for Linux
>   (and asking them to make sure it can be started not only manually - even if 
> the emulator runs on Windows only to at least consider doing the Windows 
> integration tests)
> - seeking the test account sponsorship options, ex, ask the Azure team to 
> create some test playground for Blob/Queue/etc which can be invoked remotely  
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CAMEL-11005) camel-connector - Generate json using jackson

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-11005:
---

Assignee: (was: Claus Ibsen)

> camel-connector - Generate json using jackson
> -
>
> Key: CAMEL-11005
> URL: https://issues.apache.org/jira/browse/CAMEL-11005
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-connector
>Affects Versions: 2.19.0
>Reporter: Claus Ibsen
> Fix For: 2.21.0, 3.0.0
>
>
> We can generate the output using jackson in pretty print mode which folks 
> tend to like more.
> Just that the embedded json file for the component is using the oneline dense 
> style which the json schema helper parser uses. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-10793) camel cloud: expose routes as a service

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158468#comment-16158468
 ] 

Claus Ibsen commented on CAMEL-10793:
-

I suggest to move this to 2.21

> camel cloud: expose routes as a service
> ---
>
> Key: CAMEL-10793
> URL: https://issues.apache.org/jira/browse/CAMEL-10793
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.20.0
>
>
> 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 It could maje sense to add a way for a route 
> to register itself in such registries and be available as a service for other 
> to consume.
> Something like:
> {code:java}
> // 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")
> {code}
> 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.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-10816) Figure out how to enable the Camel Azure component tests

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10816:

Fix Version/s: (was: 2.20.0)
   Future

> Figure out how to enable the Camel Azure component tests
> 
>
> Key: CAMEL-10816
> URL: https://issues.apache.org/jira/browse/CAMEL-10816
> Project: Camel
>  Issue Type: Task
>  Components: tests
>Reporter: Sergey Beryozkin
> Fix For: Future
>
>
> So far the possible options include:
> - requesting from the Azure team to release the Azure emulator for Linux
>   (and asking them to make sure it can be started not only manually - even if 
> the emulator runs on Windows only to at least consider doing the Windows 
> integration tests)
> - seeking the test account sponsorship options, ex, ask the Azure team to 
> create some test playground for Blob/Queue/etc which can be invoked remotely  
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11005) camel-connector - Generate json using jackson

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11005:

Fix Version/s: (was: 2.20.0)
   3.0.0
   2.21.0

> camel-connector - Generate json using jackson
> -
>
> Key: CAMEL-11005
> URL: https://issues.apache.org/jira/browse/CAMEL-11005
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-connector
>Affects Versions: 2.19.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.21.0, 3.0.0
>
>
> We can generate the output using jackson in pretty print mode which folks 
> tend to like more.
> Just that the embedded json file for the component is using the oneline dense 
> style which the json schema helper parser uses. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-10816) Figure out how to enable the Camel Azure component tests

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10816:

Priority: Minor  (was: Major)

> Figure out how to enable the Camel Azure component tests
> 
>
> Key: CAMEL-10816
> URL: https://issues.apache.org/jira/browse/CAMEL-10816
> Project: Camel
>  Issue Type: Task
>  Components: tests
>Reporter: Sergey Beryozkin
>Priority: Minor
> Fix For: Future
>
>
> So far the possible options include:
> - requesting from the Azure team to release the Azure emulator for Linux
>   (and asking them to make sure it can be started not only manually - even if 
> the emulator runs on Windows only to at least consider doing the Windows 
> integration tests)
> - seeking the test account sponsorship options, ex, ask the Azure team to 
> create some test playground for Blob/Queue/etc which can be invoked remotely  
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-10587) Extending SQS message invisibility timeout not working in some cases

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10587:

Fix Version/s: (was: 2.20.0)
   2.20.1

> Extending SQS message invisibility timeout not working in some cases
> 
>
> Key: CAMEL-10587
> URL: https://issues.apache.org/jira/browse/CAMEL-10587
> Project: Camel
>  Issue Type: Bug
>  Components: camel-aws
>Affects Versions: 2.18.0
>Reporter: Sindre Mehus
> Fix For: 2.20.1
>
>
> org.apache.camel.component.aws.sqs.SqsConsumer creates a TimeoutExtender task 
> for each message received in a batch, but these tasks should be started 
> *before* processing the messages.
> Error can be reproduced as follows:
> 1. Create an SQS-consuming route using maxMessagesPerPoll=10, 
> extendMessageVisibility=true, visibilityTimeout=30, waitTimeSeconds=20.
> 2. Add a process step in the route which just sleeps for a long time.
> 3. Put 20-30 messages on the SQS queue.
> 4. Start the route.
> 5. Let's say the SQS consumer reads off 10 messages.
> 6. Observe in the AWS SQS console that 10 messages are in-flight.
> 7. After 30 seconds you can observe that only 1 message is in-flight. This is 
> incorrect.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11114) Create cache DSL

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino updated CAMEL-4:
-
Fix Version/s: (was: 2.20.0)
   2.21.0

> Create cache DSL
> 
>
> Key: CAMEL-4
> URL: https://issues.apache.org/jira/browse/CAMEL-4
> Project: Camel
>  Issue Type: New Feature
>Reporter: Nicola Ferraro
> Fix For: 2.21.0
>
>
> We should evaluate adding a new "cache" dsl that can be used with all cache 
> components in Camel. A default implementation may use also caffeine, included 
> in camel-core.
> A possible usage example may be:
> {code}
> 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()
> {code}
> It should be also useful to protect internal services when using Camel e.g. 
> as a api-gateway (almost what hystrix does in case of failure of the target 
> host).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-9008) Contributing GRPC / Thrift support to Camel

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158463#comment-16158463
 ] 

Claus Ibsen commented on CAMEL-9008:


Dmitry so it looks like you have most of this implement. Is there more work?

> Contributing GRPC / Thrift support to Camel
> ---
>
> Key: CAMEL-9008
> URL: https://issues.apache.org/jira/browse/CAMEL-9008
> Project: Camel
>  Issue Type: New Feature
>Reporter: Andrew Harmel-Law
>Assignee: Dmitry Volodin
> Fix For: 2.20.0
>
>
> Hi,
> We're building Microservices with Camel, predominantly producing from REST 
> DSL components and have got to the point where having an easy way to swap in 
> GRPC [1] / Thrift [2] endpoints and clients would be of great help.
> We wondered if this was already on the cards for a future release, and if we 
> might be able to work on it, and if not, if it would be something we could 
> work on and contribute (with guidance to smooth the design and 
> implementation)?
> Kind regards, the Capgemini UK and Indian Camel teams
> [1] http://www.grpc.io/
> [2] https://thrift.apache.org/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-10320) Provide a LeaderPolicy to ease the implementation of master/slave route/context

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158465#comment-16158465
 ] 

Claus Ibsen commented on CAMEL-10320:
-

I suggest to move this to 2.21

> Provide a LeaderPolicy to ease the implementation of master/slave 
> route/context
> ---
>
> Key: CAMEL-10320
> URL: https://issues.apache.org/jira/browse/CAMEL-10320
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Dhiraj Bokde
> Fix For: 2.20.0
>
>
> 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
> Then we can also make it exposed in JMX so tooling are able to detect
> which are current master and slaves, and whatnot.
> Some possible DSL/EIP extensions:
> {code:java}
> from("...")
> .routeId("myRoute")
> .master() 
> .group("my-group")
> .consulConfiguration("http://consul-node:8500;)
> .end()
> . to(...)
> {code}
> {code:java}
> camelContext.setDefaultClusteredRouteConfiguration(
> ClusteredRouteConfiguration.builder()
> .withAction(ClusteredRouteAction.SUSPEND)
> .withHealtCheck(...)
> .consulConfiguration("http://consul-node:8500;)
> .build()
> );
>   
> // lookup the cluster configuration from the registry   
> from("clustered:file:/data")
> .routeId("data-files")
> .to(...)
> // lookup the cluster configuration from the registry  
> from("master:file:/share")
> .routeId("shared-files")
> .master()
> .configuration("...")
> .end()
> .to(...)
> {code}
> {code:xml}
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
>
> 
> 
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11114) Create cache DSL

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158460#comment-16158460
 ] 

Claus Ibsen commented on CAMEL-4:
-

I suggest to move this to 2.21 release

> Create cache DSL
> 
>
> Key: CAMEL-4
> URL: https://issues.apache.org/jira/browse/CAMEL-4
> Project: Camel
>  Issue Type: New Feature
>Reporter: Nicola Ferraro
> Fix For: 2.20.0
>
>
> We should evaluate adding a new "cache" dsl that can be used with all cache 
> components in Camel. A default implementation may use also caffeine, included 
> in camel-core.
> A possible usage example may be:
> {code}
> 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()
> {code}
> It should be also useful to protect internal services when using Camel e.g. 
> as a api-gateway (almost what hystrix does in case of failure of the target 
> host).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11249) camel-core - Extend split() capabilities with pluggable splitters

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158385#comment-16158385
 ] 

Claus Ibsen commented on CAMEL-11249:
-

Yeah or maybe its a limitation of using streaming, the the SPLIT_COMPLETE 
header would not be present at all.
For multicast we would know when its complete as its always a fixed set of 
tasks, eg multicast to 2, 3 or 4 endpoints etc.

> camel-core - Extend split() capabilities with pluggable splitters
> -
>
> Key: CAMEL-11249
> URL: https://issues.apache.org/jira/browse/CAMEL-11249
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Nicola Ferraro
>Assignee: Nicola Ferraro
> Fix For: 2.20.0
>
>
> Currently a "split().body()" processor will work with a limited set of value 
> types.
> This is an excerpt from ObjectHelper.createIterator(value):
> {code}
>  * Creates an iterator over the value if the value is a collection, an
>  * Object[], a String with values separated by comma,
>  * or a primitive type array; otherwise to simplify the caller's code,
>  * we just create a singleton collection iterator over a single value
>  * 
>  * Will default use comma for String separating String values.
>  * This method does not allow empty values
> {code}
> New libraries (reactive-streams, grpc, but also java 8 collections) make 
> heavy use of streams, not only standard java collections.
> In order to support a wide range of streams types, we can make the split 
> algorithm pluggable, e.g. by providing custom conversions from a specific 
> type to a "CamelStreamingObject" (tbd).
> This way we can convert any kind of streaming object (e.g. Publisher) into 
> its content by putting a ".split().body()". 
> In Camel 2.19.0, users should include a "UnwrapStreamProcessor" in their 
> routes to do this conversion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-9682) camel-rx module should extend Bean Binding to support methods returning Observable

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-9682:
---
Fix Version/s: (was: 2.20.0)
   Future

> camel-rx module should extend Bean Binding to support methods returning 
> Observable
> -
>
> Key: CAMEL-9682
> URL: https://issues.apache.org/jira/browse/CAMEL-9682
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-rx
>Reporter: james strachan
> Fix For: Future
>
>
> when making asynchronous InOut requests it'd be nice if methods could return 
> Observable so that we could use the RxJava async programming model to 
> process async requests & responses.
> e.g. kinda like how folks can use Retrofit for HTTP: 
> http://joluet.github.io/blog/2014/07/07/rxjava-retrofit/
> {code}
> public interface MyThing {
> @GET("/session.json")
> Observable login();
> @GET("/user.json")
> Observable getUserState();
> }
> {code}
> to then let you use the normal composition / join / flatMap stuff in RxJava 
> to compose multiple requests across different microservice invocations 
> together with timeouts etc e.g. to compose the latest from 2 calls:
> {code}
> Observable.combineLatest(api.fetchUserProfile(), api.getUserState(),
> (user, userStatus) -> new Pair<>(user, userStatus));
> {code}
> Where we'd replace the @GET annotation with a bean binding annotation and a 
> URI parameter to switch to using ActiveMQ or Twitter or whatever



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-6132:
---
Fix Version/s: (was: 2.20.0)
   Future

> camel-test-karaf - To allow end users more easily do Camel and Karaf 
> integration test
> -
>
> Key: CAMEL-6132
> URL: https://issues.apache.org/jira/browse/CAMEL-6132
> Project: Camel
>  Issue Type: New Feature
>  Components: karaf
>Reporter: Claus Ibsen
>Assignee: Quinn Stevenson
> Fix For: Future
>
>
> We should introduce a proper camel-test-karaf component that *end users* can 
> use to do Camel and Karaf integration tests.
> The code we have in tests/camel-itest-karaf is for internal usage and testing 
> of Camel. The code is not polished and intended for end users.
> We should create a new module for that, and take the good parts of 
> camel-itest-karaf and make it user friendly etc. And of course have docs to 
> go with as well.
> And when its good, we can use that in camel-itest-karaf also (eat our own dog 
> food)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-11764) connector maven plugin : generated connectors should have a schema that does not clash wit components

[Luca Burgazzoli (JIRA)]

Luca Burgazzoli created CAMEL-11764:
---

 Summary: connector maven plugin : generated connectors should have 
a schema that does not clash wit components
 Key: CAMEL-11764
 URL: https://issues.apache.org/jira/browse/CAMEL-11764
 Project: Camel
  Issue Type: Improvement
  Components: camel-connector
Reporter: Luca Burgazzoli
 Fix For: 2.20.0


As today we have a twitter-search component and a twitter-search connector 
which may confuse camel when loading components so the connector maven plugin 
should eventually detect such problem i.e. by using the catalog and warn/fail.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11680) Camel-dropbox should support Put not only from localPath

[Kamil (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158345#comment-16158345
 ] 

Kamil commented on CAMEL-11680:
---

ok, I'll test it with and without the body

> Camel-dropbox should support Put not only from localPath
> 
>
> Key: CAMEL-11680
> URL: https://issues.apache.org/jira/browse/CAMEL-11680
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-dropbox
>Reporter: Kamil
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> Currently if I want to Put file on Dropbox using Camel-Dopbox I must create 
> temporary file, write to it using file:// and then use: 
> {code}
> dropbox://put?localPath=${header.myTempFile}
> {code}
> which is tedious.
> Camel-dropbox should support writing directly from Exchange



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (CAMEL-11680) Camel-dropbox should support Put not only from localPath

[Kamil (JIRA)]

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

Kamil updated CAMEL-11680:
--
Comment: was deleted

(was: [~davsclaus], If you want to (and I think you should) support both "old" 
and "new" style, I'm certain that you should retain that two checks which you 
had removed and just change them adding additional check before.
Pseudocode:
{code}
If(body is empty) -> retain all of the checks
if(body has value) -> skip checking file and parameter existence
{code})

> Camel-dropbox should support Put not only from localPath
> 
>
> Key: CAMEL-11680
> URL: https://issues.apache.org/jira/browse/CAMEL-11680
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-dropbox
>Reporter: Kamil
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> Currently if I want to Put file on Dropbox using Camel-Dopbox I must create 
> temporary file, write to it using file:// and then use: 
> {code}
> dropbox://put?localPath=${header.myTempFile}
> {code}
> which is tedious.
> Camel-dropbox should support writing directly from Exchange



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11680) Camel-dropbox should support Put not only from localPath

[Kamil (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158343#comment-16158343
 ] 

Kamil commented on CAMEL-11680:
---

[~davsclaus], If you want to (and I think you should) support both "old" and 
"new" style, I'm certain that you should retain that two checks which you had 
removed and just change them adding additional check before.
Pseudocode:
{code}
If(body is empty) -> retain all of the checks
if(body has value) -> skip checking file and parameter existence
{code}

> Camel-dropbox should support Put not only from localPath
> 
>
> Key: CAMEL-11680
> URL: https://issues.apache.org/jira/browse/CAMEL-11680
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-dropbox
>Reporter: Kamil
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> Currently if I want to Put file on Dropbox using Camel-Dopbox I must create 
> temporary file, write to it using file:// and then use: 
> {code}
> dropbox://put?localPath=${header.myTempFile}
> {code}
> which is tedious.
> Camel-dropbox should support writing directly from Exchange



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11695) Add security and advanced properties to the camel-grpc component

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158339#comment-16158339
 ] 

ASF GitHub Bot commented on CAMEL-11695:


Github user dmvolod closed the pull request at:

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


> Add security and advanced properties to the camel-grpc component
> 
>
> Key: CAMEL-11695
> URL: https://issues.apache.org/jira/browse/CAMEL-11695
> Project: Camel
>  Issue Type: Sub-task
>  Components: camel-grpc
>Reporter: Dmitry Volodin
>Assignee: Dmitry Volodin
>Priority: Minor
> Fix For: 2.20.0
>
>
> Add advanced properties available in gRPC library as well as security (auth, 
> SSL, etc.)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11734) Upgrade grpc-java to 1.6.1

[Dmitry Volodin (JIRA)]

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

Dmitry Volodin resolved CAMEL-11734.

   Resolution: Fixed
Fix Version/s: 2.20.0

Fixed in CAMEL-11695

> Upgrade grpc-java to 1.6.1
> --
>
> Key: CAMEL-11734
> URL: https://issues.apache.org/jira/browse/CAMEL-11734
> Project: Camel
>  Issue Type: Task
>  Components: camel-grpc
>Affects Versions: 2.20.0
>Reporter: James Netherton
>Assignee: Dmitry Volodin
>Priority: Minor
> Fix For: 2.20.0
>
>
> It'd be nice if we could upgrade camel-grpc to use the latest grpc-java 
> library as there are some improvements to how it does class loading:
> https://github.com/grpc/grpc-java/releases/tag/v1.6.1



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11695) Add security and advanced properties to the camel-grpc component

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino resolved CAMEL-11695.
--
Resolution: Fixed

> Add security and advanced properties to the camel-grpc component
> 
>
> Key: CAMEL-11695
> URL: https://issues.apache.org/jira/browse/CAMEL-11695
> Project: Camel
>  Issue Type: Sub-task
>  Components: camel-grpc
>Reporter: Dmitry Volodin
>Assignee: Dmitry Volodin
>Priority: Minor
> Fix For: 2.20.0
>
>
> Add advanced properties available in gRPC library as well as security (auth, 
> SSL, etc.)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158311#comment-16158311
 ] 

ASF GitHub Bot commented on CAMEL-11750:


Github user leofromgroza closed the pull request at:

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


> Camel route with multicast (parallel) generate huge CPU load
> 
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Nazar Vishka
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> I've created simple [Spring Camel Route 
> application|https://github.com/leofromgroza/camel-long-term-route] that can 
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes: 
> 'long-task' and 'very-long-task'. They are just doing something for some 
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start 
> to make a huge CPU load. Here you can see a CPU usage during executiong of 
> Camel route that was mentioned earlier (after finishing of 'long-task' usage 
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical 
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it 
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the 
> system was generated by the thread MulticastProcessor-AggregateTask that was 
> spending a lot of time in the method 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
>  that was called from java.util.concurrent.DelayQueue#poll(long, 
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29 
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable 
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.Thread.isInterrupted(Native Method)
>   at java.lang.Thread.interrupted(Thread.java:944)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
>   at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
>   at 
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
>   at 
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
>   at 
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745){code}
> In DelayQueue#poll(long, java.util.concurrent.TimeUnit) we have a piece of 
> code:
> {code}E first = q.peek();
> if (first == null) {
>  ...
> } else {
>   long delay = first.getDelay(NANOSECONDS);
> ...
>   long timeLeft =  available.awaitNanos(delay) {code}
> During debugging I found that E first is object of class 
> [org.apache.camel.util.concurrent.SubmitOrderedCompletionService.SubmitOrderFutureTask|https://github.com/apache/camel/blob/camel-2.19.2/camel-core/src/main/java/org/apache/camel/util/concurrent/SubmitOrderedCompletionService.java]
>  and it's very interesting [getDelay(TimeUnit) 

[jira] [Updated] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11750:

Fix Version/s: 2.20.0
   2.19.3
   2.18.5

> Camel route with multicast (parallel) generate huge CPU load
> 
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Nazar Vishka
>Priority: Critical
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> I've created simple [Spring Camel Route 
> application|https://github.com/leofromgroza/camel-long-term-route] that can 
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes: 
> 'long-task' and 'very-long-task'. They are just doing something for some 
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start 
> to make a huge CPU load. Here you can see a CPU usage during executiong of 
> Camel route that was mentioned earlier (after finishing of 'long-task' usage 
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical 
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it 
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the 
> system was generated by the thread MulticastProcessor-AggregateTask that was 
> spending a lot of time in the method 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
>  that was called from java.util.concurrent.DelayQueue#poll(long, 
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29 
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable 
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.Thread.isInterrupted(Native Method)
>   at java.lang.Thread.interrupted(Thread.java:944)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
>   at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
>   at 
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
>   at 
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
>   at 
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745){code}
> In DelayQueue#poll(long, java.util.concurrent.TimeUnit) we have a piece of 
> code:
> {code}E first = q.peek();
> if (first == null) {
>  ...
> } else {
>   long delay = first.getDelay(NANOSECONDS);
> ...
>   long timeLeft =  available.awaitNanos(delay) {code}
> During debugging I found that E first is object of class 
> [org.apache.camel.util.concurrent.SubmitOrderedCompletionService.SubmitOrderFutureTask|https://github.com/apache/camel/blob/camel-2.19.2/camel-core/src/main/java/org/apache/camel/util/concurrent/SubmitOrderedCompletionService.java]
>  and it's very interesting [getDelay(TimeUnit) 
> 

[jira] [Assigned] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-11750:
---

Assignee: Claus Ibsen

> Camel route with multicast (parallel) generate huge CPU load
> 
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Nazar Vishka
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> I've created simple [Spring Camel Route 
> application|https://github.com/leofromgroza/camel-long-term-route] that can 
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes: 
> 'long-task' and 'very-long-task'. They are just doing something for some 
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start 
> to make a huge CPU load. Here you can see a CPU usage during executiong of 
> Camel route that was mentioned earlier (after finishing of 'long-task' usage 
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical 
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it 
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the 
> system was generated by the thread MulticastProcessor-AggregateTask that was 
> spending a lot of time in the method 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
>  that was called from java.util.concurrent.DelayQueue#poll(long, 
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29 
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable 
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.Thread.isInterrupted(Native Method)
>   at java.lang.Thread.interrupted(Thread.java:944)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
>   at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
>   at 
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
>   at 
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
>   at 
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745){code}
> In DelayQueue#poll(long, java.util.concurrent.TimeUnit) we have a piece of 
> code:
> {code}E first = q.peek();
> if (first == null) {
>  ...
> } else {
>   long delay = first.getDelay(NANOSECONDS);
> ...
>   long timeLeft =  available.awaitNanos(delay) {code}
> During debugging I found that E first is object of class 
> [org.apache.camel.util.concurrent.SubmitOrderedCompletionService.SubmitOrderFutureTask|https://github.com/apache/camel/blob/camel-2.19.2/camel-core/src/main/java/org/apache/camel/util/concurrent/SubmitOrderedCompletionService.java]
>  and it's very interesting [getDelay(TimeUnit) 
> 

[jira] [Commented] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158310#comment-16158310
 ] 

Claus Ibsen commented on CAMEL-11750:
-

Thanks for the PR. I ammended and pushed to master branch. Do you mind giving 
that a test on your system?

I set the minimal delay to 1 micro-second. That is very low, but some may think 
that even 1 milli second is too high. But lets see if 1 micro-second is too 
fast and also takes up too much CPU. I am open to changing it to 1 milli-second 
or do 100 micro-seconds (1/10th of micro second).

> Camel route with multicast (parallel) generate huge CPU load
> 
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Nazar Vishka
>Priority: Critical
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> I've created simple [Spring Camel Route 
> application|https://github.com/leofromgroza/camel-long-term-route] that can 
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes: 
> 'long-task' and 'very-long-task'. They are just doing something for some 
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start 
> to make a huge CPU load. Here you can see a CPU usage during executiong of 
> Camel route that was mentioned earlier (after finishing of 'long-task' usage 
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical 
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it 
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the 
> system was generated by the thread MulticastProcessor-AggregateTask that was 
> spending a lot of time in the method 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
>  that was called from java.util.concurrent.DelayQueue#poll(long, 
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29 
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable 
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.Thread.isInterrupted(Native Method)
>   at java.lang.Thread.interrupted(Thread.java:944)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
>   at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
>   at 
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
>   at 
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
>   at 
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745){code}
> In DelayQueue#poll(long, java.util.concurrent.TimeUnit) we have a piece of 
> code:
> {code}E first = q.peek();
> if (first == null) {
>  ...
> } else {
>   long delay = first.getDelay(NANOSECONDS);
> ...
>   long timeLeft =  available.awaitNanos(delay) {code}
> During debugging I found that E first is object of class 
> 

[jira] [Commented] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158292#comment-16158292
 ] 

Claus Ibsen commented on CAMEL-11750:
-

Thanks for reporting and diving int the JDK code and showing CPU graphs. Yeah 
it does smell like the JDK with the no-delay would keep looping in that logic

> Camel route with multicast (parallel) generate huge CPU load
> 
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Nazar Vishka
>Priority: Critical
>
> I've created simple [Spring Camel Route 
> application|https://github.com/leofromgroza/camel-long-term-route] that can 
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes: 
> 'long-task' and 'very-long-task'. They are just doing something for some 
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start 
> to make a huge CPU load. Here you can see a CPU usage during executiong of 
> Camel route that was mentioned earlier (after finishing of 'long-task' usage 
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical 
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it 
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the 
> system was generated by the thread MulticastProcessor-AggregateTask that was 
> spending a lot of time in the method 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
>  that was called from java.util.concurrent.DelayQueue#poll(long, 
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29 
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable 
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.Thread.isInterrupted(Native Method)
>   at java.lang.Thread.interrupted(Thread.java:944)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
>   at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
>   at 
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
>   at 
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
>   at 
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745){code}
> In DelayQueue#poll(long, java.util.concurrent.TimeUnit) we have a piece of 
> code:
> {code}E first = q.peek();
> if (first == null) {
>  ...
> } else {
>   long delay = first.getDelay(NANOSECONDS);
> ...
>   long timeLeft =  available.awaitNanos(delay) {code}
> During debugging I found that E first is object of class 
> [org.apache.camel.util.concurrent.SubmitOrderedCompletionService.SubmitOrderFutureTask|https://github.com/apache/camel/blob/camel-2.19.2/camel-core/src/main/java/org/apache/camel/util/concurrent/SubmitOrderedCompletionService.java]
>  and it's very interesting [getDelay(TimeUnit) 
> 

[jira] [Commented] (CAMEL-11761) Camel-Caffeine: Add support for StatsCounter in the component

[Andrea Cosentino (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158260#comment-16158260
 ] 

Andrea Cosentino commented on CAMEL-11761:
--

Yes, forgot this one too.. Gr..

> Camel-Caffeine: Add support for StatsCounter in the component
> -
>
> Key: CAMEL-11761
> URL: https://issues.apache.org/jira/browse/CAMEL-11761
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-caffeine
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11763) Some camel-milo unit tests pass even when exceptions are thrown

[James Netherton (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158261#comment-16158261
 ] 

James Netherton commented on CAMEL-11763:
-

Actually, none of the tests in {{ServerLocalTest}} seem to verify that the Milo 
server consumer actually works. The route under test is:

{code}
from("milo-server:myitem1").to("mock:test")
{code}

But no messages ever seem to arrive at the mock endpoint.

> Some camel-milo unit tests pass even when exceptions are thrown 
> 
>
> Key: CAMEL-11763
> URL: https://issues.apache.org/jira/browse/CAMEL-11763
> Project: Camel
>  Issue Type: Test
>  Components: camel-milo
>Affects Versions: 2.20.0
>Reporter: James Netherton
>Priority: Minor
>
> I've been running the Milo 
> [ServerLocalTest|https://github.com/apache/camel/blob/master/components/camel-milo/src/test/java/org/apache/camel/component/milo/server/ServerLocalTest.java].
>  There's a few tests that use the 'Variant' type as the message body. 
> Although the tests seem to pass, they shouldn't be because an exception is 
> thrown in the background:
> {code}
> java.lang.IllegalArgumentException: Variant cannot contain Variant
>   at 
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
>   at 
> org.eclipse.milo.opcua.stack.core.types.builtin.Variant.(Variant.java:49)
>   at 
> org.apache.camel.component.milo.server.internal.CamelServerItem.update(CamelServerItem.java:140)
>   at 
> org.apache.camel.component.milo.server.MiloServerProducer.process(MiloServerProducer.java:36)
>   at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>   at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
>   at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
>   at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
>   at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
>   at 
> org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
>   at 
> org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
>   at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
>   at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
>   at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:130)
>   at 
> org.apache.camel.test.junit4.CamelTestSupport.sendBody(CamelTestSupport.java:792)
>   at 
> org.apache.camel.component.milo.server.ServerLocalTest.testAcceptVariantString(ServerLocalTest.java:67)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> {code}
> If you tweak the tests to verify that a message was received by the mock 
> endpoint, then it'll fail because of this.
> I'm no Milo expert, so my knowledge here is limited.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11761) Camel-Caffeine: Add support for StatsCounter in the component

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino resolved CAMEL-11761.
--
Resolution: Fixed

> Camel-Caffeine: Add support for StatsCounter in the component
> -
>
> Key: CAMEL-11761
> URL: https://issues.apache.org/jira/browse/CAMEL-11761
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-caffeine
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11761) Camel-Caffeine: Add support for StatsCounter in the component

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158259#comment-16158259
 ] 

Claus Ibsen commented on CAMEL-11761:
-

Has this not been fixed?

> Camel-Caffeine: Add support for StatsCounter in the component
> -
>
> Key: CAMEL-11761
> URL: https://issues.apache.org/jira/browse/CAMEL-11761
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-caffeine
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11758) camel-itest-karaf - CamelBeanValidatorTest fails on Jenkins

[Tadayoshi Sato (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158240#comment-16158240
 ] 

Tadayoshi Sato commented on CAMEL-11758:


Ah that completely makes sense. Then let's wait for the Camel trunk notest 
being built successfully.

> camel-itest-karaf - CamelBeanValidatorTest fails on Jenkins
> ---
>
> Key: CAMEL-11758
> URL: https://issues.apache.org/jira/browse/CAMEL-11758
> Project: Camel
>  Issue Type: Test
>  Components: karaf, tests
>Affects Versions: 2.20.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>
> https://builds.apache.org/job/Camel.trunk.itest.karaf/
> {code}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 12.155 sec 
> <<< FAILURE! - in org.apache.camel.itest.karaf.CamelBeanValidatorTest
> test(org.apache.camel.itest.karaf.CamelBeanValidatorTest)  Time elapsed: 
> 12.011 sec  <<< ERROR!
> org.ops4j.pax.exam.WrappedTestContainerException: 
> [test(org.apache.camel.itest.karaf.CamelBeanValidatorTest): Unable to resolve 
> root: missing requirement [root] osgi.identity; 
> osgi.identity=camel-bean-validator; type=karaf.feature; 
> version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]"; 
> filter:="(&(osgi.identity=camel-bean-validator)(type=karaf.feature)(version>=2.20.0.SNAPSHOT)(version<=2.20.0.SNAPSHOT))"
>  [caused by: Unable to resolve camel-bean-validator/2.20.0.SNAPSHOT: missing 
> requirement [camel-bean-validator/2.20.0.SNAPSHOT] osgi.identity; 
> osgi.identity=org.apache.camel.camel-bean-validator; type=osgi.bundle; 
> version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]"; resolution:=mandatory [caused 
> by: Unable to resolve org.apache.camel.camel-bean-validator/2.20.0.SNAPSHOT: 
> missing requirement [org.apache.camel.camel-bean-validator/2.20.0.SNAPSHOT] 
> osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=javax.validation)(version>=1.1.0)(!(version>=2.0.0)))"]]]
>   at 
> org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)
>   at 
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:389)
>   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)
>   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:347)
>   at 
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:218)
>   at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:285)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1170)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1069)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> Results :
> Tests in error: 
>   CamelBeanValidatorTest.test » WrappedTestContainer 
> [test(org.apache.camel.ites...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 18.116 s
> [INFO] Finished at: 2017-09-06T18:49:24+00:00
> [INFO] Final Memory: 39M/829M
> [INFO] 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-11763) Some camel-milo unit tests pass even when exceptions are thrown

[James Netherton (JIRA)]

James Netherton created CAMEL-11763:
---

 Summary: Some camel-milo unit tests pass even when exceptions are 
thrown 
 Key: CAMEL-11763
 URL: https://issues.apache.org/jira/browse/CAMEL-11763
 Project: Camel
  Issue Type: Test
  Components: camel-milo
Affects Versions: 2.20.0
Reporter: James Netherton
Priority: Minor


I've been running the Milo 
[ServerLocalTest|https://github.com/apache/camel/blob/master/components/camel-milo/src/test/java/org/apache/camel/component/milo/server/ServerLocalTest.java].
 There's a few tests that use the 'Variant' type as the message body. Although 
the tests seem to pass, they shouldn't be because an exception is thrown in the 
background:

{code}
java.lang.IllegalArgumentException: Variant cannot contain Variant
at 
com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
at 
org.eclipse.milo.opcua.stack.core.types.builtin.Variant.(Variant.java:49)
at 
org.apache.camel.component.milo.server.internal.CamelServerItem.update(CamelServerItem.java:140)
at 
org.apache.camel.component.milo.server.MiloServerProducer.process(MiloServerProducer.java:36)
at 
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
at 
org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
at 
org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
at 
org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
at 
org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
at 
org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
at 
org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
at 
org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
at 
org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:130)
at 
org.apache.camel.test.junit4.CamelTestSupport.sendBody(CamelTestSupport.java:792)
at 
org.apache.camel.component.milo.server.ServerLocalTest.testAcceptVariantString(ServerLocalTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
{code}

If you tweak the tests to verify that a message was received by the mock 
endpoint, then it'll fail because of this.

I'm no Milo expert, so my knowledge here is limited.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11758) camel-itest-karaf - CamelBeanValidatorTest fails on Jenkins

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158215#comment-16158215
 ] 

Claus Ibsen commented on CAMEL-11758:
-

It requires a new successful build of notest
https://builds.apache.org/view/A-D/view/Camel/job/Camel.trunk.notest/

which is the build that generates new JARs of the SNAPSHOT and pushes those to 
the SNAPSHOT maven repo which the karaf uses for testing.
We fixed something about validator apis recently. That is why you can also not 
reproduce this locally

> camel-itest-karaf - CamelBeanValidatorTest fails on Jenkins
> ---
>
> Key: CAMEL-11758
> URL: https://issues.apache.org/jira/browse/CAMEL-11758
> Project: Camel
>  Issue Type: Test
>  Components: karaf, tests
>Affects Versions: 2.20.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>
> https://builds.apache.org/job/Camel.trunk.itest.karaf/
> {code}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 12.155 sec 
> <<< FAILURE! - in org.apache.camel.itest.karaf.CamelBeanValidatorTest
> test(org.apache.camel.itest.karaf.CamelBeanValidatorTest)  Time elapsed: 
> 12.011 sec  <<< ERROR!
> org.ops4j.pax.exam.WrappedTestContainerException: 
> [test(org.apache.camel.itest.karaf.CamelBeanValidatorTest): Unable to resolve 
> root: missing requirement [root] osgi.identity; 
> osgi.identity=camel-bean-validator; type=karaf.feature; 
> version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]"; 
> filter:="(&(osgi.identity=camel-bean-validator)(type=karaf.feature)(version>=2.20.0.SNAPSHOT)(version<=2.20.0.SNAPSHOT))"
>  [caused by: Unable to resolve camel-bean-validator/2.20.0.SNAPSHOT: missing 
> requirement [camel-bean-validator/2.20.0.SNAPSHOT] osgi.identity; 
> osgi.identity=org.apache.camel.camel-bean-validator; type=osgi.bundle; 
> version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]"; resolution:=mandatory [caused 
> by: Unable to resolve org.apache.camel.camel-bean-validator/2.20.0.SNAPSHOT: 
> missing requirement [org.apache.camel.camel-bean-validator/2.20.0.SNAPSHOT] 
> osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=javax.validation)(version>=1.1.0)(!(version>=2.0.0)))"]]]
>   at 
> org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)
>   at 
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:389)
>   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)
>   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:347)
>   at 
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:218)
>   at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:285)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1170)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1069)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> Results :
> Tests in error: 
>   CamelBeanValidatorTest.test » WrappedTestContainer 
> [test(org.apache.camel.ites...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 18.116 s
> [INFO] Finished at: 2017-09-06T18:49:24+00:00
> [INFO] Final Memory: 39M/829M
> [INFO] 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11680) Camel-dropbox should support Put not only from localPath

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158205#comment-16158205
 ] 

Claus Ibsen commented on CAMEL-11680:
-

Thanks I pushed another fix, can you give that a test.

> Camel-dropbox should support Put not only from localPath
> 
>
> Key: CAMEL-11680
> URL: https://issues.apache.org/jira/browse/CAMEL-11680
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-dropbox
>Reporter: Kamil
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> Currently if I want to Put file on Dropbox using Camel-Dopbox I must create 
> temporary file, write to it using file:// and then use: 
> {code}
> dropbox://put?localPath=${header.myTempFile}
> {code}
> which is tedious.
> Camel-dropbox should support writing directly from Exchange



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)