[jira] [Created] (CAMEL-20784) CamelTestSupport: Add an option for camel quarkus to customize unsupported check
Jiri Ondrusek created CAMEL-20784:
-
Summary: CamelTestSupport: Add an option for camel quarkus to
customize unsupported check
Key: CAMEL-20784
URL: https://issues.apache.org/jira/browse/CAMEL-20784
Project: Camel
Issue Type: Bug
Components: camel-test
Affects Versions: 4.7.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
I introduced an wrong condition into the CamelTestSupport a long time ago, The
issue can not be detected, because camel-quarkus overrode the logic in its own
class. The
[refactor|http://example.com]https://github.com/apache/camel/commit/427c19faa5d2e5a3534f244e30355ec7134422e5
of that code revealed that mistake.
The proper condition for the Camel-quarkus test is not existence of annotation
{code:java}
org.apache.camel.quarkus.test.CamelQuarkusTest (which does not exist){code}
, but inheritance from
{code:java}
org.apache.camel.quarkus.test.CamelQuarkusTestSupport {code}
Ideally the fix would use
{code}clazz.isAssignableFrom(CamelQuarkusTestSupport.class). {code}
Unfortunately Camel does not know about _CamelQuarkusTestSupport_, therefore it
hoas to be solved differently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20734) Aws-xray: bump of aws-xray-recorder-sdk-bom brought conflict in dependencies
Jiri Ondrusek created CAMEL-20734:
-
Summary: Aws-xray: bump of aws-xray-recorder-sdk-bom brought
conflict in dependencies
Key: CAMEL-20734
URL: https://issues.apache.org/jira/browse/CAMEL-20734
Project: Camel
Issue Type: Bug
Components: camel-aws-xray
Affects Versions: 4.6.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
I noticed (during build of camel-quarkus) that the bump of
aws-xray-recorder-sdk-bom ([PR|https://github.com/apache/camel/pull/14016])
brought conflict of _com.amazonaws:aws-java-sdk-core:jar_
Bumped BOM brought aws-java-sdk-core in versions *.228* and *.708*
{code:java}
+-org.apache.camel:camel-aws-xray:4.6.0-SNAPSHOT
+-com.amazonaws:aws-xray-recorder-sdk-aws-sdk:2.15.3
+-com.amazonaws:aws-java-sdk-core:1.12.708
{code}
and
{code:java}
+-org.apache.camel:camel-aws-xray:4.6.0-SNAPSHOT
+-com.amazonaws:aws-xray-recorder-sdk-core:2.15.3
+-com.amazonaws:aws-java-sdk-xray:1.12.228
+-com.amazonaws:aws-java-sdk-core:1.12.228 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20663) camel-main: baseMainSupport may fail to doConfigureCamelContextFromMainConfiguration
Jiri Ondrusek created CAMEL-20663:
-
Summary: camel-main: baseMainSupport may fail to
doConfigureCamelContextFromMainConfiguration
Key: CAMEL-20663
URL: https://issues.apache.org/jira/browse/CAMEL-20663
Project: Camel
Issue Type: Bug
Components: camel-main
Affects Versions: 4.4.1
Reporter: Jiri Ondrusek
According to
[https://camel.apache.org/manual/camel-4x-upgrade-guide-4_4.html#_camel_main,]
the property for enabling routeController is
`{{{}camel.routecontroller.enabled{}}}.` Unfortunatelly if such property is
used, following code is ignoring it
([https://github.com/apache/camel/blob/main/core/camel-main/src/main/java/org/apache/camel/main/BaseMainSupport.java#L1103)]
- because od lowercase vs camelCase.
If I changethe if to ignore case, I got another error, because value is not
loaded correctly (in the next lines of the baseMainSupport)
Problem can be simulated whenrunning test on camel-quarkus-examples/health
(just change property in this line
[https://github.com/apache/camel-quarkus-examples/blob/main/health/src/main/resources/application.properties#L31]
to camel.routeController.enabled = true
I think that more properties might be affected by this error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20585) Camel-package-maven-plugin: generates test configurers in non-tests artifacts
[
https://issues.apache.org/jira/browse/CAMEL-20585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828891#comment-17828891
]
Jiri Ondrusek commented on CAMEL-20585:
---
[~gnodet] FYI
> Camel-package-maven-plugin: generates test configurers in non-tests artifacts
> -
>
> Key: CAMEL-20585
> URL: https://issues.apache.org/jira/browse/CAMEL-20585
> Project: Camel
> Issue Type: Bug
> Components: camel-package-maven-plugin
>Affects Versions: 4.5.0
>Reporter: Jiri Ondrusek
>Priority: Major
>
> Change
> [https://github.com/apache/camel/commit/0fb5aa31ae590eb042a1664ff18b6d5c44acc5c4#diff-8c376760c1f21c10dc4f6b051f972405cc04fc1ce9ca636a478cc5cfb8a1f51c]
> causes that for example _camel-main.jar_ contains test configurers like
> {code:java}
> org.apache.camel.main.MySecondBar, org.apache.camel.main.MySecondFoo| {code}
> As you can see
> herehttps://github.com/apache/camel/commit/0fb5aa31ae590eb042a1664ff18b6d5c44acc5c4
> different method is called.
>
> The original method was:
> {code:java}
> public static boolean updateResource(BuildContext buildContext, Path out,
> String data) {
> try {
> if (FileUtil.updateFile(out, data)) {
> refresh(buildContext, out);
> return true;
> }
> } catch (IOException e) {
> throw new IOError(e);
> }
> return false;
> {code}
> which can not create a test resource.
> Newly called method
> {code:java}
> protected boolean updateResource(Path dir, String fileName, String data) {
> boolean updated;
> updated = updateResource(buildContext, dir.resolve(fileName), data);
> if (!fileName.endsWith(".java")) {
> > Path outputDir =
> > Paths.get(project.getBuild().getOutputDirectory());
> > updated |= updateResource(buildContext,
> > outputDir.resolve(fileName), data);
> }
> return updated;
> {code}
> refreshes also resources in outputDiectorry. Therefore some test configurers
> are created during build of the artifact.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20585) Camel-package-maven-plugin: generates test configurers in non-tests artifacts
Jiri Ondrusek created CAMEL-20585:
-
Summary: Camel-package-maven-plugin: generates test configurers in
non-tests artifacts
Key: CAMEL-20585
URL: https://issues.apache.org/jira/browse/CAMEL-20585
Project: Camel
Issue Type: Bug
Components: camel-package-maven-plugin
Affects Versions: 4.5.0
Reporter: Jiri Ondrusek
Change
[https://github.com/apache/camel/commit/0fb5aa31ae590eb042a1664ff18b6d5c44acc5c4#diff-8c376760c1f21c10dc4f6b051f972405cc04fc1ce9ca636a478cc5cfb8a1f51c]
causes that for example _camel-main.jar_ contains test configurers like
{code:java}
org.apache.camel.main.MySecondBar, org.apache.camel.main.MySecondFoo| {code}
As you can see
herehttps://github.com/apache/camel/commit/0fb5aa31ae590eb042a1664ff18b6d5c44acc5c4
different method is called.
The original method was:
{code:java}
public static boolean updateResource(BuildContext buildContext, Path out,
String data) {
try {
if (FileUtil.updateFile(out, data)) {
refresh(buildContext, out);
return true;
}
} catch (IOException e) {
throw new IOError(e);
}
return false;
{code}
which can not create a test resource.
Newly called method
{code:java}
protected boolean updateResource(Path dir, String fileName, String data) {
boolean updated;
updated = updateResource(buildContext, dir.resolve(fileName), data);
if (!fileName.endsWith(".java")) {
> Path outputDir =
> Paths.get(project.getBuild().getOutputDirectory());
> updated |= updateResource(buildContext,
> outputDir.resolve(fileName), data);
}
return updated;
{code}
refreshes also resources in outputDiectorry. Therefore some test configurers
are created during build of the artifact.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20585) Camel-package-maven-plugin: generates test configurers in non-tests artifacts
[
https://issues.apache.org/jira/browse/CAMEL-20585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828918#comment-17828918
]
Jiri Ondrusek commented on CAMEL-20585:
---
I reverted the code causing problem in this PR (as a quick fix):
https://github.com/apache/camel/pull/13549
> Camel-package-maven-plugin: generates test configurers in non-tests artifacts
> -
>
> Key: CAMEL-20585
> URL: https://issues.apache.org/jira/browse/CAMEL-20585
> Project: Camel
> Issue Type: Bug
> Components: camel-package-maven-plugin
>Affects Versions: 4.5.0
>Reporter: Jiri Ondrusek
>Priority: Major
>
> Change
> [https://github.com/apache/camel/commit/0fb5aa31ae590eb042a1664ff18b6d5c44acc5c4#diff-8c376760c1f21c10dc4f6b051f972405cc04fc1ce9ca636a478cc5cfb8a1f51c]
> causes that for example _camel-main.jar_ contains test configurers like
> {code:java}
> org.apache.camel.main.MySecondBar, org.apache.camel.main.MySecondFoo| {code}
> As you can see
> herehttps://github.com/apache/camel/commit/0fb5aa31ae590eb042a1664ff18b6d5c44acc5c4
> different method is called.
>
> The original method was:
> {code:java}
> public static boolean updateResource(BuildContext buildContext, Path out,
> String data) {
> try {
> if (FileUtil.updateFile(out, data)) {
> refresh(buildContext, out);
> return true;
> }
> } catch (IOException e) {
> throw new IOError(e);
> }
> return false;
> {code}
> which can not create a test resource.
> Newly called method
> {code:java}
> protected boolean updateResource(Path dir, String fileName, String data) {
> boolean updated;
> updated = updateResource(buildContext, dir.resolve(fileName), data);
> if (!fileName.endsWith(".java")) {
> > Path outputDir =
> > Paths.get(project.getBuild().getOutputDirectory());
> > updated |= updateResource(buildContext,
> > outputDir.resolve(fileName), data);
> }
> return updated;
> {code}
> refreshes also resources in outputDiectorry. Therefore some test configurers
> are created during build of the artifact.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20566) Jaxb version should be present in parent/pom.xml not pom/xml
Jiri Ondrusek created CAMEL-20566:
-
Summary: Jaxb version should be present in parent/pom.xml not
pom/xml
Key: CAMEL-20566
URL: https://issues.apache.org/jira/browse/CAMEL-20566
Project: Camel
Issue Type: Bug
Affects Versions: 4.5.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
I'd like to reuse a version `jaxb-core-version` in camel-quarkus project. I
noticed, that the definition of version is placed in pom.xml (not
parent/pom.xml), therefore can not be reused.
I dug up a little bit into the history and found a comment from pom.xml
{code:java}
{code}
, which was removed during removal of maven-eclipse-plugin ( that is retired
since 2015)
Based on that comment, the fact that eclipse plugin was removed and successful
local build with the fix, I think that those version definition should be moved
to parent/pom.xml (where other version resides).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20393) Splunk-hec, splunk: add ssl configuration into the component
[ https://issues.apache.org/jira/browse/CAMEL-20393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-20393: -- Priority: Major (was: Minor) > Splunk-hec, splunk: add ssl configuration into the component > > > Key: CAMEL-20393 > URL: https://issues.apache.org/jira/browse/CAMEL-20393 > Project: Camel > Issue Type: Improvement > Components: camel-splunk, camel-splunk-hec >Affects Versions: 4.4.0 >Reporter: Jiri Ondrusek >Priority: Major > > I was inspecting test coverage on CQ and I noticed, that it is not possible > to define e.g. sslContextParameters diectly for the components splunk and > splunk-hec. > Both of those components allows https configuration. To make e.g. splunk-hec > able to connect to secured server, I would need to configure certificates on > JRE level. Option to that directly on the component would be much easier and > testable and would be aligned with other Camel components (e.g. mail, > lumberjack, ...) > (and also the UX experience should be similar for each component) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20420) CSimple: use of builder throws UnsupportedOperationException
Jiri Ondrusek created CAMEL-20420:
-
Summary: CSimple: use of builder throws
UnsupportedOperationException
Key: CAMEL-20420
URL: https://issues.apache.org/jira/browse/CAMEL-20420
Project: Camel
Issue Type: Bug
Affects Versions: 4.4.0
Reporter: Jiri Ondrusek
The builder is creating unmodifiable map
[here|https://github.com/apache/camel/blob/main/core/camel-core-languages/src/main/java/org/apache/camel/language/csimple/CSimpleLanguage.java#L206].
'createExpression' call uses computeIfAbsent
[here|https://github.com/apache/camel/blob/main/core/camel-core-languages/src/main/java/org/apache/camel/language/csimple/CSimpleLanguage.java#L171],
which then fails with {{{}java.lang.UnsupportedOperationException{}}}.
Problem can be simulated on Camel-quarkus integration-tests/csimple. Failure
can be seen in this PR - [https://github.com/apache/camel-quarkus/pull/5747]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20393) Splunk-hec, splunk: add ssl configuration into the component
Jiri Ondrusek created CAMEL-20393: - Summary: Splunk-hec, splunk: add ssl configuration into the component Key: CAMEL-20393 URL: https://issues.apache.org/jira/browse/CAMEL-20393 Project: Camel Issue Type: Improvement Components: camel-splunk, camel-splunk-hec Affects Versions: 4.4.0 Reporter: Jiri Ondrusek I was inspecting test coverage on CQ and I noticed, that it is not possible to define e.g. sslContextParameters diectly for the components splunk and splunk-hec. Both of those components allows https configuration. To make e.g. splunk-hec able to connect to secured server, I would need to configure certificates on JRE level. Option to that directly on the component would be much easier and testable and would be aligned with other Camel components (e.g. mail, lumberjack, ...) (and also the UX experience should be similar for each component) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20375) Camel-ical: Camel-20370 brought a NPE in some cases
[ https://issues.apache.org/jira/browse/CAMEL-20375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-20375: -- Issue Type: Bug (was: Dependency upgrade) > Camel-ical: Camel-20370 brought a NPE in some cases > --- > > Key: CAMEL-20375 > URL: https://issues.apache.org/jira/browse/CAMEL-20375 > Project: Camel > Issue Type: Bug >Affects Versions: 4.4.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > > With the recent change > [https://github.com/apache/camel/commit/b9ec2cbf8aef4b3b86b9bb4be9ac9cb8a5bc3241] > - setter setValidating on ICalDataFormat may throw a NullPoinerException, > because the underlying object - outputter is null. > > Local variable (which is present but unset) should be used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20375) Camel-ical: Camel-20370 brought a NPE in some cases
Jiri Ondrusek created CAMEL-20375: - Summary: Camel-ical: Camel-20370 brought a NPE in some cases Key: CAMEL-20375 URL: https://issues.apache.org/jira/browse/CAMEL-20375 Project: Camel Issue Type: Dependency upgrade Affects Versions: 4.4.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek With the recent change [https://github.com/apache/camel/commit/b9ec2cbf8aef4b3b86b9bb4be9ac9cb8a5bc3241] - setter setValidating on ICalDataFormat may throw a NullPoinerException, because the underlying object - outputter is null. Local variable (which is present but unset) should be used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20168) Camel-jaxb: jaxb-impl was upgraded but not jaxb-core
Jiri Ondrusek created CAMEL-20168:
-
Summary: Camel-jaxb: jaxb-impl was upgraded but not jaxb-core
Key: CAMEL-20168
URL: https://issues.apache.org/jira/browse/CAMEL-20168
Project: Camel
Issue Type: Dependency upgrade
Components: camel-jaxb
Affects Versions: 4.3.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
Jaxb-impl-version was updated in
[commit|https://github.com/apache/camel/pull/12216/commits/3870a77fb570a22fd6586e138fd15029cc10a30b].
However the change caused, that camel-xml-jaxb brings two versions of jaxb-core
4.0.3 & 4.0.4
{code:java}
Dependency convergence error for com.sun.xml.bind:jaxb-core:4.0.3 paths to
dependency are:
+-org.apache.camel.quarkus:camel-quarkus-xml-jaxb:3.7.0-SNAPSHOT
+-org.apache.camel:camel-xml-jaxb:4.3.0-SNAPSHOT
+-com.sun.xml.bind:jaxb-core:4.0.3
and
+-org.apache.camel.quarkus:camel-quarkus-xml-jaxb:3.7.0-SNAPSHOT
+-org.apache.camel:camel-xml-jaxb:4.3.0-SNAPSHOT
+-com.sun.xml.bind:jaxb-impl:4.0.4
+-com.sun.xml.bind:jaxb-core:4.0.4
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20142) Camel-http: brings transitively 2 core versions
Jiri Ondrusek created CAMEL-20142:
-
Summary: Camel-http: brings transitively 2 core versions
Key: CAMEL-20142
URL: https://issues.apache.org/jira/browse/CAMEL-20142
Project: Camel
Issue Type: Bug
Components: camel-http
Affects Versions: 4.3.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
Upgrade of httpcore in
[8063cf7bd7977963c7cc5e43d9ba728ad8d6364b|https://github.com/apache/camel/commit/8063cf7bd7977963c7cc5e43d9ba728ad8d6364b]
brought version 5.2.3 of {_}httpcore5{_}. Unfortunately the _httpclient5_
brings also 5.2.2, which could cause a conflict when _camel-http_ is consumed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20043) Micrometer: unclear instructions of docInstrumentedThreadPoolFactory configuration in the documentation
[ https://issues.apache.org/jira/browse/CAMEL-20043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-20043: -- Affects Version/s: 4.x > Micrometer: unclear instructions of docInstrumentedThreadPoolFactory > configuration in the documentation > --- > > Key: CAMEL-20043 > URL: https://issues.apache.org/jira/browse/CAMEL-20043 > Project: Camel > Issue Type: Bug > Components: camel-micrometer >Affects Versions: 4.x >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > > Chapter [Instrumenting Camel Thread > Pools|https://camel.apache.org/components/4.0.x/micrometer-component.html#_instrumenting_camel_thread_pools] > in the documentation states: _See more details at Advanced configuration of > CamelContext using Spring._ > There is nothing like Advanced configuration in the page. Link for the > appropriate page should be used ([THREADING > MODEL|https://camel.apache.org/manual/threading-model.html] seems like the > right choice). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20043) Micrometer: unclear instructions of docInstrumentedThreadPoolFactory configuration in the documentation
Jiri Ondrusek created CAMEL-20043: - Summary: Micrometer: unclear instructions of docInstrumentedThreadPoolFactory configuration in the documentation Key: CAMEL-20043 URL: https://issues.apache.org/jira/browse/CAMEL-20043 Project: Camel Issue Type: Bug Components: camel-micrometer Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek Chapter [Instrumenting Camel Thread Pools|https://camel.apache.org/components/4.0.x/micrometer-component.html#_instrumenting_camel_thread_pools] in the documentation states: _See more details at Advanced configuration of CamelContext using Spring._ There is nothing like Advanced configuration in the page. Link for the appropriate page should be used ([THREADING MODEL|https://camel.apache.org/manual/threading-model.html] seems like the right choice). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19983) Camel-micrometer: Spring should not be mentioned as a part of the examples in the doc
Jiri Ondrusek created CAMEL-19983: - Summary: Camel-micrometer: Spring should not be mentioned as a part of the examples in the doc Key: CAMEL-19983 URL: https://issues.apache.org/jira/browse/CAMEL-19983 Project: Camel Issue Type: Bug Components: camel-micrometer Affects Versions: 4.2.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek There several occurrences of `spring` mentioned in the examples. All of them should be solved as the first example in the doc -> showing version for CDI and for spring boot. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAMEL-19883) Xml-io-dsl: route configuration is not applied to xml route
[ https://issues.apache.org/jira/browse/CAMEL-19883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek closed CAMEL-19883. - Resolution: Duplicate Duplication of https://issues.apache.org/jira/browse/CAMEL-19766 > Xml-io-dsl: route configuration is not applied to xml route > --- > > Key: CAMEL-19883 > URL: https://issues.apache.org/jira/browse/CAMEL-19883 > Project: Camel > Issue Type: Bug > Components: camel-xml-io >Affects Versions: 4.0.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > > With the fix of https://issues.apache.org/jira/browse/CAMEL-18923 a bug > (which was probably present much longer) appeared. Problem was discovered in > camel-quarkus - [https://github.com/apache/camel-quarkus/issues/4736] > > Problem is triggered on Camel side, when route defined in xml can not apply > any global routeConfiguration because reference to camel context is null. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19883) Xml-io-dsl: route configuration is not applied to xml route
Jiri Ondrusek created CAMEL-19883: - Summary: Xml-io-dsl: route configuration is not applied to xml route Key: CAMEL-19883 URL: https://issues.apache.org/jira/browse/CAMEL-19883 Project: Camel Issue Type: Bug Components: camel-xml-io Affects Versions: 4.0.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek With the fix of https://issues.apache.org/jira/browse/CAMEL-18923 a bug (which was probably present much longer) appeared. Problem was discovered in camel-quarkus - [https://github.com/apache/camel-quarkus/issues/4736] Problem is triggered on Camel side, when route defined in xml can not apply any global routeConfiguration because reference to camel context is null. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19837) Converters - unpredictable behavior linked to type hierarchy (flatpack)
[
https://issues.apache.org/jira/browse/CAMEL-19837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762286#comment-17762286
]
Jiri Ondrusek commented on CAMEL-19837:
---
This test:
https://github.com/apache/camel-quarkus/blob/camel-main/integration-tests/flatpack/src/test/java/org/apache/camel/quarkus/component/flatpack/it/FlatpackTest.java#L135-L161
> Converters - unpredictable behavior linked to type hierarchy (flatpack)
> ---
>
> Key: CAMEL-19837
> URL: https://issues.apache.org/jira/browse/CAMEL-19837
> Project: Camel
> Issue Type: Bug
> Components: core
>Affects Versions: 4.x
>Reporter: Jiri Ondrusek
>Priority: Major
>
> Consequence of
> [https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
>
> Camel-flatpack registers 2 converters:
> # from net.sf.flatpack.DataSet to Map
> # from net.sf.flatpack.Record to Map
> Problematic case: If data for conversion is instance of
> net.sf.flatpack.DefaultDataSet
>
> Direct conversion is not possible (there is no DefaultDataSet -> Map
> converter)
> therefore matching via interface is used (see
> [https://github.com/apache/camel/blob/main/core/camel-api/src/main/java/org/apache/camel/converter/TypeConvertible.java#L101-L110)]
>
> Problem is that `DefaultDataSet` implements `DataSet`, which extends `Record`.
>
> Therefore based on the order of converters in the cache (map), "random"
> converter is selected and used. Unfortunately one of these selection might
> cause a problem.
>
> I was trying to run test `fixedHeaderAndTrailerShouldSucceed` in
> camel-quarkus from branch `camel-main`.
> [code|https://github.com/apache/camel-quarkus/blob/camel-main/integration-tests/flatpack/src/test/java/org/apache/camel/quarkus/component/flatpack/it/FlatpackTest.java#L133]
> # In case that converter `DataSet` -> `Map` is selected, the test
> {*}succeeds{*}.
> # If `Record` -> `Map` is selected, test {*}fails{*}.
>
> I'd suggest to add a logic, which takes into consideration the fact, that
> some of the matched interfaces are more general and some are more specific
> (in this case, `DataSet` conversion should have higher priority).
> There might be other approaches, but ^^ this one makes sense and should be
> implementable (I'm not sure about possible performance affect)
>
> (another way might be defining order of the converters, `DataSet` is always
> tried before `Record` in Flatpack, performance should be better)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19837) Converters - unpredictable behavior linked to type hierarchy (flatpack)
[
https://issues.apache.org/jira/browse/CAMEL-19837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762121#comment-17762121
]
Jiri Ondrusek commented on CAMEL-19837:
---
FYI ^ [~orpiske]
> Converters - unpredictable behavior linked to type hierarchy (flatpack)
> ---
>
> Key: CAMEL-19837
> URL: https://issues.apache.org/jira/browse/CAMEL-19837
> Project: Camel
> Issue Type: Bug
> Components: core
>Affects Versions: 4.x
>Reporter: Jiri Ondrusek
>Priority: Major
>
> Consequence of
> [https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
>
> Camel-flatpack registers 2 converters:
> # from net.sf.flatpack.DataSet to Map
> # from net.sf.flatpack.Record to Map
> Problematic case: If data for conversion is instance of
> net.sf.flatpack.DefaultDataSet
>
> Direct conversion is not possible (there is no DefaultDataSet -> Map
> converter)
> therefore matching via interface is used (see
> [https://github.com/apache/camel/blob/main/core/camel-api/src/main/java/org/apache/camel/converter/TypeConvertible.java#L101-L110)]
>
> Problem is that `DefaultDataSet` implements `DataSet`, which extends `Record`.
>
> Therefore based on the order of converters in the cache (map), "random"
> converter is selected and used. Unfortunately one of these selection might
> cause a problem.
>
> I was trying to run test `fixedHeaderAndTrailerShouldSucceed` in
> camel-quarkus from branch `camel-main`.
> [code|https://github.com/apache/camel-quarkus/blob/camel-main/integration-tests/flatpack/src/test/java/org/apache/camel/quarkus/component/flatpack/it/FlatpackTest.java#L133]
> # In case that converter `DataSet` -> `Map` is selected, the test
> {*}succeeds{*}.
> # If `Record` -> `Map` is selected, test {*}fails{*}.
>
> I'd suggest to add a logic, which takes into consideration the fact, that
> some of the matched interfaces are more general and some are more specific
> (in this case, `DataSet` conversion should have higher priority).
> There might be other approaches, but ^^ this one makes sense and should be
> implementable (I'm not sure about possible performance affect)
>
> (another way might be defining order of the converters, `DataSet` is always
> tried before `Record` in Flatpack, performance should be better)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19837) Converters - unpredictable behavior linked to type hierarchy (flatpack)
Jiri Ondrusek created CAMEL-19837:
-
Summary: Converters - unpredictable behavior linked to type
hierarchy (flatpack)
Key: CAMEL-19837
URL: https://issues.apache.org/jira/browse/CAMEL-19837
Project: Camel
Issue Type: Bug
Components: core
Affects Versions: 4.x
Reporter: Jiri Ondrusek
Consequence of
[https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
Camel-flatpack registers 2 converters:
# from net.sf.flatpack.DataSet to Map
# from net.sf.flatpack.Record to Map
Problematic case: If data for conversion is instance of
net.sf.flatpack.DefaultDataSet
Direct conversion is not possible (there is no DefaultDataSet -> Map converter)
therefore matching via interface is used (see
[https://github.com/apache/camel/blob/main/core/camel-api/src/main/java/org/apache/camel/converter/TypeConvertible.java#L101-L110)]
Problem is that `DefaultDataSet` implements `DataSet`, which extends `Record`.
Therefore based on the order of converters in the cache (map), "random"
converter is selected and used. Unfortunately one of these selection might
cause a problem.
I was trying to run test `fixedHeaderAndTrailerShouldSucceed` in camel-quarkus
from branch `camel-main`.
[code|https://github.com/apache/camel-quarkus/blob/camel-main/integration-tests/flatpack/src/test/java/org/apache/camel/quarkus/component/flatpack/it/FlatpackTest.java#L133]
# In case that converter `DataSet` -> `Map` is selected, the test
{*}succeeds{*}.
# If `Record` -> `Map` is selected, test {*}fails{*}.
I'd suggest to add a logic, which takes into consideration the fact, that some
of the matched interfaces are more general and some are more specific (in this
case, `DataSet` conversion should have higher priority).
There might be other approaches, but ^^ this one makes sense and should be
implementable (I'm not sure about possible performance affect)
(another way might be defining order of the converters, `DataSet` is always
tried before `Record` in Flatpack, performance should be better)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19828) camel-twilio: conversion to PhoneNumber, .. fails after recent general converter change
[
https://issues.apache.org/jira/browse/CAMEL-19828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761840#comment-17761840
]
Jiri Ondrusek commented on CAMEL-19828:
---
I already test this code and it works. I see it as a workaround, because it can
not convert to a Sip.
I can create a PR with it.
Perhaps some better solution can be implemented (in twilio comp) to allow
conversion to i.e Sip. I can try to propose something later (as this will be a
very small severity)
> camel-twilio: conversion to PhoneNumber, .. fails after recent general
> converter change
> ---
>
> Key: CAMEL-19828
> URL: https://issues.apache.org/jira/browse/CAMEL-19828
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-twilio
>Affects Versions: 4.x
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> When adopting the latest Camel into camel-quarkus I noticed an error.
> {code:java}
> NoTypeConversionAvailableException: No type converter available to convert
> from type: java.lang.String to the required type: com.twilio.type.Endpoint
> {code}
> Problem is caused by this change:
> [https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
> As you can see
> [here|https://github.com/apache/camel/blob/main/components/camel-twilio/src/main/java/org/apache/camel/component/twilio/TwilioConverter.java],
> 2 converters are registered (i.e. String -> PhoneNumber). Unfortunately the
> Twilio API uses common interface `com.twilio.type.Endpoint`. See this
> [line|https://github.com/apache/camel/blob/main/components/camel-twilio/src/generated/java/org/apache/camel/component/twilio/CallEndpointConfiguration.java#L27].
> Therefore the mechanism for selection converters is not able to find
> converter `String -> Endpoint`.
> The behavior could be simply tested by following code added into
> `TwilioEndpointTest`:
> {code:java}
> te = context.getEndpoint(
>
> "twilio://call/create?from=RAW(+15005550006)=RAW(+14108675310)=http://demo.twilio.com/docs/voice.xml;,
> TwilioEndpoint.class);
> Assertions.assertTrue(te.getConfiguration() instanceof
> CallEndpointConfiguration);
> CallEndpointConfiguration cee = (CallEndpointConfiguration)
> te.getConfiguration();
> Assertions.assertEquals("+15005550006", cee.getFrom().getEndpoint());
> Assertions.assertEquals("+14108675310", cee.getTo().getEndpoint());
> {code}
> I'm not sure how it was possible, but the test wold succeed before the change
> introduced by e4007f2b1dfc982e5ea6a45427cbec8835ea58a5.
> I think that the conversion before the change might not be correct in this
> twilio case (the conversion was probably possible because of the fallback
> conversion and was depending on the order of the registered converters - I
> don't see a way how to decide which conversion should be used `PhoneNumber`
> or `Sip` from the registered converters from the link above)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19828) camel-twilio: conversion to PhoneNumber, .. fails after recent general converter change
[
https://issues.apache.org/jira/browse/CAMEL-19828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761840#comment-17761840
]
Jiri Ondrusek edited comment on CAMEL-19828 at 9/4/23 2:13 PM:
---
I already tested this code and it works. I see it as a workaround, because it
can not convert to a Sip.
I can create a PR with it.
Perhaps some better solution can be implemented (in twilio comp) to allow
conversion to i.e Sip. I can try to propose something later (as this will be a
very small severity)
was (Author: jondruse):
I already test this code and it works. I see it as a workaround, because it can
not convert to a Sip.
I can create a PR with it.
Perhaps some better solution can be implemented (in twilio comp) to allow
conversion to i.e Sip. I can try to propose something later (as this will be a
very small severity)
> camel-twilio: conversion to PhoneNumber, .. fails after recent general
> converter change
> ---
>
> Key: CAMEL-19828
> URL: https://issues.apache.org/jira/browse/CAMEL-19828
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-twilio
>Affects Versions: 4.x
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> When adopting the latest Camel into camel-quarkus I noticed an error.
> {code:java}
> NoTypeConversionAvailableException: No type converter available to convert
> from type: java.lang.String to the required type: com.twilio.type.Endpoint
> {code}
> Problem is caused by this change:
> [https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
> As you can see
> [here|https://github.com/apache/camel/blob/main/components/camel-twilio/src/main/java/org/apache/camel/component/twilio/TwilioConverter.java],
> 2 converters are registered (i.e. String -> PhoneNumber). Unfortunately the
> Twilio API uses common interface `com.twilio.type.Endpoint`. See this
> [line|https://github.com/apache/camel/blob/main/components/camel-twilio/src/generated/java/org/apache/camel/component/twilio/CallEndpointConfiguration.java#L27].
> Therefore the mechanism for selection converters is not able to find
> converter `String -> Endpoint`.
> The behavior could be simply tested by following code added into
> `TwilioEndpointTest`:
> {code:java}
> te = context.getEndpoint(
>
> "twilio://call/create?from=RAW(+15005550006)=RAW(+14108675310)=http://demo.twilio.com/docs/voice.xml;,
> TwilioEndpoint.class);
> Assertions.assertTrue(te.getConfiguration() instanceof
> CallEndpointConfiguration);
> CallEndpointConfiguration cee = (CallEndpointConfiguration)
> te.getConfiguration();
> Assertions.assertEquals("+15005550006", cee.getFrom().getEndpoint());
> Assertions.assertEquals("+14108675310", cee.getTo().getEndpoint());
> {code}
> I'm not sure how it was possible, but the test wold succeed before the change
> introduced by e4007f2b1dfc982e5ea6a45427cbec8835ea58a5.
> I think that the conversion before the change might not be correct in this
> twilio case (the conversion was probably possible because of the fallback
> conversion and was depending on the order of the registered converters - I
> don't see a way how to decide which conversion should be used `PhoneNumber`
> or `Sip` from the registered converters from the link above)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-19828) camel-twilio: conversion to PhoneNumber, .. fails after recent general converter change
[
https://issues.apache.org/jira/browse/CAMEL-19828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Ondrusek reassigned CAMEL-19828:
-
Assignee: Jiri Ondrusek
> camel-twilio: conversion to PhoneNumber, .. fails after recent general
> converter change
> ---
>
> Key: CAMEL-19828
> URL: https://issues.apache.org/jira/browse/CAMEL-19828
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-twilio
>Affects Versions: 4.x
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> When adopting the latest Camel into camel-quarkus I noticed an error.
> {code:java}
> NoTypeConversionAvailableException: No type converter available to convert
> from type: java.lang.String to the required type: com.twilio.type.Endpoint
> {code}
> Problem is caused by this change:
> [https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
> As you can see
> [here|https://github.com/apache/camel/blob/main/components/camel-twilio/src/main/java/org/apache/camel/component/twilio/TwilioConverter.java],
> 2 converters are registered (i.e. String -> PhoneNumber). Unfortunately the
> Twilio API uses common interface `com.twilio.type.Endpoint`. See this
> [line|https://github.com/apache/camel/blob/main/components/camel-twilio/src/generated/java/org/apache/camel/component/twilio/CallEndpointConfiguration.java#L27].
> Therefore the mechanism for selection converters is not able to find
> converter `String -> Endpoint`.
> The behavior could be simply tested by following code added into
> `TwilioEndpointTest`:
> {code:java}
> te = context.getEndpoint(
>
> "twilio://call/create?from=RAW(+15005550006)=RAW(+14108675310)=http://demo.twilio.com/docs/voice.xml;,
> TwilioEndpoint.class);
> Assertions.assertTrue(te.getConfiguration() instanceof
> CallEndpointConfiguration);
> CallEndpointConfiguration cee = (CallEndpointConfiguration)
> te.getConfiguration();
> Assertions.assertEquals("+15005550006", cee.getFrom().getEndpoint());
> Assertions.assertEquals("+14108675310", cee.getTo().getEndpoint());
> {code}
> I'm not sure how it was possible, but the test wold succeed before the change
> introduced by e4007f2b1dfc982e5ea6a45427cbec8835ea58a5.
> I think that the conversion before the change might not be correct in this
> twilio case (the conversion was probably possible because of the fallback
> conversion and was depending on the order of the registered converters - I
> don't see a way how to decide which conversion should be used `PhoneNumber`
> or `Sip` from the registered converters from the link above)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19828) camel-twilio: conversion to PhoneNumber, .. fails after recent general converter change
[
https://issues.apache.org/jira/browse/CAMEL-19828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761837#comment-17761837
]
Jiri Ondrusek commented on CAMEL-19828:
---
Sure, thanks for the tip!
> camel-twilio: conversion to PhoneNumber, .. fails after recent general
> converter change
> ---
>
> Key: CAMEL-19828
> URL: https://issues.apache.org/jira/browse/CAMEL-19828
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-twilio
>Affects Versions: 4.x
>Reporter: Jiri Ondrusek
>Priority: Major
>
> When adopting the latest Camel into camel-quarkus I noticed an error.
> {code:java}
> NoTypeConversionAvailableException: No type converter available to convert
> from type: java.lang.String to the required type: com.twilio.type.Endpoint
> {code}
> Problem is caused by this change:
> [https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
> As you can see
> [here|https://github.com/apache/camel/blob/main/components/camel-twilio/src/main/java/org/apache/camel/component/twilio/TwilioConverter.java],
> 2 converters are registered (i.e. String -> PhoneNumber). Unfortunately the
> Twilio API uses common interface `com.twilio.type.Endpoint`. See this
> [line|https://github.com/apache/camel/blob/main/components/camel-twilio/src/generated/java/org/apache/camel/component/twilio/CallEndpointConfiguration.java#L27].
> Therefore the mechanism for selection converters is not able to find
> converter `String -> Endpoint`.
> The behavior could be simply tested by following code added into
> `TwilioEndpointTest`:
> {code:java}
> te = context.getEndpoint(
>
> "twilio://call/create?from=RAW(+15005550006)=RAW(+14108675310)=http://demo.twilio.com/docs/voice.xml;,
> TwilioEndpoint.class);
> Assertions.assertTrue(te.getConfiguration() instanceof
> CallEndpointConfiguration);
> CallEndpointConfiguration cee = (CallEndpointConfiguration)
> te.getConfiguration();
> Assertions.assertEquals("+15005550006", cee.getFrom().getEndpoint());
> Assertions.assertEquals("+14108675310", cee.getTo().getEndpoint());
> {code}
> I'm not sure how it was possible, but the test wold succeed before the change
> introduced by e4007f2b1dfc982e5ea6a45427cbec8835ea58a5.
> I think that the conversion before the change might not be correct in this
> twilio case (the conversion was probably possible because of the fallback
> conversion and was depending on the order of the registered converters - I
> don't see a way how to decide which conversion should be used `PhoneNumber`
> or `Sip` from the registered converters from the link above)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-19828) camel-twilio: conversion to PhoneNumber, .. fails after recent general converter change
[
https://issues.apache.org/jira/browse/CAMEL-19828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Ondrusek updated CAMEL-19828:
--
Affects Version/s: 4.x
(was: 4.1.0)
> camel-twilio: conversion to PhoneNumber, .. fails after recent general
> converter change
> ---
>
> Key: CAMEL-19828
> URL: https://issues.apache.org/jira/browse/CAMEL-19828
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-twilio
>Affects Versions: 4.x
>Reporter: Jiri Ondrusek
>Priority: Major
>
> When adopting the latest Camel into camel-quarkus I noticed an error.
> {code:java}
> NoTypeConversionAvailableException: No type converter available to convert
> from type: java.lang.String to the required type: com.twilio.type.Endpoint
> {code}
> Problem is caused by this change:
> [https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
> As you can see
> [here|https://github.com/apache/camel/blob/main/components/camel-twilio/src/main/java/org/apache/camel/component/twilio/TwilioConverter.java],
> 2 converters are registered (i.e. String -> PhoneNumber). Unfortunately the
> Twilio API uses common interface `com.twilio.type.Endpoint`. See this
> [line|https://github.com/apache/camel/blob/main/components/camel-twilio/src/generated/java/org/apache/camel/component/twilio/CallEndpointConfiguration.java#L27].
> Therefore the mechanism for selection converters is not able to find
> converter `String -> Endpoint`.
> The behavior could be simply tested by following code added into
> `TwilioEndpointTest`:
> {code:java}
> te = context.getEndpoint(
>
> "twilio://call/create?from=RAW(+15005550006)=RAW(+14108675310)=http://demo.twilio.com/docs/voice.xml;,
> TwilioEndpoint.class);
> Assertions.assertTrue(te.getConfiguration() instanceof
> CallEndpointConfiguration);
> CallEndpointConfiguration cee = (CallEndpointConfiguration)
> te.getConfiguration();
> Assertions.assertEquals("+15005550006", cee.getFrom().getEndpoint());
> Assertions.assertEquals("+14108675310", cee.getTo().getEndpoint());
> {code}
> I'm not sure how it was possible, but the test wold succeed before the change
> introduced by e4007f2b1dfc982e5ea6a45427cbec8835ea58a5.
> I think that the conversion before the change might not be correct in this
> twilio case (the conversion was probably possible because of the fallback
> conversion and was depending on the order of the registered converters - I
> don't see a way how to decide which conversion should be used `PhoneNumber`
> or `Sip` from the registered converters from the link above)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19828) camel-twilio: conversion to PhoneNumber, .. fails after recent general converter change
[
https://issues.apache.org/jira/browse/CAMEL-19828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761833#comment-17761833
]
Jiri Ondrusek commented on CAMEL-19828:
---
FYI [~orpiske]
> camel-twilio: conversion to PhoneNumber, .. fails after recent general
> converter change
> ---
>
> Key: CAMEL-19828
> URL: https://issues.apache.org/jira/browse/CAMEL-19828
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-twilio
>Affects Versions: 4.1.0
>Reporter: Jiri Ondrusek
>Priority: Major
>
> When adopting the latest Camel into camel-quarkus I noticed an error.
> {code:java}
> NoTypeConversionAvailableException: No type converter available to convert
> from type: java.lang.String to the required type: com.twilio.type.Endpoint
> {code}
> Problem is caused by this change:
> [https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
> As you can see
> [here|https://github.com/apache/camel/blob/main/components/camel-twilio/src/main/java/org/apache/camel/component/twilio/TwilioConverter.java],
> 2 converters are registered (i.e. String -> PhoneNumber). Unfortunately the
> Twilio API uses common interface `com.twilio.type.Endpoint`. See this
> [line|https://github.com/apache/camel/blob/main/components/camel-twilio/src/generated/java/org/apache/camel/component/twilio/CallEndpointConfiguration.java#L27].
> Therefore the mechanism for selection converters is not able to find
> converter `String -> Endpoint`.
> The behavior could be simply tested by following code added into
> `TwilioEndpointTest`:
> {code:java}
> te = context.getEndpoint(
>
> "twilio://call/create?from=RAW(+15005550006)=RAW(+14108675310)=http://demo.twilio.com/docs/voice.xml;,
> TwilioEndpoint.class);
> Assertions.assertTrue(te.getConfiguration() instanceof
> CallEndpointConfiguration);
> CallEndpointConfiguration cee = (CallEndpointConfiguration)
> te.getConfiguration();
> Assertions.assertEquals("+15005550006", cee.getFrom().getEndpoint());
> Assertions.assertEquals("+14108675310", cee.getTo().getEndpoint());
> {code}
> I'm not sure how it was possible, but the test wold succeed before the change
> introduced by e4007f2b1dfc982e5ea6a45427cbec8835ea58a5.
> I think that the conversion before the change might not be correct in this
> twilio case (the conversion was probably possible because of the fallback
> conversion and was depending on the order of the registered converters - I
> don't see a way how to decide which conversion should be used `PhoneNumber`
> or `Sip` from the registered converters from the link above)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19828) camel-twilio: conversion to PhoneNumber, .. fails after recent general converter change
Jiri Ondrusek created CAMEL-19828:
-
Summary: camel-twilio: conversion to PhoneNumber, .. fails after
recent general converter change
Key: CAMEL-19828
URL: https://issues.apache.org/jira/browse/CAMEL-19828
Project: Camel
Issue Type: Bug
Components: camel-core, camel-twilio
Affects Versions: 4.1.0
Reporter: Jiri Ondrusek
When adopting the latest Camel into camel-quarkus I noticed an error.
{code:java}
NoTypeConversionAvailableException: No type converter available to convert from
type: java.lang.String to the required type: com.twilio.type.Endpoint
{code}
Problem is caused by this change:
[https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
As you can see
[here|https://github.com/apache/camel/blob/main/components/camel-twilio/src/main/java/org/apache/camel/component/twilio/TwilioConverter.java],
2 converters are registered (i.e. String -> PhoneNumber). Unfortunately the
Twilio API uses common interface `com.twilio.type.Endpoint`. See this
[line|https://github.com/apache/camel/blob/main/components/camel-twilio/src/generated/java/org/apache/camel/component/twilio/CallEndpointConfiguration.java#L27].
Therefore the mechanism for selection converters is not able to find converter
`String -> Endpoint`.
The behavior could be simply tested by following code added into
`TwilioEndpointTest`:
{code:java}
te = context.getEndpoint(
"twilio://call/create?from=RAW(+15005550006)=RAW(+14108675310)=http://demo.twilio.com/docs/voice.xml;,
TwilioEndpoint.class);
Assertions.assertTrue(te.getConfiguration() instanceof
CallEndpointConfiguration);
CallEndpointConfiguration cee = (CallEndpointConfiguration)
te.getConfiguration();
Assertions.assertEquals("+15005550006", cee.getFrom().getEndpoint());
Assertions.assertEquals("+14108675310", cee.getTo().getEndpoint());
{code}
I'm not sure how it was possible, but the test wold succeed before the change
introduced by e4007f2b1dfc982e5ea6a45427cbec8835ea58a5.
I think that the conversion before the change might not be correct in this
twilio case (the conversion was probably possible because of the fallback
conversion and was depending on the order of the registered converters - I
don't see a way how to decide which conversion should be used `PhoneNumber` or
`Sip` from the registered converters from the link above)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19566) Camel micrometer documentation shows wrong parameter value name for summary
Jiri Ondrusek created CAMEL-19566: - Summary: Camel micrometer documentation shows wrong parameter value name for summary Key: CAMEL-19566 URL: https://issues.apache.org/jira/browse/CAMEL-19566 Project: Camel Issue Type: Bug Components: camel-micrometer Affects Versions: 4.0-RC1 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek As you can see [here|https://github.com/apache/camel/blob/main/components/camel-micrometer/src/main/java/org/apache/camel/component/micrometer/MicrometerUtils.java#L40] allowed values for metrics type are 'counter', 'summary' and 'timer'. Values in the [doc|https://camel.apache.org/components/3.20.x/micrometer-component.html#_endpoint_path_option_metricsType] are * counter * distribution_summary * timer Distribution_summary should be changed to summary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-19364) Rest-openapi: lookup mechanism does not work after changes from Camel-18963
[
https://issues.apache.org/jira/browse/CAMEL-19364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Ondrusek reassigned CAMEL-19364:
-
Assignee: Jiri Ondrusek
> Rest-openapi: lookup mechanism does not work after changes from Camel-18963
> ---
>
> Key: CAMEL-19364
> URL: https://issues.apache.org/jira/browse/CAMEL-19364
> Project: Camel
> Issue Type: Bug
> Components: camel-rest-openapi
>Affects Versions: 4.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> I was trying to synchronize camel-quarkus with current Camel from `main`
> branch.
> I noticed failures related to fix
> [https://github.com/apache/camel/commit/e2ad230d86fcbbc1e3c4ad5a9daf01aa3127eb42]
> in the Camel-rest-openapi component.
> According to the doc, the url in component can be specified i.g.
> "classpath:...", "bean:...". At least these 2 options does not work.
> It can be verified by a simple test:
> {code:java}
> @Test
> public void testClasspath() throws Exception{
> Producer p =
> context().getEndpoint("rest-openapi:addPet?specificationUri=classpath:openapi.json").createProducer();
> Assertions.assertNotNull(p);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19364) Rest-openapi: lookup mechanism does not work after changes from Camel-18963
Jiri Ondrusek created CAMEL-19364:
-
Summary: Rest-openapi: lookup mechanism does not work after
changes from Camel-18963
Key: CAMEL-19364
URL: https://issues.apache.org/jira/browse/CAMEL-19364
Project: Camel
Issue Type: Bug
Components: camel-rest-openapi
Affects Versions: 4.0
Reporter: Jiri Ondrusek
I was trying to synchronize camel-quarkus with current Camel from `main` branch.
I noticed failures related to fix
[https://github.com/apache/camel/commit/e2ad230d86fcbbc1e3c4ad5a9daf01aa3127eb42]
in the Camel-rest-openapi component.
According to the doc, the url in component can be specified i.g.
"classpath:...", "bean:...". At least these 2 options does not work.
It can be verified by a simple test:
{code:java}
@Test
public void testClasspath() throws Exception{
Producer p =
context().getEndpoint("rest-openapi:addPet?specificationUri=classpath:openapi.json").createProducer();
Assertions.assertNotNull(p);
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19364) Rest-openapi: lookup mechanism does not work after changes from Camel-18963
[
https://issues.apache.org/jira/browse/CAMEL-19364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723447#comment-17723447
]
Jiri Ondrusek commented on CAMEL-19364:
---
[~klease78] ^ FYI
> Rest-openapi: lookup mechanism does not work after changes from Camel-18963
> ---
>
> Key: CAMEL-19364
> URL: https://issues.apache.org/jira/browse/CAMEL-19364
> Project: Camel
> Issue Type: Bug
> Components: camel-rest-openapi
>Affects Versions: 4.0
>Reporter: Jiri Ondrusek
>Priority: Major
>
> I was trying to synchronize camel-quarkus with current Camel from `main`
> branch.
> I noticed failures related to fix
> [https://github.com/apache/camel/commit/e2ad230d86fcbbc1e3c4ad5a9daf01aa3127eb42]
> in the Camel-rest-openapi component.
> According to the doc, the url in component can be specified i.g.
> "classpath:...", "bean:...". At least these 2 options does not work.
> It can be verified by a simple test:
> {code:java}
> @Test
> public void testClasspath() throws Exception{
> Producer p =
> context().getEndpoint("rest-openapi:addPet?specificationUri=classpath:openapi.json").createProducer();
> Assertions.assertNotNull(p);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-19298) Snmp: version 3 is not supported for several actions for the component
[ https://issues.apache.org/jira/browse/CAMEL-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-19298: -- Affects Version/s: 3.18.6 (was: 3.18.7) > Snmp: version 3 is not supported for several actions for the component > -- > > Key: CAMEL-19298 > URL: https://issues.apache.org/jira/browse/CAMEL-19298 > Project: Camel > Issue Type: Bug > Components: camel-snmp >Affects Versions: 3.18.6, 4.0-M3 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 4.0-RC1, 4.0 > > > In snmp component, users can use versions 0.1 and 2 (using values from the > [documentation|https://camel.apache.org/components/3.20.x/snmp-component.html#_endpoint_query_option_snmpVersion]). > Version 3 is not supported for several actions (like provide PDU or get next) > To support this version on component, different PDU class has to be used. > (for example here > https://github.com/apache/camel/blob/main/components/camel-snmp/src/main/java/org/apache/camel/component/snmp/SnmpProducer.java#L85) > There is a test coverage (creation in progress) in camel-quarkus, which could > be used as a reproducer simulating missing scenarios - > https://github.com/apache/camel-quarkus/issues/4843 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19298) Snmp: version 3 is not supported for several actions for the component
[ https://issues.apache.org/jira/browse/CAMEL-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-19298: -- Description: In snmp component, users can use versions 0.1 and 2 (using values from the [documentation|https://camel.apache.org/components/3.20.x/snmp-component.html#_endpoint_query_option_snmpVersion]). Version 3 is not supported for several actions (like provide PDU or get next) To support this version on component, different PDU class has to be used. (for example here https://github.com/apache/camel/blob/main/components/camel-snmp/src/main/java/org/apache/camel/component/snmp/SnmpProducer.java#L85) There is a test coverage (creation in progress) in camel-quarkus, which could be used as a reproducer simulating missing scenarios - https://github.com/apache/camel-quarkus/issues/4843 was: In snmp component, users can use versions 0.1 and 2 (using values from the [documentation|https://camel.apache.org/components/3.20.x/snmp-component.html#_endpoint_query_option_snmpVersion]). Version 3 is not supported for several actions (like provide PDU or get next) To support this version on component, different PDU class has to be used. (for example here https://github.com/apache/camel/blob/main/components/camel-snmp/src/main/java/org/apache/camel/component/snmp/SnmpProducer.java#L85) There is a test coverage (creation in progress) in camel-quarkus, which could be used as a reproducer simulating missing scenarios - https://github.com/apache/camel-quarkus/issues/4797 > Snmp: version 3 is not supported for several actions for the component > -- > > Key: CAMEL-19298 > URL: https://issues.apache.org/jira/browse/CAMEL-19298 > Project: Camel > Issue Type: Bug > Components: camel-snmp >Affects Versions: 3.18.7, 4.0-M3 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > > In snmp component, users can use versions 0.1 and 2 (using values from the > [documentation|https://camel.apache.org/components/3.20.x/snmp-component.html#_endpoint_query_option_snmpVersion]). > Version 3 is not supported for several actions (like provide PDU or get next) > To support this version on component, different PDU class has to be used. > (for example here > https://github.com/apache/camel/blob/main/components/camel-snmp/src/main/java/org/apache/camel/component/snmp/SnmpProducer.java#L85) > There is a test coverage (creation in progress) in camel-quarkus, which could > be used as a reproducer simulating missing scenarios - > https://github.com/apache/camel-quarkus/issues/4843 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19298) Snmp: version 3 is not supported for several actions for the component
[ https://issues.apache.org/jira/browse/CAMEL-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-19298: -- Summary: Snmp: version 3 is not supported for several actions for the component (was: Snmp: version 3 is not supported for several action for the component) > Snmp: version 3 is not supported for several actions for the component > -- > > Key: CAMEL-19298 > URL: https://issues.apache.org/jira/browse/CAMEL-19298 > Project: Camel > Issue Type: Bug > Components: camel-snmp >Affects Versions: 3.18.7, 4.0-M3 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > > In snmp component, users can use versions 0.1 and 2 (using values from the > [documentation|https://camel.apache.org/components/3.20.x/snmp-component.html#_endpoint_query_option_snmpVersion]). > Version 3 is not supported for several actions (like provide PDU or get next) > To support this version on component, different PDU class has to be used. > (for example here > https://github.com/apache/camel/blob/main/components/camel-snmp/src/main/java/org/apache/camel/component/snmp/SnmpProducer.java#L85) > There is a test coverage (creation in progress) in camel-quarkus, which could > be used as a reproducer simulating missing scenarios - > https://github.com/apache/camel-quarkus/issues/4797 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19298) Snmp: version 3 is not supported for several action for the component
[ https://issues.apache.org/jira/browse/CAMEL-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-19298: -- Affects Version/s: 3.18.7 > Snmp: version 3 is not supported for several action for the component > - > > Key: CAMEL-19298 > URL: https://issues.apache.org/jira/browse/CAMEL-19298 > Project: Camel > Issue Type: Bug > Components: camel-snmp >Affects Versions: 3.18.7, 4.0-M3 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > > In snmp component, users can use versions 0.1 and 2 (using values from the > [documentation|https://camel.apache.org/components/3.20.x/snmp-component.html#_endpoint_query_option_snmpVersion]). > Version 3 is not supported for several actions (like provide PDU or get next) > To support this version on component, different PDU class has to be used. > (for example here > https://github.com/apache/camel/blob/main/components/camel-snmp/src/main/java/org/apache/camel/component/snmp/SnmpProducer.java#L85) > There is a test coverage (creation in progress) in camel-quarkus, which could > be used as a reproducer simulating missing scenarios - > https://github.com/apache/camel-quarkus/issues/4797 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19298) Snmp: version 3 is not supported for several action for the component
Jiri Ondrusek created CAMEL-19298: - Summary: Snmp: version 3 is not supported for several action for the component Key: CAMEL-19298 URL: https://issues.apache.org/jira/browse/CAMEL-19298 Project: Camel Issue Type: Bug Components: camel-snmp Affects Versions: 4.0-M3 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek In snmp component, users can use versions 0.1 and 2 (using values from the [documentation|https://camel.apache.org/components/3.20.x/snmp-component.html#_endpoint_query_option_snmpVersion]). Version 3 is not supported for several actions (like provide PDU or get next) To support this version on component, different PDU class has to be used. (for example here https://github.com/apache/camel/blob/main/components/camel-snmp/src/main/java/org/apache/camel/component/snmp/SnmpProducer.java#L85) There is a test coverage (creation in progress) in camel-quarkus, which could be used as a reproducer simulating missing scenarios - https://github.com/apache/camel-quarkus/issues/4797 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19184) Camel-http: Upgrade to http 5.x broke test case using httpContext
[
https://issues.apache.org/jira/browse/CAMEL-19184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703591#comment-17703591
]
Jiri Ondrusek commented on CAMEL-19184:
---
[~davsclaus] This might be a regression. (may be the priority should be higher)
( [~essobedo] FYI)
> Camel-http: Upgrade to http 5.x broke test case using httpContext
> -
>
> Key: CAMEL-19184
> URL: https://issues.apache.org/jira/browse/CAMEL-19184
> Project: Camel
> Issue Type: Bug
> Components: camel-http
>Affects Versions: 4.0-M3
>Reporter: Jiri Ondrusek
>Priority: Major
>
> During upgrading camel-quarkus to the current camel version I noticed a http
> test, which is failing.
> I did some investigation:
> * test case using basic auhentication with`httpContext` is not part of the
> camel test suite
> * test is failing on camel
> * when I reverted to the revision before upgrade of http component to 5.x,
> test worked
> Here is the commit with upgrade of http components to 5.x
> ([commit|https://github.com/apache/camel/commit/c33a140ce51aa9bc9a8205429b78e00a39041967])
> Here is the added before the upgrade - test {*}succeeds{*}.
> ([branch|https://github.com/JiriOndrusek/camel/commits/http-cache-works-before-update-of-http])
> Here is the same test after upgrade of http components - test {*}fails{*}.
> ([branch|https://github.com/JiriOndrusek/camel/commits/http-cache-test-fails-after-upgrade-of-http])
> I'd suggest to add this test to the camel test suite a fix the behavior of
> http component (it is possible that the tested scenario has to be configured
> differently after upgrade. If so, migration guide should be updated)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19184) Camel-http: Upgrade to http 5.x broke test case using httpContext
Jiri Ondrusek created CAMEL-19184:
-
Summary: Camel-http: Upgrade to http 5.x broke test case using
httpContext
Key: CAMEL-19184
URL: https://issues.apache.org/jira/browse/CAMEL-19184
Project: Camel
Issue Type: Bug
Components: camel-http
Affects Versions: 4.0-M3
Reporter: Jiri Ondrusek
During upgrading camel-quarkus to the current camel version I noticed a http
test, which is failing.
I did some investigation:
* test case using basic auhentication with`httpContext` is not part of the
camel test suite
* test is failing on camel
* when I reverted to the revision before upgrade of http component to 5.x,
test worked
Here is the commit with upgrade of http components to 5.x
([commit|https://github.com/apache/camel/commit/c33a140ce51aa9bc9a8205429b78e00a39041967])
Here is the added before the upgrade - test {*}succeeds{*}.
([branch|https://github.com/JiriOndrusek/camel/commits/http-cache-works-before-update-of-http])
Here is the same test after upgrade of http components - test {*}fails{*}.
([branch|https://github.com/JiriOndrusek/camel/commits/http-cache-test-fails-after-upgrade-of-http])
I'd suggest to add this test to the camel test suite a fix the behavior of http
component (it is possible that the tested scenario has to be configured
differently after upgrade. If so, migration guide should be updated)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19113) Platform-http-vertx: consume with comma separated does not work
Jiri Ondrusek created CAMEL-19113:
-
Summary: Platform-http-vertx: consume with comma separated does
not work
Key: CAMEL-19113
URL: https://issues.apache.org/jira/browse/CAMEL-19113
Project: Camel
Issue Type: Bug
Components: camel-platform-http-vertx
Affects Versions: 3.18.5, 4.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
When rest DSL defines following endpoint
{code:java}
rest().get("/test")
.consumes("application/json,application/xml")
.produces("application/json,application/xml") {code}
requests with `content-type` header `application/json` or `application/xml`
should be accepted. (works on camel-platform-htpp)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19047) CamelTestSupport (junit5) - quarkus and springboot checks are not executed with ContextPerClass
Jiri Ondrusek created CAMEL-19047: - Summary: CamelTestSupport (junit5) - quarkus and springboot checks are not executed with ContextPerClass Key: CAMEL-19047 URL: https://issues.apache.org/jira/browse/CAMEL-19047 Project: Camel Issue Type: Bug Components: camel-test Affects Versions: 4.0-M1 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek There is a code in `CamelTestSupport` which verifies whether the right test parent is used in Quarkus or Spring-boot ([code|https://github.com/apache/camel/blob/main/components/camel-test/camel-test-junit5/src/main/java/org/apache/camel/test/junit5/CamelTestSupport.java#L373-L374]). These checks should be move above the `if` condition, to be called even if `Lifecycle.PER_CLASS` is used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18968) Camel-aws2-sqs - Queue url might stay empty for the delayed queue.
Jiri Ondrusek created CAMEL-18968: - Summary: Camel-aws2-sqs - Queue url might stay empty for the delayed queue. Key: CAMEL-18968 URL: https://issues.apache.org/jira/browse/CAMEL-18968 Project: Camel Issue Type: Bug Components: camel-aws2 Affects Versions: 3.20.1 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek During investigation of [https://github.com/apache/camel-quarkus/issues/4389] I found that aws2-sqs producer is not able to send messages to the queueu which was created as delayed. Queue url should be initialized during the endpoint initialization phase. If queue does not exist in that time, the url stays empty for the whole life of the endpoint. Therefore majority of actions would fail. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18437) Camel-bigquery: There is a difference in types between @name and ${name}
[
https://issues.apache.org/jira/browse/CAMEL-18437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675608#comment-17675608
]
Jiri Ondrusek commented on CAMEL-18437:
---
I started working on this issue, but I came to conclusion, that it cannot be
changed in such way. Example follows.
*Fix works in some cases like following one:*
User would like to use a sql query {code} insert into A(id, data) values(${id},
${data}) {code}.
Following header are send in the exchange:
{code}
exchange.getMessage().setHeader("id", 1);
exchange.getMessage().setHeader("data", "test");
{code}
The result without the fix is *insert into A(id, data) values(1, test)*
With the fix the result is OK *insert into A(id, data) values(1, 'test')*
*But fix breaks different cases*:
In case that sql is
{code}insert into A(id, data) values($values) {code}
with values {code}exchange.getMessage().setHeader("values", "1,2");{code}
The result would be (with fix) *insert into A(id, data) values('1,2')*, which
is wrong.
I'd say to keep the behavior as it is. What do you think [~davsclaus]
> Camel-bigquery: There is a difference in types between @name and ${name}
>
>
> Key: CAMEL-18437
> URL: https://issues.apache.org/jira/browse/CAMEL-18437
> Project: Camel
> Issue Type: Bug
> Components: camel-google-bigquery
>Affects Versions: 3.19.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
> Fix For: 3.21.0
>
>
> I noticed a undefined behavior when expanding coverage of google-bigquery in
> camel-quarkus ([ticket|https://github.com/apache/camel-quarkus/issues/3949]).
>
> Here is a relevant chapter from the [documentation|#_uri_format].]
>
> {quote} * parameters in form ${name} are extracted from message headers and
> formed the translated query
> * parameters in form @name are extracted from body or message headers and
> sent to Google Bigquery{quote}
> From my PoV is that in case of parameters in the header, it should not
> matter, whether _@name_ or _${name}_ is used.
> The behavior seems to be more complicated:
> * In case of _@name_ pattern, value types are dynamically resolved (see
> https://issues.apache.org/jira/browse/CAMEL-18382 for more details)
> * In case of {_}${name}{_}, value is inserted into the sql without any
> modification. Which behaves like "undefined".
> # If header value is an integer (like 4), sql is translated into {_}...
> VALUES (4) ...{_}, so it is interpreted as integer.
> # If header value is string with number inside (like "4"), sql is translated
> into {_}... VALUES (4) ...{_}, so it is interpreted as integer.
> # If the header is string (like "s4"), sql is translated into {_}... VALUES
> (s4) ...{_}, and the execution fails.
> It would make sense that the behavior of _@name_ and _${name}_ is the same
> and mainly the case 3 does not cause any failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18878) Autowiring on endpoint works even if is disabled on component
Jiri Ondrusek created CAMEL-18878: - Summary: Autowiring on endpoint works even if is disabled on component Key: CAMEL-18878 URL: https://issues.apache.org/jira/browse/CAMEL-18878 Project: Camel Issue Type: Bug Affects Versions: 3.20.1 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek Simi9lar to https://issues.apache.org/jira/browse/CAMEL-16527 If autowireEnabled=false is set into the component, the DefaultEndpoint in method "doInit" ignores the fact, that autowiring might be disabled on component/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18868) Aws2-s3: CreateDownloadLink does not work with useDefaultCredentialsProvider
[
https://issues.apache.org/jira/browse/CAMEL-18868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Ondrusek updated CAMEL-18868:
--
Affects Version/s: (was: 3.20.2)
> Aws2-s3: CreateDownloadLink does not work with useDefaultCredentialsProvider
>
>
> Key: CAMEL-18868
> URL: https://issues.apache.org/jira/browse/CAMEL-18868
> Project: Camel
> Issue Type: Bug
> Components: camel-aws2
>Affects Versions: 3.20.1
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
>
> If component uses default credential provider
> (`useDefaultCredentialsProvider`), operation `createDownloadLink` fails with:
> {quote}Caused by: java.lang.NullPointerException: Access key ID cannot be
> blank.
> at software.amazon.awssdk.utils.Validate.notNull(Validate.java:119)
> at
> software.amazon.awssdk.auth.credentials.AwsBasicCredentials.(AwsBasicCredentials.java:66)
> at
> software.amazon.awssdk.auth.credentials.AwsBasicCredentials.(AwsBasicCredentials.java:58)
> at
> software.amazon.awssdk.auth.credentials.AwsBasicCredentials.create(AwsBasicCredentials.java:78)
> at
> org.apache.camel.component.aws2.s3.AWS2S3Producer.createDownloadLink(AWS2S3Producer.java:590)
> at
> org.apache.camel.component.aws2.s3.AWS2S3Producer.process(AWS2S3Producer.java:122){quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18868) Aws2-s3: CreateDownloadLink does not work with useDefaultCredentialsProvider
[
https://issues.apache.org/jira/browse/CAMEL-18868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Ondrusek updated CAMEL-18868:
--
Affects Version/s: 3.20.1
> Aws2-s3: CreateDownloadLink does not work with useDefaultCredentialsProvider
>
>
> Key: CAMEL-18868
> URL: https://issues.apache.org/jira/browse/CAMEL-18868
> Project: Camel
> Issue Type: Bug
> Components: camel-aws2
>Affects Versions: 3.20.1, 3.20.2
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
>
> If component uses default credential provider
> (`useDefaultCredentialsProvider`), operation `createDownloadLink` fails with:
> {quote}Caused by: java.lang.NullPointerException: Access key ID cannot be
> blank.
> at software.amazon.awssdk.utils.Validate.notNull(Validate.java:119)
> at
> software.amazon.awssdk.auth.credentials.AwsBasicCredentials.(AwsBasicCredentials.java:66)
> at
> software.amazon.awssdk.auth.credentials.AwsBasicCredentials.(AwsBasicCredentials.java:58)
> at
> software.amazon.awssdk.auth.credentials.AwsBasicCredentials.create(AwsBasicCredentials.java:78)
> at
> org.apache.camel.component.aws2.s3.AWS2S3Producer.createDownloadLink(AWS2S3Producer.java:590)
> at
> org.apache.camel.component.aws2.s3.AWS2S3Producer.process(AWS2S3Producer.java:122){quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18868) Aws2-s3: CreateDownloadLink does not work with useDefaultCredentialsProvider
Jiri Ondrusek created CAMEL-18868:
-
Summary: Aws2-s3: CreateDownloadLink does not work with
useDefaultCredentialsProvider
Key: CAMEL-18868
URL: https://issues.apache.org/jira/browse/CAMEL-18868
Project: Camel
Issue Type: Bug
Components: camel-aws2
Affects Versions: 3.20.2
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
If component uses default credential provider
(`useDefaultCredentialsProvider`), operation `createDownloadLink` fails with:
{quote}Caused by: java.lang.NullPointerException: Access key ID cannot be blank.
at software.amazon.awssdk.utils.Validate.notNull(Validate.java:119)
at
software.amazon.awssdk.auth.credentials.AwsBasicCredentials.(AwsBasicCredentials.java:66)
at
software.amazon.awssdk.auth.credentials.AwsBasicCredentials.(AwsBasicCredentials.java:58)
at
software.amazon.awssdk.auth.credentials.AwsBasicCredentials.create(AwsBasicCredentials.java:78)
at
org.apache.camel.component.aws2.s3.AWS2S3Producer.createDownloadLink(AWS2S3Producer.java:590)
at
org.apache.camel.component.aws2.s3.AWS2S3Producer.process(AWS2S3Producer.java:122){quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18819) hbase: different version of audience-annotations brought by zookeeper
[ https://issues.apache.org/jira/browse/CAMEL-18819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648028#comment-17648028 ] Jiri Ondrusek commented on CAMEL-18819: --- Sure, pr: https://github.com/apache/camel/pull/8908 > hbase: different version of audience-annotations brought by zookeeper > -- > > Key: CAMEL-18819 > URL: https://issues.apache.org/jira/browse/CAMEL-18819 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-hbase >Affects Versions: 3.20.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.20.0 > > > Dependency `audience-annotations` has version 0.13.0. > Zookeper brings version 0.5.0. It should be excluded. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18819) hbase: different version of audience-annotations brought by zookeeper
Jiri Ondrusek created CAMEL-18819: - Summary: hbase: different version of audience-annotations brought by zookeeper Key: CAMEL-18819 URL: https://issues.apache.org/jira/browse/CAMEL-18819 Project: Camel Issue Type: Bug Components: camel-hbase Affects Versions: 3.20.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek Dependency `audience-annotations` has version 0.13.0. Zookeper brings version 0.5.0. It should be excluded. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18680) Wrong initialization of KeyStoreParameters causes java.lang.IllegalArgumentException
Jiri Ondrusek created CAMEL-18680:
-
Summary: Wrong initialization of KeyStoreParameters causes
java.lang.IllegalArgumentException
Key: CAMEL-18680
URL: https://issues.apache.org/jira/browse/CAMEL-18680
Project: Camel
Issue Type: Bug
Components: camel-core-api, camel-vertx
Affects Versions: 3.20.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
Newly added validation on
[JsseParameters|https://github.com/apache/camel/commit/2d1a56c2282229478f812eb7f573479428d128d3#diff-f9902a7576d2dce46871a88c8ad5694f6bf4036c83d46d3da5cf7a2c84fe6df1R116]
is not respected on several places using KeStoreParamaterts.
I encountered a failure on camel-quarkus/http extension and on several
vertx-http tests in Camel (VertxHttpSSLTest and
VertxHttpSSLGlobalConfigurationTest)
The error message is
{quote}java.lang.IllegalArgumentException: CamelContext must be specified on:
KeyStoreParameters[type=null, password=, provider=null,
resource=/jsse/keystore.p12]{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18648) Google-bigquery: ResolveEndpointFailedException because of the bug in configuration class
Jiri Ondrusek created CAMEL-18648: - Summary: Google-bigquery: ResolveEndpointFailedException because of the bug in configuration class Key: CAMEL-18648 URL: https://issues.apache.org/jira/browse/CAMEL-18648 Project: Camel Issue Type: Bug Components: camel-google-bigquery Affects Versions: 3.20.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek Some recent changes to the class `GoogleBigQueryConfiguration` causes `ArrayIndexOutOfBoundsException` for endpoint urls containing 3 parts (i.e. `google-bigquery://test-project:google_bigquery_test_dataset:google_bigquery_table_for_partitioning?connectionFactory=#connectionFactory`) Simple test covering this should be added. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18524) Google-functions: dependency conflicts brought by the component
[
https://issues.apache.org/jira/browse/CAMEL-18524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606562#comment-17606562
]
Jiri Ondrusek edited comment on CAMEL-18524 at 9/19/22 11:47 AM:
-
To be honest, I'm not sure now. I have to find the right reason. It almost
seems, like `com.google.cloud:google-cloud-functions:1.0.8` contains
`com.google.api:gax-grpc:2.18.1`, which is in conflict with
`com.google.cloud:google-cloud-functions:1.0.8`. Nevertheless the quick reason
a *quick* fix could be exclusion of the
`com.google.auto.value:auto-value-annotations:1.7.4` and to keep only
`com.google.auto.value:auto-value-annotations:1.9`.
was (Author: jondruse):
To be honest, I'm not sure now. I have to find the right reason. It almost
seems, like `com.google.cloud:google-cloud-functions:1.0.8` contains
`com.google.api:gax-grpc:2.18.1`, which is in conflict with
`com.google.cloud:google-cloud-functions:1.0.8`. Nevertheless the right reason
a quick fix could be exclusion of the
`com.google.auto.value:auto-value-annotations:1.7.4` and to keep only
`com.google.auto.value:auto-value-annotations:1.9`.
> Google-functions: dependency conflicts brought by the component
> ---
>
> Key: CAMEL-18524
> URL: https://issues.apache.org/jira/browse/CAMEL-18524
> Project: Camel
> Issue Type: Dependency upgrade
>Affects Versions: 3.19.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> I noticed failed build of camel-quarkus google-secret-manager. The log is
> {code}
> Dependency convergence error for
> com.google.auto.value:auto-value-annotations:1.7.4 paths to dependency are:
> +-org.apache.camel.quarkus:camel-quarkus-google-functions:2.13.0-SNAPSHOT
> +-org.apache.camel:camel-google-functions:3.19.0-20220918.103349-68
> +-com.google.cloud:google-cloud-functions:1.0.8
> +-com.google.auto.value:auto-value-annotations:1.7.4
> and
> +-org.apache.camel.quarkus:camel-quarkus-google-functions:2.13.0-SNAPSHOT
> +-org.apache.camel:camel-google-functions:3.19.0-20220918.103349-68
> +-com.google.cloud:google-cloud-functions:1.0.8
> +-com.google.api.grpc:proto-google-cloud-functions-v1:1.0.8
> +-com.google.auto.value:auto-value-annotations:1.7.4
> and
> +-org.apache.camel.quarkus:camel-quarkus-google-functions:2.13.0-SNAPSHOT
> +-org.apache.camel:camel-google-functions:3.19.0-20220918.103349-68
> +-com.google.cloud:google-cloud-functions:1.0.8
> +-com.google.api:gax-grpc:2.18.1
> +-io.grpc:grpc-googleapis:1.49.0
> +-io.grpc:grpc-xds:1.49.0
> +-com.google.auto.value:auto-value-annotations:1.9
> {code}
> As you can see, all conflicts are brought by
> org.apache.camel:camel-google-functions-3.19.0-*
> Therefore I think that some versions has to be aligned in camel to not create
> such issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18524) Google-functions: dependency conflicts brought by the component
[
https://issues.apache.org/jira/browse/CAMEL-18524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606562#comment-17606562
]
Jiri Ondrusek commented on CAMEL-18524:
---
To be honest, I'm not sure now. I have to find the right reason. It almost
seems, like `com.google.cloud:google-cloud-functions:1.0.8` contains
`com.google.api:gax-grpc:2.18.1`, which is in conflict with
`com.google.cloud:google-cloud-functions:1.0.8`. Nevertheless the right reason
a quick fix could be exclusion of the
`com.google.auto.value:auto-value-annotations:1.7.4` and to keep only
`com.google.auto.value:auto-value-annotations:1.9`.
> Google-functions: dependency conflicts brought by the component
> ---
>
> Key: CAMEL-18524
> URL: https://issues.apache.org/jira/browse/CAMEL-18524
> Project: Camel
> Issue Type: Dependency upgrade
>Affects Versions: 3.19.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> I noticed failed build of camel-quarkus google-secret-manager. The log is
> {code}
> Dependency convergence error for
> com.google.auto.value:auto-value-annotations:1.7.4 paths to dependency are:
> +-org.apache.camel.quarkus:camel-quarkus-google-functions:2.13.0-SNAPSHOT
> +-org.apache.camel:camel-google-functions:3.19.0-20220918.103349-68
> +-com.google.cloud:google-cloud-functions:1.0.8
> +-com.google.auto.value:auto-value-annotations:1.7.4
> and
> +-org.apache.camel.quarkus:camel-quarkus-google-functions:2.13.0-SNAPSHOT
> +-org.apache.camel:camel-google-functions:3.19.0-20220918.103349-68
> +-com.google.cloud:google-cloud-functions:1.0.8
> +-com.google.api.grpc:proto-google-cloud-functions-v1:1.0.8
> +-com.google.auto.value:auto-value-annotations:1.7.4
> and
> +-org.apache.camel.quarkus:camel-quarkus-google-functions:2.13.0-SNAPSHOT
> +-org.apache.camel:camel-google-functions:3.19.0-20220918.103349-68
> +-com.google.cloud:google-cloud-functions:1.0.8
> +-com.google.api:gax-grpc:2.18.1
> +-io.grpc:grpc-googleapis:1.49.0
> +-io.grpc:grpc-xds:1.49.0
> +-com.google.auto.value:auto-value-annotations:1.9
> {code}
> As you can see, all conflicts are brought by
> org.apache.camel:camel-google-functions-3.19.0-*
> Therefore I think that some versions has to be aligned in camel to not create
> such issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18524) Google-functions: dependency conflicts brought by the component
Jiri Ondrusek created CAMEL-18524:
-
Summary: Google-functions: dependency conflicts brought by the
component
Key: CAMEL-18524
URL: https://issues.apache.org/jira/browse/CAMEL-18524
Project: Camel
Issue Type: Dependency upgrade
Affects Versions: 3.19.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
I noticed failed build of camel-quarkus google-secret-manager. The log is
{code}
Dependency convergence error for
com.google.auto.value:auto-value-annotations:1.7.4 paths to dependency are:
+-org.apache.camel.quarkus:camel-quarkus-google-functions:2.13.0-SNAPSHOT
+-org.apache.camel:camel-google-functions:3.19.0-20220918.103349-68
+-com.google.cloud:google-cloud-functions:1.0.8
+-com.google.auto.value:auto-value-annotations:1.7.4
and
+-org.apache.camel.quarkus:camel-quarkus-google-functions:2.13.0-SNAPSHOT
+-org.apache.camel:camel-google-functions:3.19.0-20220918.103349-68
+-com.google.cloud:google-cloud-functions:1.0.8
+-com.google.api.grpc:proto-google-cloud-functions-v1:1.0.8
+-com.google.auto.value:auto-value-annotations:1.7.4
and
+-org.apache.camel.quarkus:camel-quarkus-google-functions:2.13.0-SNAPSHOT
+-org.apache.camel:camel-google-functions:3.19.0-20220918.103349-68
+-com.google.cloud:google-cloud-functions:1.0.8
+-com.google.api:gax-grpc:2.18.1
+-io.grpc:grpc-googleapis:1.49.0
+-io.grpc:grpc-xds:1.49.0
+-com.google.auto.value:auto-value-annotations:1.9
{code}
As you can see, all conflicts are brought by
org.apache.camel:camel-google-functions-3.19.0-*
Therefore I think that some versions has to be aligned in camel to not create
such issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18520) Google-secrets-manager: dependency conflicts brought by the component
Jiri Ondrusek created CAMEL-18520:
-
Summary: Google-secrets-manager: dependency conflicts brought by
the component
Key: CAMEL-18520
URL: https://issues.apache.org/jira/browse/CAMEL-18520
Project: Camel
Issue Type: Bug
Components: camel-google
Affects Versions: 3.19.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
I noticed failed build of camel-quarkus google-secret-manager. The log is
{code}
2022-09-16T06:55:52.5266134Z Dependency convergence error for
com.google.api:api-common:2.1.3 paths to dependency are:
2022-09-16T06:55:52.5267372Z
+-org.apache.camel.quarkus:camel-quarkus-google-secret-manager:2.13.0-SNAPSHOT
2022-09-16T06:55:52.5268132Z
+-org.apache.camel:camel-google-secret-manager:3.19.0-20220915.103447-65
2022-09-16T06:55:52.5268839Z
+-com.google.cloud:google-cloud-secretmanager:2.1.1
2022-09-16T06:55:52.5269506Z +-com.google.api:api-common:2.1.3
2022-09-16T06:55:52.5269908Z and
2022-09-16T06:55:52.5270481Z
+-org.apache.camel.quarkus:camel-quarkus-google-secret-manager:2.13.0-SNAPSHOT
2022-09-16T06:55:52.5271187Z
+-org.apache.camel:camel-google-secret-manager:3.19.0-20220915.103447-65
2022-09-16T06:55:52.5271838Z +-com.google.cloud:google-cloud-pubsub:1.119.0
2022-09-16T06:55:52.5272501Z +-com.google.api:api-common:2.2.0
2022-09-16T06:55:52.5272956Z
2022-09-16T06:55:52.5273109Z [WARNING]
2022-09-16T06:55:52.5273765Z Dependency convergence error for
com.google.api.grpc:proto-google-iam-v1:1.2.1 paths to dependency are:
2022-09-16T06:55:52.5274528Z
+-org.apache.camel.quarkus:camel-quarkus-google-secret-manager:2.13.0-SNAPSHOT
2022-09-16T06:55:52.5275051Z
+-org.apache.camel:camel-google-secret-manager:3.19.0-20220915.103447-65
2022-09-16T06:55:52.5275482Z
+-com.google.cloud:google-cloud-secretmanager:2.1.1
2022-09-16T06:55:52.5275899Z
+-com.google.api.grpc:proto-google-iam-v1:1.2.1
2022-09-16T06:55:52.5276150Z and
2022-09-16T06:55:52.5276540Z
+-org.apache.camel.quarkus:camel-quarkus-google-secret-manager:2.13.0-SNAPSHOT
2022-09-16T06:55:52.5277045Z
+-org.apache.camel:camel-google-secret-manager:3.19.0-20220915.103447-65
2022-09-16T06:55:52.5277461Z +-com.google.cloud:google-cloud-pubsub:1.119.0
2022-09-16T06:55:52.5277858Z
+-com.google.api.grpc:proto-google-iam-v1:1.3.4
2022-09-16T06:55:52.5278030Z
2022-09-16T06:55:52.5278113Z [WARNING]
2022-09-16T06:55:52.5279893Z Dependency convergence error for
com.google.auto.value:auto-value-annotations:1.9 paths to dependency are:
2022-09-16T06:55:52.5280662Z
+-org.apache.camel.quarkus:camel-quarkus-google-secret-manager:2.13.0-SNAPSHOT
2022-09-16T06:55:52.5281236Z
+-org.apache.camel:camel-google-secret-manager:3.19.0-20220915.103447-65
2022-09-16T06:55:52.5281734Z
+-com.google.cloud:google-cloud-secretmanager:2.1.1
2022-09-16T06:55:52.5282216Z
+-com.google.auto.value:auto-value-annotations:1.9
2022-09-16T06:55:52.5282651Z and
2022-09-16T06:55:52.5283387Z
+-org.apache.camel.quarkus:camel-quarkus-google-secret-manager:2.13.0-SNAPSHOT
2022-09-16T06:55:52.5283890Z
+-org.apache.camel:camel-google-secret-manager:3.19.0-20220915.103447-65
2022-09-16T06:55:52.5284323Z
+-com.google.cloud:google-cloud-secretmanager:2.1.1
2022-09-16T06:55:52.5284774Z
+-com.google.api.grpc:proto-google-cloud-secretmanager-v1:2.1.1
2022-09-16T06:55:52.5285229Z
+-com.google.auto.value:auto-value-annotations:1.9
2022-09-16T06:55:52.5285485Z and
2022-09-16T06:55:52.5286227Z
+-org.apache.camel.quarkus:camel-quarkus-google-secret-manager:2.13.0-SNAPSHOT
2022-09-16T06:55:52.5286782Z
+-org.apache.camel:camel-google-secret-manager:3.19.0-20220915.103447-65
2022-09-16T06:55:52.5287216Z
+-com.google.cloud:google-cloud-secretmanager:2.1.1
2022-09-16T06:55:52.5287685Z
+-com.google.api.grpc:proto-google-cloud-secretmanager-v1beta1:2.1.1
2022-09-16T06:55:52.5288297Z
+-com.google.auto.value:auto-value-annotations:1.9
2022-09-16T06:55:52.5288558Z and
2022-09-16T06:55:52.5288959Z
+-org.apache.camel.quarkus:camel-quarkus-google-secret-manager:2.13.0-SNAPSHOT
2022-09-16T06:55:52.5289446Z
+-org.apache.camel:camel-google-secret-manager:3.19.0-20220915.103447-65
2022-09-16T06:55:52.5289860Z +-com.google.cloud:google-cloud-pubsub:1.119.0
2022-09-16T06:55:52.5290292Z
+-com.google.api.grpc:proto-google-cloud-pubsub-v1:1.101.0
2022-09-16T06:55:52.5290711Z
+-com.google.auto.value:auto-value-annotations:1.9
2022-09-16T06:55:52.5290965Z and
2022-09-16T06:55:52.5291370Z
+-org.apache.camel.quarkus:camel-quarkus-google-secret-manager:2.13.0-SNAPSHOT
2022-09-16T06:55:52.5291856Z
+-org.apache.camel:camel-google-secret-manager:3.19.0-20220915.103447-65
2022-09-16T06:55:52.5292271Z +-com.google.cloud:google-cloud-pubsub:1.119.0
2022-09-16T06:55:52.5292672Z
+-com.google.auto.value:auto-value-annotations:1.9
[jira] [Updated] (CAMEL-18505) Camel-coap: Version conflict (californium-legal and element-connector)
[
https://issues.apache.org/jira/browse/CAMEL-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Ondrusek updated CAMEL-18505:
--
Summary: Camel-coap: Version conflict (californium-legal and
element-connector) (was: Camel-coap: Version conflict ()
> Camel-coap: Version conflict (californium-legal and element-connector)
> --
>
> Key: CAMEL-18505
> URL: https://issues.apache.org/jira/browse/CAMEL-18505
> Project: Camel
> Issue Type: Bug
> Components: camel-coap
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> Recent update of Scandium to 2.7.3 created 2 version conflicts in camel-coap.
> Build of camel-quarkus extension copa fails with:
> {code:java}
> Dependency convergence error for
> org.eclipse.californium:californium-legal:2.7.2 paths to dependency are:
> 2022-09-14T07:34:24.8326810Z
> +-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
> 2022-09-14T07:34:24.8327409Z
> +-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
> 2022-09-14T07:34:24.8327954Z
> +-org.eclipse.californium:californium-core:2.7.2
> 2022-09-14T07:34:24.8328418Z
> +-org.eclipse.californium:californium-legal:2.7.2
> 2022-09-14T07:34:24.8328734Z and
> 2022-09-14T07:34:24.8329134Z
> +-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
> 2022-09-14T07:34:24.8329585Z
> +-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
> 2022-09-14T07:34:24.8330014Z
> +-org.eclipse.californium:californium-core:2.7.2
> 2022-09-14T07:34:24.8330456Z
> +-org.eclipse.californium:element-connector:2.7.2
> 2022-09-14T07:34:24.8330902Z
> +-org.eclipse.californium:californium-legal:2.7.2
> 2022-09-14T07:34:24.8331209Z and
> 2022-09-14T07:34:24.8331597Z
> +-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
> 2022-09-14T07:34:24.8332051Z
> +-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
> 2022-09-14T07:34:24.8332467Z +-org.eclipse.californium:scandium:2.7.3
> 2022-09-14T07:34:24.8332906Z
> +-org.eclipse.californium:californium-legal:2.7.3
> 2022-09-14T07:34:24.8333204Z and
> 2022-09-14T07:34:24.8333592Z
> +-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
> 2022-09-14T07:34:24.8334030Z
> +-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
> 2022-09-14T07:34:24.8334476Z
> +-org.eclipse.californium:element-connector-tcp-netty:2.7.2
> 2022-09-14T07:34:24.8334946Z
> +-org.eclipse.californium:californium-legal:2.7.2
> 2022-09-14T07:34:24.8335189Z
> 2022-09-14T07:34:24.8335402Z [WARNING]
> 2022-09-14T07:34:24.8335890Z Dependency convergence error for
> org.eclipse.californium:element-connector:2.7.2 paths to dependency are:
> 2022-09-14T07:34:24.8336425Z
> +-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
> 2022-09-14T07:34:24.8336868Z
> +-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
> 2022-09-14T07:34:24.8337522Z
> +-org.eclipse.californium:californium-core:2.7.2
> 2022-09-14T07:34:24.8337984Z
> +-org.eclipse.californium:element-connector:2.7.2
> 2022-09-14T07:34:24.8338286Z and
> 2022-09-14T07:34:24.8338680Z
> +-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
> 2022-09-14T07:34:24.8339126Z
> +-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
> 2022-09-14T07:34:24.8339605Z +-org.eclipse.californium:scandium:2.7.3
> 2022-09-14T07:34:24.8340053Z
> +-org.eclipse.californium:element-connector:2.7.3
> 2022-09-14T07:34:24.8340338Z and
> 2022-09-14T07:34:24.8340717Z
> +-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
> 2022-09-14T07:34:24.8341155Z
> +-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
> 2022-09-14T07:34:24.8341615Z
> +-org.eclipse.californium:element-connector-tcp-netty:2.7.2
> 2022-09-14T07:34:24.8342089Z
> +-org.eclipse.californium:element-connector:2.7.2 {code}
> Correct solution should be to move californium:element-connector and
> californium:californium-legal: to version 2.7.3
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18505) Camel-coap: Version conflict (
Jiri Ondrusek created CAMEL-18505:
-
Summary: Camel-coap: Version conflict (
Key: CAMEL-18505
URL: https://issues.apache.org/jira/browse/CAMEL-18505
Project: Camel
Issue Type: Bug
Components: camel-coap
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
Recent update of Scandium to 2.7.3 created 2 version conflicts in camel-coap.
Build of camel-quarkus extension copa fails with:
{code:java}
Dependency convergence error for
org.eclipse.californium:californium-legal:2.7.2 paths to dependency are:
2022-09-14T07:34:24.8326810Z
+-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
2022-09-14T07:34:24.8327409Z
+-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
2022-09-14T07:34:24.8327954Z
+-org.eclipse.californium:californium-core:2.7.2
2022-09-14T07:34:24.8328418Z
+-org.eclipse.californium:californium-legal:2.7.2
2022-09-14T07:34:24.8328734Z and
2022-09-14T07:34:24.8329134Z
+-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
2022-09-14T07:34:24.8329585Z
+-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
2022-09-14T07:34:24.8330014Z
+-org.eclipse.californium:californium-core:2.7.2
2022-09-14T07:34:24.8330456Z
+-org.eclipse.californium:element-connector:2.7.2
2022-09-14T07:34:24.8330902Z
+-org.eclipse.californium:californium-legal:2.7.2
2022-09-14T07:34:24.8331209Z and
2022-09-14T07:34:24.8331597Z
+-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
2022-09-14T07:34:24.8332051Z
+-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
2022-09-14T07:34:24.8332467Z +-org.eclipse.californium:scandium:2.7.3
2022-09-14T07:34:24.8332906Z
+-org.eclipse.californium:californium-legal:2.7.3
2022-09-14T07:34:24.8333204Z and
2022-09-14T07:34:24.8333592Z
+-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
2022-09-14T07:34:24.8334030Z
+-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
2022-09-14T07:34:24.8334476Z
+-org.eclipse.californium:element-connector-tcp-netty:2.7.2
2022-09-14T07:34:24.8334946Z
+-org.eclipse.californium:californium-legal:2.7.2
2022-09-14T07:34:24.8335189Z
2022-09-14T07:34:24.8335402Z [WARNING]
2022-09-14T07:34:24.8335890Z Dependency convergence error for
org.eclipse.californium:element-connector:2.7.2 paths to dependency are:
2022-09-14T07:34:24.8336425Z
+-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
2022-09-14T07:34:24.8336868Z
+-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
2022-09-14T07:34:24.8337522Z
+-org.eclipse.californium:californium-core:2.7.2
2022-09-14T07:34:24.8337984Z
+-org.eclipse.californium:element-connector:2.7.2
2022-09-14T07:34:24.8338286Z and
2022-09-14T07:34:24.8338680Z
+-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
2022-09-14T07:34:24.8339126Z
+-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
2022-09-14T07:34:24.8339605Z +-org.eclipse.californium:scandium:2.7.3
2022-09-14T07:34:24.8340053Z
+-org.eclipse.californium:element-connector:2.7.3
2022-09-14T07:34:24.8340338Z and
2022-09-14T07:34:24.8340717Z
+-org.apache.camel.quarkus:camel-quarkus-coap:2.13.0-SNAPSHOT
2022-09-14T07:34:24.8341155Z
+-org.apache.camel:camel-coap:3.19.0-20220913.111253-62
2022-09-14T07:34:24.8341615Z
+-org.eclipse.californium:element-connector-tcp-netty:2.7.2
2022-09-14T07:34:24.8342089Z
+-org.eclipse.californium:element-connector:2.7.2 {code}
Correct solution should be to move californium:element-connector and
californium:californium-legal: to version 2.7.3
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18486) Camel-xchange: Add mocked mapping for the test AccountProducerTest#testFundingHistory
Jiri Ondrusek created CAMEL-18486:
-
Summary: Camel-xchange: Add mocked mapping for the test
AccountProducerTest#testFundingHistory
Key: CAMEL-18486
URL: https://issues.apache.org/jira/browse/CAMEL-18486
Project: Camel
Issue Type: Test
Affects Versions: 3.19.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
During implementation of https://issues.apache.org/jira/browse/CAMEL-18484 I
had a problem with the test {_}AccountProducerTest#testFundingHistory{_}.
Test works when using real account, but once I added a wiremock recording
server to catch communication, I got
{code:java}
org.knowm.xchange.exceptions.ExchangeException: API-key format invalid. (HTTP
status code: 400) {code}
I'm not sure why this is happening. It would be nice to solve this problem and
once it works, enable this test for the mocked testing (it is disabled with a
comment now)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18484) Camel-xchange: Enable mock testing without neaed of real account
Jiri Ondrusek created CAMEL-18484:
-
Summary: Camel-xchange: Enable mock testing without neaed of real
account
Key: CAMEL-18484
URL: https://issues.apache.org/jira/browse/CAMEL-18484
Project: Camel
Issue Type: Test
Affects Versions: 3.19.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
Tests in camel-xchange component are disabled by default (because of the need
of the real credentials)
{code:java}
@EnabledIfSystemProperty(named = "enable.xchange.itests", matches = "true",
disabledReason = "Requires API credentials") {code}
It would be much better if the functionality was covered by mocked junit tests.
(For example wiremock could be used)
- if _enable.xchange.itests_ is set to {_}true{_}, not-mocked test would be
used (as before)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18447) Camel-pubsub: com.google.api.gax.rpc.AsyncTaskException: Asynchronous task failed with real account
[
https://issues.apache.org/jira/browse/CAMEL-18447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Ondrusek updated CAMEL-18447:
--
Description:
During fixation of [https://github.com/apache/camel-quarkus/issues/4062] I
noticed regular exceptions shown only with real account (not with emulater):
{code:java}
Suppressed: com.google.api.gax.rpc.AsyncTaskException: Asynchronous task failed
at
com.google.api.gax.rpc.ApiExceptions.callAndTranslateApiException(ApiExceptions.java:57)
at
com.google.api.gax.rpc.UnaryCallable.call(UnaryCallable.java:112) {code}
Exception shows that some connections is closed during the acking mechanism. It
should be fixed. (To reproduce issue run i.e. run test from CQ with real
account GooglePubsubTest#pubsubTopicProduceConsume)
was:
During fixation of [https://github.com/apache/camel-quarkus/issues/4062] I
noticed regular exceptions shown only with real account (not with emulater):
{code:java}
Suppressed: com.google.api.gax.rpc.AsyncTaskException: Asynchronous task failed
at
com.google.api.gax.rpc.ApiExceptions.callAndTranslateApiException(ApiExceptions.java:57)
at
com.google.api.gax.rpc.UnaryCallable.call(UnaryCallable.java:112) {code}
Exception shows that some connections is closed during the acking mechanism. It
should be fixed. (To reproduce issue run i.e. test from CQ with lreal account
GooglePubsubTest#pubsubTopicProduceConsume)
> Camel-pubsub: com.google.api.gax.rpc.AsyncTaskException: Asynchronous task
> failed with real account
> ---
>
> Key: CAMEL-18447
> URL: https://issues.apache.org/jira/browse/CAMEL-18447
> Project: Camel
> Issue Type: Bug
> Components: camel-google-pubsub
>Affects Versions: 3.18.2, 3.19.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> During fixation of [https://github.com/apache/camel-quarkus/issues/4062] I
> noticed regular exceptions shown only with real account (not with emulater):
>
> {code:java}
> Suppressed: com.google.api.gax.rpc.AsyncTaskException: Asynchronous task
> failed at
> com.google.api.gax.rpc.ApiExceptions.callAndTranslateApiException(ApiExceptions.java:57)
> at
> com.google.api.gax.rpc.UnaryCallable.call(UnaryCallable.java:112) {code}
> Exception shows that some connections is closed during the acking mechanism.
> It should be fixed. (To reproduce issue run i.e. run test from CQ with real
> account GooglePubsubTest#pubsubTopicProduceConsume)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18447) Camel-pubsub: com.google.api.gax.rpc.AsyncTaskException: Asynchronous task failed with real account
Jiri Ondrusek created CAMEL-18447:
-
Summary: Camel-pubsub: com.google.api.gax.rpc.AsyncTaskException:
Asynchronous task failed with real account
Key: CAMEL-18447
URL: https://issues.apache.org/jira/browse/CAMEL-18447
Project: Camel
Issue Type: Bug
Components: camel-google-pubsub
Affects Versions: 3.18.2, 3.19.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
During fixation of [https://github.com/apache/camel-quarkus/issues/4062] I
noticed regular exceptions shown only with real account (not with emulater):
{code:java}
Suppressed: com.google.api.gax.rpc.AsyncTaskException: Asynchronous task failed
at
com.google.api.gax.rpc.ApiExceptions.callAndTranslateApiException(ApiExceptions.java:57)
at
com.google.api.gax.rpc.UnaryCallable.call(UnaryCallable.java:112) {code}
Exception shows that some connections is closed during the acking mechanism. It
should be fixed. (To reproduce issue run i.e. test from CQ with lreal account
GooglePubsubTest#pubsubTopicProduceConsume)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18437) Camel-bigquery: There is a difference in types between @name and ${name}
Jiri Ondrusek created CAMEL-18437:
-
Summary: Camel-bigquery: There is a difference in types between
@name and ${name}
Key: CAMEL-18437
URL: https://issues.apache.org/jira/browse/CAMEL-18437
Project: Camel
Issue Type: Bug
Components: camel-google-bigquery
Affects Versions: 3.19.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
I noticed a undefined behavior when expanding coverage of google-bigquery in
camel-quarkus ([ticket|https://github.com/apache/camel-quarkus/issues/3949]).
Here is a relevant chapter from the [documentation|#_uri_format].]
{quote} * parameters in form ${name} are extracted from message headers and
formed the translated query
* parameters in form @name are extracted from body or message headers and sent
to Google Bigquery{quote}
>From my PoV is that in case of parameters in the header, it should not matter,
>whether _@name_ or _${name}_ is used.
The behavior seems to be more complicated:
* In case of _@name_ pattern, value types are dynamically resolved (see
https://issues.apache.org/jira/browse/CAMEL-18382 for more details)
* In case of {_}${name}{_}, value is inserted into the sql without any
modification. Which behaves like "undefined".
# If header value is an integer (like 4), sql is translated into {_}... VALUES
(4) ...{_}, so it is interpreted as integer.
# If header value is string with number inside (like "4"), sql is translated
into {_}... VALUES (4) ...{_}, so it is interpreted as integer.
# If the header is string (like "s4"), sql is translated into {_}... VALUES
(s4) ...{_}, and the execution fails.
It would make sense that the behavior of _@name_ and _${name}_ is the same and
mainly the case 3 does not cause any failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18382) Google-bigquery allow different value types from headers
[ https://issues.apache.org/jira/browse/CAMEL-18382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584775#comment-17584775 ] Jiri Ondrusek commented on CAMEL-18382: --- ok, thanks > Google-bigquery allow different value types from headers > - > > Key: CAMEL-18382 > URL: https://issues.apache.org/jira/browse/CAMEL-18382 > Project: Camel > Issue Type: Improvement > Components: camel-google-bigquery >Affects Versions: 3.18.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > Fix For: 3.19.0 > > > One of the ways of execution of sql via `google-bigquery` component is to > pass values in header. Header values are passed into the sql request. > Unfortunately each object is converted to String in [this > line|https://github.com/apache/camel/blob/main/components/camel-google/camel-google-bigquery/src/main/java/org/apache/camel/component/google/bigquery/sql/GoogleBigQuerySQLProducer.java#L160.] > > It would be nice, if the component could keep several types based on the type > of the value (like numeric, boolean) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18382) Google-bigquery allow different value types from headers
[ https://issues.apache.org/jira/browse/CAMEL-18382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584772#comment-17584772 ] Jiri Ondrusek commented on CAMEL-18382: --- Hi [~davsclaus] , as I'm thinking about it, I see one problem. If I change the detection to use different types (not only String), it will break back-compatibility. Any user who is using current implementation would need to revisit scheme , potentially convert existing data. I can imagine a solution with a configuration property (something like _dynamicSqlTypeDetetection_ with default value false) which enables to switch on this new feature. What do you think? > Google-bigquery allow different value types from headers > - > > Key: CAMEL-18382 > URL: https://issues.apache.org/jira/browse/CAMEL-18382 > Project: Camel > Issue Type: Improvement > Components: camel-google-bigquery >Affects Versions: 3.18.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > Fix For: 3.19.0 > > > One of the ways of execution of sql via `google-bigquery` component is to > pass values in header. Header values are passed into the sql request. > Unfortunately each object is converted to String in [this > line|https://github.com/apache/camel/blob/main/components/camel-google/camel-google-bigquery/src/main/java/org/apache/camel/component/google/bigquery/sql/GoogleBigQuerySQLProducer.java#L160.] > > It would be nice, if the component could keep several types based on the type > of the value (like numeric, boolean) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18393) Camel-bigquery: NPE if select * is requested
Jiri Ondrusek created CAMEL-18393:
-
Summary: Camel-bigquery: NPE if select * is requested
Key: CAMEL-18393
URL: https://issues.apache.org/jira/browse/CAMEL-18393
Project: Camel
Issue Type: Bug
Components: camel-google-bigquery
Affects Versions: 3.18.2, 3.19.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
Recent change of the component brought some problems:
* If _select * from_ query is executed then it causes NPE.
{code}
Caused by: java.lang.NullPointerException
at
org.apache.camel.component.google.bigquery.sql.GoogleBigQuerySQLProducer.executeSQL(GoogleBigQuerySQLProducer.java:111)
at
org.apache.camel.component.google.bigquery.sql.GoogleBigQuerySQLProducer.process(GoogleBigQuerySQLProducer.java:82)
at
org.apache.camel.support.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:66)
{code}
* Another problem is that the result of the producer for `select` queries
should be the _totalRows_ from the result.
Code causing the troubles is
https://github.com/apache/camel/commit/bdd495048da891a2e856a116355e9ca6b6f58c72#diff-fd3f8e800c602d7167e9cdbfb4d6af42e1e6223d05eae2242b9c5b14703862ffR111-R116
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18382) Google-bigquery allow different value types from headers
Jiri Ondrusek created CAMEL-18382: - Summary: Google-bigquery allow different value types from headers Key: CAMEL-18382 URL: https://issues.apache.org/jira/browse/CAMEL-18382 Project: Camel Issue Type: Improvement Components: camel-google-bigquery Affects Versions: 3.19.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek One of the ways of execution of sql via `google-bigquery` component is to pass values in header. Header values are passed into the sql request. Unfortunately each object is converted to String in [this line|https://github.com/apache/camel/blob/main/components/camel-google/camel-google-bigquery/src/main/java/org/apache/camel/component/google/bigquery/sql/GoogleBigQuerySQLProducer.java#L160.] It would be nice, if the component could keep several types based on the type of the value (like numeric, boolean) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18349) Core - XPathRouteConcurrentBigTest - newly added limit of "operators an XPath expression can contain." fails the test
Jiri Ondrusek created CAMEL-18349:
-
Summary: Core - XPathRouteConcurrentBigTest - newly added limit of
"operators an XPath expression can contain." fails the test
Key: CAMEL-18349
URL: https://issues.apache.org/jira/browse/CAMEL-18349
Project: Camel
Issue Type: Bug
Components: tests
Affects Versions: 3.19.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
In java 11.0.15, there is a security limitation for "the number of operators
an XPath expression can contain. (see [release
notes|https://www.oracle.com/java/technologies/javase/11-0-15-relnotes.html])
with default value 100.
Unfortunately the test _XPathRouteConcurrentBigTest_ requires 101
{code:java}
Caused by: javax.xml.transform.TransformerException: JAXP0801002: the compiler
encountered an XPath expression containing '101' operators that exceeds the
'100' limit set by 'FEATURE_SECURE_PROCESSING'.
{code}
Solution would be to change a test little bit, to require <= 100 operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18277) Google Pubsub: MessageOrderingIT test does not work with real account
Jiri Ondrusek created CAMEL-18277:
-
Summary: Google Pubsub: MessageOrderingIT test does not work with
real account
Key: CAMEL-18277
URL: https://issues.apache.org/jira/browse/CAMEL-18277
Project: Camel
Issue Type: Bug
Components: camel-google-pubsub, tests
Affects Versions: 3.18.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
I'm working on test coverage of _camel-pubsub_ extension in Camel-quarkus
([issue|[https://github.com/apache/camel-quarkus/issues/3910]).]
I noticed:
* There is no easy way of running integration tests with the real account. It
would be nice to have an option to export for example a several env.
properties (like export GOOGLE_APPLICATION_CREDENTIALS=.. and export
GOOGLE_PROJECT_ID=...) and allow execution of the tests with the real account.
* _MessageOrderingIT_ does not work with the real cloud account. You can see
an exception, which is probably caused by the use of regional endpoint.
{code:java}
java.util.concurrent.ExecutionException:
com.google.api.gax.rpc.UnauthenticatedException:
io.grpc.StatusRuntimeException: UNAUTHENTICATED: Request had invalid
authentication credentials. Expected OAuth 2 access token, login cookie or
other valid authentication credential. See
https://developers.google.com/identity/sign-in/web/devconsole-project.
at
com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:588)
at
com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:567)
at com.google.api.core.AbstractApiFuture.get(AbstractApiFuture.java:55)
at
org.apache.camel.component.google.pubsub.GooglePubsubProducer.send(GooglePubsubProducer.java:117)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18219) Enhance CamelTestSupport with a check to not run on quarkus
Jiri Ondrusek created CAMEL-18219: - Summary: Enhance CamelTestSupport with a check to not run on quarkus Key: CAMEL-18219 URL: https://issues.apache.org/jira/browse/CAMEL-18219 Project: Camel Issue Type: Improvement Components: tests Affects Versions: 3.18.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek `CamelTestSupport` should not be used with the Camel Quarkus. It would be nice to have a similar check (as is for SpringBoot). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (CAMEL-18201) Enhance CamelTestSupport with an option to turn off stopping of the context
[ https://issues.apache.org/jira/browse/CAMEL-18201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-18201: -- Summary: Enhance CamelTestSupport with an option to turn off stopping of the context (was: Enhance CamelTestSupport to turn off stopping of the context) > Enhance CamelTestSupport with an option to turn off stopping of the context > --- > > Key: CAMEL-18201 > URL: https://issues.apache.org/jira/browse/CAMEL-18201 > Project: Camel > Issue Type: Improvement > Components: tests >Affects Versions: 3.18.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > > It would be nice to use CamelTestSupport for testing in camel-quarkus for JVM > tests ([ticket|https://github.com/apache/camel-quarkus/issues/3511]). Main > problem is that `CamelContext` can not be restarted in camel-quarkus. If some > kind of a configuration option (for example junit's ConfigurationParameters) > would allow to disable stopping of the context, `CamelTestSupport` kind of > testing could be adapted. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18201) Enhance CamelTestSupport to turn off stopping of the context
Jiri Ondrusek created CAMEL-18201: - Summary: Enhance CamelTestSupport to turn off stopping of the context Key: CAMEL-18201 URL: https://issues.apache.org/jira/browse/CAMEL-18201 Project: Camel Issue Type: Improvement Components: tests Affects Versions: 3.18.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek It would be nice to use CamelTestSupport for testing in camel-quarkus for JVM tests ([ticket|https://github.com/apache/camel-quarkus/issues/3511]). Main problem is that `CamelContext` can not be restarted in camel-quarkus. If some kind of a configuration option (for example junit's ConfigurationParameters) would allow to disable stopping of the context, `CamelTestSupport` kind of testing could be adapted. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (CAMEL-18123) Aws2-sqs: Operations PurgeQueue and DeleteQueue requires unnecessary header
[ https://issues.apache.org/jira/browse/CAMEL-18123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-18123: -- Summary: Aws2-sqs: Operations PurgeQueue and DeleteQueue requires unnecessary header (was: Aws2-sqs: Operations PurgeQueue and DeleteQueueu requires unnecessary header) > Aws2-sqs: Operations PurgeQueue and DeleteQueue requires unnecessary header > --- > > Key: CAMEL-18123 > URL: https://issues.apache.org/jira/browse/CAMEL-18123 > Project: Camel > Issue Type: Bug > Components: camel-aws2 >Affects Versions: 3.14.4, 3.17.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > > Both PurheQueu and DrleteQueue operations work only if header > SQS_QUEUE_PREFIX is filled with any value. This header is not required at all > (https://github.com/apache/camel/blob/64c1fbdf0c3dd130ce21a6e1cd0cd97c0d1e3473/components/camel-aws/camel-aws2-sqs/src/main/java/org/apache/camel/component/aws2/sqs/Sqs2Producer.java#L184) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18123) Aws2-sqs: Operations PurgeQueue and DeleteQueueu requires unnecessary header
Jiri Ondrusek created CAMEL-18123: - Summary: Aws2-sqs: Operations PurgeQueue and DeleteQueueu requires unnecessary header Key: CAMEL-18123 URL: https://issues.apache.org/jira/browse/CAMEL-18123 Project: Camel Issue Type: Bug Components: camel-aws2 Affects Versions: 3.14.4, 3.17.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek Both PurheQueu and DrleteQueue operations work only if header SQS_QUEUE_PREFIX is filled with any value. This header is not required at all (https://github.com/apache/camel/blob/64c1fbdf0c3dd130ce21a6e1cd0cd97c0d1e3473/components/camel-aws/camel-aws2-sqs/src/main/java/org/apache/camel/component/aws2/sqs/Sqs2Producer.java#L184) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CAMEL-18085) ManagementStatisticsLevel.RoutesOnly does not prevent creation of processors' statisctics
[
https://issues.apache.org/jira/browse/CAMEL-18085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533828#comment-17533828
]
Jiri Ondrusek commented on CAMEL-18085:
---
I will work on it and I'll prepare a new config. option, which will allow to
define a level of beans to install.
> ManagementStatisticsLevel.RoutesOnly does not prevent creation of
> processors' statisctics
> --
>
> Key: CAMEL-18085
> URL: https://issues.apache.org/jira/browse/CAMEL-18085
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, jmx
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
> Fix For: 3.17.0
>
>
> If _ManagementStatisticsLevel.RoutesOnly_ is used to configure performance
> statistics, processors' statistics are created - the are not actualized.
> Even their existence could cause performance issues. It would be better to do
> not register them at all (the same way as with
> {_}onlyRegisterProcessorWithCustomId=true{_}). See the
> [documentation|https://camel.apache.org/manual/jmx.html#_configuring_performance_statistics]
> for more details.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CAMEL-18085) ManagementStatisticsLevel.RoutesOnly does not prevent creation of processors' statisctics
[
https://issues.apache.org/jira/browse/CAMEL-18085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533825#comment-17533825
]
Jiri Ondrusek commented on CAMEL-18085:
---
[~davsclaus] Thanks for the explanation.
> ManagementStatisticsLevel.RoutesOnly does not prevent creation of
> processors' statisctics
> --
>
> Key: CAMEL-18085
> URL: https://issues.apache.org/jira/browse/CAMEL-18085
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
>
> If _ManagementStatisticsLevel.RoutesOnly_ is used to configure performance
> statistics, processors' statistics are created - the are not actualized.
> Even their existence could cause performance issues. It would be better to do
> not register them at all (the same way as with
> {_}onlyRegisterProcessorWithCustomId=true{_}). See the
> [documentation|https://camel.apache.org/manual/jmx.html#_configuring_performance_statistics]
> for more details.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CAMEL-18085) ManagementStatisticsLevel.RoutesOnly does not prevent creation of processors' statisctics
Jiri Ondrusek created CAMEL-18085:
-
Summary: ManagementStatisticsLevel.RoutesOnly does not prevent
creation of processors' statisctics
Key: CAMEL-18085
URL: https://issues.apache.org/jira/browse/CAMEL-18085
Project: Camel
Issue Type: Bug
Components: camel-core
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
If _ManagementStatisticsLevel.RoutesOnly_ is used to configure performance
statistics, processors' statistics are created - the are not actualized. Even
their existence could cause performance issues. It would be better to do not
register them at all (the same way as with
{_}onlyRegisterProcessorWithCustomId=true{_}). See the
[documentation|https://camel.apache.org/manual/jmx.html#_configuring_performance_statistics]
for more details.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (CAMEL-18071) Camel-http-platform-starter compilation problem in test module
[ https://issues.apache.org/jira/browse/CAMEL-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-18071: -- Summary: Camel-http-platform-starter compilation problem in test module (was: Fix camel-http-platform-starter compilation problem in test module) > Camel-http-platform-starter compilation problem in test module > -- > > Key: CAMEL-18071 > URL: https://issues.apache.org/jira/browse/CAMEL-18071 > Project: Camel > Issue Type: Task > Components: camel-platform-http, camel-spring-boot-starters, tests >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > > There is a chamnge of PlatformHttpComponent.getHttpEndpoints (see > https://issues.apache.org/jira/browse/CAMEL-18062). Test from starter has to > reflect it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18071) Fix camel-http-platform-starter compilation problem in test module
Jiri Ondrusek created CAMEL-18071: - Summary: Fix camel-http-platform-starter compilation problem in test module Key: CAMEL-18071 URL: https://issues.apache.org/jira/browse/CAMEL-18071 Project: Camel Issue Type: Task Components: camel-platform-http, camel-spring-boot-starters, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek There is a chamnge of PlatformHttpComponent.getHttpEndpoints (see https://issues.apache.org/jira/browse/CAMEL-18062). Test from starter has to reflect it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18062) Add tests in camel-aws2-lambda-starter
Jiri Ondrusek created CAMEL-18062: - Summary: Add tests in camel-aws2-lambda-starter Key: CAMEL-18062 URL: https://issues.apache.org/jira/browse/CAMEL-18062 Project: Camel Issue Type: Test Components: camel-aws2, camel-spring-boot-starters, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (CAMEL-18051) Backport CAMEL-17835 to 3.14.x
[ https://issues.apache.org/jira/browse/CAMEL-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek reassigned CAMEL-18051: - Assignee: Jiri Ondrusek > Backport CAMEL-17835 to 3.14.x > -- > > Key: CAMEL-18051 > URL: https://issues.apache.org/jira/browse/CAMEL-18051 > Project: Camel > Issue Type: Improvement > Components: camel-ftp, camel-jsch >Affects Versions: 3.14.0 >Reporter: Claus Ibsen >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.14.4 > > > We should backport CAMEL-17835 as jsch is not active maintained anymore and > there are some security algorithms that Camel users would need to be able to > use that they cannot do with the old jsch. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18047) Upgrade jakarta.mail to 1.6.7
Jiri Ondrusek created CAMEL-18047: - Summary: Upgrade jakarta.mail to 1.6.7 Key: CAMEL-18047 URL: https://issues.apache.org/jira/browse/CAMEL-18047 Project: Camel Issue Type: Improvement Components: camel-mail Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (CAMEL-18002) Camel-netty-http: Test BaseNettyTest.verifyNoLeaks fails.
[
https://issues.apache.org/jira/browse/CAMEL-18002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Ondrusek updated CAMEL-18002:
--
Description:
Tested with {_}OpenJDK Runtime Environment Temurin-11.0.14+9 (build
11.0.14+9){_}.
Test *NettyHttpSimpleUriParametersTest* failed with:
{quote}[ERROR] Failures:
[ERROR] NettyHttpSimpleUriParametersTest>BaseNettyTest.verifyNoLeaks:65 Leaks
detected while running tests: [Logger=io.netty.util.ResourceLeakDetector
Level=ERROR Message=LEAK: ByteBuf.release() was not called before it's
garbage-collected. See [https://netty.io/wiki/reference-counted-objects.html]
for more information.
...
{quote}
was:
Tested with {_}OpenJDK Runtime Environment Temurin-11.0.14+9 (build
11.0.14+9){_}.
Test BaseNettyTest.verifyNoLeaks failed with:
{quote}[ERROR] Failures:
[ERROR] NettyHttpSimpleUriParametersTest>BaseNettyTest.verifyNoLeaks:65 Leaks
detected while running tests: [Logger=io.netty.util.ResourceLeakDetector
Level=ERROR Message=LEAK: ByteBuf.release() was not called before it's
garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for
more information.
...
{quote}
> Camel-netty-http: Test BaseNettyTest.verifyNoLeaks fails.
> -
>
> Key: CAMEL-18002
> URL: https://issues.apache.org/jira/browse/CAMEL-18002
> Project: Camel
> Issue Type: Test
> Components: camel-netty-http, tests
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> Tested with {_}OpenJDK Runtime Environment Temurin-11.0.14+9 (build
> 11.0.14+9){_}.
> Test *NettyHttpSimpleUriParametersTest* failed with:
> {quote}[ERROR] Failures:
> [ERROR] NettyHttpSimpleUriParametersTest>BaseNettyTest.verifyNoLeaks:65
> Leaks detected while running tests:
> [Logger=io.netty.util.ResourceLeakDetector Level=ERROR Message=LEAK:
> ByteBuf.release() was not called before it's garbage-collected. See
> [https://netty.io/wiki/reference-counted-objects.html] for more information.
> ...
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (CAMEL-18002) Camel-netty-http: Test NettyHttpSimpleUriParametersTest fails.
[
https://issues.apache.org/jira/browse/CAMEL-18002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Ondrusek updated CAMEL-18002:
--
Summary: Camel-netty-http: Test NettyHttpSimpleUriParametersTest fails.
(was: Camel-netty-http: Test BaseNettyTest.verifyNoLeaks fails.)
> Camel-netty-http: Test NettyHttpSimpleUriParametersTest fails.
> --
>
> Key: CAMEL-18002
> URL: https://issues.apache.org/jira/browse/CAMEL-18002
> Project: Camel
> Issue Type: Test
> Components: camel-netty-http, tests
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> Tested with {_}OpenJDK Runtime Environment Temurin-11.0.14+9 (build
> 11.0.14+9){_}.
> Test *NettyHttpSimpleUriParametersTest* failed with:
> {quote}[ERROR] Failures:
> [ERROR] NettyHttpSimpleUriParametersTest>BaseNettyTest.verifyNoLeaks:65
> Leaks detected while running tests:
> [Logger=io.netty.util.ResourceLeakDetector Level=ERROR Message=LEAK:
> ByteBuf.release() was not called before it's garbage-collected. See
> [https://netty.io/wiki/reference-counted-objects.html] for more information.
> ...
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CAMEL-18002) Camel-netty-http: Test BaseNettyTest.verifyNoLeaks fails.
Jiri Ondrusek created CAMEL-18002:
-
Summary: Camel-netty-http: Test BaseNettyTest.verifyNoLeaks fails.
Key: CAMEL-18002
URL: https://issues.apache.org/jira/browse/CAMEL-18002
Project: Camel
Issue Type: Test
Components: camel-netty-http, tests
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
Tested with {_}OpenJDK Runtime Environment Temurin-11.0.14+9 (build
11.0.14+9){_}.
Test BaseNettyTest.verifyNoLeaks failed with:
{quote}[ERROR] Failures:
[ERROR] NettyHttpSimpleUriParametersTest>BaseNettyTest.verifyNoLeaks:65 Leaks
detected while running tests: [Logger=io.netty.util.ResourceLeakDetector
Level=ERROR Message=LEAK: ByteBuf.release() was not called before it's
garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for
more information.
...
{quote}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CAMEL-17994) Camel-aws2-kinesis: Integration test does not work - KinesisComponentManualIT
Jiri Ondrusek created CAMEL-17994:
-
Summary: Camel-aws2-kinesis: Integration test does not work -
KinesisComponentManualIT
Key: CAMEL-17994
URL: https://issues.apache.org/jira/browse/CAMEL-17994
Project: Camel
Issue Type: Test
Components: camel-aws2, tests
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
There is a code in the test
{quote}Record record = resultExchange.getIn().getBody(Record.class);
assertEquals(data, new String(record.data().asByteArray()));
{quote}
Body of the exchange is already converted in to InputStream in Kinesis2Consumer
class.
Working code should be:
{quote}assertEquals(data,resultExchange.getIn().getBody(String.class));
{quote}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CAMEL-17993) Add tests in camel-ftp-starter
Jiri Ondrusek created CAMEL-17993: - Summary: Add tests in camel-ftp-starter Key: CAMEL-17993 URL: https://issues.apache.org/jira/browse/CAMEL-17993 Project: Camel Issue Type: Test Components: camel-ftp, camel-spring-boot-starters, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-17982) Add tests in camel-aws2-kinesis
Jiri Ondrusek created CAMEL-17982: - Summary: Add tests in camel-aws2-kinesis Key: CAMEL-17982 URL: https://issues.apache.org/jira/browse/CAMEL-17982 Project: Camel Issue Type: Test Components: camel-aws2, camel-spring-boot-starters, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17965) Camel-file: There is an unknowm parameter in documentation`overruleFile`
Jiri Ondrusek created CAMEL-17965:
-
Summary: Camel-file: There is an unknowm parameter in
documentation`overruleFile`
Key: CAMEL-17965
URL: https://issues.apache.org/jira/browse/CAMEL-17965
Project: Camel
Issue Type: Bug
Components: camel-file, documentation
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
There is a sample for users in documentation, which uses unknown parameter
[overruleFile|https://camel.apache.org/components/3.16.x/file-component.html#_read_from_a_directory_and_write_to_another_directory_using_a_overrule_dynamic_name].
{quote}There are 1 parameters that couldn't be set on the endpoint. Check the
uri if the parameters are spelt correctly and that they are properties of the
endpoint. Unknown parameters=[\{overruleFile=copy-of-${file:name}}]
{quote}
Parameter _fileName_ could be use instead of {_}overruleFile{_}, to achieve the
same result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CAMEL-17959) Add tests in camel-file-starter
Jiri Ondrusek created CAMEL-17959: - Summary: Add tests in camel-file-starter Key: CAMEL-17959 URL: https://issues.apache.org/jira/browse/CAMEL-17959 Project: Camel Issue Type: Test Components: camel-file, camel-spring-boot-starters, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17938) Add tests in camel-aws2-cw-starter
Jiri Ondrusek created CAMEL-17938: - Summary: Add tests in camel-aws2-cw-starter Key: CAMEL-17938 URL: https://issues.apache.org/jira/browse/CAMEL-17938 Project: Camel Issue Type: Test Components: camel-aws2, camel-spring-boot-starters, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17920) add tests in camel-aws2-s3-starter
Jiri Ondrusek created CAMEL-17920: - Summary: add tests in camel-aws2-s3-starter Key: CAMEL-17920 URL: https://issues.apache.org/jira/browse/CAMEL-17920 Project: Camel Issue Type: Test Components: camel-aws2, camel-spring-boot-starters, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17915) add tests in camel-aws2-sns-starter - deduplication strategy is not covered
Jiri Ondrusek created CAMEL-17915: - Summary: add tests in camel-aws2-sns-starter - deduplication strategy is not covered Key: CAMEL-17915 URL: https://issues.apache.org/jira/browse/CAMEL-17915 Project: Camel Issue Type: Test Components: camel-aws2, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek I noticed that topic [message deduplication id strategy|https://camel.apache.org/components/3.16.x/aws2-sns-component.html#_sns_fifo_topic_message_group_id_strategy_and_message_deduplication_id_strategy] is not covered by componenet tests (or spring-boot-starter tests). It would be nice to have it covered. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17909) add tests in camel-aws2-sns-starter
Jiri Ondrusek created CAMEL-17909: - Summary: add tests in camel-aws2-sns-starter Key: CAMEL-17909 URL: https://issues.apache.org/jira/browse/CAMEL-17909 Project: Camel Issue Type: Test Components: camel-aws2, camel-spring-boot-starters, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17846) add tests in camel-aws2-ddb-starter
[ https://issues.apache.org/jira/browse/CAMEL-17846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517480#comment-17517480 ] Jiri Ondrusek commented on CAMEL-17846: --- R [https://github.com/apache/camel-spring-boot/pull/481] > add tests in camel-aws2-ddb-starter > --- > > Key: CAMEL-17846 > URL: https://issues.apache.org/jira/browse/CAMEL-17846 > Project: Camel > Issue Type: Test > Components: camel-aws2, camel-spring-boot-starters, tests >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.17.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] (CAMEL-17846) add tests in camel-aws2-ddb-starter
[ https://issues.apache.org/jira/browse/CAMEL-17846 ] Jiri Ondrusek deleted comment on CAMEL-17846: --- was (Author: jondruse): PR https://github.com/apache/camel-spring-boot/pull/481 > add tests in camel-aws2-ddb-starter > --- > > Key: CAMEL-17846 > URL: https://issues.apache.org/jira/browse/CAMEL-17846 > Project: Camel > Issue Type: Test > Components: camel-aws2, camel-spring-boot-starters, tests >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.17.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17905) add tests in camel-aws2-sqs-starter - follow-up
Jiri Ondrusek created CAMEL-17905: - Summary: add tests in camel-aws2-sqs-starter - follow-up Key: CAMEL-17905 URL: https://issues.apache.org/jira/browse/CAMEL-17905 Project: Camel Issue Type: Test Components: camel-aws2, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek Once https://issues.apache.org/jira/browse/CAMEL-17904 is fixed, extend coverage to spring-boot starter (follow-up for https://issues.apache.org/jira/browse/CAMEL-17860) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17904) Revisit tests for "server side encryption" and "deduplication strategy" in camel-aws2-sqs
Jiri Ondrusek created CAMEL-17904: - Summary: Revisit tests for "server side encryption" and "deduplication strategy" in camel-aws2-sqs Key: CAMEL-17904 URL: https://issues.apache.org/jira/browse/CAMEL-17904 Project: Camel Issue Type: Test Components: camel-aws2, tests Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek During development of https://issues.apache.org/jira/browse/CAMEL-17860, i found that there are 2 use cases in documentation which are not covered (server side encryption) or not working correctly (deduplication strategy) in component tests. It would be nice to cover/fix them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17860) add tests in camel-aws2-sqs-starter
Jiri Ondrusek created CAMEL-17860: - Summary: add tests in camel-aws2-sqs-starter Key: CAMEL-17860 URL: https://issues.apache.org/jira/browse/CAMEL-17860 Project: Camel Issue Type: Test Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17846) add tests in camel-aws2-ddb-starter
[ https://issues.apache.org/jira/browse/CAMEL-17846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512424#comment-17512424 ] Jiri Ondrusek commented on CAMEL-17846: --- PR https://github.com/apache/camel-spring-boot/pull/481 > add tests in camel-aws2-ddb-starter > --- > > Key: CAMEL-17846 > URL: https://issues.apache.org/jira/browse/CAMEL-17846 > Project: Camel > Issue Type: Test > Components: camel-aws2, camel-spring-boot-starters, tests >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
