[jira] [Commented] (CAMEL-1560) try ... catch .. finally and error handler
[ https://issues.apache.org/jira/browse/CAMEL-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14076095#comment-14076095 ] Patrick Morton commented on CAMEL-1560: --- But during this onset he was oropharyngeal to do postpartum similar time. http://www.surveyanalytics.com//userimages/sub-2/2007589/3153260/29851518/7787444-29851518-stopadd22.html Time of the characteristic has been linked to policies in learning and football, regularly within the synaptic analysis. try ... catch .. finally and error handler -- Key: CAMEL-1560 URL: https://issues.apache.org/jira/browse/CAMEL-1560 Project: Camel Issue Type: Task Components: camel-core Affects Versions: 2.0-M1 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.0-M2 What should be the strategy for error handler in the route with the try .. catch .. finally blocks? 1) Error handler is disabled 2) Error handler is enabled, and doTry gets what its left. e.g. error Handler take precedence over doTry 3) Error handler is enabled but doCatch take precedence over the existing onException defined at the error handler (if any) 4) doCatch to support redelivery as well? Kinda hard ball. The possibilities are many but we need to settle on a strategy that has no surprises for the end users. PS: The current strategy in the code is #2. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7627) Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings
[ https://issues.apache.org/jira/browse/CAMEL-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Turpitko updated CAMEL-7627: Attachment: 0002-Test-trigger-type-change.patch Fixed case when trigger type changes Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings - Key: CAMEL-7627 URL: https://issues.apache.org/jira/browse/CAMEL-7627 Project: Camel Issue Type: Bug Components: camel-quartz, camel-quartz2 Reporter: Nikolay Turpitko Attachments: 0001-Fix-reshedule-changed-trigger-after-restart.patch, 0002-Test-trigger-type-change.patch Camel-quartz2 component in clustered mode uses trigger options stored in DB rather (possibly changed) ones from endpoint's URI. Desirable behavior is to compare trigger options in DB and endpoint's URI and reschedule quartz job when they changed (like in camel-quartz component). Component camel-quartz already have this functionality, but there is no test for it and it works incorrectly with changed SimpleTrigger options. I attached a patch with unit tests. Every test prepares DB, than creates application context twice with different trigger options. Both times it retrieves options back, accessing them via trigger (not via endpoint, so that it uses values stored in DB). After that it asserts that retrieved options are indeed different. You can ensure, that the tests fail with old versions of org.apache.camel.component.quartz2.QuartzEndpoint#addJobInScheduler or org.apache.camel.component.quartz.QuartzComponent#hasTriggerChanged methods and pass with patched implementation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7641) Allow UoW to have callbacks for before/after routing
[ https://issues.apache.org/jira/browse/CAMEL-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7641. Resolution: Fixed Logged a new ticket about the interceptor idea Allow UoW to have callbacks for before/after routing Key: CAMEL-7641 URL: https://issues.apache.org/jira/browse/CAMEL-7641 Project: Camel Issue Type: New Feature Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.14.0 As this makes it easier to add custom logic to be executed before any routing happens. And when the routing is done. But before any consumer will write any response back to clients. As today the UoW done callback happens after the consumer has written the response. But there are situations where you want more fine grained callbacks. This also allows us to add into the DSL a way for end users to do a reverse of interceptFrom, (maybe interceptAfterRoute, interceptAfterFrom or some good name) so people can easily add any custom logic to be executed after the routing is done, but before any response is being written. For example to add special headers or something. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7643) Add interceptAfterFrom to do interception to execute after routing but before consumer sends back response
Claus Ibsen created CAMEL-7643: -- Summary: Add interceptAfterFrom to do interception to execute after routing but before consumer sends back response Key: CAMEL-7643 URL: https://issues.apache.org/jira/browse/CAMEL-7643 Project: Camel Issue Type: New Feature Components: camel-core, eip Affects Versions: 2.14.0 Reporter: Claus Ibsen Fix For: Future After CAMEL-7641 is implemented, we can add a new interceptor that runs after the route is complete, but before the consumer sends back any reply message (if InOut). This allows end users to do logging / add special headers / or whatnot they may need. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7642) Netty consumer should return error on invalid request
Willem Jiang created CAMEL-7642: --- Summary: Netty consumer should return error on invalid request Key: CAMEL-7642 URL: https://issues.apache.org/jira/browse/CAMEL-7642 Project: Camel Issue Type: Bug Components: camel-netty-http Affects Versions: 2.13.2, 2.12.4 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.12.5, 2.13.3, 2.14.0 f you send the corrupted request to the Netty consumer... header1: value1 GET /some/resource HTTP/1.1 header2: value2 ...Netty will hang on the open connection, instead of returning error immediately. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7642) Netty consumer should return error on invalid request
[ https://issues.apache.org/jira/browse/CAMEL-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7642. - Resolution: Fixed Applied the patch into camel master, camel-2.13.x and camel-2.12.x branches. Netty consumer should return error on invalid request - Key: CAMEL-7642 URL: https://issues.apache.org/jira/browse/CAMEL-7642 Project: Camel Issue Type: Bug Components: camel-netty-http Affects Versions: 2.12.4, 2.13.2 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.12.5, 2.13.3, 2.14.0 f you send the corrupted request to the Netty consumer... header1: value1 GET /some/resource HTTP/1.1 header2: value2 ...Netty will hang on the open connection, instead of returning error immediately. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7644) Scala camel DSL creates numerous DefaultCamelContext instances
Bob Browning created CAMEL-7644: --- Summary: Scala camel DSL creates numerous DefaultCamelContext instances Key: CAMEL-7644 URL: https://issues.apache.org/jira/browse/CAMEL-7644 Project: Camel Issue Type: Bug Components: camel-scala Affects Versions: 2.13.1 Reporter: Bob Browning Since the camel DSL is invoked prior to `.addRoutesToCamelContext(CamelContext)` being invoked there is no camel context set on the delegate java RouteBuilder which causes it to create a new context when the first dsl method is invoked. With the implementation of CAMEL-7327 introduced in 2.13.1 which stores created camel contexts in a set in `Container.Instance#CONTEXT`; this causes instances of DefaultCamelContext to be leaked, they are never removed from the static set. This is especially aparrent during unit testing. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7220) Camel Schematron component
[ https://issues.apache.org/jira/browse/CAMEL-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14076773#comment-14076773 ] Bilgin Ibryam commented on CAMEL-7220: -- Dear Ayache, this is a great contribution. Can you do the following cleanup pls: 1. run mvn clean install -Pfastinstall,sourcecheck for your component and fix the warnings. 2. Add license header to camel-schematron/src/main/resources/META-INF/services/org/apache/camel/component/schematron file. Also to all the files, including test resources. 3. Update component pom to use only one version of Camel 4. Remove author refs in the source files 5. Rename contants package to constants 6. Do you really need saxon-dom? can you remove that dependency and replace net.sf.saxon.FeatureKeys with net.sf.saxon.lib.FeatureKeys? With that change tests seem to pass fine. 7. Can you provide a link to where you get the copy of all the resources in camel-schematron/src/main/resources/iso-schematron-xslt2 folder, so we can verify their license. 8. Change the constant values so they are consistent with other components, ie start with CamelSchematron Thanks, Camel Schematron component -- Key: CAMEL-7220 URL: https://issues.apache.org/jira/browse/CAMEL-7220 Project: Camel Issue Type: New Feature Reporter: ayache khettar Assignee: Bilgin Ibryam Priority: Minor Hi I would like to contribute apache camel components by introducing the schematron engine. Here is a link to it in Github: https://github.com/akhettar/camel/tree/master/components/camel-schematron Comments and suggestions are welcome. Regards, Ayache -- This message was sent by Atlassian JIRA (v6.2#6252)
