[jira] [Comment Edited] (CAMEL-14788) Unable to Start Jetty server in OSGi environment
[
https://issues.apache.org/jira/browse/CAMEL-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067296#comment-17067296
]
Pedro Catalão edited comment on CAMEL-14788 at 3/26/20, 2:04 AM:
-
Hi [~cib...@e-ma.net], thanks for looking into it. I'm not sure if I understand
what you mean.
When I add Jetty directly to Karaf, I still get the exact same error :\
{code:java}
[INFO] Feature camel-jetty9/2.24.3 is defined as a boot feature
[INFO] adding maven artifact:
mvn:org.eclipse.jetty/jetty-server/9.4.25.v20191220{code}
{code:java}
243 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: Http Utility
245 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: IO Utility
254 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: Server Core
258 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: Utilities{code}
Shall I pinpoint {color:#0747a6}camel-jetty{color}'s version to a version prior
to the issue or can you think of a better way to tackle this?
Thanks,
Pedro
was (Author: pedrocatalao):
Hi Claus, thanks for looking into it. I'm not sure if I understand what you
mean.
When I add Jetty directly to Karaf, I still get the exact same error :\
{code:java}
[INFO] Feature camel-jetty9/2.24.3 is defined as a boot feature
[INFO] adding maven artifact:
mvn:org.eclipse.jetty/jetty-server/9.4.25.v20191220{code}
{code:java}
243 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: Http Utility
245 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: IO Utility
254 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: Server Core
258 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: Utilities{code}
Shall I pinpoint {color:#0747a6}camel-jetty{color}'s version to a version prior
to the issue or can you think of a better way to tackle this?
Thanks,
Pedro
> Unable to Start Jetty server in OSGi environment
>
>
> Key: CAMEL-14788
> URL: https://issues.apache.org/jira/browse/CAMEL-14788
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.24.3
>Reporter: Pedro Catalão
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.25.1, 3.2.0
>
>
> When deploying a spring XML via Karaf containing the Jetty component such as:
> {code:java}
>
> http://0.0.0.0:9000/test"/>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
> {code}
>
> Got this exception:
> {code:java}
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
> java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliance at
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
> java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
> org.eclipse.jetty.server [251] {code}
>
> While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses
> Jetty *{color:#172b4d}9.4.12.v20180830{color}* which is affected by this
> issue: [https://github.com/eclipse/jetty.project/issues/4350]
>
> This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling
> back the explicit exclusion of
> {color:#ff}MultiPartInputStreamParser{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14788) Unable to Start Jetty server in OSGi environment
[
https://issues.apache.org/jira/browse/CAMEL-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067296#comment-17067296
]
Pedro Catalão commented on CAMEL-14788:
---
Hi Claus, thanks for looking into it. I'm not sure if I understand what you
mean.
When I add Jetty directly to Karaf, I still get the exact same error :\
{code:java}
[INFO] Feature camel-jetty9/2.24.3 is defined as a boot feature
[INFO] adding maven artifact:
mvn:org.eclipse.jetty/jetty-server/9.4.25.v20191220{code}
{code:java}
243 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: Http Utility
245 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: IO Utility
254 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: Server Core
258 │ Active │ 80 │ 9.4.25.v20191220 │ Jetty :: Utilities{code}
Shall I pinpoint {color:#0747a6}camel-jetty{color}'s version to a version prior
to the issue or can you think of a better way to tackle this?
Thanks,
Pedro
> Unable to Start Jetty server in OSGi environment
>
>
> Key: CAMEL-14788
> URL: https://issues.apache.org/jira/browse/CAMEL-14788
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.24.3
>Reporter: Pedro Catalão
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.25.1, 3.2.0
>
>
> When deploying a spring XML via Karaf containing the Jetty component such as:
> {code:java}
>
> http://0.0.0.0:9000/test"/>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
> {code}
>
> Got this exception:
> {code:java}
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
> java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliance at
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
> java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
> org.eclipse.jetty.server [251] {code}
>
> While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses
> Jetty *{color:#172b4d}9.4.12.v20180830{color}* which is affected by this
> issue: [https://github.com/eclipse/jetty.project/issues/4350]
>
> This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling
> back the explicit exclusion of
> {color:#ff}MultiPartInputStreamParser{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14781) Support page missing toolbar breadcrumbs
[ https://issues.apache.org/jira/browse/CAMEL-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067279#comment-17067279 ] Solange Iyubu commented on CAMEL-14781: --- how may I access .html files for example to access support.html displayed when https://camel.apache.org/community/support/ is clicked > Support page missing toolbar breadcrumbs > > > Key: CAMEL-14781 > URL: https://issues.apache.org/jira/browse/CAMEL-14781 > Project: Camel > Issue Type: Bug > Components: website >Reporter: Solange Iyubu >Priority: Major > > While navigating on apache website I saw pages that don't have toolbars > breadcrumps such as support page from community. I am going to work on it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-13462) camel-azure - Allow a header to specify the blob name
[ https://issues.apache.org/jira/browse/CAMEL-13462?focusedWorklogId=409834=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409834 ] ASF GitHub Bot logged work on CAMEL-13462: -- Author: ASF GitHub Bot Created on: 25/Mar/20 21:32 Start Date: 25/Mar/20 21:32 Worklog Time Spent: 10m Work Description: djoleB commented on pull request #3682: [CAMEL-13462] - Override blob name using header implementation. URL: https://github.com/apache/camel/pull/3682 [JIRA TASK](https://issues.apache.org/jira/browse/CAMEL-13462) Using custom header to override blob name in the producer. Use lambda expressions in tests where it's possible. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 409834) Remaining Estimate: 0h Time Spent: 10m > camel-azure - Allow a header to specify the blob name > - > > Key: CAMEL-13462 > URL: https://issues.apache.org/jira/browse/CAMEL-13462 > Project: Camel > Issue Type: Improvement > Components: camel-azure >Reporter: Claus Ibsen >Assignee: Ramu >Priority: Major > Fix For: 3.x > > Time Spent: 10m > Remaining Estimate: 0h > > Currently the blob name is hardcoded from the endpoint uri. But if you want a > bit more dynamic then you cannot do this, and would need to use toD etc. > Ah yeah using toD can help resolve this, but mind if you have many unique > file names, you end up creating many endpoints. > We should also allow to specify a header with the blob name, then we can use > the same endpoint but let the header override the blob name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14793) Decrease default consumer request timeout to 30s
[ https://issues.apache.org/jira/browse/CAMEL-14793?focusedWorklogId=409828=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409828 ] ASF GitHub Bot logged work on CAMEL-14793: -- Author: ASF GitHub Bot Created on: 25/Mar/20 21:14 Start Date: 25/Mar/20 21:14 Worklog Time Spent: 10m Work Description: oscerd commented on pull request #3681: CAMEL-14793. Decrease default consumer request timeout to 30s URL: https://github.com/apache/camel/pull/3681 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 409828) Time Spent: 20m (was: 10m) > Decrease default consumer request timeout to 30s > - > > Key: CAMEL-14793 > URL: https://issues.apache.org/jira/browse/CAMEL-14793 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Affects Versions: 3.1.0 >Reporter: Marat Gubaidullin >Assignee: Andrea Cosentino >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Camel-kafka default Producer parameter request.timeout.ms = 305000, however > in Kafka documentation it is 3. Also it was changed in > https://issues.apache.org/jira/browse/KAFKA-7050 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14793) Decrease default consumer request timeout to 30s
[ https://issues.apache.org/jira/browse/CAMEL-14793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marat Gubaidullin updated CAMEL-14793: -- Description: Camel-kafka default Producer parameter request.timeout.ms = 305000, however in Kafka documentation it is 3. Also it was changed in https://issues.apache.org/jira/browse/KAFKA-7050 (was: Camel-kafla default Producer parameter request.timeout.ms = 305000, however in Kafka documentation it is 3. Also it was changed in https://issues.apache.org/jira/browse/KAFKA-7050) > Decrease default consumer request timeout to 30s > - > > Key: CAMEL-14793 > URL: https://issues.apache.org/jira/browse/CAMEL-14793 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Affects Versions: 3.1.0 >Reporter: Marat Gubaidullin >Assignee: Andrea Cosentino >Priority: Minor > > Camel-kafka default Producer parameter request.timeout.ms = 305000, however > in Kafka documentation it is 3. Also it was changed in > https://issues.apache.org/jira/browse/KAFKA-7050 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14793) Decrease default consumer request timeout to 30s
[ https://issues.apache.org/jira/browse/CAMEL-14793?focusedWorklogId=409827=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409827 ] ASF GitHub Bot logged work on CAMEL-14793: -- Author: ASF GitHub Bot Created on: 25/Mar/20 21:10 Start Date: 25/Mar/20 21:10 Worklog Time Spent: 10m Work Description: mgubaidullin commented on pull request #3681: CAMEL-14793. Decrease default consumer request timeout to 30s URL: https://github.com/apache/camel/pull/3681 Fix for https://issues.apache.org/jira/browse/CAMEL-14793 Align camel-kafka default Producer parameter requestTimeoutMs to Kafka default request.timeout.ms = 3 according to https://issues.apache.org/jira/browse/KAFKA-7050 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 409827) Remaining Estimate: 0h Time Spent: 10m > Decrease default consumer request timeout to 30s > - > > Key: CAMEL-14793 > URL: https://issues.apache.org/jira/browse/CAMEL-14793 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Affects Versions: 3.1.0 >Reporter: Marat Gubaidullin >Assignee: Andrea Cosentino >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Camel-kafka default Producer parameter request.timeout.ms = 305000, however > in Kafka documentation it is 3. Also it was changed in > https://issues.apache.org/jira/browse/KAFKA-7050 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-14793) Decrease default consumer request timeout to 30s
[ https://issues.apache.org/jira/browse/CAMEL-14793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reassigned CAMEL-14793: Assignee: Andrea Cosentino > Decrease default consumer request timeout to 30s > - > > Key: CAMEL-14793 > URL: https://issues.apache.org/jira/browse/CAMEL-14793 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Affects Versions: 3.1.0 >Reporter: Marat Gubaidullin >Assignee: Andrea Cosentino >Priority: Minor > > Camel-kafla default Producer parameter request.timeout.ms = 305000, however > in Kafka documentation it is 3. Also it was changed in > https://issues.apache.org/jira/browse/KAFKA-7050 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14793) Decrease default consumer request timeout to 30s
Marat Gubaidullin created CAMEL-14793: - Summary: Decrease default consumer request timeout to 30s Key: CAMEL-14793 URL: https://issues.apache.org/jira/browse/CAMEL-14793 Project: Camel Issue Type: Improvement Components: camel-kafka Affects Versions: 3.1.0 Reporter: Marat Gubaidullin Camel-kafla default Producer parameter request.timeout.ms = 305000, however in Kafka documentation it is 3. Also it was changed in https://issues.apache.org/jira/browse/KAFKA-7050 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14791) convert broken link: to checkable xref in camel-2.x
[ https://issues.apache.org/jira/browse/CAMEL-14791?focusedWorklogId=409766=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409766 ] ASF GitHub Bot logged work on CAMEL-14791: -- Author: ASF GitHub Bot Created on: 25/Mar/20 19:46 Start Date: 25/Mar/20 19:46 Worklog Time Spent: 10m Work Description: djencks commented on pull request #3680: Resolves CAMEL-14791: fix broken link: and <<>> constructs URL: https://github.com/apache/camel/pull/3680 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 409766) Time Spent: 20m (was: 10m) > convert broken link: to checkable xref in camel-2.x > --- > > Key: CAMEL-14791 > URL: https://issues.apache.org/jira/browse/CAMEL-14791 > Project: Camel > Issue Type: Sub-task > Components: website >Affects Versions: 3.1.0 >Reporter: David Jencks >Assignee: David Jencks >Priority: Major > Fix For: 3.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Broken link: are not detected by the xref-checker. > There may be missing id problems also. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn
[ https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067044#comment-17067044 ] Silvina Tamburini commented on CAMEL-14682: --- Hi! I'd like to contribute here. Is it possible? [~itolimaesther] [~zregvart] let me know if I can help here! > Upgrade the version of Yarn > --- > > Key: CAMEL-14682 > URL: https://issues.apache.org/jira/browse/CAMEL-14682 > Project: Camel > Issue Type: Improvement > Components: website >Reporter: Zoran Regvart >Priority: Minor > Labels: help-wanted > > We currently use version 1.22.0, we could upgrade to to 1.22.1, or even > better switch to 2.0 (berry) as it includes improvements to the PnP. > Switching to 2.0 (berry) would most likely require migration effort for some > of the dependencies we use. > The version needs to change both for the website build and for the > antora-ui-camel. Note that we vendor the Yarn within both of them via > [policies|https://classic.yarnpkg.com/en/docs/cli/policies]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14640) CVEs in the library dependencies
[ https://issues.apache.org/jira/browse/CAMEL-14640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067032#comment-17067032 ] Claus Ibsen commented on CAMEL-14640: - http client 3.1 is only used for testing but it would be good to switch it to http client 4.x > CVEs in the library dependencies > > > Key: CAMEL-14640 > URL: https://issues.apache.org/jira/browse/CAMEL-14640 > Project: Camel > Issue Type: Task >Reporter: XuCongying >Assignee: Andrea Cosentino >Priority: Major > Attachments: apache-camel_CVE-report.md > > > Hi, I found that your project are using some vulnerable dependencies. To > prevent potential risk it may cause, I suggest a library update. Here is the > details: > Vulnerable Library Version: com.squareup.okhttp3 : okhttp : 3.11.0 > CVE ID: > [CVE-2018-20200](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20200) > Import Path: components/camel-jetty/pom.xml > Suggested Safe Versions: 3.12.1, 3.12.2, 3.12.3, 3.12.4, 3.12.5, 3.12.6, > 3.12.7, 3.12.8, 3.13.0, 3.13.1, 3.14.0, 3.14.1, 3.14.2, 3.14.3, 3.14.4, > 3.14.5, 3.14.6, 4.0.0, 4.0.0-RC1, 4.0.0-RC2, 4.0.0-RC3, 4.0.0-alpha01, > 4.0.0-alpha02, 4.0.1, 4.1.0, 4.1.1, 4.2.0, 4.2.1, 4.2.2, 4.3.0, 4.3.1, 4.4.0 > Vulnerable Library Version: org.apache.tomcat.embed : tomcat-embed-core : > 8.5.0 > CVE ID: > [CVE-2016-0762](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0762), > > [CVE-2017-5650](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5650), > > [CVE-2016-6797](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6797), > > [CVE-2017-5647](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5647), > > [CVE-2017-5664](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5664), > > [CVE-2017-12617](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12617), > > [CVE-2016-3092](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3092), > > [CVE-2019-0199](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0199), > > [CVE-2017-5648](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5648), > > [CVE-2019-10072](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10072), > [CVE-2017-5651](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5651) > Import Path: components/camel-servlet/pom.xml > Suggested Safe Versions: 10.0.0-M1, 8.5.41, 8.5.42, 8.5.43, 8.5.45, 8.5.46, > 8.5.47, 8.5.49, 8.5.50, 8.5.51, 9.0.27, 9.0.29, 9.0.30, 9.0.31 > Vulnerable Library Version: org.apache.spark : spark-core_2.11 : 2.4.4 > CVE ID: > [CVE-2017-7678](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7678) > Import Path: components/camel-spark/pom.xml > Suggested Safe Versions: 2.4.5 > Vulnerable Library Version: org.apache.lucene : lucene-core : 3.6.0 > CVE ID: > [CVE-2017-3163](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3163) > Import Path: components/camel-jcr/pom.xml > Suggested Safe Versions: 6.4.1, 6.4.2, 6.5.0, 6.5.1, 6.6.0, 6.6.1, 6.6.2, > 6.6.3, 6.6.4, 6.6.5, 6.6.6, 7.0.0, 7.0.1, 7.1.0, 7.2.0, 7.2.1, 7.3.0, 7.3.1, > 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.7.1, 7.7.2, 8.0.0, 8.1.0, 8.1.1, 8.2.0, 8.3.0, > 8.3.1, 8.4.0, 8.4.1 > Vulnerable Library Version: org.apache.logging.log4j : log4j-api : 2.7 > CVE ID: > [CVE-2017-5645](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645) > Import Path: examples/camel-example-google-pubsub/pom.xml, > examples/camel-example-kafka/pom.xml, examples/camel-example-debezium/pom.xml > Suggested Safe Versions: 2.10.0, 2.11.0, 2.11.1, 2.11.2, 2.12.0, 2.12.1, > 2.13.0, 2.8.2, 2.9.0, 2.9.1 > Vulnerable Library Version: org.apache.hadoop : hadoop-hdfs : 2.7.4 > CVE ID: > [CVE-2018-11768](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11768) > Import Path: components/camel-hdfs/pom.xml, components/camel-hbase/pom.xml, > components/camel-hbase/pom.xml > Suggested Safe Versions: 2.10.0, 2.8.5, 2.9.2, 3.1.2, 3.1.3, 3.2.0, 3.2.1 > Vulnerable Library Version: org.apache.logging.log4j : log4j-core : 2.7 > CVE ID: > [CVE-2019-17571](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571), > [CVE-2017-5645](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645) > Import Path: examples/camel-example-google-pubsub/pom.xml, > examples/camel-example-kafka/pom.xml, examples/camel-example-debezium/pom.xml > Suggested Safe Versions: 2.10.0, 2.11.0, 2.11.1, 2.11.2, 2.12.0, 2.12.1, > 2.13.0, 2.8.2, 2.9.0, 2.9.1 > Vulnerable Library Version: org.asynchttpclient : async-http-client : 2.0.16 > CVE ID: > [CVE-2017-14063](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14063) > Import Path: components/camel-websocket/pom.xml > Suggested Safe Versions: 2.0.35, 2.0.36, 2.0.37, 2.0.38, 2.0.39, 2.0.40, > 2.1.0, 2.1.0-RC1, 2.1.0-RC2, 2.1.0-RC3, 2.1.0-RC4,
[jira] [Work logged] (CAMEL-14791) convert broken link: to checkable xref in camel-2.x
[ https://issues.apache.org/jira/browse/CAMEL-14791?focusedWorklogId=409746=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409746 ] ASF GitHub Bot logged work on CAMEL-14791: -- Author: ASF GitHub Bot Created on: 25/Mar/20 19:17 Start Date: 25/Mar/20 19:17 Worklog Time Spent: 10m Work Description: djencks commented on pull request #3680: Resolves CAMEL-14791: fix broken link: and <<>> constructs URL: https://github.com/apache/camel/pull/3680 I don't see any errors related to this running yarn checks locally. There are a lot of broken link errors due to trying to check the edit urls. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 409746) Remaining Estimate: 0h Time Spent: 10m > convert broken link: to checkable xref in camel-2.x > --- > > Key: CAMEL-14791 > URL: https://issues.apache.org/jira/browse/CAMEL-14791 > Project: Camel > Issue Type: Sub-task > Components: website >Affects Versions: 3.1.0 >Reporter: David Jencks >Assignee: David Jencks >Priority: Major > Fix For: 3.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Broken link: are not detected by the xref-checker. > There may be missing id problems also. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14783) website playbook update
[ https://issues.apache.org/jira/browse/CAMEL-14783?focusedWorklogId=409744=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409744 ] ASF GitHub Bot logged work on CAMEL-14783: -- Author: ASF GitHub Bot Created on: 25/Mar/20 19:15 Start Date: 25/Mar/20 19:15 Worklog Time Spent: 10m Work Description: djencks commented on pull request #269: Resolves CAMEL-14783: task of CAMEL-14782: add new start_paths to playbook URL: https://github.com/apache/camel-website/pull/269 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 409744) Time Spent: 0.5h (was: 20m) > website playbook update > --- > > Key: CAMEL-14783 > URL: https://issues.apache.org/jira/browse/CAMEL-14783 > Project: Camel > Issue Type: Sub-task > Components: website >Affects Versions: 3.1.0 >Reporter: David Jencks >Assignee: David Jencks >Priority: Major > Fix For: 3.2.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > add new source locations to production playbook -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-13564) Split exception/error handling model from runtime
[ https://issues.apache.org/jira/browse/CAMEL-13564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066987#comment-17066987 ] Claus Ibsen commented on CAMEL-13564: - gnodet is this not done with your recent work? > Split exception/error handling model from runtime > - > > Key: CAMEL-13564 > URL: https://issues.apache.org/jira/browse/CAMEL-13564 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.x > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14788) Unable to Start Jetty server in OSGi environment
[
https://issues.apache.org/jira/browse/CAMEL-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-14788.
-
Assignee: Claus Ibsen
Resolution: Fixed
> Unable to Start Jetty server in OSGi environment
>
>
> Key: CAMEL-14788
> URL: https://issues.apache.org/jira/browse/CAMEL-14788
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.24.3
>Reporter: Pedro Catalão
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.25.1, 3.2.0
>
>
> When deploying a spring XML via Karaf containing the Jetty component such as:
> {code:java}
>
> http://0.0.0.0:9000/test"/>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
> {code}
>
> Got this exception:
> {code:java}
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
> java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliance at
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
> java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
> org.eclipse.jetty.server [251] {code}
>
> While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses
> Jetty *{color:#172b4d}9.4.12.v20180830{color}* which is affected by this
> issue: [https://github.com/eclipse/jetty.project/issues/4350]
>
> This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling
> back the explicit exclusion of
> {color:#ff}MultiPartInputStreamParser{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14788) Unable to Start Jetty server in OSGi environment
[
https://issues.apache.org/jira/browse/CAMEL-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066975#comment-17066975
]
Claus Ibsen commented on CAMEL-14788:
-
Add OSGi workaround for older versions of Jetty
> Unable to Start Jetty server in OSGi environment
>
>
> Key: CAMEL-14788
> URL: https://issues.apache.org/jira/browse/CAMEL-14788
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.24.3
>Reporter: Pedro Catalão
>Priority: Major
> Fix For: 2.25.1, 3.2.0
>
>
> When deploying a spring XML via Karaf containing the Jetty component such as:
> {code:java}
>
> http://0.0.0.0:9000/test"/>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
> {code}
>
> Got this exception:
> {code:java}
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
> java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliance at
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
> java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
> org.eclipse.jetty.server [251] {code}
>
> While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses
> Jetty *{color:#172b4d}9.4.12.v20180830{color}* which is affected by this
> issue: [https://github.com/eclipse/jetty.project/issues/4350]
>
> This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling
> back the explicit exclusion of
> {color:#ff}MultiPartInputStreamParser{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14788) Unable to Start Jetty server in OSGi environment
[
https://issues.apache.org/jira/browse/CAMEL-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14788:
Fix Version/s: 3.2.0
2.25.1
> Unable to Start Jetty server in OSGi environment
>
>
> Key: CAMEL-14788
> URL: https://issues.apache.org/jira/browse/CAMEL-14788
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.24.3
>Reporter: Pedro Catalão
>Priority: Major
> Fix For: 2.25.1, 3.2.0
>
>
> When deploying a spring XML via Karaf containing the Jetty component such as:
> {code:java}
>
> http://0.0.0.0:9000/test"/>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
> {code}
>
> Got this exception:
> {code:java}
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
> java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliance at
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
> java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
> org.eclipse.jetty.server [251] {code}
>
> While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses
> Jetty *{color:#172b4d}9.4.12.v20180830{color}* which is affected by this
> issue: [https://github.com/eclipse/jetty.project/issues/4350]
>
> This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling
> back the explicit exclusion of
> {color:#ff}MultiPartInputStreamParser{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14788) Unable to Start Jetty server in OSGi environment
[
https://issues.apache.org/jira/browse/CAMEL-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066973#comment-17066973
]
Claus Ibsen commented on CAMEL-14788:
-
Not sure how we can hack this in older releases. Jetty is really bad, 9.4.22
and 9.4.27 is incompatible. There is a change in some error handler throws
exception that is not compilable :(
[ERROR]
/Users/davsclaus/workspace/camel/components/camel-jetty-common/src/main/java/org/apache/camel/component/jetty/JettyHttpComponent.java:[1233,28]
error: handle(String,Request,HttpServletRequest,HttpServletResponse) in
cannot
override handle(String,Request,HttpServletRequest,HttpServletResponse) in
ErrorHandler
[ERROR] overridden method does not throw ServletException
> Unable to Start Jetty server in OSGi environment
>
>
> Key: CAMEL-14788
> URL: https://issues.apache.org/jira/browse/CAMEL-14788
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.24.3
>Reporter: Pedro Catalão
>Priority: Major
>
> When deploying a spring XML via Karaf containing the Jetty component such as:
> {code:java}
>
> http://0.0.0.0:9000/test"/>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
> {code}
>
> Got this exception:
> {code:java}
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
> java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliance at
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
> java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
> org.eclipse.jetty.server [251] {code}
>
> While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses
> Jetty *{color:#172b4d}9.4.12.v20180830{color}* which is affected by this
> issue: [https://github.com/eclipse/jetty.project/issues/4350]
>
> This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling
> back the explicit exclusion of
> {color:#ff}MultiPartInputStreamParser{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14788) Unable to Start Jetty server in OSGi environment
[
https://issues.apache.org/jira/browse/CAMEL-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066957#comment-17066957
]
Claus Ibsen commented on CAMEL-14788:
-
When you run with Karaf then the Jetty server/version is provided by Karaf. So
you should upgrade it there.
> Unable to Start Jetty server in OSGi environment
>
>
> Key: CAMEL-14788
> URL: https://issues.apache.org/jira/browse/CAMEL-14788
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.24.3
>Reporter: Pedro Catalão
>Priority: Major
>
> When deploying a spring XML via Karaf containing the Jetty component such as:
> {code:java}
>
> http://0.0.0.0:9000/test"/>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
> {code}
>
> Got this exception:
> {code:java}
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
> java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliance at
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
> java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
> org.eclipse.jetty.server [251] {code}
>
> While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses
> Jetty *{color:#172b4d}9.4.12.v20180830{color}* which is affected by this
> issue: [https://github.com/eclipse/jetty.project/issues/4350]
>
> This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling
> back the explicit exclusion of
> {color:#ff}MultiPartInputStreamParser{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14780) camel-undertow: UndertowSecurityProvider SPI API misses a method to change HttpHandler
[ https://issues.apache.org/jira/browse/CAMEL-14780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14780. - Resolution: Fixed > camel-undertow: UndertowSecurityProvider SPI API misses a method to change > HttpHandler > -- > > Key: CAMEL-14780 > URL: https://issues.apache.org/jira/browse/CAMEL-14780 > Project: Camel > Issue Type: Bug > Components: camel-undertow >Affects Versions: 3.2.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > During refactor of camel-elytron to implement UndertowSecurityProvider I've > noticed that API does not allow to change of the HttpHandler during endpoint > registration. This "hook" for security provider is required for > camel-elytron. > (Change could be done without breaking back compatibility or compilation for > existing implementations.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14584) camel-elytron - Only use the JARs really needed
[ https://issues.apache.org/jira/browse/CAMEL-14584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066945#comment-17066945 ] Claus Ibsen commented on CAMEL-14584: - Jiri, with your recently work then I assume this wont use 100s of JARs anymore? > camel-elytron - Only use the JARs really needed > --- > > Key: CAMEL-14584 > URL: https://issues.apache.org/jira/browse/CAMEL-14584 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.2.0 > > > Its massive dependency set, and we only need a smaller set for camel-elytron > [INFO] +- org.wildfly.security:wildfly-elytron:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-asn1:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-audit:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth-server:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth-server-deprecated:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth-server-http:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth-server-sasl:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth-util:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-base:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-client:jar:1.11.2.Final:compile > [INFO] | | +- > org.wildfly.security:wildfly-elytron-credential-source-impl:jar:1.11.2.Final:compile > [INFO] | | \- > org.wildfly.security:wildfly-elytron-provider-util:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-credential:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-credential-source-deprecated:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-credential-store:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-digest:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-basic:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-bearer:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-cert:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-deprecated:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-digest:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-form:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-spnego:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-sso:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-util:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-jacc:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-jaspi:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-json-util:jar:1.11.2.Final:compile > [INFO] | +- org.wildfly.security:wildfly-elytron-jwt:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-keystore:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism-digest:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism-gssapi:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism-http:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism-oauth2:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism-scram:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-password-impl:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-permission:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-realm:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-realm-jdbc:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-realm-ldap:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-realm-token:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-sasl:jar:1.11.2.Final:compile > [INFO] | +- >
[jira] [Assigned] (CAMEL-14584) camel-elytron - Only use the JARs really needed
[ https://issues.apache.org/jira/browse/CAMEL-14584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-14584: --- Assignee: Jiri Ondrusek > camel-elytron - Only use the JARs really needed > --- > > Key: CAMEL-14584 > URL: https://issues.apache.org/jira/browse/CAMEL-14584 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.2.0 > > > Its massive dependency set, and we only need a smaller set for camel-elytron > [INFO] +- org.wildfly.security:wildfly-elytron:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-asn1:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-audit:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth-server:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth-server-deprecated:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth-server-http:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth-server-sasl:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-auth-util:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-base:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-client:jar:1.11.2.Final:compile > [INFO] | | +- > org.wildfly.security:wildfly-elytron-credential-source-impl:jar:1.11.2.Final:compile > [INFO] | | \- > org.wildfly.security:wildfly-elytron-provider-util:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-credential:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-credential-source-deprecated:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-credential-store:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-digest:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-basic:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-bearer:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-cert:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-deprecated:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-digest:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-form:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-spnego:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-sso:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-http-util:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-jacc:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-jaspi:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-json-util:jar:1.11.2.Final:compile > [INFO] | +- org.wildfly.security:wildfly-elytron-jwt:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-keystore:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism-digest:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism-gssapi:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism-http:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism-oauth2:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-mechanism-scram:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-password-impl:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-permission:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-realm:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-realm-jdbc:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-realm-ldap:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-realm-token:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-sasl:jar:1.11.2.Final:compile > [INFO] | +- > org.wildfly.security:wildfly-elytron-sasl-anonymous:jar:1.11.2.Final:compile > [INFO] | +- >
[jira] [Updated] (CAMEL-14792) ClassNotFoundException for onException(Class) in Java DSL in OSGi
[
https://issues.apache.org/jira/browse/CAMEL-14792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated CAMEL-14792:
-
Fix Version/s: (was: 3.1.1)
(was: 3.2.0)
> ClassNotFoundException for onException(Class) in Java DSL in OSGi
> -
>
> Key: CAMEL-14792
> URL: https://issues.apache.org/jira/browse/CAMEL-14792
> Project: Camel
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 2.25.1
>
>
> With CAMEL-13468, {{OnExceptionDefinition.java}} lost {{exceptionClasses}}
> field and actual exception classes where converted in Java DSL into String
> objects - resolved later when exception processor was created.
> This could (and actually did) cause problems in OSGi, when route was defined
> from different bundle (which had correct {{Import-Package}} headers generated
> by maven-bundle-plugin) than the bundle with actual route.
> I have a fix that both keeps class names (for marshalling purpose) and actual
> classes (for OSGi).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14789) camel-rabbitmq - Automatic recovery of temporary reply queue is not handled correctly
[
https://issues.apache.org/jira/browse/CAMEL-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14789:
Summary: camel-rabbitmq - Automatic recovery of temporary reply queue is
not handled correctly (was: Automatic recovery of temporary reply queue is not
handled correctly)
> camel-rabbitmq - Automatic recovery of temporary reply queue is not handled
> correctly
> -
>
> Key: CAMEL-14789
> URL: https://issues.apache.org/jira/browse/CAMEL-14789
> Project: Camel
> Issue Type: Bug
> Components: camel-rabbitmq
>Affects Versions: 2.25.0
> Environment: * RabbitMQ server 3.8.3
> * Erlang 22.3
>Reporter: Robert Szczesiak
>Priority: Major
> Fix For: 2.25.1
>
> Attachments:
> 0001-CAMEL-14789-FIX-Automatic-recovery-of-temporary-repl.patch
>
>
> When Remote Procedure Call (RPC) communication pattern is used RabbitMQ Camel
> component creates server-named auto-deleted temporary reply queue. Next, the
> queue is bound to the exchange with routing key equal to queue name.
> Likewise, ReplyManager's replyTo field is set with the value of the queue
> name. Reply queue created in this manner is then reused for subsequent RPC
> requests and message property rabbitmq.REPLY_TO is copied from the value
> stored previously by ReplyManager.
> When some network error suddenly appears causing connection failure,
> RabbitMQ's automatic recovery kicks in and tries to recover affected entities
> (assuming the connection was created with automatic recovery enabled, which
> is default.). As temporary quueues are auto-deleted, during recovery process
> a new temporary queue is created which has a new name that differs from the
> original one and here is where the problem begins.
> Creation of the new temporary queue is NOT detected by ReplyManager and
> therefore replyTo property is NOT updated. Also, routing key no longer
> matches queue name. This causes a problem when some implementations of
> RabbitMQ client, like. Spring AMQP, are used server-site. RPC service
> receives our request, processes it, and replies to default exchange with
> routing key equal to rabbitmq.REPLY_TO sent in our request. RPC service
> provider perceives no problem as response is sent successfully but RabbitMQ
> Camel Component keeps awaiting for the response to arrive to the original
> temporary queue which no longer exists due to connection failure and
> recovery. Eventually, Camel throws ExchangeTimedOutException.
> Example:
> # After automatic recovery, a RPC request is sent to example-exchange with
> rabitmq.REPLY_TO=amq.gen-0lLvpnj4ZMlkhxZIcCPVpA
> # After 20 seconds org.apache.camel.ExchangeTimedOutException is thrown:
> {code:java}
> The OUT message was not received within: 2 millis due reply message with
> correlationID: Camel-ID-hostname-1583401848872-0-1690397 not received on
> destination: amq.gen-0lLvpnj4ZMlkhxZIcCPVpA.
> Exchange[ID-hostname-1583401848872-0-1690391]{code}
> # Using RabbitMQ Management WebApp (rabbitmqctl) we check example-exchange's
> bindings and see that routing key amq.gen-0lLvpnj4ZMlkhxZIcCPVpA now
> corresponds to queue amq.gen-zaRCP-p-JbXeSzJmzSp83g
> *Proposed solution* is to add QueueRecoveryListener to notify when temporary
> queue name changes due to recovery. On event, replyTo field will be updated
> with the new temporary queue name and the queue will be rebound to the
> exchange so that routing key matches queue name again. The change will be
> made to org.apache.camel.component.rabbitmq.reply#createListenerContainer.
> Attached patch also contains integration test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-13934) camel-minio - Component to store/load files from blob store
[ https://issues.apache.org/jira/browse/CAMEL-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066913#comment-17066913 ] Nayananga Muhandiram commented on CAMEL-13934: -- Hello Mr Zoran, Thank you for your reply. I`ve submitted my GSoC 2020 proposal regarding this issue. Currently, I`m reading camel code and minIO docs to in order to the understand project scope thoroughly. Thank you > camel-minio - Component to store/load files from blob store > --- > > Key: CAMEL-13934 > URL: https://issues.apache.org/jira/browse/CAMEL-13934 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen >Priority: Major > Labels: gsoc2020 > > min.io is a s3 like blob store. So users have more freedom than being locked > into aws > We can create a camel-minio component for it > https://github.com/minio/minio-java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14792) ClassNotFoundException for onException(Class) in Java DSL in OSGi
[
https://issues.apache.org/jira/browse/CAMEL-14792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated CAMEL-14792:
-
Fix Version/s: (was: 3.0.2)
3.2.0
> ClassNotFoundException for onException(Class) in Java DSL in OSGi
> -
>
> Key: CAMEL-14792
> URL: https://issues.apache.org/jira/browse/CAMEL-14792
> Project: Camel
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 2.25.1, 3.2.0, 3.1.1
>
>
> With CAMEL-13468, {{OnExceptionDefinition.java}} lost {{exceptionClasses}}
> field and actual exception classes where converted in Java DSL into String
> objects - resolved later when exception processor was created.
> This could (and actually did) cause problems in OSGi, when route was defined
> from different bundle (which had correct {{Import-Package}} headers generated
> by maven-bundle-plugin) than the bundle with actual route.
> I have a fix that both keeps class names (for marshalling purpose) and actual
> classes (for OSGi).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14792) ClassNotFoundException for onException(Class) in Java DSL in OSGi
[
https://issues.apache.org/jira/browse/CAMEL-14792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated CAMEL-14792:
-
Fix Version/s: 3.1.1
2.25.1
3.0.2
> ClassNotFoundException for onException(Class) in Java DSL in OSGi
> -
>
> Key: CAMEL-14792
> URL: https://issues.apache.org/jira/browse/CAMEL-14792
> Project: Camel
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 3.0.2, 2.25.1, 3.1.1
>
>
> With CAMEL-13468, {{OnExceptionDefinition.java}} lost {{exceptionClasses}}
> field and actual exception classes where converted in Java DSL into String
> objects - resolved later when exception processor was created.
> This could (and actually did) cause problems in OSGi, when route was defined
> from different bundle (which had correct {{Import-Package}} headers generated
> by maven-bundle-plugin) than the bundle with actual route.
> I have a fix that both keeps class names (for marshalling purpose) and actual
> classes (for OSGi).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14792) ClassNotFoundException for onException(Class) in Java DSL in OSGi
[
https://issues.apache.org/jira/browse/CAMEL-14792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated CAMEL-14792:
-
Labels: (was: CAMEL-13468)
> ClassNotFoundException for onException(Class) in Java DSL in OSGi
> -
>
> Key: CAMEL-14792
> URL: https://issues.apache.org/jira/browse/CAMEL-14792
> Project: Camel
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> With CAMEL-13468, {{OnExceptionDefinition.java}} lost {{exceptionClasses}}
> field and actual exception classes where converted in Java DSL into String
> objects - resolved later when exception processor was created.
> This could (and actually did) cause problems in OSGi, when route was defined
> from different bundle (which had correct {{Import-Package}} headers generated
> by maven-bundle-plugin) than the bundle with actual route.
> I have a fix that both keeps class names (for marshalling purpose) and actual
> classes (for OSGi).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14792) ClassNotFoundException for onException(Class) in Java DSL in OSGi
Grzegorz Grzybek created CAMEL-14792:
Summary: ClassNotFoundException for onException(Class) in Java DSL
in OSGi
Key: CAMEL-14792
URL: https://issues.apache.org/jira/browse/CAMEL-14792
Project: Camel
Issue Type: Bug
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
With CAMEL-13468, {{OnExceptionDefinition.java}} lost {{exceptionClasses}}
field and actual exception classes where converted in Java DSL into String
objects - resolved later when exception processor was created.
This could (and actually did) cause problems in OSGi, when route was defined
from different bundle (which had correct {{Import-Package}} headers generated
by maven-bundle-plugin) than the bundle with actual route.
I have a fix that both keeps class names (for marshalling purpose) and actual
classes (for OSGi).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14791) convert broken link: to checkable xref in camel-2.x
David Jencks created CAMEL-14791: Summary: convert broken link: to checkable xref in camel-2.x Key: CAMEL-14791 URL: https://issues.apache.org/jira/browse/CAMEL-14791 Project: Camel Issue Type: Sub-task Components: website Affects Versions: 3.1.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.2.0 Broken link: are not detected by the xref-checker. There may be missing id problems also. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14781) Support page missing toolbar breadcrumbs
[ https://issues.apache.org/jira/browse/CAMEL-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066808#comment-17066808 ] Solange Iyubu commented on CAMEL-14781: --- I am working on this issue > Support page missing toolbar breadcrumbs > > > Key: CAMEL-14781 > URL: https://issues.apache.org/jira/browse/CAMEL-14781 > Project: Camel > Issue Type: Bug > Components: website >Reporter: Solange Iyubu >Priority: Major > > While navigating on apache website I saw pages that don't have toolbars > breadcrumps such as support page from community. I am going to work on it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14786) Move as much initialisation code from start() to init() phase
[
https://issues.apache.org/jira/browse/CAMEL-14786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved CAMEL-14786.
-
Resolution: Fixed
> Move as much initialisation code from start() to init() phase
> -
>
> Key: CAMEL-14786
> URL: https://issues.apache.org/jira/browse/CAMEL-14786
> Project: Camel
> Issue Type: Task
> Components: camel-core
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.2.0
>
>
> The work done currently in the {{init}} phase will be moved to the {{build}}
> phase.
> The {{start}} phase will be split between {{init}} for bean configuration /
> wiring, excluding any thread / network access and the {{start}} phase to
> actually start consuming and creating threads / sockets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-13530) Upgrade Milo to 0.3.8
[ https://issues.apache.org/jira/browse/CAMEL-13530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Volodin reassigned CAMEL-13530: -- Assignee: Dmitry Volodin > Upgrade Milo to 0.3.8 > - > > Key: CAMEL-13530 > URL: https://issues.apache.org/jira/browse/CAMEL-13530 > Project: Camel > Issue Type: Task > Components: camel-milo >Reporter: Andrea Cosentino >Assignee: Dmitry Volodin >Priority: Minor > Fix For: 3.2.0 > > > Some breaking changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14790) camel-undertow: remove spring-boot starter after refactor of elytron component
Jiri Ondrusek created CAMEL-14790: - Summary: camel-undertow: remove spring-boot starter after refactor of elytron component Key: CAMEL-14790 URL: https://issues.apache.org/jira/browse/CAMEL-14790 Project: Camel Issue Type: Task Components: camel-undertow Affects Versions: 3.2.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek Fix of https://issues.apache.org/jira/browse/CAMEL-14743 removes elytron-component (but functionality is kept as plugin into camel-undertow) If fix is approved, elytron starter has to be removed to prevent compilation problems -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14495) OPC UA Client samplingInterval parameter seems not take any effect
[
https://issues.apache.org/jira/browse/CAMEL-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Volodin resolved CAMEL-14495.
Resolution: Fixed
> OPC UA Client samplingInterval parameter seems not take any effect
> --
>
> Key: CAMEL-14495
> URL: https://issues.apache.org/jira/browse/CAMEL-14495
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
>Affects Versions: 2.25.0
>Reporter: Hobbert
>Assignee: Dmitry Volodin
>Priority: Minor
> Labels: help-wanted
> Fix For: 3.2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When I set the *samplingInterval* parameter on a Milo OPC UA Client route,
> the interval not changes on the real OPC application! Remains 1000 mili
> seconds even after configuring!! Can anyone confirm that??
> Heres my route
> http://camel.apache.org/schema/spring; >
>
> uri="milo-client:tcp://192.168.0.2:4840?samplingInterval=50=RAW(ns=4;i=12)"/>
>
> ${in.body}
>
>
>
> Thanks
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-14495) OPC UA Client samplingInterval parameter seems not take any effect
[
https://issues.apache.org/jira/browse/CAMEL-14495?focusedWorklogId=409550=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409550
]
ASF GitHub Bot logged work on CAMEL-14495:
--
Author: ASF GitHub Bot
Created on: 25/Mar/20 14:51
Start Date: 25/Mar/20 14:51
Worklog Time Spent: 10m
Work Description: asfgit commented on pull request #3678: CAMEL-14495:
OPC UA Client samplingInterval parameter seems not take any effect
URL: https://github.com/apache/camel/pull/3678
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 409550)
Time Spent: 20m (was: 10m)
> OPC UA Client samplingInterval parameter seems not take any effect
> --
>
> Key: CAMEL-14495
> URL: https://issues.apache.org/jira/browse/CAMEL-14495
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
>Affects Versions: 2.25.0
>Reporter: Hobbert
>Assignee: Dmitry Volodin
>Priority: Minor
> Labels: help-wanted
> Fix For: 3.2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When I set the *samplingInterval* parameter on a Milo OPC UA Client route,
> the interval not changes on the real OPC application! Remains 1000 mili
> seconds even after configuring!! Can anyone confirm that??
> Heres my route
> http://camel.apache.org/schema/spring; >
>
> uri="milo-client:tcp://192.168.0.2:4840?samplingInterval=50=RAW(ns=4;i=12)"/>
>
> ${in.body}
>
>
>
> Thanks
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-14743) camel-elytron: refactor component to use new SPI interface from camel-undertow
[ https://issues.apache.org/jira/browse/CAMEL-14743?focusedWorklogId=409549=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409549 ] ASF GitHub Bot logged work on CAMEL-14743: -- Author: ASF GitHub Bot Created on: 25/Mar/20 14:50 Start Date: 25/Mar/20 14:50 Worklog Time Spent: 10m Work Description: JiriOndrusek commented on pull request #3679: CAMEL-14743 camel-elytron: use UndertowSecurityProvider API URL: https://github.com/apache/camel/pull/3679 Issue: https://issues.apache.org/jira/browse/CAMEL-14743 Fix contains refactor of camel-elytron to use UndertowSecurityProvider (see https://issues.apache.org/jira/browse/CAMEL-14208) Changes introduces new ElytronSecurityProvider.java and removes elytron as a component (since now it is only plugin for camel-undertow) JUnit test covers basic token bearer scenario. I'm not sure about following changes: - I've removed ElytronComponent (and all generated files linked to it) - I've changed documentation to not contain component (and starter) parameters (I've changed 'since' attribute to 3.2 - I'm not sure whether it is 'the same' component as before or not) - location of files is still the same Following step is: - to remove of camel-elytron-starter (https://github.com/apache/camel-spring-boot/tree/master/components-starter/camel-elytron-starter) !!! It makes sense to remove starter first (to prevent compilation issues with dev profile). Once this PR is approved, I can remove starter (after creating a jira issue) and after removal of the starter, this PR could be merged. [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. [ ] Each commit in the pull request should have a meaningful subject line and body. [ ] If you're unsure, you can format the pull request title like `[CAMEL-XXX] Fixes bug in camel-file component`, where you replace `CAMEL-XXX` with the appropriate JIRA issue. [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. [ ] Run `mvn clean install -Psourcecheck` in your module with source check enabled to make sure basic checks pass and there are no checkstyle violations. A more thorough check will be performed on your pull request automatically. Below are the contribution guidelines: https://github.com/apache/camel/blob/master/CONTRIBUTING.md This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 409549) Remaining Estimate: 0h Time Spent: 10m > camel-elytron: refactor component to use new SPI interface from camel-undertow > -- > > Key: CAMEL-14743 > URL: https://issues.apache.org/jira/browse/CAMEL-14743 > Project: Camel > Issue Type: Task > Components: camel-undertow >Affects Versions: 3.2.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > As a part of the fix of https://issues.apache.org/jira/browse/CAMEL-14208 > there is a new SPI APi for security providers. Component camel-elytron should > be refactored to use that api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14715) Move karaf/osgi to separate git repository
[ https://issues.apache.org/jira/browse/CAMEL-14715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-14715: - Summary: Move karaf/osgi to separate git repository (was: Move karaf/osgi to separate git repositor) > Move karaf/osgi to separate git repository > -- > > Key: CAMEL-14715 > URL: https://issues.apache.org/jira/browse/CAMEL-14715 > Project: Camel > Issue Type: Improvement > Components: karaf, osgi >Reporter: Claus Ibsen >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.2.0 > > > See > https://camel.465427.n5.nabble.com/Moving-Karaf-OSGi-code-into-a-Camel-sub-project-td5859320.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14789) Automatic recovery of temporary reply queue is not handled correctly
[
https://issues.apache.org/jira/browse/CAMEL-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066701#comment-17066701
]
Andrea Cosentino commented on CAMEL-14789:
--
Can you please create a PR on Github? It's usually easier to review, also you
should do this against master and then we can backport on older branches.
> Automatic recovery of temporary reply queue is not handled correctly
>
>
> Key: CAMEL-14789
> URL: https://issues.apache.org/jira/browse/CAMEL-14789
> Project: Camel
> Issue Type: Bug
> Components: camel-rabbitmq
>Affects Versions: 2.25.0
> Environment: * RabbitMQ server 3.8.3
> * Erlang 22.3
>Reporter: Robert Szczesiak
>Priority: Major
> Fix For: 2.25.1
>
> Attachments:
> 0001-CAMEL-14789-FIX-Automatic-recovery-of-temporary-repl.patch
>
>
> When Remote Procedure Call (RPC) communication pattern is used RabbitMQ Camel
> component creates server-named auto-deleted temporary reply queue. Next, the
> queue is bound to the exchange with routing key equal to queue name.
> Likewise, ReplyManager's replyTo field is set with the value of the queue
> name. Reply queue created in this manner is then reused for subsequent RPC
> requests and message property rabbitmq.REPLY_TO is copied from the value
> stored previously by ReplyManager.
> When some network error suddenly appears causing connection failure,
> RabbitMQ's automatic recovery kicks in and tries to recover affected entities
> (assuming the connection was created with automatic recovery enabled, which
> is default.). As temporary quueues are auto-deleted, during recovery process
> a new temporary queue is created which has a new name that differs from the
> original one and here is where the problem begins.
> Creation of the new temporary queue is NOT detected by ReplyManager and
> therefore replyTo property is NOT updated. Also, routing key no longer
> matches queue name. This causes a problem when some implementations of
> RabbitMQ client, like. Spring AMQP, are used server-site. RPC service
> receives our request, processes it, and replies to default exchange with
> routing key equal to rabbitmq.REPLY_TO sent in our request. RPC service
> provider perceives no problem as response is sent successfully but RabbitMQ
> Camel Component keeps awaiting for the response to arrive to the original
> temporary queue which no longer exists due to connection failure and
> recovery. Eventually, Camel throws ExchangeTimedOutException.
> Example:
> # After automatic recovery, a RPC request is sent to example-exchange with
> rabitmq.REPLY_TO=amq.gen-0lLvpnj4ZMlkhxZIcCPVpA
> # After 20 seconds org.apache.camel.ExchangeTimedOutException is thrown:
> {code:java}
> The OUT message was not received within: 2 millis due reply message with
> correlationID: Camel-ID-hostname-1583401848872-0-1690397 not received on
> destination: amq.gen-0lLvpnj4ZMlkhxZIcCPVpA.
> Exchange[ID-hostname-1583401848872-0-1690391]{code}
> # Using RabbitMQ Management WebApp (rabbitmqctl) we check example-exchange's
> bindings and see that routing key amq.gen-0lLvpnj4ZMlkhxZIcCPVpA now
> corresponds to queue amq.gen-zaRCP-p-JbXeSzJmzSp83g
> *Proposed solution* is to add QueueRecoveryListener to notify when temporary
> queue name changes due to recovery. On event, replyTo field will be updated
> with the new temporary queue name and the queue will be rebound to the
> exchange so that routing key matches queue name again. The change will be
> made to org.apache.camel.component.rabbitmq.reply#createListenerContainer.
> Attached patch also contains integration test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14789) Automatic recovery of temporary reply queue is not handled correctly
[
https://issues.apache.org/jira/browse/CAMEL-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Szczesiak updated CAMEL-14789:
-
Description:
When Remote Procedure Call (RPC) communication pattern is used RabbitMQ Camel
component creates server-named auto-deleted temporary reply queue. Next, the
queue is bound to the exchange with routing key equal to queue name. Likewise,
ReplyManager's replyTo field is set with the value of the queue name. Reply
queue created in this manner is then reused for subsequent RPC requests and
message property rabbitmq.REPLY_TO is copied from the value stored previously
by ReplyManager.
When some network error suddenly appears causing connection failure, RabbitMQ's
automatic recovery kicks in and tries to recover affected entities (assuming
the connection was created with automatic recovery enabled, which is default.).
As temporary quueues are auto-deleted, during recovery process a new temporary
queue is created which has a new name that differs from the original one and
here is where the problem begins.
Creation of the new temporary queue is NOT detected by ReplyManager and
therefore replyTo property is NOT updated. Also, routing key no longer matches
queue name. This causes a problem when some implementations of RabbitMQ client,
like. Spring AMQP, are used server-site. RPC service receives our request,
processes it, and replies to default exchange with routing key equal to
rabbitmq.REPLY_TO sent in our request. RPC service provider perceives no
problem as response is sent successfully but RabbitMQ Camel Component keeps
awaiting for the response to arrive to the original temporary queue which no
longer exists due to connection failure and recovery. Eventually, Camel throws
ExchangeTimedOutException.
Example:
# After automatic recovery, a RPC request is sent to example-exchange with
rabitmq.REPLY_TO=amq.gen-0lLvpnj4ZMlkhxZIcCPVpA
# After 20 seconds org.apache.camel.ExchangeTimedOutException is thrown:
{code:java}
The OUT message was not received within: 2 millis due reply message with
correlationID: Camel-ID-hostname-1583401848872-0-1690397 not received on
destination: amq.gen-0lLvpnj4ZMlkhxZIcCPVpA.
Exchange[ID-hostname-1583401848872-0-1690391]{code}
# Using RabbitMQ Management WebApp (rabbitmqctl) we check example-exchange's
bindings and see that routing key amq.gen-0lLvpnj4ZMlkhxZIcCPVpA now
corresponds to queue amq.gen-zaRCP-p-JbXeSzJmzSp83g
*Proposed solution* is to add QueueRecoveryListener to notify when temporary
queue name changes due to recovery. On event, replyTo field will be updated
with the new temporary queue name and the queue will be rebound to the exchange
so that routing key matches queue name again. The change will be made to
org.apache.camel.component.rabbitmq.reply#createListenerContainer.
Attached patch also contains integration test.
was:
When Remote Procedure Call (RPC) communication pattern is used RabbitMQ Camel
component creates server-named auto-deleted temporary reply queue. Next, the
queue is bound to the exchange with routing key equal to queue name. Likewise,
ReplyManager's replyTo field is set with the value of the queue name. Reply
queue created in this manner is then reused for subsequent RPC requests and
message property rabbitmq.REPLY_TO is copied from the value stored previously
by ReplyManager.
When some network error suddenly appears causing connection failure, RabbitMQ's
automatic recovery kicks in and tries to recover affected entities (assuming
the connection was created with automatic recovery enabled, which is default.).
As temporary quueues are auto-deleted, during recovery process a new temporary
queue is created which has a new name that differs from the original one and
here is where the problem begins.
Creation of the new temporary queue is NOT detected by ReplyManager and
therefore replyTo property is NOT updated. Also, routing key no longer matches
queue name. This causes a problem when some implementations of RabbitMQ client,
like. Spring AMQP, are used server-site. RPC service receives our request,
processes it, and replies to default exchange with routing key equal to
rabbitmq.REPLY_TO sent in our request. RPC service provider perceives no
problem as response is sent successfully but RabbitMQ Camel Component keeps
awaiting for the response to arrive to the original temporary queue which no
longer exists due to connection failure and recovery. Eventually, Camel throws
ExchangeTimedOutException.
Example:
# After automatic recovery, a RPC request is sent to example-exchange with
rabitmq.REPLY_TO=amq.gen-0lLvpnj4ZMlkhxZIcCPVpA
# After 20 seconds org.apache.camel.ExchangeTimedOutException is thrown:
{code:java}
The OUT message was not received within: 2 millis due reply message with
correlationID:
Camel-ID-hostname-y579vjqenbwmcd1bpqmd5phtd-1583401848872-0-1690397 not
[jira] [Work logged] (CAMEL-14495) OPC UA Client samplingInterval parameter seems not take any effect
[
https://issues.apache.org/jira/browse/CAMEL-14495?focusedWorklogId=409509=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409509
]
ASF GitHub Bot logged work on CAMEL-14495:
--
Author: ASF GitHub Bot
Created on: 25/Mar/20 13:40
Start Date: 25/Mar/20 13:40
Worklog Time Spent: 10m
Work Description: dmvolod commented on pull request #3678: CAMEL-14495:
OPC UA Client samplingInterval parameter seems not take any effect
URL: https://github.com/apache/camel/pull/3678
[ ] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change
(usually before you start working on it). Trivial changes like typos do not
require a JIRA issue. Your pull request should address just this issue,
without pulling in other changes.
[ ] Each commit in the pull request should have a meaningful subject line
and body.
[ ] If you're unsure, you can format the pull request title like
`[CAMEL-XXX] Fixes bug in camel-file component`, where you replace `CAMEL-XXX`
with the appropriate JIRA issue.
[ ] Write a pull request description that is detailed enough to understand
what the pull request does, how, and why.
[ ] Run `mvn clean install -Psourcecheck` in your module with source check
enabled to make sure basic checks pass and there are no checkstyle violations.
A more thorough check will be performed on your pull request automatically.
Below are the contribution guidelines:
https://github.com/apache/camel/blob/master/CONTRIBUTING.md
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 409509)
Remaining Estimate: 0h
Time Spent: 10m
> OPC UA Client samplingInterval parameter seems not take any effect
> --
>
> Key: CAMEL-14495
> URL: https://issues.apache.org/jira/browse/CAMEL-14495
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
>Affects Versions: 2.25.0
>Reporter: Hobbert
>Assignee: Dmitry Volodin
>Priority: Minor
> Labels: help-wanted
> Fix For: 3.2.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I set the *samplingInterval* parameter on a Milo OPC UA Client route,
> the interval not changes on the real OPC application! Remains 1000 mili
> seconds even after configuring!! Can anyone confirm that??
> Heres my route
> http://camel.apache.org/schema/spring; >
>
> uri="milo-client:tcp://192.168.0.2:4840?samplingInterval=50=RAW(ns=4;i=12)"/>
>
> ${in.body}
>
>
>
> Thanks
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14744) camel-salesforce : lazy-login
[ https://issues.apache.org/jira/browse/CAMEL-14744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066676#comment-17066676 ] Maarten Tutak commented on CAMEL-14744: --- [~zregvart], sure, I can give it a try. > camel-salesforce : lazy-login > - > > Key: CAMEL-14744 > URL: https://issues.apache.org/jira/browse/CAMEL-14744 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.1.0 >Reporter: Maarten Tutak >Priority: Minor > > I'm using org.apache.camel.springboot:camel-salesforce-starter:3.1.0 > Configuration *camel.component.salesforce.lazy-login* only seems to work when > it's used in combination with > *camel.component.salesforce.lazy-start-producer*. > When used on it's own, method > > *_org.apache.camel.component.salesforce.internal.client.AbstractClientBase#start()_* > will call method > _*org.apache.camel.component.salesforce.internal.SalesforceSession#login()*_ > without an appropriate guard statement. > Is this intended behaviour? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14780) camel-undertow: UndertowSecurityProvider SPI API misses a method to change HttpHandler
[ https://issues.apache.org/jira/browse/CAMEL-14780?focusedWorklogId=409488=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409488 ] ASF GitHub Bot logged work on CAMEL-14780: -- Author: ASF GitHub Bot Created on: 25/Mar/20 13:12 Start Date: 25/Mar/20 13:12 Worklog Time Spent: 10m Work Description: davsclaus commented on pull request #3677: CAMEL-14780 camel-undertow: Enhance SPI API for HttpHandler change URL: https://github.com/apache/camel/pull/3677 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 409488) Time Spent: 20m (was: 10m) > camel-undertow: UndertowSecurityProvider SPI API misses a method to change > HttpHandler > -- > > Key: CAMEL-14780 > URL: https://issues.apache.org/jira/browse/CAMEL-14780 > Project: Camel > Issue Type: Bug > Components: camel-undertow >Affects Versions: 3.2.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > During refactor of camel-elytron to implement UndertowSecurityProvider I've > noticed that API does not allow to change of the HttpHandler during endpoint > registration. This "hook" for security provider is required for > camel-elytron. > (Change could be done without breaking back compatibility or compilation for > existing implementations.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14789) Automatic recovery of temporary reply queue is not handled correctly
[
https://issues.apache.org/jira/browse/CAMEL-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Szczesiak updated CAMEL-14789:
-
Description:
When Remote Procedure Call (RPC) communication pattern is used RabbitMQ Camel
component creates server-named auto-deleted temporary reply queue. Next, the
queue is bound to the exchange with routing key equal to queue name. Likewise,
ReplyManager's replyTo field is set with the value of the queue name. Reply
queue created in this manner is then reused for subsequent RPC requests and
message property rabbitmq.REPLY_TO is copied from the value stored previously
by ReplyManager.
When some network error suddenly appears causing connection failure, RabbitMQ's
automatic recovery kicks in and tries to recover affected entities (assuming
the connection was created with automatic recovery enabled, which is default.).
As temporary quueues are auto-deleted, during recovery process a new temporary
queue is created which has a new name that differs from the original one and
here is where the problem begins.
Creation of the new temporary queue is NOT detected by ReplyManager and
therefore replyTo property is NOT updated. Also, routing key no longer matches
queue name. This causes a problem when some implementations of RabbitMQ client,
like. Spring AMQP, are used server-site. RPC service receives our request,
processes it, and replies to default exchange with routing key equal to
rabbitmq.REPLY_TO sent in our request. RPC service provider perceives no
problem as response is sent successfully but RabbitMQ Camel Component keeps
awaiting for the response to arrive to the original temporary queue which no
longer exists due to connection failure and recovery. Eventually, Camel throws
ExchangeTimedOutException.
Example:
# After automatic recovery, a RPC request is sent to example-exchange with
rabitmq.REPLY_TO=amq.gen-0lLvpnj4ZMlkhxZIcCPVpA
# After 20 seconds org.apache.camel.ExchangeTimedOutException is thrown:
{code:java}
The OUT message was not received within: 2 millis due reply message with
correlationID:
Camel-ID-hostname-y579vjqenbwmcd1bpqmd5phtd-1583401848872-0-1690397 not
received on destination: amq.gen-0lLvpnj4ZMlkhxZIcCPVpA.
Exchange[ID-hostname-y579vjqenbwmcd1bpqmd5phtd-1583401848872-0-1690391]{code}
# Using RabbitMQ Management WebApp (rabbitmqctl) we check example-exchange's
bindings and see that routing key amq.gen-0lLvpnj4ZMlkhxZIcCPVpA now
corresponds to queue amq.gen-zaRCP-p-JbXeSzJmzSp83g
*Proposed solution* is to add QueueRecoveryListener to notify when temporary
queue name changes due to recovery. On event, replyTo field will be updated
with the new temporary queue name and the queue will be rebound to the exchange
so that routing key matches queue name again. The change will be made to
org.apache.camel.component.rabbitmq.reply#createListenerContainer.
Attached patch also contains integration test.
was:
When Remote Procedure Call (RPC) communication pattern is used RabbitMQ Camel
component creates server-named auto-deleted temporary reply queue. Next, the
queue is bound to the exchange with routing key equal to queue name. Likewise,
ReplyManager's replyTo field is set with the value of the queue name. Reply
queue created in this manner is then reused for subsequent RPC requests and
message property rabbitmq.REPLY_TO is copied from the value stored previously
by ReplyManager.
When some network error suddenly appears causing connection failure, RabbitMQ's
automatic recovery kicks in and tries to recover affected entities (assuming
the connection was created with automatic recovery enabled, which is default.).
As temporary quueues are auto-deleted, during recovery process a new temporary
queue is created which has a new name that differs from the original one and
here is where the problem begins.
Creation of the new temporary queue is NOT detected by ReplyManager and
therefore replyTo property is NOT updated. Also, routing key no longer matches
queue name. This causes a problem when some implementations of RabbitMQ client,
like. Spring AMQP, are used server-site. RPC service receives our request,
processes it, and replies to default exchange with routing key equal to
rabbitmq.REPLY_TO sent in our request. RPC service provider perceives no
problem as response is sent successfully but RabbitMQ Camel Component keeps
awaiting for the response to arrive to the original temporary queue which no
longer exists due to connection failure and recovery. Eventually, Camel throws
ExchangeTimedOutException.
Example:
# After automatic recovery, a RPC request is sent to example-exchange with
rabitmq.REPLY_TO=amq.gen-0lLvpnj4ZMlkhxZIcCPVpA
# After 20 seconds org.apache.camel.ExchangeTimedOutException is thrown:
{code:java}
The OUT message was not received within: 2 millis due reply message with
correlationID:
[jira] [Updated] (CAMEL-14789) Automatic recovery of temporary reply queue is not handled correctly
[
https://issues.apache.org/jira/browse/CAMEL-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Szczesiak updated CAMEL-14789:
-
Patch Info: Patch Available
> Automatic recovery of temporary reply queue is not handled correctly
>
>
> Key: CAMEL-14789
> URL: https://issues.apache.org/jira/browse/CAMEL-14789
> Project: Camel
> Issue Type: Bug
> Components: camel-rabbitmq
>Affects Versions: 2.25.0
> Environment: * RabbitMQ server 3.8.3
> * Erlang 22.3
>Reporter: Robert Szczesiak
>Priority: Major
> Fix For: 2.25.1
>
> Attachments:
> 0001-CAMEL-14789-FIX-Automatic-recovery-of-temporary-repl.patch
>
>
> When Remote Procedure Call (RPC) communication pattern is used RabbitMQ Camel
> component creates server-named auto-deleted temporary reply queue. Next, the
> queue is bound to the exchange with routing key equal to queue name.
> Likewise, ReplyManager's replyTo field is set with the value of the queue
> name. Reply queue created in this manner is then reused for subsequent RPC
> requests and message property rabbitmq.REPLY_TO is copied from the value
> stored previously by ReplyManager.
> When some network error suddenly appears causing connection failure,
> RabbitMQ's automatic recovery kicks in and tries to recover affected entities
> (assuming the connection was created with automatic recovery enabled, which
> is default.). As temporary quueues are auto-deleted, during recovery process
> a new temporary queue is created which has a new name that differs from the
> original one and here is where the problem begins.
> Creation of the new temporary queue is NOT detected by ReplyManager and
> therefore replyTo property is NOT updated. Also, routing key no longer
> matches queue name. This causes a problem when some implementations of
> RabbitMQ client, like. Spring AMQP, are used server-site. RPC service
> receives our request, processes it, and replies to default exchange with
> routing key equal to rabbitmq.REPLY_TO sent in our request. RPC service
> provider perceives no problem as response is sent successfully but RabbitMQ
> Camel Component keeps awaiting for the response to arrive to the original
> temporary queue which no longer exists due to connection failure and
> recovery. Eventually, Camel throws ExchangeTimedOutException.
> Example:
> # After automatic recovery, a RPC request is sent to example-exchange with
> rabitmq.REPLY_TO=amq.gen-0lLvpnj4ZMlkhxZIcCPVpA
> # After 20 seconds org.apache.camel.ExchangeTimedOutException is thrown:
> {code:java}
> The OUT message was not received within: 2 millis due reply message with
> correlationID:
> Camel-ID-hostname-y579vjqenbwmcd1bpqmd5phtd-1583401848872-0-1690397 not
> received on destination: amq.gen-0lLvpnj4ZMlkhxZIcCPVpA.
> Exchange[ID-hostname-y579vjqenbwmcd1bpqmd5phtd-1583401848872-0-1690391]{code}
> # Using RabbitMQ Management WebApp (rabbitmqctl) we check example-exchange's
> bindings and see that routing key amq.gen-0lLvpnj4ZMlkhxZIcCPVpA now
> corresponds to queue amq.gen-zaRCP-p-JbXeSzJmzSp83g
> *Proposed solution* is to add QueueRecoveryListener to notify when temporary
> queue name changes due to recovery. On event, replyTo field will be updated
> with the new temporary queue name and the queue will be rebound to the
> exchange so that routing key matches queue name again. The change will be
> made to org.apache.camel.component.rabbitmq.reply#createListenerContainer.
> The fix is ready to be delivered in pull-request/patch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14789) Automatic recovery of temporary reply queue is not handled correctly
[
https://issues.apache.org/jira/browse/CAMEL-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Szczesiak updated CAMEL-14789:
-
Attachment: 0001-CAMEL-14789-FIX-Automatic-recovery-of-temporary-repl.patch
> Automatic recovery of temporary reply queue is not handled correctly
>
>
> Key: CAMEL-14789
> URL: https://issues.apache.org/jira/browse/CAMEL-14789
> Project: Camel
> Issue Type: Bug
> Components: camel-rabbitmq
>Affects Versions: 2.25.0
> Environment: * RabbitMQ server 3.8.3
> * Erlang 22.3
>Reporter: Robert Szczesiak
>Priority: Major
> Fix For: 2.25.1
>
> Attachments:
> 0001-CAMEL-14789-FIX-Automatic-recovery-of-temporary-repl.patch
>
>
> When Remote Procedure Call (RPC) communication pattern is used RabbitMQ Camel
> component creates server-named auto-deleted temporary reply queue. Next, the
> queue is bound to the exchange with routing key equal to queue name.
> Likewise, ReplyManager's replyTo field is set with the value of the queue
> name. Reply queue created in this manner is then reused for subsequent RPC
> requests and message property rabbitmq.REPLY_TO is copied from the value
> stored previously by ReplyManager.
> When some network error suddenly appears causing connection failure,
> RabbitMQ's automatic recovery kicks in and tries to recover affected entities
> (assuming the connection was created with automatic recovery enabled, which
> is default.). As temporary quueues are auto-deleted, during recovery process
> a new temporary queue is created which has a new name that differs from the
> original one and here is where the problem begins.
> Creation of the new temporary queue is NOT detected by ReplyManager and
> therefore replyTo property is NOT updated. Also, routing key no longer
> matches queue name. This causes a problem when some implementations of
> RabbitMQ client, like. Spring AMQP, are used server-site. RPC service
> receives our request, processes it, and replies to default exchange with
> routing key equal to rabbitmq.REPLY_TO sent in our request. RPC service
> provider perceives no problem as response is sent successfully but RabbitMQ
> Camel Component keeps awaiting for the response to arrive to the original
> temporary queue which no longer exists due to connection failure and
> recovery. Eventually, Camel throws ExchangeTimedOutException.
> Example:
> # After automatic recovery, a RPC request is sent to example-exchange with
> rabitmq.REPLY_TO=amq.gen-0lLvpnj4ZMlkhxZIcCPVpA
> # After 20 seconds org.apache.camel.ExchangeTimedOutException is thrown:
> {code:java}
> The OUT message was not received within: 2 millis due reply message with
> correlationID:
> Camel-ID-hostname-y579vjqenbwmcd1bpqmd5phtd-1583401848872-0-1690397 not
> received on destination: amq.gen-0lLvpnj4ZMlkhxZIcCPVpA.
> Exchange[ID-hostname-y579vjqenbwmcd1bpqmd5phtd-1583401848872-0-1690391]{code}
> # Using RabbitMQ Management WebApp (rabbitmqctl) we check example-exchange's
> bindings and see that routing key amq.gen-0lLvpnj4ZMlkhxZIcCPVpA now
> corresponds to queue amq.gen-zaRCP-p-JbXeSzJmzSp83g
> *Proposed solution* is to add QueueRecoveryListener to notify when temporary
> queue name changes due to recovery. On event, replyTo field will be updated
> with the new temporary queue name and the queue will be rebound to the
> exchange so that routing key matches queue name again. The change will be
> made to org.apache.camel.component.rabbitmq.reply#createListenerContainer.
> The fix is ready to be delivered in pull-request/patch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14789) Automatic recovery of temporary reply queue is not handled correctly
Robert Szczesiak created CAMEL-14789:
Summary: Automatic recovery of temporary reply queue is not
handled correctly
Key: CAMEL-14789
URL: https://issues.apache.org/jira/browse/CAMEL-14789
Project: Camel
Issue Type: Bug
Components: camel-rabbitmq
Affects Versions: 2.25.0
Environment: * RabbitMQ server 3.8.3
* Erlang 22.3
Reporter: Robert Szczesiak
Fix For: 2.25.1
When Remote Procedure Call (RPC) communication pattern is used RabbitMQ Camel
component creates server-named auto-deleted temporary reply queue. Next, the
queue is bound to the exchange with routing key equal to queue name. Likewise,
ReplyManager's replyTo field is set with the value of the queue name. Reply
queue created in this manner is then reused for subsequent RPC requests and
message property rabbitmq.REPLY_TO is copied from the value stored previously
by ReplyManager.
When some network error suddenly appears causing connection failure, RabbitMQ's
automatic recovery kicks in and tries to recover affected entities (assuming
the connection was created with automatic recovery enabled, which is default.).
As temporary quueues are auto-deleted, during recovery process a new temporary
queue is created which has a new name that differs from the original one and
here is where the problem begins.
Creation of the new temporary queue is NOT detected by ReplyManager and
therefore replyTo property is NOT updated. Also, routing key no longer matches
queue name. This causes a problem when some implementations of RabbitMQ client,
like. Spring AMQP, are used server-site. RPC service receives our request,
processes it, and replies to default exchange with routing key equal to
rabbitmq.REPLY_TO sent in our request. RPC service provider perceives no
problem as response is sent successfully but RabbitMQ Camel Component keeps
awaiting for the response to arrive to the original temporary queue which no
longer exists due to connection failure and recovery. Eventually, Camel throws
ExchangeTimedOutException.
Example:
# After automatic recovery, a RPC request is sent to example-exchange with
rabitmq.REPLY_TO=amq.gen-0lLvpnj4ZMlkhxZIcCPVpA
# After 20 seconds org.apache.camel.ExchangeTimedOutException is thrown:
{code:java}
The OUT message was not received within: 2 millis due reply message with
correlationID:
Camel-ID-hostname-y579vjqenbwmcd1bpqmd5phtd-1583401848872-0-1690397 not
received on destination: amq.gen-0lLvpnj4ZMlkhxZIcCPVpA.
Exchange[ID-hostname-y579vjqenbwmcd1bpqmd5phtd-1583401848872-0-1690391]{code}
# Using RabbitMQ Management WebApp (rabbitmqctl) we check example-exchange's
bindings and see that routing key amq.gen-0lLvpnj4ZMlkhxZIcCPVpA now
corresponds to queue amq.gen-zaRCP-p-JbXeSzJmzSp83g
*Proposed solution* is to add QueueRecoveryListener to notify when temporary
queue name changes due to recovery. On event, replyTo field will be updated
with the new temporary queue name and the queue will be rebound to the exchange
so that routing key matches queue name again. The change will be made to
org.apache.camel.component.rabbitmq.reply#createListenerContainer.
The fix is ready to be delivered in pull-request/patch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14788) Unable to Start Jetty server in OSGi environment
[
https://issues.apache.org/jira/browse/CAMEL-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pedro Catalão updated CAMEL-14788:
--
Environment: (was: {noformat}
*no* further _formatting_ is done here{noformat})
> Unable to Start Jetty server in OSGi environment
>
>
> Key: CAMEL-14788
> URL: https://issues.apache.org/jira/browse/CAMEL-14788
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.24.3
>Reporter: Pedro Catalão
>Priority: Major
>
> When deploying a spring XML via Karaf containing the Jetty component such as:
> {code:java}
>
> http://0.0.0.0:9000/test"/>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
> {code}
>
> Got this exception:
> {code:java}
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
> java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliance at
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
> java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
> org.eclipse.jetty.server [251] {code}
>
> While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses
> Jetty *{color:#172b4d}9.4.12.v20180830{color}* which is affected by this
> issue: [https://github.com/eclipse/jetty.project/issues/4350]
>
> This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling
> back the explicit exclusion of
> {color:#FF}MultiPartInputStreamParser{color}
> {{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14788) Unable to Start Jetty server in OSGi environment
[
https://issues.apache.org/jira/browse/CAMEL-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pedro Catalão updated CAMEL-14788:
--
Description:
When deploying a spring XML via Karaf containing the Jetty component such as:
{code:java}
http://0.0.0.0:9000/test"/>
{code}
Got this exception:
{code:java}
java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
java.lang.NoClassDefFoundError:
org/eclipse/jetty/server/MultiPartFormDataCompliance at
java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
java.lang.ClassNotFoundException:
org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
org.eclipse.jetty.server [251] {code}
While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses Jetty
*{color:#172b4d}9.4.12.v20180830{color}* which is affected by this issue:
[https://github.com/eclipse/jetty.project/issues/4350]
This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling back
the explicit exclusion of {color:#ff}MultiPartInputStreamParser{color}
was:
When deploying a spring XML via Karaf containing the Jetty component such as:
{code:java}
http://0.0.0.0:9000/test"/>
{code}
Got this exception:
{code:java}
java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
java.lang.NoClassDefFoundError:
org/eclipse/jetty/server/MultiPartFormDataCompliance at
java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
java.lang.ClassNotFoundException:
org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
org.eclipse.jetty.server [251] {code}
While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses Jetty
*{color:#172b4d}9.4.12.v20180830{color}* which is affected by this issue:
[https://github.com/eclipse/jetty.project/issues/4350]
This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling back
the explicit exclusion of {color:#FF}MultiPartInputStreamParser{color}
{{}}
> Unable to Start Jetty server in OSGi environment
>
>
> Key: CAMEL-14788
> URL: https://issues.apache.org/jira/browse/CAMEL-14788
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.24.3
>Reporter: Pedro Catalão
>Priority: Major
>
> When deploying a spring XML via Karaf containing the Jetty component such as:
> {code:java}
>
> http://0.0.0.0:9000/test"/>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
>
> uri="activemq:ID_5e5520ab59931d2df203_test_9de65790-5809-11ea-aafe-874a8d3d85de"/>
>
> {code}
>
> Got this exception:
> {code:java}
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
> java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiPartFormDataCompliance at
> java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
> java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
> org.eclipse.jetty.server [251] {code}
>
> While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses
> Jetty *{color:#172b4d}9.4.12.v20180830{color}* which is affected by this
> issue: [https://github.com/eclipse/jetty.project/issues/4350]
>
> This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling
> back the explicit exclusion of
> {color:#ff}MultiPartInputStreamParser{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14788) Unable to Start Jetty server in OSGi environment
Pedro Catalão created CAMEL-14788:
-
Summary: Unable to Start Jetty server in OSGi environment
Key: CAMEL-14788
URL: https://issues.apache.org/jira/browse/CAMEL-14788
Project: Camel
Issue Type: Bug
Components: camel-jetty
Affects Versions: 2.24.3
Environment: {noformat}
*no* further _formatting_ is done here{noformat}
Reporter: Pedro Catalão
When deploying a spring XML via Karaf containing the Jetty component such as:
{code:java}
http://0.0.0.0:9000/test"/>
{code}
Got this exception:
{code:java}
java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
org/eclipse/jetty/server/MultiPartFormDataCompliancejava.util.concurrent.ExecutionException:
java.lang.NoClassDefFoundError:
org/eclipse/jetty/server/MultiPartFormDataCompliance at
java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]Caused by:
java.lang.ClassNotFoundException:
org.eclipse.jetty.server.MultiPartFormDataCompliance not found by
org.eclipse.jetty.server [251] {code}
While investigating found that Camel *{color:#172b4d}2.24.3{color}* uses Jetty
*{color:#172b4d}9.4.12.v20180830{color}* which is affected by this issue:
[https://github.com/eclipse/jetty.project/issues/4350]
This has been fixed in Jetty >= *{color:#172b4d}9.4.25{color}* by rolling back
the explicit exclusion of {color:#FF}MultiPartInputStreamParser{color}
{{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14787) camel-zookeeper-master - Test fails on CI
[ https://issues.apache.org/jira/browse/CAMEL-14787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14787: Priority: Minor (was: Major) > camel-zookeeper-master - Test fails on CI > - > > Key: CAMEL-14787 > URL: https://issues.apache.org/jira/browse/CAMEL-14787 > Project: Camel > Issue Type: Task >Reporter: Claus Ibsen >Priority: Minor > Fix For: 3.2.0 > > > But they work locally on my osx > https://builds.apache.org/job/Camel/job/master/lastCompletedBuild/testReport/org.apache.camel.component.zookeepermaster.group/GroupTest/testOrder/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14787) camel-zookeeper-master - Test fails on CI
[ https://issues.apache.org/jira/browse/CAMEL-14787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066577#comment-17066577 ] Claus Ibsen commented on CAMEL-14787: - Pushed an attempted fix as its when cleaning up that CI cannot delete a log file. > camel-zookeeper-master - Test fails on CI > - > > Key: CAMEL-14787 > URL: https://issues.apache.org/jira/browse/CAMEL-14787 > Project: Camel > Issue Type: Task >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.2.0 > > > But they work locally on my osx > https://builds.apache.org/job/Camel/job/master/lastCompletedBuild/testReport/org.apache.camel.component.zookeepermaster.group/GroupTest/testOrder/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14780) camel-undertow: UndertowSecurityProvider SPI API misses a method to change HttpHandler
[ https://issues.apache.org/jira/browse/CAMEL-14780?focusedWorklogId=409417=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409417 ] ASF GitHub Bot logged work on CAMEL-14780: -- Author: ASF GitHub Bot Created on: 25/Mar/20 10:12 Start Date: 25/Mar/20 10:12 Worklog Time Spent: 10m Work Description: JiriOndrusek commented on pull request #3677: CAMEL-14780 camel-undertow: Enhance SPI API for HttpHandler change URL: https://github.com/apache/camel/pull/3677 Issue: https://issues.apache.org/jira/browse/CAMEL-14780 Change adds method co change httpHandler into SPI API. Extension of API is back compatible with previous version of API. Added JUnit test validating htppHandler 'hook' and test for usage of security parameters defined on component. [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. [ ] Each commit in the pull request should have a meaningful subject line and body. [ ] If you're unsure, you can format the pull request title like `[CAMEL-XXX] Fixes bug in camel-file component`, where you replace `CAMEL-XXX` with the appropriate JIRA issue. [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. [ ] Run `mvn clean install -Psourcecheck` in your module with source check enabled to make sure basic checks pass and there are no checkstyle violations. A more thorough check will be performed on your pull request automatically. Below are the contribution guidelines: https://github.com/apache/camel/blob/master/CONTRIBUTING.md This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 409417) Remaining Estimate: 0h Time Spent: 10m > camel-undertow: UndertowSecurityProvider SPI API misses a method to change > HttpHandler > -- > > Key: CAMEL-14780 > URL: https://issues.apache.org/jira/browse/CAMEL-14780 > Project: Camel > Issue Type: Bug > Components: camel-undertow >Affects Versions: 3.2.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > > During refactor of camel-elytron to implement UndertowSecurityProvider I've > noticed that API does not allow to change of the HttpHandler during endpoint > registration. This "hook" for security provider is required for > camel-elytron. > (Change could be done without breaking back compatibility or compilation for > existing implementations.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14787) camel-zookeeper-master - Test fails on CI
Claus Ibsen created CAMEL-14787: --- Summary: camel-zookeeper-master - Test fails on CI Key: CAMEL-14787 URL: https://issues.apache.org/jira/browse/CAMEL-14787 Project: Camel Issue Type: Task Reporter: Claus Ibsen Fix For: 3.2.0 But they work locally on my osx https://builds.apache.org/job/Camel/job/master/lastCompletedBuild/testReport/org.apache.camel.component.zookeepermaster.group/GroupTest/testOrder/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14739) RouteContext missing for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14739. - Resolution: Fixed Thanks for reporting, and the sample project. > RouteContext missing for RedeliveryErrorHandler > --- > > Key: CAMEL-14739 > URL: https://issues.apache.org/jira/browse/CAMEL-14739 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 3.1.0 >Reporter: Nathan >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.2.0, 3.1.1 > > Attachments: camel-error-test.zip > > > The RedeliveryErrorHandler needs the RouteContext to determine which > onException rule to use. > The RouteContext is set at the start of a route, when leaving a route the > RouteContext should be set to the route that called it. However it is > apparently null, which means that if an error happens at that point it cannot > use the onException rules that have been set. > In 3.0 the RouteContext was a stack so it kept track of all the routes that > it passed, meaning automatically returned to the parent RouteContext value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14739) RouteContext missing for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14739: Fix Version/s: 3.1.1 > RouteContext missing for RedeliveryErrorHandler > --- > > Key: CAMEL-14739 > URL: https://issues.apache.org/jira/browse/CAMEL-14739 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 3.1.0 >Reporter: Nathan >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.2.0, 3.1.1 > > Attachments: camel-error-test.zip > > > The RedeliveryErrorHandler needs the RouteContext to determine which > onException rule to use. > The RouteContext is set at the start of a route, when leaving a route the > RouteContext should be set to the route that called it. However it is > apparently null, which means that if an error happens at that point it cannot > use the onException rules that have been set. > In 3.0 the RouteContext was a stack so it kept track of all the routes that > it passed, meaning automatically returned to the parent RouteContext value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-14467) camel-jcache - Dynamically bypass the cache for lookups
[ https://issues.apache.org/jira/browse/CAMEL-14467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Volodin reassigned CAMEL-14467: -- Assignee: Dmitry Volodin > camel-jcache - Dynamically bypass the cache for lookups > --- > > Key: CAMEL-14467 > URL: https://issues.apache.org/jira/browse/CAMEL-14467 > Project: Camel > Issue Type: New Feature > Components: camel-jcache >Affects Versions: 3.0.1 >Reporter: Jens Kleine-Herzbruch >Assignee: Dmitry Volodin >Priority: Major > Attachments: bypass.diff > > > Currently, the JCachePolicy can only enabled or disable the cache completely > at startup. > > It would be useful to be able to enable or disable caching per request, > though. This change adds a new property "bypassExpression". If this > expression is set and returns true, the cache is ignored for lookup, the > underlying route is executed as normal, and the returned value is inserted in > the cache for future lookups. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14512) Allow reference to custom ClientInterceptor or Producer to customize authentication
[
https://issues.apache.org/jira/browse/CAMEL-14512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Volodin updated CAMEL-14512:
---
Component/s: (was: camel-spring-boot-starters)
(was: camel-spring-boot)
(was: camel-spring)
> Allow reference to custom ClientInterceptor or Producer to customize
> authentication
> ---
>
> Key: CAMEL-14512
> URL: https://issues.apache.org/jira/browse/CAMEL-14512
> Project: Camel
> Issue Type: Wish
> Components: camel-grpc
> Environment: * Java 11
> * SpringBoot 2.1.5.RELEASE
> * Camel 3.0.0-M2
> * Camel-Grpc-Starter 3.0.0-M2
>Reporter: Philipp
>Priority: Minor
>
> The [GRPC
> component|https://github.com/apache/camel/blob/master/components/camel-grpc/src/main/docs/grpc-component.adoc]
> does currently not offer the possibility to intercept the connection
> establishment against the gRPC server out of the box.
> This prevents to add custom authentication to the channel/connection setup.
> And since the gRPC component does not offer this custom implementation out of
> the box, the currently only solution is:
> * Implement a custom {{GrpcComponent}}
> * Implement a custom {{GrpcEndpoint}}
> * Implement a custom {{GrpcProducer}} or {{DefaultAsyncProducer}}
> ** Override the {{doStart()}} method
> ** Instantiate the {{Channel}}
> ** Add a custom {{ClientInterceptor}} and override the {{interceptCall()}}
> method
> ** Add headers to the metadata of the prepared call
> Even though there are the properties {{authenticationType=JWT}},
> {{jwtSecret}}, {{jwtIssuer}} and so on, these arguments only allow constant
> strings. Therefore, no retrieval of OAuth tokens (for example) during the
> runtime is possible, but everything would have to be hard-coded.
> The [AHC-WS
> component|https://github.com/apache/camel/blob/master/components/camel-ahc-ws/src/main/docs/ahc-ws-component.adoc]
> in contrast, offers this possibility by implementing a custom
> {{AsyncHttpClient}} and pointing to it via the
> {{camel.component.ahc-ws.client}} property in the {{application.yml}}. Like
> this, the connection setup of the websocket can easily be intercepted by
> overriding {{DefaultAsyncHttpClient.prepareGet()}} where OAuth tokens (for
> example) can be passed and added to the handshake.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-14512) Allow reference to custom ClientInterceptor or Producer to customize authentication
[
https://issues.apache.org/jira/browse/CAMEL-14512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Volodin reassigned CAMEL-14512:
--
Assignee: Dmitry Volodin
> Allow reference to custom ClientInterceptor or Producer to customize
> authentication
> ---
>
> Key: CAMEL-14512
> URL: https://issues.apache.org/jira/browse/CAMEL-14512
> Project: Camel
> Issue Type: Wish
> Components: camel-grpc
> Environment: * Java 11
> * SpringBoot 2.1.5.RELEASE
> * Camel 3.0.0-M2
> * Camel-Grpc-Starter 3.0.0-M2
>Reporter: Philipp
>Assignee: Dmitry Volodin
>Priority: Minor
>
> The [GRPC
> component|https://github.com/apache/camel/blob/master/components/camel-grpc/src/main/docs/grpc-component.adoc]
> does currently not offer the possibility to intercept the connection
> establishment against the gRPC server out of the box.
> This prevents to add custom authentication to the channel/connection setup.
> And since the gRPC component does not offer this custom implementation out of
> the box, the currently only solution is:
> * Implement a custom {{GrpcComponent}}
> * Implement a custom {{GrpcEndpoint}}
> * Implement a custom {{GrpcProducer}} or {{DefaultAsyncProducer}}
> ** Override the {{doStart()}} method
> ** Instantiate the {{Channel}}
> ** Add a custom {{ClientInterceptor}} and override the {{interceptCall()}}
> method
> ** Add headers to the metadata of the prepared call
> Even though there are the properties {{authenticationType=JWT}},
> {{jwtSecret}}, {{jwtIssuer}} and so on, these arguments only allow constant
> strings. Therefore, no retrieval of OAuth tokens (for example) during the
> runtime is possible, but everything would have to be hard-coded.
> The [AHC-WS
> component|https://github.com/apache/camel/blob/master/components/camel-ahc-ws/src/main/docs/ahc-ws-component.adoc]
> in contrast, offers this possibility by implementing a custom
> {{AsyncHttpClient}} and pointing to it via the
> {{camel.component.ahc-ws.client}} property in the {{application.yml}}. Like
> this, the connection setup of the websocket can easily be intercepted by
> overriding {{DefaultAsyncHttpClient.prepareGet()}} where OAuth tokens (for
> example) can be passed and added to the handshake.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-14739) RouteContext missing for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-14739: --- Assignee: Claus Ibsen (was: Guillaume Nodet) > RouteContext missing for RedeliveryErrorHandler > --- > > Key: CAMEL-14739 > URL: https://issues.apache.org/jira/browse/CAMEL-14739 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 3.1.0 >Reporter: Nathan >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.2.0 > > Attachments: camel-error-test.zip > > > The RedeliveryErrorHandler needs the RouteContext to determine which > onException rule to use. > The RouteContext is set at the start of a route, when leaving a route the > RouteContext should be set to the route that called it. However it is > apparently null, which means that if an error happens at that point it cannot > use the onException rules that have been set. > In 3.0 the RouteContext was a stack so it kept track of all the routes that > it passed, meaning automatically returned to the parent RouteContext value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14739) RouteContext missing for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066541#comment-17066541 ] Claus Ibsen commented on CAMEL-14739: - Okay pushed an unit test to camel-core so we can use that to track down the bug https://github.com/apache/camel/commit/c75ab25edb27e99565faf9891e2766f438392b5d > RouteContext missing for RedeliveryErrorHandler > --- > > Key: CAMEL-14739 > URL: https://issues.apache.org/jira/browse/CAMEL-14739 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 3.1.0 >Reporter: Nathan >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.2.0 > > Attachments: camel-error-test.zip > > > The RedeliveryErrorHandler needs the RouteContext to determine which > onException rule to use. > The RouteContext is set at the start of a route, when leaving a route the > RouteContext should be set to the route that called it. However it is > apparently null, which means that if an error happens at that point it cannot > use the onException rules that have been set. > In 3.0 the RouteContext was a stack so it kept track of all the routes that > it passed, meaning automatically returned to the parent RouteContext value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-13530) Upgrade Milo to 0.3.8
[ https://issues.apache.org/jira/browse/CAMEL-13530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Volodin updated CAMEL-13530: --- Summary: Upgrade Milo to 0.3.8 (was: Upgrade Milo to 0.3.0) > Upgrade Milo to 0.3.8 > - > > Key: CAMEL-13530 > URL: https://issues.apache.org/jira/browse/CAMEL-13530 > Project: Camel > Issue Type: Task > Components: camel-milo >Reporter: Andrea Cosentino >Priority: Minor > Fix For: 3.x > > > Some breaking changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-14495) OPC UA Client samplingInterval parameter seems not take any effect
[
https://issues.apache.org/jira/browse/CAMEL-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Volodin reassigned CAMEL-14495:
--
Assignee: Dmitry Volodin
> OPC UA Client samplingInterval parameter seems not take any effect
> --
>
> Key: CAMEL-14495
> URL: https://issues.apache.org/jira/browse/CAMEL-14495
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
>Affects Versions: 2.25.0
>Reporter: Hobbert
>Assignee: Dmitry Volodin
>Priority: Minor
> Labels: help-wanted
> Fix For: 3.2.0
>
>
> When I set the *samplingInterval* parameter on a Milo OPC UA Client route,
> the interval not changes on the real OPC application! Remains 1000 mili
> seconds even after configuring!! Can anyone confirm that??
> Heres my route
> http://camel.apache.org/schema/spring; >
>
> uri="milo-client:tcp://192.168.0.2:4840?samplingInterval=50=RAW(ns=4;i=12)"/>
>
> ${in.body}
>
>
>
> Thanks
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14495) OPC UA Client samplingInterval parameter seems not take any effect
[
https://issues.apache.org/jira/browse/CAMEL-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066533#comment-17066533
]
Dmitry Volodin commented on CAMEL-14495:
[~evergreen] do you need to configure hardcoded requestedPublishingInterval?
samplingInterval and requestedPublishingInterval are different parameters:
[https://stackoverflow.com/questions/41183394/what-does-the-requestedpublishinginterval-in-milo-mean]
> OPC UA Client samplingInterval parameter seems not take any effect
> --
>
> Key: CAMEL-14495
> URL: https://issues.apache.org/jira/browse/CAMEL-14495
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
>Affects Versions: 2.25.0
>Reporter: Hobbert
>Priority: Minor
> Labels: help-wanted
> Fix For: 3.2.0
>
>
> When I set the *samplingInterval* parameter on a Milo OPC UA Client route,
> the interval not changes on the real OPC application! Remains 1000 mili
> seconds even after configuring!! Can anyone confirm that??
> Heres my route
> http://camel.apache.org/schema/spring; >
>
> uri="milo-client:tcp://192.168.0.2:4840?samplingInterval=50=RAW(ns=4;i=12)"/>
>
> ${in.body}
>
>
>
> Thanks
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-12863) Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
[
https://issues.apache.org/jira/browse/CAMEL-12863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Volodin resolved CAMEL-12863.
Resolution: Fixed
> Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
>
>
> Key: CAMEL-12863
> URL: https://issues.apache.org/jira/browse/CAMEL-12863
> Project: Camel
> Issue Type: New Feature
> Components: tooling
>Affects Versions: 2.22.1
>Reporter: Jochen Cordes
>Assignee: Dmitry Volodin
>Priority: Major
> Fix For: 3.2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For dealing with "legacy" date-formats (like -MM-dd) add the ability to
> pass configOptions to the swagger-codegen-plugin, f.e. dateLibrary.
>
> ...
> legacy
> ...
>
>
> The default date-object generated by the swagger-codegen-plugin (LocalTime)
> leads to parsing errors ("Expected BEGIN_OBJECT but was STRING"). Another
> option would be to enhance the GsonDataFormat
> (org.apache.camel.component.gson.GsonDataFormat), so that it also allows for
> registering TypeAdapters
> [https://www.javadoc.io/doc/com.google.code.gson/gson/latest/com.google.gson/com/google/gson/TypeAdapter.html]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-12863) Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
[
https://issues.apache.org/jira/browse/CAMEL-12863?focusedWorklogId=409370=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409370
]
ASF GitHub Bot logged work on CAMEL-12863:
--
Author: ASF GitHub Bot
Created on: 25/Mar/20 08:24
Start Date: 25/Mar/20 08:24
Worklog Time Spent: 10m
Work Description: asfgit commented on pull request #3676: CAMEL-12863:
Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
URL: https://github.com/apache/camel/pull/3676
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 409370)
Time Spent: 20m (was: 10m)
> Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
>
>
> Key: CAMEL-12863
> URL: https://issues.apache.org/jira/browse/CAMEL-12863
> Project: Camel
> Issue Type: New Feature
> Components: tooling
>Affects Versions: 2.22.1
>Reporter: Jochen Cordes
>Assignee: Dmitry Volodin
>Priority: Major
> Fix For: 3.2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For dealing with "legacy" date-formats (like -MM-dd) add the ability to
> pass configOptions to the swagger-codegen-plugin, f.e. dateLibrary.
>
> ...
> legacy
> ...
>
>
> The default date-object generated by the swagger-codegen-plugin (LocalTime)
> leads to parsing errors ("Expected BEGIN_OBJECT but was STRING"). Another
> option would be to enhance the GsonDataFormat
> (org.apache.camel.component.gson.GsonDataFormat), so that it also allows for
> registering TypeAdapters
> [https://www.javadoc.io/doc/com.google.code.gson/gson/latest/com.google.gson/com/google/gson/TypeAdapter.html]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-12863) Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
[
https://issues.apache.org/jira/browse/CAMEL-12863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Volodin updated CAMEL-12863:
---
Labels: (was: help-wanted)
> Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
>
>
> Key: CAMEL-12863
> URL: https://issues.apache.org/jira/browse/CAMEL-12863
> Project: Camel
> Issue Type: New Feature
> Components: tooling
>Affects Versions: 2.22.1
>Reporter: Jochen Cordes
>Assignee: Dmitry Volodin
>Priority: Major
> Fix For: 3.2.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For dealing with "legacy" date-formats (like -MM-dd) add the ability to
> pass configOptions to the swagger-codegen-plugin, f.e. dateLibrary.
>
> ...
> legacy
> ...
>
>
> The default date-object generated by the swagger-codegen-plugin (LocalTime)
> leads to parsing errors ("Expected BEGIN_OBJECT but was STRING"). Another
> option would be to enhance the GsonDataFormat
> (org.apache.camel.component.gson.GsonDataFormat), so that it also allows for
> registering TypeAdapters
> [https://www.javadoc.io/doc/com.google.code.gson/gson/latest/com.google.gson/com/google/gson/TypeAdapter.html]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-12863) Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
[
https://issues.apache.org/jira/browse/CAMEL-12863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Volodin updated CAMEL-12863:
---
Fix Version/s: (was: Future)
3.2.0
> Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
>
>
> Key: CAMEL-12863
> URL: https://issues.apache.org/jira/browse/CAMEL-12863
> Project: Camel
> Issue Type: New Feature
> Components: tooling
>Affects Versions: 2.22.1
>Reporter: Jochen Cordes
>Assignee: Dmitry Volodin
>Priority: Major
> Labels: help-wanted
> Fix For: 3.2.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For dealing with "legacy" date-formats (like -MM-dd) add the ability to
> pass configOptions to the swagger-codegen-plugin, f.e. dateLibrary.
>
> ...
> legacy
> ...
>
>
> The default date-object generated by the swagger-codegen-plugin (LocalTime)
> leads to parsing errors ("Expected BEGIN_OBJECT but was STRING"). Another
> option would be to enhance the GsonDataFormat
> (org.apache.camel.component.gson.GsonDataFormat), so that it also allows for
> registering TypeAdapters
> [https://www.javadoc.io/doc/com.google.code.gson/gson/latest/com.google.gson/com/google/gson/TypeAdapter.html]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-12863) Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
[
https://issues.apache.org/jira/browse/CAMEL-12863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066462#comment-17066462
]
Dmitry Volodin commented on CAMEL-12863:
Yes, configOptions is part of the swagger-codegen-maven-plugin.
[https://github.com/swagger-api/swagger-codegen/tree/master/modules/swagger-codegen-maven-plugin]
> Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
>
>
> Key: CAMEL-12863
> URL: https://issues.apache.org/jira/browse/CAMEL-12863
> Project: Camel
> Issue Type: New Feature
> Components: tooling
>Affects Versions: 2.22.1
>Reporter: Jochen Cordes
>Assignee: Dmitry Volodin
>Priority: Major
> Labels: help-wanted
> Fix For: Future
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For dealing with "legacy" date-formats (like -MM-dd) add the ability to
> pass configOptions to the swagger-codegen-plugin, f.e. dateLibrary.
>
> ...
> legacy
> ...
>
>
> The default date-object generated by the swagger-codegen-plugin (LocalTime)
> leads to parsing errors ("Expected BEGIN_OBJECT but was STRING"). Another
> option would be to enhance the GsonDataFormat
> (org.apache.camel.component.gson.GsonDataFormat), so that it also allows for
> registering TypeAdapters
> [https://www.javadoc.io/doc/com.google.code.gson/gson/latest/com.google.gson/com/google/gson/TypeAdapter.html]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14786) Move as much initialisation code from start() to init() phase
[
https://issues.apache.org/jira/browse/CAMEL-14786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14786:
Component/s: camel-core
> Move as much initialisation code from start() to init() phase
> -
>
> Key: CAMEL-14786
> URL: https://issues.apache.org/jira/browse/CAMEL-14786
> Project: Camel
> Issue Type: Task
> Components: camel-core
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.2.0
>
>
> The work done currently in the {{init}} phase will be moved to the {{build}}
> phase.
> The {{start}} phase will be split between {{init}} for bean configuration /
> wiring, excluding any thread / network access and the {{start}} phase to
> actually start consuming and creating threads / sockets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-12863) Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
[
https://issues.apache.org/jira/browse/CAMEL-12863?focusedWorklogId=409362=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409362
]
ASF GitHub Bot logged work on CAMEL-12863:
--
Author: ASF GitHub Bot
Created on: 25/Mar/20 07:52
Start Date: 25/Mar/20 07:52
Worklog Time Spent: 10m
Work Description: dmvolod commented on pull request #3676: CAMEL-12863:
Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
URL: https://github.com/apache/camel/pull/3676
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 409362)
Remaining Estimate: 0h
Time Spent: 10m
> Add configOptions to camel-restdsl-swagger-plugin for swagger-codegen-plugin
>
>
> Key: CAMEL-12863
> URL: https://issues.apache.org/jira/browse/CAMEL-12863
> Project: Camel
> Issue Type: New Feature
> Components: tooling
>Affects Versions: 2.22.1
>Reporter: Jochen Cordes
>Assignee: Dmitry Volodin
>Priority: Major
> Labels: help-wanted
> Fix For: Future
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For dealing with "legacy" date-formats (like -MM-dd) add the ability to
> pass configOptions to the swagger-codegen-plugin, f.e. dateLibrary.
>
> ...
> legacy
> ...
>
>
> The default date-object generated by the swagger-codegen-plugin (LocalTime)
> leads to parsing errors ("Expected BEGIN_OBJECT but was STRING"). Another
> option would be to enhance the GsonDataFormat
> (org.apache.camel.component.gson.GsonDataFormat), so that it also allows for
> registering TypeAdapters
> [https://www.javadoc.io/doc/com.google.code.gson/gson/latest/com.google.gson/com/google/gson/TypeAdapter.html]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-13704) Add github pull request template for PR instruction
[
https://issues.apache.org/jira/browse/CAMEL-13704?focusedWorklogId=409361=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409361
]
ASF GitHub Bot logged work on CAMEL-13704:
--
Author: ASF GitHub Bot
Created on: 25/Mar/20 07:50
Start Date: 25/Mar/20 07:50
Worklog Time Spent: 10m
Work Description: oscerd commented on pull request #3665: CAMEL-13704 -
Added PR template file with instructions on what to include when subm…
URL: https://github.com/apache/camel/pull/3665
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 409361)
Time Spent: 20m (was: 10m)
> Add github pull request template for PR instruction
> ---
>
> Key: CAMEL-13704
> URL: https://issues.apache.org/jira/browse/CAMEL-13704
> Project: Camel
> Issue Type: Task
> Components: website
>Reporter: Willem Jiang
>Priority: Major
> Labels: help-wanted
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's standard procedure to accept the big contribution with iCLA granted in
> ASF.
> We should list this information when the contributor send the PR by
> specifying a PR template for github. It could be annoying for the
> experienced contributors, but it could save us some time for the new
> contributors.
> Here is a draft I have, please add comment for it.
> {code}
> - [ ] Make sure there is a [JIRA
> issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change
> (usually before you start working on it). Trivial changes like typos do not
> require a JIRA issue. Your pull request should address just this issue,
> without pulling in other changes.
> - [ ] Each commit in the pull request should have a meaningful subject line
> and body.
> - [ ] Format the pull request title like `[CAMEL-XXX] Fixes bug in
> camel-file component`, where you replace `CAMEL-XXX` with the appropriate
> JIRA issue.
> - [ ] Write a pull request description that is detailed enough to understand
> what the pull request does, how, and why.
> - [ ] Run `mvn clean install` in your module to make sure basic checks pass.
> A more thorough check will be performed on your pull request automatically.
> - [ ] If this contribution is large, please file an Apache [Individual
> Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14739) RouteContext missing for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066443#comment-17066443 ] Claus Ibsen commented on CAMEL-14739: - Thanks for the sample project. Reproduced and we see this WARN 2020-03-25 07:55:46.758 WARN 2123 --- [nio-8080-exec-4] o.a.c.p.e.RedeliveryErrorHandler : Cannot determine current route from Exchange with id: ID-davsclaus-pro-local-1585119287866-0-3, will fallback and use first error handler. > RouteContext missing for RedeliveryErrorHandler > --- > > Key: CAMEL-14739 > URL: https://issues.apache.org/jira/browse/CAMEL-14739 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 3.1.0 >Reporter: Nathan >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.2.0 > > Attachments: camel-error-test.zip > > > The RedeliveryErrorHandler needs the RouteContext to determine which > onException rule to use. > The RouteContext is set at the start of a route, when leaving a route the > RouteContext should be set to the route that called it. However it is > apparently null, which means that if an error happens at that point it cannot > use the onException rules that have been set. > In 3.0 the RouteContext was a stack so it kept track of all the routes that > it passed, meaning automatically returned to the parent RouteContext value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14739) RouteContext missing for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066444#comment-17066444 ] Claus Ibsen commented on CAMEL-14739: - ❯ curl http://localhost:8080/camel/api/hello "Hello world"% ❯ curl http://localhost:8080/camel/api/helloError "general exception was properly handled"% ❯ curl http://localhost:8080/camel/api/helloBug "random processing (should not be exposed)"% > RouteContext missing for RedeliveryErrorHandler > --- > > Key: CAMEL-14739 > URL: https://issues.apache.org/jira/browse/CAMEL-14739 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 3.1.0 >Reporter: Nathan >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.2.0 > > Attachments: camel-error-test.zip > > > The RedeliveryErrorHandler needs the RouteContext to determine which > onException rule to use. > The RouteContext is set at the start of a route, when leaving a route the > RouteContext should be set to the route that called it. However it is > apparently null, which means that if an error happens at that point it cannot > use the onException rules that have been set. > In 3.0 the RouteContext was a stack so it kept track of all the routes that > it passed, meaning automatically returned to the parent RouteContext value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14772) website - Add section to display the 6 camel projects with logos
[ https://issues.apache.org/jira/browse/CAMEL-14772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066431#comment-17066431 ] JyotiAttri commented on CAMEL-14772: [~davsclaus], Thanks > website - Add section to display the 6 camel projects with logos > > > Key: CAMEL-14772 > URL: https://issues.apache.org/jira/browse/CAMEL-14772 > Project: Camel > Issue Type: Improvement > Components: website >Reporter: Claus Ibsen >Priority: Major > Labels: help-wanted > Fix For: 3.x > > Attachments: front-page.png > > > We should take this tweet with screenshot, and put on the front page to > better highlight the Camel projects we have > https://twitter.com/ApacheCamel/status/1242074457050624000 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14772) website - Add section to display the 6 camel projects with logos
[ https://issues.apache.org/jira/browse/CAMEL-14772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066430#comment-17066430 ] JyotiAttri commented on CAMEL-14772: Hi [~@pooja_y], I am already working on this, just don't want that we duplicate work. I am adding the section as listed in the description above. > website - Add section to display the 6 camel projects with logos > > > Key: CAMEL-14772 > URL: https://issues.apache.org/jira/browse/CAMEL-14772 > Project: Camel > Issue Type: Improvement > Components: website >Reporter: Claus Ibsen >Priority: Major > Labels: help-wanted > Fix For: 3.x > > Attachments: front-page.png > > > We should take this tweet with screenshot, and put on the front page to > better highlight the Camel projects we have > https://twitter.com/ApacheCamel/status/1242074457050624000 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14786) Move as much initialisation code from start() to init() phase
Guillaume Nodet created CAMEL-14786:
---
Summary: Move as much initialisation code from start() to init()
phase
Key: CAMEL-14786
URL: https://issues.apache.org/jira/browse/CAMEL-14786
Project: Camel
Issue Type: Task
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
Fix For: 3.2.0
The work done currently in the {{init}} phase will be moved to the {{build}}
phase.
The {{start}} phase will be split between {{init}} for bean configuration /
wiring, excluding any thread / network access and the {{start}} phase to
actually start consuming and creating threads / sockets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14778) camel-cxf - Move Spring out into camel-cxf-spring
[ https://issues.apache.org/jira/browse/CAMEL-14778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14778: Fix Version/s: (was: 3.2.0) 3.x > camel-cxf - Move Spring out into camel-cxf-spring > - > > Key: CAMEL-14778 > URL: https://issues.apache.org/jira/browse/CAMEL-14778 > Project: Camel > Issue Type: Improvement > Components: camel-cxf >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > We have moved OSGi blueprint out. We could look at moving spring out (spring > xml) as that could potentially make camel-cxf lighter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14778) camel-cxf - Move Spring out into camel-cxf-spring
[ https://issues.apache.org/jira/browse/CAMEL-14778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14778: Component/s: camel-cxf > camel-cxf - Move Spring out into camel-cxf-spring > - > > Key: CAMEL-14778 > URL: https://issues.apache.org/jira/browse/CAMEL-14778 > Project: Camel > Issue Type: Improvement > Components: camel-cxf >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.2.0 > > > We have moved OSGi blueprint out. We could look at moving spring out (spring > xml) as that could potentially make camel-cxf lighter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14780) camel-undertow: UndertowSecurityProvider SPI API misses a method to change HttpHandler
[ https://issues.apache.org/jira/browse/CAMEL-14780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14780: Fix Version/s: 3.2.0 > camel-undertow: UndertowSecurityProvider SPI API misses a method to change > HttpHandler > -- > > Key: CAMEL-14780 > URL: https://issues.apache.org/jira/browse/CAMEL-14780 > Project: Camel > Issue Type: Bug > Components: camel-undertow >Affects Versions: 3.2.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.2.0 > > > During refactor of camel-elytron to implement UndertowSecurityProvider I've > noticed that API does not allow to change of the HttpHandler during endpoint > registration. This "hook" for security provider is required for > camel-elytron. > (Change could be done without breaking back compatibility or compilation for > existing implementations.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14772) website - Add section to display the 6 camel projects with logos
[ https://issues.apache.org/jira/browse/CAMEL-14772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066408#comment-17066408 ] Claus Ibsen commented on CAMEL-14772: - For the logos then use what is the best practice. They are individual logos so if its possible to use two and place then next to each other then do so. Otherwise you would have to create your own set of combo and put them together as a single logo. > website - Add section to display the 6 camel projects with logos > > > Key: CAMEL-14772 > URL: https://issues.apache.org/jira/browse/CAMEL-14772 > Project: Camel > Issue Type: Improvement > Components: website >Reporter: Claus Ibsen >Priority: Major > Labels: help-wanted > Fix For: 3.x > > Attachments: front-page.png > > > We should take this tweet with screenshot, and put on the front page to > better highlight the Camel projects we have > https://twitter.com/ApacheCamel/status/1242074457050624000 -- This message was sent by Atlassian Jira (v8.3.4#803005)
