[jira] [Updated] (CAMEL-16393) camel-jsonpath - results from $.concat(...) seems to be cached on following calls
[
https://issues.apache.org/jira/browse/CAMEL-16393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16393:
Summary: camel-jsonpath - results from $.concat(...) seems to be cached on
following calls (was: results from $.concat(...) seems to be cached on
following calls)
> camel-jsonpath - results from $.concat(...) seems to be cached on following
> calls
> -
>
> Key: CAMEL-16393
> URL: https://issues.apache.org/jira/browse/CAMEL-16393
> Project: Camel
> Issue Type: Bug
> Components: camel-jsonpath
>Affects Versions: 2.25.3
>Reporter: Stefano Linguerri
>Priority: Major
> Fix For: 2.25.4, 3.4.6, 3.7.4, 3.10.0
>
> Attachments: jsonpath-issue.zip
>
>
> The first result from $.concat(...) seems to be "cached"
> Eg, given json:
> {{{"payload": \{"id": 1, "first_name": "Marie", "last_name": "Rose" } }}}
> The expression:
> {{jsonpath("$.concat($.payload.first_name,\" \",$.payload.last_name)")}}
> Will always returns _Marie Rose_ on following calls with different values in
> the input json.
> Please find attached reproducer maven project with junit test.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-16370) Camel Salesforce component unable to reconnect after disconnect from Salesforce
[
https://issues.apache.org/jira/browse/CAMEL-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307407#comment-17307407
]
Jason commented on CAMEL-16370:
---
Yes, that is correct.
> Camel Salesforce component unable to reconnect after disconnect from
> Salesforce
> ---
>
> Key: CAMEL-16370
> URL: https://issues.apache.org/jira/browse/CAMEL-16370
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 3.8.0
> Environment: Running in a spring-boot (v2.1.18.RELEASE) app in a
> linux container deployed to openshift 3.11
>Reporter: Jason
>Priority: Major
> Fix For: 3.x
>
>
> We are consuming Salesforce platform-events following the documented
> recommendations and our connection will not reconnect after being
> disconnected, apparently, from Salesforce. I am not quite certain as to the
> circumstances that Salesforce sends some sort of disconnect signal, but that
> is what's logged from the SubscriptionHelper class. Our initial connection to
> Salesforce is successful and we are able to receive platform-events up until
> the point of the spontaneous disconnection. Re-connection fails consistently
> and always in the same way. Logging is slightly different across version,
> but the behavior seems to always be the same.
> Our only work around for this is to run our service consuming this message
> like a cron job and restart it every 15 minutes (period we settled on through
> experimentation). This is not how we'd prefer to sun this service, it's
> quite hacky and we'd like to not have to force a restart to work around what
> appears to an issue with how the reconnect is handled.
>
> Here is the stacktrace:
> [DEBUG] 2021-03-17 13:30:48,513
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=21,
> successful=true}][DEBUG] 2021-03-17 13:30:48,513
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=21,
> successful=true}[DEBUG] 2021-03-17 13:32:38,588
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=22,
> successful=true}][DEBUG] 2021-03-17 13:32:38,589
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=22,
> successful=true}[DEBUG] 2021-03-17 13:34:28,665
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=23,
> successful=true}][DEBUG] 2021-03-17 13:34:28,666
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=23,
> successful=true}[DEBUG] 2021-03-17 13:34:28,766
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-32 ] - Received messages
> [{channel=/meta/disconnect}, {clientId=[redacted],
> advice={reconnect=none, interval=0}, channel=/meta/connect, id=24,
> error=401::Authentication invalid, successful=false}][INFO ] 2021-03-17
> 13:34:28,769
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-26 ] - Restarting on unexpected disconnect
> from Salesforce...[DEBUG] 2021-03-17 13:34:28,769
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-26 ] - Waiting to disconnect...[DEBUG]
> 2021-03-17 13:34:28,770
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-32 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], advice={reconnect=none, interval=0},
> channel=/meta/connect, id=24, error=401::Authentication invalid,
> successful=false}[WARN ] 2021-03-17 13:34:28,771
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-32 ] - Connect failure:
> {clientId=[redacted], advice={reconnect=none, interval=0},
> channel=/meta/connect, id=24, error=401::Authentication invalid,
> successful=false}[DEBUG] 2021-03-17 13:34:33,769
>
[jira] [Commented] (CAMEL-13092) Gzipping HTTP response prevents writing chunked output
[
https://issues.apache.org/jira/browse/CAMEL-13092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307292#comment-17307292
]
Claus Ibsen commented on CAMEL-13092:
-
When in gzip mode then it seems its currently hardcoded to be non chunked in
the doWriteGZIPResponse method
if (LOG.isDebugEnabled()) {
LOG.debug("Streaming response as GZIP in non-chunked mode with
content-length {} and buffer size: {}", data.length, response.getBufferSize());
}
> Gzipping HTTP response prevents writing chunked output
> --
>
> Key: CAMEL-13092
> URL: https://issues.apache.org/jira/browse/CAMEL-13092
> Project: Camel
> Issue Type: Bug
> Components: camel-servlet
>Affects Versions: 2.23.1
> Environment: I encounter this using the REST DSL with the servlet
> component, but I imagine its a more general problem. I
> 'm using Camel 2.18.0, but I checked and the problem seem to also happen with
> the latest version.
>Reporter: Tim Dudgeon
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.10.0
>
>
> This has been discussed in the users mailing list [1], but there was no
> conclusion, and it looks like a bug or quirk so I'm raising this issue to try
> to get resolution.
> The issue is that when writing the response of an HTTP request using a
> PipedInputStream to the Message body and with the `Content-Encoding: gzip`
> set as a response header the data does not seem to be sent until the entire
> stream has been written to the PipedInputStream. This means the client cannot
> start to read the response until the entire set of data has been written.
> When that header is not set the data is streamed immediately.
> Also, symptomatic of this, when using `Content-Encoding: gzip` the
> `Content-Length` header gets set, which can only happen after the entire
> stream has been processed. Without the gzip header the 'Transfer-Encoding:
> chunked' header gets set and there is no Content-Length as you might expect.
> I would have expected this to happen even if the `Content-Encoding: gzip`
> header is set.
> Is this a bug, or am I missing some magical way to ensure that the response
> is streamed when it is being gzipped?
>
> [1]http://mail-archives.apache.org/mod_mbox/camel-users/201901.mbox/%3C9cc4adf0-91f2-a111-edce-e7a18fde9fdf%40gmail.com%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-13092) Gzipping HTTP response prevents writing chunked output
[ https://issues.apache.org/jira/browse/CAMEL-13092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307280#comment-17307280 ] Claus Ibsen commented on CAMEL-13092: - Have build an use case for plain text (not gzipped) > Gzipping HTTP response prevents writing chunked output > -- > > Key: CAMEL-13092 > URL: https://issues.apache.org/jira/browse/CAMEL-13092 > Project: Camel > Issue Type: Bug > Components: camel-servlet >Affects Versions: 2.23.1 > Environment: I encounter this using the REST DSL with the servlet > component, but I imagine its a more general problem. I > 'm using Camel 2.18.0, but I checked and the problem seem to also happen with > the latest version. >Reporter: Tim Dudgeon >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > > This has been discussed in the users mailing list [1], but there was no > conclusion, and it looks like a bug or quirk so I'm raising this issue to try > to get resolution. > The issue is that when writing the response of an HTTP request using a > PipedInputStream to the Message body and with the `Content-Encoding: gzip` > set as a response header the data does not seem to be sent until the entire > stream has been written to the PipedInputStream. This means the client cannot > start to read the response until the entire set of data has been written. > When that header is not set the data is streamed immediately. > Also, symptomatic of this, when using `Content-Encoding: gzip` the > `Content-Length` header gets set, which can only happen after the entire > stream has been processed. Without the gzip header the 'Transfer-Encoding: > chunked' header gets set and there is no Content-Length as you might expect. > I would have expected this to happen even if the `Content-Encoding: gzip` > header is set. > Is this a bug, or am I missing some magical way to ensure that the response > is streamed when it is being gzipped? > > [1]http://mail-archives.apache.org/mod_mbox/camel-users/201901.mbox/%3C9cc4adf0-91f2-a111-edce-e7a18fde9fdf%40gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-13092) Gzipping HTTP response prevents writing chunked output
[ https://issues.apache.org/jira/browse/CAMEL-13092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-13092: --- Assignee: Claus Ibsen > Gzipping HTTP response prevents writing chunked output > -- > > Key: CAMEL-13092 > URL: https://issues.apache.org/jira/browse/CAMEL-13092 > Project: Camel > Issue Type: Bug > Components: camel-servlet >Affects Versions: 2.23.1 > Environment: I encounter this using the REST DSL with the servlet > component, but I imagine its a more general problem. I > 'm using Camel 2.18.0, but I checked and the problem seem to also happen with > the latest version. >Reporter: Tim Dudgeon >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.x > > > This has been discussed in the users mailing list [1], but there was no > conclusion, and it looks like a bug or quirk so I'm raising this issue to try > to get resolution. > The issue is that when writing the response of an HTTP request using a > PipedInputStream to the Message body and with the `Content-Encoding: gzip` > set as a response header the data does not seem to be sent until the entire > stream has been written to the PipedInputStream. This means the client cannot > start to read the response until the entire set of data has been written. > When that header is not set the data is streamed immediately. > Also, symptomatic of this, when using `Content-Encoding: gzip` the > `Content-Length` header gets set, which can only happen after the entire > stream has been processed. Without the gzip header the 'Transfer-Encoding: > chunked' header gets set and there is no Content-Length as you might expect. > I would have expected this to happen even if the `Content-Encoding: gzip` > header is set. > Is this a bug, or am I missing some magical way to ensure that the response > is streamed when it is being gzipped? > > [1]http://mail-archives.apache.org/mod_mbox/camel-users/201901.mbox/%3C9cc4adf0-91f2-a111-edce-e7a18fde9fdf%40gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-13092) Gzipping HTTP response prevents writing chunked output
[ https://issues.apache.org/jira/browse/CAMEL-13092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-13092: Fix Version/s: (was: 3.x) 3.10.0 > Gzipping HTTP response prevents writing chunked output > -- > > Key: CAMEL-13092 > URL: https://issues.apache.org/jira/browse/CAMEL-13092 > Project: Camel > Issue Type: Bug > Components: camel-servlet >Affects Versions: 2.23.1 > Environment: I encounter this using the REST DSL with the servlet > component, but I imagine its a more general problem. I > 'm using Camel 2.18.0, but I checked and the problem seem to also happen with > the latest version. >Reporter: Tim Dudgeon >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > > This has been discussed in the users mailing list [1], but there was no > conclusion, and it looks like a bug or quirk so I'm raising this issue to try > to get resolution. > The issue is that when writing the response of an HTTP request using a > PipedInputStream to the Message body and with the `Content-Encoding: gzip` > set as a response header the data does not seem to be sent until the entire > stream has been written to the PipedInputStream. This means the client cannot > start to read the response until the entire set of data has been written. > When that header is not set the data is streamed immediately. > Also, symptomatic of this, when using `Content-Encoding: gzip` the > `Content-Length` header gets set, which can only happen after the entire > stream has been processed. Without the gzip header the 'Transfer-Encoding: > chunked' header gets set and there is no Content-Length as you might expect. > I would have expected this to happen even if the `Content-Encoding: gzip` > header is set. > Is this a bug, or am I missing some magical way to ensure that the response > is streamed when it is being gzipped? > > [1]http://mail-archives.apache.org/mod_mbox/camel-users/201901.mbox/%3C9cc4adf0-91f2-a111-edce-e7a18fde9fdf%40gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16393) results from $.concat(...) seems to be cached on following calls
[
https://issues.apache.org/jira/browse/CAMEL-16393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307259#comment-17307259
]
Andrea Cosentino commented on CAMEL-16393:
--
For the moment I set the fix version to all the active branches, lets check.
> results from $.concat(...) seems to be cached on following calls
>
>
> Key: CAMEL-16393
> URL: https://issues.apache.org/jira/browse/CAMEL-16393
> Project: Camel
> Issue Type: Bug
> Components: camel-jsonpath
>Affects Versions: 2.25.3
>Reporter: Stefano Linguerri
>Priority: Major
> Fix For: 2.25.4, 3.4.6, 3.7.4, 3.10.0
>
> Attachments: jsonpath-issue.zip
>
>
> The first result from $.concat(...) seems to be "cached"
> Eg, given json:
> {{{"payload": \{"id": 1, "first_name": "Marie", "last_name": "Rose" } }}}
> The expression:
> {{jsonpath("$.concat($.payload.first_name,\" \",$.payload.last_name)")}}
> Will always returns _Marie Rose_ on following calls with different values in
> the input json.
> Please find attached reproducer maven project with junit test.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16393) results from $.concat(...) seems to be cached on following calls
[
https://issues.apache.org/jira/browse/CAMEL-16393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-16393:
-
Fix Version/s: 3.10.0
3.7.4
3.4.6
2.25.4
> results from $.concat(...) seems to be cached on following calls
>
>
> Key: CAMEL-16393
> URL: https://issues.apache.org/jira/browse/CAMEL-16393
> Project: Camel
> Issue Type: Bug
> Components: camel-jsonpath
>Affects Versions: 2.25.3
>Reporter: Stefano Linguerri
>Priority: Major
> Fix For: 2.25.4, 3.4.6, 3.7.4, 3.10.0
>
> Attachments: jsonpath-issue.zip
>
>
> The first result from $.concat(...) seems to be "cached"
> Eg, given json:
> {{{"payload": \{"id": 1, "first_name": "Marie", "last_name": "Rose" } }}}
> The expression:
> {{jsonpath("$.concat($.payload.first_name,\" \",$.payload.last_name)")}}
> Will always returns _Marie Rose_ on following calls with different values in
> the input json.
> Please find attached reproducer maven project with junit test.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-16393) results from $.concat(...) seems to be cached on following calls
Stefano Linguerri created CAMEL-16393:
-
Summary: results from $.concat(...) seems to be cached on
following calls
Key: CAMEL-16393
URL: https://issues.apache.org/jira/browse/CAMEL-16393
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.25.3
Reporter: Stefano Linguerri
Attachments: jsonpath-issue.zip
The first result from $.concat(...) seems to be "cached"
Eg, given json:
{{{"payload": \{"id": 1, "first_name": "Marie", "last_name": "Rose" } }}}
The expression:
{{jsonpath("$.concat($.payload.first_name,\" \",$.payload.last_name)")}}
Will always returns _Marie Rose_ on following calls with different values in
the input json.
Please find attached reproducer maven project with junit test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-13047) Validator Component Fails on XSD with file Relative Imports or include
[ https://issues.apache.org/jira/browse/CAMEL-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-13047. - Resolution: Fixed > Validator Component Fails on XSD with file Relative Imports or include > --- > > Key: CAMEL-13047 > URL: https://issues.apache.org/jira/browse/CAMEL-13047 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.22.0, 2.22.1, 2.22.2 >Reporter: W.Y >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > Attachments: testcase.zip > > > When using the validator component with an XSD that references > (import/include) a second XSD on a different path, and where the second XSD > references a third XSD using a relative path, the path of the third XSD is > resolved relative to the first schema rather than relative to the second. > I found it it same bug ticket reported , although it stated it is fixed > already at camel 2.10, but it does not work for us when we use >=camel 2.22. > The problem is reported as fixed at > https://issues.apache.org/jira/browse/CAMEL-6013 . i modified testcase of it > and put it here again for you to reproduce the problem. thanks and rgds -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16392) Camel-Pulsar: Make the client configurable from component parameters
Andrea Cosentino created CAMEL-16392: Summary: Camel-Pulsar: Make the client configurable from component parameters Key: CAMEL-16392 URL: https://issues.apache.org/jira/browse/CAMEL-16392 Project: Camel Issue Type: Task Reporter: Andrea Cosentino Assignee: Andrea Cosentino Fix For: 3.10.0 Currently you can only pass a pulsar client, without the possibility of creating the client from parameters. It's really limitating from kamelet pov. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-13047) Validator Component Fails on XSD with file Relative Imports or include
[ https://issues.apache.org/jira/browse/CAMEL-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307173#comment-17307173 ] Claus Ibsen commented on CAMEL-13047: - A bit complex with that deep directory structure, but the hunch is that the resolver loose the scheme being file as all the relative links, end up loosing file: as scheme, which means it ends up using classpath as resolver. > Validator Component Fails on XSD with file Relative Imports or include > --- > > Key: CAMEL-13047 > URL: https://issues.apache.org/jira/browse/CAMEL-13047 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.22.0, 2.22.1, 2.22.2 >Reporter: W.Y >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > Attachments: testcase.zip > > > When using the validator component with an XSD that references > (import/include) a second XSD on a different path, and where the second XSD > references a third XSD using a relative path, the path of the third XSD is > resolved relative to the first schema rather than relative to the second. > I found it it same bug ticket reported , although it stated it is fixed > already at camel 2.10, but it does not work for us when we use >=camel 2.22. > The problem is reported as fixed at > https://issues.apache.org/jira/browse/CAMEL-6013 . i modified testcase of it > and put it here again for you to reproduce the problem. thanks and rgds -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16370) Camel Salesforce component unable to reconnect after disconnect from Salesforce
[
https://issues.apache.org/jira/browse/CAMEL-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307132#comment-17307132
]
Claus Ibsen commented on CAMEL-16370:
-
So you are saying a very old Camel 2.23.1 works for you. But when using Camel
3.8.0 it does not
> Camel Salesforce component unable to reconnect after disconnect from
> Salesforce
> ---
>
> Key: CAMEL-16370
> URL: https://issues.apache.org/jira/browse/CAMEL-16370
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 3.8.0
> Environment: Running in a spring-boot (v2.1.18.RELEASE) app in a
> linux container deployed to openshift 3.11
>Reporter: Jason
>Priority: Major
> Fix For: 3.x
>
>
> We are consuming Salesforce platform-events following the documented
> recommendations and our connection will not reconnect after being
> disconnected, apparently, from Salesforce. I am not quite certain as to the
> circumstances that Salesforce sends some sort of disconnect signal, but that
> is what's logged from the SubscriptionHelper class. Our initial connection to
> Salesforce is successful and we are able to receive platform-events up until
> the point of the spontaneous disconnection. Re-connection fails consistently
> and always in the same way. Logging is slightly different across version,
> but the behavior seems to always be the same.
> Our only work around for this is to run our service consuming this message
> like a cron job and restart it every 15 minutes (period we settled on through
> experimentation). This is not how we'd prefer to sun this service, it's
> quite hacky and we'd like to not have to force a restart to work around what
> appears to an issue with how the reconnect is handled.
>
> Here is the stacktrace:
> [DEBUG] 2021-03-17 13:30:48,513
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=21,
> successful=true}][DEBUG] 2021-03-17 13:30:48,513
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=21,
> successful=true}[DEBUG] 2021-03-17 13:32:38,588
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=22,
> successful=true}][DEBUG] 2021-03-17 13:32:38,589
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=22,
> successful=true}[DEBUG] 2021-03-17 13:34:28,665
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=23,
> successful=true}][DEBUG] 2021-03-17 13:34:28,666
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=23,
> successful=true}[DEBUG] 2021-03-17 13:34:28,766
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-32 ] - Received messages
> [{channel=/meta/disconnect}, {clientId=[redacted],
> advice={reconnect=none, interval=0}, channel=/meta/connect, id=24,
> error=401::Authentication invalid, successful=false}][INFO ] 2021-03-17
> 13:34:28,769
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-26 ] - Restarting on unexpected disconnect
> from Salesforce...[DEBUG] 2021-03-17 13:34:28,769
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-26 ] - Waiting to disconnect...[DEBUG]
> 2021-03-17 13:34:28,770
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-32 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], advice={reconnect=none, interval=0},
> channel=/meta/connect, id=24, error=401::Authentication invalid,
> successful=false}[WARN ] 2021-03-17 13:34:28,771
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-32 ] - Connect failure:
> {clientId=[redacted], advice={reconnect=none, interval=0},
> channel=/meta/connect, id=24,
[jira] [Updated] (CAMEL-13047) Validator Component Fails on XSD with file Relative Imports or include
[ https://issues.apache.org/jira/browse/CAMEL-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-13047: Fix Version/s: 3.10.0 > Validator Component Fails on XSD with file Relative Imports or include > --- > > Key: CAMEL-13047 > URL: https://issues.apache.org/jira/browse/CAMEL-13047 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.22.0, 2.22.1, 2.22.2 >Reporter: W.Y >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > Attachments: testcase.zip > > > When using the validator component with an XSD that references > (import/include) a second XSD on a different path, and where the second XSD > references a third XSD using a relative path, the path of the third XSD is > resolved relative to the first schema rather than relative to the second. > I found it it same bug ticket reported , although it stated it is fixed > already at camel 2.10, but it does not work for us when we use >=camel 2.22. > The problem is reported as fixed at > https://issues.apache.org/jira/browse/CAMEL-6013 . i modified testcase of it > and put it here again for you to reproduce the problem. thanks and rgds -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-13047) Validator Component Fails on XSD with file Relative Imports or include
[ https://issues.apache.org/jira/browse/CAMEL-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307128#comment-17307128 ] Claus Ibsen commented on CAMEL-13047: - Thanks for the sample project - I managed to make it run with latest code. > Validator Component Fails on XSD with file Relative Imports or include > --- > > Key: CAMEL-13047 > URL: https://issues.apache.org/jira/browse/CAMEL-13047 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.22.0, 2.22.1, 2.22.2 >Reporter: W.Y >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > Attachments: testcase.zip > > > When using the validator component with an XSD that references > (import/include) a second XSD on a different path, and where the second XSD > references a third XSD using a relative path, the path of the third XSD is > resolved relative to the first schema rather than relative to the second. > I found it it same bug ticket reported , although it stated it is fixed > already at camel 2.10, but it does not work for us when we use >=camel 2.22. > The problem is reported as fixed at > https://issues.apache.org/jira/browse/CAMEL-6013 . i modified testcase of it > and put it here again for you to reproduce the problem. thanks and rgds -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-13047) Validator Component Fails on XSD with file Relative Imports or include
[ https://issues.apache.org/jira/browse/CAMEL-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-13047: --- Assignee: Claus Ibsen > Validator Component Fails on XSD with file Relative Imports or include > --- > > Key: CAMEL-13047 > URL: https://issues.apache.org/jira/browse/CAMEL-13047 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.22.0, 2.22.1, 2.22.2 >Reporter: W.Y >Assignee: Claus Ibsen >Priority: Minor > Attachments: testcase.zip > > > When using the validator component with an XSD that references > (import/include) a second XSD on a different path, and where the second XSD > references a third XSD using a relative path, the path of the third XSD is > resolved relative to the first schema rather than relative to the second. > I found it it same bug ticket reported , although it stated it is fixed > already at camel 2.10, but it does not work for us when we use >=camel 2.22. > The problem is reported as fixed at > https://issues.apache.org/jira/browse/CAMEL-6013 . i modified testcase of it > and put it here again for you to reproduce the problem. thanks and rgds -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-16370) Camel Salesforce component unable to reconnect after disconnect from Salesforce
[
https://issues.apache.org/jira/browse/CAMEL-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307121#comment-17307121
]
Jason edited comment on CAMEL-16370 at 3/23/21, 2:28 PM:
-
This works in in Camel 2.23.1 and auth only fails when a forced restart of the
connection occurs.
was (Author: jasonholmberg):
This works in in Camel 2.23.1 and auth only fails when forced restart of the
connection occurs.
> Camel Salesforce component unable to reconnect after disconnect from
> Salesforce
> ---
>
> Key: CAMEL-16370
> URL: https://issues.apache.org/jira/browse/CAMEL-16370
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 3.8.0
> Environment: Running in a spring-boot (v2.1.18.RELEASE) app in a
> linux container deployed to openshift 3.11
>Reporter: Jason
>Priority: Major
> Fix For: 3.x
>
>
> We are consuming Salesforce platform-events following the documented
> recommendations and our connection will not reconnect after being
> disconnected, apparently, from Salesforce. I am not quite certain as to the
> circumstances that Salesforce sends some sort of disconnect signal, but that
> is what's logged from the SubscriptionHelper class. Our initial connection to
> Salesforce is successful and we are able to receive platform-events up until
> the point of the spontaneous disconnection. Re-connection fails consistently
> and always in the same way. Logging is slightly different across version,
> but the behavior seems to always be the same.
> Our only work around for this is to run our service consuming this message
> like a cron job and restart it every 15 minutes (period we settled on through
> experimentation). This is not how we'd prefer to sun this service, it's
> quite hacky and we'd like to not have to force a restart to work around what
> appears to an issue with how the reconnect is handled.
>
> Here is the stacktrace:
> [DEBUG] 2021-03-17 13:30:48,513
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=21,
> successful=true}][DEBUG] 2021-03-17 13:30:48,513
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=21,
> successful=true}[DEBUG] 2021-03-17 13:32:38,588
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=22,
> successful=true}][DEBUG] 2021-03-17 13:32:38,589
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=22,
> successful=true}[DEBUG] 2021-03-17 13:34:28,665
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=23,
> successful=true}][DEBUG] 2021-03-17 13:34:28,666
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=23,
> successful=true}[DEBUG] 2021-03-17 13:34:28,766
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-32 ] - Received messages
> [{channel=/meta/disconnect}, {clientId=[redacted],
> advice={reconnect=none, interval=0}, channel=/meta/connect, id=24,
> error=401::Authentication invalid, successful=false}][INFO ] 2021-03-17
> 13:34:28,769
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-26 ] - Restarting on unexpected disconnect
> from Salesforce...[DEBUG] 2021-03-17 13:34:28,769
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-26 ] - Waiting to disconnect...[DEBUG]
> 2021-03-17 13:34:28,770
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-32 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], advice={reconnect=none, interval=0},
> channel=/meta/connect, id=24, error=401::Authentication invalid,
> successful=false}[WARN ] 2021-03-17 13:34:28,771
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
>
[jira] [Commented] (CAMEL-16370) Camel Salesforce component unable to reconnect after disconnect from Salesforce
[
https://issues.apache.org/jira/browse/CAMEL-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307121#comment-17307121
]
Jason commented on CAMEL-16370:
---
This works in in Camel 2.23.1 and auth only fails when forced restart of the
connection occurs.
> Camel Salesforce component unable to reconnect after disconnect from
> Salesforce
> ---
>
> Key: CAMEL-16370
> URL: https://issues.apache.org/jira/browse/CAMEL-16370
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 3.8.0
> Environment: Running in a spring-boot (v2.1.18.RELEASE) app in a
> linux container deployed to openshift 3.11
>Reporter: Jason
>Priority: Major
> Fix For: 3.x
>
>
> We are consuming Salesforce platform-events following the documented
> recommendations and our connection will not reconnect after being
> disconnected, apparently, from Salesforce. I am not quite certain as to the
> circumstances that Salesforce sends some sort of disconnect signal, but that
> is what's logged from the SubscriptionHelper class. Our initial connection to
> Salesforce is successful and we are able to receive platform-events up until
> the point of the spontaneous disconnection. Re-connection fails consistently
> and always in the same way. Logging is slightly different across version,
> but the behavior seems to always be the same.
> Our only work around for this is to run our service consuming this message
> like a cron job and restart it every 15 minutes (period we settled on through
> experimentation). This is not how we'd prefer to sun this service, it's
> quite hacky and we'd like to not have to force a restart to work around what
> appears to an issue with how the reconnect is handled.
>
> Here is the stacktrace:
> [DEBUG] 2021-03-17 13:30:48,513
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=21,
> successful=true}][DEBUG] 2021-03-17 13:30:48,513
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=21,
> successful=true}[DEBUG] 2021-03-17 13:32:38,588
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=22,
> successful=true}][DEBUG] 2021-03-17 13:32:38,589
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=22,
> successful=true}[DEBUG] 2021-03-17 13:34:28,665
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-25 ] - Received messages
> [{clientId=[redacted], channel=/meta/connect, id=23,
> successful=true}][DEBUG] 2021-03-17 13:34:28,666
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-25 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], channel=/meta/connect, id=23,
> successful=true}[DEBUG] 2021-03-17 13:34:28,766
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5
> [SalesforceHttpClient@60c73e58-32 ] - Received messages
> [{channel=/meta/disconnect}, {clientId=[redacted],
> advice={reconnect=none, interval=0}, channel=/meta/connect, id=24,
> error=401::Authentication invalid, successful=false}][INFO ] 2021-03-17
> 13:34:28,769
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-26 ] - Restarting on unexpected disconnect
> from Salesforce...[DEBUG] 2021-03-17 13:34:28,769
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-26 ] - Waiting to disconnect...[DEBUG]
> 2021-03-17 13:34:28,770
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-32 ] - [CHANNEL:META_CONNECT]:
> {clientId=[redacted], advice={reconnect=none, interval=0},
> channel=/meta/connect, id=24, error=401::Authentication invalid,
> successful=false}[WARN ] 2021-03-17 13:34:28,771
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@60c73e58-32 ] - Connect failure:
> {clientId=[redacted], advice={reconnect=none, interval=0},
> channel=/meta/connect, id=24,
[jira] [Resolved] (CAMEL-12764) camel-http4: basic auth no longer working when used in combination with a dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-12764.
-
Resolution: Fixed
Now it also works for the authority part of the uri as in the initial report
> camel-http4: basic auth no longer working when used in combination with a
> dynamic to
>
>
> Key: CAMEL-12764
> URL: https://issues.apache.org/jira/browse/CAMEL-12764
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Affects Versions: 2.22.0, 2.22.1, 2.23.2, 2.24.1
>Reporter: Pascal Schumacher
>Assignee: Claus Ibsen
>Priority: Major
> Labels: regresion
> Fix For: 3.10.0
>
>
> After upgrading a Spring Boot Project from Camel 2.21.1 to Camel 2.22.0 basic
> authentication of the http4 component stopped working when it is used in
> combination with a dynamic to.
> My (slightly simplified) route:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
>
> .toD("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/${exchangeProperty.my_id}");
> {code}
> When I change the route and remove the dynamic to everything works fine again:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
> .setHeader(Exchange.HTTP_PATH, exchangeProperty("my_id"))
> .to("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/");
> {code}
> Maybe this regression was caused by CAMEL-12462?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-12764) camel-http4: basic auth no longer working when used in combination with a dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307065#comment-17307065
]
Claus Ibsen edited comment on CAMEL-12764 at 3/23/21, 1:52 PM:
---
If you specify the username and password as query parameters then it works
{code}
from("direct:joes")
.toD("http://localhost:; + localServer.getLocalPort()
+
"/joes?authMethod=Basic={{myUsername}}={{myPassword}}=true=false=${header.drink}");
{code}
was (Author: davsclaus):
If you specify the username and password as query parameters then it works
from("direct:joes")
.toD("http://localhost:; + localServer.getLocalPort()
+
"/joes?authMethod=Basic={{myUsername}}={{myPassword}}=false=${header.drink}");
> camel-http4: basic auth no longer working when used in combination with a
> dynamic to
>
>
> Key: CAMEL-12764
> URL: https://issues.apache.org/jira/browse/CAMEL-12764
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Affects Versions: 2.22.0, 2.22.1, 2.23.2, 2.24.1
>Reporter: Pascal Schumacher
>Assignee: Claus Ibsen
>Priority: Major
> Labels: regresion
> Fix For: 3.10.0
>
>
> After upgrading a Spring Boot Project from Camel 2.21.1 to Camel 2.22.0 basic
> authentication of the http4 component stopped working when it is used in
> combination with a dynamic to.
> My (slightly simplified) route:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
>
> .toD("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/${exchangeProperty.my_id}");
> {code}
> When I change the route and remove the dynamic to everything works fine again:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
> .setHeader(Exchange.HTTP_PATH, exchangeProperty("my_id"))
> .to("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/");
> {code}
> Maybe this regression was caused by CAMEL-12462?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-16391) Deprecate and remove redundant code from camel-microprofile-health
James Netherton created CAMEL-16391: --- Summary: Deprecate and remove redundant code from camel-microprofile-health Key: CAMEL-16391 URL: https://issues.apache.org/jira/browse/CAMEL-16391 Project: Camel Issue Type: Improvement Reporter: James Netherton Assignee: James Netherton Fix For: 3.10.0 I did a quick revisit of camel-microprofile-health and noticed a few things that can be tidied up. The initial implementation pre-dates some of the improvements that were made to the Camel Health APIs, so some stuff is now obsolete. So I'd like to: * Deprecate and eventually remove CamelMicroProfileLivenessCheck / CamelMicroProfileReadinessCheck as AbstractHealthCheck provides its own methods for marking a check as exclusively for liveness or readiness. * Remove CamelMicroProfileContextCheck as there's a similar thing already in camel-health -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-16390) camel-salesforce: Add raw operation
[ https://issues.apache.org/jira/browse/CAMEL-16390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Ross reassigned CAMEL-16390: --- Assignee: Jeremy Ross > camel-salesforce: Add raw operation > --- > > Key: CAMEL-16390 > URL: https://issues.apache.org/jira/browse/CAMEL-16390 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Affects Versions: 3.9.0 >Reporter: Jeremy Ross >Assignee: Jeremy Ross >Priority: Major > Fix For: 3.10.0 > > > This will be a new `raw` operation that allows users to specify URL, URL > parameters, http body, and http method. This will allow a lot more > flexibility in using the salesforce APIs with raw payloads. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16390) camel-salesforce: Add raw operation
Jeremy Ross created CAMEL-16390: --- Summary: camel-salesforce: Add raw operation Key: CAMEL-16390 URL: https://issues.apache.org/jira/browse/CAMEL-16390 Project: Camel Issue Type: New Feature Components: camel-salesforce Affects Versions: 3.9.0 Reporter: Jeremy Ross Fix For: 3.10.0 This will be a new `raw` operation that allows users to specify URL, URL parameters, http body, and http method. This will allow a lot more flexibility in using the salesforce APIs with raw payloads. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15757) camel-salesforce: Add rawPayload support in camel-salesforce composite
[ https://issues.apache.org/jira/browse/CAMEL-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Ross updated CAMEL-15757: Description: (was: This will be a new `raw` operation that allows users to specify URL, URL parameters, http body, and http method. This will allow a lot more flexibility in using the salesforce APIs with raw payloads. ) > camel-salesforce: Add rawPayload support in camel-salesforce composite > -- > > Key: CAMEL-15757 > URL: https://issues.apache.org/jira/browse/CAMEL-15757 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15757) camel-salesforce: Add rawPayload support in camel-salesforce composite
[ https://issues.apache.org/jira/browse/CAMEL-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Ross updated CAMEL-15757: Summary: camel-salesforce: Add rawPayload support in camel-salesforce composite (was: camel-salesforce: Add raw operation) > camel-salesforce: Add rawPayload support in camel-salesforce composite > -- > > Key: CAMEL-15757 > URL: https://issues.apache.org/jira/browse/CAMEL-15757 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 3.7.0 > > > This will be a new `raw` operation that allows users to specify URL, URL > parameters, http body, and http method. This will allow a lot more > flexibility in using the salesforce APIs with raw payloads. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15757) camel-salesforce: Add raw operation
[ https://issues.apache.org/jira/browse/CAMEL-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Ross updated CAMEL-15757: Description: This will be a new `raw` operation that allows users to specify URL, URL parameters, http body, and http method. This will allow a lot more flexibility in using the salesforce APIs with raw payloads. (was: Id) > camel-salesforce: Add raw operation > --- > > Key: CAMEL-15757 > URL: https://issues.apache.org/jira/browse/CAMEL-15757 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 3.7.0 > > > This will be a new `raw` operation that allows users to specify URL, URL > parameters, http body, and http method. This will allow a lot more > flexibility in using the salesforce APIs with raw payloads. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-12764) camel-http4: basic auth no longer working when used in combination with a dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307065#comment-17307065
]
Claus Ibsen commented on CAMEL-12764:
-
If you specify the username and password as query parameters then it works
from("direct:joes")
.toD("http://localhost:; + localServer.getLocalPort()
+
"/joes?authMethod=Basic={{myUsername}}={{myPassword}}=false=${header.drink}");
> camel-http4: basic auth no longer working when used in combination with a
> dynamic to
>
>
> Key: CAMEL-12764
> URL: https://issues.apache.org/jira/browse/CAMEL-12764
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Affects Versions: 2.22.0, 2.22.1, 2.23.2, 2.24.1
>Reporter: Pascal Schumacher
>Assignee: Claus Ibsen
>Priority: Major
> Labels: regresion
> Fix For: 3.10.0
>
>
> After upgrading a Spring Boot Project from Camel 2.21.1 to Camel 2.22.0 basic
> authentication of the http4 component stopped working when it is used in
> combination with a dynamic to.
> My (slightly simplified) route:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
>
> .toD("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/${exchangeProperty.my_id}");
> {code}
> When I change the route and remove the dynamic to everything works fine again:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
> .setHeader(Exchange.HTTP_PATH, exchangeProperty("my_id"))
> .to("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/");
> {code}
> Maybe this regression was caused by CAMEL-12462?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-12764) camel-http4: basic auth no longer working when used in combination with a dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-12764:
Fix Version/s: 3.10.0
> camel-http4: basic auth no longer working when used in combination with a
> dynamic to
>
>
> Key: CAMEL-12764
> URL: https://issues.apache.org/jira/browse/CAMEL-12764
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Affects Versions: 2.22.0, 2.22.1, 2.23.2, 2.24.1
>Reporter: Pascal Schumacher
>Assignee: Claus Ibsen
>Priority: Major
> Labels: regresion
> Fix For: 3.10.0
>
>
> After upgrading a Spring Boot Project from Camel 2.21.1 to Camel 2.22.0 basic
> authentication of the http4 component stopped working when it is used in
> combination with a dynamic to.
> My (slightly simplified) route:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
>
> .toD("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/${exchangeProperty.my_id}");
> {code}
> When I change the route and remove the dynamic to everything works fine again:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
> .setHeader(Exchange.HTTP_PATH, exchangeProperty("my_id"))
> .to("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/");
> {code}
> Maybe this regression was caused by CAMEL-12462?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-12764) camel-http4: basic auth no longer working when used in combination with a dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-12764:
---
Assignee: Claus Ibsen
> camel-http4: basic auth no longer working when used in combination with a
> dynamic to
>
>
> Key: CAMEL-12764
> URL: https://issues.apache.org/jira/browse/CAMEL-12764
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Affects Versions: 2.22.0, 2.22.1, 2.23.2, 2.24.1
>Reporter: Pascal Schumacher
>Assignee: Claus Ibsen
>Priority: Major
> Labels: regresion
>
> After upgrading a Spring Boot Project from Camel 2.21.1 to Camel 2.22.0 basic
> authentication of the http4 component stopped working when it is used in
> combination with a dynamic to.
> My (slightly simplified) route:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
>
> .toD("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/${exchangeProperty.my_id}");
> {code}
> When I change the route and remove the dynamic to everything works fine again:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
> .setHeader(Exchange.HTTP_PATH, exchangeProperty("my_id"))
> .to("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/");
> {code}
> Maybe this regression was caused by CAMEL-12462?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-15757) camel-salesforce: Add raw operation
[ https://issues.apache.org/jira/browse/CAMEL-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Ross updated CAMEL-15757: Summary: camel-salesforce: Add raw operation (was: Add rawPayload support in camel-salesforce composite) > camel-salesforce: Add raw operation > --- > > Key: CAMEL-15757 > URL: https://issues.apache.org/jira/browse/CAMEL-15757 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15757) camel-salesforce: Add raw operation
[ https://issues.apache.org/jira/browse/CAMEL-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Ross updated CAMEL-15757: Description: Id > camel-salesforce: Add raw operation > --- > > Key: CAMEL-15757 > URL: https://issues.apache.org/jira/browse/CAMEL-15757 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 3.7.0 > > > Id -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16389) Remove json-smart
[ https://issues.apache.org/jira/browse/CAMEL-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307054#comment-17307054 ] Colm O hEigeartaigh commented on CAMEL-16389: - Oops, sorry about that. > Remove json-smart > - > > Key: CAMEL-16389 > URL: https://issues.apache.org/jira/browse/CAMEL-16389 > Project: Camel > Issue Type: Task >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.10.0 > > > There is a issue in json-smart, and the project appears not to be updated any > longer: [https://github.com/json-path/JsonPath/issues/676] > It's used in two components: > * camel-chunk - Appears to be no longer needed > * camel-jsonpath - I propose to swap it out to use Jackson instead via > [https://github.com/json-path/JsonPath/blob/master/README.md#jsonprovider-spi] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16388) camel-salesforce: drop support for XML as a serialization format
[
https://issues.apache.org/jira/browse/CAMEL-16388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307052#comment-17307052
]
Jeremy Ross commented on CAMEL-16388:
-
One minor correction. XML does *not* have parity with JSON in some of the
salesforce APIs, e.g., plain composite supports JSON only.
> camel-salesforce: drop support for XML as a serialization format
>
>
> Key: CAMEL-16388
> URL: https://issues.apache.org/jira/browse/CAMEL-16388
> Project: Camel
> Issue Type: Wish
> Components: camel-salesforce
>Affects Versions: 3.8.0
>Reporter: Jeremy Ross
>Priority: Major
> Fix For: 3.10.0
>
>
> Putting this out here for a discussion.
> The salesforce REST APIs support XML and JSON. However, it's clear from the
> official documentation and examples that JSON is the first-class citizen. All
> the examples are in JSON and there's only this one, sad reference to XML
> serialization:
> {quote}XML serialization is similar to SOAP API. XML requests are supported
> in UTF-8 and UTF-16, and XML responses are provided in UTF-8.{quote}
> This leaves us Camel maintainers with the not-fun activity of guessing how
> salesforce expects its myriad types to be serialized to XML.
> I suspect that Camel users don't really care that much which serialization
> format is used. Both have equal parity with salesforce, and as a Camel user I
> just care that Camel serializes and deserializes my DTOs correctly. Wire
> format is an abstraction that shouldn't matter. This is the crux of my
> argument.
> Camel's support for both formats is a maintenance burden, and a barrier to
> developing future features and support for newer APIs. Serialization format
> isn't a concern to users, and supporting both formats is of no real value.
> Therefore, I'd like to consider dropping XML support, leaving JSON as the
> supported format.
> Note that this does not affect the `rawPayload` option. Users would still be
> welcome to provide their own raw payloads in either format.
> Paging for comment: [~zregvart] [~davsclaus] [~jbonofre]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-12764) camel-http4: basic auth no longer working when used in combination with a dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307051#comment-17307051
]
Claus Ibsen commented on CAMEL-12764:
-
In Camel 3.x the basic auth uses authUsername, authPassword as query parameters
to specify those, instead of in the authority part.
> camel-http4: basic auth no longer working when used in combination with a
> dynamic to
>
>
> Key: CAMEL-12764
> URL: https://issues.apache.org/jira/browse/CAMEL-12764
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Affects Versions: 2.22.0, 2.22.1, 2.23.2, 2.24.1
>Reporter: Pascal Schumacher
>Priority: Major
> Labels: regresion
>
> After upgrading a Spring Boot Project from Camel 2.21.1 to Camel 2.22.0 basic
> authentication of the http4 component stopped working when it is used in
> combination with a dynamic to.
> My (slightly simplified) route:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
>
> .toD("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/${exchangeProperty.my_id}");
> {code}
> When I change the route and remove the dynamic to everything works fine again:
> {code:java}
> from(inUri)
> .setHeader(Exchange.CONTENT_TYPE,
> constant(MediaType.APPLICATION_JSON_VALUE))
> .setBody(constant("{\"action\":\"signal\"}"))
> .setHeader(Exchange.HTTP_METHOD, constant(HttpMethods.PUT))
> .setHeader(Exchange.HTTP_PATH, exchangeProperty("my_id"))
> .to("http4://{{username}}:{{password}}@{{host}}:{{port}}/executions/");
> {code}
> Maybe this regression was caused by CAMEL-12462?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-16375) Getting rid of json-smart as explicit and transitive dependency
[ https://issues.apache.org/jira/browse/CAMEL-16375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-16375. -- Resolution: Duplicate [~coheigea] please check next time if there is already a ticket and if it's assigned. > Getting rid of json-smart as explicit and transitive dependency > --- > > Key: CAMEL-16375 > URL: https://issues.apache.org/jira/browse/CAMEL-16375 > Project: Camel > Issue Type: Task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.10.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-16389) Remove json-smart
[ https://issues.apache.org/jira/browse/CAMEL-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16389: Issue Type: Task (was: Improvement) > Remove json-smart > - > > Key: CAMEL-16389 > URL: https://issues.apache.org/jira/browse/CAMEL-16389 > Project: Camel > Issue Type: Task >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.10.0 > > > There is a issue in json-smart, and the project appears not to be updated any > longer: [https://github.com/json-path/JsonPath/issues/676] > It's used in two components: > * camel-chunk - Appears to be no longer needed > * camel-jsonpath - I propose to swap it out to use Jackson instead via > [https://github.com/json-path/JsonPath/blob/master/README.md#jsonprovider-spi] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16389) Remove json-smart
[ https://issues.apache.org/jira/browse/CAMEL-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307035#comment-17307035 ] Claus Ibsen commented on CAMEL-16389: - Colm, there was already ticket CAME-16375 > Remove json-smart > - > > Key: CAMEL-16389 > URL: https://issues.apache.org/jira/browse/CAMEL-16389 > Project: Camel > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.10.0 > > > There is a issue in json-smart, and the project appears not to be updated any > longer: [https://github.com/json-path/JsonPath/issues/676] > It's used in two components: > * camel-chunk - Appears to be no longer needed > * camel-jsonpath - I propose to swap it out to use Jackson instead via > [https://github.com/json-path/JsonPath/blob/master/README.md#jsonprovider-spi] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-16389) Remove json-smart
[ https://issues.apache.org/jira/browse/CAMEL-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16389: Description: There is a issue in json-smart, and the project appears not to be updated any longer: [https://github.com/json-path/JsonPath/issues/676] It's used in two components: * camel-chunk - Appears to be no longer needed * camel-jsonpath - I propose to swap it out to use Jackson instead via [https://github.com/json-path/JsonPath/blob/master/README.md#jsonprovider-spi] was: There is a security issue in json-smart, and the project appears not to be updated any longer: [https://github.com/json-path/JsonPath/issues/676] It's used in two components: * camel-chunk - Appears to be no longer needed * camel-jsonpath - I propose to swap it out to use Jackson instead via [https://github.com/json-path/JsonPath/blob/master/README.md#jsonprovider-spi] > Remove json-smart > - > > Key: CAMEL-16389 > URL: https://issues.apache.org/jira/browse/CAMEL-16389 > Project: Camel > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.10.0 > > > There is a issue in json-smart, and the project appears not to be updated any > longer: [https://github.com/json-path/JsonPath/issues/676] > It's used in two components: > * camel-chunk - Appears to be no longer needed > * camel-jsonpath - I propose to swap it out to use Jackson instead via > [https://github.com/json-path/JsonPath/blob/master/README.md#jsonprovider-spi] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-16389) Remove json-smart
[ https://issues.apache.org/jira/browse/CAMEL-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16389: Fix Version/s: (was: 3.9.0) 3.10.0 > Remove json-smart > - > > Key: CAMEL-16389 > URL: https://issues.apache.org/jira/browse/CAMEL-16389 > Project: Camel > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.10.0 > > > There is a security issue in json-smart, and the project appears not to be > updated any longer: [https://github.com/json-path/JsonPath/issues/676] > It's used in two components: > * camel-chunk - Appears to be no longer needed > * camel-jsonpath - I propose to swap it out to use Jackson instead via > [https://github.com/json-path/JsonPath/blob/master/README.md#jsonprovider-spi] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (CAMEL-16389) Remove json-smart
[ https://issues.apache.org/jira/browse/CAMEL-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-16389 started by Colm O hEigeartaigh. --- > Remove json-smart > - > > Key: CAMEL-16389 > URL: https://issues.apache.org/jira/browse/CAMEL-16389 > Project: Camel > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.9.0 > > > There is a security issue in json-smart, and the project appears not to be > updated any longer: [https://github.com/json-path/JsonPath/issues/676] > It's used in two components: > * camel-chunk - Appears to be no longer needed > * camel-jsonpath - I propose to swap it out to use Jackson instead via > [https://github.com/json-path/JsonPath/blob/master/README.md#jsonprovider-spi] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16389) Remove json-smart
Colm O hEigeartaigh created CAMEL-16389: --- Summary: Remove json-smart Key: CAMEL-16389 URL: https://issues.apache.org/jira/browse/CAMEL-16389 Project: Camel Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 3.9.0 There is a security issue in json-smart, and the project appears not to be updated any longer: [https://github.com/json-path/JsonPath/issues/676] It's used in two components: * camel-chunk - Appears to be no longer needed * camel-jsonpath - I propose to swap it out to use Jackson instead via [https://github.com/json-path/JsonPath/blob/master/README.md#jsonprovider-spi] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-12472) Downloading a large file with streamDownload and stepwise hangs
[
https://issues.apache.org/jira/browse/CAMEL-12472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307028#comment-17307028
]
Claus Ibsen commented on CAMEL-12472:
-
This has been fixed by CAMEL-14506 where we does not allow to use stepwise with
stream download.
> Downloading a large file with streamDownload and stepwise hangs
>
>
> Key: CAMEL-12472
> URL: https://issues.apache.org/jira/browse/CAMEL-12472
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.21.0
> Environment: * Camel versions: 2.17.0 and 2.21.0
> * Ftp servers: plain vsftpd server, org.apache.ftpserver as a mock, Camel
> test environment ftp.
> * Files: depending on configuration from 1mb to 5mb file is vital for error
> to happen.
>Reporter: Karol Koltun
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.10.0
>
> Attachments: 0001-FtpSimpleConsumeStreamingStepwiseTest.patch
>
>
> *Downloading a file exceeding certain, system-dependent size with
> streamDownload and stepwise options turned on hangs and causes timeout.*
> I prepared a test which triggers the error. The patch file is pretty big, as
> I had to make a file enough big to make the timeout happen. Basing on my
> predictions, the size of the file triggering the error depends on FTP
> configuration and Java caching policy (no proof available yet). Working with
> plain Vsftpd server even 1mb files triggered timeouts. In the test
> environment the limit on my desktop is 5 mb. If the test passes, please make
> the file bigger.
> My intepretation of the problem:
> # Start downloading a file with size exceeding InputStream cache (on my pc
> approx. 1mb is the limit).
>
> [FtpOperations.java:373|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L423]
> {code:java}
> InputStream is = this.client.retrieveFileStream(remoteName);
> {code}
> # The server responds 150 and opens data connection.
> {code:java}
> [user_ftp] FTP response: Client "127.0.0.1", "150 Opening BINARY mode data
> connection for x (1048576 bytes)."
> {code}
> # The data connection does not end because InputStream is waiting for reads
> and it has not cached whole file. No "226 Transfer complete" response from
> server.
> # Try to change directory as stepwise is turned on.
>
> [FtpOperations.java:387|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L443]
> {code:java}
> this.changeCurrentDirectory(currentDir);
> {code}
> # Camel hangs as the server is still in the data connection and we are
> waiting for response from CWD command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-12472) Downloading a large file with streamDownload and stepwise hangs
[
https://issues.apache.org/jira/browse/CAMEL-12472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-12472.
-
Resolution: Fixed
> Downloading a large file with streamDownload and stepwise hangs
>
>
> Key: CAMEL-12472
> URL: https://issues.apache.org/jira/browse/CAMEL-12472
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.21.0
> Environment: * Camel versions: 2.17.0 and 2.21.0
> * Ftp servers: plain vsftpd server, org.apache.ftpserver as a mock, Camel
> test environment ftp.
> * Files: depending on configuration from 1mb to 5mb file is vital for error
> to happen.
>Reporter: Karol Koltun
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.10.0
>
> Attachments: 0001-FtpSimpleConsumeStreamingStepwiseTest.patch
>
>
> *Downloading a file exceeding certain, system-dependent size with
> streamDownload and stepwise options turned on hangs and causes timeout.*
> I prepared a test which triggers the error. The patch file is pretty big, as
> I had to make a file enough big to make the timeout happen. Basing on my
> predictions, the size of the file triggering the error depends on FTP
> configuration and Java caching policy (no proof available yet). Working with
> plain Vsftpd server even 1mb files triggered timeouts. In the test
> environment the limit on my desktop is 5 mb. If the test passes, please make
> the file bigger.
> My intepretation of the problem:
> # Start downloading a file with size exceeding InputStream cache (on my pc
> approx. 1mb is the limit).
>
> [FtpOperations.java:373|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L423]
> {code:java}
> InputStream is = this.client.retrieveFileStream(remoteName);
> {code}
> # The server responds 150 and opens data connection.
> {code:java}
> [user_ftp] FTP response: Client "127.0.0.1", "150 Opening BINARY mode data
> connection for x (1048576 bytes)."
> {code}
> # The data connection does not end because InputStream is waiting for reads
> and it has not cached whole file. No "226 Transfer complete" response from
> server.
> # Try to change directory as stepwise is turned on.
>
> [FtpOperations.java:387|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L443]
> {code:java}
> this.changeCurrentDirectory(currentDir);
> {code}
> # Camel hangs as the server is still in the data connection and we are
> waiting for response from CWD command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-12472) Downloading a large file with streamDownload and stepwise hangs
[
https://issues.apache.org/jira/browse/CAMEL-12472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-12472:
Fix Version/s: 3.10.0
> Downloading a large file with streamDownload and stepwise hangs
>
>
> Key: CAMEL-12472
> URL: https://issues.apache.org/jira/browse/CAMEL-12472
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.21.0
> Environment: * Camel versions: 2.17.0 and 2.21.0
> * Ftp servers: plain vsftpd server, org.apache.ftpserver as a mock, Camel
> test environment ftp.
> * Files: depending on configuration from 1mb to 5mb file is vital for error
> to happen.
>Reporter: Karol Koltun
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.10.0
>
> Attachments: 0001-FtpSimpleConsumeStreamingStepwiseTest.patch
>
>
> *Downloading a file exceeding certain, system-dependent size with
> streamDownload and stepwise options turned on hangs and causes timeout.*
> I prepared a test which triggers the error. The patch file is pretty big, as
> I had to make a file enough big to make the timeout happen. Basing on my
> predictions, the size of the file triggering the error depends on FTP
> configuration and Java caching policy (no proof available yet). Working with
> plain Vsftpd server even 1mb files triggered timeouts. In the test
> environment the limit on my desktop is 5 mb. If the test passes, please make
> the file bigger.
> My intepretation of the problem:
> # Start downloading a file with size exceeding InputStream cache (on my pc
> approx. 1mb is the limit).
>
> [FtpOperations.java:373|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L423]
> {code:java}
> InputStream is = this.client.retrieveFileStream(remoteName);
> {code}
> # The server responds 150 and opens data connection.
> {code:java}
> [user_ftp] FTP response: Client "127.0.0.1", "150 Opening BINARY mode data
> connection for x (1048576 bytes)."
> {code}
> # The data connection does not end because InputStream is waiting for reads
> and it has not cached whole file. No "226 Transfer complete" response from
> server.
> # Try to change directory as stepwise is turned on.
>
> [FtpOperations.java:387|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L443]
> {code:java}
> this.changeCurrentDirectory(currentDir);
> {code}
> # Camel hangs as the server is still in the data connection and we are
> waiting for response from CWD command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-12472) Downloading a large file with streamDownload and stepwise hangs
[
https://issues.apache.org/jira/browse/CAMEL-12472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-12472:
---
Assignee: Claus Ibsen
> Downloading a large file with streamDownload and stepwise hangs
>
>
> Key: CAMEL-12472
> URL: https://issues.apache.org/jira/browse/CAMEL-12472
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.21.0
> Environment: * Camel versions: 2.17.0 and 2.21.0
> * Ftp servers: plain vsftpd server, org.apache.ftpserver as a mock, Camel
> test environment ftp.
> * Files: depending on configuration from 1mb to 5mb file is vital for error
> to happen.
>Reporter: Karol Koltun
>Assignee: Claus Ibsen
>Priority: Major
> Attachments: 0001-FtpSimpleConsumeStreamingStepwiseTest.patch
>
>
> *Downloading a file exceeding certain, system-dependent size with
> streamDownload and stepwise options turned on hangs and causes timeout.*
> I prepared a test which triggers the error. The patch file is pretty big, as
> I had to make a file enough big to make the timeout happen. Basing on my
> predictions, the size of the file triggering the error depends on FTP
> configuration and Java caching policy (no proof available yet). Working with
> plain Vsftpd server even 1mb files triggered timeouts. In the test
> environment the limit on my desktop is 5 mb. If the test passes, please make
> the file bigger.
> My intepretation of the problem:
> # Start downloading a file with size exceeding InputStream cache (on my pc
> approx. 1mb is the limit).
>
> [FtpOperations.java:373|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L423]
> {code:java}
> InputStream is = this.client.retrieveFileStream(remoteName);
> {code}
> # The server responds 150 and opens data connection.
> {code:java}
> [user_ftp] FTP response: Client "127.0.0.1", "150 Opening BINARY mode data
> connection for x (1048576 bytes)."
> {code}
> # The data connection does not end because InputStream is waiting for reads
> and it has not cached whole file. No "226 Transfer complete" response from
> server.
> # Try to change directory as stepwise is turned on.
>
> [FtpOperations.java:387|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L443]
> {code:java}
> this.changeCurrentDirectory(currentDir);
> {code}
> # Camel hangs as the server is still in the data connection and we are
> waiting for response from CWD command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-12078) MIME-Mutipart DataFormat reads attachment DataSource twice
[ https://issues.apache.org/jira/browse/CAMEL-12078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306972#comment-17306972 ] Claus Ibsen commented on CAMEL-12078: - Thanks, Tim for the test case. This one was a bit more tricky to get to the bottom, as it is javax-mail that reads the stream to determine encoding for each part that build up the multipart message. So we can fix this by setting explicit the Content-Transfer-Encoding header on every part so this does not happen. > MIME-Mutipart DataFormat reads attachment DataSource twice > -- > > Key: CAMEL-12078 > URL: https://issues.apache.org/jira/browse/CAMEL-12078 > Project: Camel > Issue Type: Bug > Components: camel-mail >Affects Versions: 2.20.1 >Reporter: Tim Dudgeon >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > > As reported on mailing list if an attachment for MIME-Mutipart DataFormat is > defined using a DataSource that can only be read once you get an exception. > http://mail-archives.apache.org/mod_mbox/camel-users/201712.mbox/%3C0e0d4b2e-dc32-c61e-3ccd-7ee14238c485%40gmail.com%3E > For instance, this happens if the DataSource is created using an InputStream > that cannot be read multiple times > It should be possible to post the data only reading the input a single time. > I will add a test case shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-12078) MIME-Mutipart DataFormat reads attachment DataSource twice
[ https://issues.apache.org/jira/browse/CAMEL-12078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-12078. - Resolution: Fixed > MIME-Mutipart DataFormat reads attachment DataSource twice > -- > > Key: CAMEL-12078 > URL: https://issues.apache.org/jira/browse/CAMEL-12078 > Project: Camel > Issue Type: Bug > Components: camel-mail >Affects Versions: 2.20.1 >Reporter: Tim Dudgeon >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > > As reported on mailing list if an attachment for MIME-Mutipart DataFormat is > defined using a DataSource that can only be read once you get an exception. > http://mail-archives.apache.org/mod_mbox/camel-users/201712.mbox/%3C0e0d4b2e-dc32-c61e-3ccd-7ee14238c485%40gmail.com%3E > For instance, this happens if the DataSource is created using an InputStream > that cannot be read multiple times > It should be possible to post the data only reading the input a single time. > I will add a test case shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-12078) MIME-Mutipart DataFormat reads attachment DataSource twice
[ https://issues.apache.org/jira/browse/CAMEL-12078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-12078: --- Assignee: Claus Ibsen > MIME-Mutipart DataFormat reads attachment DataSource twice > -- > > Key: CAMEL-12078 > URL: https://issues.apache.org/jira/browse/CAMEL-12078 > Project: Camel > Issue Type: Bug > Components: camel-mail >Affects Versions: 2.20.1 >Reporter: Tim Dudgeon >Assignee: Claus Ibsen >Priority: Minor > Fix For: Future > > > As reported on mailing list if an attachment for MIME-Mutipart DataFormat is > defined using a DataSource that can only be read once you get an exception. > http://mail-archives.apache.org/mod_mbox/camel-users/201712.mbox/%3C0e0d4b2e-dc32-c61e-3ccd-7ee14238c485%40gmail.com%3E > For instance, this happens if the DataSource is created using an InputStream > that cannot be read multiple times > It should be possible to post the data only reading the input a single time. > I will add a test case shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-12078) MIME-Mutipart DataFormat reads attachment DataSource twice
[ https://issues.apache.org/jira/browse/CAMEL-12078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-12078: Fix Version/s: (was: Future) 3.10.0 > MIME-Mutipart DataFormat reads attachment DataSource twice > -- > > Key: CAMEL-12078 > URL: https://issues.apache.org/jira/browse/CAMEL-12078 > Project: Camel > Issue Type: Bug > Components: camel-mail >Affects Versions: 2.20.1 >Reporter: Tim Dudgeon >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > > As reported on mailing list if an attachment for MIME-Mutipart DataFormat is > defined using a DataSource that can only be read once you get an exception. > http://mail-archives.apache.org/mod_mbox/camel-users/201712.mbox/%3C0e0d4b2e-dc32-c61e-3ccd-7ee14238c485%40gmail.com%3E > For instance, this happens if the DataSource is created using an InputStream > that cannot be read multiple times > It should be possible to post the data only reading the input a single time. > I will add a test case shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-11846) xtokenize and apply xslt to a string does not work with UTF-16BE
[ https://issues.apache.org/jira/browse/CAMEL-11846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-11846. - Fix Version/s: 3.10.0 Assignee: Claus Ibsen Resolution: Fixed CAMEL-13374 fixes this as we use a xml reader that understands the encoding in the declaration > xtokenize and apply xslt to a string does not work with UTF-16BE > - > > Key: CAMEL-11846 > URL: https://issues.apache.org/jira/browse/CAMEL-11846 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.17.5 >Reporter: Robert Half >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > Attachments: UTF-16BE (with BOM).png, my example looks like this > (and it's really UTF-16BE).png > > > In XML, encoding is often provided inside tag. In general, you > cannot read the tag, if you don't know the encoding, but XML Parsers support > the detection of several encodings which allows them to read the tag. With > that information they can read the whole file without knowing the "charset" > in first place. > xtokenize and xslt use XmlInputFactory#createXmlStreamReader(Reader). But by > providing a reader Camel tells, that it knows the encoding, so it won't be > detected by the XML parser. > Also Camel sets the charset to UTF-8 if it is not provided inside a header. > This makes the underlying reader fail reading UTF-16. > Using XmlInputFactory#createXmlStreamReader(InputStream) inside > XMLTokenExpressionIterator works (tried in a patch). But the next xslt steps > fails again because it again uses a Reader. > See Stackoverflow Question for reference: > [https://stackoverflow.com/questions/46322376/apache-camel-to-handle-encoding-declared-in-xml-file] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-16230) Placeholders not Working with CamelSpringBootTest and AdviceWith
[
https://issues.apache.org/jira/browse/CAMEL-16230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16230:
Component/s: (was: tests)
camel-core
> Placeholders not Working with CamelSpringBootTest and AdviceWith
>
>
> Key: CAMEL-16230
> URL: https://issues.apache.org/jira/browse/CAMEL-16230
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 3.7.2
>Reporter: Alex
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.10.0
>
>
> Unable to use camel placeholders in a CamelSpringBootTest:
> This does not work:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("{{camel.placeholder}}");
> });
> {code}
> This does:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("jpa:MyEntity");
> });
> {code}
> My route is defined like so:
> {code}
> from("{{camel.person.csv.file}}")
> .id("person-import")
> .unmarshal(bindy)
> .process(new CamelLogger())
> .to("{{camel.placeholder}}")
> ;
> {code}
> My placeholder is application.yaml of Spring Boot
> {code}
> camel:
> placeholder: "jpa:MyEntity"
> {code}
> Please advise
> Best Regards
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-16230) Placeholders not Working with CamelSpringBootTest and AdviceWith
[
https://issues.apache.org/jira/browse/CAMEL-16230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16230.
-
Resolution: Fixed
> Placeholders not Working with CamelSpringBootTest and AdviceWith
>
>
> Key: CAMEL-16230
> URL: https://issues.apache.org/jira/browse/CAMEL-16230
> Project: Camel
> Issue Type: Improvement
> Components: tests
>Affects Versions: 3.7.2
>Reporter: Alex
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.10.0
>
>
> Unable to use camel placeholders in a CamelSpringBootTest:
> This does not work:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("{{camel.placeholder}}");
> });
> {code}
> This does:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("jpa:MyEntity");
> });
> {code}
> My route is defined like so:
> {code}
> from("{{camel.person.csv.file}}")
> .id("person-import")
> .unmarshal(bindy)
> .process(new CamelLogger())
> .to("{{camel.placeholder}}")
> ;
> {code}
> My placeholder is application.yaml of Spring Boot
> {code}
> camel:
> placeholder: "jpa:MyEntity"
> {code}
> Please advise
> Best Regards
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-16230) Placeholders not Working with CamelSpringBootTest and AdviceWith
[
https://issues.apache.org/jira/browse/CAMEL-16230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306897#comment-17306897
]
Claus Ibsen edited comment on CAMEL-16230 at 3/23/21, 8:46 AM:
---
This is only those special methods in AdviceWithRoyteBuilder like the
mockEndpointAndSkip you are using. You can resolve the placeholder first with
String pattern =
getContext().resolvePropertyPlaceholders("{{camel.placeholder}}");
route.mockEndpointsAndSkip(pattern);
was (Author: davsclaus):
This is only those special methods in AdviceWithRoyteBuilder like the
mockEndpointAndSkip you are using. You can resolve the placeholder first with
String pattern =
getContext().resolvePropertyPlaceholders("{{camel.placeholder");
route.mockEndpointsAndSkip(pattern);
> Placeholders not Working with CamelSpringBootTest and AdviceWith
>
>
> Key: CAMEL-16230
> URL: https://issues.apache.org/jira/browse/CAMEL-16230
> Project: Camel
> Issue Type: Improvement
> Components: tests
>Affects Versions: 3.7.2
>Reporter: Alex
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.10.0
>
>
> Unable to use camel placeholders in a CamelSpringBootTest:
> This does not work:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("{{camel.placeholder}}");
> });
> {code}
> This does:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("jpa:MyEntity");
> });
> {code}
> My route is defined like so:
> {code}
> from("{{camel.person.csv.file}}")
> .id("person-import")
> .unmarshal(bindy)
> .process(new CamelLogger())
> .to("{{camel.placeholder}}")
> ;
> {code}
> My placeholder is application.yaml of Spring Boot
> {code}
> camel:
> placeholder: "jpa:MyEntity"
> {code}
> Please advise
> Best Regards
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-16230) Placeholders not Working with CamelSpringBootTest and AdviceWith
[
https://issues.apache.org/jira/browse/CAMEL-16230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306897#comment-17306897
]
Claus Ibsen edited comment on CAMEL-16230 at 3/23/21, 8:46 AM:
---
This is only those special methods in AdviceWithRoyteBuilder like the
mockEndpointAndSkip you are using. You can resolve the placeholder first with
{code}
String pattern =
getContext().resolvePropertyPlaceholders("{{camel.placeholder}}");
route.mockEndpointsAndSkip(pattern);
{code}
was (Author: davsclaus):
This is only those special methods in AdviceWithRoyteBuilder like the
mockEndpointAndSkip you are using. You can resolve the placeholder first with
String pattern =
getContext().resolvePropertyPlaceholders("{{camel.placeholder}}");
route.mockEndpointsAndSkip(pattern);
> Placeholders not Working with CamelSpringBootTest and AdviceWith
>
>
> Key: CAMEL-16230
> URL: https://issues.apache.org/jira/browse/CAMEL-16230
> Project: Camel
> Issue Type: Improvement
> Components: tests
>Affects Versions: 3.7.2
>Reporter: Alex
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.10.0
>
>
> Unable to use camel placeholders in a CamelSpringBootTest:
> This does not work:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("{{camel.placeholder}}");
> });
> {code}
> This does:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("jpa:MyEntity");
> });
> {code}
> My route is defined like so:
> {code}
> from("{{camel.person.csv.file}}")
> .id("person-import")
> .unmarshal(bindy)
> .process(new CamelLogger())
> .to("{{camel.placeholder}}")
> ;
> {code}
> My placeholder is application.yaml of Spring Boot
> {code}
> camel:
> placeholder: "jpa:MyEntity"
> {code}
> Please advise
> Best Regards
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-16230) Placeholders not Working with CamelSpringBootTest and AdviceWith
[
https://issues.apache.org/jira/browse/CAMEL-16230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306897#comment-17306897
]
Claus Ibsen commented on CAMEL-16230:
-
This is only those special methods in AdviceWithRoyteBuilder like the
mockEndpointAndSkip you are using. You can resolve the placeholder first with
String pattern =
getContext().resolvePropertyPlaceholders("{{camel.placeholder");
route.mockEndpointsAndSkip(pattern);
> Placeholders not Working with CamelSpringBootTest and AdviceWith
>
>
> Key: CAMEL-16230
> URL: https://issues.apache.org/jira/browse/CAMEL-16230
> Project: Camel
> Issue Type: Improvement
> Components: tests
>Affects Versions: 3.7.2
>Reporter: Alex
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.10.0
>
>
> Unable to use camel placeholders in a CamelSpringBootTest:
> This does not work:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("{{camel.placeholder}}");
> });
> {code}
> This does:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("jpa:MyEntity");
> });
> {code}
> My route is defined like so:
> {code}
> from("{{camel.person.csv.file}}")
> .id("person-import")
> .unmarshal(bindy)
> .process(new CamelLogger())
> .to("{{camel.placeholder}}")
> ;
> {code}
> My placeholder is application.yaml of Spring Boot
> {code}
> camel:
> placeholder: "jpa:MyEntity"
> {code}
> Please advise
> Best Regards
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16230) Placeholders not Working with CamelSpringBootTest and AdviceWith
[
https://issues.apache.org/jira/browse/CAMEL-16230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16230:
Fix Version/s: 3.10.0
> Placeholders not Working with CamelSpringBootTest and AdviceWith
>
>
> Key: CAMEL-16230
> URL: https://issues.apache.org/jira/browse/CAMEL-16230
> Project: Camel
> Issue Type: Improvement
> Components: tests
>Affects Versions: 3.7.2
>Reporter: Alex
>Priority: Minor
> Fix For: 3.10.0
>
>
> Unable to use camel placeholders in a CamelSpringBootTest:
> This does not work:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("{{camel.placeholder}}");
> });
> {code}
> This does:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("jpa:MyEntity");
> });
> {code}
> My route is defined like so:
> {code}
> from("{{camel.person.csv.file}}")
> .id("person-import")
> .unmarshal(bindy)
> .process(new CamelLogger())
> .to("{{camel.placeholder}}")
> ;
> {code}
> My placeholder is application.yaml of Spring Boot
> {code}
> camel:
> placeholder: "jpa:MyEntity"
> {code}
> Please advise
> Best Regards
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-16230) Placeholders not Working with CamelSpringBootTest and AdviceWith
[
https://issues.apache.org/jira/browse/CAMEL-16230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306893#comment-17306893
]
Claus Ibsen commented on CAMEL-16230:
-
Placeholders was not supported there, but its a good idea to add support for
this
> Placeholders not Working with CamelSpringBootTest and AdviceWith
>
>
> Key: CAMEL-16230
> URL: https://issues.apache.org/jira/browse/CAMEL-16230
> Project: Camel
> Issue Type: Improvement
> Components: tests
>Affects Versions: 3.7.2
>Reporter: Alex
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.10.0
>
>
> Unable to use camel placeholders in a CamelSpringBootTest:
> This does not work:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("{{camel.placeholder}}");
> });
> {code}
> This does:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("jpa:MyEntity");
> });
> {code}
> My route is defined like so:
> {code}
> from("{{camel.person.csv.file}}")
> .id("person-import")
> .unmarshal(bindy)
> .process(new CamelLogger())
> .to("{{camel.placeholder}}")
> ;
> {code}
> My placeholder is application.yaml of Spring Boot
> {code}
> camel:
> placeholder: "jpa:MyEntity"
> {code}
> Please advise
> Best Regards
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16230) Placeholders not Working with CamelSpringBootTest and AdviceWith
[
https://issues.apache.org/jira/browse/CAMEL-16230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16230:
Issue Type: Improvement (was: Bug)
> Placeholders not Working with CamelSpringBootTest and AdviceWith
>
>
> Key: CAMEL-16230
> URL: https://issues.apache.org/jira/browse/CAMEL-16230
> Project: Camel
> Issue Type: Improvement
> Components: tests
>Affects Versions: 3.7.2
>Reporter: Alex
>Priority: Minor
>
> Unable to use camel placeholders in a CamelSpringBootTest:
> This does not work:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("{{camel.placeholder}}");
> });
> {code}
> This does:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("jpa:MyEntity");
> });
> {code}
> My route is defined like so:
> {code}
> from("{{camel.person.csv.file}}")
> .id("person-import")
> .unmarshal(bindy)
> .process(new CamelLogger())
> .to("{{camel.placeholder}}")
> ;
> {code}
> My placeholder is application.yaml of Spring Boot
> {code}
> camel:
> placeholder: "jpa:MyEntity"
> {code}
> Please advise
> Best Regards
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-16230) Placeholders not Working with CamelSpringBootTest and AdviceWith
[
https://issues.apache.org/jira/browse/CAMEL-16230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-16230:
---
Assignee: Claus Ibsen
> Placeholders not Working with CamelSpringBootTest and AdviceWith
>
>
> Key: CAMEL-16230
> URL: https://issues.apache.org/jira/browse/CAMEL-16230
> Project: Camel
> Issue Type: Improvement
> Components: tests
>Affects Versions: 3.7.2
>Reporter: Alex
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.10.0
>
>
> Unable to use camel placeholders in a CamelSpringBootTest:
> This does not work:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("{{camel.placeholder}}");
> });
> {code}
> This does:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("jpa:MyEntity");
> });
> {code}
> My route is defined like so:
> {code}
> from("{{camel.person.csv.file}}")
> .id("person-import")
> .unmarshal(bindy)
> .process(new CamelLogger())
> .to("{{camel.placeholder}}")
> ;
> {code}
> My placeholder is application.yaml of Spring Boot
> {code}
> camel:
> placeholder: "jpa:MyEntity"
> {code}
> Please advise
> Best Regards
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16230) Placeholders not Working with CamelSpringBootTest and AdviceWith
[
https://issues.apache.org/jira/browse/CAMEL-16230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16230:
Priority: Minor (was: Major)
> Placeholders not Working with CamelSpringBootTest and AdviceWith
>
>
> Key: CAMEL-16230
> URL: https://issues.apache.org/jira/browse/CAMEL-16230
> Project: Camel
> Issue Type: Bug
> Components: tests
>Affects Versions: 3.7.2
>Reporter: Alex
>Priority: Minor
>
> Unable to use camel placeholders in a CamelSpringBootTest:
> This does not work:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("{{camel.placeholder}}");
> });
> {code}
> This does:
> {code}
> AdviceWith.adviceWith(camelContext, "person-import", route -> {
> route.replaceFromWith("direct:csv");
> route.mockEndpointsAndSkip("jpa:MyEntity");
> });
> {code}
> My route is defined like so:
> {code}
> from("{{camel.person.csv.file}}")
> .id("person-import")
> .unmarshal(bindy)
> .process(new CamelLogger())
> .to("{{camel.placeholder}}")
> ;
> {code}
> My placeholder is application.yaml of Spring Boot
> {code}
> camel:
> placeholder: "jpa:MyEntity"
> {code}
> Please advise
> Best Regards
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-13374) XMLTokenExpressionIterator Default Exchange charset overrides original xml encoding from InputStream
[ https://issues.apache.org/jira/browse/CAMEL-13374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-13374. - Resolution: Fixed > XMLTokenExpressionIterator Default Exchange charset overrides original xml > encoding from InputStream > > > Key: CAMEL-13374 > URL: https://issues.apache.org/jira/browse/CAMEL-13374 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.0, 2.22.0 >Reporter: Sergey Smith >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > > Default Exchange charset overrides original xml encoding from InputStream > at > org.apache.camel.support.XMLTokenExpressionIterator.doEvaluate(Exchange > exchange, boolean closeStream) > _String charset = IOHelper.getCharsetName(exchange);_ > must be replaced with > _String charset = IOHelper.getCharsetName(exchange, *false*);_ > then at > _// woodstox's getLocation().etCharOffset() does not return the offset > correctly for InputStream, so use Reader instead._ > _this(path, nsmap, mode, group, new *InputStreamReader*(in, charset));_ > _and_ > _// woodstox's getLocation().etCharOffset() does not return the offset > correctly for InputStream, so use Reader instead._ > _this(path, nsmap, mode, 1, new *InputStreamReader*(in, charset));_ > lines use > org.apache.commons.io.input.XmlStreamReader instead of just InputStreamReader > it correctly determinants encoding from xml header when it present. > > Examle document at InputStream body: > __ > __ > Current _charset_ result: is UTF-8 (*default* from > _IOHelper.getCharsetName(exchange)_) > Expected result: _ISO-8859-5_ > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-13374) XMLTokenExpressionIterator Default Exchange charset overrides original xml encoding from InputStream
[ https://issues.apache.org/jira/browse/CAMEL-13374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306804#comment-17306804 ] Claus Ibsen commented on CAMEL-13374: - We can use camel-xml-io which has a XmlStreamReader that can read the charset from the xml declaration. > XMLTokenExpressionIterator Default Exchange charset overrides original xml > encoding from InputStream > > > Key: CAMEL-13374 > URL: https://issues.apache.org/jira/browse/CAMEL-13374 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.0, 2.22.0 >Reporter: Sergey Smith >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > > Default Exchange charset overrides original xml encoding from InputStream > at > org.apache.camel.support.XMLTokenExpressionIterator.doEvaluate(Exchange > exchange, boolean closeStream) > _String charset = IOHelper.getCharsetName(exchange);_ > must be replaced with > _String charset = IOHelper.getCharsetName(exchange, *false*);_ > then at > _// woodstox's getLocation().etCharOffset() does not return the offset > correctly for InputStream, so use Reader instead._ > _this(path, nsmap, mode, group, new *InputStreamReader*(in, charset));_ > _and_ > _// woodstox's getLocation().etCharOffset() does not return the offset > correctly for InputStream, so use Reader instead._ > _this(path, nsmap, mode, 1, new *InputStreamReader*(in, charset));_ > lines use > org.apache.commons.io.input.XmlStreamReader instead of just InputStreamReader > it correctly determinants encoding from xml header when it present. > > Examle document at InputStream body: > __ > __ > Current _charset_ result: is UTF-8 (*default* from > _IOHelper.getCharsetName(exchange)_) > Expected result: _ISO-8859-5_ > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-13374) XMLTokenExpressionIterator Default Exchange charset overrides original xml encoding from InputStream
[ https://issues.apache.org/jira/browse/CAMEL-13374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-13374: --- Assignee: Claus Ibsen > XMLTokenExpressionIterator Default Exchange charset overrides original xml > encoding from InputStream > > > Key: CAMEL-13374 > URL: https://issues.apache.org/jira/browse/CAMEL-13374 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.0, 2.22.0 >Reporter: Sergey Smith >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.x > > > Default Exchange charset overrides original xml encoding from InputStream > at > org.apache.camel.support.XMLTokenExpressionIterator.doEvaluate(Exchange > exchange, boolean closeStream) > _String charset = IOHelper.getCharsetName(exchange);_ > must be replaced with > _String charset = IOHelper.getCharsetName(exchange, *false*);_ > then at > _// woodstox's getLocation().etCharOffset() does not return the offset > correctly for InputStream, so use Reader instead._ > _this(path, nsmap, mode, group, new *InputStreamReader*(in, charset));_ > _and_ > _// woodstox's getLocation().etCharOffset() does not return the offset > correctly for InputStream, so use Reader instead._ > _this(path, nsmap, mode, 1, new *InputStreamReader*(in, charset));_ > lines use > org.apache.commons.io.input.XmlStreamReader instead of just InputStreamReader > it correctly determinants encoding from xml header when it present. > > Examle document at InputStream body: > __ > __ > Current _charset_ result: is UTF-8 (*default* from > _IOHelper.getCharsetName(exchange)_) > Expected result: _ISO-8859-5_ > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-13374) XMLTokenExpressionIterator Default Exchange charset overrides original xml encoding from InputStream
[ https://issues.apache.org/jira/browse/CAMEL-13374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-13374: Fix Version/s: (was: 3.x) 3.10.0 > XMLTokenExpressionIterator Default Exchange charset overrides original xml > encoding from InputStream > > > Key: CAMEL-13374 > URL: https://issues.apache.org/jira/browse/CAMEL-13374 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.0, 2.22.0 >Reporter: Sergey Smith >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.10.0 > > > Default Exchange charset overrides original xml encoding from InputStream > at > org.apache.camel.support.XMLTokenExpressionIterator.doEvaluate(Exchange > exchange, boolean closeStream) > _String charset = IOHelper.getCharsetName(exchange);_ > must be replaced with > _String charset = IOHelper.getCharsetName(exchange, *false*);_ > then at > _// woodstox's getLocation().etCharOffset() does not return the offset > correctly for InputStream, so use Reader instead._ > _this(path, nsmap, mode, group, new *InputStreamReader*(in, charset));_ > _and_ > _// woodstox's getLocation().etCharOffset() does not return the offset > correctly for InputStream, so use Reader instead._ > _this(path, nsmap, mode, 1, new *InputStreamReader*(in, charset));_ > lines use > org.apache.commons.io.input.XmlStreamReader instead of just InputStreamReader > it correctly determinants encoding from xml header when it present. > > Examle document at InputStream body: > __ > __ > Current _charset_ result: is UTF-8 (*default* from > _IOHelper.getCharsetName(exchange)_) > Expected result: _ISO-8859-5_ > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-11998) Configuring SSL via endpointProperty in restConfiguration for an Undertow component will cause a BindException for multiple endpoints
[
https://issues.apache.org/jira/browse/CAMEL-11998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-11998.
-
Resolution: Abandoned
> Configuring SSL via endpointProperty in restConfiguration for an Undertow
> component will cause a BindException for multiple endpoints
> -
>
> Key: CAMEL-11998
> URL: https://issues.apache.org/jira/browse/CAMEL-11998
> Project: Camel
> Issue Type: Bug
> Components: camel-undertow
>Affects Versions: 2.19.0, 2.20.0
> Environment: MacBookPro 15' with Mac OS X (10.12.6), Oracle Java
> 1.8.144
>Reporter: Roman Vottner
>Priority: Major
> Fix For: 3.x
>
>
> On recreating the test case depicted in
> https://github.com/apache/camel/blob/master/components/camel-undertow/src/test/java/org/apache/camel/component/undertow/rest/RestApiUndertowTest.java
> and activating SSL configuration, I noticed that multiple endpoints exposed
> will configure multiple Undertow consumers which all try to bind onto the
> same port and thus throw a BindException.
> The full Test-Code looks as follows:
> {code:java}
> import static org.hamcrest.CoreMatchers.equalTo;
> import static org.hamcrest.CoreMatchers.is;
> import at.rovo.utils.TestHttpClient;
> import io.undertow.server.HttpServerExchange;
> import java.net.InetSocketAddress;
> import java.net.URL;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.Map;
> import javax.annotation.Resource;
> import javax.net.ssl.SSLSession;
> import org.apache.camel.CamelContext;
> import org.apache.camel.Exchange;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.component.properties.PropertiesComponent;
> import org.apache.camel.component.undertow.RestUndertowHttpBinding;
> import org.apache.camel.component.undertow.UndertowHttpBinding;
> import org.apache.camel.model.rest.RestParamType;
> import org.apache.camel.spring.javaconfig.CamelConfiguration;
> import org.apache.camel.test.spring.CamelSpringRunner;
> import org.apache.camel.test.spring.CamelTestContextBootstrapper;
> import org.apache.camel.util.jsse.KeyManagersParameters;
> import org.apache.camel.util.jsse.KeyStoreParameters;
> import org.apache.camel.util.jsse.SSLContextParameters;
> import org.apache.camel.util.jsse.TrustManagersParameters;
> import org.junit.Assert;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.springframework.context.annotation.Bean;
> import org.springframework.context.annotation.Configuration;
> import org.springframework.context.annotation.PropertySource;
> import org.springframework.core.env.Environment;
> import org.springframework.test.context.BootstrapWith;
> import org.springframework.test.context.ContextConfiguration;
> import org.springframework.test.context.support.AnnotationConfigContextLoader;
> @RunWith(CamelSpringRunner.class)
> @BootstrapWith(CamelTestContextBootstrapper.class)
> @ContextConfiguration(loader = AnnotationConfigContextLoader.class,
> classes = {UndertowRouteTest.ContextConfig.class})
> public class UndertowRouteTest {
> private static final String REMOTE_IP = "REMOTE_IP";
> private static final String REMOTE_PORT = "REMOTE_PORT";
> private static final String USER_AGENT = "USER_AGENT";
> private static final String TLS_PROTOCOL_VERSION = "TLS_PROTOCOL_VERSION";
> private static final String TLS_CIPHER_SUITE = "TLS_CIPHER_SUITE";
> @Configuration
> @PropertySource({"classpath:test.properties"})
> public static class ContextConfig extends CamelConfiguration {
> @Resource
> private Environment env;
> @Bean(name = "undertowHttpBinding")
> public UndertowHttpBinding undertowHttpBinding() {
> return new IPResolvableRestUndertowHttpBinding();
> }
> public static class IPResolvableRestUndertowHttpBinding extends
> RestUndertowHttpBinding {
> @Override
> public void populateCamelHeaders(HttpServerExchange httpExchange,
> Map headersMap, Exchange exchange) throws Exception {
> super.populateCamelHeaders(httpExchange, headersMap, exchange);
> InetSocketAddress peer = httpExchange.getSourceAddress();
> headersMap.put(REMOTE_IP, peer.getAddress().getHostAddress());
> headersMap.put(REMOTE_PORT, peer.getPort());
> for (String key : headersMap.keySet()) {
> if (key.toLowerCase().equals("user-agent")) {
> headersMap.put(USER_AGENT, headersMap.get(key));
> }
> }
> if (null != httpExchange.getConnection().getSslSessionInfo()
> && null !=
> httpExchange.getConnection().getSslSessionInfo().getSSLSession()) {
> SSLSession sslSession =
>
[jira] [Resolved] (CAMEL-16316) ProducerTemplate asyncSend is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-16316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16316.
-
Resolution: Fixed
Added note to javadoc about the thread-safety issue
> ProducerTemplate asyncSend is not thread safe
> -
>
> Key: CAMEL-16316
> URL: https://issues.apache.org/jira/browse/CAMEL-16316
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.1.0, 3.7.2
>Reporter: Zoltán Nébli
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.10.0
>
>
> The
> {code:java}
> CompletableFuture asyncSend(String endpointUri, Processor
> processor){code}
> method is not thread safe because the processor is passed as a lambda to the
> executor service:
> {code:java}
> getExecutorService().submit(() ->
> getProducerCache().asyncSendExchange(endpoint, pattern, processor,
> resultProcessor, inExchange, exchangeFuture));{code}
> and therefore if the caller use the original Exchange reference in the
> Processor, for example
> {code:java}
> request -> request.setBody(originalExchange.getIn().getBody(...)){code}
> the executorService thread will use a dirty Exchange body in cases where the
> original executor thread runs faster.
> On the other hand this method is thread safe because the new Exchange object
> can be populated from the original exchange:
> {code:java}
> CompletableFuture asyncSend(String endpointUri, Exchange
> exchange){code}
> I think the solution would be processing the request with the passed
> processor then submit the job to the executor service or clearly mention this
> in the API doc. This behavior is currently not straightforward.
> Of course you can pass references with the 2. method also which will become
> dirty but I think the clear intention here is sending a clean Exchange
> asynchronously to an endpoint with either a Processor or an exact Exchange
> object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-16316) ProducerTemplate asyncSend is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-16316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-16316:
---
Assignee: Claus Ibsen
> ProducerTemplate asyncSend is not thread safe
> -
>
> Key: CAMEL-16316
> URL: https://issues.apache.org/jira/browse/CAMEL-16316
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.1.0, 3.7.2
>Reporter: Zoltán Nébli
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.10.0
>
>
> The
> {code:java}
> CompletableFuture asyncSend(String endpointUri, Processor
> processor){code}
> method is not thread safe because the processor is passed as a lambda to the
> executor service:
> {code:java}
> getExecutorService().submit(() ->
> getProducerCache().asyncSendExchange(endpoint, pattern, processor,
> resultProcessor, inExchange, exchangeFuture));{code}
> and therefore if the caller use the original Exchange reference in the
> Processor, for example
> {code:java}
> request -> request.setBody(originalExchange.getIn().getBody(...)){code}
> the executorService thread will use a dirty Exchange body in cases where the
> original executor thread runs faster.
> On the other hand this method is thread safe because the new Exchange object
> can be populated from the original exchange:
> {code:java}
> CompletableFuture asyncSend(String endpointUri, Exchange
> exchange){code}
> I think the solution would be processing the request with the passed
> processor then submit the job to the executor service or clearly mention this
> in the API doc. This behavior is currently not straightforward.
> Of course you can pass references with the 2. method also which will become
> dirty but I think the clear intention here is sending a clean Exchange
> asynchronously to an endpoint with either a Processor or an exact Exchange
> object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
