[jira] [Commented] (CAMEL-10804) Create a salesforce example
[ https://issues.apache.org/jira/browse/CAMEL-10804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857597#comment-15857597 ] Claus Ibsen commented on CAMEL-10804: - [~zregvart] I assume you can help with this > Create a salesforce example > --- > > Key: CAMEL-10804 > URL: https://issues.apache.org/jira/browse/CAMEL-10804 > Project: Camel > Issue Type: New Feature > Components: examples >Reporter: Claus Ibsen > Fix For: 2.19.0 > > > We need a little example about salesforce as its not so easy to get started > using. > There is a little start here > https://github.com/apache/camel/tree/master/examples/camel-example-twitter-salesforce -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10804) Create a salesforce example
Claus Ibsen created CAMEL-10804: --- Summary: Create a salesforce example Key: CAMEL-10804 URL: https://issues.apache.org/jira/browse/CAMEL-10804 Project: Camel Issue Type: New Feature Components: examples Reporter: Claus Ibsen Fix For: 2.19.0 We need a little example about salesforce as its not so easy to get started using. There is a little start here https://github.com/apache/camel/tree/master/examples/camel-example-twitter-salesforce -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10802) java.lang.ClassCastException when using FlexibleAggregationStrategy with Spring Boot
[
https://issues.apache.org/jira/browse/CAMEL-10802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857595#comment-15857595
]
Claus Ibsen commented on CAMEL-10802:
-
Can you try without spring boot. I would assume it wouldn't matter. And maybe
just create a plain junit test that can run standalone.
> java.lang.ClassCastException when using FlexibleAggregationStrategy with
> Spring Boot
>
>
> Key: CAMEL-10802
> URL: https://issues.apache.org/jira/browse/CAMEL-10802
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-spring-boot
>Affects Versions: 2.18.2
> Environment: Windows 10
> Camel 2.18.2
> Spring 4.3.6
> Spring Boot 1.5.1
>Reporter: Giovanni Condello
>
> We are having a strange issue while using the FlexibleAggregationStrategy
> with spring boot. Below is a sample and trivial route I just made up
> to demonstrate the issue:
> {code:java}
> from("direct:should-work")
> .id("should-work")
> .log(LoggingLevel.INFO, "Before the first split the
> body is ${body} and has class ${body.getClass()}")
> .split(body(),
> AggregationStrategies.flexible().pick(body()).accumulateInCollection(LinkedList.class))
> .log(LoggingLevel.INFO, "During the first split the
> body is ${body} and has class ${body.getClass()}")
> .end()
> .log(LoggingLevel.INFO, "Before the second split the
> body is ${body} and has class ${body.getClass()}")
> .split(body(),
> AggregationStrategies.flexible().pick(body()).accumulateInCollection(LinkedList.class))
> .log(LoggingLevel.INFO, "During the second split the
> body is ${body} and has class ${body.getClass()}")
> .end()
> .log(LoggingLevel.INFO, "After the second split the
> body is ${body} and has class ${body.getClass()}")
> {code}
> Along with the relevant unit test:
> {code:java}
>@Test
> public void shouldProduceMessages() throws InterruptedException {
> // we expect that a number of messages is automatic done by the Camel
> // route as it uses a timer to trigger
> NotifyBuilder notify = new
> NotifyBuilder(camelContext).whenDone(1).and().whenExactlyFailed(0).create();
> producerTemplateShouldWork.sendBody(Arrays.asList("FIRST", "SECOND"));
> assertTrue(notify.matches(10, TimeUnit.SECONDS));
> }
> {code}
> The test fails with the following unexpected exception:
> {code}
> java.lang.ClassCastException: Cannot cast java.util.LinkedHashSet to
> java.util.LinkedList
> at java.lang.Class.cast(Class.java:3369) ~[na:1.8.0_111]
> at
> org.apache.camel.util.toolbox.FlexibleAggregationStrategy.safeInsertIntoCollection(FlexibleAggregationStrategy.java:281)
> ~[camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.util.toolbox.FlexibleAggregationStrategy.injectAsCollection(FlexibleAggregationStrategy.java:264)
> ~[camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.util.toolbox.FlexibleAggregationStrategy.aggregate(FlexibleAggregationStrategy.java:235)
> ~[camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.processor.MulticastProcessor.doAggregateInternal(MulticastProcessor.java:942)
> ~[camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.processor.MulticastProcessor.doAggregate(MulticastProcessor.java:924)
> ~[camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.processor.MulticastProcessor.doProcessSequential(MulticastProcessor.java:644)
> ~[camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:238)
> ~[camel-core-2.18.2.jar:2.18.2]
> at org.apache.camel.processor.Splitter.process(Splitter.java:108)
> ~[camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)
> ~[camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:542)
> ~[camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> [camel-core-2.18.2.jar:2.18.2]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:120)
> [camel-core-2.18.2.jar:2.18.2]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:83)
> [camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> [camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:62)
> [camel-core-2.18.2.jar:2.18.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> [camel-core-2.18.2.jar:2.18.2]
> at
>
[jira] [Updated] (CAMEL-10791) Add an option in the ZipFileDataFormat to let the iterator support the empty directory
[ https://issues.apache.org/jira/browse/CAMEL-10791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-10791: Priority: Minor (was: Major) > Add an option in the ZipFileDataFormat to let the iterator support the empty > directory > --- > > Key: CAMEL-10791 > URL: https://issues.apache.org/jira/browse/CAMEL-10791 > Project: Camel > Issue Type: Improvement > Components: camel-zipfile >Affects Versions: 2.18.2 >Reporter: Uladzimir Zhuraulevich >Priority: Minor > > Would be great to have an option to ask camel-zipfile to catch empty folders > too. > http://camel.465427.n5.nabble.com/camel-zipfile-td5793495.html > Thanks. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10607) camel-cxf - Allow to call no-arg methods more easier
[ https://issues.apache.org/jira/browse/CAMEL-10607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856803#comment-15856803 ] ASF GitHub Bot commented on CAMEL-10607: GitHub user anoordover opened a pull request: https://github.com/apache/camel/pull/1451 CAMEL-10607 I think getParams should return empty array when body is null. This solves https://issues.apache.org/jira/browse/CAMEL-10607 You can merge this pull request into a Git repository by running: $ git pull https://github.com/anoordover/camel CAMEL-10607 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/1451.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 #1451 > camel-cxf - Allow to call no-arg methods more easier > > > Key: CAMEL-10607 > URL: https://issues.apache.org/jira/browse/CAMEL-10607 > Project: Camel > Issue Type: Improvement > Components: camel-cxf >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > See SO > http://stackoverflow.com/questions/41164377/calling-no-params-webservice-operation-from-camel-route-using-cxf > We could detect that it expect 0 parameters and then don't do any parameter > mappings so the service can be easily called. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10803) Base undertow component on http-common
[ https://issues.apache.org/jira/browse/CAMEL-10803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856443#comment-15856443 ] ASF GitHub Bot commented on CAMEL-10803: GitHub user zregvart opened a pull request: https://github.com/apache/camel/pull/1450 CAMEL-10803 Base undertow component on http-common # Please don't merge I would like some feedback on this first. Still to do: - [x] Make `UndertowComponent` and `UndertowEndpoint` extend `HttpCommonComponent` and `HttpCommonEndpoint` - [ ] Implement support for options from `http-common` component You can merge this pull request into a Git repository by running: $ git pull https://github.com/zregvart/camel CAMEL-10803 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/1450.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 #1450 > Base undertow component on http-common > -- > > Key: CAMEL-10803 > URL: https://issues.apache.org/jira/browse/CAMEL-10803 > Project: Camel > Issue Type: Improvement > Components: camel-undertow >Affects Versions: 2.19.0 >Reporter: Zoran Regvart >Assignee: Zoran Regvart > > To facilitate reuse, the Undertow component should be based on http-common > component. > The `UndertowComponent` should extend `HttpCommonComponent` and > `UndertowEndpoint` should extend `HttpCommonEndpoint`. > Following that options defined in the http-common component should be also > supported in the Undertow component. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CAMEL-10779) Authentication : provide a way to use refresh_token mode in addition to password method
[
https://issues.apache.org/jira/browse/CAMEL-10779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mabrouk Belhout closed CAMEL-10779.
---
PR provided and merged into 2.19.0
> Authentication : provide a way to use refresh_token mode in addition to
> password method
> ---
>
> Key: CAMEL-10779
> URL: https://issues.apache.org/jira/browse/CAMEL-10779
> Project: Camel
> Issue Type: Improvement
> Components: camel-salesforce
>Reporter: Mabrouk Belhout
>Assignee: Zoran Regvart
>Priority: Minor
> Labels: authentication, oauth2
> Fix For: 2.19.0
>
>
> We had to connect to a Salesforce partner instance. Our partner did not
> provide login/password but instead a clientid clientsecret and refreshtoken.
> Today in camel-salesforce component, authentication is forced to be
> login/password based.
> This improvement should provide an alternative using refresh_token method of
> oauth.
> Objective is to enrich the
> _SalesforceSession.getLoginRequest(HttpConversation)_ method and add
> {{fields.put("grant_type", "refresh_token");}}
> as an alternative to
> {{fields.put("grant_type", "password");}}
> this has impacts on _SalesforceLoginConfig_ class and other authentication
> involved classes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CAMEL-10791) Add an option in the ZipFileDataFormat to let the iterator support the empty directory
[ https://issues.apache.org/jira/browse/CAMEL-10791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-10791: Estimated Complexity: Novice (was: Unknown) > Add an option in the ZipFileDataFormat to let the iterator support the empty > directory > --- > > Key: CAMEL-10791 > URL: https://issues.apache.org/jira/browse/CAMEL-10791 > Project: Camel > Issue Type: Improvement > Components: camel-zipfile >Affects Versions: 2.18.2 >Reporter: Uladzimir Zhuraulevich > > Would be great to have an option to ask camel-zipfile to catch empty folders > too. > http://camel.465427.n5.nabble.com/camel-zipfile-td5793495.html > Thanks. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10803) Base undertow component on http-common
Zoran Regvart created CAMEL-10803: - Summary: Base undertow component on http-common Key: CAMEL-10803 URL: https://issues.apache.org/jira/browse/CAMEL-10803 Project: Camel Issue Type: Improvement Components: camel-undertow Affects Versions: 2.19.0 Reporter: Zoran Regvart Assignee: Zoran Regvart To facilitate reuse, the Undertow component should be based on http-common component. The `UndertowComponent` should extend `HttpCommonComponent` and `UndertowEndpoint` should extend `HttpCommonEndpoint`. Following that options defined in the http-common component should be also supported in the Undertow component. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CAMEL-10756) Mina2 Producer "hang" until timeout if the response message could not be decoded
[
https://issues.apache.org/jira/browse/CAMEL-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-10756.
-
Resolution: Fixed
Assignee: Claus Ibsen
Fix Version/s: 2.19.0
2.18.3
2.17.6
Thanks for the PR
> Mina2 Producer "hang" until timeout if the response message could not be
> decoded
>
>
> Key: CAMEL-10756
> URL: https://issues.apache.org/jira/browse/CAMEL-10756
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.18.1
>Reporter: Thomas Papke
>Assignee: Claus Ibsen
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
> Attachments: camel_mina2.patch
>
>
> I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
> camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
> *The scenario which fail:*
> A Mina2 producer send a request to a server, the server provide a response
> which could not be interpreted/decoded by a custom codec on the producer side
> (e.g. due to invalid encoding).
> *Expected behavior:*
> * The Exception from the decoder on the producer side will be directly
> propogated to the caller. The mina2 session will be closed.
> *Current behavior:*
> * Instead of the exception from the decoder, the producer wait until the
> timeout is reached and the caller get a timeout exception after the timeout
> is reached.
> *First analysis:*
> I have attached a patch for the camel-mina2 module which contain a test
> {{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
> to reproduce this issue.
> *If i revert the changes done within CAMEL-10024, the test run correct.* If I
> debug into the new code, i see that the producer "hang" in
> {{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
> {{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced
> with CAML-10024.
> I could not yet provide a fix as well, since I don't really understand the
> details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CAMEL-10756) Mina2 Producer "hang" until timeout if the response message could not be decoded
[
https://issues.apache.org/jira/browse/CAMEL-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856396#comment-15856396
]
ASF GitHub Bot commented on CAMEL-10756:
Github user asfgit closed the pull request at:
https://github.com/apache/camel/pull/1449
> Mina2 Producer "hang" until timeout if the response message could not be
> decoded
>
>
> Key: CAMEL-10756
> URL: https://issues.apache.org/jira/browse/CAMEL-10756
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.18.1
>Reporter: Thomas Papke
> Attachments: camel_mina2.patch
>
>
> I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
> camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
> *The scenario which fail:*
> A Mina2 producer send a request to a server, the server provide a response
> which could not be interpreted/decoded by a custom codec on the producer side
> (e.g. due to invalid encoding).
> *Expected behavior:*
> * The Exception from the decoder on the producer side will be directly
> propogated to the caller. The mina2 session will be closed.
> *Current behavior:*
> * Instead of the exception from the decoder, the producer wait until the
> timeout is reached and the caller get a timeout exception after the timeout
> is reached.
> *First analysis:*
> I have attached a patch for the camel-mina2 module which contain a test
> {{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
> to reproduce this issue.
> *If i revert the changes done within CAMEL-10024, the test run correct.* If I
> debug into the new code, i see that the producer "hang" in
> {{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
> {{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced
> with CAML-10024.
> I could not yet provide a fix as well, since I don't really understand the
> details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CAMEL-10779) Authentication : provide a way to use refresh_token mode in addition to password method
[
https://issues.apache.org/jira/browse/CAMEL-10779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-10779.
-
Resolution: Fixed
Assignee: Zoran Regvart
Thanks for the PR
> Authentication : provide a way to use refresh_token mode in addition to
> password method
> ---
>
> Key: CAMEL-10779
> URL: https://issues.apache.org/jira/browse/CAMEL-10779
> Project: Camel
> Issue Type: Improvement
> Components: camel-salesforce
>Reporter: Mabrouk Belhout
>Assignee: Zoran Regvart
>Priority: Minor
> Labels: authentication, oauth2
> Fix For: 2.19.0
>
>
> We had to connect to a Salesforce partner instance. Our partner did not
> provide login/password but instead a clientid clientsecret and refreshtoken.
> Today in camel-salesforce component, authentication is forced to be
> login/password based.
> This improvement should provide an alternative using refresh_token method of
> oauth.
> Objective is to enrich the
> _SalesforceSession.getLoginRequest(HttpConversation)_ method and add
> {{fields.put("grant_type", "refresh_token");}}
> as an alternative to
> {{fields.put("grant_type", "password");}}
> this has impacts on _SalesforceLoginConfig_ class and other authentication
> involved classes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CAMEL-10779) Authentication : provide a way to use refresh_token mode in addition to password method
[
https://issues.apache.org/jira/browse/CAMEL-10779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-10779:
Fix Version/s: 2.19.0
> Authentication : provide a way to use refresh_token mode in addition to
> password method
> ---
>
> Key: CAMEL-10779
> URL: https://issues.apache.org/jira/browse/CAMEL-10779
> Project: Camel
> Issue Type: Improvement
> Components: camel-salesforce
>Reporter: Mabrouk Belhout
>Priority: Minor
> Labels: authentication, oauth2
> Fix For: 2.19.0
>
>
> We had to connect to a Salesforce partner instance. Our partner did not
> provide login/password but instead a clientid clientsecret and refreshtoken.
> Today in camel-salesforce component, authentication is forced to be
> login/password based.
> This improvement should provide an alternative using refresh_token method of
> oauth.
> Objective is to enrich the
> _SalesforceSession.getLoginRequest(HttpConversation)_ method and add
> {{fields.put("grant_type", "refresh_token");}}
> as an alternative to
> {{fields.put("grant_type", "password");}}
> this has impacts on _SalesforceLoginConfig_ class and other authentication
> involved classes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CAMEL-10800) camel-connector - Allow to generate json schema and include it in source code
[ https://issues.apache.org/jira/browse/CAMEL-10800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-10800. - Resolution: Fixed > camel-connector - Allow to generate json schema and include it in source code > - > > Key: CAMEL-10800 > URL: https://issues.apache.org/jira/browse/CAMEL-10800 > Project: Camel > Issue Type: Improvement > Components: camel-connector >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.19.0 > > > So the camel-connector-plugin can generate the json schema file to be > included in the source code you check in git along side camel-connector.json > so you have all the details at your finger tips. > Its the files camel-connector-schema.json and camel-component-schema.json > which currently are built in the target/classes folder. We can make the built > into src/main/resources so they are more visible to the developers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10802) java.lang.ClassCastException when using FlexibleAggregationStrategy with Spring Boot
Giovanni Condello created CAMEL-10802:
-
Summary: java.lang.ClassCastException when using
FlexibleAggregationStrategy with Spring Boot
Key: CAMEL-10802
URL: https://issues.apache.org/jira/browse/CAMEL-10802
Project: Camel
Issue Type: Bug
Components: camel-core, camel-spring-boot
Affects Versions: 2.18.2
Environment: Windows 10
Camel 2.18.2
Spring 4.3.6
Spring Boot 1.5.1
Reporter: Giovanni Condello
We are having a strange issue while using the FlexibleAggregationStrategy
with spring boot. Below is a sample and trivial route I just made up
to demonstrate the issue:
{code:java}
from("direct:should-work")
.id("should-work")
.log(LoggingLevel.INFO, "Before the first split the
body is ${body} and has class ${body.getClass()}")
.split(body(),
AggregationStrategies.flexible().pick(body()).accumulateInCollection(LinkedList.class))
.log(LoggingLevel.INFO, "During the first split the
body is ${body} and has class ${body.getClass()}")
.end()
.log(LoggingLevel.INFO, "Before the second split the
body is ${body} and has class ${body.getClass()}")
.split(body(),
AggregationStrategies.flexible().pick(body()).accumulateInCollection(LinkedList.class))
.log(LoggingLevel.INFO, "During the second split the
body is ${body} and has class ${body.getClass()}")
.end()
.log(LoggingLevel.INFO, "After the second split the
body is ${body} and has class ${body.getClass()}")
{code}
Along with the relevant unit test:
{code:java}
@Test
public void shouldProduceMessages() throws InterruptedException {
// we expect that a number of messages is automatic done by the Camel
// route as it uses a timer to trigger
NotifyBuilder notify = new
NotifyBuilder(camelContext).whenDone(1).and().whenExactlyFailed(0).create();
producerTemplateShouldWork.sendBody(Arrays.asList("FIRST", "SECOND"));
assertTrue(notify.matches(10, TimeUnit.SECONDS));
}
{code}
The test fails with the following unexpected exception:
{code}
java.lang.ClassCastException: Cannot cast java.util.LinkedHashSet to
java.util.LinkedList
at java.lang.Class.cast(Class.java:3369) ~[na:1.8.0_111]
at
org.apache.camel.util.toolbox.FlexibleAggregationStrategy.safeInsertIntoCollection(FlexibleAggregationStrategy.java:281)
~[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.util.toolbox.FlexibleAggregationStrategy.injectAsCollection(FlexibleAggregationStrategy.java:264)
~[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.util.toolbox.FlexibleAggregationStrategy.aggregate(FlexibleAggregationStrategy.java:235)
~[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.processor.MulticastProcessor.doAggregateInternal(MulticastProcessor.java:942)
~[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.processor.MulticastProcessor.doAggregate(MulticastProcessor.java:924)
~[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.processor.MulticastProcessor.doProcessSequential(MulticastProcessor.java:644)
~[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:238)
~[camel-core-2.18.2.jar:2.18.2]
at org.apache.camel.processor.Splitter.process(Splitter.java:108)
~[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)
~[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:542)
~[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
[camel-core-2.18.2.jar:2.18.2]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:120)
[camel-core-2.18.2.jar:2.18.2]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:83)
[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:62)
[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
[camel-core-2.18.2.jar:2.18.2]
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:97)
[camel-core-2.18.2.jar:2.18.2]
at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:529)
[camel-core-2.18.2.jar:2.18.2]
at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:497)
[camel-core-2.18.2.jar:2.18.2]
at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:365)
[camel-core-2.18.2.jar:2.18.2]
at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:497)
[camel-core-2.18.2.jar:2.18.2]
at
[jira] [Resolved] (CAMEL-10801) ServiceCall : add the option to force the service call to use the default load balancer
[ https://issues.apache.org/jira/browse/CAMEL-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-10801. - Resolution: Fixed > ServiceCall : add the option to force the service call to use the default > load balancer > --- > > Key: CAMEL-10801 > URL: https://issues.apache.org/jira/browse/CAMEL-10801 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 2.19.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10801) ServiceCall : add the option to force the service call to use the default load balancer
Luca Burgazzoli created CAMEL-10801: --- Summary: ServiceCall : add the option to force the service call to use the default load balancer Key: CAMEL-10801 URL: https://issues.apache.org/jira/browse/CAMEL-10801 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Luca Burgazzoli Assignee: Luca Burgazzoli Priority: Minor Fix For: 2.19.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10800) camel-connector - Allow to generate json schema and include it in source code
Claus Ibsen created CAMEL-10800: --- Summary: camel-connector - Allow to generate json schema and include it in source code Key: CAMEL-10800 URL: https://issues.apache.org/jira/browse/CAMEL-10800 Project: Camel Issue Type: Improvement Components: camel-connector Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.19.0 So the camel-connector-plugin can generate the json schema file to be included in the source code you check in git along side camel-connector.json so you have all the details at your finger tips. Its the files camel-connector-schema.json and camel-component-schema.json which currently are built in the target/classes folder. We can make the built into src/main/resources so they are more visible to the developers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CAMEL-10796) camel-example-spring-boot - Remove shell
[ https://issues.apache.org/jira/browse/CAMEL-10796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-10796. - Resolution: Fixed > camel-example-spring-boot - Remove shell > > > Key: CAMEL-10796 > URL: https://issues.apache.org/jira/browse/CAMEL-10796 > Project: Camel > Issue Type: Task > Components: examples >Reporter: Claus Ibsen >Assignee: Luca Burgazzoli > Fix For: 2.19.0 > > > spring-boot shell / commands is deprecated and we should remove this from > this example > https://github.com/apache/camel/tree/master/examples/camel-example-spring-boot -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (CAMEL-10796) camel-example-spring-boot - Remove shell
[ https://issues.apache.org/jira/browse/CAMEL-10796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-10796: --- Assignee: Luca Burgazzoli > camel-example-spring-boot - Remove shell > > > Key: CAMEL-10796 > URL: https://issues.apache.org/jira/browse/CAMEL-10796 > Project: Camel > Issue Type: Task > Components: examples >Reporter: Claus Ibsen >Assignee: Luca Burgazzoli > Fix For: 2.19.0 > > > spring-boot shell / commands is deprecated and we should remove this from > this example > https://github.com/apache/camel/tree/master/examples/camel-example-spring-boot -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10799) camel-connector - Generate spring boot auto configuration
Claus Ibsen created CAMEL-10799: --- Summary: camel-connector - Generate spring boot auto configuration Key: CAMEL-10799 URL: https://issues.apache.org/jira/browse/CAMEL-10799 Project: Camel Issue Type: Improvement Components: camel-connector Reporter: Claus Ibsen Fix For: Future We could make the camel-connector-plugin be able to generate spring boot autoconfiguration as well, just like regular components. But mind that a connector is a facade on top of a component so there is already the spring boot auto configuration on the components, eg twitter, salesforce etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CAMEL-10797) Create endpoint from uri without context-path
[ https://issues.apache.org/jira/browse/CAMEL-10797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-10797. - Resolution: Fixed > Create endpoint from uri without context-path > - > > Key: CAMEL-10797 > URL: https://issues.apache.org/jira/browse/CAMEL-10797 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.19.0 > > > Most of the Camel endpoint uris are configured as a > scheme:context-path?options where the uri has some values in the > context-path, eg log:foo, direct:bar, file:inbox, etc. > However in some rare cases you can use an endpoint without any context-path > and only with query parameters, this is currently not supported in Camel. > To workaround this people have sometimes used mycomponent:dummy. However we > can support uris with just mycomponent or mycomponent?foo=123 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CAMEL-10798) camel-twitter, camel-ignite - Make the uri endpoints separated
[ https://issues.apache.org/jira/browse/CAMEL-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-10798: Fix Version/s: 2.19.0 > camel-twitter, camel-ignite - Make the uri endpoints separated > -- > > Key: CAMEL-10798 > URL: https://issues.apache.org/jira/browse/CAMEL-10798 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen > Fix For: 2.19.0, 3.0.0 > > > They currently have the same @UriEndpoint that represents all of their > possible endpoint combinations. This usually works fine for Camel components. > But some components such as twitter, ignite, hazelcast etc do have to many > different endpoints that have very specific options per different endpoint. > We should split up this in different components so they are separated. > So we have > twitter-status > twitter-search > twitter-direct > Or something. > This will also help tooling, documentation, et all so they are clearly > separated and there are no confusion. For example twitter mention do not > support the delay option which only twitter search uses etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10798) camel-twitter, camel-ignite - Make the uri endpoints separated
[ https://issues.apache.org/jira/browse/CAMEL-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855857#comment-15855857 ] Claus Ibsen commented on CAMEL-10798: - We may consider this for 2.19 to make this sooner, and we can have a way of supporting old uri syntaxes and make it log WARN so people have time to migrate. > camel-twitter, camel-ignite - Make the uri endpoints separated > -- > > Key: CAMEL-10798 > URL: https://issues.apache.org/jira/browse/CAMEL-10798 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen > Fix For: 2.19.0, 3.0.0 > > > They currently have the same @UriEndpoint that represents all of their > possible endpoint combinations. This usually works fine for Camel components. > But some components such as twitter, ignite, hazelcast etc do have to many > different endpoints that have very specific options per different endpoint. > We should split up this in different components so they are separated. > So we have > twitter-status > twitter-search > twitter-direct > Or something. > This will also help tooling, documentation, et all so they are clearly > separated and there are no confusion. For example twitter mention do not > support the delay option which only twitter search uses etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CAMEL-10798) camel-twitter, camel-ignite - Make the uri endpoints separated
[ https://issues.apache.org/jira/browse/CAMEL-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-10798: Fix Version/s: 3.0.0 > camel-twitter, camel-ignite - Make the uri endpoints separated > -- > > Key: CAMEL-10798 > URL: https://issues.apache.org/jira/browse/CAMEL-10798 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen > Fix For: 3.0.0 > > > They currently have the same @UriEndpoint that represents all of their > possible endpoint combinations. This usually works fine for Camel components. > But some components such as twitter, ignite, hazelcast etc do have to many > different endpoints that have very specific options per different endpoint. > We should split up this in different components so they are separated. > So we have > twitter-status > twitter-search > twitter-direct > Or something. > This will also help tooling, documentation, et all so they are clearly > separated and there are no confusion. For example twitter mention do not > support the delay option which only twitter search uses etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10798) camel-twitter, camel-ignite - Make the uri endpoints separated
Claus Ibsen created CAMEL-10798: --- Summary: camel-twitter, camel-ignite - Make the uri endpoints separated Key: CAMEL-10798 URL: https://issues.apache.org/jira/browse/CAMEL-10798 Project: Camel Issue Type: Improvement Reporter: Claus Ibsen They currently have the same @UriEndpoint that represents all of their possible endpoint combinations. This usually works fine for Camel components. But some components such as twitter, ignite, hazelcast etc do have to many different endpoints that have very specific options per different endpoint. We should split up this in different components so they are separated. So we have twitter-status twitter-search twitter-direct Or something. This will also help tooling, documentation, et all so they are clearly separated and there are no confusion. For example twitter mention do not support the delay option which only twitter search uses etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10797) Create endpoint from uri without context-path
Claus Ibsen created CAMEL-10797: --- Summary: Create endpoint from uri without context-path Key: CAMEL-10797 URL: https://issues.apache.org/jira/browse/CAMEL-10797 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.19.0 Most of the Camel endpoint uris are configured as a scheme:context-path?options where the uri has some values in the context-path, eg log:foo, direct:bar, file:inbox, etc. However in some rare cases you can use an endpoint without any context-path and only with query parameters, this is currently not supported in Camel. To workaround this people have sometimes used mycomponent:dummy. However we can support uris with just mycomponent or mycomponent?foo=123 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10795) PingCheck API
[
https://issues.apache.org/jira/browse/CAMEL-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855673#comment-15855673
]
Claus Ibsen commented on CAMEL-10795:
-
Yes no route is required.
This helps with tooling and also allows us to have detains in the documentation
which options is used to configure the connection details so the component can
connect. Today you have a lot of options and it may not always be so easy to
see which of these I must use to configure that stuff.
We can consider adding some kind of label="ping" or whatever to the UriParams
etc so they stand out in the docs.
For more complex stuff like SSL we can cross that bridge a bit later. They are
frankly a bit harder to configure with the SSLContext and if you need keystores
and certificates and all that jazz.
However for many SaaS components and the likes, then API tokens etc are maybe
more what they use.
> PingCheck API
> -
>
> Key: CAMEL-10795
> URL: https://issues.apache.org/jira/browse/CAMEL-10795
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Claus Ibsen
> Fix For: 2.19.0
>
>
> Related to CAMEL-10026 about Health Check API
> We need some way for Camel components to be able to more easily validate if
> they can connect to their remote system.
> And for that the user must configure the Camel component/endpoint accordingly
> with details such as username/password/tokens/ other beans etc.
> How this is done varies from Camel component to component, but most of them
> uses endpoint options.
> So we may want to introduce some interface (whether the name Pingable is a
> good name is up for discussion)
> {code}
> interface Pingable {
> PingResult ping(Map config);
> boolean canPing(Map config);
> }
> class PingResult {
> private boolean isSuccess();
> private String errorMessage();
> }
> {code}
> This API is just a little suggestion.
> The parameters should ideally be type less, eg Map as the
> user configures this in endpoint uris, XML DSL etc. and therefore we should
> be able to do this without having to use Java code per see.
> Also we may want to have canPing as a method to check if the component can
> accept the ping or not. In some cases it may not be able to do the ping.
> For example camel-http component would just require the following information
> in the Map
> httpUri=http://myserver/foo/bar
> Where httpUri is the name of the option accordingly to the table at
> https://github.com/apache/camel/blob/master/components/camel-http/src/main/docs/http-component.adoc
> And then it depends on each Camel component how they do the ping check, the
> http component may do a HTTP HEAD or a HTTP GET etc and check the HTTP
> response code etc.
> Notice this is not intended entirely for runtime health check, but for
> validating/testing Camel components can work with the user given
> configuration to connect to the remote system.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CAMEL-10795) PingCheck API
[
https://issues.apache.org/jira/browse/CAMEL-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855660#comment-15855660
]
Luca Burgazzoli commented on CAMEL-10795:
-
This validation does not requires any route and so on, like spinning up a new
camel context and ask a component to validate the options correct ?
In that case should we expect the camel context to be have the registry set-up
or we should grab all the stuffs from the given map ? I'm thinking about i.e
ssl context parameters which is usually taken from the registry and should be
there when a connection attempt is made.
> PingCheck API
> -
>
> Key: CAMEL-10795
> URL: https://issues.apache.org/jira/browse/CAMEL-10795
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Claus Ibsen
> Fix For: 2.19.0
>
>
> Related to CAMEL-10026 about Health Check API
> We need some way for Camel components to be able to more easily validate if
> they can connect to their remote system.
> And for that the user must configure the Camel component/endpoint accordingly
> with details such as username/password/tokens/ other beans etc.
> How this is done varies from Camel component to component, but most of them
> uses endpoint options.
> So we may want to introduce some interface (whether the name Pingable is a
> good name is up for discussion)
> {code}
> interface Pingable {
> PingResult ping(Map config);
> boolean canPing(Map config);
> }
> class PingResult {
> private boolean isSuccess();
> private String errorMessage();
> }
> {code}
> This API is just a little suggestion.
> The parameters should ideally be type less, eg Map as the
> user configures this in endpoint uris, XML DSL etc. and therefore we should
> be able to do this without having to use Java code per see.
> Also we may want to have canPing as a method to check if the component can
> accept the ping or not. In some cases it may not be able to do the ping.
> For example camel-http component would just require the following information
> in the Map
> httpUri=http://myserver/foo/bar
> Where httpUri is the name of the option accordingly to the table at
> https://github.com/apache/camel/blob/master/components/camel-http/src/main/docs/http-component.adoc
> And then it depends on each Camel component how they do the ping check, the
> http component may do a HTTP HEAD or a HTTP GET etc and check the HTTP
> response code etc.
> Notice this is not intended entirely for runtime health check, but for
> validating/testing Camel components can work with the user given
> configuration to connect to the remote system.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CAMEL-10796) camel-example-spring-boot - Remove shell
Claus Ibsen created CAMEL-10796: --- Summary: camel-example-spring-boot - Remove shell Key: CAMEL-10796 URL: https://issues.apache.org/jira/browse/CAMEL-10796 Project: Camel Issue Type: Task Components: examples Reporter: Claus Ibsen Fix For: 2.19.0 spring-boot shell / commands is deprecated and we should remove this from this example https://github.com/apache/camel/tree/master/examples/camel-example-spring-boot -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10026) HealthCheck API
[ https://issues.apache.org/jira/browse/CAMEL-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855581#comment-15855581 ] Claus Ibsen commented on CAMEL-10026: - I have created CAMEL-10795 which is related to this and should be the first task we get started with. > HealthCheck API > --- > > Key: CAMEL-10026 > URL: https://issues.apache.org/jira/browse/CAMEL-10026 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen > Fix For: 2.19.0 > > > Add a health check API to camel-core so this API can be queried from Java / > JMX / spring-boot etc. so users can easily get a health check. This can be > used for liveness/readiness checks for their Camel apps. > The API should allow optional support for components to implement custom > logic for health check. So a FTP component can connect to a FTP server and do > a FTP list etc. A JDBC component does a SQL query, and so on. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10795) PingCheck API
Claus Ibsen created CAMEL-10795:
---
Summary: PingCheck API
Key: CAMEL-10795
URL: https://issues.apache.org/jira/browse/CAMEL-10795
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Claus Ibsen
Fix For: 2.19.0
Related to CAMEL-10026 about Health Check API
We need some way for Camel components to be able to more easily validate if
they can connect to their remote system.
And for that the user must configure the Camel component/endpoint accordingly
with details such as username/password/tokens/ other beans etc.
How this is done varies from Camel component to component, but most of them
uses endpoint options.
So we may want to introduce some interface (whether the name Pingable is a good
name is up for discussion)
{code}
interface Pingable {
PingResult ping(Map config);
boolean canPing(Map config);
}
class PingResult {
private boolean isSuccess();
private String errorMessage();
}
{code}
This API is just a little suggestion.
The parameters should ideally be type less, eg Map as the user
configures this in endpoint uris, XML DSL etc. and therefore we should be able
to do this without having to use Java code per see.
Also we may want to have canPing as a method to check if the component can
accept the ping or not. In some cases it may not be able to do the ping.
For example camel-http component would just require the following information
in the Map
httpUri=http://myserver/foo/bar
Where httpUri is the name of the option accordingly to the table at
https://github.com/apache/camel/blob/master/components/camel-http/src/main/docs/http-component.adoc
And then it depends on each Camel component how they do the ping check, the
http component may do a HTTP HEAD or a HTTP GET etc and check the HTTP response
code etc.
Notice this is not intended entirely for runtime health check, but for
validating/testing Camel components can work with the user given configuration
to connect to the remote system.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CAMEL-6289) camel-example-loan-broker - The broker example should use broker.xml file to setup broker
[ https://issues.apache.org/jira/browse/CAMEL-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855562#comment-15855562 ] Claus Ibsen commented on CAMEL-6289: Thanks, we will get them into the next release. Any of the Camel committers if you get the time then take a look at this and get this merged into the codebase. > camel-example-loan-broker - The broker example should use broker.xml file to > setup broker > - > > Key: CAMEL-6289 > URL: https://issues.apache.org/jira/browse/CAMEL-6289 > Project: Camel > Issue Type: Improvement > Components: examples >Affects Versions: 2.11.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: 2.19.0 > > Attachments: CAMEL.6289.NEW.patch, CAMEL-6289.patch > > > We should use the broker.xml file to setup the AMQ broker like we do with the > management example. > Then we can have a better stopping order of AMQ + Camel. So we may not get > the noise logs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CAMEL-6289) camel-example-loan-broker - The broker example should use broker.xml file to setup broker
[ https://issues.apache.org/jira/browse/CAMEL-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6289: --- Fix Version/s: (was: Future) 2.19.0 > camel-example-loan-broker - The broker example should use broker.xml file to > setup broker > - > > Key: CAMEL-6289 > URL: https://issues.apache.org/jira/browse/CAMEL-6289 > Project: Camel > Issue Type: Improvement > Components: examples >Affects Versions: 2.11.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: 2.19.0 > > Attachments: CAMEL.6289.NEW.patch, CAMEL-6289.patch > > > We should use the broker.xml file to setup the AMQ broker like we do with the > management example. > Then we can have a better stopping order of AMQ + Camel. So we may not get > the noise logs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CAMEL-10782) SFTP: cannot get files from users home with readlock changed
[ https://issues.apache.org/jira/browse/CAMEL-10782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Roos updated CAMEL-10782: Attachment: camel_2.18.2_sftp_problem_with_homedir Added full trace log from camel 2.18.2 session with similar incident. Notice how list file count changes after camel goes to sleeping (from 10 files to 23). > SFTP: cannot get files from users home with readlock changed > > > Key: CAMEL-10782 > URL: https://issues.apache.org/jira/browse/CAMEL-10782 > Project: Camel > Issue Type: Bug > Components: camel-ftp >Affects Versions: 2.16.4 > Environment: servicemix 7.0.0, Linux SFTP server >Reporter: Stefan Roos >Priority: Minor > Attachments: camel_2.18.2_sftp_problem_with_homedir > > > Camel cannot fetch files from users home directory when using > readlock=changed. > Route from URI is defined like this: > uri="sftp://testi@server:22?password=passwordinclude=PSOP_123-.*\.(xml|pdf)delete=truereadLock=changedreadLockTimeout=36readLockCheckInterval=18readLockMinAge=10smaxMessagesPerPoll=100"/> > And from TRACE logs I can see stuff like this: > 2017-02-03 10:59:45,146 | TRACE | //testi@infra:22 | > ChangedExclusiveReadLockStrategy | 225 - org.apache.camel.camel-ftp - 2.16.4 > | Using full directory listing to update file information for > RemoteFile[PSOP_123-sdfsd.xml]. Consider enabling fastExistsCheck option. > 2017-02-03 10:59:45,146 | TRACE | //testi@infra:22 | SftpOperations > | 225 - org.apache.camel.camel-ftp - 2.16.4 | listFiles(/) > 2017-02-03 10:59:45,150 | TRACE | //testi@infra:22 | > ChangedExclusiveReadLockStrategy | 225 - org.apache.camel.camel-ftp - 2.16.4 > | List files PSOP_123-sdfsd.xml found 23 files > 2017-02-03 10:59:45,150 | TRACE | //testi@infra:22 | > ChangedExclusiveReadLockStrategy | 225 - org.apache.camel.camel-ftp - 2.16.4 > | Previous last modified: 0, new last modified: 0 > 2017-02-03 10:59:45,150 | TRACE | //testi@infra:22 | > ChangedExclusiveReadLockStrategy | 225 - org.apache.camel.camel-ftp - 2.16.4 > | Previous length: 0, new length: 0 > 2017-02-03 10:59:45,150 | TRACE | //testi@infra:22 | > ChangedExclusiveReadLockStrategy | 225 - org.apache.camel.camel-ftp - 2.16.4 > | New older than threshold: 1486112375150 > 2017-02-03 10:59:45,150 | TRACE | //testi@infra:22 | > ChangedExclusiveReadLockStrategy | 225 - org.apache.camel.camel-ftp - 2.16.4 > | Exclusive read lock not granted. Sleeping for 2 millis. > User home directory contains only 1 file, which does match to include > parameter. It does seem, that camel-ftp is trying to check file readlock from > the server root. > When placing the files to a subdirectory in users home, this does not happen. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
