[jira] [Resolved] (CAMEL-21357) camel-jq: Add ability to resolve the root scope from the registry
[ https://issues.apache.org/jira/browse/CAMEL-21357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-21357. - Resolution: Fixed > camel-jq: Add ability to resolve the root scope from the registry > - > > Key: CAMEL-21357 > URL: https://issues.apache.org/jira/browse/CAMEL-21357 > Project: Camel > Issue Type: Improvement > Components: camel-jq >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.8.1, 4.9.0 > > > Relates to this Camel Quarkus issue: > https://github.com/apache/camel-quarkus/issues/6651 > In CQ, there's already an existing scope where most JQ functions are already > resolved at build time. So it'd be better for Camel to reuse it and then > augment with its own custom functions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21357) camel-jq: Add ability to resolve the root scope from the registry
James Netherton created CAMEL-21357: --- Summary: camel-jq: Add ability to resolve the root scope from the registry Key: CAMEL-21357 URL: https://issues.apache.org/jira/browse/CAMEL-21357 Project: Camel Issue Type: Improvement Components: camel-jq Reporter: James Netherton Assignee: James Netherton Fix For: 4.8.1, 4.9.0 Relates to this Camel Quarkus issue: https://github.com/apache/camel-quarkus/issues/6651 In CQ, there's already an existing scope where most JQ functions are already resolved at build time. So it'd be better for Camel to reuse it and then augment with its own custom functions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21218) camel-quarkus - BindToRegistry seems NOT to work outside RouteBuilder
[
https://issues.apache.org/jira/browse/CAMEL-21218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882683#comment-17882683
]
James Netherton commented on CAMEL-21218:
-
There's a CQ issue to track the work here:
https://github.com/apache/camel-quarkus/issues/6479
Since we're close to cutting an LTS release, I'll leave it for >= CQ 3.16.0. We
could consider backporting it for 3.15.x later.
> camel-quarkus - BindToRegistry seems NOT to work outside RouteBuilder
> -
>
> Key: CAMEL-21218
> URL: https://issues.apache.org/jira/browse/CAMEL-21218
> Project: Camel
> Issue Type: Bug
> Components: camel-quarkus
>Reporter: Bruno Meseguer
>Priority: Minor
> Fix For: 4.x
>
> Attachments: report.tar.gz
>
>
> It seems Camel Quarkus is not able to pick up beans defined with:
> {code:java}
> @BindToRegistry{code}
> When defined outside a RouteBuilder.
> However, if ported inside a RouteBuilder all seems good.
> Developers may want to define Beans outside the RouteBuilder class, it makes
> sense Camel Quarkus finds them when starting up.
>
> Find attached a reproduceable.
> If started with:
> {code:java}
> ./mvnw quarkus:dev{code}
> it will fail.
> Then try uncommenting the "myProcessor" code inside the RouteBuilder in the
> file "routes.java"/
> Camel Quarkus the starts and succeeds to execute.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21218) camel-quarkus - BindToRegistry seems NOT to work outside RouteBuilder
[
https://issues.apache.org/jira/browse/CAMEL-21218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882303#comment-17882303
]
James Netherton commented on CAMEL-21218:
-
It works for routes because the bean post processor runs which discovers any
BindToRegistry annotated stuff in the bean class.
We can probably discover any BindToRegistry bits at build time and get them
bound to the registry.
> camel-quarkus - BindToRegistry seems NOT to work outside RouteBuilder
> -
>
> Key: CAMEL-21218
> URL: https://issues.apache.org/jira/browse/CAMEL-21218
> Project: Camel
> Issue Type: Bug
> Components: camel-quarkus
>Reporter: Bruno Meseguer
>Priority: Minor
> Attachments: report.tar.gz
>
>
> It seems Camel Quarkus is not able to pick up beans defined with:
> {code:java}
> @BindToRegistry{code}
> When defined outside a RouteBuilder.
> However, if ported inside a RouteBuilder all seems good.
> Developers may want to define Beans outside the RouteBuilder class, it makes
> sense Camel Quarkus finds them when starting up.
>
> Find attached a reproduceable.
> If started with:
> {code:java}
> ./mvnw quarkus:dev{code}
> it will fail.
> Then try uncommenting the "myProcessor" code inside the RouteBuilder in the
> file "routes.java"/
> Camel Quarkus the starts and succeeds to execute.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-21177) camel-datasonnet: Enable libsonnet libraries to be discovered at build time
[ https://issues.apache.org/jira/browse/CAMEL-21177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-21177. - Fix Version/s: 4.8.0 Resolution: Fixed > camel-datasonnet: Enable libsonnet libraries to be discovered at build time > --- > > Key: CAMEL-21177 > URL: https://issues.apache.org/jira/browse/CAMEL-21177 > Project: Camel > Issue Type: Improvement >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.8.0 > > > The main motivation here is for Camel Quarkus. It'd be nice to avoid doing > resource discovery in a static initializer within DatasonnetLanguage and > allow any discovered resources to be passed in via a constructor. > On CQ, this avoids the need for classgraph since resource discovery can be > done at build time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-21156) camel-hashicorp-vault: Allow SecretPath header to be used on create & delete operations
[ https://issues.apache.org/jira/browse/CAMEL-21156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-21156. - Resolution: Fixed > camel-hashicorp-vault: Allow SecretPath header to be used on create & delete > operations > --- > > Key: CAMEL-21156 > URL: https://issues.apache.org/jira/browse/CAMEL-21156 > Project: Camel > Issue Type: Improvement > Components: camel-hashicorp-vault >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.8.0 > > > Currently you can use the SecretPath header on the getSecret operation. It'd > be nice if you could do likewise for createSecret & deleteSecret. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21156) camel-hashicorp-vault: Allow SecretPath header to be used on create & delete operations
James Netherton created CAMEL-21156: --- Summary: camel-hashicorp-vault: Allow SecretPath header to be used on create & delete operations Key: CAMEL-21156 URL: https://issues.apache.org/jira/browse/CAMEL-21156 Project: Camel Issue Type: Improvement Components: camel-hashicorp-vault Reporter: James Netherton Assignee: James Netherton Fix For: 4.8.0 Currently you can use the SecretPath header on the getSecret operation. It'd be nice if you could do likewise for createSecret & deleteSecret. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-21154) camel-hashicorp-vault: Potential NPE in getSecret operation result handling
[ https://issues.apache.org/jira/browse/CAMEL-21154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-21154. - Fix Version/s: 4.4.4 4.8.0 Resolution: Fixed > camel-hashicorp-vault: Potential NPE in getSecret operation result handling > --- > > Key: CAMEL-21154 > URL: https://issues.apache.org/jira/browse/CAMEL-21154 > Project: Camel > Issue Type: Bug > Components: camel-hashicorp-vault >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.4.4, 4.8.0 > > > It can happen that the REST invocation for fetching secrets returns a 404. > Internally, spring-vault will return null from VaultTemplate.read. > This is not handled in HashicorpVaultProducer, so an NPE is thrown when the > secret data is attempted to be extracted from the VaultResponse object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21154) camel-hashicorp-vault: Potential NPE in getSecret operation result handling
James Netherton created CAMEL-21154: --- Summary: camel-hashicorp-vault: Potential NPE in getSecret operation result handling Key: CAMEL-21154 URL: https://issues.apache.org/jira/browse/CAMEL-21154 Project: Camel Issue Type: Bug Components: camel-hashicorp-vault Reporter: James Netherton Assignee: James Netherton It can happen that the REST invocation for fetching secrets returns a 404. Internally, spring-vault will return null from VaultTemplate.read. This is not handled in HashicorpVaultProducer, so an NPE is thrown when the secret data is attempted to be extracted from the VaultResponse object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21100) camel-azure-eventhubs: sharedAccessName & sharedAccessKey should not be required for credential type AZURE_IDENTITY
James Netherton created CAMEL-21100:
---
Summary: camel-azure-eventhubs: sharedAccessName & sharedAccessKey
should not be required for credential type AZURE_IDENTITY
Key: CAMEL-21100
URL: https://issues.apache.org/jira/browse/CAMEL-21100
Project: Camel
Issue Type: Bug
Components: camel-azure-eventhubs
Reporter: James Netherton
Assignee: James Netherton
Fix For: 4.8.0
Unless I misunderstand something, if you choose to use AZURE_IDENTITY as the
credentialType option, then there should be no need to supply either a
sharedAccessName or sharedAccessKey. Those are only required when the component
automatically builds a connection string (E.g CONNECTION_STRING credentialType
option).
But when AZURE_IDENTITY is used, you get a validation error:
{code}
Caused by: java.lang.IllegalArgumentException: Azure EventHubs
SharedAccessName/SharedAccessKey, ProducerAsyncClient, ConnectionString or
TokenCredential must be specified.
at
org.apache.camel.component.azure.eventhubs.EventHubsComponent.validateConfigurations(EventHubsComponent.java:82)
{code}
I think we can skip this validation for AZURE_IDENTITY, given that all of the
authentication info should get discovered by the azure-identity internals.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-21089) camel-core: CamelBaseBulkConverterLoader should handle conversion to byte primitive
[ https://issues.apache.org/jira/browse/CAMEL-21089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton updated CAMEL-21089: Fix Version/s: 4.4.4 > camel-core: CamelBaseBulkConverterLoader should handle conversion to byte > primitive > --- > > Key: CAMEL-21089 > URL: https://issues.apache.org/jira/browse/CAMEL-21089 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.4.4, 4.8.0 > > > Relates to an issue reported in Camel Quarkus where a user was trying to > configure a byte component option for SMPP. > https://github.com/apache/camel-quarkus/issues/6350 > Seems that CamelBaseBulkConverterLoader does not have a condition to match > the conversion type on primitive byte.class. > https://github.com/apache/camel/blob/e5ab1649bdb5c5a9c332af2c5b201c143f611539/core/camel-base/src/generated/java/org/apache/camel/converter/CamelBaseBulkConverterLoader.java#L202-L216 > Indeed the Maven mojo that generates the bulk converter does not handle byte > as a primitive option. > https://github.com/apache/camel/blob/e5ab1649bdb5c5a9c332af2c5b201c143f611539/tooling/maven/camel-package-maven-plugin/src/main/java/org/apache/camel/maven/packaging/TypeConverterLoaderGeneratorMojo.java#L220-L240 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-21089) camel-core: CamelBaseBulkConverterLoader should handle conversion to byte primitive
[ https://issues.apache.org/jira/browse/CAMEL-21089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-21089. - Resolution: Fixed > camel-core: CamelBaseBulkConverterLoader should handle conversion to byte > primitive > --- > > Key: CAMEL-21089 > URL: https://issues.apache.org/jira/browse/CAMEL-21089 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.8.0 > > > Relates to an issue reported in Camel Quarkus where a user was trying to > configure a byte component option for SMPP. > https://github.com/apache/camel-quarkus/issues/6350 > Seems that CamelBaseBulkConverterLoader does not have a condition to match > the conversion type on primitive byte.class. > https://github.com/apache/camel/blob/e5ab1649bdb5c5a9c332af2c5b201c143f611539/core/camel-base/src/generated/java/org/apache/camel/converter/CamelBaseBulkConverterLoader.java#L202-L216 > Indeed the Maven mojo that generates the bulk converter does not handle byte > as a primitive option. > https://github.com/apache/camel/blob/e5ab1649bdb5c5a9c332af2c5b201c143f611539/tooling/maven/camel-package-maven-plugin/src/main/java/org/apache/camel/maven/packaging/TypeConverterLoaderGeneratorMojo.java#L220-L240 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21089) camel-core: CamelBaseBulkConverterLoader should handle conversion to byte primitive
James Netherton created CAMEL-21089: --- Summary: camel-core: CamelBaseBulkConverterLoader should handle conversion to byte primitive Key: CAMEL-21089 URL: https://issues.apache.org/jira/browse/CAMEL-21089 Project: Camel Issue Type: Improvement Components: camel-core Reporter: James Netherton Assignee: James Netherton Fix For: 4.8.0 Relates to an issue reported in Camel Quarkus where a user was trying to configure a byte component option for SMPP. https://github.com/apache/camel-quarkus/issues/6350 Seems that CamelBaseBulkConverterLoader does not have a condition to match the conversion type on primitive byte.class. https://github.com/apache/camel/blob/e5ab1649bdb5c5a9c332af2c5b201c143f611539/core/camel-base/src/generated/java/org/apache/camel/converter/CamelBaseBulkConverterLoader.java#L202-L216 Indeed the Maven mojo that generates the bulk converter does not handle byte as a primitive option. https://github.com/apache/camel/blob/e5ab1649bdb5c5a9c332af2c5b201c143f611539/tooling/maven/camel-package-maven-plugin/src/main/java/org/apache/camel/maven/packaging/TypeConverterLoaderGeneratorMojo.java#L220-L240 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-21043) Make SyncPropertiesMojo dynamically determine the POM template version for the org.apache:apache parent
[ https://issues.apache.org/jira/browse/CAMEL-21043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-21043. - Resolution: Fixed > Make SyncPropertiesMojo dynamically determine the POM template version for > the org.apache:apache parent > --- > > Key: CAMEL-21043 > URL: https://issues.apache.org/jira/browse/CAMEL-21043 > Project: Camel > Issue Type: Improvement > Components: tooling >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.8.0 > > > I was digging into why Dependabot is not updating some Maven plugins in CQ > and it turns out it's because camel-dependencies has an old org.apache:apache > parent. > https://github.com/apache/camel/blob/main/tooling/maven/sync-properties-maven-plugin/src/main/resources/camel-dependencies-template.xml#L27 > It should be aligned with whatever Camel has in its root pom.xml. E.g this > https://github.com/apache/camel/blob/main/pom.xml#L24-L28 > We should be able to get the sync-properties-maven-plugin to figure out the > correct version instead of hard coding it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21043) Make SyncPropertiesMojo dynamically determine the POM template version for the org.apache:apache parent
James Netherton created CAMEL-21043: --- Summary: Make SyncPropertiesMojo dynamically determine the POM template version for the org.apache:apache parent Key: CAMEL-21043 URL: https://issues.apache.org/jira/browse/CAMEL-21043 Project: Camel Issue Type: Improvement Components: tooling Reporter: James Netherton Assignee: James Netherton Fix For: 4.8.0 I was digging into why Dependabot is not updating some Maven plugins in CQ and it turns out it's because camel-dependencies has an old org.apache:apache parent. https://github.com/apache/camel/blob/main/tooling/maven/sync-properties-maven-plugin/src/main/resources/camel-dependencies-template.xml#L27 It should be aligned with whatever Camel has in its root pom.xml. E.g this https://github.com/apache/camel/blob/main/pom.xml#L24-L28 We should be able to get the sync-properties-maven-plugin to figure out the correct version instead of hard coding it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-21003) camel-main: Unable to enable debug profile in Camel Quarkus due to FileNotFoundException
[ https://issues.apache.org/jira/browse/CAMEL-21003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-21003. - Resolution: Fixed > camel-main: Unable to enable debug profile in Camel Quarkus due to > FileNotFoundException > > > Key: CAMEL-21003 > URL: https://issues.apache.org/jira/browse/CAMEL-21003 > Project: Camel > Issue Type: Bug > Components: camel-main >Affects Versions: 4.7.0 >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.8.0 > > > Something I came across when working on this task: > [https://github.com/apache/camel-quarkus/issues/6083] > In Camel Quarkus we have some logic to suppress Camel resolving properties > from property sources other then those used by MicroProfile Config: > [https://github.com/apache/camel-quarkus/blob/803e96645110ac555bec08e96d6723521c5487bf/extensions-core/core/runtime/src/main/java/org/apache/camel/quarkus/main/CamelMainRecorder.java#L46-L48] > And there's a check for it in camel-main here: > [https://github.com/apache/camel/blob/f911e2c1d6fa4561ffb88019889b2d530dd5a2b2/core/camel-main/src/main/java/org/apache/camel/main/BaseMainSupport.java#L398] > However, when the 'dev' profile is activated, this check fails because the > locations string is concatenated with other info. It'd probably be enough to > tweak the if condition to also check if locations ends with ',false'. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-21003) camel-main: Unable to enable debug profile in Camel Quarkus due to FileNotFoundException
[ https://issues.apache.org/jira/browse/CAMEL-21003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton updated CAMEL-21003: Summary: camel-main: Unable to enable debug profile in Camel Quarkus due to FileNotFoundException (was: camel-main: Unable to enabling debug profile in Camel Quarkus due to FileNotFoundException) > camel-main: Unable to enable debug profile in Camel Quarkus due to > FileNotFoundException > > > Key: CAMEL-21003 > URL: https://issues.apache.org/jira/browse/CAMEL-21003 > Project: Camel > Issue Type: Bug > Components: camel-main >Affects Versions: 4.7.0 >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.8.0 > > > Something I came across when working on this task: > [https://github.com/apache/camel-quarkus/issues/6083] > In Camel Quarkus we have some logic to suppress Camel resolving properties > from property sources other then those used by MicroProfile Config: > [https://github.com/apache/camel-quarkus/blob/803e96645110ac555bec08e96d6723521c5487bf/extensions-core/core/runtime/src/main/java/org/apache/camel/quarkus/main/CamelMainRecorder.java#L46-L48] > And there's a check for it in camel-main here: > [https://github.com/apache/camel/blob/f911e2c1d6fa4561ffb88019889b2d530dd5a2b2/core/camel-main/src/main/java/org/apache/camel/main/BaseMainSupport.java#L398] > However, when the 'dev' profile is activated, this check fails because the > locations string is concatenated with other info. It'd probably be enough to > tweak the if condition to also check if locations ends with ',false'. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21003) camel-main: Unable to enabling debug profile in Camel Quarkus due to FileNotFoundException
James Netherton created CAMEL-21003: --- Summary: camel-main: Unable to enabling debug profile in Camel Quarkus due to FileNotFoundException Key: CAMEL-21003 URL: https://issues.apache.org/jira/browse/CAMEL-21003 Project: Camel Issue Type: Bug Components: camel-main Affects Versions: 4.7.0 Reporter: James Netherton Assignee: James Netherton Fix For: 4.8.0 Something I came across when working on this task: [https://github.com/apache/camel-quarkus/issues/6083] In Camel Quarkus we have some logic to suppress Camel resolving properties from property sources other then those used by MicroProfile Config: [https://github.com/apache/camel-quarkus/blob/803e96645110ac555bec08e96d6723521c5487bf/extensions-core/core/runtime/src/main/java/org/apache/camel/quarkus/main/CamelMainRecorder.java#L46-L48] And there's a check for it in camel-main here: [https://github.com/apache/camel/blob/f911e2c1d6fa4561ffb88019889b2d530dd5a2b2/core/camel-main/src/main/java/org/apache/camel/main/BaseMainSupport.java#L398] However, when the 'dev' profile is activated, this check fails because the locations string is concatenated with other info. It'd probably be enough to tweak the if condition to also check if locations ends with ',false'. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20901) camel-arangodb: Add the option to provide a custom Vertx instance
[ https://issues.apache.org/jira/browse/CAMEL-20901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20901. - Fix Version/s: 4.7.0 (was: 4.x) Resolution: Fixed > camel-arangodb: Add the option to provide a custom Vertx instance > - > > Key: CAMEL-20901 > URL: https://issues.apache.org/jira/browse/CAMEL-20901 > Project: Camel > Issue Type: Improvement > Components: camel-arangodb >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.7.0 > > > ArangoDB 7.7.1 made is possible to provide a custom Vertx instance for the > ArangoDB client. > This is useful for Camel Quarkus where there's already an existing managed > Vertx. Currently the client will create its own Vert.x instance. Which is a > waste of resources and causes some ugly log warnings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20901) camel-arangodb: Add the option to provide a custom Vertx instance
James Netherton created CAMEL-20901: --- Summary: camel-arangodb: Add the option to provide a custom Vertx instance Key: CAMEL-20901 URL: https://issues.apache.org/jira/browse/CAMEL-20901 Project: Camel Issue Type: Improvement Components: camel-arangodb Reporter: James Netherton Assignee: James Netherton Fix For: 4.x ArangoDB 7.7.1 made is possible to provide a custom Vertx instance for the ArangoDB client. This is useful for Camel Quarkus where there's already an existing managed Vertx. Currently the client will create its own Vert.x instance. Which is a waste of resources and causes some ugly log warnings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20800) camel-couchdb: gson upgrade to 2.11.0 breaks the component
[
https://issues.apache.org/jira/browse/CAMEL-20800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17854749#comment-17854749
]
James Netherton commented on CAMEL-20800:
-
Yeah, I completely missed that the Lightcouch project is inactive.
Seems you're right and cloudant-java-sdk is the only other client project that
has recent releases. Looks like it aligns with gson 2.11 too.
No idea how much effort it'd be to migrate to using it. But I guess if we want
to continue supporting couchdb for the long term, we have to move away from
Lightcouch.
> camel-couchdb: gson upgrade to 2.11.0 breaks the component
> --
>
> Key: CAMEL-20800
> URL: https://issues.apache.org/jira/browse/CAMEL-20800
> Project: Camel
> Issue Type: Dependency upgrade
> Components: camel-gson
>Reporter: Otavio Rodolfo Piske
>Priority: Major
> Fix For: 4.x
>
>
> Ref.:
> [https://github.com/apache/camel/commit/60ad51f7d69c3d7f6ccf7443e436500da61ba658]
>
> The tests are broken with the following error:
>
> {code:java}
> Failed to start route route1 because of Cannot override built-in adapter for
> class com.google.gson.JsonObject{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20873) camel-platform-http-vertx: Responses may not complete if exceptions are thrown in VertxPlatformHttpSupport.writeResponse
[ https://issues.apache.org/jira/browse/CAMEL-20873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20873. - Resolution: Fixed > camel-platform-http-vertx: Responses may not complete if exceptions are > thrown in VertxPlatformHttpSupport.writeResponse > > > Key: CAMEL-20873 > URL: https://issues.apache.org/jira/browse/CAMEL-20873 > Project: Camel > Issue Type: Bug > Components: camel-platform-http-vertx >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.4.3, 4.7.0 > > > In VertxPlatformHttpSupport.writeResponse, the only exception that is handled > is when fallback type conversion fails on the message body: > https://github.com/apache/camel/blob/4621c36131a32fa340e6ab5975126d207a104fe5/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpSupport.java#L179-L205 > However, it can potentially happen that other parts of processing the > response, such as adding HTTP headers, can fail and cause an exception. In > this case, the Vert.x promise is left unfulfilled and thus the response may > not complete correctly. > It is probably better to wrap all of the writeResponse method code in a try / > catch block so the promise can be correctly set in a failed state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20873) camel-platform-http-vertx: Responses may not complete if exceptions are thrown in VertxPlatformHttpSupport.writeResponse
James Netherton created CAMEL-20873: --- Summary: camel-platform-http-vertx: Responses may not complete if exceptions are thrown in VertxPlatformHttpSupport.writeResponse Key: CAMEL-20873 URL: https://issues.apache.org/jira/browse/CAMEL-20873 Project: Camel Issue Type: Bug Components: camel-platform-http-vertx Reporter: James Netherton Assignee: James Netherton Fix For: 4.4.3, 4.7.0 In VertxPlatformHttpSupport.writeResponse, the only exception that is handled is when fallback type conversion fails on the message body: https://github.com/apache/camel/blob/4621c36131a32fa340e6ab5975126d207a104fe5/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpSupport.java#L179-L205 However, it can potentially happen that other parts of processing the response, such as adding HTTP headers, can fail and cause an exception. In this case, the Vert.x promise is left unfulfilled and thus the response may not complete correctly. It is probably better to wrap all of the writeResponse method code in a try / catch block so the promise can be correctly set in a failed state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20865) camel-elasticsearch-rest-client: Add usage details to component documentation
[ https://issues.apache.org/jira/browse/CAMEL-20865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20865. - Resolution: Fixed > camel-elasticsearch-rest-client: Add usage details to component documentation > - > > Key: CAMEL-20865 > URL: https://issues.apache.org/jira/browse/CAMEL-20865 > Project: Camel > Issue Type: Improvement > Components: documentation >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.7.0 > > > The elasticsearch-rest-client docs are a little thin on detail. It'd be good > to do like the camel-elasticsearch component and have an overview of the > supported operations and how they are used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20865) camel-elasticsearch-rest-client: Add usage details to component documentation
James Netherton created CAMEL-20865: --- Summary: camel-elasticsearch-rest-client: Add usage details to component documentation Key: CAMEL-20865 URL: https://issues.apache.org/jira/browse/CAMEL-20865 Project: Camel Issue Type: Improvement Components: documentation Reporter: James Netherton Assignee: James Netherton Fix For: 4.7.0 The elasticsearch-rest-client docs are a little thin on detail. It'd be good to do like the camel-elasticsearch component and have an overview of the supported operations and how they are used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20851) camel-elasticsearch-rest-client: Sniffer should be closed on producer stop
James Netherton created CAMEL-20851:
---
Summary: camel-elasticsearch-rest-client: Sniffer should be closed
on producer stop
Key: CAMEL-20851
URL: https://issues.apache.org/jira/browse/CAMEL-20851
Project: Camel
Issue Type: Improvement
Reporter: James Netherton
Assignee: James Netherton
Fix For: 4.x
Quoting from the [ES client
docs|https://www.elastic.co/guide/en/elasticsearch/client/java-api-client/current/_usage.html]:
{quote}
It is important to close the Sniffer so that its background thread gets
properly shutdown and all of its resources are released. The Sniffer object
should have the same lifecycle as the RestClient and get closed right before
the client
{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20846) camel-elasticsearch-rest-client: Add component options
James Netherton created CAMEL-20846: --- Summary: camel-elasticsearch-rest-client: Add component options Key: CAMEL-20846 URL: https://issues.apache.org/jira/browse/CAMEL-20846 Project: Camel Issue Type: Improvement Reporter: James Netherton Assignee: James Netherton Fix For: 4.x Currently, you can only configure camel-elasticsearch-rest-client using endpoint options. It'd be nice to do like camel-elasticsearch and have most of those options available as component options. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20836) camel-qdrant: Add support for deleting a collection
[ https://issues.apache.org/jira/browse/CAMEL-20836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20836. - Resolution: Fixed > camel-qdrant: Add support for deleting a collection > --- > > Key: CAMEL-20836 > URL: https://issues.apache.org/jira/browse/CAMEL-20836 > Project: Camel > Issue Type: Improvement > Components: camel-qdrant >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.7.0 > > > Minor thing I noticed while experimenting with camel-qdrant. There's no > action to delete a collection. So currently you're forced to do it via the > web UI or use the Qdrant client directly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20836) camel-qdrant: Add support for deleting a collection
James Netherton created CAMEL-20836: --- Summary: camel-qdrant: Add support for deleting a collection Key: CAMEL-20836 URL: https://issues.apache.org/jira/browse/CAMEL-20836 Project: Camel Issue Type: Improvement Components: camel-qdrant Reporter: James Netherton Assignee: James Netherton Fix For: 4.7.0 Minor thing I noticed while experimenting with camel-qdrant. There's no action to delete a collection. So currently you're forced to do it via the web UI or use the Qdrant client directly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20800) camel-couchdb: gson upgrade to 2.11.0 breaks the component
[
https://issues.apache.org/jira/browse/CAMEL-20800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852304#comment-17852304
]
James Netherton commented on CAMEL-20800:
-
The latest Quarkus SNAPSHOTs use gson 2.11 so I see the same issue in Camel
Quarkus. I opened an issue in the LightCouch project:
https://github.com/lightcouch/LightCouch/issues/82
> camel-couchdb: gson upgrade to 2.11.0 breaks the component
> --
>
> Key: CAMEL-20800
> URL: https://issues.apache.org/jira/browse/CAMEL-20800
> Project: Camel
> Issue Type: Task
> Components: camel-gson
>Reporter: Otavio Rodolfo Piske
>Priority: Major
>
> Ref.:
> [https://github.com/apache/camel/commit/60ad51f7d69c3d7f6ccf7443e436500da61ba658]
>
> The tests are broken with the following error:
>
> {code:java}
> Failed to start route route1 because of Cannot override built-in adapter for
> class com.google.gson.JsonObject{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20719) camel-milvus: Exclude troublesome bulk writer related dependencies
James Netherton created CAMEL-20719: --- Summary: camel-milvus: Exclude troublesome bulk writer related dependencies Key: CAMEL-20719 URL: https://issues.apache.org/jira/browse/CAMEL-20719 Project: Camel Issue Type: Improvement Components: camel-milvus Reporter: James Netherton Assignee: James Netherton Fix For: 4.6.0 Since the introduction of bulk writer support in the Milvus Java SDK, there are various transitive dependencies that cause some pain. Mainly hadoop, which depends on Jetty 9.x and other non-jakarta compliant & CVE affected stuff. Since the component does not have any bulk writer support. We could try to add maven exclusions for unwanted transitives. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20700) camel-core: ReflectionHelper.setField may fail for numeric type fields
James Netherton created CAMEL-20700:
---
Summary: camel-core: ReflectionHelper.setField may fail for
numeric type fields
Key: CAMEL-20700
URL: https://issues.apache.org/jira/browse/CAMEL-20700
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 4.5.0, 4.4.0, 4.3.0
Reporter: James Netherton
Originally reported here:
[https://camel.zulipchat.com/#narrow/stream/257302-camel-quarkus/topic/PropertyInject.20failure.20in.20CxfConfigurer]
If you use @PropertyInject like:
{code:java}
public class Foo {
@PropertyInject(value = "1")
private Integer bar;
}
{code}
Then you get an exception like:
{code:java}
java.lang.UnsupportedOperationException: Cannot inject value of class: class
java.lang.Integer into: private java.lang.Integer
{code}
The original exception is swallowed, but it's something like:
{code:java}
IllegalArgumentException: Can not set java.lang.Integer field to int(1)
{code}
You can't use Field.setInt etc where the field type is not a primitive. You
have to use Field.set in that case.
[https://docs.oracle.com/javase/tutorial/reflect/member/fieldTrouble.html]
Maybe it's related to this change:
[https://github.com/apache/camel/commit/df19aec009164ba821c60518651dfc5eda3aee7d]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20684) camel-microprofile-fault-tolerance: ThreadTimer should be a singleton
James Netherton created CAMEL-20684: --- Summary: camel-microprofile-fault-tolerance: ThreadTimer should be a singleton Key: CAMEL-20684 URL: https://issues.apache.org/jira/browse/CAMEL-20684 Project: Camel Issue Type: Improvement Components: camel-microprofile-fault-tolerance Reporter: James Netherton Fix For: 4.6.0 Something I missed when upgrading SmallRye Fault Tolerance to 6.3.0 is that the use of ThreadTimer requires it to be a singleton. You can't create a multiple instances with a custom executor on each init of FaultToleranceProcessor. [https://github.com/smallrye/smallrye-fault-tolerance/blob/3d92e94269619115062a55f145b6b07eda18452f/implementation/core/src/main/java/io/smallrye/faulttolerance/core/timer/ThreadTimer.java#L67] For Quarkus, there's already a singleton scoped CDI bean containing the ThreadTimer, so we could wire that into the Camel registry and look it up later. Not sure how best to manage it for non-quarkus apps. You'd need to manage the lifecycle of the ThreadTimer & executor on Camel startup / shutdown. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20684) camel-microprofile-fault-tolerance: ThreadTimer should be a singleton
[ https://issues.apache.org/jira/browse/CAMEL-20684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton updated CAMEL-20684: Description: Something I missed when upgrading SmallRye Fault Tolerance to 6.3.0 is that the use of ThreadTimer requires it to be a singleton. You can't create multiple instances with a custom executor on each init of FaultToleranceProcessor. [https://github.com/smallrye/smallrye-fault-tolerance/blob/3d92e94269619115062a55f145b6b07eda18452f/implementation/core/src/main/java/io/smallrye/faulttolerance/core/timer/ThreadTimer.java#L67] For Quarkus, there's already a singleton scoped CDI bean containing the ThreadTimer, so we could wire that into the Camel registry and look it up later. Not sure how best to manage it for non-quarkus apps. You'd need to manage the lifecycle of the ThreadTimer & executor on Camel startup / shutdown. was: Something I missed when upgrading SmallRye Fault Tolerance to 6.3.0 is that the use of ThreadTimer requires it to be a singleton. You can't create a multiple instances with a custom executor on each init of FaultToleranceProcessor. [https://github.com/smallrye/smallrye-fault-tolerance/blob/3d92e94269619115062a55f145b6b07eda18452f/implementation/core/src/main/java/io/smallrye/faulttolerance/core/timer/ThreadTimer.java#L67] For Quarkus, there's already a singleton scoped CDI bean containing the ThreadTimer, so we could wire that into the Camel registry and look it up later. Not sure how best to manage it for non-quarkus apps. You'd need to manage the lifecycle of the ThreadTimer & executor on Camel startup / shutdown. > camel-microprofile-fault-tolerance: ThreadTimer should be a singleton > - > > Key: CAMEL-20684 > URL: https://issues.apache.org/jira/browse/CAMEL-20684 > Project: Camel > Issue Type: Improvement > Components: camel-microprofile-fault-tolerance >Reporter: James Netherton >Priority: Minor > Fix For: 4.6.0 > > > Something I missed when upgrading SmallRye Fault Tolerance to 6.3.0 is that > the use of ThreadTimer requires it to be a singleton. You can't create > multiple instances with a custom executor on each init of > FaultToleranceProcessor. > [https://github.com/smallrye/smallrye-fault-tolerance/blob/3d92e94269619115062a55f145b6b07eda18452f/implementation/core/src/main/java/io/smallrye/faulttolerance/core/timer/ThreadTimer.java#L67] > For Quarkus, there's already a singleton scoped CDI bean containing the > ThreadTimer, so we could wire that into the Camel registry and look it up > later. > Not sure how best to manage it for non-quarkus apps. You'd need to manage the > lifecycle of the ThreadTimer & executor on Camel startup / shutdown. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20670) camel-platform-http-vertx: Multipart attachment id should be consistent with other HTTP components
[ https://issues.apache.org/jira/browse/CAMEL-20670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20670. - Resolution: Fixed > camel-platform-http-vertx: Multipart attachment id should be consistent with > other HTTP components > -- > > Key: CAMEL-20670 > URL: https://issues.apache.org/jira/browse/CAMEL-20670 > Project: Camel > Issue Type: Improvement > Components: camel-platform-http-vertx >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.6.0 > > > Originally reported here: > [https://github.com/apache/camel-quarkus/issues/5981] > When the platform-http-vertx consumer adds an attachment to the > AttachmentMessage, it uses the actual file name of the uploaded content as > the id. > [https://github.com/apache/camel/blob/450c4a6228711bf947f9beb8ec65ab801959a0c0/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpConsumer.java#L343] > We should change it to be consistent with other HTTP components and use the > 'name' attribute of the Content-Disposition sent in the request body. E.g > this: > [https://github.com/apache/camel/blob/450c4a6228711bf947f9beb8ec65ab801959a0c0/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpConsumer.java#L323] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20670) camel-platform-http-vertx: Multipart attachment id should be consistent with other HTTP components
James Netherton created CAMEL-20670: --- Summary: camel-platform-http-vertx: Multipart attachment id should be consistent with other HTTP components Key: CAMEL-20670 URL: https://issues.apache.org/jira/browse/CAMEL-20670 Project: Camel Issue Type: Improvement Components: camel-platform-http-vertx Reporter: James Netherton Assignee: James Netherton Fix For: 4.6.0 Originally reported here: [https://github.com/apache/camel-quarkus/issues/5981] When the platform-http-vertx consumer adds an attachment to the AttachmentMessage, it uses the actual file name of the uploaded content as the id. [https://github.com/apache/camel/blob/450c4a6228711bf947f9beb8ec65ab801959a0c0/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpConsumer.java#L343] We should change it to be consistent with other HTTP components and use the 'name' attribute of the Content-Disposition sent in the request body. E.g this: [https://github.com/apache/camel/blob/450c4a6228711bf947f9beb8ec65ab801959a0c0/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpConsumer.java#L323] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20662) camel-grpc: Add more consumer options for the Netty server setup
[ https://issues.apache.org/jira/browse/CAMEL-20662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20662. - Fix Version/s: 4.6.0 Resolution: Fixed > camel-grpc: Add more consumer options for the Netty server setup > > > Key: CAMEL-20662 > URL: https://issues.apache.org/jira/browse/CAMEL-20662 > Project: Camel > Issue Type: Improvement > Components: camel-grpc >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.6.0 > > > At present we only allow users to configure a small fraction of the available > options on the gRPC NettyServerBuilder. > * Max inbound message size > * Max concurrent calls per connection > * Flow control window > The server builder provides many other options for idle timeouts, connection > timeouts and various other things that can be useful for performance etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20662) camel-grpc: Add more consumer options for the Netty server setup
James Netherton created CAMEL-20662: --- Summary: camel-grpc: Add more consumer options for the Netty server setup Key: CAMEL-20662 URL: https://issues.apache.org/jira/browse/CAMEL-20662 Project: Camel Issue Type: Improvement Components: camel-grpc Reporter: James Netherton Assignee: James Netherton At present we only allow users to configure a small fraction of the available options on the gRPC NettyServerBuilder. * Max inbound message size * Max concurrent calls per connection * Flow control window The server builder provides many other options for idle timeouts, connection timeouts and various other things that can be useful for performance etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20571) camel-infinispan: Upgrade to 15.x
[ https://issues.apache.org/jira/browse/CAMEL-20571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20571. - Resolution: Fixed > camel-infinispan: Upgrade to 15.x > - > > Key: CAMEL-20571 > URL: https://issues.apache.org/jira/browse/CAMEL-20571 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-infinispan >Reporter: James Netherton >Assignee: James Netherton >Priority: Major > Fix For: 4.6.0 > > > Infinispan 15 is now available: > https://infinispan.org/blog/2024/03/13/infinispan-15 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20571) camel-infinispan: Upgrade to 15.x
[ https://issues.apache.org/jira/browse/CAMEL-20571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton reassigned CAMEL-20571: --- Assignee: James Netherton > camel-infinispan: Upgrade to 15.x > - > > Key: CAMEL-20571 > URL: https://issues.apache.org/jira/browse/CAMEL-20571 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-infinispan >Reporter: James Netherton >Assignee: James Netherton >Priority: Major > > Infinispan 15 is now available: > https://infinispan.org/blog/2024/03/13/infinispan-15 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20571) camel-infinispan: Upgrade to 15.x
[ https://issues.apache.org/jira/browse/CAMEL-20571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton updated CAMEL-20571: Fix Version/s: 4.6.0 > camel-infinispan: Upgrade to 15.x > - > > Key: CAMEL-20571 > URL: https://issues.apache.org/jira/browse/CAMEL-20571 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-infinispan >Reporter: James Netherton >Assignee: James Netherton >Priority: Major > Fix For: 4.6.0 > > > Infinispan 15 is now available: > https://infinispan.org/blog/2024/03/13/infinispan-15 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19469) camel-opentelemetry: Context not propagated correctly when tracing bean or processor invocations with @WithSpan
[
https://issues.apache.org/jira/browse/CAMEL-19469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829804#comment-17829804
]
James Netherton commented on CAMEL-19469:
-
{quote}The OpenTelemetryTracingStrategy already creates a Span for
Processors{quote}
True, but that wasn't the case when this issue was created. So this issue
probably needs a retest / reassessment.
> camel-opentelemetry: Context not propagated correctly when tracing bean or
> processor invocations with @WithSpan
> ---
>
> Key: CAMEL-19469
> URL: https://issues.apache.org/jira/browse/CAMEL-19469
> Project: Camel
> Issue Type: Improvement
> Components: camel-opentelemetry
>Affects Versions: 3.20.5, 4.0-M3
>Reporter: James Netherton
>Priority: Minor
>
> OpenTelemetry enables you to trace arbitrary method invocations by tagging
> them with the @WithSpan annotation:
> https://opentelemetry.io/docs/instrumentation/java/automatic/annotations/#creating-spans-around-methods-with-withspan
> For some scenarios, the tracing context does not seem to get propagated and
> the resulting spans end up being disassociated. For example:
> {code}
> from("timer:tick?period=5s)
> .process("myProcessor");
> {code}
> {code}
> public class MyProcessor implements Processor {
> @WithSpan
> @Override
> public void process(Exchange exchange) {
> // Useful work here...
> }
> }
> {code}
> This results in 2 spans. One for timer:tick & another for MyProcessor. The
> problem is that the parent span for MyProcessor is not set, so they appear as
> 2 distinct traces.
> There is a workaround where you can configure the route like this and the
> span hierarchy ends up being correct:
> {code}
> from("timer:tick?period=5s")
> .to("direct:start");
> from("direct:start")
> .process("myProcessor");
> {code}
> There's some more background in the original issue reported on Camel Quarkus:
> https://github.com/apache/camel-quarkus/issues/4981
> There's also a reproducer project here:
> https://github.com/jamesnetherton/camel-opentelemetry-demo
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20579) camel-xchange: ticker action may throw NotYetImplementedForExchangeException
[ https://issues.apache.org/jira/browse/CAMEL-20579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20579. - Resolution: Fixed > camel-xchange: ticker action may throw NotYetImplementedForExchangeException > > > Key: CAMEL-20579 > URL: https://issues.apache.org/jira/browse/CAMEL-20579 > Project: Camel > Issue Type: Bug > Components: camel-xchange >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.5.0 > > > The xchange ticker action invokes this code: > https://github.com/apache/camel/blob/e924867d1a153e3d1bf6af7b01cf1f950cf91ff3/components/camel-xchange/src/main/java/org/apache/camel/component/xchange/XChangeEndpoint.java#L181 > Note the cast of 'pair' to 'Instrument'. Conveniently this works for the > default binance exchange that the component ships with. But for most other > exchanges, the xchange crypto API implementations still use the deprecated > MarketDataService.getTicker(CurrencyPair). > So if you try to use the ticker action for the kraken exchange, you get > NotYetImplementedForExchangeException. > We could do fallback to the older getTicker variant if the initial attempt > fails. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20579) camel-xchange: ticker action may throw NotYetImplementedForExchangeException
James Netherton created CAMEL-20579: --- Summary: camel-xchange: ticker action may throw NotYetImplementedForExchangeException Key: CAMEL-20579 URL: https://issues.apache.org/jira/browse/CAMEL-20579 Project: Camel Issue Type: Bug Components: camel-xchange Reporter: James Netherton Assignee: James Netherton Fix For: 4.5.0 The xchange ticker action invokes this code: https://github.com/apache/camel/blob/e924867d1a153e3d1bf6af7b01cf1f950cf91ff3/components/camel-xchange/src/main/java/org/apache/camel/component/xchange/XChangeEndpoint.java#L181 Note the cast of 'pair' to 'Instrument'. Conveniently this works for the default binance exchange that the component ships with. But for most other exchanges, the xchange crypto API implementations still use the deprecated MarketDataService.getTicker(CurrencyPair). So if you try to use the ticker action for the kraken exchange, you get NotYetImplementedForExchangeException. We could do fallback to the older getTicker variant if the initial attempt fails. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20571) camel-infinispan: Upgrade to 15.x
[ https://issues.apache.org/jira/browse/CAMEL-20571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827448#comment-17827448 ] James Netherton commented on CAMEL-20571: - I wasn't planning to (for 4.5.0 at least). If nobody else has time, I could maybe try to work on it for 4.6.0. > camel-infinispan: Upgrade to 15.x > - > > Key: CAMEL-20571 > URL: https://issues.apache.org/jira/browse/CAMEL-20571 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-infinispan >Reporter: James Netherton >Priority: Major > > Infinispan 15 is now available: > https://infinispan.org/blog/2024/03/13/infinispan-15 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20571) camel-infinispan: Upgrade to 15.x
James Netherton created CAMEL-20571: --- Summary: camel-infinispan: Upgrade to 15.x Key: CAMEL-20571 URL: https://issues.apache.org/jira/browse/CAMEL-20571 Project: Camel Issue Type: Dependency upgrade Components: camel-infinispan Reporter: James Netherton Infinispan 15 is now available: https://infinispan.org/blog/2024/03/13/infinispan-15 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20534) camel-grpc: Port validation should check if a port was specified
[ https://issues.apache.org/jira/browse/CAMEL-20534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20534. - Resolution: Fixed > camel-grpc: Port validation should check if a port was specified > > > Key: CAMEL-20534 > URL: https://issues.apache.org/jira/browse/CAMEL-20534 > Project: Camel > Issue Type: Improvement > Components: camel-grpc >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.4.1, 4.5.0 > > > The gRPC docs are maybe a bit misleading because they state that the port > part of the URI is mandatory. > However, it's currently possible to omit it and you then end up with either a > consumer started on a random port (because the port int has the default value > of 0). Or a producer that tries to connect to the gRPC default port. > So I propose to initialize the port with a default of -1 and fix up the > validation logic as using isEmpty is not really appropriate in this case. > [https://github.com/apache/camel/blob/7c8e7414e31f3eab888c7fb539abc8e5b3a61d6b/components/camel-grpc/src/main/java/org/apache/camel/component/grpc/GrpcConsumer.java#L96] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20534) camel-grpc: Port validation should check if a port was specified
James Netherton created CAMEL-20534: --- Summary: camel-grpc: Port validation should check if a port was specified Key: CAMEL-20534 URL: https://issues.apache.org/jira/browse/CAMEL-20534 Project: Camel Issue Type: Improvement Components: camel-grpc Reporter: James Netherton Assignee: James Netherton Fix For: 4.4.1, 4.5.0 The gRPC docs are maybe a bit misleading because they state that the port part of the URI is mandatory. However, it's currently possible to omit it and you then end up with either a consumer started on a random port (because the port int has the default value of 0). Or a producer that tries to connect to the gRPC default port. So I propose to initialize the port with a default of -1 and fix up the validation logic as using isEmpty is not really appropriate in this case. [https://github.com/apache/camel/blob/7c8e7414e31f3eab888c7fb539abc8e5b3a61d6b/components/camel-grpc/src/main/java/org/apache/camel/component/grpc/GrpcConsumer.java#L96] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20519) camel-servlet: Tidy and improve documentation
[ https://issues.apache.org/jira/browse/CAMEL-20519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20519. - Resolution: Fixed > camel-servlet: Tidy and improve documentation > - > > Key: CAMEL-20519 > URL: https://issues.apache.org/jira/browse/CAMEL-20519 > Project: Camel > Issue Type: Task > Components: camel-servlet, documentation >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.4.1, 4.5.0 > > > The servlet docs could benefit from a little rework to improve them. I am > planning to: > - Give a brief mention to the automatic configuration on SB / CQ. > - Reorder some of the sections so that it flows a bit better and have the > important stuff near the top of the doc > - Update the example code snippets > - Remove old redundant stuff > - Improve wording where possible -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20519) camel-servlet: Tidy and improve documentation
James Netherton created CAMEL-20519: --- Summary: camel-servlet: Tidy and improve documentation Key: CAMEL-20519 URL: https://issues.apache.org/jira/browse/CAMEL-20519 Project: Camel Issue Type: Task Components: camel-servlet, documentation Reporter: James Netherton Assignee: James Netherton Fix For: 4.4.1, 4.5.0 The servlet docs could benefit from a little rework to improve them. I am planning to: - Give a brief mention to the automatic configuration on SB / CQ. - Reorder some of the sections so that it flows a bit better and have the important stuff near the top of the doc - Update the example code snippets - Remove old redundant stuff - Improve wording where possible -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20401) camel-kudu: Potential NullPointerException on endpoint stop
[ https://issues.apache.org/jira/browse/CAMEL-20401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20401. - Resolution: Fixed > camel-kudu: Potential NullPointerException on endpoint stop > --- > > Key: CAMEL-20401 > URL: https://issues.apache.org/jira/browse/CAMEL-20401 > Project: Camel > Issue Type: Bug > Components: camel-kudu >Affects Versions: 3.22.1, 4.0.4 >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 3.22.2, 4.4.0 > > > Something I just stumbled into by accident when testing. > If instantiation and setup of the KuduClient fails for some reason, its class > field will be left null, which causes the client shutdown logic in > KuduEndoint.doStop to throw an NPE since it has no null check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20401) camel-kudu: Potential NullPointerException on endpoint stop
James Netherton created CAMEL-20401: --- Summary: camel-kudu: Potential NullPointerException on endpoint stop Key: CAMEL-20401 URL: https://issues.apache.org/jira/browse/CAMEL-20401 Project: Camel Issue Type: Bug Components: camel-kudu Affects Versions: 4.0.4, 3.22.1 Reporter: James Netherton Assignee: James Netherton Fix For: 3.22.2, 4.4.0 Something I just stumbled into by accident when testing. If instantiation and setup of the KuduClient fails for some reason, its class field will be left null, which causes the client shutdown logic in KuduEndoint.doStop to throw an NPE since it has no null check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20396) camel-kudu: Allow KuduClient to be autowired
[ https://issues.apache.org/jira/browse/CAMEL-20396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20396. - Fix Version/s: 4.4.0 Resolution: Fixed > camel-kudu: Allow KuduClient to be autowired > > > Key: CAMEL-20396 > URL: https://issues.apache.org/jira/browse/CAMEL-20396 > Project: Camel > Issue Type: Improvement > Components: camel-kudu >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.4.0 > > > If users want to do some customization on the client configuration then it > could be useful to provide an existing client instance for the component to > use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20396) camel-kudu: Allow KuduClient to be autowired
James Netherton created CAMEL-20396: --- Summary: camel-kudu: Allow KuduClient to be autowired Key: CAMEL-20396 URL: https://issues.apache.org/jira/browse/CAMEL-20396 Project: Camel Issue Type: Improvement Components: camel-kudu Reporter: James Netherton Assignee: James Netherton If users want to do some customization on the client configuration then it could be useful to provide an existing client instance for the component to use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20353) camel-rest-openapi: test broken after swagger upgrade
[ https://issues.apache.org/jira/browse/CAMEL-20353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20353. - Fix Version/s: 4.4.0 Resolution: Fixed > camel-rest-openapi: test broken after swagger upgrade > - > > Key: CAMEL-20353 > URL: https://issues.apache.org/jira/browse/CAMEL-20353 > Project: Camel > Issue Type: Test > Components: camel-rest-openapi >Affects Versions: 4.4.0 >Reporter: Otavio Rodolfo Piske >Assignee: James Netherton >Priority: Major > Labels: easy, help-wanted > Fix For: 4.4.0 > > > This upgrade broke RestOpenApiRequestValidationTest: > https://github.com/apache/camel/commit/394084605ec909f1aed514734166dd45da35af97 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20353) camel-rest-openapi: test broken after swagger upgrade
[
https://issues.apache.org/jira/browse/CAMEL-20353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810390#comment-17810390
]
James Netherton commented on CAMEL-20353:
-
There must be a change in the validation behaviour. The 3.1 spec for the pet
store definition for POST /pet states that 'id' is required in the Pet JSON
request body.
{code}
"post" : {
"tags" : [ "pet" ],
"summary" : "Add a new pet to the store",
"description" : "Add a new pet to the store",
"operationId" : "addPet",
"requestBody" : {
"description" : "Create a new pet in the store",
"content" : {
"application/json" : {
"schema" : {
"$ref" : "#/components/schemas/Pet",
"description" : "A Pet in JSON Format",
"required" : [ "id" ],
"writeOnly" : true
}
},
"application/xml" : {
"schema" : {
"$ref" : "#/components/schemas/Pet",
"description" : "A Pet in XML Format",
"required" : [ "id" ],
"writeOnly" : true
}
}
},
"required" : true
},
{code}
And that now seems to override the validation options specified on Pet object
{code}
Pet:
$schema: https://json-schema.org/draft/2020-12/schema
description: Pet
required:
- name
- photoUrls
{code}
Somewhat weirdly on the Swagger UI, you can remove the 'id' and other required
fields and make a successful request.
https://petstore31.swagger.io/#/pet/addPet
So given that, I'll tweak the 3.1 pet store spec file and remove the "required"
: [ "id" ] bits to restore the previous (IMO correct) behaviour.
> camel-rest-openapi: test broken after swagger upgrade
> -
>
> Key: CAMEL-20353
> URL: https://issues.apache.org/jira/browse/CAMEL-20353
> Project: Camel
> Issue Type: Test
> Components: camel-rest-openapi
>Affects Versions: 4.4.0
>Reporter: Otavio Rodolfo Piske
>Assignee: James Netherton
>Priority: Major
> Labels: easy, help-wanted
>
> This upgrade broke RestOpenApiRequestValidationTest:
> https://github.com/apache/camel/commit/394084605ec909f1aed514734166dd45da35af97
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-20353) camel-rest-openapi: test broken after swagger upgrade
[ https://issues.apache.org/jira/browse/CAMEL-20353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton reassigned CAMEL-20353: --- Assignee: James Netherton > camel-rest-openapi: test broken after swagger upgrade > - > > Key: CAMEL-20353 > URL: https://issues.apache.org/jira/browse/CAMEL-20353 > Project: Camel > Issue Type: Test > Components: camel-rest-openapi >Affects Versions: 4.4.0 >Reporter: Otavio Rodolfo Piske >Assignee: James Netherton >Priority: Major > Labels: easy, help-wanted > > This upgrade broke RestOpenApiRequestValidationTest: > https://github.com/apache/camel/commit/394084605ec909f1aed514734166dd45da35af97 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20360) camel-jasypt: Improve and tidy documentation
[ https://issues.apache.org/jira/browse/CAMEL-20360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20360. - Resolution: Fixed > camel-jasypt: Improve and tidy documentation > > > Key: CAMEL-20360 > URL: https://issues.apache.org/jira/browse/CAMEL-20360 > Project: Camel > Issue Type: Task > Components: camel-jasypt, documentation >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.4.0 > > > I was thinking it'd be good to tidy the camel-jasypt component docs a little, > remove some of the old cruft & improve the wording etc. > Might also be good to simplify how we tell users to run the command line > utility. JBang could be a nice option because you can point it at the Maven > GAV of the camel-jasypt JAR and it'll run it and accept the necessary > parameters. It's nicer than having to manually download JARs or find their > location and do java -jar etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20360) camel-jasypt: Improve and tidy documentation
James Netherton created CAMEL-20360: --- Summary: camel-jasypt: Improve and tidy documentation Key: CAMEL-20360 URL: https://issues.apache.org/jira/browse/CAMEL-20360 Project: Camel Issue Type: Task Components: camel-jasypt, documentation Reporter: James Netherton Assignee: James Netherton Fix For: 4.4.0 I was thinking it'd be good to tidy the camel-jasypt component docs a little, remove some of the old cruft & improve the wording etc. Might also be good to simplify how we tell users to run the command line utility. JBang could be a nice option because you can point it at the Maven GAV of the camel-jasypt JAR and it'll run it and accept the necessary parameters. It's nicer than having to manually download JARs or find their location and do java -jar etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20358) camel-microprofile-config: CamelMicroProfilePropertiesSource should consider active profiles when loading properties
[ https://issues.apache.org/jira/browse/CAMEL-20358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20358. - Resolution: Fixed > camel-microprofile-config: CamelMicroProfilePropertiesSource should consider > active profiles when loading properties > > > Key: CAMEL-20358 > URL: https://issues.apache.org/jira/browse/CAMEL-20358 > Project: Camel > Issue Type: Improvement > Components: camel-microprofile-config >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.4.0 > > > CamelMicroProfilePropertiesSource loadProperties() gets the names of all > available config properties and proceeds to try and resolve their values. > There are some edge cases where if properties are prefixed with a profile > qualifier (E.g %foo.some.property) , and that specific config profile is not > active, then there can potentially be issues trying to resolve the config > value. > So it would probably be safer to filter out profile specific config if the > relevant profile is not activated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20358) camel-microprofile-config: CamelMicroProfilePropertiesSource should consider active profiles when loading properties
James Netherton created CAMEL-20358: --- Summary: camel-microprofile-config: CamelMicroProfilePropertiesSource should consider active profiles when loading properties Key: CAMEL-20358 URL: https://issues.apache.org/jira/browse/CAMEL-20358 Project: Camel Issue Type: Improvement Components: camel-microprofile-config Reporter: James Netherton Assignee: James Netherton Fix For: 4.4.0 CamelMicroProfilePropertiesSource loadProperties() gets the names of all available config properties and proceeds to try and resolve their values. There are some edge cases where if properties are prefixed with a profile qualifier (E.g %foo.some.property) , and that specific config profile is not active, then there can potentially be issues trying to resolve the config value. So it would probably be safer to filter out profile specific config if the relevant profile is not activated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20295) camel-grpc: Enable tests to run on more platforms
[ https://issues.apache.org/jira/browse/CAMEL-20295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20295. - Fix Version/s: 4.4.0 Resolution: Fixed > camel-grpc: Enable tests to run on more platforms > - > > Key: CAMEL-20295 > URL: https://issues.apache.org/jira/browse/CAMEL-20295 > Project: Camel > Issue Type: Improvement > Components: camel-grpc >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.4.0 > > > Currently camel-grpc testing is only enabled on a small selection of > platforms: > https://github.com/apache/camel/blob/main/components/camel-grpc/pom.xml#L178 > In theory we can expand this to all architectures supported by protoc: > https://repo1.maven.org/maven2/com/google/protobuf/protoc/3.25.1/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20295) camel-grpc: Enable tests to run on more platforms
James Netherton created CAMEL-20295: --- Summary: camel-grpc: Enable tests to run on more platforms Key: CAMEL-20295 URL: https://issues.apache.org/jira/browse/CAMEL-20295 Project: Camel Issue Type: Improvement Components: camel-grpc Reporter: James Netherton Assignee: James Netherton Currently camel-grpc testing is only enabled on a small selection of platforms: https://github.com/apache/camel/blob/main/components/camel-grpc/pom.xml#L178 In theory we can expand this to all architectures supported by protoc: https://repo1.maven.org/maven2/com/google/protobuf/protoc/3.25.1/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20156) openapi-java: REST DSL param arrayType with allowableValues can lead to NoSuchMethodException
James Netherton created CAMEL-20156: --- Summary: openapi-java: REST DSL param arrayType with allowableValues can lead to NoSuchMethodException Key: CAMEL-20156 URL: https://issues.apache.org/jira/browse/CAMEL-20156 Project: Camel Issue Type: Bug Components: camel-openapi-java Affects Versions: 4.2.0, 4.0.2, 3.21.2 Reporter: James Netherton There is some logic in the openapi-java component to handle different array types: [https://github.com/apache/camel/blob/main/components/camel-openapi-java/src/main/java/org/apache/camel/openapi/RestOpenApiReader.java#L498-L534] If you provide a set of allowable values, then you end up in method convertAndSetItemsEnum: [https://github.com/apache/camel/blob/main/components/camel-openapi-java/src/main/java/org/apache/camel/openapi/RestOpenApiReader.java#L705] The problem is that the code attempts to invoke static method valueOf. This will only be present for types that are standard JDK types (Integer, Float, Double etc). For types like ByteArraySchema, BinarySchema etc, no such method exists hence Camel startup will fail with NoSuchMethodException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20107) camel-salesforce: PubSubApiConsumer may fail to load pojo class
[
https://issues.apache.org/jira/browse/CAMEL-20107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Netherton resolved CAMEL-20107.
-
Resolution: Fixed
> camel-salesforce: PubSubApiConsumer may fail to load pojo class
> ---
>
> Key: CAMEL-20107
> URL: https://issues.apache.org/jira/browse/CAMEL-20107
> Project: Camel
> Issue Type: Improvement
> Components: camel-salesforce
>Affects Versions: 4.0.2, 4.1.0, 4.2.0
>Reporter: James Netherton
>Assignee: James Netherton
>Priority: Minor
> Fix For: 4.0.4, 4.3.0
>
>
> When using Salesforce Pub / Sub with pubSubDeserializeType POJO, it's
> possible that the POJO class will not get loaded correctly on some platforms.
> [https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/PubSubApiConsumer.java#L65]
> It'd be better if the class loading logic used the Camel {{ClassResolver}} or
> {{ObjectHelper.loadClass}} so that the class is attempted to be loaded from
> the correct set of ClassLoaders.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20114) camel-salesforce: generatePubSub plugin goal should clean up temporary schema JSON files
[ https://issues.apache.org/jira/browse/CAMEL-20114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20114. - Resolution: Fixed > camel-salesforce: generatePubSub plugin goal should clean up temporary schema > JSON files > > > Key: CAMEL-20114 > URL: https://issues.apache.org/jira/browse/CAMEL-20114 > Project: Camel > Issue Type: Improvement > Components: camel-salesforce >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.1.0, 4.2.0 >Reporter: James Netherton >Assignee: James Netherton >Priority: Trivial > Fix For: 4.0.4, 4.3.0 > > > Relates to chat on Camel Zulip: > https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Salesforce.20generatePubSub.20goal > Seems the generated temporary Avro schema JSON files are not needed after the > Avro compiler runs. So it'd be useful to clean them up in case users choose > the output directory to be somewhere under the project source tree. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20107) camel-salesforce: PubSubApiConsumer may fail to load pojo class
[
https://issues.apache.org/jira/browse/CAMEL-20107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Netherton reassigned CAMEL-20107:
---
Assignee: James Netherton
> camel-salesforce: PubSubApiConsumer may fail to load pojo class
> ---
>
> Key: CAMEL-20107
> URL: https://issues.apache.org/jira/browse/CAMEL-20107
> Project: Camel
> Issue Type: Improvement
> Components: camel-salesforce
>Affects Versions: 4.0.2, 4.1.0, 4.2.0
>Reporter: James Netherton
>Assignee: James Netherton
>Priority: Minor
> Fix For: 4.0.4, 4.3.0
>
>
> When using Salesforce Pub / Sub with pubSubDeserializeType POJO, it's
> possible that the POJO class will not get loaded correctly on some platforms.
> [https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/PubSubApiConsumer.java#L65]
> It'd be better if the class loading logic used the Camel {{ClassResolver}} or
> {{ObjectHelper.loadClass}} so that the class is attempted to be loaded from
> the correct set of ClassLoaders.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20114) camel-salesforce: generatePubSub plugin goal should clean up temporary schema JSON files
James Netherton created CAMEL-20114: --- Summary: camel-salesforce: generatePubSub plugin goal should clean up temporary schema JSON files Key: CAMEL-20114 URL: https://issues.apache.org/jira/browse/CAMEL-20114 Project: Camel Issue Type: Improvement Components: camel-salesforce Affects Versions: 4.2.0, 4.1.0, 4.0.2, 4.0.1, 4.0.0, 4.0.3 Reporter: James Netherton Assignee: James Netherton Fix For: 4.0.4, 4.3.0 Relates to chat on Camel Zulip: https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Salesforce.20generatePubSub.20goal Seems the generated temporary Avro schema JSON files are not needed after the Avro compiler runs. So it'd be useful to clean them up in case users choose the output directory to be somewhere under the project source tree. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20107) camel-salesforce: PubSubApiConsumer may fail to load pojo class
James Netherton created CAMEL-20107:
---
Summary: camel-salesforce: PubSubApiConsumer may fail to load pojo
class
Key: CAMEL-20107
URL: https://issues.apache.org/jira/browse/CAMEL-20107
Project: Camel
Issue Type: Improvement
Components: camel-salesforce
Affects Versions: 4.1.0, 4.0.2, 4.2.0
Reporter: James Netherton
When using Salesforce Pub / Sub with pubSubDeserializeType POJO, it's possible
that the POJO class will not get loaded correctly on some platforms.
[https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/PubSubApiConsumer.java#L65]
It'd be better if the class loading logic used the Camel {{ClassResolver}} or
{{ObjectHelper.loadClass}} so that the class is attempted to be loaded from the
correct set of ClassLoaders.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-19905) camel-platform-http-vertx - Streaming mode for message body
[ https://issues.apache.org/jira/browse/CAMEL-19905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-19905. - Fix Version/s: 4.2.0 (was: 4.x) Resolution: Fixed > camel-platform-http-vertx - Streaming mode for message body > --- > > Key: CAMEL-19905 > URL: https://issues.apache.org/jira/browse/CAMEL-19905 > Project: Camel > Issue Type: Improvement > Components: camel-platform-http-vertx >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.2.0 > > > It appears that when you have big HTTP requests then vertx-http server will > read all content into memory. > At first glance it does not seems an easy API to use some kind of streaming > mode via java.io.InputStream as the message body type. > The vertx based Buffer appears to be read entirely into memory. > io.vertx.ext.web.handler.BodyHandler#create() > See the following code > https://github.com/apache/camel/blob/b7eed290f06dc483e67892b3bb1cfccc0a4e1f1e/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpConsumer.java#L276 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19905) camel-platform-http-vertx - Streaming mode for message body
[ https://issues.apache.org/jira/browse/CAMEL-19905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782471#comment-17782471 ] James Netherton commented on CAMEL-19905: - Not sure if this is the right way of going about fixing this, but I made a POC that could handle large requests / response payloads. https://github.com/apache/camel/compare/main...jamesnetherton:camel:CAMEL-19905 I added a new 'useStreaming' option. When true the request body is handled in a different way to normal. E.g don't register the normal BodyHandler, but instead register a handler on the incoming Vert.x HttpRequest that lets us read the body payload in chunks. Then we feed each chunk into `CachedOutputStream` which we can use to get an `InputStream` for the exchange message body. That allows overflow to disk if needed. I have a basic unit test that uploads and echos back a 4GB payload and it seems to be working ok. Also tested with a small heap size and that was ok. > camel-platform-http-vertx - Streaming mode for message body > --- > > Key: CAMEL-19905 > URL: https://issues.apache.org/jira/browse/CAMEL-19905 > Project: Camel > Issue Type: Improvement > Components: camel-platform-http-vertx >Reporter: Claus Ibsen >Priority: Major > > It appears that when you have big HTTP requests then vertx-http server will > read all content into memory. > At first glance it does not seems an easy API to use some kind of streaming > mode via java.io.InputStream as the message body type. > The vertx based Buffer appears to be read entirely into memory. > io.vertx.ext.web.handler.BodyHandler#create() > See the following code > https://github.com/apache/camel/blob/b7eed290f06dc483e67892b3bb1cfccc0a4e1f1e/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpConsumer.java#L276 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20053) camel-jira: watchUpdates consumer does not see issues created after route startup
[ https://issues.apache.org/jira/browse/CAMEL-20053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20053. - Resolution: Fixed > camel-jira: watchUpdates consumer does not see issues created after route > startup > - > > Key: CAMEL-20053 > URL: https://issues.apache.org/jira/browse/CAMEL-20053 > Project: Camel > Issue Type: Bug > Components: camel-jira >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 3.20.9, 3.21.3, 3.22.0, 4.0.3, 4.2.0 > > > Originally reported for Camel Quarkus here: > https://github.com/apache/camel-quarkus/issues/5427 > I think the implementation of poll() in the Jira WatchUpdatesConsumer is not > correct. > If the number of issues found during the poll has changed compared to > previous, then for some reason it invokes init(). It should probably be > invoking initIssues to refresh the map of watched issues. Otherwise the > consumer is only able to watch for updates on issues that were created before > the route was started. > https://github.com/apache/camel/blob/main/components/camel-jira/src/main/java/org/apache/camel/component/jira/consumer/WatchUpdatesConsumer.java#L70 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20053) camel-jira: watchUpdates consumer does not see issues created after route startup
[ https://issues.apache.org/jira/browse/CAMEL-20053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton reassigned CAMEL-20053: --- Assignee: James Netherton > camel-jira: watchUpdates consumer does not see issues created after route > startup > - > > Key: CAMEL-20053 > URL: https://issues.apache.org/jira/browse/CAMEL-20053 > Project: Camel > Issue Type: Bug > Components: camel-jira >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 3.20.9, 3.21.3, 3.22.0, 4.0.3, 4.2.0 > > > Originally reported for Camel Quarkus here: > https://github.com/apache/camel-quarkus/issues/5427 > I think the implementation of poll() in the Jira WatchUpdatesConsumer is not > correct. > If the number of issues found during the poll has changed compared to > previous, then for some reason it invokes init(). It should probably be > invoking initIssues to refresh the map of watched issues. Otherwise the > consumer is only able to watch for updates on issues that were created before > the route was started. > https://github.com/apache/camel/blob/main/components/camel-jira/src/main/java/org/apache/camel/component/jira/consumer/WatchUpdatesConsumer.java#L70 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20053) camel-jira: watchUpdates consumer does not see issues created after route startup
[ https://issues.apache.org/jira/browse/CAMEL-20053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780269#comment-17780269 ] James Netherton commented on CAMEL-20053: - Yeah, I'll try to do a PR for it. > camel-jira: watchUpdates consumer does not see issues created after route > startup > - > > Key: CAMEL-20053 > URL: https://issues.apache.org/jira/browse/CAMEL-20053 > Project: Camel > Issue Type: Bug > Components: camel-jira >Reporter: James Netherton >Priority: Minor > Fix For: 3.20.9, 3.21.3, 3.22.0, 4.0.3, 4.2.0 > > > Originally reported for Camel Quarkus here: > https://github.com/apache/camel-quarkus/issues/5427 > I think the implementation of poll() in the Jira WatchUpdatesConsumer is not > correct. > If the number of issues found during the poll has changed compared to > previous, then for some reason it invokes init(). It should probably be > invoking initIssues to refresh the map of watched issues. Otherwise the > consumer is only able to watch for updates on issues that were created before > the route was started. > https://github.com/apache/camel/blob/main/components/camel-jira/src/main/java/org/apache/camel/component/jira/consumer/WatchUpdatesConsumer.java#L70 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20053) camel-jira: watchUpdates consumer does not see issues created after route startup
James Netherton created CAMEL-20053: --- Summary: camel-jira: watchUpdates consumer does not see issues created after route startup Key: CAMEL-20053 URL: https://issues.apache.org/jira/browse/CAMEL-20053 Project: Camel Issue Type: Bug Components: camel-jira Reporter: James Netherton Originally reported for Camel Quarkus here: https://github.com/apache/camel-quarkus/issues/5427 I think the implementation of poll() in the Jira WatchUpdatesConsumer is not correct. If the number of issues found during the poll has changed compared to previous, then for some reason it invokes init(). It should probably be invoking initIssues to refresh the map of watched issues. Otherwise the consumer is only able to watch for updates on issues that were created before the route was started. https://github.com/apache/camel/blob/main/components/camel-jira/src/main/java/org/apache/camel/component/jira/consumer/WatchUpdatesConsumer.java#L70 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20011) camel-vertx: Avoid usage of deprecated Vertx.executeBlocking(Handler>)
[ https://issues.apache.org/jira/browse/CAMEL-20011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20011. - Fix Version/s: 4.2.0 Resolution: Fixed > camel-vertx: Avoid usage of deprecated > Vertx.executeBlocking(Handler>) > - > > Key: CAMEL-20011 > URL: https://issues.apache.org/jira/browse/CAMEL-20011 > Project: Camel > Issue Type: Improvement >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.2.0 > > > In Vert.x 4.5.5, the method signature that we use in various components for > Vertx.executeBlocking became deprecated. E.g > executeBlocking(Handler> blockingCodeHandler) > Is deprecated in favor of: > executeBlocking(Callable blockingCodeHandler) > It'd be good to migrate the following components to use the preferred > signature if possible. > * camel-knative-http (See KnativeHttpConsumer & KnativeHttpTest) > * camel-platform-http-vertx (See VertxPlatformHttpConsumer) > * camel-reactive-executor-vertx (See VertXReactiveExecutor) > * camel-threadpoolfactory-vertx (See VertXThreadPoolFactory) > * camel-vertx-websocket (See VertxWebsocketConsumer & > VertxWebsocketClientConsumer) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20011) camel-vertx: Avoid usage of deprecated Vertx.executeBlocking(Handler>)
[ https://issues.apache.org/jira/browse/CAMEL-20011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton reassigned CAMEL-20011: --- Assignee: James Netherton > camel-vertx: Avoid usage of deprecated > Vertx.executeBlocking(Handler>) > - > > Key: CAMEL-20011 > URL: https://issues.apache.org/jira/browse/CAMEL-20011 > Project: Camel > Issue Type: Improvement >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > > In Vert.x 4.5.5, the method signature that we use in various components for > Vertx.executeBlocking became deprecated. E.g > executeBlocking(Handler> blockingCodeHandler) > Is deprecated in favor of: > executeBlocking(Callable blockingCodeHandler) > It'd be good to migrate the following components to use the preferred > signature if possible. > * camel-knative-http (See KnativeHttpConsumer & KnativeHttpTest) > * camel-platform-http-vertx (See VertxPlatformHttpConsumer) > * camel-reactive-executor-vertx (See VertXReactiveExecutor) > * camel-threadpoolfactory-vertx (See VertXThreadPoolFactory) > * camel-vertx-websocket (See VertxWebsocketConsumer & > VertxWebsocketClientConsumer) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20011) camel-vertx: Avoid usage of deprecated Vertx.executeBlocking(Handler>)
[ https://issues.apache.org/jira/browse/CAMEL-20011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776645#comment-17776645 ] James Netherton commented on CAMEL-20011: - [~davsclaus] would a change like this be ok? https://github.com/jamesnetherton/camel/commit/2248a6d5398251326bfd2d6e90734a51746434bb I.e switch from getAsyncProcessor to getProcessor. Either way you have to wait in the Callable block until the processing is done. I wasn't sure if maybe it'd impact performance or something using the non-async processor. > camel-vertx: Avoid usage of deprecated > Vertx.executeBlocking(Handler>) > - > > Key: CAMEL-20011 > URL: https://issues.apache.org/jira/browse/CAMEL-20011 > Project: Camel > Issue Type: Improvement >Reporter: James Netherton >Priority: Minor > > In Vert.x 4.5.5, the method signature that we use in various components for > Vertx.executeBlocking became deprecated. E.g > executeBlocking(Handler> blockingCodeHandler) > Is deprecated in favor of: > executeBlocking(Callable blockingCodeHandler) > It'd be good to migrate the following components to use the preferred > signature if possible. > * camel-knative-http (See KnativeHttpConsumer & KnativeHttpTest) > * camel-platform-http-vertx (See VertxPlatformHttpConsumer) > * camel-reactive-executor-vertx (See VertXReactiveExecutor) > * camel-threadpoolfactory-vertx (See VertXThreadPoolFactory) > * camel-vertx-websocket (See VertxWebsocketConsumer & > VertxWebsocketClientConsumer) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20011) camel-vertx: Avoid usage of deprecated Vertx.executeBlocking(Handler>)
James Netherton created CAMEL-20011: --- Summary: camel-vertx: Avoid usage of deprecated Vertx.executeBlocking(Handler>) Key: CAMEL-20011 URL: https://issues.apache.org/jira/browse/CAMEL-20011 Project: Camel Issue Type: Improvement Reporter: James Netherton In Vert.x 4.5.5, the method signature that we use in various components for Vertx.executeBlocking became deprecated. E.g executeBlocking(Handler> blockingCodeHandler) Is deprecated in favor of: executeBlocking(Callable blockingCodeHandler) It'd be good to migrate the following components to use the preferred signature if possible. * camel-knative-http (See KnativeHttpConsumer & KnativeHttpTest) * camel-platform-http-vertx (See VertxPlatformHttpConsumer) * camel-reactive-executor-vertx (See VertXReactiveExecutor) * camel-threadpoolfactory-vertx (See VertXThreadPoolFactory) * camel-vertx-websocket (See VertxWebsocketConsumer & VertxWebsocketClientConsumer) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20002) camel-core: Make it easier to extend DefaultInjector
[ https://issues.apache.org/jira/browse/CAMEL-20002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-20002. - Resolution: Fixed > camel-core: Make it easier to extend DefaultInjector > > > Key: CAMEL-20002 > URL: https://issues.apache.org/jira/browse/CAMEL-20002 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.2.0 > > > Motivated by a change I made in Camel Quarkus to resolve TypeConverters from > the CDI bean registry: > https://github.com/apache/camel-quarkus/issues/5429 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20002) camel-core: Make it easier to extend DefaultInjector
James Netherton created CAMEL-20002: --- Summary: camel-core: Make it easier to extend DefaultInjector Key: CAMEL-20002 URL: https://issues.apache.org/jira/browse/CAMEL-20002 Project: Camel Issue Type: Improvement Components: camel-core Reporter: James Netherton Assignee: James Netherton Fix For: 4.2.0 Motivated by a change I made in Camel Quarkus to resolve TypeConverters from the CDI bean registry: https://github.com/apache/camel-quarkus/issues/5429 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19975) NIOConverter File to ByteBuffer conversion behavior is potentially non-deterministic
James Netherton created CAMEL-19975:
---
Summary: NIOConverter File to ByteBuffer conversion behavior is
potentially non-deterministic
Key: CAMEL-19975
URL: https://issues.apache.org/jira/browse/CAMEL-19975
Project: Camel
Issue Type: Bug
Reporter: James Netherton
Maybe a bit of an edge case, but the result of
{{NIOConverter.toByteBuffer(File)}} can potentially vary depending on the size
of the file used for conversion. It can be {{null}} or a {{ByteBuffer}} with
partial or empty content.
The converter does:
{code:java}
byte[] buf = new byte[(int) file.length()];
{code}
If {{file.length()}} > {{Integer.MAX_VALUE}}, then the cast from {{long}} to
{{int}} can produce some unexpected results. E.g if the file size is
{{Integer.MAX_VALUE + 1}}, then the result from the cast is {{-2147483648}}. If
the file size is {{4294967296}} then the result from the cast is {{0}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-19899) camel-servlet: Multipart attachment processing does not work on Undertow
[ https://issues.apache.org/jira/browse/CAMEL-19899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-19899. - Fix Version/s: 4.1.0 Assignee: James Netherton Resolution: Fixed > camel-servlet: Multipart attachment processing does not work on Undertow > > > Key: CAMEL-19899 > URL: https://issues.apache.org/jira/browse/CAMEL-19899 > Project: Camel > Issue Type: Bug > Components: camel-servlet >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.1.0 > > > Something I observed with camel-servlet on Camel Quarkus. Undertow provides > the Servlet support and the way that it's implementation of multipart > attachment parsing works, assumes that the request body has not been read > yet. Otherwise it will not attempt to process attachments. > In DefaultHttpBinding.readyBody. The body is read first: > https://github.com/apache/camel/blob/2509b469b5acfc46861643d01f0495133b690ddb/components/camel-http-common/src/main/java/org/apache/camel/http/common/DefaultHttpBinding.java#L203 > And then attachments processed at the end: > https://github.com/apache/camel/blob/2509b469b5acfc46861643d01f0495133b690ddb/components/camel-http-common/src/main/java/org/apache/camel/http/common/DefaultHttpBinding.java#L230 > I tested moving attachment processing to the beginning and it made my test > case work successfully. > Not sure if that change could potentially screw things up non-undertow > servlet containers? > This same issue is probably present on Spring Boot with Undertow. I've not > checked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19899) camel-servlet: Multipart attachment processing does not work on Undertow
James Netherton created CAMEL-19899: --- Summary: camel-servlet: Multipart attachment processing does not work on Undertow Key: CAMEL-19899 URL: https://issues.apache.org/jira/browse/CAMEL-19899 Project: Camel Issue Type: Bug Components: camel-servlet Reporter: James Netherton Something I observed with camel-servlet on Camel Quarkus. Undertow provides the Servlet support and the way that it's implementation of multipart attachment parsing works, assumes that the request body has not been read yet. Otherwise it will not attempt to process attachments. In DefaultHttpBinding.readyBody. The body is read first: https://github.com/apache/camel/blob/2509b469b5acfc46861643d01f0495133b690ddb/components/camel-http-common/src/main/java/org/apache/camel/http/common/DefaultHttpBinding.java#L203 And then attachments processed at the end: https://github.com/apache/camel/blob/2509b469b5acfc46861643d01f0495133b690ddb/components/camel-http-common/src/main/java/org/apache/camel/http/common/DefaultHttpBinding.java#L230 I tested moving attachment processing to the beginning and it made my test case work successfully. Not sure if that change could potentially screw things up non-undertow servlet containers? This same issue is probably present on Spring Boot with Undertow. I've not checked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19218) Add request validation feature for REST OPENAPI
[ https://issues.apache.org/jira/browse/CAMEL-19218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-19218. - Resolution: Fixed > Add request validation feature for REST OPENAPI > --- > > Key: CAMEL-19218 > URL: https://issues.apache.org/jira/browse/CAMEL-19218 > Project: Camel > Issue Type: New Feature > Components: camel-rest-openapi >Reporter: Zineb Bendhiba >Assignee: James Netherton >Priority: Major > Fix For: 4.1.0 > > > I'm currently investigating on adding this feature -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-19218) Add request validation feature for REST OPENAPI
[ https://issues.apache.org/jira/browse/CAMEL-19218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton reassigned CAMEL-19218: --- Assignee: James Netherton (was: Zineb Bendhiba) > Add request validation feature for REST OPENAPI > --- > > Key: CAMEL-19218 > URL: https://issues.apache.org/jira/browse/CAMEL-19218 > Project: Camel > Issue Type: New Feature > Components: camel-rest-openapi >Reporter: Zineb Bendhiba >Assignee: James Netherton >Priority: Major > Fix For: 4.1.0 > > > I'm currently investigating on adding this feature -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19218) Add request validation feature for REST OPENAPI
[ https://issues.apache.org/jira/browse/CAMEL-19218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766753#comment-17766753 ] James Netherton commented on CAMEL-19218: - I have looked into this a bit so I can take this issue. > Add request validation feature for REST OPENAPI > --- > > Key: CAMEL-19218 > URL: https://issues.apache.org/jira/browse/CAMEL-19218 > Project: Camel > Issue Type: New Feature > Components: camel-rest-openapi >Reporter: Zineb Bendhiba >Assignee: Zineb Bendhiba >Priority: Major > Fix For: 4.1.0 > > > I'm currently investigating on adding this feature -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19816) camel-platform-http-vertx: Add headers for local address & remote address
[ https://issues.apache.org/jira/browse/CAMEL-19816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton updated CAMEL-19816: Fix Version/s: 4.0.1 > camel-platform-http-vertx: Add headers for local address & remote address > - > > Key: CAMEL-19816 > URL: https://issues.apache.org/jira/browse/CAMEL-19816 > Project: Camel > Issue Type: Improvement > Components: camel-platform-http-vertx >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.0.1, 4.1.0 > > > netty-http provides the capability to retrieve info about the local and > remote address via headers CamelNettyLocalAddress & CamelNettyRemoteAddress. > It can be useful if you want to get at info like figuring out the address of > the connecting client. > We can do a similar thing in platform-http-vertx and get the relevant info > from the Vert.x HttpServerRequest on the RoutingContext. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19816) camel-platform-http-vertx: Add headers for local address & remote address
[ https://issues.apache.org/jira/browse/CAMEL-19816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-19816. - Resolution: Fixed > camel-platform-http-vertx: Add headers for local address & remote address > - > > Key: CAMEL-19816 > URL: https://issues.apache.org/jira/browse/CAMEL-19816 > Project: Camel > Issue Type: Improvement > Components: camel-platform-http-vertx >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 4.1.0 > > > netty-http provides the capability to retrieve info about the local and > remote address via headers CamelNettyLocalAddress & CamelNettyRemoteAddress. > It can be useful if you want to get at info like figuring out the address of > the connecting client. > We can do a similar thing in platform-http-vertx and get the relevant info > from the Vert.x HttpServerRequest on the RoutingContext. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19816) camel-platform-http-vertx: Add headers for local address & remote address
James Netherton created CAMEL-19816: --- Summary: camel-platform-http-vertx: Add headers for local address & remote address Key: CAMEL-19816 URL: https://issues.apache.org/jira/browse/CAMEL-19816 Project: Camel Issue Type: Improvement Components: camel-platform-http-vertx Reporter: James Netherton Assignee: James Netherton Fix For: 4.1.0 netty-http provides the capability to retrieve info about the local and remote address via headers CamelNettyLocalAddress & CamelNettyRemoteAddress. It can be useful if you want to get at info like figuring out the address of the connecting client. We can do a similar thing in platform-http-vertx and get the relevant info from the Vert.x HttpServerRequest on the RoutingContext. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19714) camel-jsonpath: Consider removing json-smart exclusion
James Netherton created CAMEL-19714:
---
Summary: camel-jsonpath: Consider removing json-smart exclusion
Key: CAMEL-19714
URL: https://issues.apache.org/jira/browse/CAMEL-19714
Project: Camel
Issue Type: Improvement
Components: camel-jsonpath
Reporter: James Netherton
json-smart is excluded in camel-jsonpath in favor of using Jackson.
The problem is that json-smart is not truly an optional dependency. Depending
on the jsonpath expressions used, you can end up with a ClassNotFoundException.
E.g given this JSON:
{code:java}
{
"messages": [
{
"id": 1,
"text": "Hello, this is a message from a user."
},
{
"id": 2,
"text": "This is another message from a user."
},
{
"id": 3,
"text": "This message is from a bot.",
"bot_id": "123"
},
]
}
{code}
And then using the expression:
{code:java}
$.messages[?(!@.bot_id)]
{code}
You get:
{code:java}
Caused by: java.lang.NoClassDefFoundError: net/minidev/json/writer/JsonReaderI
at
com.jayway.jsonpath.internal.DefaultsImpl.(DefaultsImpl.java:17)
at
com.jayway.jsonpath.internal.DefaultsImpl.(DefaultsImpl.java:15)
at
com.jayway.jsonpath.Configuration.getEffectiveDefaults(Configuration.java:43)
at com.jayway.jsonpath.Configuration.access$000(Configuration.java:29)
at
com.jayway.jsonpath.Configuration$ConfigurationBuilder.build(Configuration.java:224)
at
com.jayway.jsonpath.internal.filter.ValueNodes$PathNode.evaluate(ValueNodes.java:679)
at
com.jayway.jsonpath.internal.filter.RelationalExpressionNode.apply(RelationalExpressionNode.java:37)
at
com.jayway.jsonpath.internal.filter.FilterCompiler$CompiledFilter.apply(FilterCompiler.java:430)
at
com.jayway.jsonpath.internal.path.PredicatePathToken.accept(PredicatePathToken.java:77)
at
com.jayway.jsonpath.internal.path.PredicatePathToken.evaluate(PredicatePathToken.java:60)
at
com.jayway.jsonpath.internal.path.PathToken.handleObjectProperty(PathToken.java:90)
at
com.jayway.jsonpath.internal.path.PropertyPathToken.evaluate(PropertyPathToken.java:80)
at
com.jayway.jsonpath.internal.path.RootPathToken.evaluate(RootPathToken.java:66)
at
com.jayway.jsonpath.internal.path.CompiledPath.evaluate(CompiledPath.java:99)
at
com.jayway.jsonpath.internal.path.CompiledPath.evaluate(CompiledPath.java:107)
at com.jayway.jsonpath.JsonPath.read(JsonPath.java:191)
at com.jayway.jsonpath.internal.JsonContext.read(JsonContext.java:88)
at com.jayway.jsonpath.internal.JsonContext.read(JsonContext.java:77)
at
org.apache.camel.jsonpath.JsonPathEngine.readWithInputStream(JsonPathEngine.java:265)
at
org.apache.camel.jsonpath.JsonPathEngine.doRead(JsonPathEngine.java:219)
at
org.apache.camel.jsonpath.JsonPathEngine.read(JsonPathEngine.java:124)
at
org.apache.camel.jsonpath.JsonPathExpression.evaluateJsonPath(JsonPathExpression.java:220)
at
org.apache.camel.jsonpath.JsonPathExpression.evaluate(JsonPathExpression.java:170)
at
org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:45)
at
org.apache.camel.processor.TransformProcessor.process(TransformProcessor.java:47)
... 76 more
Caused by: java.lang.ClassNotFoundException: net.minidev.json.writer.JsonReaderI
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
... 101 more
{code}
Similar issue reported here when predicates are used:
https://github.com/json-path/JsonPath/issues/274
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-19660) camel-mapstruct: Improve support for Mappers defined as abstract classes
[
https://issues.apache.org/jira/browse/CAMEL-19660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Netherton updated CAMEL-19660:
Fix Version/s: 3.20.7
3.21.1
3.22.0
> camel-mapstruct: Improve support for Mappers defined as abstract classes
>
>
> Key: CAMEL-19660
> URL: https://issues.apache.org/jira/browse/CAMEL-19660
> Project: Camel
> Issue Type: Improvement
> Components: camel-mapstruct
>Reporter: James Netherton
>Assignee: James Netherton
>Priority: Minor
> Fix For: 3.20.7, 3.21.1, 3.22.0, 4.0.0
>
>
> If you define MapStruct mappings using an abstract class, then some unwanted
> TypeConverters get registered for the equals and wait methods. In the logs
> you see:
> {code:java}
> Added MapStruct type converter: long -> void
> Added MapStruct type converter: class java.lang.Object -> boolean
> {code}
> This happens because they pass the DefaultMapStructFinder.discoverMappings
> check for a single method arg ,but the void return type is checked against
> Void.class and not the primitive void.class. We should probably just filter
> out anything with a primitive return type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-19660) camel-mapstruct: Improve support for Mappers defined as abstract classes
[
https://issues.apache.org/jira/browse/CAMEL-19660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Netherton updated CAMEL-19660:
Fix Version/s: 4.0.0
> camel-mapstruct: Improve support for Mappers defined as abstract classes
>
>
> Key: CAMEL-19660
> URL: https://issues.apache.org/jira/browse/CAMEL-19660
> Project: Camel
> Issue Type: Improvement
> Components: camel-mapstruct
>Reporter: James Netherton
>Assignee: James Netherton
>Priority: Minor
> Fix For: 4.0.0
>
>
> If you define MapStruct mappings using an abstract class, then some unwanted
> TypeConverters get registered for the equals and wait methods. In the logs
> you see:
> {code:java}
> Added MapStruct type converter: long -> void
> Added MapStruct type converter: class java.lang.Object -> boolean
> {code}
> This happens because they pass the DefaultMapStructFinder.discoverMappings
> check for a single method arg ,but the void return type is checked against
> Void.class and not the primitive void.class. We should probably just filter
> out anything with a primitive return type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19660) camel-mapstruct: Improve support for Mappers defined as abstract classes
James Netherton created CAMEL-19660:
---
Summary: camel-mapstruct: Improve support for Mappers defined as
abstract classes
Key: CAMEL-19660
URL: https://issues.apache.org/jira/browse/CAMEL-19660
Project: Camel
Issue Type: Improvement
Components: camel-mapstruct
Reporter: James Netherton
Assignee: James Netherton
If you define MapStruct mappings using an abstract class, then some unwanted
TypeConverters get registered for the equals and wait methods. In the logs you
see:
{code:java}
Added MapStruct type converter: long -> void
Added MapStruct type converter: class java.lang.Object -> boolean
{code}
This happens because they pass the DefaultMapStructFinder.discoverMappings
check for a single method arg ,but the void return type is checked against
Void.class and not the primitive void.class. We should probably just filter out
anything with a primitive return type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19632) camel-xml-jaxp: Split package warning
James Netherton created CAMEL-19632:
---
Summary: camel-xml-jaxp: Split package warning
Key: CAMEL-19632
URL: https://issues.apache.org/jira/browse/CAMEL-19632
Project: Camel
Issue Type: Task
Reporter: James Netherton
Build time warning observed in Camel Quarkus with Camel 4.0.0-RC1:
{code}
2023-07-19T17:40:18.3973680Z 2023-07-19 17:40:18,263 WARN
[io.qua.arc.dep.SplitPackageProcessor] (build-30) Detected a split package
usage which is considered a bad practice and should be avoided. Following
packages were detected in multiple archives:
2023-07-19T17:40:18.3974807Z - "org.apache.camel.util.xml" found in
[org.apache.camel:camel-xml-jaxp-util::jar,
org.apache.camel:camel-xml-jaxp::jar]
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19627) paho-mqtt5: Allow password to be optional if username is provided
James Netherton created CAMEL-19627: --- Summary: paho-mqtt5: Allow password to be optional if username is provided Key: CAMEL-19627 URL: https://issues.apache.org/jira/browse/CAMEL-19627 Project: Camel Issue Type: Improvement Components: camel-paho-mqtt5 Reporter: James Netherton See background to this ticket here: https://github.com/apache/camel-quarkus/issues/5107 Seems in some scenarios it is desirable to not provide a password together with a username. The current way the component code is written expects both to be provided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19469) camel-opentelemetry: Context not propagated correctly when tracing bean or processor invocations with @WithSpan
James Netherton created CAMEL-19469:
---
Summary: camel-opentelemetry: Context not propagated correctly
when tracing bean or processor invocations with @WithSpan
Key: CAMEL-19469
URL: https://issues.apache.org/jira/browse/CAMEL-19469
Project: Camel
Issue Type: Bug
Components: camel-opentelemetry
Affects Versions: 4.0-M3, 3.20.5
Reporter: James Netherton
OpenTelemetry enables you to trace arbitrary method invocations by tagging them
with the @WithSpan annotation:
https://opentelemetry.io/docs/instrumentation/java/automatic/annotations/#creating-spans-around-methods-with-withspan
For some scenarios, the tracing context does not seem to get propagated and the
resulting spans end up being disassociated. For example:
{code}
from("timer:tick?period=5s)
.process("myProcessor");
{code}
{code}
public class MyProcessor implements Processor {
@WithSpan
@Override
public void process(Exchange exchange) {
// Useful work here...
}
}
{code}
This results in 2 spans. One for timer:tick & another for MyProcessor. The
problem is that the parent span for MyProcessor is not set, so they appear as 2
distinct traces.
There is a workaround where you can configure the route like this and the span
hierarchy ends up being correct:
{code}
from("timer:tick?period=5s")
.to("direct:start");
from("direct:start")
.process("myProcessor");
{code}
There's some more background in the original issue reported on Camel Quarkus:
https://github.com/apache/camel-quarkus/issues/4981
There's also a reproducer project here:
https://github.com/jamesnetherton/camel-opentelemetry-demo
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-19432) camel-azure-eventhubs: Providing a custom EventHubProducerAsyncClient has no effect
[
https://issues.apache.org/jira/browse/CAMEL-19432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Netherton resolved CAMEL-19432.
-
Resolution: Fixed
> camel-azure-eventhubs: Providing a custom EventHubProducerAsyncClient has no
> effect
> ---
>
> Key: CAMEL-19432
> URL: https://issues.apache.org/jira/browse/CAMEL-19432
> Project: Camel
> Issue Type: Bug
> Components: camel-azure-eventhubs
>Reporter: James Netherton
>Assignee: James Netherton
>Priority: Minor
> Fix For: 3.20.6, 3.21.0, 4.0-RC1, 4.0
>
>
> The azure-eventhubs component has a {{producerAsyncClient}} option where you
> can pass a custom {{EventHubProducerAsyncClient}} instance to the component
> configuration.
> Looking at the producer code, it seems that it gets ignored and a new
> {{EventHubProducerAsyncClient}} is created in {{doStart}}.
> https://github.com/apache/camel/blob/main/components/camel-azure/camel-azure-eventhubs/src/main/java/org/apache/camel/component/azure/eventhubs/EventHubsProducer.java#L41
> This was originally reported in the Camel Quarkus project:
> https://github.com/apache/camel-quarkus/issues/4975
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-19432) camel-azure-eventhubs: Providing a custom EventHubProducerAsyncClient has no effect
[
https://issues.apache.org/jira/browse/CAMEL-19432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Netherton reassigned CAMEL-19432:
---
Assignee: James Netherton
> camel-azure-eventhubs: Providing a custom EventHubProducerAsyncClient has no
> effect
> ---
>
> Key: CAMEL-19432
> URL: https://issues.apache.org/jira/browse/CAMEL-19432
> Project: Camel
> Issue Type: Bug
> Components: camel-azure-eventhubs
>Reporter: James Netherton
>Assignee: James Netherton
>Priority: Minor
> Fix For: 3.20.6, 3.21.0, 4.0-RC1, 4.0
>
>
> The azure-eventhubs component has a {{producerAsyncClient}} option where you
> can pass a custom {{EventHubProducerAsyncClient}} instance to the component
> configuration.
> Looking at the producer code, it seems that it gets ignored and a new
> {{EventHubProducerAsyncClient}} is created in {{doStart}}.
> https://github.com/apache/camel/blob/main/components/camel-azure/camel-azure-eventhubs/src/main/java/org/apache/camel/component/azure/eventhubs/EventHubsProducer.java#L41
> This was originally reported in the Camel Quarkus project:
> https://github.com/apache/camel-quarkus/issues/4975
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19432) camel-azure-eventhubs: Providing a custom EventHubProducerAsyncClient has no effect
James Netherton created CAMEL-19432:
---
Summary: camel-azure-eventhubs: Providing a custom
EventHubProducerAsyncClient has no effect
Key: CAMEL-19432
URL: https://issues.apache.org/jira/browse/CAMEL-19432
Project: Camel
Issue Type: Bug
Components: camel-azure-eventhubs
Reporter: James Netherton
The azure-eventhubs component has a {{producerAsyncClient}} option where you
can pass a custom {{EventHubProducerAsyncClient}} instance to the component
configuration.
Looking at the producer code, it seems that it gets ignored and a new
{{EventHubProducerAsyncClient}} is created in {{doStart}}.
https://github.com/apache/camel/blob/main/components/camel-azure/camel-azure-eventhubs/src/main/java/org/apache/camel/component/azure/eventhubs/EventHubsProducer.java#L41
This was originally reported in the Camel Quarkus project:
https://github.com/apache/camel-quarkus/issues/4975
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
