[jira] [Assigned] (CAMEL-10521) Camel-Rabbitmq: Support RabbitMQ AMQP client 4.x

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino reassigned CAMEL-10521:


Assignee: Andrea Cosentino

> Camel-Rabbitmq: Support RabbitMQ AMQP client 4.x
> 
>
> Key: CAMEL-10521
> URL: https://issues.apache.org/jira/browse/CAMEL-10521
> Project: Camel
>  Issue Type: Task
>  Components: camel-rabbitmq
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.19.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10521) Camel-Rabbitmq: Support RabbitMQ AMQP client 4.x

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino updated CAMEL-10521:
-
Fix Version/s: 2.19.0

> Camel-Rabbitmq: Support RabbitMQ AMQP client 4.x
> 
>
> Key: CAMEL-10521
> URL: https://issues.apache.org/jira/browse/CAMEL-10521
> Project: Camel
>  Issue Type: Task
>  Components: camel-rabbitmq
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.19.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10504) Hiding an underlying exception if MongoDbBasicConverters fails to convert to DBObject

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino commented on CAMEL-10504:
--

Commit:

https://github.com/apache/camel/commit/600abd802047f35cdca4b95c0f1aaf511f56da82

https://github.com/apache/camel/commit/99f70acc726db3836dfcc8b03fb8f4e3d30aca86

> Hiding an underlying exception if MongoDbBasicConverters fails to convert to 
> DBObject
> -
>
> Key: CAMEL-10504
> URL: https://issues.apache.org/jira/browse/CAMEL-10504
> Project: Camel
>  Issue Type: Bug
>  Components: camel-mongodb
>Affects Versions: 2.17.3, 2.18.0
>Reporter: Evgenii Lomonosov
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.18.1, 2.19.0
>
>
> If conversion fails it could be hard to understand what is a problem because 
> it returns just a message "Conversion has fallen back to generic Object -> 
> DBObject, but unable to convert type {}. Returning null" that points to a 
> class that was not converted.
> In case of, as example, if a list of objects that should be converted leads 
> to a memory error because of parent-child link are cycled for 2 objects, it 
> would take a lot of efforts to understand what is going on. And information 
> about underlying exception, stackoverflow in this case, could help to find 
> the root cause much faster than now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CAMEL-10504) Hiding an underlying exception if MongoDbBasicConverters fails to convert to DBObject

[Andrea Cosentino (JIRA)]

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

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

> Hiding an underlying exception if MongoDbBasicConverters fails to convert to 
> DBObject
> -
>
> Key: CAMEL-10504
> URL: https://issues.apache.org/jira/browse/CAMEL-10504
> Project: Camel
>  Issue Type: Bug
>  Components: camel-mongodb
>Affects Versions: 2.17.3, 2.18.0
>Reporter: Evgenii Lomonosov
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.18.1, 2.19.0
>
>
> If conversion fails it could be hard to understand what is a problem because 
> it returns just a message "Conversion has fallen back to generic Object -> 
> DBObject, but unable to convert type {}. Returning null" that points to a 
> class that was not converted.
> In case of, as example, if a list of objects that should be converted leads 
> to a memory error because of parent-child link are cycled for 2 objects, it 
> would take a lot of efforts to understand what is going on. And information 
> about underlying exception, stackoverflow in this case, could help to find 
> the root cause much faster than now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10504) Hiding an underlying exception if MongoDbBasicConverters fails to convert to DBObject

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino updated CAMEL-10504:
-
Fix Version/s: 2.19.0
   2.18.1

> Hiding an underlying exception if MongoDbBasicConverters fails to convert to 
> DBObject
> -
>
> Key: CAMEL-10504
> URL: https://issues.apache.org/jira/browse/CAMEL-10504
> Project: Camel
>  Issue Type: Bug
>  Components: camel-mongodb
>Affects Versions: 2.17.3, 2.18.0
>Reporter: Evgenii Lomonosov
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.18.1, 2.19.0
>
>
> If conversion fails it could be hard to understand what is a problem because 
> it returns just a message "Conversion has fallen back to generic Object -> 
> DBObject, but unable to convert type {}. Returning null" that points to a 
> class that was not converted.
> In case of, as example, if a list of objects that should be converted leads 
> to a memory error because of parent-child link are cycled for 2 objects, it 
> would take a lot of efforts to understand what is going on. And information 
> about underlying exception, stackoverflow in this case, could help to find 
> the root cause much faster than now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CAMEL-10514) Camel-Kubernetes: Copy headers from in to out in producer operations

[Andrea Cosentino (JIRA)]

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

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

> Camel-Kubernetes: Copy headers from in to out in producer operations
> 
>
> Key: CAMEL-10514
> URL: https://issues.apache.org/jira/browse/CAMEL-10514
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kubernetes
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.19.0
>
>
> Like Camel-Git, Camel-Kubernetes was developed with the idea of single 
> operation. Maybe it would be good to copy the headers from in to out for 
> operations chains on the Cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10447) Add contract based type awareness

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10447:


Github user igarashitm closed the pull request at:

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


> Add contract based type awareness
> -
>
> Key: CAMEL-10447
> URL: https://issues.apache.org/jira/browse/CAMEL-10447
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core
>Reporter: Tomohisa Igarashi
>Assignee: Tomohisa Igarashi
>
> Original proposal is available here:
> https://github.com/kcbabo/sandbox/blob/master/camel-metadata.md
> We'd like to propose adding contract based type awareness on the Camel 
> Message Exchange. It introduces following benefits to Camel users:
> * Static evaluation and validation of data types and interactions in an 
> application.
> * Runtime evaluation of data types and interactions
> * The ability to start with a weak/dynamically typed application and move to 
> a statically typed application
> * Support for declarative transformation / automatic type conversion
> * Support for declarative validation of data types
> Let's see the declarative transformation example:
> {code:java}
> from("direct:abc")
> .inputType("java:org.example.Order")
> .to("direct:d")
> .inputType("xml:{org.example}xmlOrder")
> .outputType("urn:acme:orderAck")
> .to("direct:e")
> {code}
> Instead of specifying transform().marshal() programmatically in the route, 
> above declares data type contract of the endpoints. This example means that 
> the input message should be transformed from *java:org.example.Order* to 
> *xml:\{org.example\}xmlOrder* before it is sent to *direct:d* from 
> *direct:abc*.
> Once we add this feature, we can even validate if required transformer is 
> declared along the data type by some maven plugin or IDE at design time.
> The most important thing is that this feature is *completely optional*, so it 
> doesn't make any effect on existing Camel applications at all unless type 
> declaration is explicitly added.
> We've been discussing about this here in camel-dev:
> http://camel.465427.n5.nabble.com/Adding-type-awareness-in-Camel-route-td5787621.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10272) Aggregation is broken due to race condition in ParallelAggregateTask.doAggregateInternal()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10272:


Github user aldettinger closed the pull request at:

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


> Aggregation is broken due to race condition in 
> ParallelAggregateTask.doAggregateInternal()
> --
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>
> Unfortunately, I am not able to provide a (simple) unit test for 
> comprehending the problem. Furthermore our (complex) unit tests are not 
> deterministic due to the root cause of the problem.
> However I tried to analyze the Camel Java code, to work out the problem. 
> Please find below my findings.
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a 
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
>  from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange 
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which 
> contradicts the contract with Camel.
> h3. Analysis
> During the processing, Camel invokes {{MulticastProcessor.process()}}. Here 
> the result object {{AtomicExchange}} is created which is shared during the 
> whole processing.
> If the processing should be done in parallel (as it is the case for our 
> route) then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one 
> instance of {{AggregateOnTheFlyTask}} is initialized and 
> {{aggregateOnTheFly()}} is invoked -*asynchronously* via {{run()}}  for 
> *every* target in the recipient list-. via 
> {{aggregateExecutorService.submit}} ({{aggregationTaskSubmitted}} guarantees 
> that this is only be done once)
> In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is 
> generated, and if aggregation is not done in parallel (as it is the case in 
> our route), {{ParallelAggregateTask.run()}}, 
> {{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and 
> {{ParallelAggregateTask.doAggregateInternal()}} is invoked synchronously:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy, 
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> } 
> {code}
> However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a 
> race condition as {{result}} is shared -by every instance of 
> {{AggregateOnTheFlyTask}}- such that {{oldExchange = result.get()}} may be 
> {{null}} more than once!
> Note: As a new instance of {{ParallelAggregateTask}} for every target in 
> recipient list is created, the {{synchronized}} method 
> {{ParallelAggregateTask.doAggregate()}} does not prevent the race condition!
> Does this sounds reasonably?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10175) camel-jetty - Continuation timeout should send back HTTP timeout status code

[Nikhil Vibhav (JIRA)]

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

Nikhil Vibhav commented on CAMEL-10175:
---

[~cib...@e-ma.net] Hey, I would like to pick up this issue if no one working on 
this at the moment.


> camel-jetty - Continuation timeout should send back HTTP timeout status code
> 
>
> Key: CAMEL-10175
> URL: https://issues.apache.org/jira/browse/CAMEL-10175
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jetty
>Reporter: Claus Ibsen
>Priority: Minor
>
> See the proposed solution at SO
> http://stackoverflow.com/questions/36656391/camel-exchange-expired-via-jetty-continuation/36660661?noredirect=1#comment64460262_36660661
> We can bake that out of the box into the default binding.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10272) Aggregation is broken due to race condition in ParallelAggregateTask.doAggregateInternal()

[Alex Dettinger (JIRA)]

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

Alex Dettinger commented on CAMEL-10272:


I don't think that we are facing such a simple race condition here. In the 
method _doAggregateInternal(...)_, _result.get(...)_ and _result.set(...)_ are 
not run concurrently.
A single thread is used at aggregation time, in the provided example at least.

However, _oldExchange_ could be null more than once when the user custom 
aggregation strategy throws a runtime exception:
{code}
public static class Router {
public String[] routeTo() {
return new String[] {"log:MSGROUTER_0?level=TRACE", 
"log:MSGROUTER_1?level=TRACE"};
}
}

@Override
protected RouteBuilder createRouteBuilder() {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
from("direct:start").
recipientList().
method(new Router()).
aggregationStrategy(new AggregationStrategy(){
public Exchange aggregate(Exchange oldExchange, Exchange 
newExchange) {
if (oldExchange == null) {
System.out.println("oldExchange is null 
"+newExchange.getExchangeId()+" thread: "+Thread.currentThread());
}
System.out.println(3/0); // throws 
java.lang.ArithmeticException
return null;
}
}).
parallelProcessing().
end();
}
};
}
{code}
outputs:
{noformat}
oldExchange is null ID-alex-42036-1479994398470-0-3 thread: Thread[Camel 
(camel-1) thread #2 - RecipientList-AggregateTask,5,main]
oldExchange is null ID-alex-42036-1479994398470-0-4 thread: Thread[Camel 
(camel-1) thread #2 - RecipientList-AggregateTask,5,main]
{noformat}
That said, I see the following drawbacks with the current implementation:
* The AggregationStrategy class javadoc lists a single case where oldExchange 
could be null whereas two exists
* This case could be difficult to debug from a camel user perspective. Camel 
kind of hides the runtime exception in the custom aggregation strategy.

>From there, I see 2 paths to handle a runtime exception unwind from a custom 
>aggregation strategy:
* Produce an ERROR log. We then need to correct the javadoc accordingly.
* Unwind the exception to the default error handler. Note that this is what 
happen when parallelProcessing is false.

Any thoughts on the right path then ?

> Aggregation is broken due to race condition in 
> ParallelAggregateTask.doAggregateInternal()
> --
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>
> Unfortunately, I am not able to provide a (simple) unit test for 
> comprehending the problem. Furthermore our (complex) unit tests are not 
> deterministic due to the root cause of the problem.
> However I tried to analyze the Camel Java code, to work out the problem. 
> Please find below my findings.
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a 
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
>  from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange 
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which 
> contradicts the contract with Camel.
> h3. Analysis
> During the processing, Camel invokes {{MulticastProcessor.process()}}. Here 
> the result object {{AtomicExchange}} is created which is shared during the 
> whole processing.
> If the processing should be done in parallel (as it is the case for our 
> route) then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one 
> instance of {{AggregateOnTheFlyTask}} is initialized and 
> {{aggregateOnTheFly()}} is invoked -*asynchronously* via {{run()}}  for 
> *every* target in the recipient list-. via 
> 

[jira] [Commented] (CAMEL-10272) Aggregation is broken due to race condition in ParallelAggregateTask.doAggregateInternal()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10272:


GitHub user aldettinger opened a pull request:

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

CAMEL 10272: Fixed few comments

Note that this PR does not fix 
[CAMEL-10272](https://issues.apache.org/jira/browse/CAMEL-10272). I'll post on 
the issue tracker directly to details my findings.

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

$ git pull https://github.com/aldettinger/camel master

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

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


commit 42efb4ef220beb26e8a49c7e729c81d3e0054a63
Author: aldettinger 
Date:   2016-11-24T18:00:02Z

CAMEL 10272: Fixed few comments




> Aggregation is broken due to race condition in 
> ParallelAggregateTask.doAggregateInternal()
> --
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>
> Unfortunately, I am not able to provide a (simple) unit test for 
> comprehending the problem. Furthermore our (complex) unit tests are not 
> deterministic due to the root cause of the problem.
> However I tried to analyze the Camel Java code, to work out the problem. 
> Please find below my findings.
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a 
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
>  from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange 
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which 
> contradicts the contract with Camel.
> h3. Analysis
> During the processing, Camel invokes {{MulticastProcessor.process()}}. Here 
> the result object {{AtomicExchange}} is created which is shared during the 
> whole processing.
> If the processing should be done in parallel (as it is the case for our 
> route) then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one 
> instance of {{AggregateOnTheFlyTask}} is initialized and 
> {{aggregateOnTheFly()}} is invoked -*asynchronously* via {{run()}}  for 
> *every* target in the recipient list-. via 
> {{aggregateExecutorService.submit}} ({{aggregationTaskSubmitted}} guarantees 
> that this is only be done once)
> In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is 
> generated, and if aggregation is not done in parallel (as it is the case in 
> our route), {{ParallelAggregateTask.run()}}, 
> {{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and 
> {{ParallelAggregateTask.doAggregateInternal()}} is invoked synchronously:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy, 
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> } 
> {code}
> However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a 
> race condition as {{result}} is shared -by every instance of 
> {{AggregateOnTheFlyTask}}- such that {{oldExchange = result.get()}} may be 
> {{null}} more than once!
> Note: As a new instance of {{ParallelAggregateTask}} for every target in 
> recipient list is created, the {{synchronized}} method 
> {{ParallelAggregateTask.doAggregate()}} does not prevent the race condition!
> Does this sounds reasonably?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10504) Hiding an underlying exception if MongoDbBasicConverters fails to convert to DBObject

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10504:
-

I think this PR is about this
https://github.com/apache/camel/pull/1309

> Hiding an underlying exception if MongoDbBasicConverters fails to convert to 
> DBObject
> -
>
> Key: CAMEL-10504
> URL: https://issues.apache.org/jira/browse/CAMEL-10504
> Project: Camel
>  Issue Type: Bug
>  Components: camel-mongodb
>Affects Versions: 2.17.3, 2.18.0
>Reporter: Evgenii Lomonosov
>Assignee: Andrea Cosentino
>Priority: Minor
>
> If conversion fails it could be hard to understand what is a problem because 
> it returns just a message "Conversion has fallen back to generic Object -> 
> DBObject, but unable to convert type {}. Returning null" that points to a 
> class that was not converted.
> In case of, as example, if a list of objects that should be converted leads 
> to a memory error because of parent-child link are cycled for 2 objects, it 
> would take a lot of efforts to understand what is going on. And information 
> about underlying exception, stackoverflow in this case, could help to find 
> the root cause much faster than now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CAMEL-10498) Update Salesforce component to support approval REST API

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-10498.
-
Resolution: Fixed
  Assignee: Zoran Regvart

> Update Salesforce component to support approval REST API
> 
>
> Key: CAMEL-10498
> URL: https://issues.apache.org/jira/browse/CAMEL-10498
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-salesforce
>Affects Versions: 2.18.0
> Environment: Any
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
> Fix For: 2.19.0
>
>
> Part of CAMEL-8396 to add support for the 
> [Approvals|https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_process_approvals.htm].
> Implement support for getting and sending approvals for
> processing via Salesforce REST API.
> Add two new operations: _approvals_ to fetch any approvals already
> in progress, and _approval_ to initiate approval process on the supplied
> record or records (batch).
> To fetch the records in approval process:
> {code:java}
> ...to("salesforce:approvals")
> .split().body()
> .log("${body.entityId} - ${body.instanceStatus}")
> {code}
> And to send a record for approval:
> {code:java}
> ...to("salesforce:approval?approval.actionType=Submit&...")
> .log("${body.id} - ${body.instanceStatus}")
> {code}
> The _approval_ operation should have the ability to set properties on the
> endpoint (let's call that template), via message headers and message
> body. These can be combined, to place default values on the endpoint
> (template), and runtime values trough headers or message body.
> If the message body is an _Iterable_ then
> they should be submitted in a batch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10516) Clean code: remove the 308 import not used

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10516:


Github user apupier closed the pull request at:

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


> Clean code: remove the 308 import not used
> --
>
> Key: CAMEL-10516
> URL: https://issues.apache.org/jira/browse/CAMEL-10516
> Project: Camel
>  Issue Type: Task
>Affects Versions: 2.18.0
>Reporter: Aurelien Pupier
> Fix For: 2.19.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10519) Disable TLSv1.0 in camel-salesforce

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10519:


Github user asfgit closed the pull request at:

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


> Disable TLSv1.0 in camel-salesforce
> ---
>
> Key: CAMEL-10519
> URL: https://issues.apache.org/jira/browse/CAMEL-10519
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>
> Salesforce is [disabling 
> TLSv1.0|https://help.salesforce.com/HTViewSolution?id=000221207] connections 
> for production organizations on March 4, 2017.
> As a proactive measure for clients not running Java 8 (or newer) we should 
> change the defaults to disable TLSv.1.0 if the runtime supports TLSv1.1 or 
> newer or issue a warning if clients can use only TLSv1.0 (Java 6 before 
> update 111).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10516) Clean code: remove the 308 import not used

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10516:


GitHub user apupier opened a pull request:

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

CAMEL-10516 - Remove unused import

second round, don't know why they didn't appear in problems view the first 
time and so I miss them

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

$ git pull https://github.com/apupier/camel CAMEL-10516-removeUnusedImport-2

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

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


commit d6ab168e5b3580e30acf0ffe92cefafa70e3e196
Author: Aurelien Pupier 
Date:   2016-11-24T13:21:09Z

CAMEL-10516 - Remove unused import




> Clean code: remove the 308 import not used
> --
>
> Key: CAMEL-10516
> URL: https://issues.apache.org/jira/browse/CAMEL-10516
> Project: Camel
>  Issue Type: Task
>Affects Versions: 2.18.0
>Reporter: Aurelien Pupier
> Fix For: 2.19.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10519) Disable TLSv1.0 in camel-salesforce

[Zoran Regvart (JIRA)]

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

Zoran Regvart commented on CAMEL-10519:
---

Adding link to 
[discussion|http://camel.465427.n5.nabble.com/Salesforce-and-TLS-v1-0-tt5790484.html]
 on the mailing list.

> Disable TLSv1.0 in camel-salesforce
> ---
>
> Key: CAMEL-10519
> URL: https://issues.apache.org/jira/browse/CAMEL-10519
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>
> Salesforce is [disabling 
> TLSv1.0|https://help.salesforce.com/HTViewSolution?id=000221207] connections 
> for production organizations on March 4, 2017.
> As a proactive measure for clients not running Java 8 (or newer) we should 
> change the defaults to disable TLSv.1.0 if the runtime supports TLSv1.1 or 
> newer or issue a warning if clients can use only TLSv1.0 (Java 6 before 
> update 111).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10519) Disable TLSv1.0 in camel-salesforce

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10519:


GitHub user zregvart opened a pull request:

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

CAMEL-10519 Disable TLSv1.0 in camel-salesforce

This commit adds a warning message if the used JSSE implementation does
not support TLS version 1.1 or newer. TLS version 1.0 is disabled by
default and additionaly all SSL versions are disabled -- which is done
by default in BaseSSLContextParameters, so its added here so that the
new default configuration does not override and allow SSL versions.

The main purpose of this commit is to allow users that are using Java 7
without support for TLS version 1.1 or newer, i.e. not using Oracle or
IBM Java or using custom SSL configuration with custom JSSE provider
that is configured or does not support TLS version 1.1 or newer --
to get an early warning (before March, 2017 when Salesforce disables TLS
version 1.0). And to set default enabled SSL protocols to TLS version
1.1 and onward.

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

$ git pull https://github.com/zregvart/camel CAMEL-10519-camel-2.17.x

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

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


commit 887627bd8fcf20c7b2575176c6257233fb0d21a8
Author: Zoran Regvart 
Date:   2016-11-24T11:12:21Z

CAMEL-10519 Disable TLSv1.0 in camel-salesforce

This commit adds a warning message if the used JSSE implementation does
not support TLS version 1.1 or newer. TLS version 1.0 is disabled by
default and additionaly all SSL versions are disabled -- which is done
by default in BaseSSLContextParameters, so its added here so that the
new default configuration does not override and allow SSL versions.

The main purpose of this commit is to allow users that are using Java 7
without support for TLS version 1.1 or newer, i.e. not using Oracle or
IBM Java or using custom SSL configuration with custom JSSE provider
that is configured or does not support TLS version 1.1 or newer --
to get an early warning (before March, 2017 when Salesforce disables TLS
version 1.0). And to set default enabled SSL protocols to TLS version
1.1 and onward.




> Disable TLSv1.0 in camel-salesforce
> ---
>
> Key: CAMEL-10519
> URL: https://issues.apache.org/jira/browse/CAMEL-10519
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>
> Salesforce is [disabling 
> TLSv1.0|https://help.salesforce.com/HTViewSolution?id=000221207] connections 
> for production organizations on March 4, 2017.
> As a proactive measure for clients not running Java 8 (or newer) we should 
> change the defaults to disable TLSv.1.0 if the runtime supports TLSv1.1 or 
> newer or issue a warning if clients can use only TLSv1.0 (Java 6 before 
> update 111).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10447) Add contract based type awareness

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10447:


GitHub user igarashitm opened a pull request:

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

CAMEL-10447 Split ContractAdvice#doTransform() into smaller methods



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

$ git pull https://github.com/igarashitm/camel 
CAMEL-10447-split-transformer-method

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

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


commit 108993099375c4baae3287820dfe87681aceee1c
Author: Tomohisa Igarashi 
Date:   2016-11-24T09:47:00Z

CAMEL-10447 Split ContractAdvice#doTransform() into smaller methods




> Add contract based type awareness
> -
>
> Key: CAMEL-10447
> URL: https://issues.apache.org/jira/browse/CAMEL-10447
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core
>Reporter: Tomohisa Igarashi
>Assignee: Tomohisa Igarashi
>
> Original proposal is available here:
> https://github.com/kcbabo/sandbox/blob/master/camel-metadata.md
> We'd like to propose adding contract based type awareness on the Camel 
> Message Exchange. It introduces following benefits to Camel users:
> * Static evaluation and validation of data types and interactions in an 
> application.
> * Runtime evaluation of data types and interactions
> * The ability to start with a weak/dynamically typed application and move to 
> a statically typed application
> * Support for declarative transformation / automatic type conversion
> * Support for declarative validation of data types
> Let's see the declarative transformation example:
> {code:java}
> from("direct:abc")
> .inputType("java:org.example.Order")
> .to("direct:d")
> .inputType("xml:{org.example}xmlOrder")
> .outputType("urn:acme:orderAck")
> .to("direct:e")
> {code}
> Instead of specifying transform().marshal() programmatically in the route, 
> above declares data type contract of the endpoints. This example means that 
> the input message should be transformed from *java:org.example.Order* to 
> *xml:\{org.example\}xmlOrder* before it is sent to *direct:d* from 
> *direct:abc*.
> Once we add this feature, we can even validate if required transformer is 
> declared along the data type by some maven plugin or IDE at design time.
> The most important thing is that this feature is *completely optional*, so it 
> doesn't make any effect on existing Camel applications at all unless type 
> declaration is explicitly added.
> We've been discussing about this here in camel-dev:
> http://camel.465427.n5.nabble.com/Adding-type-awareness-in-Camel-route-td5787621.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10498) Update Salesforce component to support approval REST API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10498:


Github user zregvart closed the pull request at:

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


> Update Salesforce component to support approval REST API
> 
>
> Key: CAMEL-10498
> URL: https://issues.apache.org/jira/browse/CAMEL-10498
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-salesforce
>Affects Versions: 2.18.0
> Environment: Any
>Reporter: Zoran Regvart
> Fix For: 2.19.0
>
>
> Part of CAMEL-8396 to add support for the 
> [Approvals|https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_process_approvals.htm].
> Implement support for getting and sending approvals for
> processing via Salesforce REST API.
> Add two new operations: _approvals_ to fetch any approvals already
> in progress, and _approval_ to initiate approval process on the supplied
> record or records (batch).
> To fetch the records in approval process:
> {code:java}
> ...to("salesforce:approvals")
> .split().body()
> .log("${body.entityId} - ${body.instanceStatus}")
> {code}
> And to send a record for approval:
> {code:java}
> ...to("salesforce:approval?approval.actionType=Submit&...")
> .log("${body.id} - ${body.instanceStatus}")
> {code}
> The _approval_ operation should have the ability to set properties on the
> endpoint (let's call that template), via message headers and message
> body. These can be combined, to place default values on the endpoint
> (template), and runtime values trough headers or message body.
> If the message body is an _Iterable_ then
> they should be submitted in a batch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10447) Add contract based type awareness

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10447:


Github user igarashitm closed the pull request at:

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


> Add contract based type awareness
> -
>
> Key: CAMEL-10447
> URL: https://issues.apache.org/jira/browse/CAMEL-10447
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core
>Reporter: Tomohisa Igarashi
>Assignee: Tomohisa Igarashi
>
> Original proposal is available here:
> https://github.com/kcbabo/sandbox/blob/master/camel-metadata.md
> We'd like to propose adding contract based type awareness on the Camel 
> Message Exchange. It introduces following benefits to Camel users:
> * Static evaluation and validation of data types and interactions in an 
> application.
> * Runtime evaluation of data types and interactions
> * The ability to start with a weak/dynamically typed application and move to 
> a statically typed application
> * Support for declarative transformation / automatic type conversion
> * Support for declarative validation of data types
> Let's see the declarative transformation example:
> {code:java}
> from("direct:abc")
> .inputType("java:org.example.Order")
> .to("direct:d")
> .inputType("xml:{org.example}xmlOrder")
> .outputType("urn:acme:orderAck")
> .to("direct:e")
> {code}
> Instead of specifying transform().marshal() programmatically in the route, 
> above declares data type contract of the endpoints. This example means that 
> the input message should be transformed from *java:org.example.Order* to 
> *xml:\{org.example\}xmlOrder* before it is sent to *direct:d* from 
> *direct:abc*.
> Once we add this feature, we can even validate if required transformer is 
> declared along the data type by some maven plugin or IDE at design time.
> The most important thing is that this feature is *completely optional*, so it 
> doesn't make any effect on existing Camel applications at all unless type 
> declaration is explicitly added.
> We've been discussing about this here in camel-dev:
> http://camel.465427.n5.nabble.com/Adding-type-awareness-in-Camel-route-td5787621.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10519) Disable TLSv1.0 in camel-salesforce

[Zoran Regvart (JIRA)]

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

Zoran Regvart commented on CAMEL-10519:
---

[~davsclaus] thank you for that comment, I'm aware of that, could we do a point 
release of 2.17 so that any users still not on Java 8 can upgrade to that?

> Disable TLSv1.0 in camel-salesforce
> ---
>
> Key: CAMEL-10519
> URL: https://issues.apache.org/jira/browse/CAMEL-10519
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>
> Salesforce is [disabling 
> TLSv1.0|https://help.salesforce.com/HTViewSolution?id=000221207] connections 
> for production organizations on March 4, 2017.
> As a proactive measure for clients not running Java 8 (or newer) we should 
> change the defaults to disable TLSv.1.0 if the runtime supports TLSv1.1 or 
> newer or issue a warning if clients can use only TLSv1.0 (Java 6 before 
> update 111).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-10521) Camel-Rabbitmq: Support RabbitMQ AMQP client 4.x

[Andrea Cosentino (JIRA)]

Andrea Cosentino created CAMEL-10521:


 Summary: Camel-Rabbitmq: Support RabbitMQ AMQP client 4.x
 Key: CAMEL-10521
 URL: https://issues.apache.org/jira/browse/CAMEL-10521
 Project: Camel
  Issue Type: Task
  Components: camel-rabbitmq
Reporter: Andrea Cosentino
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)