[jira] [Commented] (CAMEL-17881) TLS for MLLP Component
[ https://issues.apache.org/jira/browse/CAMEL-17881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515993#comment-17515993 ] Quinn Stevenson commented on CAMEL-17881: - Sorry Andrea - I’m in the middle of a big project and won’t be able to get to this for several months. > TLS for MLLP Component > -- > > Key: CAMEL-17881 > URL: https://issues.apache.org/jira/browse/CAMEL-17881 > Project: Camel > Issue Type: New Feature > Components: camel-mllp >Reporter: Peter Palaga >Priority: Major > > There is no single occurrence of TLS or SSL on the MLLP component page > https://camel.apache.org/components/3.16.x/mllp-component.html > So I assume it is currently not possible to activate TLS for MLLP > communication. > Would it please be possibly to add this functionality? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CAMEL-12659) MllpTcpServerConsumer logging failure to set HL7 headers even when setting HL7 headers is disabled
[ https://issues.apache.org/jira/browse/CAMEL-12659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12659. - Resolution: Fixed Fix Version/s: 2.23.0 2.22.1 2.21.2 2.20.4 Correct on master w/commit 130a42223171a39cbe3d77021b2ecf15a21036f8. Back-ported to 2.22.x w/commit fc069058dbf283e5b72e58d6c3e3f438c8c34ec0 Back-ported to 2.21.x w/commit 9d8f7c662562f17ad9d0282fbfae7fb585fd4d11 Back-ported to 2.20.x w/commit b7281f1eda9c5a4dd7328c3e4d55142f45737a22 > MllpTcpServerConsumer logging failure to set HL7 headers even when setting > HL7 headers is disabled > -- > > Key: CAMEL-12659 > URL: https://issues.apache.org/jira/browse/CAMEL-12659 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Affects Versions: 2.20.3, 2.21.1, 2.22.0 >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.20.4, 2.21.2, 2.22.1, 2.23.0 > > > In the process of setting Camel message headers from the payload, the > MllpTcpServerConsumer is logging an error when it fails to identify the MSH > segment of the message. This error is logged before the hl7Headers > configuration option is checked, so the error is always logged - even if > setting the HL7 headers is disabled (i.e. hl7Headers=false). > This is a minor issue, but it effects edge cases where non-HL7 payloads are > sent with the MLLP protocol. > The logic should be changed such that if the hl7Headers option is false, > don't do anything (i.e. no log statement). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12659) MllpTcpServerConsumer logging failure to set HL7 headers even when setting HL7 headers is disabled
[ https://issues.apache.org/jira/browse/CAMEL-12659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson updated CAMEL-12659: Issue Type: Bug (was: Improvement) > MllpTcpServerConsumer logging failure to set HL7 headers even when setting > HL7 headers is disabled > -- > > Key: CAMEL-12659 > URL: https://issues.apache.org/jira/browse/CAMEL-12659 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Affects Versions: 2.20.3, 2.21.1, 2.22.0 >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > > In the process of setting Camel message headers from the payload, the > MllpTcpServerConsumer is logging an error when it fails to identify the MSH > segment of the message. This error is logged before the hl7Headers > configuration option is checked, so the error is always logged - even if > setting the HL7 headers is disabled (i.e. hl7Headers=false). > This is a minor issue, but it effects edge cases where non-HL7 payloads are > sent with the MLLP protocol. > The logic should be changed such that if the hl7Headers option is false, > don't do anything (i.e. no log statement). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (CAMEL-12659) MllpTcpServerConsumer logging failure to set HL7 headers even when setting HL7 headers is disabled
[ https://issues.apache.org/jira/browse/CAMEL-12659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-12659 started by Quinn Stevenson. --- > MllpTcpServerConsumer logging failure to set HL7 headers even when setting > HL7 headers is disabled > -- > > Key: CAMEL-12659 > URL: https://issues.apache.org/jira/browse/CAMEL-12659 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Affects Versions: 2.20.3, 2.21.1, 2.22.0 >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > > In the process of setting Camel message headers from the payload, the > MllpTcpServerConsumer is logging an error when it fails to identify the MSH > segment of the message. This error is logged before the hl7Headers > configuration option is checked, so the error is always logged - even if > setting the HL7 headers is disabled (i.e. hl7Headers=false). > This is a minor issue, but it effects edge cases where non-HL7 payloads are > sent with the MLLP protocol. > The logic should be changed such that if the hl7Headers option is false, > don't do anything (i.e. no log statement). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12659) MllpTcpServerConsumer logging failure to set HL7 headers even when setting HL7 headers is disabled
Quinn Stevenson created CAMEL-12659: --- Summary: MllpTcpServerConsumer logging failure to set HL7 headers even when setting HL7 headers is disabled Key: CAMEL-12659 URL: https://issues.apache.org/jira/browse/CAMEL-12659 Project: Camel Issue Type: Improvement Components: camel-mllp Affects Versions: 2.21.1, 2.20.3, 2.22.0 Reporter: Quinn Stevenson Assignee: Quinn Stevenson In the process of setting Camel message headers from the payload, the MllpTcpServerConsumer is logging an error when it fails to identify the MSH segment of the message. This error is logged before the hl7Headers configuration option is checked, so the error is always logged - even if setting the HL7 headers is disabled (i.e. hl7Headers=false). This is a minor issue, but it effects edge cases where non-HL7 payloads are sent with the MLLP protocol. The logic should be changed such that if the hl7Headers option is false, don't do anything (i.e. no log statement). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12360) Add logRetryAttemptedInterval to RedeliveryPolicy
[ https://issues.apache.org/jira/browse/CAMEL-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12360. - Resolution: Fixed Backported to 2.20.4 with commit 7ff38a225a2de0f3b87ac5cbcfaab0a5648b3378 > Add logRetryAttemptedInterval to RedeliveryPolicy > - > > Key: CAMEL-12360 > URL: https://issues.apache.org/jira/browse/CAMEL-12360 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.20.4, 2.21.2, 2.22.0 > > > A logRetryAttemptedInterval configuration property will be added to the > RedeliveryPolicy to provide a little more control over how much information > winds up the logs when Camel is attempting to redeliver an exchange. > When this option is set to a value greater than zero and logRetryAttempted is > true, the retry attempt will be logged for the first attempt and then every > Nth attempt after the first attempt - reducing the number of log entries for > this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12360) Add logRetryAttemptedInterval to RedeliveryPolicy
[ https://issues.apache.org/jira/browse/CAMEL-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495214#comment-16495214 ] Quinn Stevenson commented on CAMEL-12360: - Backported to 2.21.2 with commit 347f8b15d94839ba2eacb51050a5bd016ecdba11 > Add logRetryAttemptedInterval to RedeliveryPolicy > - > > Key: CAMEL-12360 > URL: https://issues.apache.org/jira/browse/CAMEL-12360 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.20.4, 2.21.2, 2.22.0 > > > A logRetryAttemptedInterval configuration property will be added to the > RedeliveryPolicy to provide a little more control over how much information > winds up the logs when Camel is attempting to redeliver an exchange. > When this option is set to a value greater than zero and logRetryAttempted is > true, the retry attempt will be logged for the first attempt and then every > Nth attempt after the first attempt - reducing the number of log entries for > this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12360) Add logRetryAttemptedInterval to RedeliveryPolicy
[ https://issues.apache.org/jira/browse/CAMEL-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson updated CAMEL-12360: Fix Version/s: 2.21.2 2.20.4 > Add logRetryAttemptedInterval to RedeliveryPolicy > - > > Key: CAMEL-12360 > URL: https://issues.apache.org/jira/browse/CAMEL-12360 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.20.4, 2.21.2, 2.22.0 > > > A logRetryAttemptedInterval configuration property will be added to the > RedeliveryPolicy to provide a little more control over how much information > winds up the logs when Camel is attempting to redeliver an exchange. > When this option is set to a value greater than zero and logRetryAttempted is > true, the retry attempt will be logged for the first attempt and then every > Nth attempt after the first attempt - reducing the number of log entries for > this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (CAMEL-12360) Add logRetryAttemptedInterval to RedeliveryPolicy
[ https://issues.apache.org/jira/browse/CAMEL-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson reopened CAMEL-12360: - Backporting to supported versions > Add logRetryAttemptedInterval to RedeliveryPolicy > - > > Key: CAMEL-12360 > URL: https://issues.apache.org/jira/browse/CAMEL-12360 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.22.0 > > > A logRetryAttemptedInterval configuration property will be added to the > RedeliveryPolicy to provide a little more control over how much information > winds up the logs when Camel is attempting to redeliver an exchange. > When this option is set to a value greater than zero and logRetryAttempted is > true, the retry attempt will be logged for the first attempt and then every > Nth attempt after the first attempt - reducing the number of log entries for > this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12360) Add logRetryAttemptedInterval to RedeliveryPolicy
[ https://issues.apache.org/jira/browse/CAMEL-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12360. - Resolution: Fixed Added Spring support for retryAttemptedLogInterval with commit 73c76e30d268447b810c6985fd009f02aec8917c > Add logRetryAttemptedInterval to RedeliveryPolicy > - > > Key: CAMEL-12360 > URL: https://issues.apache.org/jira/browse/CAMEL-12360 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.22.0 > > > A logRetryAttemptedInterval configuration property will be added to the > RedeliveryPolicy to provide a little more control over how much information > winds up the logs when Camel is attempting to redeliver an exchange. > When this option is set to a value greater than zero and logRetryAttempted is > true, the retry attempt will be logged for the first attempt and then every > Nth attempt after the first attempt - reducing the number of log entries for > this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12360) Add logRetryAttemptedInterval to RedeliveryPolicy
[ https://issues.apache.org/jira/browse/CAMEL-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494257#comment-16494257 ] Quinn Stevenson edited comment on CAMEL-12360 at 5/29/18 9:00 PM: -- Missed configuration for Spring - will follow with another commit was (Author: hqstevenson): Missed configuration for Spring - will follow with another PR > Add logRetryAttemptedInterval to RedeliveryPolicy > - > > Key: CAMEL-12360 > URL: https://issues.apache.org/jira/browse/CAMEL-12360 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.22.0 > > > A logRetryAttemptedInterval configuration property will be added to the > RedeliveryPolicy to provide a little more control over how much information > winds up the logs when Camel is attempting to redeliver an exchange. > When this option is set to a value greater than zero and logRetryAttempted is > true, the retry attempt will be logged for the first attempt and then every > Nth attempt after the first attempt - reducing the number of log entries for > this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (CAMEL-12360) Add logRetryAttemptedInterval to RedeliveryPolicy
[ https://issues.apache.org/jira/browse/CAMEL-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson reopened CAMEL-12360: - Missed configuration for Spring - will follow with another PR > Add logRetryAttemptedInterval to RedeliveryPolicy > - > > Key: CAMEL-12360 > URL: https://issues.apache.org/jira/browse/CAMEL-12360 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.22.0 > > > A logRetryAttemptedInterval configuration property will be added to the > RedeliveryPolicy to provide a little more control over how much information > winds up the logs when Camel is attempting to redeliver an exchange. > When this option is set to a value greater than zero and logRetryAttempted is > true, the retry attempt will be logged for the first attempt and then every > Nth attempt after the first attempt - reducing the number of log entries for > this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12360) Add logRetryAttemptedInterval to RedeliveryPolicy
[ https://issues.apache.org/jira/browse/CAMEL-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12360. - Resolution: Fixed Fix Version/s: 2.22.0 Added functionality with commit 60d285f55dd0ba1139256932e5b0a09608ecaf14 > Add logRetryAttemptedInterval to RedeliveryPolicy > - > > Key: CAMEL-12360 > URL: https://issues.apache.org/jira/browse/CAMEL-12360 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.22.0 > > > A logRetryAttemptedInterval configuration property will be added to the > RedeliveryPolicy to provide a little more control over how much information > winds up the logs when Camel is attempting to redeliver an exchange. > When this option is set to a value greater than zero and logRetryAttempted is > true, the retry attempt will be logged for the first attempt and then every > Nth attempt after the first attempt - reducing the number of log entries for > this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12325) lastConnectionActivityTicks is not getting updated by MllpTcpClientProducer
[ https://issues.apache.org/jira/browse/CAMEL-12325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12325. - Resolution: Fixed Commits for 2.22 14d2cf99cd0fbd85ab5a8383e4516acdffb65a7b 97ae6103acd5c28626d14045502e42df4e0b91af Commits for 2.21.1 b782d2eead7d72b5ab3703495343c89954589651 5fa2f4f9ba203cca61687b34bc8b3b2d32c291d2 > lastConnectionActivityTicks is not getting updated by MllpTcpClientProducer > --- > > Key: CAMEL-12325 > URL: https://issues.apache.org/jira/browse/CAMEL-12325 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Major > Fix For: 2.21.1, 2.22.0 > > > The producer is not updating the last activity timestamp, which is causing > idleTimeout to not work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12360) Add logRetryAttemptedInterval to RedeliveryPolicy
Quinn Stevenson created CAMEL-12360: --- Summary: Add logRetryAttemptedInterval to RedeliveryPolicy Key: CAMEL-12360 URL: https://issues.apache.org/jira/browse/CAMEL-12360 Project: Camel Issue Type: New Feature Components: camel-core Reporter: Quinn Stevenson Assignee: Quinn Stevenson A logRetryAttemptedInterval configuration property will be added to the RedeliveryPolicy to provide a little more control over how much information winds up the logs when Camel is attempting to redeliver an exchange. When this option is set to a value greater than zero and logRetryAttempted is true, the retry attempt will be logged for the first attempt and then every Nth attempt after the first attempt - reducing the number of log entries for this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (CAMEL-12325) lastConnectionActivityTicks is not getting updated by MllpTcpClientProducer
[ https://issues.apache.org/jira/browse/CAMEL-12325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson reopened CAMEL-12325: - > lastConnectionActivityTicks is not getting updated by MllpTcpClientProducer > --- > > Key: CAMEL-12325 > URL: https://issues.apache.org/jira/browse/CAMEL-12325 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Major > Fix For: 2.21.1, 2.22.0 > > > The producer is not updating the last activity timestamp, which is causing > idleTimeout to not work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12325) lastConnectionActivityTicks is not getting updated by MllpTcpClientProducer
[ https://issues.apache.org/jira/browse/CAMEL-12325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson updated CAMEL-12325: Fix Version/s: (was: 2.21.0) 2.22.0 2.21.1 > lastConnectionActivityTicks is not getting updated by MllpTcpClientProducer > --- > > Key: CAMEL-12325 > URL: https://issues.apache.org/jira/browse/CAMEL-12325 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Major > Fix For: 2.21.1, 2.22.0 > > > The producer is not updating the last activity timestamp, which is causing > idleTimeout to not work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12333) MllpTcpServerConsumer resetting connections on idleTimout
[ https://issues.apache.org/jira/browse/CAMEL-12333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12333. - Resolution: Fixed Fix Version/s: 2.21.0 Resolved w/commit 89bcfa0753233f8b576154486a89a2677d9d3efd > MllpTcpServerConsumer resetting connections on idleTimout > - > > Key: CAMEL-12333 > URL: https://issues.apache.org/jira/browse/CAMEL-12333 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Major > Fix For: 2.21.0 > > > If an idleTimeout is specified, the MllpTcpServerConsumer is resetting client > connections after the idleTimeout - regardless of whether or not there has > been any activity on the connection. > This causes serious issues with upstream components that are very connection > sensitive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12333) MllpTcpServerConsumer resetting connections on idleTimout
Quinn Stevenson created CAMEL-12333: --- Summary: MllpTcpServerConsumer resetting connections on idleTimout Key: CAMEL-12333 URL: https://issues.apache.org/jira/browse/CAMEL-12333 Project: Camel Issue Type: Bug Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson If an idleTimeout is specified, the MllpTcpServerConsumer is resetting client connections after the idleTimeout - regardless of whether or not there has been any activity on the connection. This causes serious issues with upstream components that are very connection sensitive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (CAMEL-12333) MllpTcpServerConsumer resetting connections on idleTimout
[ https://issues.apache.org/jira/browse/CAMEL-12333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-12333 started by Quinn Stevenson. --- > MllpTcpServerConsumer resetting connections on idleTimout > - > > Key: CAMEL-12333 > URL: https://issues.apache.org/jira/browse/CAMEL-12333 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Major > > If an idleTimeout is specified, the MllpTcpServerConsumer is resetting client > connections after the idleTimeout - regardless of whether or not there has > been any activity on the connection. > This causes serious issues with upstream components that are very connection > sensitive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12325) lastConnectionActivityTicks is not getting updated by MllpTcpClientProducer
[ https://issues.apache.org/jira/browse/CAMEL-12325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12325. - Resolution: Fixed Fix Version/s: 2.21.0 Fixed with commit e2b10183ba735986102799e8d1be28111f11cfc6 > lastConnectionActivityTicks is not getting updated by MllpTcpClientProducer > --- > > Key: CAMEL-12325 > URL: https://issues.apache.org/jira/browse/CAMEL-12325 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Major > Fix For: 2.21.0 > > > The producer is not updating the last activity timestamp, which is causing > idleTimeout to not work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12325) lastConnectionActivityTicks is not getting updated by MllpTcpClientProducer
Quinn Stevenson created CAMEL-12325: --- Summary: lastConnectionActivityTicks is not getting updated by MllpTcpClientProducer Key: CAMEL-12325 URL: https://issues.apache.org/jira/browse/CAMEL-12325 Project: Camel Issue Type: Bug Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson The producer is not updating the last activity timestamp, which is causing idleTimeout to not work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12315) AutoAcknowledgement issues
[ https://issues.apache.org/jira/browse/CAMEL-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12315. - Resolution: Fixed Fix Version/s: 2.21.0 Corrected issues w/commit 9b19e60dbe42df472aefa45e10fbfd1f3436a43e > AutoAcknowledgement issues > -- > > Key: CAMEL-12315 > URL: https://issues.apache.org/jira/browse/CAMEL-12315 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > Several minor issues were discovered with the automatic acknowledgment > functionality. > * autoAck = false is ignored (the component still attempts to generate an > acknowledgement if one is not found on the exchage > * acknowledgment generation exceptions are not passed to the error handler > when bridgeErrorHander=true > * invalid acknowledgment exceptions are not passed to the error handler when > bridgeErrorHander=true > * the automatically generated acknowledgement uses the same timestamp as the > message > * the automatically generated acknowledgement uses the same message control > id as the message > * the automatically generated acknowledgment includes MSH-8 if present, > which should not be passed on > * automatically generated negative acknowledgments do not include any > information about the failure -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12315) AutoAcknowledgement issues
Quinn Stevenson created CAMEL-12315: --- Summary: AutoAcknowledgement issues Key: CAMEL-12315 URL: https://issues.apache.org/jira/browse/CAMEL-12315 Project: Camel Issue Type: Bug Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson Several minor issues were discovered with the automatic acknowledgment functionality. * autoAck = false is ignored (the component still attempts to generate an acknowledgement if one is not found on the exchage * acknowledgment generation exceptions are not passed to the error handler when bridgeErrorHander=true * invalid acknowledgment exceptions are not passed to the error handler when bridgeErrorHander=true * the automatically generated acknowledgement uses the same timestamp as the message * the automatically generated acknowledgement uses the same message control id as the message * the automatically generated acknowledgment includes MSH-8 if present, which should not be passed on * automatically generated negative acknowledgments do not include any information about the failure -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12279) convertBodyTo w/Charset removes existing Charset from Exchange
[ https://issues.apache.org/jira/browse/CAMEL-12279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12279. - Resolution: Fixed Fix Version/s: 2.21.0 Resolved w/commit c7b93d9d4cdccf34fb543272c7bd9e507e2eb474 > convertBodyTo w/Charset removes existing Charset from Exchange > -- > > Key: CAMEL-12279 > URL: https://issues.apache.org/jira/browse/CAMEL-12279 > Project: Camel > Issue Type: Bug > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > When covertBodyTo is used with both a target type and a Charset for an > Exchange that already has the CamelCharsetName Exchange property set, the > Exchange property is deleted. > The original value of the CamelCharsetName exchange property should be > restored after the conversion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12279) convertBodyTo w/Charset removes existing Charset from Exchange
Quinn Stevenson created CAMEL-12279: --- Summary: convertBodyTo w/Charset removes existing Charset from Exchange Key: CAMEL-12279 URL: https://issues.apache.org/jira/browse/CAMEL-12279 Project: Camel Issue Type: Bug Components: camel-core Reporter: Quinn Stevenson Assignee: Quinn Stevenson When covertBodyTo is used with both a target type and a Charset for an Exchange that already has the CamelCharsetName Exchange property set, the Exchange property is deleted. The original value of the CamelCharsetName exchange property should be restored after the conversion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12265) Reduce logging caused by load balancer probes
[ https://issues.apache.org/jira/browse/CAMEL-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12265. - Resolution: Fixed Fix Version/s: 2.21.0 Resolved w/Commit 0b7fb515b5f09ab5ce5f5fa269474415070c2f6a Also resolved an NPE under certain circumstances when charsetName is specified? > Reduce logging caused by load balancer probes > - > > Key: CAMEL-12265 > URL: https://issues.apache.org/jira/browse/CAMEL-12265 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > When load balancers are used in front of MLLP data sources, the component > logs information for every probe from the load-balance. This pollutes the > log file with a large number of log entries (at the INFO/WARN levels) that > can be distracting when troubleshooting. > This log information will be moved to DEBUG. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12265) Reduce logging caused by load balancer probes
Quinn Stevenson created CAMEL-12265: --- Summary: Reduce logging caused by load balancer probes Key: CAMEL-12265 URL: https://issues.apache.org/jira/browse/CAMEL-12265 Project: Camel Issue Type: Improvement Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson When load balancers are used in front of MLLP data sources, the component logs information for every probe from the load-balance. This pollutes the log file with a large number of log entries (at the INFO/WARN levels) that can be distracting when troubleshooting. This log information will be moved to DEBUG. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12258) use configured readTimeout for initial message
[ https://issues.apache.org/jira/browse/CAMEL-12258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12258. - Resolution: Fixed Fix Version/s: 2.21.0 Resolved w/commit 5884ab755731d40a1d3d00153cc776fb0c068936. Also improved the logging to make it easier to diagnose issues with the initial read/validation Runnable. > use configured readTimeout for initial message > -- > > Key: CAMEL-12258 > URL: https://issues.apache.org/jira/browse/CAMEL-12258 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Major > Fix For: 2.21.0 > > > The camel-mllp component checks for load balancer probes by using a slightly > different Runnable for processing the first message. This runnable uses a > short receiveTimeout as is should. However, it should use the configured > readTimeout. Failure to use this configured timeout causes large messages to > fail when they are the first messages received on the TCP Socket, and the > camel-mllp component subsequently resets the TCP connection - so messages can > never flow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12258) use configured readTimeout for initial message
Quinn Stevenson created CAMEL-12258: --- Summary: use configured readTimeout for initial message Key: CAMEL-12258 URL: https://issues.apache.org/jira/browse/CAMEL-12258 Project: Camel Issue Type: Bug Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson The camel-mllp component checks for load balancer probes by using a slightly different Runnable for processing the first message. This runnable uses a short receiveTimeout as is should. However, it should use the configured readTimeout. Failure to use this configured timeout causes large messages to fail when they are the first messages received on the TCP Socket, and the camel-mllp component subsequently resets the TCP connection - so messages can never flow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12105) Add Additional TypeConverters to camel-hl7
[ https://issues.apache.org/jira/browse/CAMEL-12105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12105. - Resolution: Fixed Fix Version/s: 2.21.0 Specific type converters added w/commit 40685296333d69402111067c1a1a9b3f99a6661f. Also corrected existing type converters to use Charset if specified with conversion. > Add Additional TypeConverters to camel-hl7 > -- > > Key: CAMEL-12105 > URL: https://issues.apache.org/jira/browse/CAMEL-12105 > Project: Camel > Issue Type: New Feature > Components: camel-hl7 >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > The camel-hl7 component has a TypeConverter for HAPI Messages, but this type > converter always returns the specifc HAPI Structure for the message. > Oftentimes it is useful to use a HAPI GenericMessage instead of the specific > structure, and TypeConverters supporting this would make it much more > straightforward. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12226) Change HAPI version from 2.2 to 2.3
[ https://issues.apache.org/jira/browse/CAMEL-12226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12226. - Resolution: Fixed Fix Version/s: 2.21.0 Update parent POM in commit cdcaa6a7bd17e6b4384c6846c5315a8be6a6ba2f > Change HAPI version from 2.2 to 2.3 > --- > > Key: CAMEL-12226 > URL: https://issues.apache.org/jira/browse/CAMEL-12226 > Project: Camel > Issue Type: Improvement > Components: camel-hl7 >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (CAMEL-12226) Change HAPI version from 2.2 to 2.3
[ https://issues.apache.org/jira/browse/CAMEL-12226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-12226 started by Quinn Stevenson. --- > Change HAPI version from 2.2 to 2.3 > --- > > Key: CAMEL-12226 > URL: https://issues.apache.org/jira/browse/CAMEL-12226 > Project: Camel > Issue Type: Improvement > Components: camel-hl7 >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12226) Change HAPI version from 2.2 to 2.3
Quinn Stevenson created CAMEL-12226: --- Summary: Change HAPI version from 2.2 to 2.3 Key: CAMEL-12226 URL: https://issues.apache.org/jira/browse/CAMEL-12226 Project: Camel Issue Type: Improvement Components: camel-hl7 Reporter: Quinn Stevenson Assignee: Quinn Stevenson -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12178) Add getMessage and setMessage methods to the Exchange interface
[ https://issues.apache.org/jira/browse/CAMEL-12178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12178. - Resolution: Fixed Fix Version/s: 2.21.0 Fixed with commit 698c04dba0721f99abf04fee2030fb64b3601b69 > Add getMessage and setMessage methods to the Exchange interface > --- > > Key: CAMEL-12178 > URL: https://issues.apache.org/jira/browse/CAMEL-12178 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Trivial > Fix For: 2.21.0 > > > Most of the time, the correct Camel Message is retrieve from the exchange > using > > Message message = hasOut() ? getOut() : getIn(); > > With this enhancement, the common usage would be supported by these methods. > > To try this out, I had to change the Exchange interface, the DefaultExchange > implementation (both in camel-core), and RichExchange (in camel-scala). > Everything seemed to be fine with the change. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (CAMEL-12178) Add getMessage and setMessage methods to the Exchange interface
[ https://issues.apache.org/jira/browse/CAMEL-12178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-12178 started by Quinn Stevenson. --- > Add getMessage and setMessage methods to the Exchange interface > --- > > Key: CAMEL-12178 > URL: https://issues.apache.org/jira/browse/CAMEL-12178 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Trivial > > Most of the time, the correct Camel Message is retrieve from the exchange > using > > Message message = hasOut() ? getOut() : getIn(); > > With this enhancement, the common usage would be supported by these methods. > > To try this out, I had to change the Exchange interface, the DefaultExchange > implementation (both in camel-core), and RichExchange (in camel-scala). > Everything seemed to be fine with the change. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-12178) Add getMessage and setMessage methods to the Exchange interface
[ https://issues.apache.org/jira/browse/CAMEL-12178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson reassigned CAMEL-12178: --- Assignee: Quinn Stevenson > Add getMessage and setMessage methods to the Exchange interface > --- > > Key: CAMEL-12178 > URL: https://issues.apache.org/jira/browse/CAMEL-12178 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Trivial > > Most of the time, the correct Camel Message is retrieve from the exchange > using > > Message message = hasOut() ? getOut() : getIn(); > > With this enhancement, the common usage would be supported by these methods. > > To try this out, I had to change the Exchange interface, the DefaultExchange > implementation (both in camel-core), and RichExchange (in camel-scala). > Everything seemed to be fine with the change. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12218) Make bridgeErrorHandler optional
[ https://issues.apache.org/jira/browse/CAMEL-12218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12218. - Resolution: Fixed Fix Version/s: 2.21.0 Resolved w/commit 005b2c9a78a357d76d9396b379825d3c033dfac7 > Make bridgeErrorHandler optional > > > Key: CAMEL-12218 > URL: https://issues.apache.org/jira/browse/CAMEL-12218 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > The camel-mllp consumer has not allowed disabling bridgeErrorHandler in the > past (it defaults to true for this component). > The option should be configurable (as it is with other Camel components), and > documented as having a default value of 'true' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12218) Make bridgeErrorHandler optional
Quinn Stevenson created CAMEL-12218: --- Summary: Make bridgeErrorHandler optional Key: CAMEL-12218 URL: https://issues.apache.org/jira/browse/CAMEL-12218 Project: Camel Issue Type: Improvement Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson The camel-mllp consumer has not allowed disabling bridgeErrorHandler in the past (it defaults to true for this component). The option should be configurable (as it is with other Camel components), and documented as having a default value of 'true' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12215) Add lenient-bind option for MLLP Consumers
[ https://issues.apache.org/jira/browse/CAMEL-12215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12215. - Resolution: Fixed Fix Version/s: 2.21.0 Added URI option w/commit b3468ef4db9d17b137fc26268d83426d20890cf9 > Add lenient-bind option for MLLP Consumers > -- > > Key: CAMEL-12215 > URL: https://issues.apache.org/jira/browse/CAMEL-12215 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > Currently, MLLP Consumers block startup of the route until the bind operation > on the TCP port succeeds. This can be problematic in production environments > when containers are restarted, since some Camel contexts may not be able to > bind to the TCP port within the startup timeout. > > Adding an option to allow the route to bind to the TCP asynchronously will > greatly improve operational simplicity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12215) Add lenient-bind option for MLLP Consumers
Quinn Stevenson created CAMEL-12215: --- Summary: Add lenient-bind option for MLLP Consumers Key: CAMEL-12215 URL: https://issues.apache.org/jira/browse/CAMEL-12215 Project: Camel Issue Type: Improvement Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson Currently, MLLP Consumers block startup of the route until the bind operation on the TCP port succeeds. This can be problematic in production environments when containers are restarted, since some Camel contexts may not be able to bind to the TCP port within the startup timeout. Adding an option to allow the route to bind to the TCP asynchronously will greatly improve operational simplicity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12210) End of HL7 Message not always detected correctly
[ https://issues.apache.org/jira/browse/CAMEL-12210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12210. - Resolution: Fixed Fix Version/s: 2.21.0 Resolved w/commit c8f24cac46f9c4a02a869597a0e7ba03565aa9fd > End of HL7 Message not always detected correctly > > > Key: CAMEL-12210 > URL: https://issues.apache.org/jira/browse/CAMEL-12210 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > The MllpTcpServerConsumer is not always detecting the end of the MLLP > envelope correctly, resulting in unpredictable route behavior (empty messages > being delivered to route, exceptions generating acknowledgments, etc). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12210) End of HL7 Message not always detected correctly
Quinn Stevenson created CAMEL-12210: --- Summary: End of HL7 Message not always detected correctly Key: CAMEL-12210 URL: https://issues.apache.org/jira/browse/CAMEL-12210 Project: Camel Issue Type: Bug Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson The MllpTcpServerConsumer is not always detecting the end of the MLLP envelope correctly, resulting in unpredictable route behavior (empty messages being delivered to route, exceptions generating acknowledgments, etc). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12200) camel-mllp - Fix IndexOutOfBounds exception when generating acknowledgment
[ https://issues.apache.org/jira/browse/CAMEL-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12200. - Resolution: Fixed Fix Version/s: 2.21.0 > camel-mllp - Fix IndexOutOfBounds exception when generating acknowledgment > -- > > Key: CAMEL-12200 > URL: https://issues.apache.org/jira/browse/CAMEL-12200 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > Under certain circumstances, generating acknowledgements will fail with an > IndexOutOfBounds exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12200) camel-mllp - Fix IndexOutOfBounds exception when generating acknowledgment
[ https://issues.apache.org/jira/browse/CAMEL-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16343791#comment-16343791 ] Quinn Stevenson commented on CAMEL-12200: - fixed w/commit c7c9ea1d26011e24ccdd4aa84219625d41a56584 > camel-mllp - Fix IndexOutOfBounds exception when generating acknowledgment > -- > > Key: CAMEL-12200 > URL: https://issues.apache.org/jira/browse/CAMEL-12200 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > Under certain circumstances, generating acknowledgements will fail with an > IndexOutOfBounds exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
***UNCHECKED*** [jira] [Created] (CAMEL-12200) Fix IndexOutOfBounds exception when generating acknowledgment
Quinn Stevenson created CAMEL-12200: --- Summary: Fix IndexOutOfBounds exception when generating acknowledgment Key: CAMEL-12200 URL: https://issues.apache.org/jira/browse/CAMEL-12200 Project: Camel Issue Type: Improvement Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson Under certain circumstances, generating acknowledgements will fail with an IndexOutOfBounds exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12106) Update camel-mllp with enhancements from fork
[ https://issues.apache.org/jira/browse/CAMEL-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12106. - Resolution: Fixed Fix Version/s: 2.21.0 > Update camel-mllp with enhancements from fork > - > > Key: CAMEL-12106 > URL: https://issues.apache.org/jira/browse/CAMEL-12106 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > I've been running a custom build/fork of camel-mllp at a customer site for a > while now, and I've fixed several issues with the component as well as added > some new features. > Backward compatibility will be maintained, but one deprecated URI option > (maxReceiveTimeouts replaced by idleTimeout) will be removed in a future > version. Additionally, bridgeErrorHandler functionality is enabled by > default, and cannot be disabled - yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12106) Update camel-mllp with enhancements from fork
[ https://issues.apache.org/jira/browse/CAMEL-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336101#comment-16336101 ] Quinn Stevenson commented on CAMEL-12106: - I'm going to open another JIRA for the documentation updates. > Update camel-mllp with enhancements from fork > - > > Key: CAMEL-12106 > URL: https://issues.apache.org/jira/browse/CAMEL-12106 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > I've been running a custom build/fork of camel-mllp at a customer site for a > while now, and I've fixed several issues with the component as well as added > some new features. > Backward compatibility will be maintained, but one deprecated URI option > (maxReceiveTimeouts replaced by idleTimeout) will be removed in a future > version. Additionally, bridgeErrorHandler functionality is enabled by > default, and cannot be disabled - yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12182) Connection should be reset in the event of an acknowledgement timeout
[ https://issues.apache.org/jira/browse/CAMEL-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson resolved CAMEL-12182. - Resolution: Fixed Fix Version/s: 2.21.0 > Connection should be reset in the event of an acknowledgement timeout > - > > Key: CAMEL-12182 > URL: https://issues.apache.org/jira/browse/CAMEL-12182 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.21.0 > > > When a MLLP Sender (Producer) times-out waiting for the MLLP Acknowledgment > message, the TCP connection should be reset. Currently, it is left open > which can lead to MLLP protocol issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12182) Connection should be reset in the event of an acknowledgement timeout
[ https://issues.apache.org/jira/browse/CAMEL-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336097#comment-16336097 ] Quinn Stevenson commented on CAMEL-12182: - Corrected this with 56ce80ec20b0045d0526229f880c422397720e1c > Connection should be reset in the event of an acknowledgement timeout > - > > Key: CAMEL-12182 > URL: https://issues.apache.org/jira/browse/CAMEL-12182 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > > When a MLLP Sender (Producer) times-out waiting for the MLLP Acknowledgment > message, the TCP connection should be reset. Currently, it is left open > which can lead to MLLP protocol issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12182) Connection should be reset in the event of an acknowledgement timeout
Quinn Stevenson created CAMEL-12182: --- Summary: Connection should be reset in the event of an acknowledgement timeout Key: CAMEL-12182 URL: https://issues.apache.org/jira/browse/CAMEL-12182 Project: Camel Issue Type: Improvement Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson When a MLLP Sender (Producer) times-out waiting for the MLLP Acknowledgment message, the TCP connection should be reset. Currently, it is left open which can lead to MLLP protocol issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12178) Add getMessage and setMessage methods to the Exchange interface
Quinn Stevenson created CAMEL-12178: --- Summary: Add getMessage and setMessage methods to the Exchange interface Key: CAMEL-12178 URL: https://issues.apache.org/jira/browse/CAMEL-12178 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Quinn Stevenson Most of the time, the correct Camel Message is retrieve from the exchange using Message message = hasOut() ? getOut() : setOut(); With this enhancement, the common usage would be supported by these methods. To try this out, I had to change the Exchange interface, the DefaultExchange implementation (both in camel-core), and RichExchange (in camel-scala). Everything seemed to be fine with the change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (CAMEL-12106) Update camel-mllp with enhancements from fork
[ https://issues.apache.org/jira/browse/CAMEL-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-12106 started by Quinn Stevenson. --- > Update camel-mllp with enhancements from fork > - > > Key: CAMEL-12106 > URL: https://issues.apache.org/jira/browse/CAMEL-12106 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > > I've been running a custom build/fork of camel-mllp at a customer site for a > while now, and I've fixed several issues with the component as well as added > some new features. > Backward compatibility will be maintained, but one deprecated URI option > (maxReceiveTimeouts replaced by idleTimeout) will be removed in a future > version. Additionally, bridgeErrorHandler functionality is enabled by > default, and cannot be disabled - yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12106) Update camel-mllp with enhancements from fork
[ https://issues.apache.org/jira/browse/CAMEL-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16324631#comment-16324631 ] Quinn Stevenson commented on CAMEL-12106: - I've made two commits for this fb9c4a252d4ea6bec39aa1c00aa6e3e207357f34 b51c59b3b24b7d61d3e600c3fe13f35232525b02 I still have some documentation updates to do before I close this ticket. > Update camel-mllp with enhancements from fork > - > > Key: CAMEL-12106 > URL: https://issues.apache.org/jira/browse/CAMEL-12106 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > > I've been running a custom build/fork of camel-mllp at a customer site for a > while now, and I've fixed several issues with the component as well as added > some new features. > Backward compatibility will be maintained, but one deprecated URI option > (maxReceiveTimeouts replaced by idleTimeout) will be removed in a future > version. Additionally, bridgeErrorHandler functionality is enabled by > default, and cannot be disabled - yet. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-12106) Update camel-mllp with enhancements from fork
Quinn Stevenson created CAMEL-12106: --- Summary: Update camel-mllp with enhancements from fork Key: CAMEL-12106 URL: https://issues.apache.org/jira/browse/CAMEL-12106 Project: Camel Issue Type: Improvement Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson Priority: Minor I've been running a custom build/fork of camel-mllp at a customer site for a while now, and I've fixed several issues with the component as well as added some new features. Backward compatibility will be maintained, but one deprecated URI option (maxReceiveTimeouts replaced by idleTimeout) will be removed in a future version. Additionally, bridgeErrorHandler functionality is enabled by default, and cannot be disabled - yet. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-12105) Add Additional TypeConverters to camel-hl7
Quinn Stevenson created CAMEL-12105: --- Summary: Add Additional TypeConverters to camel-hl7 Key: CAMEL-12105 URL: https://issues.apache.org/jira/browse/CAMEL-12105 Project: Camel Issue Type: New Feature Components: camel-hl7 Reporter: Quinn Stevenson Assignee: Quinn Stevenson Priority: Minor The camel-hl7 component has a TypeConverter for HAPI Messages, but this type converter always returns the specifc HAPI Structure for the message. Oftentimes it is useful to use a HAPI GenericMessage instead of the specific structure, and TypeConverters supporting this would make it much more straightforward. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test
[ https://issues.apache.org/jira/browse/CAMEL-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880964#comment-15880964 ] Quinn Stevenson commented on CAMEL-6132: Claus is correct in the statement that this still needs quite a bit of love. I started it by combining on what was already in the Camel codeline with some stuff I'd done for a customer, and I ran out of time before I got very far. I'd love to have some help on this one - I'll see if I can pull your example (or find the one I had), but it may take me a few days (kinda busy with customers right now). > camel-test-karaf - To allow end users more easily do Camel and Karaf > integration test > - > > Key: CAMEL-6132 > URL: https://issues.apache.org/jira/browse/CAMEL-6132 > Project: Camel > Issue Type: New Feature > Components: karaf >Reporter: Claus Ibsen >Assignee: Quinn Stevenson > Fix For: 2.19.0 > > > We should introduce a proper camel-test-karaf component that *end users* can > use to do Camel and Karaf integration tests. > The code we have in tests/camel-itest-karaf is for internal usage and testing > of Camel. The code is not polished and intended for end users. > We should create a new module for that, and take the good parts of > camel-itest-karaf and make it user friendly etc. And of course have docs to > go with as well. > And when its good, we can use that in camel-itest-karaf also (eat our own dog > food) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10511) MllpTcpClientProducer should read all available bytes in TCP buffer for acknowledgment
[ https://issues.apache.org/jira/browse/CAMEL-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15754815#comment-15754815 ] Quinn Stevenson commented on CAMEL-10511: - Sorry about all the hassle Claus. I should've noticed all the extra commits when I created the PR - I apologize. Looks like I didn't do very well with my first attempt at creating a PR for something other than the master branch. Thank you for completing the backport to 2.18. I'll give the backport to 2.17 another shot. > MllpTcpClientProducer should read all available bytes in TCP buffer for > acknowledgment > -- > > Key: CAMEL-10511 > URL: https://issues.apache.org/jira/browse/CAMEL-10511 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Affects Versions: 2.17.0 >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.18.2, 2.19.0 > > > The MllpClientProducer currently reads the TCP buffer until it receives the > proper closing frame characters for the MLLP envelope. > This turned out to be a problem with a certain MLLP Server, which under > certain circumstances would send double MLLP acknowledgments. As currently > written, the MllpClientProducer will use the old/double/second acknowledgment > for the next message - which may cause erroneous results, but in any case is > clearly wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-10511) MllpTcpClientProducer should read all available bytes in TCP buffer for acknowledgment
[ https://issues.apache.org/jira/browse/CAMEL-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752254#comment-15752254 ] Quinn Stevenson commented on CAMEL-10511: - I would like to get this back-ported to 2.17, but I've never done a PR for anything but master. Do I just checkout the camel-2.17.x branch and do it from there following the same process? > MllpTcpClientProducer should read all available bytes in TCP buffer for > acknowledgment > -- > > Key: CAMEL-10511 > URL: https://issues.apache.org/jira/browse/CAMEL-10511 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Affects Versions: 2.17.0 >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.19.0 > > > The MllpClientProducer currently reads the TCP buffer until it receives the > proper closing frame characters for the MLLP envelope. > This turned out to be a problem with a certain MLLP Server, which under > certain circumstances would send double MLLP acknowledgments. As currently > written, the MllpClientProducer will use the old/double/second acknowledgment > for the next message - which may cause erroneous results, but in any case is > clearly wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10513) Start BlueprintCamelContext on BlueprintEvent.CREATED
Quinn Stevenson created CAMEL-10513: --- Summary: Start BlueprintCamelContext on BlueprintEvent.CREATED Key: CAMEL-10513 URL: https://issues.apache.org/jira/browse/CAMEL-10513 Project: Camel Issue Type: Improvement Components: camel-blueprint Reporter: Quinn Stevenson Assignee: Grzegorz Grzybek Priority: Minor Currently the BlueprintCamelContext starts when the BlueprintContainer OSGi service is registered. Because of this, the startup of the BlueprintCamelContext can effect the startup of the BlueprintContainer itself, which can lead to infinite loops and make issues more difficult to resolve. The BlueprintCamelContext should be changed to start on the BlueprintEvent.CREATED, which is sent after the BlueprintContainer is fully initialized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10510) HL7AcknowledgementGenerator should set exchange property and not message header
Quinn Stevenson created CAMEL-10510: --- Summary: HL7AcknowledgementGenerator should set exchange property and not message header Key: CAMEL-10510 URL: https://issues.apache.org/jira/browse/CAMEL-10510 Project: Camel Issue Type: Bug Components: camel-mllp Affects Versions: 2.17.0 Reporter: Quinn Stevenson Assignee: Quinn Stevenson Priority: Minor The HL7AcknowledgmentGenerator is setting the CamelMllpAcknowledgement message header, but this should be an exchange property. This is "hangover" from when this class was an internal/implementation class. Since I moved it and made it generally available for use, it should be setting the exchange property so that the acknowledgement will be delivered. As currently written, the user will have to copy the message header to the exchange property for it to be used. If this isn't done, the component will generate a new acknowledgement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10512) Add JMX attributes for connections & connection status
Quinn Stevenson created CAMEL-10512: --- Summary: Add JMX attributes for connections & connection status Key: CAMEL-10512 URL: https://issues.apache.org/jira/browse/CAMEL-10512 Project: Camel Issue Type: Improvement Components: camel-mllp Reporter: Quinn Stevenson Assignee: Quinn Stevenson Priority: Minor I've received this enhancement request from a few customers using this component. They would like to have the TCP connection information for both the consumer and producer exposed as JMX attributes so they can see the physical state of the connection, and not just if the component is up or down. They would also like a JMX operation to close/reset a connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-10510) HL7AcknowledgementGenerator should set exchange property and not message header
[ https://issues.apache.org/jira/browse/CAMEL-10510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15687104#comment-15687104 ] Quinn Stevenson commented on CAMEL-10510: - This component also drops extra delimiters if they are present in the message. Even though a message containing more than 4 delimiters is clearly not compliant with the HL7 standard, the component shouldn't alter the message - the delimiters should be passed through on the generated acknowledgement. > HL7AcknowledgementGenerator should set exchange property and not message > header > --- > > Key: CAMEL-10510 > URL: https://issues.apache.org/jira/browse/CAMEL-10510 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Affects Versions: 2.17.0 >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > > The HL7AcknowledgmentGenerator is setting the CamelMllpAcknowledgement > message header, but this should be an exchange property. > This is "hangover" from when this class was an internal/implementation class. > Since I moved it and made it generally available for use, it should be > setting the exchange property so that the acknowledgement will be delivered. > As currently written, the user will have to copy the message header to the > exchange property for it to be used. If this isn't done, the component will > generate a new acknowledgement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10511) MllpTcpClientProducer should read all available bytes in TCP buffer for acknowledgment
Quinn Stevenson created CAMEL-10511: --- Summary: MllpTcpClientProducer should read all available bytes in TCP buffer for acknowledgment Key: CAMEL-10511 URL: https://issues.apache.org/jira/browse/CAMEL-10511 Project: Camel Issue Type: Bug Components: camel-mllp Affects Versions: 2.17.0 Reporter: Quinn Stevenson Assignee: Quinn Stevenson Priority: Minor The MllpClientProducer currently reads the TCP buffer until it receives the proper closing frame characters for the MLLP envelope. This turned out to be a problem with a certain MLLP Server, which under certain circumstances would send double MLLP acknowledgments. As currently written, the MllpClientProducer will use the old/double/second acknowledgment for the next message - which may cause erroneous results, but in any case is clearly wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[ https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15664529#comment-15664529 ] Quinn Stevenson commented on CAMEL-9570: I've had a few discussions on the mailing list about this one, and I thought I should add the relevant information here. The root of this problem is the CamelDependenciesFinder - it is forcing the BlueprintContainer to create objects before it should. This puts the BlueprintContainer in a strange state, where service references and such are not handled correctly. The PR removes the CamelDependenciesFinder, and the expected net effect is described in the PR comment above. IMO this is more intuitive behavior than what occurs now. It turns out that the CamelDependenciesFinder bit me in the past - with a custom DataFormat. It caused the CamelContext to timeout when starting because of a service dependent, but the DataFormat was defined in the same bundle as the rest of the code, so there wasn't a service reference required - this one was tough to work around. > Blueprint Proxies are not used when injected into Java RouteBuilders > > > Key: CAMEL-9570 > URL: https://issues.apache.org/jira/browse/CAMEL-9570 > Project: Camel > Issue Type: Bug > Components: camel-blueprint, camel-core >Affects Versions: 2.16.2 >Reporter: Quinn Stevenson >Assignee: Christian Schneider > > Basic Conditions: > - Java interface used for OSGi Services > - Implementation of the Java interface registered as a OSGi service. Note > that the package containing implementation is NOT exported > - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, > with a setter for the bean implementing the interface > - Wire everything together with Blueprint - create a for the > service, a for the RouteBuilder and inject the service reference, > and use the RouteBuilder in a CamelContext. > After all this is deployed, stop the bundle implementing the service. A > ServiceUnavailableException should be thrown after a timeout, but the object > that was injected into the RouteBuilder process the request - so the > Blueprint Proxy is not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10462) Add MDC support to DefaultCamelContext startup/shutdown
Quinn Stevenson created CAMEL-10462: --- Summary: Add MDC support to DefaultCamelContext startup/shutdown Key: CAMEL-10462 URL: https://issues.apache.org/jira/browse/CAMEL-10462 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Quinn Stevenson Assignee: Quinn Stevenson Priority: Minor Camel supports MDC through the MDCUnitOfWork, so MDC keys/values are not set during context/route startup and shutdown. It would be nice to have the keys/values there during these phases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-10394) BlueprintCamelContext cannot find components created in RouteBuilder.configure method
[
https://issues.apache.org/jira/browse/CAMEL-10394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15582731#comment-15582731
]
Quinn Stevenson commented on CAMEL-10394:
-
Could this be related to https://issues.apache.org/jira/browse/CAMEL-9570?
If I use the same type of workaround (a subclass of BlueprintCamelContext and
bypass the Camel Blueprint Extender), I can make it work.
> BlueprintCamelContext cannot find components created in
> RouteBuilder.configure method
> -
>
> Key: CAMEL-10394
> URL: https://issues.apache.org/jira/browse/CAMEL-10394
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint
>Reporter: Quinn Stevenson
>Assignee: Grzegorz Grzybek
>
> When a simple java RouteBuilder that creates a component and adds it to the
> context in the configure method is used in a blueprint, the context cannot
> find the component.
> Example Builder:
> public class TimerRouteBuilder extends RouteBuilder {
> @Override
> public void configure() throws Exception {
> TimerComponent timerComponent = new TimerComponent();
> getContext().addComponent("my-timer", timerComponent);
> from( "my-timer://test-timer")
> .log("Timer Fired")
> .to("mock://result");
> }
> }
> Example Blueprint:
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> http://camel.apache.org/schema/blueprint
> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd";>
> class="com.pronoia.camel.builder.TimerRouteBuilder"/>
> xmlns="http://camel.apache.org/schema/blueprint";>
>
>
>
> This test fails:
> public class BlueprintTest extends CamelBlueprintTestSupport {
> @EndpointInject(uri = "mock://result")
> MockEndpoint result;
> @Override
> protected String getBlueprintDescriptor() {
> return "/OSGI-INF/blueprint/blueprint.xml";
> }
> @Test
> public void testRoute() throws Exception {
> result.expectedMessageCount(5);
> assertMockEndpointsSatisfied(10, TimeUnit.SECONDS);
> }
> }
> But this test passes
> public class CamelTest extends CamelTestSupport {
> @EndpointInject(uri = "mock://result")
> MockEndpoint result;
> @Override
> protected RoutesBuilder createRouteBuilder() throws Exception {
> return new TimerRouteBuilder();
> }
> @Test
> public void testRoute() throws Exception {
> result.expectedMessageCount(5);
> assertMockEndpointsSatisfied(10, TimeUnit.SECONDS);
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-10394) BlueprintCamelContext cannot find components created in RouteBuilder.configure method
Quinn Stevenson created CAMEL-10394:
---
Summary: BlueprintCamelContext cannot find components created in
RouteBuilder.configure method
Key: CAMEL-10394
URL: https://issues.apache.org/jira/browse/CAMEL-10394
Project: Camel
Issue Type: Bug
Components: camel-blueprint
Reporter: Quinn Stevenson
Assignee: Grzegorz Grzybek
When a simple java RouteBuilder that creates a component and adds it to the
context in the configure method is used in a blueprint, the context cannot find
the component.
Example Builder:
public class TimerRouteBuilder extends RouteBuilder {
@Override
public void configure() throws Exception {
TimerComponent timerComponent = new TimerComponent();
getContext().addComponent("my-timer", timerComponent);
from( "my-timer://test-timer")
.log("Timer Fired")
.to("mock://result");
}
}
Example Blueprint:
http://www.osgi.org/xmlns/blueprint/v1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint
http://camel.apache.org/schema/blueprint/camel-blueprint.xsd";>
http://camel.apache.org/schema/blueprint";>
This test fails:
public class BlueprintTest extends CamelBlueprintTestSupport {
@EndpointInject(uri = "mock://result")
MockEndpoint result;
@Override
protected String getBlueprintDescriptor() {
return "/OSGI-INF/blueprint/blueprint.xml";
}
@Test
public void testRoute() throws Exception {
result.expectedMessageCount(5);
assertMockEndpointsSatisfied(10, TimeUnit.SECONDS);
}
}
But this test passes
public class CamelTest extends CamelTestSupport {
@EndpointInject(uri = "mock://result")
MockEndpoint result;
@Override
protected RoutesBuilder createRouteBuilder() throws Exception {
return new TimerRouteBuilder();
}
@Test
public void testRoute() throws Exception {
result.expectedMessageCount(5);
assertMockEndpointsSatisfied(10, TimeUnit.SECONDS);
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (CAMEL-10303) MllpTcpServerConsumer fails silently on acknowledgment failure
[ https://issues.apache.org/jira/browse/CAMEL-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-10303 started by Quinn Stevenson. --- > MllpTcpServerConsumer fails silently on acknowledgment failure > -- > > Key: CAMEL-10303 > URL: https://issues.apache.org/jira/browse/CAMEL-10303 > Project: Camel > Issue Type: Bug > Components: camel-mllp >Affects Versions: 2.17.0, 2.17.1, 2.17.2, 2.17.3 >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson > > If an error occurs when MllpTcpServerConsumer is delivering the > acknowledgment back to the caller, there is now way to tell that the > acknowledgement failed. > The MllpTcpServerConsumer needs to make the route fail and log an error about > the condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10303) MllpTcpServerConsumer fails silently on acknowledgment failure
Quinn Stevenson created CAMEL-10303: --- Summary: MllpTcpServerConsumer fails silently on acknowledgment failure Key: CAMEL-10303 URL: https://issues.apache.org/jira/browse/CAMEL-10303 Project: Camel Issue Type: Bug Components: camel-mllp Affects Versions: 2.17.3, 2.17.2, 2.17.1, 2.17.0 Reporter: Quinn Stevenson Assignee: Quinn Stevenson If an error occurs when MllpTcpServerConsumer is delivering the acknowledgment back to the caller, there is now way to tell that the acknowledgement failed. The MllpTcpServerConsumer needs to make the route fail and log an error about the condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-10242) camel-mllp - Enhance Camel to support idleTimeout to avoid network resource wastage due to leak in caller code
[ https://issues.apache.org/jira/browse/CAMEL-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422772#comment-15422772 ] Quinn Stevenson commented on CAMEL-10242: - Adding support for the idleTimeout shouldn't be much of a problem for the MllpTcpServerConsumer, but the MllpTcpClientProducer is more involved. The MllpTcpServerConsumer already has a polling thread looking for incoming data, so it will be easy enough to add a check for receiving something within a given timeout. The granularity will be limited to multiples of the receiveTimout, but that shouldn't be too much of an issue. The MllpTcpClientProducer doesn't create any threads of it's own, so I'd need to add a thread in order to timeout a connection. I'm not sure we actually need the timeout for the MllpTcpClientProducer anyway, since the route can always set the CamelMllpCloseConnectionBeforeSend or CamelMllpResetConnectionBeforeSend exchange property and then "send" a dummy message - the connection will be closed/reset at that time. This makes more sense to me because the route will have a better idea what a "timeout" means for a MllpTcpClientProducer. My preference would be to add support for and idleTimeout to the MllpTcpServerConsumer, but leave the MllpTcpClientProducer alone. Thoughts? > camel-mllp - Enhance Camel to support idleTimeout to avoid network resource > wastage due to leak in caller code > -- > > Key: CAMEL-10242 > URL: https://issues.apache.org/jira/browse/CAMEL-10242 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Affects Versions: 2.17.3 >Reporter: Venkateswara Rao Desu >Assignee: Quinn Stevenson > Fix For: Future > > > For a good client and Server , idle timeout is not required. > But when client has bugs which open socket but not close, then server would > have ESTABLISHED connections pilled up. Which end up restarting the process > or killing sockets manually. > To avoid this we should have idleTimeout for all mllp connections. > This is in reference to : > https://github.com/hqstevenson/camel-mllp/issues/14#issuecomment-238911254 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test
[ https://issues.apache.org/jira/browse/CAMEL-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422727#comment-15422727 ] Quinn Stevenson commented on CAMEL-6132: I was hoping to get some feedback on this - nothing? > camel-test-karaf - To allow end users more easily do Camel and Karaf > integration test > - > > Key: CAMEL-6132 > URL: https://issues.apache.org/jira/browse/CAMEL-6132 > Project: Camel > Issue Type: New Feature > Components: karaf >Reporter: Claus Ibsen >Assignee: Quinn Stevenson > Fix For: 2.18.0 > > > We should introduce a proper camel-test-karaf component that *end users* can > use to do Camel and Karaf integration tests. > The code we have in tests/camel-itest-karaf is for internal usage and testing > of Camel. The code is not polished and intended for end users. > We should create a new module for that, and take the good parts of > camel-itest-karaf and make it user friendly etc. And of course have docs to > go with as well. > And when its good, we can use that in camel-itest-karaf also (eat our own dog > food) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[ https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422725#comment-15422725 ] Quinn Stevenson commented on CAMEL-9570: Sorry Brad - I guess I missed you're last comments - I just saw them when I was checking on this. I don't know if the two issues should be merged. I haven't tried to reproduce the other issue because it hasn't hit me :-) I'd leave it to the powers that be to decide if the two issues should be merged. It doesn't look like much is happening with this one - I went as far as I could short of re-writing the blueprint extender, so I'm not sure if anything will happen with this - I don't think I can fix it, at least not alone. > Blueprint Proxies are not used when injected into Java RouteBuilders > > > Key: CAMEL-9570 > URL: https://issues.apache.org/jira/browse/CAMEL-9570 > Project: Camel > Issue Type: Bug > Components: camel-blueprint, camel-core >Affects Versions: 2.16.2 >Reporter: Quinn Stevenson >Assignee: Christian Schneider > > Basic Conditions: > - Java interface used for OSGi Services > - Implementation of the Java interface registered as a OSGi service. Note > that the package containing implementation is NOT exported > - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, > with a setter for the bean implementing the interface > - Wire everything together with Blueprint - create a for the > service, a for the RouteBuilder and inject the service reference, > and use the RouteBuilder in a CamelContext. > After all this is deployed, stop the bundle implementing the service. A > ServiceUnavailableException should be thrown after a timeout, but the object > that was injected into the RouteBuilder process the request - so the > Blueprint Proxy is not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-10242) camel-mllp - Enhance Camel to support idleTimeout to avoid network resource wastage due to leak in caller code
[ https://issues.apache.org/jira/browse/CAMEL-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson reassigned CAMEL-10242: --- Assignee: Quinn Stevenson > camel-mllp - Enhance Camel to support idleTimeout to avoid network resource > wastage due to leak in caller code > -- > > Key: CAMEL-10242 > URL: https://issues.apache.org/jira/browse/CAMEL-10242 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Affects Versions: 2.17.3 >Reporter: Venkateswara Rao Desu >Assignee: Quinn Stevenson > Fix For: Future > > > For a good client and Server , idle timeout is not required. > But when client has bugs which open socket but not close, then server would > have ESTABLISHED connections pilled up. Which end up restarting the process > or killing sockets manually. > To avoid this we should have idleTimeout for all mllp connections. > This is in reference to : > https://github.com/hqstevenson/camel-mllp/issues/14#issuecomment-238911254 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[ https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15330121#comment-15330121 ] Quinn Stevenson commented on CAMEL-9570: Digging through the logs, I see on difference in the initialization phases - I see the following entry for the service proxy that doesn't work 2016-06-14 12:24:55,543 | DEBUG | Karaf local console user karaf | org.apache.aries.blueprint.container.BlueprintContainerImpl | 13 - org.apache.aries.blueprint.core - 1.6.1 | Recipe service-one is already instantiated and cannot be updated When the proxy is working correctly, I don't see this entry. > Blueprint Proxies are not used when injected into Java RouteBuilders > > > Key: CAMEL-9570 > URL: https://issues.apache.org/jira/browse/CAMEL-9570 > Project: Camel > Issue Type: Bug > Components: camel-blueprint, camel-core >Affects Versions: 2.16.2 >Reporter: Quinn Stevenson >Assignee: Christian Schneider > > Basic Conditions: > - Java interface used for OSGi Services > - Implementation of the Java interface registered as a OSGi service. Note > that the package containing implementation is NOT exported > - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, > with a setter for the bean implementing the interface > - Wire everything together with Blueprint - create a for the > service, a for the RouteBuilder and inject the service reference, > and use the RouteBuilder in a CamelContext. > After all this is deployed, stop the bundle implementing the service. A > ServiceUnavailableException should be thrown after a timeout, but the object > that was injected into the RouteBuilder process the request - so the > Blueprint Proxy is not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15328047#comment-15328047
]
Quinn Stevenson commented on CAMEL-9570:
I found a workaround - I haven't tested it throughly, but it works in the basic
case of my test.
I extended the BlueprintCamelContext, and then used that context as a normal
bean rather than using the camel blueprint extension namespace.
Here's the extended context I used
public class SimpleCamelBlueprintContext extends BlueprintCamelContext {
public SimpleCamelBlueprintContext(BundleContext bundleContext,
BlueprintContainer blueprintContainer) {
super(bundleContext, blueprintContainer);
}
public void setRoute(RouteBuilder builder) throws Exception {
this.addRoutes(builder);
}
@Override
public void init() throws Exception {
super.init();
super.start();
}
@Override
public void destroy() throws Exception {
super.destroy();
}
}
And here's a sample blueprint snippit
So as near as I can tell, something in the camel blueprint namespace extension
is causing the issue.
> Blueprint Proxies are not used when injected into Java RouteBuilders
>
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service. Note
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls,
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a for the
> service, a for the RouteBuilder and inject the service reference,
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service. A
> ServiceUnavailableException should be thrown after a timeout, but the object
> that was injected into the RouteBuilder process the request - so the
> Blueprint Proxy is not used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[ https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15302841#comment-15302841 ] Quinn Stevenson commented on CAMEL-9570: The basic versions of the source are in this JIRA at the top, but I just push the current incarnation of my testing components to GitHub ( https://github.com/hqstevenson/example-camel-osgi-service-testing ). As far a I know, this has been there forever. I first noticed some strange behavior with Camel 2.12 (at least that's what I remember), but I didn't ever track down exactly what was going on until Camel 2.16. I actually have a bunch of blueprint files. There are three bundles that make up the services I'm using for testing - one that contains the java interface for the service and two that have implementations of the service. I recently moved the basic implementation of the service into and abstract class in the service interface bundle (because I got tired of changing code twice every time I wanted the service implementations to log something more/different), but that didn't have any effect on the behavior. The service implementations from the two bundles are exposed using a blueprint file in each bundle, and the implementing classes are not exported from the bundle. The bundle containing the camel consumer has three blueprint files in it. One defines the service references (used by the other two), one defines the camel context and configures the route builder, and the final one configures a plain java object to call the same service (i.e. no Camel involved). If you clone the project, you'll see another bundle as well - it has a blueprint that doesn't use camel that calls services (similar to the camel bundle, just without camel). I was trying to reproduce the behavior with this bundle, but I couldn't. > Blueprint Proxies are not used when injected into Java RouteBuilders > > > Key: CAMEL-9570 > URL: https://issues.apache.org/jira/browse/CAMEL-9570 > Project: Camel > Issue Type: Bug > Components: camel-blueprint, camel-core >Affects Versions: 2.16.2 >Reporter: Quinn Stevenson >Assignee: Christian Schneider > > Basic Conditions: > - Java interface used for OSGi Services > - Implementation of the Java interface registered as a OSGi service. Note > that the package containing implementation is NOT exported > - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, > with a setter for the bean implementing the interface > - Wire everything together with Blueprint - create a for the > service, a for the RouteBuilder and inject the service reference, > and use the RouteBuilder in a CamelContext. > After all this is deployed, stop the bundle implementing the service. A > ServiceUnavailableException should be thrown after a timeout, but the object > that was injected into the RouteBuilder process the request - so the > Blueprint Proxy is not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[ https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15302599#comment-15302599 ] Quinn Stevenson commented on CAMEL-9570: Thanks Brad - No - I stripped out everything I could to keep things as simple as possible and reproduce the issue. The only annotation I have anywhere in any of these bundles is Override - I don't think that should effect anything. > Blueprint Proxies are not used when injected into Java RouteBuilders > > > Key: CAMEL-9570 > URL: https://issues.apache.org/jira/browse/CAMEL-9570 > Project: Camel > Issue Type: Bug > Components: camel-blueprint, camel-core >Affects Versions: 2.16.2 >Reporter: Quinn Stevenson >Assignee: Christian Schneider > > Basic Conditions: > - Java interface used for OSGi Services > - Implementation of the Java interface registered as a OSGi service. Note > that the package containing implementation is NOT exported > - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, > with a setter for the bean implementing the interface > - Wire everything together with Blueprint - create a for the > service, a for the RouteBuilder and inject the service reference, > and use the RouteBuilder in a CamelContext. > After all this is deployed, stop the bundle implementing the service. A > ServiceUnavailableException should be thrown after a timeout, but the object > that was injected into the RouteBuilder process the request - so the > Blueprint Proxy is not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[ https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15302561#comment-15302561 ] Quinn Stevenson commented on CAMEL-9570: Thank You Claus - I was going to reach out to the other teams, but I'm pretty sure this problem is in Camel - not Blueprint of Karaf. The reason I say that is I tried to replicate the issue using a plain Blueprint XML, and I couldn't. The plain blueprint initialized a simple bean the same way I initialize a the route builder in the Camel Blueprint XML, and then started a thread that called the bean periodically (just like the timer-driver java RouteBuilder does). With this configuration, I couldn't reproduce the issue. I then put the plain blueprint XML in the same bundle as the Camel blueprint XML, and found that the plain blueprint XML was effected by the Camel Blueprint XML. When the component in the plain blueprint XML called the service via the proxy (obtained from the blueprint container), it behaved exactly the same way as the Camel blueprint XML. I also tried this when the route in the route builder was not auto-started, and that had no effect (i.e. I still didn't get the new service, and the original instance of the service is continued to be called even though the bundle exporting that service has been stopped) Then I tried the bundle with both blueprint XMLs, but I did NOT put the route builder in the camel context. In this situation, the component in the plain blueprint XML behaved as expected. Based on all of this, it looks to me like the blueprint proxy is being modified when the camel context is initialized. Either that Camel is effecting the way the proxy is created before it is put in the blueprint context. If you can you point me to the right spot in the code where this type of initialization occurs, I'd be very grateful. I've spent many hours tracing through the camel code in a debugger, be I get lost in all the dynamic proxies and reflection manipulations - I'm not sure where to focus. > Blueprint Proxies are not used when injected into Java RouteBuilders > > > Key: CAMEL-9570 > URL: https://issues.apache.org/jira/browse/CAMEL-9570 > Project: Camel > Issue Type: Bug > Components: camel-blueprint, camel-core >Affects Versions: 2.16.2 >Reporter: Quinn Stevenson >Assignee: Christian Schneider > > Basic Conditions: > - Java interface used for OSGi Services > - Implementation of the Java interface registered as a OSGi service. Note > that the package containing implementation is NOT exported > - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, > with a setter for the bean implementing the interface > - Wire everything together with Blueprint - create a for the > service, a for the RouteBuilder and inject the service reference, > and use the RouteBuilder in a CamelContext. > After all this is deployed, stop the bundle implementing the service. A > ServiceUnavailableException should be thrown after a timeout, but the object > that was injected into the RouteBuilder process the request - so the > Blueprint Proxy is not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[ https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300868#comment-15300868 ] Quinn Stevenson commented on CAMEL-9570: Does anybody have any other ideas? I really need this fixed - I just don't know where to look and what to try next. > Blueprint Proxies are not used when injected into Java RouteBuilders > > > Key: CAMEL-9570 > URL: https://issues.apache.org/jira/browse/CAMEL-9570 > Project: Camel > Issue Type: Bug > Components: camel-blueprint, camel-core >Affects Versions: 2.16.2 >Reporter: Quinn Stevenson >Assignee: Christian Schneider > > Basic Conditions: > - Java interface used for OSGi Services > - Implementation of the Java interface registered as a OSGi service. Note > that the package containing implementation is NOT exported > - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, > with a setter for the bean implementing the interface > - Wire everything together with Blueprint - create a for the > service, a for the RouteBuilder and inject the service reference, > and use the RouteBuilder in a CamelContext. > After all this is deployed, stop the bundle implementing the service. A > ServiceUnavailableException should be thrown after a timeout, but the object > that was injected into the RouteBuilder process the request - so the > Blueprint Proxy is not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test
[ https://issues.apache.org/jira/browse/CAMEL-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300865#comment-15300865 ] Quinn Stevenson commented on CAMEL-6132: Any comments on the example as it stands? > camel-test-karaf - To allow end users more easily do Camel and Karaf > integration test > - > > Key: CAMEL-6132 > URL: https://issues.apache.org/jira/browse/CAMEL-6132 > Project: Camel > Issue Type: New Feature > Components: karaf >Reporter: Claus Ibsen >Assignee: Quinn Stevenson > Fix For: 2.18.0 > > > We should introduce a proper camel-test-karaf component that *end users* can > use to do Camel and Karaf integration tests. > The code we have in tests/camel-itest-karaf is for internal usage and testing > of Camel. The code is not polished and intended for end users. > We should create a new module for that, and take the good parts of > camel-itest-karaf and make it user friendly etc. And of course have docs to > go with as well. > And when its good, we can use that in camel-itest-karaf also (eat our own dog > food) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15297283#comment-15297283
]
Quinn Stevenson commented on CAMEL-9570:
I tried changing the route to use a processor exposed as an OSGi service
instead of a bean ( i.e. process( svc ) instead of .to ("bean:"), and the
result is the same - dynamic changes don't happen and the route continues to
call the processor even after the bundle exposing the processor as a service is
stopped.
I also tried putting a simple wrapper object around the service and injecting
that into the route builder instead - same results.
I'm running out of things to try in order to figure out what is going on here -
let alone fix it.
> Blueprint Proxies are not used when injected into Java RouteBuilders
>
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service. Note
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls,
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a for the
> service, a for the RouteBuilder and inject the service reference,
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service. A
> ServiceUnavailableException should be thrown after a timeout, but the object
> that was injected into the RouteBuilder process the request - so the
> Blueprint Proxy is not used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[ https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15296747#comment-15296747 ] Quinn Stevenson commented on CAMEL-9570: One more thing - I noticed one change in the stack trace for the case when the service-reference is injected into the route builder. When the route is initially running, the service is called via sun.reflect.NativeMethodAccessorImpl. However, after the OSGi service is stopped (when I'd expect the call to pickup a new service, blocking until one becomes available), the stack changes and the service is called via a sun.reflect.GeneratedMethodAccessor. Initial stack trace at com.pronoia.osgi.service.impl.ServiceOneImplementation.execute(ServiceOneImplementation.java:20) at Proxye4dcb4b6_278e_4b9e_b700_e969c2379f0d.execute(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_91] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_91] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_91] at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_91] at org.apache.camel.component.bean.MethodInfo.invoke(MethodInfo.java:408)[55:org.apache.camel.camel-core:2.18.0.SNAPSHOT] Stack trace after service is stopped at com.pronoia.osgi.service.impl.ServiceOneImplementation.execute(ServiceOneImplementation.java:20) at Proxye4dcb4b6_278e_4b9e_b700_e969c2379f0d.execute(Unknown Source) at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_91] at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_91] at org.apache.camel.component.bean.MethodInfo.invoke(MethodInfo.java:408)[55:org.apache.camel.camel-core:2.18.0.SNAPSHOT] > Blueprint Proxies are not used when injected into Java RouteBuilders > > > Key: CAMEL-9570 > URL: https://issues.apache.org/jira/browse/CAMEL-9570 > Project: Camel > Issue Type: Bug > Components: camel-blueprint, camel-core >Affects Versions: 2.16.2 >Reporter: Quinn Stevenson >Assignee: Christian Schneider > > Basic Conditions: > - Java interface used for OSGi Services > - Implementation of the Java interface registered as a OSGi service. Note > that the package containing implementation is NOT exported > - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, > with a setter for the bean implementing the interface > - Wire everything together with Blueprint - create a for the > service, a for the RouteBuilder and inject the service reference, > and use the RouteBuilder in a CamelContext. > After all this is deployed, stop the bundle implementing the service. A > ServiceUnavailableException should be thrown after a timeout, but the object > that was injected into the RouteBuilder process the request - so the > Blueprint Proxy is not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders
[ https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15296728#comment-15296728 ] Quinn Stevenson commented on CAMEL-9570: A couple of more updates on this - I tried removing the OsgiServiceRegistry from the camel context - no effect I also tried this with another Blueprint that doesn't use camel but uses the same service reference - all in the same bundle. The BlueprintServiceConsumer starts a timer and calls the injected service - nothing else. The net of this is when the blueprint bundle behaves the same way as the camel bundle - i.e. when the service reference is injected into the route builder, the POJO in the blueprint bundle won't pickup new services either. I then removed the routebuilder from the camel context and tried again - this time the blueprint consumer works as expected. So it appears that the service proxy is being modified somehow when the routebuilder is initialized in by the camel context? Still digging - but this is strange > Blueprint Proxies are not used when injected into Java RouteBuilders > > > Key: CAMEL-9570 > URL: https://issues.apache.org/jira/browse/CAMEL-9570 > Project: Camel > Issue Type: Bug > Components: camel-blueprint, camel-core >Affects Versions: 2.16.2 >Reporter: Quinn Stevenson >Assignee: Christian Schneider > > Basic Conditions: > - Java interface used for OSGi Services > - Implementation of the Java interface registered as a OSGi service. Note > that the package containing implementation is NOT exported > - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, > with a setter for the bean implementing the interface > - Wire everything together with Blueprint - create a for the > service, a for the RouteBuilder and inject the service reference, > and use the RouteBuilder in a CamelContext. > After all this is deployed, stop the bundle implementing the service. A > ServiceUnavailableException should be thrown after a timeout, but the object > that was injected into the RouteBuilder process the request - so the > Blueprint Proxy is not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test
[ https://issues.apache.org/jira/browse/CAMEL-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291586#comment-15291586 ] Quinn Stevenson commented on CAMEL-6132: I opened a pull request with the initial version of camel-example-blueprint ( https://github.com/apache/camel/pull/987 ). Can you take a look and see what you think? I hit a few issues while doing this that should be addressed: - I had to use Pax Exam 4.8.0. Pax Exam 4.9.1 failed for some reason - I'm not really sure why - The example is using version 2.18.1 of the maven-surefire-plugin and the maven-failsafe-plugin. I had issues with 2.19.1 in the past, and I didn't get around to tracking those down, or even seeing if they would hit me for this example project - The logging is behaving very strangely. I'm not sure what's going on there - I'm getting a lot of debug output as well as some failures starting bundles in the CamelBlueprintTestSupport-based tests. I could use some help tracking it down. > camel-test-karaf - To allow end users more easily do Camel and Karaf > integration test > - > > Key: CAMEL-6132 > URL: https://issues.apache.org/jira/browse/CAMEL-6132 > Project: Camel > Issue Type: New Feature > Components: karaf >Reporter: Claus Ibsen >Assignee: Quinn Stevenson > Fix For: 2.18.0 > > > We should introduce a proper camel-test-karaf component that *end users* can > use to do Camel and Karaf integration tests. > The code we have in tests/camel-itest-karaf is for internal usage and testing > of Camel. The code is not polished and intended for end users. > We should create a new module for that, and take the good parts of > camel-itest-karaf and make it user friendly etc. And of course have docs to > go with as well. > And when its good, we can use that in camel-itest-karaf also (eat our own dog > food) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test
[ https://issues.apache.org/jira/browse/CAMEL-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272404#comment-15272404 ] Quinn Stevenson commented on CAMEL-6132: Sorry - typo. I meant to say "update the blueprint archetype" - not example (since it doesn't exist yet). The camel-example-cdi-osgi uses Pax Exam w/Karaf as well - I could look at updating that example to use CamelKarafTestSupport as well. > camel-test-karaf - To allow end users more easily do Camel and Karaf > integration test > - > > Key: CAMEL-6132 > URL: https://issues.apache.org/jira/browse/CAMEL-6132 > Project: Camel > Issue Type: New Feature > Components: karaf >Reporter: Claus Ibsen >Assignee: Quinn Stevenson > Fix For: 2.18.0 > > > We should introduce a proper camel-test-karaf component that *end users* can > use to do Camel and Karaf integration tests. > The code we have in tests/camel-itest-karaf is for internal usage and testing > of Camel. The code is not polished and intended for end users. > We should create a new module for that, and take the good parts of > camel-itest-karaf and make it user friendly etc. And of course have docs to > go with as well. > And when its good, we can use that in camel-itest-karaf also (eat our own dog > food) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test
[ https://issues.apache.org/jira/browse/CAMEL-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272284#comment-15272284 ] Quinn Stevenson commented on CAMEL-6132: Sounds Good - but I have a question on the example. I've used Pax Exam in two different scenarios, and I'm not sure which one is the right one for the example. In one case, I use the Pax Exam tests in the same module where the code I'm testing lives. In the other case, the Pax Exam tests are in a completely separate module, and just use the jar for the component they are testing. Both uses have their merits/downfalls - but I'm not sure which one makes the most sense for the example. One thought I had was to update the blueprint example with a Pax test to demonstrate the first scenario and then have the example projects demonstrate the second usage. Thoughts? > camel-test-karaf - To allow end users more easily do Camel and Karaf > integration test > - > > Key: CAMEL-6132 > URL: https://issues.apache.org/jira/browse/CAMEL-6132 > Project: Camel > Issue Type: New Feature > Components: karaf >Reporter: Claus Ibsen >Assignee: Quinn Stevenson > Fix For: 2.18.0 > > > We should introduce a proper camel-test-karaf component that *end users* can > use to do Camel and Karaf integration tests. > The code we have in tests/camel-itest-karaf is for internal usage and testing > of Camel. The code is not polished and intended for end users. > We should create a new module for that, and take the good parts of > camel-itest-karaf and make it user friendly etc. And of course have docs to > go with as well. > And when its good, we can use that in camel-itest-karaf also (eat our own dog > food) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test
[ https://issues.apache.org/jira/browse/CAMEL-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272269#comment-15272269 ] Quinn Stevenson commented on CAMEL-6132: Sorry - got pulled onto some other items for a bit. I see the CamelKarafTestSupport class is being used in the camel-itest-osgi tests now, so I'm not sure whats left for this JIRA. Is there anything else before we call this one done? > camel-test-karaf - To allow end users more easily do Camel and Karaf > integration test > - > > Key: CAMEL-6132 > URL: https://issues.apache.org/jira/browse/CAMEL-6132 > Project: Camel > Issue Type: New Feature > Components: karaf >Reporter: Claus Ibsen >Assignee: Quinn Stevenson > Fix For: 2.18.0 > > > We should introduce a proper camel-test-karaf component that *end users* can > use to do Camel and Karaf integration tests. > The code we have in tests/camel-itest-karaf is for internal usage and testing > of Camel. The code is not polished and intended for end users. > We should create a new module for that, and take the good parts of > camel-itest-karaf and make it user friendly etc. And of course have docs to > go with as well. > And when its good, we can use that in camel-itest-karaf also (eat our own dog > food) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9920) Handle SocketTimeoutException on accept
Quinn Stevenson created CAMEL-9920: -- Summary: Handle SocketTimeoutException on accept Key: CAMEL-9920 URL: https://issues.apache.org/jira/browse/CAMEL-9920 Project: Camel Issue Type: Bug Components: camel-mllp Affects Versions: 2.17.0 Reporter: Quinn Stevenson Assignee: Quinn Stevenson The MLLP receiver logs and error when a SocketTimeoutException is encountered while waiting for a connection. It will not successfully accept connections after that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9867) IndexOutOfBoundsException when MSH-18 is not present
Quinn Stevenson created CAMEL-9867: -- Summary: IndexOutOfBoundsException when MSH-18 is not present Key: CAMEL-9867 URL: https://issues.apache.org/jira/browse/CAMEL-9867 Project: Camel Issue Type: Bug Components: camel-mllp Affects Versions: 2.17.0 Reporter: Quinn Stevenson Assignee: Quinn Stevenson The MLLP Consumer is throwing a IndexOutOfBoundsException when the MSH segment doesn't contain enough segments to populate the headers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8502) Camel BOM for Maven users
[ https://issues.apache.org/jira/browse/CAMEL-8502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15227260#comment-15227260 ] Quinn Stevenson commented on CAMEL-8502: I'm starting on this one, but I'm not quite sure how you want the top-level POMs split up. Currently, there is a org.apache.camel/camel POM and a org.apache.camel/came-parent POM, and configuration is split across the two. I'm creating an org.apache.camel/camel-bom with all the library dependencies in it (in dependencyManagement), but that's all. I'm running into trouble with determining the parent for the BOM. Everything else uses org.apache.camel/camel, but the BOM can't do that because of the extra configuration in that project. It seems the right thing to do is make the org.apache.camel/camel project simply a placeholder for all the child modules. Does that sound correct? > Camel BOM for Maven users > - > > Key: CAMEL-8502 > URL: https://issues.apache.org/jira/browse/CAMEL-8502 > Project: Camel > Issue Type: New Feature > Components: build system >Reporter: Claus Ibsen > Fix For: Future > > > We should consider introducing a real Maven BOM (bill of material) that Camel > end users can import and use when working on camel maven projects. Then the > BOM imports the version dependencies and whatnot that Camel uses. > Today camel-parent can be sorta used for that, but it was for internal camel > usage. > Having a BOM is the proper way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9754) Convert from maven-bundle-plugin to bnd-maven-plugin
[ https://issues.apache.org/jira/browse/CAMEL-9754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224939#comment-15224939 ] Quinn Stevenson commented on CAMEL-9754: I've worked through the basics for this, and it looks very promising. I'm waiting for version 3.2.0 of the bnd-maven-plugin because I need the -snapshot=SNAPSHOT functionality to replicated what is currently done by the maven-bundle-plugin. > Convert from maven-bundle-plugin to bnd-maven-plugin > > > Key: CAMEL-9754 > URL: https://issues.apache.org/jira/browse/CAMEL-9754 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Quinn Stevenson > > Currently, the v2.3.7 of the maven-bundle-plugin is used to generate the OSGi > Manifests for the Camel libraries. The project cannot upgrade to a later > version of the maven-bundle-plugin because the newer versions break the build. > The bnd-maven-plugin is maintained by the same group that maintains the BND > libraries (which both plugins use internally) expedites updates to the plugin > when the underlying libraries change. Also, the bnd-maven-plugin uses the > same BND configuration file format as BND, which eliminates the complex > mapping from XML to BND configuration that the maven-bundle-plugin has to > deal with. > The goals are: > - change from the maven-bundle-plugin to the bnd-maven-plugin > - upgrade the OSGi version > - upgrade the default OSGi dependencies in the parent POM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test
[ https://issues.apache.org/jira/browse/CAMEL-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218722#comment-15218722 ] Quinn Stevenson commented on CAMEL-6132: The first iteration on this will create the camel-test-karaf module, and move the AbstractFeatureTest class from the camel-itest-karaf module to the new camel-test-karaf module. I'm also going to include some of the configuration to help keep the Karaf instances from hanging around after the tests. I should have the PR ready tomorrow > camel-test-karaf - To allow end users more easily do Camel and Karaf > integration test > - > > Key: CAMEL-6132 > URL: https://issues.apache.org/jira/browse/CAMEL-6132 > Project: Camel > Issue Type: New Feature > Components: karaf >Reporter: Claus Ibsen >Assignee: Quinn Stevenson > Fix For: Future > > > We should introduce a proper camel-test-karaf component that *end users* can > use to do Camel and Karaf integration tests. > The code we have in tests/camel-itest-karaf is for internal usage and testing > of Camel. The code is not polished and intended for end users. > We should create a new module for that, and take the good parts of > camel-itest-karaf and make it user friendly etc. And of course have docs to > go with as well. > And when its good, we can use that in camel-itest-karaf also (eat our own dog > food) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9754) Convert from maven-bundle-plugin to bnd-maven-plugin
Quinn Stevenson created CAMEL-9754: -- Summary: Convert from maven-bundle-plugin to bnd-maven-plugin Key: CAMEL-9754 URL: https://issues.apache.org/jira/browse/CAMEL-9754 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Quinn Stevenson Currently, the v2.3.7 of the maven-bundle-plugin is used to generate the OSGi Manifests for the Camel libraries. The project cannot upgrade to a later version of the maven-bundle-plugin because the newer versions break the build. The bnd-maven-plugin is maintained by the same group that maintains the BND libraries (which both plugins use internally) expedites updates to the plugin when the underlying libraries change. Also, the bnd-maven-plugin uses the same BND configuration file format as BND, which eliminates the complex mapping from XML to BND configuration that the maven-bundle-plugin has to deal with. The goals are: - change from the maven-bundle-plugin to the bnd-maven-plugin - upgrade the OSGi version - upgrade the default OSGi dependencies in the parent POM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test
[ https://issues.apache.org/jira/browse/CAMEL-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn Stevenson reassigned CAMEL-6132: -- Assignee: Quinn Stevenson > camel-test-karaf - To allow end users more easily do Camel and Karaf > integration test > - > > Key: CAMEL-6132 > URL: https://issues.apache.org/jira/browse/CAMEL-6132 > Project: Camel > Issue Type: New Feature > Components: karaf >Reporter: Claus Ibsen >Assignee: Quinn Stevenson > Fix For: Future > > > We should introduce a proper camel-test-karaf component that *end users* can > use to do Camel and Karaf integration tests. > The code we have in tests/camel-itest-karaf is for internal usage and testing > of Camel. The code is not polished and intended for end users. > We should create a new module for that, and take the good parts of > camel-itest-karaf and make it user friendly etc. And of course have docs to > go with as well. > And when its good, we can use that in camel-itest-karaf also (eat our own dog > food) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test
[ https://issues.apache.org/jira/browse/CAMEL-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15210274#comment-15210274 ] Quinn Stevenson commented on CAMEL-6132: I have a start on this I put together while working with a customer - I'll get a PR going so it can be reviewed. However, with the discussion going on about what version(s) of Karaf will be supported, should we have a module for each version of karaf? (something like camel-test-karaf-v2 and camel-test-karaf-v4) > camel-test-karaf - To allow end users more easily do Camel and Karaf > integration test > - > > Key: CAMEL-6132 > URL: https://issues.apache.org/jira/browse/CAMEL-6132 > Project: Camel > Issue Type: New Feature > Components: karaf >Reporter: Claus Ibsen > Fix For: Future > > > We should introduce a proper camel-test-karaf component that *end users* can > use to do Camel and Karaf integration tests. > The code we have in tests/camel-itest-karaf is for internal usage and testing > of Camel. The code is not polished and intended for end users. > We should create a new module for that, and take the good parts of > camel-itest-karaf and make it user friendly etc. And of course have docs to > go with as well. > And when its good, we can use that in camel-itest-karaf also (eat our own dog > food) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9699) Change the default for DataSets used as sources to zero
[ https://issues.apache.org/jira/browse/CAMEL-9699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15195607#comment-15195607 ] Quinn Stevenson commented on CAMEL-9699: Claus - Thank you for granting my JIRA user karma to self-assign tickets. A process question - does that mean I should resolve tickets once I complete work on them? > Change the default for DataSets used as sources to zero > --- > > Key: CAMEL-9699 > URL: https://issues.apache.org/jira/browse/CAMEL-9699 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Quinn Stevenson >Assignee: Quinn Stevenson >Priority: Minor > Fix For: 2.17.0 > > > Change the current behavior of the DataSet component such that the expected > message count defaults to zero for DataSets used as a source (i.e. > DataSetConsumers). > The reasoning behind this is as follows. > I use the DataSet component for simple load testing. When I use a DataSet as > a source (i.e. from(“dataset://my-dataset”) ), the > assertMockEndpointsSatisfied() always fails because the expectedMessageSize > is set to the size of the DataSet. I either have to explicitly set the > expected message count on the endpoint to zero ( getMockEndpoint( > “dataset://my-dataset”).expectedMessageCount( 0 ), or I have to assert all of > the other mock endpoints individually (i.e not use > assertMockEndpointsSatisfied() ). > I rarely use the same dataset as both a source (i.e. from(“dataset://…”) ) > and a target (i.e. to( “dataset://…”) ), so this behavior doesn’t make much > sense to me. Additionally, I can’t use the same DataSet as the source and > target when the source message count would be different than the target > message count - which would be the case for a route that does some simple > filtering, and all I want to assert is the correct number of messages came > through. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9699) Change the default for DataSets used as sources to zero
[ https://issues.apache.org/jira/browse/CAMEL-9699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194139#comment-15194139 ] Quinn Stevenson commented on CAMEL-9699: The PR for this has been merged (thank you Claus), and the documentation for the dataset on the wiki has been updated. > Change the default for DataSets used as sources to zero > --- > > Key: CAMEL-9699 > URL: https://issues.apache.org/jira/browse/CAMEL-9699 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Quinn Stevenson >Priority: Minor > > Change the current behavior of the DataSet component such that the expected > message count defaults to zero for DataSets used as a source (i.e. > DataSetConsumers). > The reasoning behind this is as follows. > I use the DataSet component for simple load testing. When I use a DataSet as > a source (i.e. from(“dataset://my-dataset”) ), the > assertMockEndpointsSatisfied() always fails because the expectedMessageSize > is set to the size of the DataSet. I either have to explicitly set the > expected message count on the endpoint to zero ( getMockEndpoint( > “dataset://my-dataset”).expectedMessageCount( 0 ), or I have to assert all of > the other mock endpoints individually (i.e not use > assertMockEndpointsSatisfied() ). > I rarely use the same dataset as both a source (i.e. from(“dataset://…”) ) > and a target (i.e. to( “dataset://…”) ), so this behavior doesn’t make much > sense to me. Additionally, I can’t use the same DataSet as the source and > target when the source message count would be different than the target > message count - which would be the case for a route that does some simple > filtering, and all I want to assert is the correct number of messages came > through. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9707) Add ListDataSet and FileDataSet
Quinn Stevenson created CAMEL-9707: -- Summary: Add ListDataSet and FileDataSet Key: CAMEL-9707 URL: https://issues.apache.org/jira/browse/CAMEL-9707 Project: Camel Issue Type: New Feature Components: camel-core Reporter: Quinn Stevenson Priority: Minor Add two additional DataSet implementation to help with testing. A ListDataSet that can use a Java List as a source, and a FileDataSet that can read messages from a File, optionally splitting the file using a specified delimiter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9699) Change the default for DataSets used as sources to zero
[ https://issues.apache.org/jira/browse/CAMEL-9699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191813#comment-15191813 ] Quinn Stevenson commented on CAMEL-9699: For some reason the PR didn't update this JIRA. Here's the link to the PR https://github.com/apache/camel/pull/897 > Change the default for DataSets used as sources to zero > --- > > Key: CAMEL-9699 > URL: https://issues.apache.org/jira/browse/CAMEL-9699 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Quinn Stevenson >Priority: Minor > > Change the current behavior of the DataSet component such that the expected > message count defaults to zero for DataSets used as a source (i.e. > DataSetConsumers). > The reasoning behind this is as follows. > I use the DataSet component for simple load testing. When I use a DataSet as > a source (i.e. from(“dataset://my-dataset”) ), the > assertMockEndpointsSatisfied() always fails because the expectedMessageSize > is set to the size of the DataSet. I either have to explicitly set the > expected message count on the endpoint to zero ( getMockEndpoint( > “dataset://my-dataset”).expectedMessageCount( 0 ), or I have to assert all of > the other mock endpoints individually (i.e not use > assertMockEndpointsSatisfied() ). > I rarely use the same dataset as both a source (i.e. from(“dataset://…”) ) > and a target (i.e. to( “dataset://…”) ), so this behavior doesn’t make much > sense to me. Additionally, I can’t use the same DataSet as the source and > target when the source message count would be different than the target > message count - which would be the case for a route that does some simple > filtering, and all I want to assert is the correct number of messages came > through. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
