[jira] [Commented] (CAMEL-8943) camel-jetty should use jetty9 as default

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen commented on CAMEL-8943:


There may be some other components using camel-jetty for testing that may rely 
on it was version 8. So an idea is to build all the code and also unit test 
those modules that are using camel-jetty. 


> camel-jetty should use jetty9 as default
> 
>
> Key: CAMEL-8943
> URL: https://issues.apache.org/jira/browse/CAMEL-8943
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jetty
>Reporter: Claus Ibsen
> Fix For: 2.16.0
>
>
> We should use jetty 9 as the default jetty version



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

[jira] [Updated] (CAMEL-9139) Reading parameter not configurable via header in camel-facebook

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen updated CAMEL-9139:
---
Fix Version/s: 2.16.0

> Reading parameter not configurable via header in camel-facebook
> ---
>
> Key: CAMEL-9139
> URL: https://issues.apache.org/jira/browse/CAMEL-9139
> Project: Camel
>  Issue Type: Bug
>  Components: camel-facebook
>Affects Versions: 2.16.0
>Reporter: Manuel Holzleitner
>Assignee: Andrea Cosentino
> Fix For: 2.16.0
>
>
> The reading parameter in camel-facebook can not be configured via an exchange 
> header as described in the documentation:
> bq. The reading option can be a reference or value of type 
> facebook4j.Reading, or can be specified using the following reading options 
> in either the endpoint URI *or exchange header with CamelFacebook. prefix*.



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

[jira] [Updated] (CAMEL-9140) Missing configuration properties in camel-facebook

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen updated CAMEL-9140:
---
Fix Version/s: 2.16.0

> Missing configuration properties in camel-facebook
> --
>
> Key: CAMEL-9140
> URL: https://issues.apache.org/jira/browse/CAMEL-9140
> Project: Camel
>  Issue Type: Bug
>  Components: camel-facebook
>Affects Versions: 2.16.0
>Reporter: Manuel Holzleitner
>Assignee: Andrea Cosentino
> Fix For: 2.16.0
>
>
> For the new request methods that were introduced with the Facebook4j 2.x 
> version (see CAMEL-7634) some new parameter arguments are required but were 
> not added to the endpoint configuration (e.g. pageId for getPage) and thus 
> endpoints for this methods fail to resolve.
> For example, the following does not work: facebook://getPage?pageId=6538157161



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

[jira] [Created] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests

2015-09-16 Thread Scott Cranton (JIRA) 
Scott Cranton created CAMEL-9142:


 Summary: dropped support for multiple blueprint descriptors in 
unit tests
 Key: CAMEL-9142
 URL: https://issues.apache.org/jira/browse/CAMEL-9142
 Project: Camel
  Issue Type: Bug
Affects Versions: 2.15.3
Reporter: Scott Cranton
Priority: Minor






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

[jira] [Reopened] (CAMEL-9097) XSLT Aggregation Strategy

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen reopened CAMEL-9097:


> XSLT Aggregation Strategy
> -
>
> Key: CAMEL-9097
> URL: https://issues.apache.org/jira/browse/CAMEL-9097
> Project: Camel
>  Issue Type: New Feature
>Reporter: Ranil Wijeyratne
>Assignee: Raúl Kripalani
>Priority: Minor
>  Labels: aggregate, xslt
> Fix For: 2.16.0
>
>
> It would be great to have an built in aggregation strategy that allows to use 
> an xsl stylesheet to aggregate messages.



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

[jira] [Commented] (CAMEL-9140) Missing configuration properties in camel-facebook

2015-09-16 Thread ASF GitHub Bot (JIRA) 

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

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

Github user manuelh9r closed the pull request at:

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


> Missing configuration properties in camel-facebook
> --
>
> Key: CAMEL-9140
> URL: https://issues.apache.org/jira/browse/CAMEL-9140
> Project: Camel
>  Issue Type: Bug
>  Components: camel-facebook
>Affects Versions: 2.16.0
>Reporter: Manuel Holzleitner
>Assignee: Andrea Cosentino
> Fix For: 2.16.0
>
>
> For the new request methods that were introduced with the Facebook4j 2.x 
> version (see CAMEL-7634) some new parameter arguments are required but were 
> not added to the endpoint configuration (e.g. pageId for getPage) and thus 
> endpoints for this methods fail to resolve.
> For example, the following does not work: facebook://getPage?pageId=6538157161



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

[jira] [Commented] (CAMEL-9119) XSLT errors should not be ignored

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen commented on CAMEL-9119:


This causes side-effects - looking into reverting this

> XSLT errors should not be ignored
> -
>
> Key: CAMEL-9119
> URL: https://issues.apache.org/jira/browse/CAMEL-9119
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.14.3
> Environment: ServiceMix 5.4.1
>Reporter: metatech
>Assignee: Claus Ibsen
> Fix For: 2.16.0, 2.15.4
>
> Attachments: camel_xslt_errors_thrown.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Since CAMEL-4396, XSLT exceptions are not logged anymore on System.err.
> Unfortunately, the XsltErrorHandler which was introduced does not behave as 
> the default ErrorHandler which logs on System.err and re-throws exceptions 
> (my mistake). 
> The XsltErrorHandler should re-throw exceptions for ERROR or FATAL, otherwise 
> they are ignored and the service is allowed to start, although the XSLT 
> transformation is not successfully started.
> Here is a small patch that fixes that.
> The test "XsltTestErrorListenerTest" is still successful.



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

[jira] [Commented] (CAMEL-9097) XSLT Aggregation Strategy

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen commented on CAMEL-9097:


This causes many unit tests errors in camel-core - I guess because you add saxon
{code}
Tests in error:
  
DefaultNamespaceContextTest>TestSupport.runBare:58->testDefaultNamespaceContextDualNamespaces:79
 » UnsupportedOperation
  
DefaultNamespaceContextTest>TestSupport.runBare:58->testDefaultNamespaceContextParent:98
 » UnsupportedOperation
  
DefaultNamespaceContextTest>TestSupport.runBare:58->testDefaultNamespaceContextPre:58
 » UnsupportedOperation
  
DefaultNamespaceContextTest>TestSupport.runBare:58->testDefaultNamespaceContextEmpty:39
 » UnsupportedOperation
  XPathFeatureTest>TestSupport.runBare:58->testXPathResult:46 » NullPointer
  
XsltRouteAllowStAXTest>TestSupport.runBare:58->XsltRouteTest.testSendBytesMessage:37->XsltRouteTest.sendMessageAndHaveItTransformed:50
 » CamelExecution
  
XsltRouteAllowStAXTest>TestSupport.runBare:58->XsltRouteTest.testSendDomMessage:43->XsltRouteTest.sendMessageAndHaveItTransformed:50
 » CamelExecution
  
XsltRouteAllowStAXTest>TestSupport.runBare:58->XsltRouteTest.testSendStringMessage:33->XsltRouteTest.sendMessageAndHaveItTransformed:50
 » CamelExecution
  
XsltRouteFileTest>TestSupport.runBare:58->XsltRouteTest.testSendBytesMessage:37->XsltRouteTest.sendMessageAndHaveItTransformed:50
 » CamelExecution
  
XsltRouteFileTest>TestSupport.runBare:58->XsltRouteTest.testSendDomMessage:43->XsltRouteTest.sendMessageAndHaveItTransformed:50
 » CamelExecution
  
XsltRouteFileTest>TestSupport.runBare:58->XsltRouteTest.testSendStringMessage:33->XsltRouteTest.sendMessageAndHaveItTransformed:50
 » CamelExecution
  
XsltRouteTest>TestSupport.runBare:58->testSendBytesMessage:37->sendMessageAndHaveItTransformed:50
 » CamelExecution
  
XsltRouteTest>TestSupport.runBare:58->testSendDomMessage:43->sendMessageAndHaveItTransformed:50
 » CamelExecution
  
XsltRouteTest>TestSupport.runBare:58->testSendStringMessage:33->sendMessageAndHaveItTransformed:50
 » CamelExecution
  
AsyncLoopTest>TestSupport.runBare:58->testExpressionClauseLoop:46->performLoopTest:87->performLoopTest:82
 » CamelExecution
  
LoopTest>TestSupport.runBare:58->testExpressionClauseLoop:40->performLoopTest:70->performLoopTest:65
 » CamelExecution
  
ToDynamicLanguageSimpleAndXPathAndHeaderTest>TestSupport.runBare:58->testToDynamic:28
 » CamelExecution
  ToDynamicLanguageSimpleAndXPathTest>TestSupport.runBare:58->testToDynamic:28 
» CamelExecution
  ToDynamicLanguageXPathTest>TestSupport.runBare:58->testToDynamic:28 » 
CamelExecution
{code}

> XSLT Aggregation Strategy
> -
>
> Key: CAMEL-9097
> URL: https://issues.apache.org/jira/browse/CAMEL-9097
> Project: Camel
>  Issue Type: New Feature
>Reporter: Ranil Wijeyratne
>Assignee: Raúl Kripalani
>Priority: Minor
>  Labels: aggregate, xslt
> Fix For: 2.16.0
>
>
> It would be great to have an built in aggregation strategy that allows to use 
> an xsl stylesheet to aggregate messages.



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

[jira] [Reopened] (CAMEL-9119) XSLT errors should not be ignored

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen reopened CAMEL-9119:


> XSLT errors should not be ignored
> -
>
> Key: CAMEL-9119
> URL: https://issues.apache.org/jira/browse/CAMEL-9119
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.14.3
> Environment: ServiceMix 5.4.1
>Reporter: metatech
>Assignee: Claus Ibsen
> Fix For: 2.16.0, 2.15.4
>
> Attachments: camel_xslt_errors_thrown.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Since CAMEL-4396, XSLT exceptions are not logged anymore on System.err.
> Unfortunately, the XsltErrorHandler which was introduced does not behave as 
> the default ErrorHandler which logs on System.err and re-throws exceptions 
> (my mistake). 
> The XsltErrorHandler should re-throw exceptions for ERROR or FATAL, otherwise 
> they are ignored and the service is allowed to start, although the XSLT 
> transformation is not successfully started.
> Here is a small patch that fixes that.
> The test "XsltTestErrorListenerTest" is still successful.



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

[jira] [Created] (CAMEL-9141) Salesforce component's LoginToken.java is broken

2015-09-16 Thread Devendra Khanolkar (JIRA) 
Devendra Khanolkar created CAMEL-9141:
-

 Summary: Salesforce component's LoginToken.java is broken
 Key: CAMEL-9141
 URL: https://issues.apache.org/jira/browse/CAMEL-9141
 Project: Camel
  Issue Type: Bug
Reporter: Devendra Khanolkar


Apparently, Salesforce released a patch to all their non prod env's over the 
weekend and that has busted the camel components login.
Here is the error - 
Caused by: org.codehaus.jackson.map.exc.UnrecognizedPropertyException: 
Unrecognized field "is_readonly" (Class 
org.apache.camel.component.salesforce.internal.dto.LoginToken), not marked as 
ignorable
 at [Source: [B@3112c01a; line: 1, column: 147] (through reference chain: 
org.apache.camel.component.salesforce.internal.dto.LoginToken["is_readonly"])

I've submitted a pull request - 
https://github.com/apache/camel/pull/615

I've tested it against https://test.salesforce.com, however its worth testing 
against https://login.salesforce.com



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

[jira] [Updated] (CAMEL-9141) Salesforce component's LoginToken.java is broken

2015-09-16 Thread Devendra Khanolkar (JIRA) 

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

Devendra Khanolkar updated CAMEL-9141:
--
Affects Version/s: 2.15.3
Fix Version/s: 2.16.0

> Salesforce component's LoginToken.java is broken
> 
>
> Key: CAMEL-9141
> URL: https://issues.apache.org/jira/browse/CAMEL-9141
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.15.3
>Reporter: Devendra Khanolkar
> Fix For: 2.16.0
>
>
> Apparently, Salesforce released a patch to all their non prod env's over the 
> weekend and that has busted the camel components login.
> Here is the error - 
> Caused by: org.codehaus.jackson.map.exc.UnrecognizedPropertyException: 
> Unrecognized field "is_readonly" (Class 
> org.apache.camel.component.salesforce.internal.dto.LoginToken), not marked as 
> ignorable
>  at [Source: [B@3112c01a; line: 1, column: 147] (through reference chain: 
> org.apache.camel.component.salesforce.internal.dto.LoginToken["is_readonly"])
> I've submitted a pull request - 
> https://github.com/apache/camel/pull/615
> I've tested it against https://test.salesforce.com, however its worth testing 
> against https://login.salesforce.com



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

[jira] [Commented] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests

2015-09-16 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user scranton opened a pull request:

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

CAMEL-9142: added back support for multiple blueprint descriptors in …

…camel-test-blueprint

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

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

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

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


commit 4f212df06867c7b7b4fd63e465080399c54ee6dc
Author: Scott Cranton 
Date:   2015-09-16T12:39:07Z

CAMEL-9142: added back support for multiple blueprint descriptors in 
camel-test-blueprint




> dropped support for multiple blueprint descriptors in unit tests
> 
>
> Key: CAMEL-9142
> URL: https://issues.apache.org/jira/browse/CAMEL-9142
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.15.3
>Reporter: Scott Cranton
>Priority: Minor
>




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

[jira] [Updated] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests

2015-09-16 Thread Scott Cranton (JIRA) 

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

Scott Cranton updated CAMEL-9142:
-
Patch Info: Patch Available

> dropped support for multiple blueprint descriptors in unit tests
> 
>
> Key: CAMEL-9142
> URL: https://issues.apache.org/jira/browse/CAMEL-9142
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.15.3
>Reporter: Scott Cranton
>Priority: Minor
>




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

[jira] [Commented] (CAMEL-9097) XSLT Aggregation Strategy

2015-09-16 Thread JIRA 

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

Raúl Kripalani commented on CAMEL-9097:
---

Thanks, Claus. I'll have a look. It doesn't break anything in Camel – though. I 
had to add Saxon because of this old bug in Xalan which affects the unit tests 
for this new Aggr. Strategy: https://issues.apache.org/jira/browse/XALANJ-2057.

> XSLT Aggregation Strategy
> -
>
> Key: CAMEL-9097
> URL: https://issues.apache.org/jira/browse/CAMEL-9097
> Project: Camel
>  Issue Type: New Feature
>Reporter: Ranil Wijeyratne
>Assignee: Raúl Kripalani
>Priority: Minor
>  Labels: aggregate, xslt
> Fix For: 2.16.0
>
>
> It would be great to have an built in aggregation strategy that allows to use 
> an xsl stylesheet to aggregate messages.



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

[jira] [Commented] (CAMEL-9119) XSLT errors should not be ignored

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen commented on CAMEL-9119:


Okay seems it was another ticket that had a knock-on effect on this. JDK vs 
Saxon behaves different and report different errors etc.

> XSLT errors should not be ignored
> -
>
> Key: CAMEL-9119
> URL: https://issues.apache.org/jira/browse/CAMEL-9119
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.14.3
> Environment: ServiceMix 5.4.1
>Reporter: metatech
>Assignee: Claus Ibsen
> Fix For: 2.16.0, 2.15.4
>
> Attachments: camel_xslt_errors_thrown.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Since CAMEL-4396, XSLT exceptions are not logged anymore on System.err.
> Unfortunately, the XsltErrorHandler which was introduced does not behave as 
> the default ErrorHandler which logs on System.err and re-throws exceptions 
> (my mistake). 
> The XsltErrorHandler should re-throw exceptions for ERROR or FATAL, otherwise 
> they are ignored and the service is allowed to start, although the XSLT 
> transformation is not successfully started.
> Here is a small patch that fixes that.
> The test "XsltTestErrorListenerTest" is still successful.



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

[jira] [Commented] (CAMEL-9097) XSLT Aggregation Strategy

2015-09-16 Thread JIRA 

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

Raúl Kripalani commented on CAMEL-9097:
---

Sounds like a plan. Will you take care of it, then? 

Just the test, right? We want the strategy to remain in camel-core so that 
folks running processors other than Xalan or Saxon can also use it without 
importing camel-saxon.

Thanks.

> XSLT Aggregation Strategy
> -
>
> Key: CAMEL-9097
> URL: https://issues.apache.org/jira/browse/CAMEL-9097
> Project: Camel
>  Issue Type: New Feature
>Reporter: Ranil Wijeyratne
>Assignee: Raúl Kripalani
>Priority: Minor
>  Labels: aggregate, xslt
> Fix For: 2.16.0
>
>
> It would be great to have an built in aggregation strategy that allows to use 
> an xsl stylesheet to aggregate messages.



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

[jira] [Commented] (CAMEL-9097) XSLT Aggregation Strategy

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen commented on CAMEL-9097:


Okay moving the xslt test to camel-saxon should be the right solution which I 
am doing now.

> XSLT Aggregation Strategy
> -
>
> Key: CAMEL-9097
> URL: https://issues.apache.org/jira/browse/CAMEL-9097
> Project: Camel
>  Issue Type: New Feature
>Reporter: Ranil Wijeyratne
>Assignee: Raúl Kripalani
>Priority: Minor
>  Labels: aggregate, xslt
> Fix For: 2.16.0
>
>
> It would be great to have an built in aggregation strategy that allows to use 
> an xsl stylesheet to aggregate messages.



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

[jira] [Resolved] (CAMEL-9097) XSLT Aggregation Strategy

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen resolved CAMEL-9097.

Resolution: Fixed

> XSLT Aggregation Strategy
> -
>
> Key: CAMEL-9097
> URL: https://issues.apache.org/jira/browse/CAMEL-9097
> Project: Camel
>  Issue Type: New Feature
>Reporter: Ranil Wijeyratne
>Assignee: Raúl Kripalani
>Priority: Minor
>  Labels: aggregate, xslt
> Fix For: 2.16.0
>
>
> It would be great to have an built in aggregation strategy that allows to use 
> an xsl stylesheet to aggregate messages.



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

[jira] [Commented] (CAMEL-8587) Exceptions from multicast aggregators are not propagated to the global exception handler

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen commented on CAMEL-8587:


If an exception is thrown from the aggregate method in the AggregationStrategy, 
then by default, that exception is not handled by the error handler. The error 
handler can be enabled to react if enabling the shareUnitOfWork option.

> Exceptions from multicast aggregators are not propagated to the global 
> exception handler
> 
>
> Key: CAMEL-8587
> URL: https://issues.apache.org/jira/browse/CAMEL-8587
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.15.1
>Reporter: Pavel Drasil
>Assignee: Claus Ibsen
> Fix For: 2.16.0
>
> Attachments: MyAggregator.java, camel-context.xml
>
>
> When a multicast aggregator throws an exception, either directly or by 
> setting the exception to the returned exchange, the exception is just logged 
> instead of being  propagated to the global exception handler.



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

[jira] [Updated] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests

2015-09-16 Thread Scott Cranton (JIRA) 

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

Scott Cranton updated CAMEL-9142:
-
Description: Looks like update CAMEL-8948 dropped support for multiple 
blueprint descriptors within CamelBlueprintTestSupport file within 
camel-test-blueprint component. The symptom is a null input stream for unit 
tests that have a getBlueprintDescriptor with multiple file references, i.e. a 
'+' concatenating two or more descriptor files.

> dropped support for multiple blueprint descriptors in unit tests
> 
>
> Key: CAMEL-9142
> URL: https://issues.apache.org/jira/browse/CAMEL-9142
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.15.3
>Reporter: Scott Cranton
>Priority: Minor
>
> Looks like update CAMEL-8948 dropped support for multiple blueprint 
> descriptors within CamelBlueprintTestSupport file within camel-test-blueprint 
> component. The symptom is a null input stream for unit tests that have a 
> getBlueprintDescriptor with multiple file references, i.e. a '+' 
> concatenating two or more descriptor files.



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

[jira] [Resolved] (CAMEL-8393) Redelivery doesn't work correctly on Dynamic Routers

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen resolved CAMEL-8393.

Resolution: Fixed

Thanks for reporting

> Redelivery doesn't work correctly on Dynamic Routers
> 
>
> Key: CAMEL-8393
> URL: https://issues.apache.org/jira/browse/CAMEL-8393
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.1
> Environment: mac
>Reporter: Minh Tran
>Assignee: Claus Ibsen
> Fix For: 2.16.0
>
>
> When redelivery occurs for dynamic routers, the properties are being kept. So 
> if the dynamic router uses a property to store the current state such as used 
> in example http://camel.apache.org/dynamic-router.html , then the redelivery 
> actually ends up skipping the endpoint that caused the exception
> Here is my dynamic router class
> {noformat}
> public class Router {
>   public String route(Exchange exchange) {
>   Boolean invoked = exchange.getProperty("invoked", 
> Boolean.class);
>   if (invoked == null) {
>   exchange.setProperty("invoked", true);
>   return "mock:route";
>   } else
>   return null;
>   }
> }
> {noformat}
> Here is my unit test class
> {noformat}
> @RunWith(CamelSpringJUnit4ClassRunner.class)
> @ContextConfiguration(loader = CamelSpringDelegatingTestContextLoader.class)
> public class DynamicRouterTest {
>   @Produce(uri = "direct:start")
>   private ProducerTemplate producerTemplate;
>   @EndpointInject(uri = "mock:end")
>   private MockEndpoint end;
>   @EndpointInject(uri = "mock:route")
>   private MockEndpoint route;
>   @Configuration
>   public static class JavaConfig extends SingleRouteCamelConfiguration {
>   @Override
>   public RouteBuilder route() {
>   return new SpringRouteBuilder() {
>   @Override
>   public void configure() throws Exception {
>   this.getContext().setTracing(true);
>   
> from("direct:start").onException(IOException.class).maximumRedeliveries(-1).end()
>   
> .dynamicRouter().method(Router.class).to("mock:end");
>   }
>   };
>   }
>   }
>   @Test
>   public void test() throws InterruptedException {
>   route.whenAnyExchangeReceived(new Processor() {
>   @Override
>   public void process(Exchange exchange) throws Exception 
> {
>   exchange.getIn().setBody("mock route");
>   }
>   });
>   route.expectedBodiesReceived("before");
>   end.expectedBodiesReceived("mock route");
>   producerTemplate.sendBody("before");
>   route.assertIsSatisfied();
>   end.assertIsSatisfied();
>   }
>   @Test
>   public void test_exception() throws InterruptedException {
>   route.whenExchangeReceived(1, new Processor() {
>   @Override
>   public void process(Exchange exchange) throws Exception 
> {
>   exchange.setException(new IOException());
>   }
>   });
>   route.whenExchangeReceived(2, new Processor() {
>   @Override
>   public void process(Exchange exchange) throws Exception 
> {
>   exchange.getIn().setBody("mock route");
>   }
>   });
> // this bit fails
>   route.expectedBodiesReceived("before", "before");
>   end.expectedBodiesReceived("mock route");
>   producerTemplate.sendBody("before");
>   route.assertIsSatisfied();
>   end.assertIsSatisfied();
>   }
> }
> {noformat}
> The test method runs successfully but the test_exception method which tests 
> the redelivery does not. Fails with "java.lang.AssertionError: mock://route 
> Received message count. Expected: <2> but was: <1>" which shows that the 
> dynamic router only called the mock:route once.
>   



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

[jira] [Updated] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests

2015-09-16 Thread Scott Cranton (JIRA) 

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

Scott Cranton updated CAMEL-9142:
-
Description: Looks like update CAMEL-8948 dropped support for multiple 
blueprint descriptors within CamelBlueprintTestSupport file within 
camel-test-blueprint component. The symptom is a 'java.lang.RuntimeException: 
InputStream cannot be null' for unit tests that have a getBlueprintDescriptor 
with multiple file references, i.e. a '+' concatenating two or more descriptor 
files.  (was: Looks like update CAMEL-8948 dropped support for multiple 
blueprint descriptors within CamelBlueprintTestSupport file within 
camel-test-blueprint component. The symptom is a null input stream for unit 
tests that have a getBlueprintDescriptor with multiple file references, i.e. a 
'+' concatenating two or more descriptor files.)

> dropped support for multiple blueprint descriptors in unit tests
> 
>
> Key: CAMEL-9142
> URL: https://issues.apache.org/jira/browse/CAMEL-9142
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.15.3
>Reporter: Scott Cranton
>Priority: Minor
>
> Looks like update CAMEL-8948 dropped support for multiple blueprint 
> descriptors within CamelBlueprintTestSupport file within camel-test-blueprint 
> component. The symptom is a 'java.lang.RuntimeException: InputStream cannot 
> be null' for unit tests that have a getBlueprintDescriptor with multiple file 
> references, i.e. a '+' concatenating two or more descriptor files.



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

[jira] [Resolved] (CAMEL-8587) Exceptions from multicast aggregators are not propagated to the global exception handler

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen resolved CAMEL-8587.

Resolution: Cannot Reproduce

> Exceptions from multicast aggregators are not propagated to the global 
> exception handler
> 
>
> Key: CAMEL-8587
> URL: https://issues.apache.org/jira/browse/CAMEL-8587
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.15.1
>Reporter: Pavel Drasil
>Assignee: Claus Ibsen
> Fix For: 2.16.0
>
> Attachments: MyAggregator.java, camel-context.xml
>
>
> When a multicast aggregator throws an exception, either directly or by 
> setting the exception to the returned exchange, the exception is just logged 
> instead of being  propagated to the global exception handler.



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

[jira] [Commented] (CAMEL-9097) XSLT Aggregation Strategy

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen commented on CAMEL-9097:


Yep only the test

> XSLT Aggregation Strategy
> -
>
> Key: CAMEL-9097
> URL: https://issues.apache.org/jira/browse/CAMEL-9097
> Project: Camel
>  Issue Type: New Feature
>Reporter: Ranil Wijeyratne
>Assignee: Raúl Kripalani
>Priority: Minor
>  Labels: aggregate, xslt
> Fix For: 2.16.0
>
>
> It would be great to have an built in aggregation strategy that allows to use 
> an xsl stylesheet to aggregate messages.



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

[jira] [Resolved] (CAMEL-9119) XSLT errors should not be ignored

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen resolved CAMEL-9119.

Resolution: Fixed

> XSLT errors should not be ignored
> -
>
> Key: CAMEL-9119
> URL: https://issues.apache.org/jira/browse/CAMEL-9119
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.14.3
> Environment: ServiceMix 5.4.1
>Reporter: metatech
>Assignee: Claus Ibsen
> Fix For: 2.16.0, 2.15.4
>
> Attachments: camel_xslt_errors_thrown.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Since CAMEL-4396, XSLT exceptions are not logged anymore on System.err.
> Unfortunately, the XsltErrorHandler which was introduced does not behave as 
> the default ErrorHandler which logs on System.err and re-throws exceptions 
> (my mistake). 
> The XsltErrorHandler should re-throw exceptions for ERROR or FATAL, otherwise 
> they are ignored and the service is allowed to start, although the XSLT 
> transformation is not successfully started.
> Here is a small patch that fixes that.
> The test "XsltTestErrorListenerTest" is still successful.



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

[jira] [Updated] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen updated CAMEL-9142:
---
Fix Version/s: 2.15.4
   2.16.0

> dropped support for multiple blueprint descriptors in unit tests
> 
>
> Key: CAMEL-9142
> URL: https://issues.apache.org/jira/browse/CAMEL-9142
> Project: Camel
>  Issue Type: Bug
>  Components: camel-test
>Affects Versions: 2.15.3
>Reporter: Scott Cranton
>Priority: Minor
> Fix For: 2.16.0, 2.15.4
>
>
> Looks like update CAMEL-8948 dropped support for multiple blueprint 
> descriptors within CamelBlueprintTestSupport file within camel-test-blueprint 
> component. The symptom is a 'java.lang.RuntimeException: InputStream cannot 
> be null' for unit tests that have a getBlueprintDescriptor with multiple file 
> references, i.e. a '+' concatenating two or more descriptor files.



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

[jira] [Resolved] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen resolved CAMEL-9142.

Resolution: Fixed
  Assignee: Claus Ibsen

> dropped support for multiple blueprint descriptors in unit tests
> 
>
> Key: CAMEL-9142
> URL: https://issues.apache.org/jira/browse/CAMEL-9142
> Project: Camel
>  Issue Type: Bug
>  Components: camel-test
>Affects Versions: 2.15.3
>Reporter: Scott Cranton
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.16.0, 2.15.4
>
>
> Looks like update CAMEL-8948 dropped support for multiple blueprint 
> descriptors within CamelBlueprintTestSupport file within camel-test-blueprint 
> component. The symptom is a 'java.lang.RuntimeException: InputStream cannot 
> be null' for unit tests that have a getBlueprintDescriptor with multiple file 
> references, i.e. a '+' concatenating two or more descriptor files.



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

[jira] [Resolved] (CAMEL-9141) Salesforce component's LoginToken.java is broken

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen resolved CAMEL-9141.

   Resolution: Fixed
 Assignee: Claus Ibsen
Fix Version/s: 2.15.4

Thanks for the PR

> Salesforce component's LoginToken.java is broken
> 
>
> Key: CAMEL-9141
> URL: https://issues.apache.org/jira/browse/CAMEL-9141
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.15.3
>Reporter: Devendra Khanolkar
>Assignee: Claus Ibsen
> Fix For: 2.16.0, 2.15.4
>
>
> Apparently, Salesforce released a patch to all their non prod env's over the 
> weekend and that has busted the camel components login.
> Here is the error - 
> Caused by: org.codehaus.jackson.map.exc.UnrecognizedPropertyException: 
> Unrecognized field "is_readonly" (Class 
> org.apache.camel.component.salesforce.internal.dto.LoginToken), not marked as 
> ignorable
>  at [Source: [B@3112c01a; line: 1, column: 147] (through reference chain: 
> org.apache.camel.component.salesforce.internal.dto.LoginToken["is_readonly"])
> I've submitted a pull request - 
> https://github.com/apache/camel/pull/615
> I've tested it against https://test.salesforce.com, however its worth testing 
> against https://login.salesforce.com



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

[jira] [Updated] (CAMEL-9070) java.lang.IllegalStateException: SENDING => HEADERS

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen updated CAMEL-9070:
---
Priority: Major  (was: Critical)

> java.lang.IllegalStateException: SENDING => HEADERS
> ---
>
> Key: CAMEL-9070
> URL: https://issues.apache.org/jira/browse/CAMEL-9070
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jetty
>Affects Versions: 2.15.2
> Environment: Karaf 3.0.3
>Reporter: Ralf Steppacher
>
> When using the jetty component in a simple reverse proxy route deployed in 
> {{Karaf 3.0.3}} I randomly receive the following Stacktrace:
> {noformat}
> 2015-08-14 10:44:15,931 | WARN  | (0x64868d0a)-184 | HttpExchange 
> | 117 - org.eclipse.jetty.aggregate.jetty-all-server - 
> 8.1.15.v20140411 |   | EXCEPTION 
> ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)->EXCEPTED(0ms)sent=388ms
> org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING 
> => HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by: 
> [java.lang.IllegalStateException - SENDING => HEADERS]
>   at 
> org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
>   at 
> org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
>   at 
> org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
>   at 
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
>   at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
>   at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
>   at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
> Caused by: java.lang.IllegalStateException: SENDING => HEADERS
>   at 
> org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
>   at 
> org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
>   at 
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
>   at 
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
>   at 
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
>   ... 5 more
> {noformat}
> I have found (rather old) posts on the web that claim that the behavior is 
> related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the 
> following headers:
> {noformat}
> POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
> Accept-Encoding: gzip,deflate
> Content-Type: multipart/related; type="application/xop+xml"; 
> start=""; start-info="application/soap+xml"; 
> action="urn:ihe:iti:2007:RetrieveDocumentSet"; 
> boundary="=_Part_139_1471895036.1439218177147"
> MIME-Version: 1.0
> Content-Length: 6858
> Host: localhost:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
> {noformat}
> The issue pops up at random but not evenly distributed. It either almost 
> always happens or hardly ever. Re-installing my bundle or restarting Karaf 
> usually triggers a switch between the two scenarios on some machines. On 
> others the error is persistent.



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

[jira] [Commented] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests

2015-09-16 Thread ASF GitHub Bot (JIRA) 

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

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

Github user scranton closed the pull request at:

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


> dropped support for multiple blueprint descriptors in unit tests
> 
>
> Key: CAMEL-9142
> URL: https://issues.apache.org/jira/browse/CAMEL-9142
> Project: Camel
>  Issue Type: Bug
>  Components: camel-test
>Affects Versions: 2.15.3
>Reporter: Scott Cranton
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.16.0, 2.15.4
>
>
> Looks like update CAMEL-8948 dropped support for multiple blueprint 
> descriptors within CamelBlueprintTestSupport file within camel-test-blueprint 
> component. The symptom is a 'java.lang.RuntimeException: InputStream cannot 
> be null' for unit tests that have a getBlueprintDescriptor with multiple file 
> references, i.e. a '+' concatenating two or more descriptor files.



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

[jira] [Commented] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests

2015-09-16 Thread Claus Ibsen (JIRA) 

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

Claus Ibsen commented on CAMEL-9142:


Thanks for the patch Scott.

> dropped support for multiple blueprint descriptors in unit tests
> 
>
> Key: CAMEL-9142
> URL: https://issues.apache.org/jira/browse/CAMEL-9142
> Project: Camel
>  Issue Type: Bug
>  Components: camel-test
>Affects Versions: 2.15.3
>Reporter: Scott Cranton
>Priority: Minor
> Fix For: 2.16.0, 2.15.4
>
>
> Looks like update CAMEL-8948 dropped support for multiple blueprint 
> descriptors within CamelBlueprintTestSupport file within camel-test-blueprint 
> component. The symptom is a 'java.lang.RuntimeException: InputStream cannot 
> be null' for unit tests that have a getBlueprintDescriptor with multiple file 
> references, i.e. a '+' concatenating two or more descriptor files.



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

[jira] [Updated] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references

2015-09-16 Thread Bob Browning (JIRA) 

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

Bob Browning updated CAMEL-9143:

Description: 
h4. Description

Producer instances that implement the ServicePoolAware interface will leak 
memory if their route is stopped, with new producers being leaked every time 
the route is started/stopped.

Known implementations that are affected are RemoteFileProducer (ftp, sftp) and 
Mina2Producer.

This is due to the behaviour that the SendProcessor which when the route is 
stopped it shuts down it's `producerCache` instance.

{code}
protected void doStop() throws Exception {
ServiceHelper.stopServices(producerCache, producer);
}
{code}

this in turn calls `stopAndShutdownService(pool)` which will call stop on the 
SharedProducerServicePool instance which is a NOOP however it also calls 
shutdown which effects a stop of the global pool (this stops all the registered 
services and then clears the pool.

{code}
protected void doStop() throws Exception {
// when stopping we intend to shutdown
ServiceHelper.stopAndShutdownService(pool);
try {
ServiceHelper.stopAndShutdownServices(producers.values());
} finally {
// ensure producers are removed, and also from JMX
for (Producer producer : producers.values()) {
getCamelContext().removeService(producer);
}
}
producers.clear();
}
{code}

However no call to `context.removeService(Producer) is called for the entries 
from the pool only those singleton instances that were in the `producers` map 
hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes 
{code}getCamelContext().addService(answer, false);
{code} is never removed. 

Since the global pool is empty when the next request to get a producer is 
called a new producer is created, jmx wrapper and all, whilst the old instance 
remains orphaned retaining any objects that pertain to that instance.

One workaround is for the producer to call 
{code}getEndpoint().getCamelContext().removeService(this){code} in it's stop 
method, however this is fairly obscure and it would probably be better to 
invoke removal of the producer when it is removed from the shared pool.

Another issue of note is that when a route is shutdown that contains a 
SendProcessor due to the shutdown invocation on the SharedProcessorServicePool 
the global pool is cleared of `everything` and remains in `Stopped` state until 
another route starts it (although it is still accessed and used whilst in the 
`Stopped` state).

h4. Impact

For general use where there is no dynamic creation or passivation of routes 
this issue should be minimal, however in our use case where the routes are not 
static, there is a certain amount of recreation of routes as customer endpoints 
change and there is a need to passivate idle routes this causes a considerable 
memory leak (via SFTP in particular).

h4. Test Case
{code}
package org.apache.camel.component;

import com.google.common.util.concurrent.AtomicLongMap;

import org.apache.camel.CamelContext;
import org.apache.camel.Consumer;
import org.apache.camel.Endpoint;
import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.apache.camel.Producer;
import org.apache.camel.Route;
import org.apache.camel.Service;
import org.apache.camel.ServicePoolAware;
import org.apache.camel.ServiceStatus;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.impl.DefaultComponent;
import org.apache.camel.impl.DefaultEndpoint;
import org.apache.camel.impl.DefaultProducer;
import org.apache.camel.support.LifecycleStrategySupport;
import org.apache.camel.support.ServiceSupport;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.Test;

import java.util.Map;

import static com.google.common.base.Preconditions.checkNotNull;

/**
 * Test memory behaviour of producers using {@link ServicePoolAware} when using 
JMX.
 */
public class ServicePoolAwareLeakyTest extends CamelTestSupport {

  private static final String LEAKY_SIEVE_STABLE = 
"leaky://sieve-stable?plugged=true";
  private static final String LEAKY_SIEVE_TRANSIENT = 
"leaky://sieve-transient?plugged=true";


  private static boolean isPatchApplied() {
return Boolean.parseBoolean(System.getProperty("patchApplied", "false"));
  }

  /**
   * Component that provides leaks producers.
   */
  private static class LeakySieveComponent extends DefaultComponent {
@Override
protected Endpoint createEndpoint(String uri, String remaining, Map parameters) throws Exception {
  boolean plugged = "true".equalsIgnoreCase((String) 
parameters.remove("plugged"));
  return new LeakySieveEndpoint(uri, isPatchApplied() && plugged);
}
  }

  /**
   * Endpoint that provides leaky producers.
   */
  private static class

[jira] [Updated] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references

2015-09-16 Thread Bob Browning (JIRA) 

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

Bob Browning updated CAMEL-9143:

Affects Version/s: (was: 2.14.3)

> Producers that implement the ServicePoolAware interface cause memory leak due 
> to JMX references
> ---
>
> Key: CAMEL-9143
> URL: https://issues.apache.org/jira/browse/CAMEL-9143
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.1, 2.14.2, 2.15.0, 2.15.1
>Reporter: Bob Browning
>
> h4. Description
> Producer instances that implement the ServicePoolAware interface will leak 
> memory if their route is stopped, with new producers being leaked every time 
> the route is started/stopped.
> Known implementations that are affected are RemoteFileProducer (ftp, sftp) 
> and Mina2Producer.
> This is due to the behaviour that the SendProcessor which when the route is 
> stopped it shuts down it's `producerCache` instance.
> {code}
> protected void doStop() throws Exception {
> ServiceHelper.stopServices(producerCache, producer);
> }
> {code}
> this in turn calls `stopAndShutdownService(pool)` which will call stop on the 
> SharedProducerServicePool instance which is a NOOP however it also calls 
> shutdown which effects a stop of the global pool (this stops all the 
> registered services and then clears the pool.
> {code}
> protected void doStop() throws Exception {
> // when stopping we intend to shutdown
> ServiceHelper.stopAndShutdownService(pool);
> try {
> ServiceHelper.stopAndShutdownServices(producers.values());
> } finally {
> // ensure producers are removed, and also from JMX
> for (Producer producer : producers.values()) {
> getCamelContext().removeService(producer);
> }
> }
> producers.clear();
> }
> {code}
> However no call to `context.removeService(Producer) is called for the entries 
> from the pool only those singleton instances that were in the `producers` map 
> hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes 
> {code}getCamelContext().addService(answer, false);
> {code} is never removed. 
> Since the global pool is empty when the next request to get a producer is 
> called a new producer is created, jmx wrapper and all, whilst the old 
> instance remains orphaned retaining any objects that pertain to that instance.
> One workaround is for the producer to call 
> {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop 
> method, however this is fairly obscure and it would probably be better to 
> invoke removal of the producer when it is removed from the shared pool.
> Another issue of note is that when a route is shutdown that contains a 
> SendProcessor due to the shutdown invocation on the 
> SharedProcessorServicePool the global pool is cleared of `everything` and 
> remains in `Stopped` state until another route starts it (although it is 
> still accessed and used whilst in the `Stopped` state).
> h4. Impact
> For general use where there is no dynamic creation or passivation of routes 
> this issue should be minimal, however in our use case where the routes are 
> not static, there is a certain amount of recreation of routes as customer 
> endpoints change and there is a need to passivate idle routes this causes a 
> considerable memory leak (via SFTP in particular).
> h4. Test Case
> {code}
> package org.apache.camel.component;
> import com.google.common.util.concurrent.AtomicLongMap;
> import org.apache.camel.CamelContext;
> import org.apache.camel.Consumer;
> import org.apache.camel.Endpoint;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Producer;
> import org.apache.camel.Route;
> import org.apache.camel.Service;
> import org.apache.camel.ServicePoolAware;
> import org.apache.camel.ServiceStatus;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.DefaultComponent;
> import org.apache.camel.impl.DefaultEndpoint;
> import org.apache.camel.impl.DefaultProducer;
> import org.apache.camel.support.LifecycleStrategySupport;
> import org.apache.camel.support.ServiceSupport;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import java.util.Map;
> import static com.google.common.base.Preconditions.checkNotNull;
> /**
>  * Test memory behaviour of producers using {@link ServicePoolAware} when 
> using JMX.
>  */
> public class ServicePoolAwareLeakyTest extends CamelTestSupport {
>   private static final String LEAKY_SIEVE_STABLE = 
> "leaky://sieve-stable?plugged=true";
>   private static final String LEAKY_SIEVE_TRANSIENT = 
>

[jira] [Created] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references

2015-09-16 Thread Bob Browning (JIRA) 
Bob Browning created CAMEL-9143:
---

 Summary: Producers that implement the ServicePoolAware interface 
cause memory leak due to JMX references
 Key: CAMEL-9143
 URL: https://issues.apache.org/jira/browse/CAMEL-9143
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.15.1, 2.15.0, 2.14.3, 2.14.2, 2.14.1
Reporter: Bob Browning


h4. Description

Producer instances that implement the ServicePoolAware interface will leak 
memory if their route is stopped, with new producers being leaked every time 
the route is started/stopped.

Known implementations that are affected are RemoteFileProducer (ftp, sftp) and 
Mina2Producer.

This is due to the behaviour that the SendProcessor which when the route is 
stopped it shuts down it's `producerCache` instance.

{code}
protected void doStop() throws Exception {
ServiceHelper.stopServices(producerCache, producer);
}
{code}

this in turn calls `stopAndShutdownService(pool)` which will call stop on the 
SharedProducerServicePool instance which is a NOOP however it also calls 
shutdown which effects a stop of the global pool (this stops all the registered 
services and then clears the pool.

{code}
protected void doStop() throws Exception {
// when stopping we intend to shutdown
ServiceHelper.stopAndShutdownService(pool);
try {
ServiceHelper.stopAndShutdownServices(producers.values());
} finally {
// ensure producers are removed, and also from JMX
for (Producer producer : producers.values()) {
getCamelContext().removeService(producer);
}
}
producers.clear();
}
{code}

However no call to `context.removeService(Producer) is called for the entries 
from the pool only those singleton instances that were in the `producers` map 
hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes 
{code}getCamelContext().addService(answer, false);
{code} is never removed. 

Since the global pool is empty when the next request to get a producer is 
called a new producer is created, jmx wrapper and all, whilst the old instance 
remains orphaned retaining any objects that pertain to that instance.

One workaround is for the producer to call 
{code}getEndpoint().getCamelContext().removeService(this){code} in it's stop 
method, however this is fairly obscure and it would probably be better to 
invoke removal of the producer when it is removed from the shared pool.

Another issue of note is that when a route is shutdown that contains a 
SendProcessor due to the shutdown invocation on the SharedProcessorServicePool 
the global pool is cleared of `everything`.

h4. Impact

For general use where there is no dynamic creation or passivation of routes 
this issue should be minimal, however in our use case where the routes are not 
static, there is a certain amount of recreation of routes as customer endpoints 
change and there is a need to passivate idle routes this causes a considerable 
memory leak (via SFTP in particular).

h4. Test Case
{code}
package org.apache.camel.component;

import com.google.common.util.concurrent.AtomicLongMap;

import org.apache.camel.CamelContext;
import org.apache.camel.Consumer;
import org.apache.camel.Endpoint;
import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.apache.camel.Producer;
import org.apache.camel.Route;
import org.apache.camel.Service;
import org.apache.camel.ServicePoolAware;
import org.apache.camel.ServiceStatus;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.impl.DefaultComponent;
import org.apache.camel.impl.DefaultEndpoint;
import org.apache.camel.impl.DefaultProducer;
import org.apache.camel.support.LifecycleStrategySupport;
import org.apache.camel.support.ServiceSupport;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.Test;

import java.util.Map;

import static com.google.common.base.Preconditions.checkNotNull;

/**
 * Test memory behaviour of producers using {@link ServicePoolAware} when using 
JMX.
 */
public class ServicePoolAwareLeakyTest extends CamelTestSupport {

  private static final String LEAKY_SIEVE_STABLE = 
"leaky://sieve-stable?plugged=true";
  private static final String LEAKY_SIEVE_TRANSIENT = 
"leaky://sieve-transient?plugged=true";


  private static boolean isPatchApplied() {
return Boolean.parseBoolean(System.getProperty("patchApplied", "false"));
  }

  /**
   * Component that provides leaks producers.
   */
  private static class LeakySieveComponent extends DefaultComponent {
@Override
protected Endpoint createEndpoint(String uri, String remaining, Map parameters) throws Exception {
  boolean plugged = "true".equalsIgnoreCase((String) 
parameters.remove("plugged"));
  return new LeakySieveEndpoint(uri,