[jira] [Commented] (CAMEL-20668) camel-sftp - Issue with autoCreateKnownHostsFile
[
https://issues.apache.org/jira/browse/CAMEL-20668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836716#comment-17836716
]
Claus Ibsen commented on CAMEL-20668:
-
What do you see in the logs, Camel should log something about file not exists,
create yes/no
> camel-sftp - Issue with autoCreateKnownHostsFile
> -
>
> Key: CAMEL-20668
> URL: https://issues.apache.org/jira/browse/CAMEL-20668
> Project: Camel
> Issue Type: Bug
> Components: camel-sftp
>Affects Versions: 4.4.1
>Reporter: Saravanakumar Selvaraj
>Priority: Minor
>
> I'm encountering a problem with {{camel-sftp}} where the
> {{autoCreateKnownHostsFile}} option doesn't seem to be functioning as
> expected. According to the documentation, setting
> {{autoCreateKnownHostsFile}} to {{true}} should automatically create the
> known hosts file if it doesn't exist. However, in my testing, the file is not
> being created as expected.
> *Steps to Reproduce:*
> # Configure {{camel-sftp}} route with {{autoCreateKnownHostsFile}} set to
> {{{}true{}}}.
> # Start the application and establish an SFTP connection.
> # Check if the known hosts file is created in the specified location.
> *Expected Behavior:* The {{autoCreateKnownHostsFile}} option should create
> the known hosts file if it doesn't exist, ensuring that host key verification
> works as intended.
> *Actual Behavior:* The known hosts file is not created automatically, leading
> to host key verification issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (CAMEL-20668) camel-sftp - Issue with autoCreateKnownHostsFile
[ https://issues.apache.org/jira/browse/CAMEL-20668 ]
Claus Ibsen deleted comment on CAMEL-20668:
-
was (Author: davsclaus):
Have you set knownHostFile also
> camel-sftp - Issue with autoCreateKnownHostsFile
> -
>
> Key: CAMEL-20668
> URL: https://issues.apache.org/jira/browse/CAMEL-20668
> Project: Camel
> Issue Type: Bug
> Components: camel-sftp
>Affects Versions: 4.4.1
>Reporter: Saravanakumar Selvaraj
>Priority: Minor
>
> I'm encountering a problem with {{camel-sftp}} where the
> {{autoCreateKnownHostsFile}} option doesn't seem to be functioning as
> expected. According to the documentation, setting
> {{autoCreateKnownHostsFile}} to {{true}} should automatically create the
> known hosts file if it doesn't exist. However, in my testing, the file is not
> being created as expected.
> *Steps to Reproduce:*
> # Configure {{camel-sftp}} route with {{autoCreateKnownHostsFile}} set to
> {{{}true{}}}.
> # Start the application and establish an SFTP connection.
> # Check if the known hosts file is created in the specified location.
> *Expected Behavior:* The {{autoCreateKnownHostsFile}} option should create
> the known hosts file if it doesn't exist, ensuring that host key verification
> works as intended.
> *Actual Behavior:* The known hosts file is not created automatically, leading
> to host key verification issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20668) camel-sftp - Issue with autoCreateKnownHostsFile
[
https://issues.apache.org/jira/browse/CAMEL-20668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20668:
Priority: Minor (was: Major)
> camel-sftp - Issue with autoCreateKnownHostsFile
> -
>
> Key: CAMEL-20668
> URL: https://issues.apache.org/jira/browse/CAMEL-20668
> Project: Camel
> Issue Type: Bug
> Components: camel-sftp
>Affects Versions: 4.4.1
>Reporter: Saravanakumar Selvaraj
>Priority: Minor
>
> I'm encountering a problem with {{camel-sftp}} where the
> {{autoCreateKnownHostsFile}} option doesn't seem to be functioning as
> expected. According to the documentation, setting
> {{autoCreateKnownHostsFile}} to {{true}} should automatically create the
> known hosts file if it doesn't exist. However, in my testing, the file is not
> being created as expected.
> *Steps to Reproduce:*
> # Configure {{camel-sftp}} route with {{autoCreateKnownHostsFile}} set to
> {{{}true{}}}.
> # Start the application and establish an SFTP connection.
> # Check if the known hosts file is created in the specified location.
> *Expected Behavior:* The {{autoCreateKnownHostsFile}} option should create
> the known hosts file if it doesn't exist, ensuring that host key verification
> works as intended.
> *Actual Behavior:* The known hosts file is not created automatically, leading
> to host key verification issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20668) camel-sftp - Issue with autoCreateKnownHostsFile
[
https://issues.apache.org/jira/browse/CAMEL-20668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836714#comment-17836714
]
Claus Ibsen commented on CAMEL-20668:
-
Have you set knownHostFile also
> camel-sftp - Issue with autoCreateKnownHostsFile
> -
>
> Key: CAMEL-20668
> URL: https://issues.apache.org/jira/browse/CAMEL-20668
> Project: Camel
> Issue Type: Bug
> Components: camel-sftp
>Affects Versions: 4.4.1
>Reporter: Saravanakumar Selvaraj
>Priority: Minor
>
> I'm encountering a problem with {{camel-sftp}} where the
> {{autoCreateKnownHostsFile}} option doesn't seem to be functioning as
> expected. According to the documentation, setting
> {{autoCreateKnownHostsFile}} to {{true}} should automatically create the
> known hosts file if it doesn't exist. However, in my testing, the file is not
> being created as expected.
> *Steps to Reproduce:*
> # Configure {{camel-sftp}} route with {{autoCreateKnownHostsFile}} set to
> {{{}true{}}}.
> # Start the application and establish an SFTP connection.
> # Check if the known hosts file is created in the specified location.
> *Expected Behavior:* The {{autoCreateKnownHostsFile}} option should create
> the known hosts file if it doesn't exist, ensuring that host key verification
> works as intended.
> *Actual Behavior:* The known hosts file is not created automatically, leading
> to host key verification issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20671) camel-core-model - DSL description should be attribute and not element in json metadata
[ https://issues.apache.org/jira/browse/CAMEL-20671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20671. - Resolution: Fixed > camel-core-model - DSL description should be attribute and not element in > json metadata > --- > > Key: CAMEL-20671 > URL: https://issues.apache.org/jira/browse/CAMEL-20671 > Project: Camel > Issue Type: Task > Components: camel-catalog >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20671) camel-core-model - DSL description should be attribute and not element in json metadata
Claus Ibsen created CAMEL-20671: --- Summary: camel-core-model - DSL description should be attribute and not element in json metadata Key: CAMEL-20671 URL: https://issues.apache.org/jira/browse/CAMEL-20671 Project: Camel Issue Type: Task Components: camel-catalog Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 4.6.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20563) camel-kafka - breakOnFirstError causes thread and memory leaks
[ https://issues.apache.org/jira/browse/CAMEL-20563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836687#comment-17836687 ] Claus Ibsen commented on CAMEL-20563: - https://camel.apache.org/blog/2023/12/camel3ending/ We will do a set of releases of 3.x in may/june > camel-kafka - breakOnFirstError causes thread and memory leaks > -- > > Key: CAMEL-20563 > URL: https://issues.apache.org/jira/browse/CAMEL-20563 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.5, 3.22.1 >Reporter: Aniket Jadhav >Priority: Major > Fix For: 3.21.5, 3.22.2, 4.0.5, 4.4.2, 4.5.0 > > Attachments: KafkaHeartBeatLeakThread.PNG, > heartbeat-threading-problem.zip > > > This has got fixed in > [CAMEL-16857|https://issues.apache.org/jira/browse/CAMEL-16857]. But Facing > same issue with 3.18.5, is it reintroduced at some point? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-17088) Provide a GraphQL consumer
[ https://issues.apache.org/jira/browse/CAMEL-17088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836686#comment-17836686 ] Claus Ibsen commented on CAMEL-17088: - Yes you are welcome, thanks > Provide a GraphQL consumer > -- > > Key: CAMEL-17088 > URL: https://issues.apache.org/jira/browse/CAMEL-17088 > Project: Camel > Issue Type: New Feature > Components: camel-graphql >Reporter: Luca Ferrari >Priority: Minor > Labels: help-wanted > > at the moment only producer is supported but there are libraries that allow > for supporting this scenario as well > [https://www.graphql-java.com/tutorials/getting-started-with-spring-boot/] > it would be interesting to offer an alternative to something like Apollo > Server based on camel, with all the possible transformation and logic that > you can apply to query and response -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17088) Provide a GraphQL consumer
[ https://issues.apache.org/jira/browse/CAMEL-17088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17088: Fix Version/s: 4.x > Provide a GraphQL consumer > -- > > Key: CAMEL-17088 > URL: https://issues.apache.org/jira/browse/CAMEL-17088 > Project: Camel > Issue Type: New Feature > Components: camel-graphql >Reporter: Luca Ferrari >Priority: Minor > Labels: help-wanted > Fix For: 4.x > > > at the moment only producer is supported but there are libraries that allow > for supporting this scenario as well > [https://www.graphql-java.com/tutorials/getting-started-with-spring-boot/] > it would be interesting to offer an alternative to something like Apollo > Server based on camel, with all the possible transformation and logic that > you can apply to query and response -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18017) camel-as2 - Signed content in MDN gets corrupted and is not possible to validate
[
https://issues.apache.org/jira/browse/CAMEL-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836685#comment-17836685
]
Claus Ibsen commented on CAMEL-18017:
-
Thanks
> camel-as2 - Signed content in MDN gets corrupted and is not possible to
> validate
>
>
> Key: CAMEL-18017
> URL: https://issues.apache.org/jira/browse/CAMEL-18017
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Affects Versions: 3.16.0
>Reporter: Ted Lundqvist
>Assignee: Jono Morris
>Priority: Minor
> Fix For: 4.4.2, 4.6.0
>
>
> When the http response with an MDN is received it is parsed to a
> MultipartSignedEntity-object.
> When the object is serialized back to an outputstream using the method
> AS2MessageDispositionNotificationEntity#writeTo the string is not guaranteed
> to be identical to the the string received in the original http-response.
> This makes it impossible to calculate an correct message-digest and the
> method MultipartSignedEntity#isValid returns false because the following
> exception is thrown:
> "org.bouncycastle.cms.CMSSignerDigestMismatchException: message-digest
> attribute value does not match calculated value"
> when calling:
> signer.verify(new
> JcaSimpleSignerInfoVerifierBuilder().setProvider("BC").build(cert)
> I tried to use the AS2-client to send messeages to both IBM Datapower and
> ArcESB and it was not possible to validate the MDN from neither of them.
> A few examples of differences between the actual received string and the
> reconstructed string are (see the full examples further down):
> # The order of the fields in the disposition-notification was in the wrong
> order:
> In the original string they where ordered as follows:
> Reporting-UA
> Original-Recipient
> Final-Recipient
> Original-Message-ID
> Disposition
> Received-content-MIC
> But in the reconstructed string the field Original-Recipient had been moved
> down and was placed before Received-content-MIC.
> # Received-content-MIC returned from both Datapower and ArcESB had a space
> between the comma-sign and the algorithmId.
> In the reconstructed string the space-character was removed.
> According to the example in RFC4130
> ([https://datatracker.ietf.org/doc/html/rfc4130)] is seems as if it should be
> ok to have a space-character.
> # In the MDN from ArcESB the field Received-content-MIC the word content was
> written with a capital 'C' i.e. Received-Content-MIC.
> I'm not sure if that is valid according to the standard or not.
> The actual string received in the http-response:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Original-Recipient: rfc822; "TEST"
> Final-Recipient: rfc822; "TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically; processed
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,
> sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> The String reconstructed from the MultipartSignedEntity:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Final-Recipient: rfc822;"TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically;processed
> Original-Recipient: rfc822; "TEST"
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> In order to always being able to calculate a correct digest the original
> string that was signed should be preserved as is.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-18017) camel-as2 - Signed content in MDN gets corrupted and is not possible to validate
[
https://issues.apache.org/jira/browse/CAMEL-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-18017.
-
Resolution: Fixed
> camel-as2 - Signed content in MDN gets corrupted and is not possible to
> validate
>
>
> Key: CAMEL-18017
> URL: https://issues.apache.org/jira/browse/CAMEL-18017
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Affects Versions: 3.16.0
>Reporter: Ted Lundqvist
>Assignee: Jono Morris
>Priority: Minor
> Fix For: 4.4.2, 4.6.0
>
>
> When the http response with an MDN is received it is parsed to a
> MultipartSignedEntity-object.
> When the object is serialized back to an outputstream using the method
> AS2MessageDispositionNotificationEntity#writeTo the string is not guaranteed
> to be identical to the the string received in the original http-response.
> This makes it impossible to calculate an correct message-digest and the
> method MultipartSignedEntity#isValid returns false because the following
> exception is thrown:
> "org.bouncycastle.cms.CMSSignerDigestMismatchException: message-digest
> attribute value does not match calculated value"
> when calling:
> signer.verify(new
> JcaSimpleSignerInfoVerifierBuilder().setProvider("BC").build(cert)
> I tried to use the AS2-client to send messeages to both IBM Datapower and
> ArcESB and it was not possible to validate the MDN from neither of them.
> A few examples of differences between the actual received string and the
> reconstructed string are (see the full examples further down):
> # The order of the fields in the disposition-notification was in the wrong
> order:
> In the original string they where ordered as follows:
> Reporting-UA
> Original-Recipient
> Final-Recipient
> Original-Message-ID
> Disposition
> Received-content-MIC
> But in the reconstructed string the field Original-Recipient had been moved
> down and was placed before Received-content-MIC.
> # Received-content-MIC returned from both Datapower and ArcESB had a space
> between the comma-sign and the algorithmId.
> In the reconstructed string the space-character was removed.
> According to the example in RFC4130
> ([https://datatracker.ietf.org/doc/html/rfc4130)] is seems as if it should be
> ok to have a space-character.
> # In the MDN from ArcESB the field Received-content-MIC the word content was
> written with a capital 'C' i.e. Received-Content-MIC.
> I'm not sure if that is valid according to the standard or not.
> The actual string received in the http-response:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Original-Recipient: rfc822; "TEST"
> Final-Recipient: rfc822; "TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically; processed
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,
> sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> The String reconstructed from the MultipartSignedEntity:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Final-Recipient: rfc822;"TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically;processed
> Original-Recipient: rfc822; "TEST"
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> In order to always being able to calculate a correct digest the original
> string that was signed should be preserved as is.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18017) camel-as2 - Signed content in MDN gets corrupted and is not possible to validate
[
https://issues.apache.org/jira/browse/CAMEL-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18017:
Fix Version/s: 4.4.2
> camel-as2 - Signed content in MDN gets corrupted and is not possible to
> validate
>
>
> Key: CAMEL-18017
> URL: https://issues.apache.org/jira/browse/CAMEL-18017
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Affects Versions: 3.16.0
>Reporter: Ted Lundqvist
>Assignee: Jono Morris
>Priority: Minor
> Fix For: 4.4.2, 4.6.0
>
>
> When the http response with an MDN is received it is parsed to a
> MultipartSignedEntity-object.
> When the object is serialized back to an outputstream using the method
> AS2MessageDispositionNotificationEntity#writeTo the string is not guaranteed
> to be identical to the the string received in the original http-response.
> This makes it impossible to calculate an correct message-digest and the
> method MultipartSignedEntity#isValid returns false because the following
> exception is thrown:
> "org.bouncycastle.cms.CMSSignerDigestMismatchException: message-digest
> attribute value does not match calculated value"
> when calling:
> signer.verify(new
> JcaSimpleSignerInfoVerifierBuilder().setProvider("BC").build(cert)
> I tried to use the AS2-client to send messeages to both IBM Datapower and
> ArcESB and it was not possible to validate the MDN from neither of them.
> A few examples of differences between the actual received string and the
> reconstructed string are (see the full examples further down):
> # The order of the fields in the disposition-notification was in the wrong
> order:
> In the original string they where ordered as follows:
> Reporting-UA
> Original-Recipient
> Final-Recipient
> Original-Message-ID
> Disposition
> Received-content-MIC
> But in the reconstructed string the field Original-Recipient had been moved
> down and was placed before Received-content-MIC.
> # Received-content-MIC returned from both Datapower and ArcESB had a space
> between the comma-sign and the algorithmId.
> In the reconstructed string the space-character was removed.
> According to the example in RFC4130
> ([https://datatracker.ietf.org/doc/html/rfc4130)] is seems as if it should be
> ok to have a space-character.
> # In the MDN from ArcESB the field Received-content-MIC the word content was
> written with a capital 'C' i.e. Received-Content-MIC.
> I'm not sure if that is valid according to the standard or not.
> The actual string received in the http-response:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Original-Recipient: rfc822; "TEST"
> Final-Recipient: rfc822; "TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically; processed
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,
> sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> The String reconstructed from the MultipartSignedEntity:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Final-Recipient: rfc822;"TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically;processed
> Original-Recipient: rfc822; "TEST"
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> In order to always being able to calculate a correct digest the original
> string that was signed should be preserved as is.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20574) Camel-Milvus: Add more producer operation
[ https://issues.apache.org/jira/browse/CAMEL-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-20574. -- Resolution: Fixed > Camel-Milvus: Add more producer operation > - > > Key: CAMEL-20574 > URL: https://issues.apache.org/jira/browse/CAMEL-20574 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20670) camel-platform-http-vertx: Multipart attachment id should be consistent with other HTTP components
James Netherton created CAMEL-20670: --- Summary: camel-platform-http-vertx: Multipart attachment id should be consistent with other HTTP components Key: CAMEL-20670 URL: https://issues.apache.org/jira/browse/CAMEL-20670 Project: Camel Issue Type: Improvement Components: camel-platform-http-vertx Reporter: James Netherton Assignee: James Netherton Fix For: 4.6.0 Originally reported here: [https://github.com/apache/camel-quarkus/issues/5981] When the platform-http-vertx consumer adds an attachment to the AttachmentMessage, it uses the actual file name of the uploaded content as the id. [https://github.com/apache/camel/blob/450c4a6228711bf947f9beb8ec65ab801959a0c0/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpConsumer.java#L343] We should change it to be consistent with other HTTP components and use the 'name' attribute of the Content-Disposition sent in the request body. E.g this: [https://github.com/apache/camel/blob/450c4a6228711bf947f9beb8ec65ab801959a0c0/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpConsumer.java#L323] -- This message was sent by Atlassian Jira (v8.20.10#820010)
