[jira] [Updated] (CAMEL-9555) Setting deadLetterHandleNewException to false breaks DeadLetterChannel default exception handling

[Laurent Chiarello (JIRA)]

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

Laurent Chiarello updated CAMEL-9555:
-
Attachment: (was: DeadLetterChannelTest.java)

> Setting deadLetterHandleNewException to false breaks DeadLetterChannel 
> default exception handling
> -
>
> Key: CAMEL-9555
> URL: https://issues.apache.org/jira/browse/CAMEL-9555
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Laurent Chiarello
>Assignee: Claus Ibsen
> Fix For: 2.15.6, 2.16.3, 2.17.0
>
>
> By default, the {{DeadLetterChannel}} handles every exception, including any 
> exception thrown by the dead letter itself. This can be changed by setting 
> the option {{deadLetterHandleNewException}} to _false_. Unfortunately, 
> setting it to _false_ also disable the handling in case of a normal 
> exception, which is not at all what the name suggests. 
> To make the point clear, here is the little scenario I am trying to set up, 
> and why this option is really important in that case.
> h3. Scenario
> I have a camel route consuming persistent messages from a JMS (activemq) 
> endpoint. I have set {{CLIENT_ACKNOWLEDGE}} on the component to prevent 
> consuming the messages until they have been successfully processed.
> So I want to configure my error handler as a {{DeadLetterChannel}} with the 
> following behavior:
> # in case of an exception during processing, send the message to a DLQ
> # if the DLQ itself fails (preventing the message to be safely stored), do 
> not handle it and let the exception being propagated back to the JMS 
> consumer, such that ActiveMQ won't remove it from its queue.
> From my understanding, this is what the option 
> {{deadLetterHandleNewException=false}} should provide. But when testing it, 
> setting it to _false_ actually breaks the default handling of the dead letter 
> channel as well, and no exception at all are handled, even when successfully 
> sent to the DLQ...
> I checked {{DeadLetterHandleNewExceptionTest}} from the camel test cases, but 
> it does not cover the scenario I described (it only checks the behavior when 
> the DLQ fails, not when it succeeds).
> Basically, in the current release, I can either have:
> * the DLC handle *all* exceptions (default)
> * the DLC handle *no* exception at all (with 
> {{deadLetterHandleNewException=false}})
> However, the intended behavior with {{deadLetterHandleNewException=false}} 
> should have the DLC handle any exception thrown during normal routing, while 
> not handling any exception thrown during the DLQ processing itself.



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

[jira] [Updated] (CAMEL-9555) Setting deadLetterHandleNewException to false breaks DeadLetterChannel default exception handling

[Laurent Chiarello (JIRA)]

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

Laurent Chiarello updated CAMEL-9555:
-
Attachment: DeadLetterChannelTest.java

Reupload of Test case

> Setting deadLetterHandleNewException to false breaks DeadLetterChannel 
> default exception handling
> -
>
> Key: CAMEL-9555
> URL: https://issues.apache.org/jira/browse/CAMEL-9555
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Laurent Chiarello
>Assignee: Claus Ibsen
> Fix For: 2.15.6, 2.16.3, 2.17.0
>
> Attachments: DeadLetterChannelTest.java
>
>
> By default, the {{DeadLetterChannel}} handles every exception, including any 
> exception thrown by the dead letter itself. This can be changed by setting 
> the option {{deadLetterHandleNewException}} to _false_. Unfortunately, 
> setting it to _false_ also disable the handling in case of a normal 
> exception, which is not at all what the name suggests. 
> To make the point clear, here is the little scenario I am trying to set up, 
> and why this option is really important in that case.
> h3. Scenario
> I have a camel route consuming persistent messages from a JMS (activemq) 
> endpoint. I have set {{CLIENT_ACKNOWLEDGE}} on the component to prevent 
> consuming the messages until they have been successfully processed.
> So I want to configure my error handler as a {{DeadLetterChannel}} with the 
> following behavior:
> # in case of an exception during processing, send the message to a DLQ
> # if the DLQ itself fails (preventing the message to be safely stored), do 
> not handle it and let the exception being propagated back to the JMS 
> consumer, such that ActiveMQ won't remove it from its queue.
> From my understanding, this is what the option 
> {{deadLetterHandleNewException=false}} should provide. But when testing it, 
> setting it to _false_ actually breaks the default handling of the dead letter 
> channel as well, and no exception at all are handled, even when successfully 
> sent to the DLQ...
> I checked {{DeadLetterHandleNewExceptionTest}} from the camel test cases, but 
> it does not cover the scenario I described (it only checks the behavior when 
> the DLQ fails, not when it succeeds).
> Basically, in the current release, I can either have:
> * the DLC handle *all* exceptions (default)
> * the DLC handle *no* exception at all (with 
> {{deadLetterHandleNewException=false}})
> However, the intended behavior with {{deadLetterHandleNewException=false}} 
> should have the DLC handle any exception thrown during normal routing, while 
> not handling any exception thrown during the DLQ processing itself.



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

[jira] [Assigned] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

[Christian Schneider (JIRA)]

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

Christian Schneider reassigned CAMEL-9570:
--

Assignee: Christian Schneider

> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



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

[jira] [Created] (CAMEL-9573) Multicast and RecipientList - ShareUnitOfWork should rework a bit

[Claus Ibsen (JIRA)]

Claus Ibsen created CAMEL-9573:
--

 Summary: Multicast and RecipientList - ShareUnitOfWork should 
rework a bit
 Key: CAMEL-9573
 URL: https://issues.apache.org/jira/browse/CAMEL-9573
 Project: Camel
  Issue Type: Task
  Components: camel-core
Reporter: Claus Ibsen
Assignee: Claus Ibsen


They should not return CamelInternalProcessor in the createProcessor. But 
should like aggregate / splitter does.

We would need a way to add the advice in another way, so we can return the real 
processor in the method.



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

[jira] [Commented] (CAMEL-4725) camel-sql - Add support for Callable statements

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-4725:


I added a page for the documentation
https://cwiki.apache.org/confluence/display/CAMEL/SQL+Stored+Procedure

> camel-sql - Add support for Callable statements
> ---
>
> Key: CAMEL-4725
> URL: https://issues.apache.org/jira/browse/CAMEL-4725
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-sql
>Affects Versions: 2.8.3
>Reporter: Christian Müller
>Assignee: Claus Ibsen
> Fix For: 2.17.0
>
>
> See 
> [Nabble|http://camel.465427.n5.nabble.com/call-Oracle-Package-procedure-td5032133.html]
>  for details.



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

[jira] [Assigned] (CAMEL-9444) Incorrect exceptions handling from Splitter

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-9444:
--

Assignee: Claus Ibsen

> Incorrect exceptions handling from Splitter
> ---
>
> Key: CAMEL-9444
> URL: https://issues.apache.org/jira/browse/CAMEL-9444
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.1
> Environment: OS: Ubuntu 15.10
> JDK: Oracle JDK 1.8.0_66
> Camel version: 2.16.1
>Reporter: Vlad Oblamskyi
>Assignee: Claus Ibsen
> Attachments: camel-test.zip
>
>
> Steps to reproduce:
> 1. Create global onException handler
> {code}
> 
> java.lang.Exception
> 
> false
> 
> 
> 
> {code}
> 2. Create 2 routes with Splitter (set shareUnitOfWork to TRUE, important)
> {code}
> 
> 
> 
> 
> ${body}
> 
> 
> 
> 
> 
> 
> 
> {code}
> Expected: string "SOME MESSAGE" is logged
> Actual:   is not executed at all 



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

[jira] [Resolved] (CAMEL-4725) camel-sql - Add support for Callable statements

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-4725.

Resolution: Fixed

> camel-sql - Add support for Callable statements
> ---
>
> Key: CAMEL-4725
> URL: https://issues.apache.org/jira/browse/CAMEL-4725
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-sql
>Affects Versions: 2.8.3
>Reporter: Christian Müller
>Assignee: Claus Ibsen
> Fix For: 2.17.0
>
>
> See 
> [Nabble|http://camel.465427.n5.nabble.com/call-Oracle-Package-procedure-td5032133.html]
>  for details.



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

[jira] [Commented] (CAMEL-9444) Incorrect exceptions handling from Splitter

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-9444:


This problem is only when handled is false and you use shareUnitOfWork.

> Incorrect exceptions handling from Splitter
> ---
>
> Key: CAMEL-9444
> URL: https://issues.apache.org/jira/browse/CAMEL-9444
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.1
> Environment: OS: Ubuntu 15.10
> JDK: Oracle JDK 1.8.0_66
> Camel version: 2.16.1
>Reporter: Vlad Oblamskyi
>Assignee: Claus Ibsen
> Attachments: camel-test.zip
>
>
> Steps to reproduce:
> 1. Create global onException handler
> {code}
> 
> java.lang.Exception
> 
> false
> 
> 
> 
> {code}
> 2. Create 2 routes with Splitter (set shareUnitOfWork to TRUE, important)
> {code}
> 
> 
> 
> 
> ${body}
> 
> 
> 
> 
> 
> 
> 
> {code}
> Expected: string "SOME MESSAGE" is logged
> Actual:   is not executed at all 



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

[jira] [Updated] (CAMEL-9444) Incorrect exceptions handling from Splitter

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-9444:
---
Estimated Complexity: Advanced  (was: Unknown)

> Incorrect exceptions handling from Splitter
> ---
>
> Key: CAMEL-9444
> URL: https://issues.apache.org/jira/browse/CAMEL-9444
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.1
> Environment: OS: Ubuntu 15.10
> JDK: Oracle JDK 1.8.0_66
> Camel version: 2.16.1
>Reporter: Vlad Oblamskyi
>Assignee: Claus Ibsen
> Attachments: camel-test.zip
>
>
> Steps to reproduce:
> 1. Create global onException handler
> {code}
> 
> java.lang.Exception
> 
> false
> 
> 
> 
> {code}
> 2. Create 2 routes with Splitter (set shareUnitOfWork to TRUE, important)
> {code}
> 
> 
> 
> 
> ${body}
> 
> 
> 
> 
> 
> 
> 
> {code}
> Expected: string "SOME MESSAGE" is logged
> Actual:   is not executed at all 



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

[jira] [Commented] (CAMEL-9498) Always provide a writable local registry

[Jyrki Ruuskanen (JIRA)]

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

Jyrki Ruuskanen commented on CAMEL-9498:


Claus et al, I'd really appreciate some feedback on this PR.

> Always provide a writable local registry
> 
>
> Key: CAMEL-9498
> URL: https://issues.apache.org/jira/browse/CAMEL-9498
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Jyrki Ruuskanen
>Priority: Minor
>
> Many Camel components need to reference objects in CamelContext's registry as 
> part of their configuration (for example httpClientConfigurer for http/http4 
> and restletRealm for restlet).
> These objects often apply to that particular CamelContext and not others, 
> thus the registry holding these bits could be local instead of, say, OSGi 
> service registry. Using a local registry prevents the risk of conflicting 
> keys and spares us from devising a naming policy for even trivial stuff.
> To conveniently create and add these objects, even from inside RouteBuilder's 
> configure method, we need write access to said registry.
> CamelContext should, in my opinion, provide a local SimpleRegistry that is 
> always available.



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

[jira] [Created] (CAMEL-9574) Be able to force one-way operation when using camel-cxf transport

[David J. M. Karlsen (JIRA)]

David J. M. Karlsen created CAMEL-9574:
--

 Summary: Be able to force one-way operation when using camel-cxf 
transport
 Key: CAMEL-9574
 URL: https://issues.apache.org/jira/browse/CAMEL-9574
 Project: Camel
  Issue Type: New Feature
  Components: camel-cxf
Reporter: David J. M. Karlsen


It should be possible to make/force invocations oneway only (outonly? inonly?) 
either by setting the exchangePattern in the camel route or configuring the 
endpoint explicitly.
The way it works today is that it will always wait synchronously for the 
response if invoking a request/reply defined operation.
My usecase is to invoke soap webservices over JMS by using the camel cxf 
transport, but I would like the responses to appear decoupled on a dedicated 
messagedriven endpoint - not in a request/reply manner



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

[jira] [Created] (CAMEL-9575) Computing Content-Type

[Seiji Sogabe (JIRA)]

Seiji Sogabe created CAMEL-9575:
---

 Summary: Computing Content-Type
 Key: CAMEL-9575
 URL: https://issues.apache.org/jira/browse/CAMEL-9575
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.16.2
Reporter: Seiji Sogabe


See 
http://camel.465427.n5.nabble.com/Invalid-quot-Content-Type-quot-Header-is-configured-td5777250.html

Content-Type header of response should be "application/xml", not 
"application/json".
It seems that if Content-Type header of *request* has been configured, it is 
used as a Content-Type header of *response*.





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

[jira] [Updated] (CAMEL-9575) Computing Content-Type

[Seiji Sogabe (JIRA)]

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

Seiji Sogabe updated CAMEL-9575:

Flags: Patch

created PR.
 https://github.com/apache/camel/pull/828

> Computing Content-Type
> --
>
> Key: CAMEL-9575
> URL: https://issues.apache.org/jira/browse/CAMEL-9575
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.2
>Reporter: Seiji Sogabe
>
> See 
> http://camel.465427.n5.nabble.com/Invalid-quot-Content-Type-quot-Header-is-configured-td5777250.html
> Content-Type header of response should be "application/xml", not 
> "application/json".
> It seems that if Content-Type header of *request* has been configured, it is 
> used as a Content-Type header of *response*.



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

[jira] [Commented] (CAMEL-9575) Computing Content-Type

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9575:
---

GitHub user ssogabe opened a pull request:

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

[CAMEL-9575] overrides Content-Type header even if it is set, or not



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

$ git pull https://github.com/ssogabe/camel CAMEL-9575

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

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


commit ee70ee95e6b960b384914f6bb8ba8ca867ccb99e
Author: Seiji Sogabe 
Date:   2016-02-08T06:27:47Z

overrides Content-Type header even if it is set, or not




> Computing Content-Type
> --
>
> Key: CAMEL-9575
> URL: https://issues.apache.org/jira/browse/CAMEL-9575
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.2
>Reporter: Seiji Sogabe
>
> See 
> http://camel.465427.n5.nabble.com/Invalid-quot-Content-Type-quot-Header-is-configured-td5777250.html
> Content-Type header of response should be "application/xml", not 
> "application/json".
> It seems that if Content-Type header of *request* has been configured, it is 
> used as a Content-Type header of *response*.



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