[jira] [Commented] (CAMEL-20798) camel-tracing - Add servername to more decorators
[ https://issues.apache.org/jira/browse/CAMEL-20798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849921#comment-17849921 ] Luca Burgazzoli commented on CAMEL-20798: - A about the AWS ones, there should be an *overrideEndpoint* property you can use to point to your compatible AWS API endpoint (as an example, that can be used for tests or to point to a minio/cepth s3 compatible endpoint). > camel-tracing - Add servername to more decorators > - > > Key: CAMEL-20798 > URL: https://issues.apache.org/jira/browse/CAMEL-20798 > Project: Camel > Issue Type: Improvement > Components: camel-tracing >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.7.0 > > > There is a tag for SERVER_ADDRESS which we can enrich for more of the > decorators. > > Some like JMS is harder as the JMS broker is configured specific such as > ActiveMQ has the brokerURL on the activemq class. > Kafka has boostrapServers etc. > We may add some SPI interface that a component can implemented, and then we > can call it via an endpoint, and then we can use the logic in the component > to return the server address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20807) Wrong list of spring boor ptoperties in tokenize language
Luca Burgazzoli created CAMEL-20807: --- Summary: Wrong list of spring boor ptoperties in tokenize language Key: CAMEL-20807 URL: https://issues.apache.org/jira/browse/CAMEL-20807 Project: Camel Issue Type: Bug Components: documentation Reporter: Luca Burgazzoli Attachments: image-2024-05-27-15-15-17-133.png The list of spring boot properties listed in [https://camel.apache.org/components/next/languages/tokenize-language.html] does not seems to be right as it includes a number of unrelated properties i.e. from camel-main: !image-2024-05-27-15-15-17-133.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18546) camel-core - HostedService - To mark a consumer as a Camel hosted service
[ https://issues.apache.org/jira/browse/CAMEL-18546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849680#comment-17849680 ] Luca Burgazzoli commented on CAMEL-18546: - Just for reference, in the past we had something similar: - [https://camel.apache.org/components/4.4.x/service-component.html] - [https://github.com/apache/camel/tree/main/components/camel-service] So there is a [ServiceRegistry|https://github.com/apache/camel/blob/main/core/camel-api/src/main/java/org/apache/camel/cloud/ServiceRegistry.java] where services can be registered. Not 100% the same but wonder if the API can be reused and eventually the old camle-service deprecated/removed. > camel-core - HostedService - To mark a consumer as a Camel hosted service > - > > Key: CAMEL-18546 > URL: https://issues.apache.org/jira/browse/CAMEL-18546 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.7.0 > > > A few components hosts a service exclusive in Camel such as HTTP/TCP based > from cxf > from platform-http > from servlet > from netty (not in client mode) > from mina > from mllp > from jetty > There may be a few others. > Its not the same as > from file > from jms > from kafka > As these are camel consumer that reacts on events from another "service", eg > JMS broker or Kafka broker. > If we have an API/SPI to mark a consumer as being a HostedConsumer (or come > up with a better name). Then we can collect service information, such as > - name > - protocol > - ur to call the service > - additional metadata > - api schema (optional) > Then we can make camel-core able to detect all its consumers that are hosted, > and be able to expose this so its easier for tooling etc to gather a list of > services. > There is something related to this in RestRegistry in camel-core but that was > for RESTful hosted service only. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-20740) Allow to configure multiple components of same type in application.properties
[ https://issues.apache.org/jira/browse/CAMEL-20740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843753#comment-17843753 ] Luca Burgazzoli edited comment on CAMEL-20740 at 5/6/24 2:02 PM: - Just for reference, I think at some point in the past we had a special _configurations_ entry in spring boot, like: {code} # standard component camel.component.sql.batch = 333 # custom sql component registered as ${alias} camel.component.sql.configurations.${alias}.batch = 444 {code} was (Author: lb): Just for reference, I think at some point in the past we had a special _configurations_ entry in spring boot, like: {code} # standard component camel.component.sql.batch = 333 # custom sql component registered as {alias} camel.component.sql.configurations.${alias}.batch = 444 {code} > Allow to configure multiple components of same type in application.properties > - > > Key: CAMEL-20740 > URL: https://issues.apache.org/jira/browse/CAMEL-20740 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > See if we can make it easier to define 2 JMS or 2+ SQL components with their > own configuration and do all of this via application.properties. > The default camel.component.sql is for the default component only. > So something > camel.component.mysql.alias=sql > camel.component.mysql.batch=123 > camel.component.oracle-db.alias=sql > camel.component.oracle-db.batch=444 > So the name of the component needs to use a non OOTB component name and have > an alias option that refers to the actual component. > This does impact tooling as they dont understand these "fake components" so > maybe we need to put this into another prefix to avoid confusion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20740) Allow to configure multiple components of same type in application.properties
[ https://issues.apache.org/jira/browse/CAMEL-20740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843753#comment-17843753 ] Luca Burgazzoli commented on CAMEL-20740: - Just for reference, I think at some point in the past we had a special _configurations_ entry in spring boot, like: {code} # standard component camel.component.sql.batch = 333 # custom sql component registered as {alias} camel.component.sql.configurations.${alias}.batch = 444 {code} > Allow to configure multiple components of same type in application.properties > - > > Key: CAMEL-20740 > URL: https://issues.apache.org/jira/browse/CAMEL-20740 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > See if we can make it easier to define 2 JMS or 2+ SQL components with their > own configuration and do all of this via application.properties. > The default camel.component.sql is for the default component only. > So something > camel.component.mysql.alias=sql > camel.component.mysql.batch=123 > camel.component.oracle-db.alias=sql > camel.component.oracle-db.batch=444 > So the name of the component needs to use a non OOTB component name and have > an alias option that refers to the actual component. > This does impact tooling as they dont understand these "fake components" so > maybe we need to put this into another prefix to avoid confusion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20675) camel-spring-boot: move cluster service implementations to dedicated starters
[ https://issues.apache.org/jira/browse/CAMEL-20675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-20675. - Resolution: Fixed > camel-spring-boot: move cluster service implementations to dedicated starters > - > > Key: CAMEL-20675 > URL: https://issues.apache.org/jira/browse/CAMEL-20675 > Project: Camel > Issue Type: Improvement > Components: camel-spring-boot-starters >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.6.0 > > > As today the auto configuration of a Cluster Service implementation is > provided as part of the related component starters, as an example, the > Kubernetes Cluster Service auto configuration is provided by the > camel-kubernetes-startes module and it is an opt in so a user has to explicit > enable it. > However, the goal of starters is usually to enable some behavior by just > adding the starter to the classpath, hence I think it would be nice to move > the Cluster Service auto configuration to dedicated starters and > automatically enable them when the starter is on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20675) camel-spring-boot: move cluster service implementations to dedicated starters
[ https://issues.apache.org/jira/browse/CAMEL-20675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-20675: Component/s: (was: camel-kubernetes) > camel-spring-boot: move cluster service implementations to dedicated starters > - > > Key: CAMEL-20675 > URL: https://issues.apache.org/jira/browse/CAMEL-20675 > Project: Camel > Issue Type: Improvement > Components: camel-spring-boot-starters >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > As today the auto configuration of a Cluster Service implementation is > provided as part of the related component starters, as an example, the > Kubernetes Cluster Service auto configuration is provided by the > camel-kubernetes-startes module and it is an opt in so a user has to explicit > enable it. > However, the goal of starters is usually to enable some behavior by just > adding the starter to the classpath, hence I think it would be nice to move > the Cluster Service auto configuration to dedicated starters and > automatically enable them when the starter is on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20675) camel-spring-boot: move cluster service implementations to dedicated starters
Luca Burgazzoli created CAMEL-20675: --- Summary: camel-spring-boot: move cluster service implementations to dedicated starters Key: CAMEL-20675 URL: https://issues.apache.org/jira/browse/CAMEL-20675 Project: Camel Issue Type: Improvement Components: camel-kubernetes, camel-spring-boot-starters Reporter: Luca Burgazzoli Assignee: Luca Burgazzoli Fix For: 4.x As today the auto configuration of a Cluster Service implementation is provided as part of the related component starters, as an example, the Kubernetes Cluster Service auto configuration is provided by the camel-kubernetes-startes module and it is an opt in so a user has to explicit enable it. However, the goal of starters is usually to enable some behavior by just adding the starter to the classpath, hence I think it would be nice to move the Cluster Service auto configuration to dedicated starters and automatically enable them when the starter is on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20524) Harmonize camel main configuration properties across runtimes
[ https://issues.apache.org/jira/browse/CAMEL-20524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831246#comment-17831246 ] Luca Burgazzoli commented on CAMEL-20524: - so we are fine ! thank you [~gnodet] > Harmonize camel main configuration properties across runtimes > - > > Key: CAMEL-20524 > URL: https://issues.apache.org/jira/browse/CAMEL-20524 > Project: Camel > Issue Type: Improvement > Components: camel-main, camel-quarkus, camel-spring-boot, > camel-spring-boot-starters >Reporter: Luca Burgazzoli >Assignee: Guillaume Nodet >Priority: Minor > > The camel-main module was originally designed to run make it easy to run > camel standalone without the need of a specific runtime (spring-boot, > quarkus, etc), but now camel-main is also a core component of camel-quarkus > and camel-spring-boot. > camel-main also offers a number of properties that can be configured to > configure camel-main, however, the runtimes may use some slight different > property naming/namespaces making things a little bit confusing. > As an example, camel-main defines a camel.main.routes-include-pattern > property to let camel discover routes, however in camel-spring-boot the same > property is camel.springboot..routes-include-pattern > Ideally, runtimes should honor camel-main property and reserve some specific > namespaces (i.e. camel.quarkus camel.springboot) for runtime specific options. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20548) catalog: include a capability section to advertise which artifact provides a specific feature
[ https://issues.apache.org/jira/browse/CAMEL-20548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-20548. - Fix Version/s: 4.5.0 (was: 4.x) Resolution: Fixed > catalog: include a capability section to advertise which artifact provides a > specific feature > - > > Key: CAMEL-20548 > URL: https://issues.apache.org/jira/browse/CAMEL-20548 > Project: Camel > Issue Type: Improvement > Components: camel-catalog >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.5.0 > > > In the camel-k catalog there is a section that maps a capability to a > specific artifact [1] so as example, you can discovery that the a > circuit-breaker implementation is provided by the > camel-quarkus-microprofile-fault-tolerance component/artifact. > It would be nice to have the same in the camel catalog so tooling can > discover what artifacts are required for a specific feature in a runtime > agnosctic way. > This can be part for example of the RuntimeProvider interface so each runtime > can override it with its specific mapping. > [1] > https://github.com/apache/camel-k-runtime/blob/main/support/camel-k-maven-plugin/src/main/java/org/apache/camel/k/tooling/maven/GenerateCatalogMojo.java#L460-L529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20548) catalog: include a capability section to advertise which artifact provides a specific feature
[ https://issues.apache.org/jira/browse/CAMEL-20548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20548 started by Luca Burgazzoli. --- > catalog: include a capability section to advertise which artifact provides a > specific feature > - > > Key: CAMEL-20548 > URL: https://issues.apache.org/jira/browse/CAMEL-20548 > Project: Camel > Issue Type: Improvement > Components: camel-catalog >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > In the camel-k catalog there is a section that maps a capability to a > specific artifact [1] so as example, you can discovery that the a > circuit-breaker implementation is provided by the > camel-quarkus-microprofile-fault-tolerance component/artifact. > It would be nice to have the same in the camel catalog so tooling can > discover what artifacts are required for a specific feature in a runtime > agnosctic way. > This can be part for example of the RuntimeProvider interface so each runtime > can override it with its specific mapping. > [1] > https://github.com/apache/camel-k-runtime/blob/main/support/camel-k-maven-plugin/src/main/java/org/apache/camel/k/tooling/maven/GenerateCatalogMojo.java#L460-L529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20548) catalog: include a capability section to advertise which artifact provides a specific feature
[ https://issues.apache.org/jira/browse/CAMEL-20548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-20548: --- Assignee: Luca Burgazzoli > catalog: include a capability section to advertise which artifact provides a > specific feature > - > > Key: CAMEL-20548 > URL: https://issues.apache.org/jira/browse/CAMEL-20548 > Project: Camel > Issue Type: Improvement > Components: camel-catalog >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > In the camel-k catalog there is a section that maps a capability to a > specific artifact [1] so as example, you can discovery that the a > circuit-breaker implementation is provided by the > camel-quarkus-microprofile-fault-tolerance component/artifact. > It would be nice to have the same in the camel catalog so tooling can > discover what artifacts are required for a specific feature in a runtime > agnosctic way. > This can be part for example of the RuntimeProvider interface so each runtime > can override it with its specific mapping. > [1] > https://github.com/apache/camel-k-runtime/blob/main/support/camel-k-maven-plugin/src/main/java/org/apache/camel/k/tooling/maven/GenerateCatalogMojo.java#L460-L529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20541) Include arbitrary metadata to the camel-catalog
[ https://issues.apache.org/jira/browse/CAMEL-20541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-20541. - Resolution: Fixed > Include arbitrary metadata to the camel-catalog > --- > > Key: CAMEL-20541 > URL: https://issues.apache.org/jira/browse/CAMEL-20541 > Project: Camel > Issue Type: Improvement > Components: camel-catalog >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.5.0 > > > It would be nice to include some additional and arbitrary metadata in the > camel-catalog, as example, for components: > {code:json} > { > "component": { > "metadata": { > "camel.apache.org/capabilities": "tracing,metrics" > } > } > {code} > This would helps tools to gather some additional information about the > various element of the catalog as well as generating custom catalog with > additional information needed by 3rd party tools. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20548) catalog: include a capability section to advertise which artifact provides a specific feature
[ https://issues.apache.org/jira/browse/CAMEL-20548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-20548: Description: In the camel-k catalog there is a section that maps a capability to a specific artifact [1] so as example, you can discovery that the a circuit-breaker implementation is provided by the camel-quarkus-microprofile-fault-tolerance component/artifact. It would be nice to have the same in the camel catalog so tooling can discover what artifacts are required for a specific feature in a runtime agnosctic way. This can be part for example of the RuntimeProvider interface so each runtime can override it with its specific mapping. [1] https://github.com/apache/camel-k-runtime/blob/main/support/camel-k-maven-plugin/src/main/java/org/apache/camel/k/tooling/maven/GenerateCatalogMojo.java#L460-L529 was: In the camel-k catalog there is a section that maps a capability to a specific artifact [1] so as example, you can discovery that the a circuit-breaker implementation is provided by the camel-quarkus-microprofile-fault-tolerance component/artifact. It would be nice to have the same in the camel catalog so tooling can discover what artifacts are required for a specific feature in a runtime agnosctic way [1] https://github.com/apache/camel-k-runtime/blob/main/support/camel-k-maven-plugin/src/main/java/org/apache/camel/k/tooling/maven/GenerateCatalogMojo.java#L460-L529 > catalog: include a capability section to advertise which artifact provides a > specific feature > - > > Key: CAMEL-20548 > URL: https://issues.apache.org/jira/browse/CAMEL-20548 > Project: Camel > Issue Type: Improvement > Components: camel-catalog >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > In the camel-k catalog there is a section that maps a capability to a > specific artifact [1] so as example, you can discovery that the a > circuit-breaker implementation is provided by the > camel-quarkus-microprofile-fault-tolerance component/artifact. > It would be nice to have the same in the camel catalog so tooling can > discover what artifacts are required for a specific feature in a runtime > agnosctic way. > This can be part for example of the RuntimeProvider interface so each runtime > can override it with its specific mapping. > [1] > https://github.com/apache/camel-k-runtime/blob/main/support/camel-k-maven-plugin/src/main/java/org/apache/camel/k/tooling/maven/GenerateCatalogMojo.java#L460-L529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20548) catalog: include a capability section to advertise which artifact provides a specific feature
[ https://issues.apache.org/jira/browse/CAMEL-20548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825170#comment-17825170 ] Luca Burgazzoli commented on CAMEL-20548: - [~davsclaus] what do you think ? > catalog: include a capability section to advertise which artifact provides a > specific feature > - > > Key: CAMEL-20548 > URL: https://issues.apache.org/jira/browse/CAMEL-20548 > Project: Camel > Issue Type: Improvement > Components: camel-catalog >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > In the camel-k catalog there is a section that maps a capability to a > specific artifact [1] so as example, you can discovery that the a > circuit-breaker implementation is provided by the > camel-quarkus-microprofile-fault-tolerance component/artifact. > It would be nice to have the same in the camel catalog so tooling can > discover what artifacts are required for a specific feature in a runtime > agnosctic way > [1] > https://github.com/apache/camel-k-runtime/blob/main/support/camel-k-maven-plugin/src/main/java/org/apache/camel/k/tooling/maven/GenerateCatalogMojo.java#L460-L529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20548) catalog: include a capability section to advertise which artifact provides a specific feature
Luca Burgazzoli created CAMEL-20548: --- Summary: catalog: include a capability section to advertise which artifact provides a specific feature Key: CAMEL-20548 URL: https://issues.apache.org/jira/browse/CAMEL-20548 Project: Camel Issue Type: Improvement Components: camel-catalog Reporter: Luca Burgazzoli Fix For: 4.x In the camel-k catalog there is a section that maps a capability to a specific artifact [1] so as example, you can discovery that the a circuit-breaker implementation is provided by the camel-quarkus-microprofile-fault-tolerance component/artifact. It would be nice to have the same in the camel catalog so tooling can discover what artifacts are required for a specific feature in a runtime agnosctic way [1] https://github.com/apache/camel-k-runtime/blob/main/support/camel-k-maven-plugin/src/main/java/org/apache/camel/k/tooling/maven/GenerateCatalogMojo.java#L460-L529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16557) Catalog: add a free form key value map on components, dataformats, languages, etc
[ https://issues.apache.org/jira/browse/CAMEL-16557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-16557: Summary: Catalog: add a free form key value map on components, dataformats, languages, etc (was: Catalog: add a free form key value map on components) > Catalog: add a free form key value map on components, dataformats, languages, > etc > - > > Key: CAMEL-16557 > URL: https://issues.apache.org/jira/browse/CAMEL-16557 > Project: Camel > Issue Type: New Feature > Components: Catalog >Reporter: Peter Palaga >Assignee: Peter Palaga >Priority: Major > Fix For: 3.10.0 > > > Camel K would like to receive the info which Camel components are included in > a given Camel Quarkus extension, see > https://github.com/apache/camel-quarkus/issues/2368 > Adding a free form key value map for storing this and any other subproject > specific info seems to make more sense than adding dedicated attributes that > would have little to no meaning in the context of Camel Core. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20541) Include arbitrary metadata to the camel-catalog
[ https://issues.apache.org/jira/browse/CAMEL-20541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20541 started by Luca Burgazzoli. --- > Include arbitrary metadata to the camel-catalog > --- > > Key: CAMEL-20541 > URL: https://issues.apache.org/jira/browse/CAMEL-20541 > Project: Camel > Issue Type: Improvement > Components: camel-catalog >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > It would be nice to include some additional and arbitrary metadata in the > camel-catalog, as example, for components: > {code:json} > { > "component": { > "metadata": { > "camel.apache.org/capabilities": "tracing,metrics" > } > } > {code} > This would helps tools to gather some additional information about the > various element of the catalog as well as generating custom catalog with > additional information needed by 3rd party tools. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20541) Include arbitrary metadata to the camel-catalog
Luca Burgazzoli created CAMEL-20541: --- Summary: Include arbitrary metadata to the camel-catalog Key: CAMEL-20541 URL: https://issues.apache.org/jira/browse/CAMEL-20541 Project: Camel Issue Type: Improvement Components: camel-catalog Reporter: Luca Burgazzoli Assignee: Luca Burgazzoli Fix For: 4.x It would be nice to include some additional and arbitrary metadata in the camel-catalog, as example, for components: {code:json} { "component": { "metadata": { "camel.apache.org/capabilities": "tracing,metrics" } } {code} This would helps tools to gather some additional information about the various element of the catalog as well as generating custom catalog with additional information needed by 3rd party tools. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20529) Misleading summary on components page
Luca Burgazzoli created CAMEL-20529: --- Summary: Misleading summary on components page Key: CAMEL-20529 URL: https://issues.apache.org/jira/browse/CAMEL-20529 Project: Camel Issue Type: Improvement Components: documentation Reporter: Luca Burgazzoli The [components page summary|https://camel.apache.org/components/4.4.x/index.html] is quite misleading as it says: {code} Component references are references used to place a component in an assembly. Apache Component references provides various references that offers services for messaging, sending data, notifications and various other services that can not only resolve easy messaging and transferring data but also provide securing of data. {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20524) Harmonize camel main configuration properties across runtimes
Luca Burgazzoli created CAMEL-20524: --- Summary: Harmonize camel main configuration properties across runtimes Key: CAMEL-20524 URL: https://issues.apache.org/jira/browse/CAMEL-20524 Project: Camel Issue Type: Improvement Components: camel-quarkus, camel-main, camel-spring-boot, camel-spring-boot-starters Reporter: Luca Burgazzoli The camel-main module was originally designed to run make it easy to run camel standalone without the need of a specific runtime (spring-boot, quarkus, etc), but now camel-main is also a core component of camel-quarkus and camel-spring-boot. camel-main also offers a number of properties that can be configured to configure camel-main, however, the runtimes may use some slight different property naming/namespaces making things a little bit confusing. As an example, camel-main defines a camel.main.routes-include-pattern property to let camel discover routes, however in camel-spring-boot the same property is camel.springboot..routes-include-pattern Ideally, runtimes should honor camel-main property and reserve some specific namespaces (i.e. camel.quarkus camel.springboot) for runtime specific options. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20404) Create a component for Qdrant Vector Database
[ https://issues.apache.org/jira/browse/CAMEL-20404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-20404. - Resolution: Fixed > Create a component for Qdrant Vector Database > - > > Key: CAMEL-20404 > URL: https://issues.apache.org/jira/browse/CAMEL-20404 > Project: Camel > Issue Type: New Feature >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.5.0 > > > It would be nice to have a component for the [Qdrant Vector > Database|[https://qdrant.tech/]] > A java client is provided: https://github.com/qdrant/java-client -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20412) camel-knative: remove transport abstraction as knative is only http
Luca Burgazzoli created CAMEL-20412: --- Summary: camel-knative: remove transport abstraction as knative is only http Key: CAMEL-20412 URL: https://issues.apache.org/jira/browse/CAMEL-20412 Project: Camel Issue Type: Improvement Components: camel-knative Reporter: Luca Burgazzoli Fix For: 4.x When the camel-knative was first created as part of the camel-k project, knative was supposed to support different transports hence the component was designed with that in mind and a number of SPI were introduced to abstract the component from the specific transport. However as today, Knative is http only so we can remove the abstractions and make the code simpler. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20404) Create a component for Qdrant Vector Database
[ https://issues.apache.org/jira/browse/CAMEL-20404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20404 started by Luca Burgazzoli. --- > Create a component for Qdrant Vector Database > - > > Key: CAMEL-20404 > URL: https://issues.apache.org/jira/browse/CAMEL-20404 > Project: Camel > Issue Type: New Feature >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > It would be nice to have a component for the [Qdrant Vector > Database|[https://qdrant.tech/]] > A java client is provided: https://github.com/qdrant/java-client -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20404) Create a component for Qdrant Vector Database
[ https://issues.apache.org/jira/browse/CAMEL-20404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-20404: --- Assignee: Luca Burgazzoli > Create a component for Qdrant Vector Database > - > > Key: CAMEL-20404 > URL: https://issues.apache.org/jira/browse/CAMEL-20404 > Project: Camel > Issue Type: New Feature >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > It would be nice to have a component for the [Qdrant Vector > Database|[https://qdrant.tech/]] > A java client is provided: https://github.com/qdrant/java-client -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20404) Create a component for Qdrant Vector Database
Luca Burgazzoli created CAMEL-20404: --- Summary: Create a component for Qdrant Vector Database Key: CAMEL-20404 URL: https://issues.apache.org/jira/browse/CAMEL-20404 Project: Camel Issue Type: New Feature Reporter: Luca Burgazzoli Fix For: 4.x It would be nice to have a component for the [Qdrant Vector Database|[https://qdrant.tech/]] A java client is provided: https://github.com/qdrant/java-client -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20400) Support for Knative SinkBinding
[ https://issues.apache.org/jira/browse/CAMEL-20400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-20400. - Resolution: Fixed > Support for Knative SinkBinding > --- > > Key: CAMEL-20400 > URL: https://issues.apache.org/jira/browse/CAMEL-20400 > Project: Camel > Issue Type: Improvement > Components: camel-knative >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 4.4.0 > > > The camel-k-runtime project offers native support for > [SinkBinding|https://knative.dev/docs/eventing/custom-event-source/sinkbinding/] > in the form as a > [ContextCustomizer|https://github.com/apache/camel-k-runtime/blob/main/camel-k-knative/impl/src/main/java/org/apache/camel/k/knative/customizer/KnativeSinkBindingContextCustomizer.java] > > We should port that code over form camel-k-runtime to the camel project -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20400) Support for Knative SinkBinding
[ https://issues.apache.org/jira/browse/CAMEL-20400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-20400: Fix Version/s: 4.4.0 (was: 4.x) > Support for Knative SinkBinding > --- > > Key: CAMEL-20400 > URL: https://issues.apache.org/jira/browse/CAMEL-20400 > Project: Camel > Issue Type: Improvement > Components: camel-knative >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 4.4.0 > > > The camel-k-runtime project offers native support for > [SinkBinding|https://knative.dev/docs/eventing/custom-event-source/sinkbinding/] > in the form as a > [ContextCustomizer|https://github.com/apache/camel-k-runtime/blob/main/camel-k-knative/impl/src/main/java/org/apache/camel/k/knative/customizer/KnativeSinkBindingContextCustomizer.java] > > We should port that code over form camel-k-runtime to the camel project -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20400) Support for Knative SinkBinding
[ https://issues.apache.org/jira/browse/CAMEL-20400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-20400: Summary: Support for Knative SinkBinding (was: Knative : support for SunkBinding) > Support for Knative SinkBinding > --- > > Key: CAMEL-20400 > URL: https://issues.apache.org/jira/browse/CAMEL-20400 > Project: Camel > Issue Type: Improvement > Components: camel-knative >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 4.x > > > The camel-k-runtime project offers native support for > [SinkBinding|https://knative.dev/docs/eventing/custom-event-source/sinkbinding/] > in the form as a > [ContextCustomizer|https://github.com/apache/camel-k-runtime/blob/main/camel-k-knative/impl/src/main/java/org/apache/camel/k/knative/customizer/KnativeSinkBindingContextCustomizer.java] > > We should port that code over form camel-k-runtime to the camel project -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20400) Knative : support for SunkBinding
[ https://issues.apache.org/jira/browse/CAMEL-20400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20400 started by Luca Burgazzoli. --- > Knative : support for SunkBinding > - > > Key: CAMEL-20400 > URL: https://issues.apache.org/jira/browse/CAMEL-20400 > Project: Camel > Issue Type: Improvement > Components: camel-knative >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 4.x > > > The camel-k-runtime project offers native support for > [SinkBinding|https://knative.dev/docs/eventing/custom-event-source/sinkbinding/] > in the form as a > [ContextCustomizer|https://github.com/apache/camel-k-runtime/blob/main/camel-k-knative/impl/src/main/java/org/apache/camel/k/knative/customizer/KnativeSinkBindingContextCustomizer.java] > > We should port that code over form camel-k-runtime to the camel project -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20400) Knative : support for SunkBinding
[ https://issues.apache.org/jira/browse/CAMEL-20400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-20400: --- Assignee: Luca Burgazzoli > Knative : support for SunkBinding > - > > Key: CAMEL-20400 > URL: https://issues.apache.org/jira/browse/CAMEL-20400 > Project: Camel > Issue Type: Improvement > Components: camel-knative >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 4.x > > > The camel-k-runtime project offers native support for > [SinkBinding|https://knative.dev/docs/eventing/custom-event-source/sinkbinding/] > in the form as a > [ContextCustomizer|https://github.com/apache/camel-k-runtime/blob/main/camel-k-knative/impl/src/main/java/org/apache/camel/k/knative/customizer/KnativeSinkBindingContextCustomizer.java] > > We should port that code over form camel-k-runtime to the camel project -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20400) Knative : support for SunkBinding
Luca Burgazzoli created CAMEL-20400: --- Summary: Knative : support for SunkBinding Key: CAMEL-20400 URL: https://issues.apache.org/jira/browse/CAMEL-20400 Project: Camel Issue Type: Improvement Components: camel-knative Reporter: Luca Burgazzoli Fix For: 4.x The camel-k-runtime project offers native support for [SinkBinding|https://knative.dev/docs/eventing/custom-event-source/sinkbinding/] in the form as a [ContextCustomizer|https://github.com/apache/camel-k-runtime/blob/main/camel-k-knative/impl/src/main/java/org/apache/camel/k/knative/customizer/KnativeSinkBindingContextCustomizer.java] We should port that code over form camel-k-runtime to the camel project -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20336) Add a WebAssembly component and language
Luca Burgazzoli created CAMEL-20336: --- Summary: Add a WebAssembly component and language Key: CAMEL-20336 URL: https://issues.apache.org/jira/browse/CAMEL-20336 Project: Camel Issue Type: New Feature Reporter: Luca Burgazzoli Assignee: Luca Burgazzoli Fix For: 4.x I made a little [POC|https://lburgazzoli.github.io/posts/2024-01-14_apache_camel_meets_wasm_part_1/] to create a WebAssembly component and I think it would be nice to include it in the official camel repo -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20336) Add a WebAssembly component and language
[ https://issues.apache.org/jira/browse/CAMEL-20336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20336 started by Luca Burgazzoli. --- > Add a WebAssembly component and language > > > Key: CAMEL-20336 > URL: https://issues.apache.org/jira/browse/CAMEL-20336 > Project: Camel > Issue Type: New Feature >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > I made a little > [POC|https://lburgazzoli.github.io/posts/2024-01-14_apache_camel_meets_wasm_part_1/] > to create a WebAssembly component and I think it would be nice to include it > in the official camel repo -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-16234) camel-main - Allow 3rd party components to offer configuration options
[ https://issues.apache.org/jira/browse/CAMEL-16234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-16234: --- Assignee: Luca Burgazzoli > camel-main - Allow 3rd party components to offer configuration options > -- > > Key: CAMEL-16234 > URL: https://issues.apache.org/jira/browse/CAMEL-16234 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen >Assignee: Luca Burgazzoli >Priority: Major > > Today we put stuff into camel-main for various things you can configure. Most > of that are stuff that is in core. > But when we have components outside core, that are pluggable, then it would > be great if they can provide their own configuration with them, and then have > that as metadata and a configuration class (for java based configuration). > We need the maven tooling to generate those meta data file, and java based > configuration fluent builders. > Then for java you can register the addon in main ala > main.configure(MyFooThingy.class) >.someFooStuffHere(true) >.someOtherFooish(123) > .end() > For example camel-saga, and the 3 circuit breakers are today hardcoded into > camel-main. > Those can be candidates to try out with. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19919) camel-kafka: provided an out of the box byte[] to String header deserializer
[ https://issues.apache.org/jira/browse/CAMEL-19919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-19919: Fix Version/s: 4.0.2 > camel-kafka: provided an out of the box byte[] to String header deserializer > - > > Key: CAMEL-19919 > URL: https://issues.apache.org/jira/browse/CAMEL-19919 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.0.2, 4.1.0 > > > Headers in a Kafka Record are expressed as byte[], and it is quite common to > convert such headers to String. > It would be nice to provide a ready to use byte[] to String header > deserializer instead, something like: > {code:java} > import java.nio.charset.Charset; > import java.nio.charset.StandardCharsets; > import java.util.Objects; > import org.apache.camel.component.kafka.serde.KafkaHeaderDeserializer; > public class ToStringHeaderDeserializer implements KafkaHeaderDeserializer { > private Charset charset = StandardCharsets.UTF_8; > public Charset getCharset() { > return charset; > } > public void setCharset(Charset charset) { > this.charset = Objects.requireNonNull(charset); > } > @Override > public Object deserialize(String key, byte[] value) { > return new String(value, this.charset); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19919) camel-kafka: provided an out of the box byte[] to String header deserializer
[ https://issues.apache.org/jira/browse/CAMEL-19919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769586#comment-17769586 ] Luca Burgazzoli commented on CAMEL-19919: - that would be nice, let me do it > camel-kafka: provided an out of the box byte[] to String header deserializer > - > > Key: CAMEL-19919 > URL: https://issues.apache.org/jira/browse/CAMEL-19919 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.1.0 > > > Headers in a Kafka Record are expressed as byte[], and it is quite common to > convert such headers to String. > It would be nice to provide a ready to use byte[] to String header > deserializer instead, something like: > {code:java} > import java.nio.charset.Charset; > import java.nio.charset.StandardCharsets; > import java.util.Objects; > import org.apache.camel.component.kafka.serde.KafkaHeaderDeserializer; > public class ToStringHeaderDeserializer implements KafkaHeaderDeserializer { > private Charset charset = StandardCharsets.UTF_8; > public Charset getCharset() { > return charset; > } > public void setCharset(Charset charset) { > this.charset = Objects.requireNonNull(charset); > } > @Override > public Object deserialize(String key, byte[] value) { > return new String(value, this.charset); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-19919) camel-kafka: provided an out of the box byte[] to String header deserializer
[ https://issues.apache.org/jira/browse/CAMEL-19919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-19919: --- Assignee: Luca Burgazzoli > camel-kafka: provided an out of the box byte[] to String header deserializer > - > > Key: CAMEL-19919 > URL: https://issues.apache.org/jira/browse/CAMEL-19919 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.1.0 > > > Headers in a Kafka Record are expressed as byte[], and it is quite common to > convert such headers to String. > It would be nice to provide a ready to use byte[] to String header > deserializer instead, something like: > {code:java} > import java.nio.charset.Charset; > import java.nio.charset.StandardCharsets; > import java.util.Objects; > import org.apache.camel.component.kafka.serde.KafkaHeaderDeserializer; > public class ToStringHeaderDeserializer implements KafkaHeaderDeserializer { > private Charset charset = StandardCharsets.UTF_8; > public Charset getCharset() { > return charset; > } > public void setCharset(Charset charset) { > this.charset = Objects.requireNonNull(charset); > } > @Override > public Object deserialize(String key, byte[] value) { > return new String(value, this.charset); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19919) camel-kafka: provided an out of the box byte[] to String header deserializer
[ https://issues.apache.org/jira/browse/CAMEL-19919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-19919: Description: Headers in a Kafka Record are expressed as byte[], and it is quite common to convert such headers to String. It would be nice to provide a ready to use byte[] to String header deserializer instead, something like: {code:java} import java.nio.charset.Charset; import java.nio.charset.StandardCharsets; import java.util.Objects; import org.apache.camel.component.kafka.serde.KafkaHeaderDeserializer; public class ToStringHeaderDeserializer implements KafkaHeaderDeserializer { private Charset charset = StandardCharsets.UTF_8; public Charset getCharset() { return charset; } public void setCharset(Charset charset) { this.charset = Objects.requireNonNull(charset); } @Override public Object deserialize(String key, byte[] value) { return new String(value, this.charset); } } {code} was: Headers in a Kafka Record are expressed as byte[], and it is quite common to convert such headers to String. It would be nice to provide a ready to use byte[] to String header deserializer instead. > camel-kafka: provided an out of the box byte[] to String header deserializer > - > > Key: CAMEL-19919 > URL: https://issues.apache.org/jira/browse/CAMEL-19919 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 4.1.0 > > > Headers in a Kafka Record are expressed as byte[], and it is quite common to > convert such headers to String. > It would be nice to provide a ready to use byte[] to String header > deserializer instead, something like: > {code:java} > import java.nio.charset.Charset; > import java.nio.charset.StandardCharsets; > import java.util.Objects; > import org.apache.camel.component.kafka.serde.KafkaHeaderDeserializer; > public class ToStringHeaderDeserializer implements KafkaHeaderDeserializer { > private Charset charset = StandardCharsets.UTF_8; > public Charset getCharset() { > return charset; > } > public void setCharset(Charset charset) { > this.charset = Objects.requireNonNull(charset); > } > @Override > public Object deserialize(String key, byte[] value) { > return new String(value, this.charset); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19919) camel-kafka: provided an out of the box byte[] to String header deserializer
Luca Burgazzoli created CAMEL-19919: --- Summary: camel-kafka: provided an out of the box byte[] to String header deserializer Key: CAMEL-19919 URL: https://issues.apache.org/jira/browse/CAMEL-19919 Project: Camel Issue Type: Improvement Components: camel-kafka Reporter: Luca Burgazzoli Fix For: 4.1.0 Headers in a Kafka Record are expressed as byte[], and it is quite common to convert such headers to String. It would be nice to provide a ready to use byte[] to String header deserializer instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19718) camel-util-json should allow to configure escape forward slashes or not
[ https://issues.apache.org/jira/browse/CAMEL-19718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-19718: Summary: camel-util-json should allow to configure escape forward slashes or not (was: camel-util-json should not escape slashes in strings) > camel-util-json should allow to configure escape forward slashes or not > --- > > Key: CAMEL-19718 > URL: https://issues.apache.org/jira/browse/CAMEL-19718 > Project: Camel > Issue Type: Improvement > Components: tooling >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 4.1.0 > > > Wile exploring > [CAMEL-19717|https://issues.apache.org/jira/browse/CAMEL-19717], I noticed > that camel-util-json escapes i.e. slashes: > > {code:json} > "beans": { > "$ref": > "#\/items\/definitions\/org.apache.camel.dsl.yaml.deserializers.BeansDeserializer" > }, > {code} > This is not required in json-schema and would be nice to have a way to > configure JSooner to disable such behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19703) [yaml dsl] remove kebab-case schema definition
[ https://issues.apache.org/jira/browse/CAMEL-19703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751664#comment-17751664 ] Luca Burgazzoli commented on CAMEL-19703: - [~aurelien.pupier] do you know how/if vscode support this ? it would be nice if by default vscode would pick the main url but the user had the chance to switch to another version if working with an older version of camel > [yaml dsl] remove kebab-case schema definition > -- > > Key: CAMEL-19703 > URL: https://issues.apache.org/jira/browse/CAMEL-19703 > Project: Camel > Issue Type: Task > Components: camel-yaml-dsl >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 4.0.0 > > > As today there are two schema for the YAML dsl: > - one that uses camelCase > - one that uses kebab-case > since the kebab-case is a leftover from an initial version and was meant to > be removed, we can take finally remove it now that we are moving to a new > major release. > once removed we also need to update the [schemastore > repository|https://github.com/SchemaStore/schemastore/blob/14f6880f5e6520beb1889f404589008fda1bd09f/src/api/json/catalog.json#L745-L750] > to point to the right schema -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-19717) [yaml dsl] replace jackson with camel-util-json for json schema generation
[ https://issues.apache.org/jira/browse/CAMEL-19717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-19717: --- Assignee: Luca Burgazzoli > [yaml dsl] replace jackson with camel-util-json for json schema generation > -- > > Key: CAMEL-19717 > URL: https://issues.apache.org/jira/browse/CAMEL-19717 > Project: Camel > Issue Type: Improvement > Components: camel-yaml-dsl >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.1.0 > > > as today, the yaml dsl Json schema generation leverages Jackson, however for > consistency with json code generation in Camel, it would be nice to re-write > the schema generation on top of camel-util-json -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19718) camel-util-json should not escape slashes in strings
Luca Burgazzoli created CAMEL-19718: --- Summary: camel-util-json should not escape slashes in strings Key: CAMEL-19718 URL: https://issues.apache.org/jira/browse/CAMEL-19718 Project: Camel Issue Type: Improvement Components: tooling Reporter: Luca Burgazzoli Fix For: 4.1.0 Wile exploring [CAMEL-19717|https://issues.apache.org/jira/browse/CAMEL-19717], I noticed that camel-util-json escapes i.e. slashes: {code:json} "beans": { "$ref": "#\/items\/definitions\/org.apache.camel.dsl.yaml.deserializers.BeansDeserializer" }, {code} This is not required in json-schema and would be nice to have a way to configure JSooner to disable such behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19717) [yaml dsl] replace jackson with camel-util-json for json schema generation
Luca Burgazzoli created CAMEL-19717: --- Summary: [yaml dsl] replace jackson with camel-util-json for json schema generation Key: CAMEL-19717 URL: https://issues.apache.org/jira/browse/CAMEL-19717 Project: Camel Issue Type: Improvement Components: camel-yaml-dsl Reporter: Luca Burgazzoli Fix For: 4.1.0 as today, the yaml dsl Json schema generation leverages Jackson, however for consistency with json code generation in Camel, it would be nice to re-write the schema generation on top of camel-util-json -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-19709) [yaml dsl] include additional information such as description and title in the jscon schema
[ https://issues.apache.org/jira/browse/CAMEL-19709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-19709 started by Luca Burgazzoli. --- > [yaml dsl] include additional information such as description and title in > the jscon schema > --- > > Key: CAMEL-19709 > URL: https://issues.apache.org/jira/browse/CAMEL-19709 > Project: Camel > Issue Type: Improvement > Components: camel-yaml-dsl >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.0.0 > > > As today the YAML DSL Json schema is very minimal and does not include any > description or title for properties. > As the Json schema is also useful for tooling to provide code assistance in > addition to validation, it would be nice to have such information included in > the schema by default. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19698) camel-yaml-dsl: Express "simple" and "expression.simple" are mutually exclusive if possible
[ https://issues.apache.org/jira/browse/CAMEL-19698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750781#comment-17750781 ] Luca Burgazzoli commented on CAMEL-19698: - [~marat.gubaidul...@gmail.com] thx > camel-yaml-dsl: Express "simple" and "expression.simple" are mutually > exclusive if possible > > > Key: CAMEL-19698 > URL: https://issues.apache.org/jira/browse/CAMEL-19698 > Project: Camel > Issue Type: Task > Components: camel-yaml-dsl >Reporter: Tomohisa Igarashi >Assignee: Luca Burgazzoli >Priority: Major > > For example currently YAML DSL allows specifying both "simple" and > "expression" under "when" > {code:yaml} > - from: > uri: "timer:test" > parameters: > period: 3000 > steps: > - when: > simple: "${header.baz} != null" > expression: > simple: "${header.baz} == null" > steps: > - log: "test" > {code} > But at runtime only latter wins in this case. It would be nice if this > exclusiveness could be expressed in the schema. > Similarly, this "anyOf" seems to allow specifying multiple expressions > https://github.com/apache/camel/blob/36bcd6277854b8e69ca91a8d51845a306b1c2136/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camel-yaml-dsl.json#L3567-L3569 > for example > {code:yaml} > - from: > uri: "timer:test" > parameters: > period: 3000 > steps: > - when: > simple: ${header.baz} != null > jq: ".foo" > steps: > - log: "test" > {code} > Although this ends up with a runtime error > {noformat} > 2023-08-02 14:27:29.445 INFO 1579388 --- [ main] > org.apache.camel.main.MainSupport : Using Java 20.0.1 with PID 1579388. > Started by tomo in /home/tomo/workspace/Kaoto/datamapper-research/examples > Field: jq has already been configured as an expression > in file:test.yaml, line 8, column 13: > jq: ".foo" > ^ > at > org.apache.camel.dsl.yaml.deserializers.ModelDeserializers$WhenDefinitionDeserializer.setProperty(ModelDeserializers.java:18445) > at > org.apache.camel.dsl.yaml.deserializers.ModelDeserializers$WhenDefinitionDeserializer.setProperty(ModelDeserializers.java:18385) > at > org.apache.camel.dsl.yaml.common.YamlDeserializerBase.setProperties(YamlDeserializerBase.java:125) > at > org.apache.camel.dsl.yaml.common.YamlDeserializerBase.construct(YamlDeserializerBase.java:65) > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19709) [yaml dsl] include additional information such as description and title in the jscon schema
Luca Burgazzoli created CAMEL-19709: --- Summary: [yaml dsl] include additional information such as description and title in the jscon schema Key: CAMEL-19709 URL: https://issues.apache.org/jira/browse/CAMEL-19709 Project: Camel Issue Type: Improvement Components: camel-yaml-dsl Reporter: Luca Burgazzoli Assignee: Luca Burgazzoli Fix For: 4.0.0 As today the YAML DSL Json schema is very minimal and does not include any description or title for properties. As the Json schema is also useful for tooling to provide code assistance in addition to validation, it would be nice to have such information included in the schema by default. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19703) [yaml dsl] remove kebab-case schema definition
[ https://issues.apache.org/jira/browse/CAMEL-19703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750770#comment-17750770 ] Luca Burgazzoli commented on CAMEL-19703: - About schemastore, we can eventually use versions to point to different branches, as example: {code:json} { "name": "BX CI", "description": "CI configuration for Amdocs Bill Experience projects", "url": "https://json.schemastore.org/bxci.schema-2.x.json;, "fileMatch": ["**/bxci.yaml", "**/bxci.yml"], "versions": { "1.0": "https://json.schemastore.org/bxci.schema-1.0.json;, "1.0.1": "https://json.schemastore.org/bxci.schema-1.0.1.json;, "2.0.0": "https://json.schemastore.org/bxci.schema-2.0.0.json;, "2.x": "https://json.schemastore.org/bxci.schema-2.x.json; } } {code} There is also an option to define versions in the camel, an example https://github.com/SchemaStore/schemastore/pull/2057#issuecomment-1024470105 > [yaml dsl] remove kebab-case schema definition > -- > > Key: CAMEL-19703 > URL: https://issues.apache.org/jira/browse/CAMEL-19703 > Project: Camel > Issue Type: Task > Components: camel-yaml-dsl >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 4.0.0 > > > As today there are two schema for the YAML dsl: > - one that uses camelCase > - one that uses kebab-case > since the kebab-case is a leftover from an initial version and was meant to > be removed, we can take finally remove it now that we are moving to a new > major release. > once removed we also need to update the [schemastore > repository|https://github.com/SchemaStore/schemastore/blob/14f6880f5e6520beb1889f404589008fda1bd09f/src/api/json/catalog.json#L745-L750] > to point to the right schema -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19703) [yaml dsl] remove kebab-case schema definition
[ https://issues.apache.org/jira/browse/CAMEL-19703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-19703: Summary: [yaml dsl] remove kebab-case schema definition (was: [yaml sdl] remove kebab-case schema definition) > [yaml dsl] remove kebab-case schema definition > -- > > Key: CAMEL-19703 > URL: https://issues.apache.org/jira/browse/CAMEL-19703 > Project: Camel > Issue Type: Task > Components: camel-yaml-dsl >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 4.0.0 > > > As today there are two schema for the YAML dsl: > - one that uses camelCase > - one that uses kebab-case > since the kebab-case is a leftover from an initial version and was meant to > be removed, we can take finally remove it now that we are moving to a new > major release. > once removed we also need to update the [schemastore > repository|https://github.com/SchemaStore/schemastore/blob/14f6880f5e6520beb1889f404589008fda1bd09f/src/api/json/catalog.json#L745-L750] > to point to the right schema -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19703) [yaml sdl] remove kebab-case schema definition
Luca Burgazzoli created CAMEL-19703: --- Summary: [yaml sdl] remove kebab-case schema definition Key: CAMEL-19703 URL: https://issues.apache.org/jira/browse/CAMEL-19703 Project: Camel Issue Type: Task Components: camel-yaml-dsl Reporter: Luca Burgazzoli Fix For: 4.0.0 As today there are two schema for the YAML dsl: - one that uses camelCase - one that uses kebab-case since the kebab-case is a leftover from an initial version and was meant to be removed, we can take finally remove it now that we are moving to a new major release. once removed we also need to update the [schemastore repository|https://github.com/SchemaStore/schemastore/blob/14f6880f5e6520beb1889f404589008fda1bd09f/src/api/json/catalog.json#L745-L750] to point to the right schema -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19698) camel-yaml-dsl: Express "simple" and "expression.simple" are mutually exclusive if possible
[ https://issues.apache.org/jira/browse/CAMEL-19698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750594#comment-17750594 ] Luca Burgazzoli edited comment on CAMEL-19698 at 8/3/23 6:45 AM: - [~marat.gubaidul...@gmail.com] what happens when Karavan encounter an "inline" variant ? is it still able to render it properly and then when it is saved back it is re-written as full expression/type/expression ? was (Author: lb): [~marat.gubaidul...@gmail.com] what happens when the tooling encounter an "inline" variant ? is it still able to render it properly and then when it is saved back it is re-written as full expression/type/expression ? > camel-yaml-dsl: Express "simple" and "expression.simple" are mutually > exclusive if possible > > > Key: CAMEL-19698 > URL: https://issues.apache.org/jira/browse/CAMEL-19698 > Project: Camel > Issue Type: Task > Components: camel-yaml-dsl >Reporter: Tomohisa Igarashi >Assignee: Luca Burgazzoli >Priority: Major > > For example currently YAML DSL allows specifying both "simple" and > "expression" under "when" > {code:yaml} > - from: > uri: "timer:test" > parameters: > period: 3000 > steps: > - when: > simple: "${header.baz} != null" > expression: > simple: "${header.baz} == null" > steps: > - log: "test" > {code} > But at runtime only latter wins in this case. It would be nice if this > exclusiveness could be expressed in the schema. > Similarly, this "anyOf" seems to allow specifying multiple expressions > https://github.com/apache/camel/blob/36bcd6277854b8e69ca91a8d51845a306b1c2136/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camel-yaml-dsl.json#L3567-L3569 > for example > {code:yaml} > - from: > uri: "timer:test" > parameters: > period: 3000 > steps: > - when: > simple: ${header.baz} != null > jq: ".foo" > steps: > - log: "test" > {code} > Although this ends up with a runtime error > {noformat} > 2023-08-02 14:27:29.445 INFO 1579388 --- [ main] > org.apache.camel.main.MainSupport : Using Java 20.0.1 with PID 1579388. > Started by tomo in /home/tomo/workspace/Kaoto/datamapper-research/examples > Field: jq has already been configured as an expression > in file:test.yaml, line 8, column 13: > jq: ".foo" > ^ > at > org.apache.camel.dsl.yaml.deserializers.ModelDeserializers$WhenDefinitionDeserializer.setProperty(ModelDeserializers.java:18445) > at > org.apache.camel.dsl.yaml.deserializers.ModelDeserializers$WhenDefinitionDeserializer.setProperty(ModelDeserializers.java:18385) > at > org.apache.camel.dsl.yaml.common.YamlDeserializerBase.setProperties(YamlDeserializerBase.java:125) > at > org.apache.camel.dsl.yaml.common.YamlDeserializerBase.construct(YamlDeserializerBase.java:65) > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19698) camel-yaml-dsl: Express "simple" and "expression.simple" are mutually exclusive if possible
[ https://issues.apache.org/jira/browse/CAMEL-19698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750594#comment-17750594 ] Luca Burgazzoli commented on CAMEL-19698: - [~marat.gubaidul...@gmail.com] what happens when the tooling encounter an "inline" variant ? is it still able to render it properly and then when it is saved back it is re-written as full expression/type/expression ? > camel-yaml-dsl: Express "simple" and "expression.simple" are mutually > exclusive if possible > > > Key: CAMEL-19698 > URL: https://issues.apache.org/jira/browse/CAMEL-19698 > Project: Camel > Issue Type: Task > Components: camel-yaml-dsl >Reporter: Tomohisa Igarashi >Assignee: Luca Burgazzoli >Priority: Major > > For example currently YAML DSL allows specifying both "simple" and > "expression" under "when" > {code:yaml} > - from: > uri: "timer:test" > parameters: > period: 3000 > steps: > - when: > simple: "${header.baz} != null" > expression: > simple: "${header.baz} == null" > steps: > - log: "test" > {code} > But at runtime only latter wins in this case. It would be nice if this > exclusiveness could be expressed in the schema. > Similarly, this "anyOf" seems to allow specifying multiple expressions > https://github.com/apache/camel/blob/36bcd6277854b8e69ca91a8d51845a306b1c2136/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camel-yaml-dsl.json#L3567-L3569 > for example > {code:yaml} > - from: > uri: "timer:test" > parameters: > period: 3000 > steps: > - when: > simple: ${header.baz} != null > jq: ".foo" > steps: > - log: "test" > {code} > Although this ends up with a runtime error > {noformat} > 2023-08-02 14:27:29.445 INFO 1579388 --- [ main] > org.apache.camel.main.MainSupport : Using Java 20.0.1 with PID 1579388. > Started by tomo in /home/tomo/workspace/Kaoto/datamapper-research/examples > Field: jq has already been configured as an expression > in file:test.yaml, line 8, column 13: > jq: ".foo" > ^ > at > org.apache.camel.dsl.yaml.deserializers.ModelDeserializers$WhenDefinitionDeserializer.setProperty(ModelDeserializers.java:18445) > at > org.apache.camel.dsl.yaml.deserializers.ModelDeserializers$WhenDefinitionDeserializer.setProperty(ModelDeserializers.java:18385) > at > org.apache.camel.dsl.yaml.common.YamlDeserializerBase.setProperties(YamlDeserializerBase.java:125) > at > org.apache.camel.dsl.yaml.common.YamlDeserializerBase.construct(YamlDeserializerBase.java:65) > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19698) camel-yaml-dsl: Express "simple" and "expression.simple" are mutually exclusive if possible
[ https://issues.apache.org/jira/browse/CAMEL-19698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750450#comment-17750450 ] Luca Burgazzoli commented on CAMEL-19698: - yeah, expression with nested is the one that matches the model, the reason for the "inline" version was to make the syntax less boring and closed to the XML/Java one as example: {code:yaml} - setBody: simple: ${header.foo} {code} vs {code:yaml} - setBody: expression: simple: ${header.foo} {code} I guess we could think to do something different, like supporting both: {code:yaml} - setBody: simple: ${header.foo} {code} and {code:yaml} - setBody: simple: expression: ${header.foo} resultType: java.lang.String {code} This would allow to reduce or at least consolidate on a single way preserving the possibility to use inline but also to define additional properties. What do you think ? > camel-yaml-dsl: Express "simple" and "expression.simple" are mutually > exclusive if possible > > > Key: CAMEL-19698 > URL: https://issues.apache.org/jira/browse/CAMEL-19698 > Project: Camel > Issue Type: Task > Components: camel-yaml-dsl >Reporter: Tomohisa Igarashi >Assignee: Luca Burgazzoli >Priority: Major > > For example currently YAML DSL allows specifying both "simple" and > "expression" under "when" > {code:yaml} > - from: > uri: "timer:test" > parameters: > period: 3000 > steps: > - when: > simple: "${header.baz} != null" > expression: > simple: "${header.baz} == null" > steps: > - log: "test" > {code} > But at runtime only latter wins in this case. It would be nice if this > exclusiveness could be expressed in the schema. > Similarly, this "anyOf" seems to allow specifying multiple expressions > https://github.com/apache/camel/blob/36bcd6277854b8e69ca91a8d51845a306b1c2136/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camel-yaml-dsl.json#L3567-L3569 > for example > {code:yaml} > - from: > uri: "timer:test" > parameters: > period: 3000 > steps: > - when: > simple: ${header.baz} != null > jq: ".foo" > steps: > - log: "test" > {code} > Although this ends up with a runtime error > {noformat} > 2023-08-02 14:27:29.445 INFO 1579388 --- [ main] > org.apache.camel.main.MainSupport : Using Java 20.0.1 with PID 1579388. > Started by tomo in /home/tomo/workspace/Kaoto/datamapper-research/examples > Field: jq has already been configured as an expression > in file:test.yaml, line 8, column 13: > jq: ".foo" > ^ > at > org.apache.camel.dsl.yaml.deserializers.ModelDeserializers$WhenDefinitionDeserializer.setProperty(ModelDeserializers.java:18445) > at > org.apache.camel.dsl.yaml.deserializers.ModelDeserializers$WhenDefinitionDeserializer.setProperty(ModelDeserializers.java:18385) > at > org.apache.camel.dsl.yaml.common.YamlDeserializerBase.setProperties(YamlDeserializerBase.java:125) > at > org.apache.camel.dsl.yaml.common.YamlDeserializerBase.construct(YamlDeserializerBase.java:65) > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18177) camel-slack - Honour Retry-After when requests are rate-limited
[ https://issues.apache.org/jira/browse/CAMEL-18177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646562#comment-17646562 ] Luca Burgazzoli commented on CAMEL-18177: - /cc [~acosentino] > camel-slack - Honour Retry-After when requests are rate-limited > --- > > Key: CAMEL-18177 > URL: https://issues.apache.org/jira/browse/CAMEL-18177 > Project: Camel > Issue Type: Improvement > Components: camel-slack >Reporter: Luca Burgazzoli >Priority: Major > Fix For: 3.x > > > According to slack's doc: > {code} > If you exceed a rate limit when using any of our HTTP-based APIs (including > Incoming Webhooks), Slack will return a HTTP 429 Too Many Requests error, and > a Retry-After HTTP header containing the number of seconds until you can > retry. > {code} > We should explore if we can honor the Retry-After seconds to perform the > next poll. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18796) camel-kafka: kafka consumer stops in case of an authentication issue
[ https://issues.apache.org/jira/browse/CAMEL-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643571#comment-17643571 ] Luca Burgazzoli commented on CAMEL-18796: - I observed that another strange behavior happens if the pollOnError option is set to RECONNECT, as in such case, only a single reconnect attempt is performed then the consumer is essentially idle and no more reconnect attempt are made: {code:java} //usr/bin/env jbang "$0" "$@" ; exit $? // //DEPS io.quarkus.platform:quarkus-camel-bom:2.14.2.Final@pom //DEPS org.apache.camel.quarkus:camel-quarkus-kafka //DEPS org.apache.camel.quarkus:camel-quarkus-log //DEPS org.apache.camel.quarkus:camel-quarkus-direct //DEPS org.apache.camel.quarkus:camel-quarkus-microprofile-health // //JAVAC_OPTIONS -parameters //JAVA_OPTIONS -Djava.util.logging.manager=org.jboss.logmanager.LogManager // import org.apache.camel.ExtendedCamelContext; import org.apache.camel.builder.endpoint.EndpointRouteBuilder; public class ck extends EndpointRouteBuilder { @Override public void configure() throws Exception { var kafka = kafka("demo") .brokers("{{test.kafka.broker}}") .autoOffsetReset("earliest") .securityProtocol("SASL_SSL") .pollOnError("RECONNECT") .saslMechanism("PLAIN") .saslJaasConfig("org.apache.kafka.common.security.plain.PlainLoginModule required username='{{test.kafka.username}}' password='{{test.kafka.password}}';"); from(kafka) .to("log:kafka?showAll=true=true"); } } {code} As result is {code} 2022-12-05 22:50:44,012 INFO [org.apa.kaf.com.net.Selector] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) [Consumer clientId=consumer-e5368aa3-6d4f-4081-bd1e-bf58dca40a06-1, groupId=e5368aa3-6d4f-4081-bd1e-bf58dca40a06] Failed re-authentication with broker-0-lb-cos-ce---l--votu-gig.bf2.kafka.rhcloud.com/34.247.249.77 (channelId=2147483647) (Authentication failed: credentials for user could not be verified) 2022-12-05 22:50:44,014 ERROR [org.apa.kaf.cli.NetworkClient] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) [Consumer clientId=consumer-e5368aa3-6d4f-4081-bd1e-bf58dca40a06-1, groupId=e5368aa3-6d4f-4081-bd1e-bf58dca40a06] Connection to node 2147483647 (broker-0-lb-cos-ce---l--votu-gig.bf2.kafka.rhcloud.com/34.247.249.77:443) failed authentication due to: Authentication failed: credentials for user could not be verified 2022-12-05 22:50:44,017 WARN [org.apa.kaf.cli.con.int.ConsumerCoordinator] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) [Consumer clientId=consumer-e5368aa3-6d4f-4081-bd1e-bf58dca40a06-1, groupId=e5368aa3-6d4f-4081-bd1e-bf58dca40a06] Asynchronous auto-commit of offsets {demo-0=OffsetAndMetadata{offset=0, leaderEpoch=null, metadata=''}} failed: Authentication failed: credentials for user could not be verified 2022-12-05 22:50:44,016 ERROR [org.apa.kaf.cli.con.int.ConsumerCoordinator] (kafka-coordinator-heartbeat-thread | e5368aa3-6d4f-4081-bd1e-bf58dca40a06) [Consumer clientId=consumer-e5368aa3-6d4f-4081-bd1e-bf58dca40a06-1, groupId=e5368aa3-6d4f-4081-bd1e-bf58dca40a06] An authentication error occurred in the heartbeat thread: org.apache.kafka.common.errors.SaslAuthenticationException: Authentication failed: credentials for user could not be verified 2022-12-05 22:50:44,262 WARN [org.apa.cam.com.kaf.KafkaFetchRecords] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Exception org.apache.kafka.common.errors.SaslAuthenticationException caught by thread demo-Thread 0 while polling topic demo from kafka: Authentication failed: credentials for user could not be verified: org.apache.kafka.common.errors.SaslAuthenticationException: Authentication failed: credentials for user could not be verified 2022-12-05 22:50:44,262 WARN [org.apa.cam.com.kaf.con.err.ReconnectErrorStrategy] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Requesting the consumer to re-connect on the next run based on polling exception strategy 2022-12-05 22:50:44,263 DEBUG [org.apa.cam.com.kaf.KafkaFetchRecords] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Closing consumer demo-Thread 0 2022-12-05 22:50:44,263 DEBUG [org.apa.cam.com.kaf.con.sup.PartitionAssignmentListener] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) onPartitionsRevoked: demo-Thread 0 from demo 2022-12-05 22:50:45,953 INFO [org.apa.kaf.com.net.Selector] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) [Consumer clientId=consumer-e5368aa3-6d4f-4081-bd1e-bf58dca40a06-1, groupId=e5368aa3-6d4f-4081-bd1e-bf58dca40a06] Failed authentication with broker-0-lb-cos-ce---l--votu-gig.bf2.kafka.rhcloud.com/34.247.249.77 (channelId=2147483647) (Authentication failed: credentials for user could not be verified) 2022-12-05 22:50:45,954 ERROR [org.apa.kaf.cli.NetworkClient] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) [Consumer
[jira] [Comment Edited] (CAMEL-18796) camel-kafka: kafka consumer stops in case of an authentication issue
[ https://issues.apache.org/jira/browse/CAMEL-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643555#comment-17643555 ] Luca Burgazzoli edited comment on CAMEL-18796 at 12/5/22 9:11 PM: -- /cc [~orpiske] was (Author: lb): /cc @orpiske > camel-kafka: kafka consumer stops in case of an authentication issue > > > Key: CAMEL-18796 > URL: https://issues.apache.org/jira/browse/CAMEL-18796 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.0, 3.19.0 >Reporter: Luca Burgazzoli >Priority: Major > > I'm running in a strange behavior of the camle-kafka component in case of a > glitch/temporary authentication issue. Assuming we have the following code: > {code:java} > //usr/bin/env jbang "$0" "$@" ; exit $? > // > //DEPS io.quarkus.platform:quarkus-camel-bom:2.14.2.Final@pom > //DEPS org.apache.camel.quarkus:camel-quarkus-kafka > //DEPS org.apache.camel.quarkus:camel-quarkus-log > //DEPS org.apache.camel.quarkus:camel-quarkus-direct > // > //JAVAC_OPTIONS -parameters > //JAVA_OPTIONS -Djava.util.logging.manager=org.jboss.logmanager.LogManager > // > import org.apache.camel.ExtendedCamelContext; > import org.apache.camel.builder.endpoint.EndpointRouteBuilder; > public class ck extends EndpointRouteBuilder { > @Override > public void configure() throws Exception { > getCamelContext().adapt(ExtendedCamelContext.class) > .setErrorHandlerFactory( > deadLetterChannel("direct:dlq") > ); > var kafka = kafka("demo") > .brokers("{{test.kafka.broker}}") > .autoOffsetReset("earliest") > .securityProtocol("SASL_SSL") > .saslMechanism("PLAIN") > > .saslJaasConfig("org.apache.kafka.common.security.plain.PlainLoginModule > required username='{{test.kafka.username}}' > password='{{test.kafka.password}}';"); > from("direct:dlq") > .to("log:dlq?showAll=true=true"); > from(kafka) > .to("log:kafka?showAll=true=true"); > } > } > {code} > What this route is doing is: > 1. set-up a global error handler (send to a DLQ) > 2. poll data from a kafka topic > If for some reason there is a glitch in the authentication machinery, then > the KafkaConsumer thread is terminated and no more poll/reconnection attempt > are made. > {code} > 2022-12-05 21:52:48,728 DEBUG > [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted > on 0 records to process > 2022-12-05 21:52:53,729 DEBUG > [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted > on 0 records to process > 2022-12-05 21:52:58,730 DEBUG > [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted > on 0 records to process > 2022-12-05 21:53:03,731 DEBUG > [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted > on 0 records to process > 2022-12-05 21:53:08,732 DEBUG > [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted > on 0 records to process > 2022-12-05 21:53:09,598 INFO [org.apa.kaf.com.net.Selector] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) [Consumer > clientId=consumer-9fc21222-980b-4dd7-8e2b-0a228a4f3fe5-1, > groupId=9fc21222-980b-4dd7-8e2b-0a228a4f3fe5] Failed re-authentication with > broker-0-lb-cos-ce---l--votu-gig.bf2.kafka.rhcloud.com/34.247.249.77 > (channelId=2147483647) (Authentication failed: credentials for user could not > be verified) > 2022-12-05 21:53:09,602 ERROR [org.apa.kaf.cli.NetworkClient] (Camel > (camel-1) thread #1 - KafkaConsumer[demo]) [Consumer > clientId=consumer-9fc21222-980b-4dd7-8e2b-0a228a4f3fe5-1, > groupId=9fc21222-980b-4dd7-8e2b-0a228a4f3fe5] Connection to node 2147483647 > (broker-0-lb-cos-ce---l--votu-gig.bf2.kafka.rhcloud.com/34.247.249.77:443) > failed authentication due to: Authentication failed: credentials for user > could not be verified > 2022-12-05 21:53:09,605 WARN [org.apa.cam.com.kaf.KafkaFetchRecords] (Camel > (camel-1) thread #1 - KafkaConsumer[demo]) Exception > org.apache.kafka.common.errors.SaslAuthenticationException caught by thread > demo-Thread 0 while polling topic demo from kafka: Authentication failed: > credentials for user could not be verified: > org.apache.kafka.common.errors.SaslAuthenticationException: Authentication >
[jira] [Commented] (CAMEL-18796) camel-kafka: kafka consumer stops in case of an authentication issue
[ https://issues.apache.org/jira/browse/CAMEL-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643555#comment-17643555 ] Luca Burgazzoli commented on CAMEL-18796: - /cc @orpiske > camel-kafka: kafka consumer stops in case of an authentication issue > > > Key: CAMEL-18796 > URL: https://issues.apache.org/jira/browse/CAMEL-18796 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.0, 3.19.0 >Reporter: Luca Burgazzoli >Priority: Major > > I'm running in a strange behavior of the camle-kafka component in case of a > glitch/temporary authentication issue. Assuming we have the following code: > {code:java} > //usr/bin/env jbang "$0" "$@" ; exit $? > // > //DEPS io.quarkus.platform:quarkus-camel-bom:2.14.2.Final@pom > //DEPS org.apache.camel.quarkus:camel-quarkus-kafka > //DEPS org.apache.camel.quarkus:camel-quarkus-log > //DEPS org.apache.camel.quarkus:camel-quarkus-direct > // > //JAVAC_OPTIONS -parameters > //JAVA_OPTIONS -Djava.util.logging.manager=org.jboss.logmanager.LogManager > // > import org.apache.camel.ExtendedCamelContext; > import org.apache.camel.builder.endpoint.EndpointRouteBuilder; > public class ck extends EndpointRouteBuilder { > @Override > public void configure() throws Exception { > getCamelContext().adapt(ExtendedCamelContext.class) > .setErrorHandlerFactory( > deadLetterChannel("direct:dlq") > ); > var kafka = kafka("demo") > .brokers("{{test.kafka.broker}}") > .autoOffsetReset("earliest") > .securityProtocol("SASL_SSL") > .saslMechanism("PLAIN") > > .saslJaasConfig("org.apache.kafka.common.security.plain.PlainLoginModule > required username='{{test.kafka.username}}' > password='{{test.kafka.password}}';"); > from("direct:dlq") > .to("log:dlq?showAll=true=true"); > from(kafka) > .to("log:kafka?showAll=true=true"); > } > } > {code} > What this route is doing is: > 1. set-up a global error handler (send to a DLQ) > 2. poll data from a kafka topic > If for some reason there is a glitch in the authentication machinery, then > the KafkaConsumer thread is terminated and no more poll/reconnection attempt > are made. > {code} > 2022-12-05 21:52:48,728 DEBUG > [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted > on 0 records to process > 2022-12-05 21:52:53,729 DEBUG > [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted > on 0 records to process > 2022-12-05 21:52:58,730 DEBUG > [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted > on 0 records to process > 2022-12-05 21:53:03,731 DEBUG > [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted > on 0 records to process > 2022-12-05 21:53:08,732 DEBUG > [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted > on 0 records to process > 2022-12-05 21:53:09,598 INFO [org.apa.kaf.com.net.Selector] (Camel (camel-1) > thread #1 - KafkaConsumer[demo]) [Consumer > clientId=consumer-9fc21222-980b-4dd7-8e2b-0a228a4f3fe5-1, > groupId=9fc21222-980b-4dd7-8e2b-0a228a4f3fe5] Failed re-authentication with > broker-0-lb-cos-ce---l--votu-gig.bf2.kafka.rhcloud.com/34.247.249.77 > (channelId=2147483647) (Authentication failed: credentials for user could not > be verified) > 2022-12-05 21:53:09,602 ERROR [org.apa.kaf.cli.NetworkClient] (Camel > (camel-1) thread #1 - KafkaConsumer[demo]) [Consumer > clientId=consumer-9fc21222-980b-4dd7-8e2b-0a228a4f3fe5-1, > groupId=9fc21222-980b-4dd7-8e2b-0a228a4f3fe5] Connection to node 2147483647 > (broker-0-lb-cos-ce---l--votu-gig.bf2.kafka.rhcloud.com/34.247.249.77:443) > failed authentication due to: Authentication failed: credentials for user > could not be verified > 2022-12-05 21:53:09,605 WARN [org.apa.cam.com.kaf.KafkaFetchRecords] (Camel > (camel-1) thread #1 - KafkaConsumer[demo]) Exception > org.apache.kafka.common.errors.SaslAuthenticationException caught by thread > demo-Thread 0 while polling topic demo from kafka: Authentication failed: > credentials for user could not be verified: > org.apache.kafka.common.errors.SaslAuthenticationException: Authentication > failed: credentials for user could not be verified > 2022-12-05 21:53:09,609 WARN >
[jira] [Created] (CAMEL-18796) camel-kafka: kafka consumer stops in case of an authentication issue
Luca Burgazzoli created CAMEL-18796: --- Summary: camel-kafka: kafka consumer stops in case of an authentication issue Key: CAMEL-18796 URL: https://issues.apache.org/jira/browse/CAMEL-18796 Project: Camel Issue Type: Bug Components: camel-kafka Affects Versions: 3.19.0, 3.18.0 Reporter: Luca Burgazzoli I'm running in a strange behavior of the camle-kafka component in case of a glitch/temporary authentication issue. Assuming we have the following code: {code:java} //usr/bin/env jbang "$0" "$@" ; exit $? // //DEPS io.quarkus.platform:quarkus-camel-bom:2.14.2.Final@pom //DEPS org.apache.camel.quarkus:camel-quarkus-kafka //DEPS org.apache.camel.quarkus:camel-quarkus-log //DEPS org.apache.camel.quarkus:camel-quarkus-direct // //JAVAC_OPTIONS -parameters //JAVA_OPTIONS -Djava.util.logging.manager=org.jboss.logmanager.LogManager // import org.apache.camel.ExtendedCamelContext; import org.apache.camel.builder.endpoint.EndpointRouteBuilder; public class ck extends EndpointRouteBuilder { @Override public void configure() throws Exception { getCamelContext().adapt(ExtendedCamelContext.class) .setErrorHandlerFactory( deadLetterChannel("direct:dlq") ); var kafka = kafka("demo") .brokers("{{test.kafka.broker}}") .autoOffsetReset("earliest") .securityProtocol("SASL_SSL") .saslMechanism("PLAIN") .saslJaasConfig("org.apache.kafka.common.security.plain.PlainLoginModule required username='{{test.kafka.username}}' password='{{test.kafka.password}}';"); from("direct:dlq") .to("log:dlq?showAll=true=true"); from(kafka) .to("log:kafka?showAll=true=true"); } } {code} What this route is doing is: 1. set-up a global error handler (send to a DLQ) 2. poll data from a kafka topic If for some reason there is a glitch in the authentication machinery, then the KafkaConsumer thread is terminated and no more poll/reconnection attempt are made. {code} 2022-12-05 21:52:48,728 DEBUG [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted on 0 records to process 2022-12-05 21:52:53,729 DEBUG [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted on 0 records to process 2022-12-05 21:52:58,730 DEBUG [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted on 0 records to process 2022-12-05 21:53:03,731 DEBUG [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted on 0 records to process 2022-12-05 21:53:08,732 DEBUG [org.apa.cam.com.kaf.con.sup.KafkaRecordProcessorFacade] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Last poll on thread demo-Thread 0 resulted on 0 records to process 2022-12-05 21:53:09,598 INFO [org.apa.kaf.com.net.Selector] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) [Consumer clientId=consumer-9fc21222-980b-4dd7-8e2b-0a228a4f3fe5-1, groupId=9fc21222-980b-4dd7-8e2b-0a228a4f3fe5] Failed re-authentication with broker-0-lb-cos-ce---l--votu-gig.bf2.kafka.rhcloud.com/34.247.249.77 (channelId=2147483647) (Authentication failed: credentials for user could not be verified) 2022-12-05 21:53:09,602 ERROR [org.apa.kaf.cli.NetworkClient] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) [Consumer clientId=consumer-9fc21222-980b-4dd7-8e2b-0a228a4f3fe5-1, groupId=9fc21222-980b-4dd7-8e2b-0a228a4f3fe5] Connection to node 2147483647 (broker-0-lb-cos-ce---l--votu-gig.bf2.kafka.rhcloud.com/34.247.249.77:443) failed authentication due to: Authentication failed: credentials for user could not be verified 2022-12-05 21:53:09,605 WARN [org.apa.cam.com.kaf.KafkaFetchRecords] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Exception org.apache.kafka.common.errors.SaslAuthenticationException caught by thread demo-Thread 0 while polling topic demo from kafka: Authentication failed: credentials for user could not be verified: org.apache.kafka.common.errors.SaslAuthenticationException: Authentication failed: credentials for user could not be verified 2022-12-05 21:53:09,609 WARN [org.apa.cam.com.kaf.con.err.BridgeErrorStrategy] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Deferring processing to the exception handler based on polling exception strategy 2022-12-05 21:53:09,624 DEBUG [org.apa.cam.pro.err.DeadLetterChannel] (Camel (camel-1) thread #1 - KafkaConsumer[demo]) Failed delivery for (MessageId: 386B9AF6D607152- on ExchangeId: 386B9AF6D607152-). On delivery
[jira] [Work started] (CAMEL-18663) camel-vertx-http: allow to configure WebClientOptions at component level
[ https://issues.apache.org/jira/browse/CAMEL-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-18663 started by Luca Burgazzoli. --- > camel-vertx-http: allow to configure WebClientOptions at component level > > > Key: CAMEL-18663 > URL: https://issues.apache.org/jira/browse/CAMEL-18663 > Project: Camel > Issue Type: Improvement > Components: camel-vertx-http >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 3.20.0 > > > As today, the VertxHttpComponent exposes a number of configuration options > but lacks the options to set WebClientOptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-18663) camel-vertx-http: allow to configure WebClientOptions at component level
[ https://issues.apache.org/jira/browse/CAMEL-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-18663: --- Assignee: Luca Burgazzoli > camel-vertx-http: allow to configure WebClientOptions at component level > > > Key: CAMEL-18663 > URL: https://issues.apache.org/jira/browse/CAMEL-18663 > Project: Camel > Issue Type: Improvement > Components: camel-vertx-http >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 3.20.0 > > > As today, the VertxHttpComponent exposes a number of configuration options > but lacks the options to set WebClientOptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18665) JsseParameters should use the camel provided resource loader instead of its own
[ https://issues.apache.org/jira/browse/CAMEL-18665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-18665: Summary: JsseParameters should use the camel provided resource loader instead of its own (was: JsseParameters should use the camel provided resource loader instead of its own way) > JsseParameters should use the camel provided resource loader instead of its > own > --- > > Key: CAMEL-18665 > URL: https://issues.apache.org/jira/browse/CAMEL-18665 > Project: Camel > Issue Type: Improvement > Components: camel-core, camel-core-api >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 3.20.0 > > > the JsseParameters should use camel's resource loader mechanism to load > resources instead of its own one (see JsseParameters.resolveResource) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18666) rest openapi: allow to set the compoennt instance instead of just the name
Luca Burgazzoli created CAMEL-18666: --- Summary: rest openapi: allow to set the compoennt instance instead of just the name Key: CAMEL-18666 URL: https://issues.apache.org/jira/browse/CAMEL-18666 Project: Camel Issue Type: Improvement Components: camel-rest-openapi Reporter: Luca Burgazzoli As today, the camel-rest-openapi supports to configure the name of the http component to use but it does not allow to configure it. A workaround to configure it is to use the rest configuration but that's complicated things. To make things easy it should be possible to directly bind an http component instance to the amel-rest-openapi. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18665) JsseParameters should use the camel provided resource loader instead of its own way
[ https://issues.apache.org/jira/browse/CAMEL-18665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-18665: Description: the JsseParameters should use camel's resource loader mechanism to load resources instead of its own one (see JsseParameters.resolveResource) (was: the JsseParameters should use camle's resource loader mechanism to load resources instead of its own one (see JsseParameters.resolveResource)) > JsseParameters should use the camel provided resource loader instead of its > own way > --- > > Key: CAMEL-18665 > URL: https://issues.apache.org/jira/browse/CAMEL-18665 > Project: Camel > Issue Type: Improvement > Components: camel-core, camel-core-api >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 3.20.0 > > > the JsseParameters should use camel's resource loader mechanism to load > resources instead of its own one (see JsseParameters.resolveResource) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18665) JsseParameters should use the camel provided resource loader instead of its own way
Luca Burgazzoli created CAMEL-18665: --- Summary: JsseParameters should use the camel provided resource loader instead of its own way Key: CAMEL-18665 URL: https://issues.apache.org/jira/browse/CAMEL-18665 Project: Camel Issue Type: Improvement Components: camel-core, camel-core-api Reporter: Luca Burgazzoli Fix For: 3.20.0 the JsseParameters should use camle's resource loader mechanism to load resources instead of its own one (see JsseParameters.resolveResource) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18663) camel-vertx-http: allow to configure WebClientOptions at component level
Luca Burgazzoli created CAMEL-18663: --- Summary: camel-vertx-http: allow to configure WebClientOptions at component level Key: CAMEL-18663 URL: https://issues.apache.org/jira/browse/CAMEL-18663 Project: Camel Issue Type: Improvement Components: camel-vertx-http Reporter: Luca Burgazzoli Fix For: 3.20.0 As today, the VertxHttpComponent exposes a number of configuration options but lacks the options to set WebClientOptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18654) azure components: allow to override the client endpojnt
Luca Burgazzoli created CAMEL-18654: --- Summary: azure components: allow to override the client endpojnt Key: CAMEL-18654 URL: https://issues.apache.org/jira/browse/CAMEL-18654 Project: Camel Issue Type: Improvement Components: camel-azure Reporter: Luca Burgazzoli In order to test the azure components against i.e. azurite, it would be nice if the azure components would provide a way to to override the service endpoint used by the clients at the component and endpoint level. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18617) Some health checks are hidden when running withg supervised controller enabled
[ https://issues.apache.org/jira/browse/CAMEL-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-18617. - Resolution: Fixed > Some health checks are hidden when running withg supervised controller enabled > -- > > Key: CAMEL-18617 > URL: https://issues.apache.org/jira/browse/CAMEL-18617 > Project: Camel > Issue Type: Bug > Components: camel-health, camel-microprofile-health >Affects Versions: 3.18.2, 3.19.0 >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 3.20.0 > > > As follow up of https://issues.apache.org/jira/browse/CAMEL-18483, when > enabling the supervise route controller, some heath checks are not included. > With the supervisor disabled, we can see a camel-kafka check: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "name": "camel-kafka", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} > However with the supervisor enabled, the camel-kafka check is not reported: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-18617) Some health checks are hidden when running withg supervised controller enabled
[ https://issues.apache.org/jira/browse/CAMEL-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-18617: --- Assignee: Luca Burgazzoli > Some health checks are hidden when running withg supervised controller enabled > -- > > Key: CAMEL-18617 > URL: https://issues.apache.org/jira/browse/CAMEL-18617 > Project: Camel > Issue Type: Bug > Components: camel-health, camel-microprofile-health >Affects Versions: 3.18.2, 3.19.0 >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 3.20.0 > > > As follow up of https://issues.apache.org/jira/browse/CAMEL-18483, when > enabling the supervise route controller, some heath checks are not included. > With the supervisor disabled, we can see a camel-kafka check: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "name": "camel-kafka", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} > However with the supervisor enabled, the camel-kafka check is not reported: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-18617) Some health checks are hidden when running withg supervised controller enabled
[ https://issues.apache.org/jira/browse/CAMEL-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-18617 started by Luca Burgazzoli. --- > Some health checks are hidden when running withg supervised controller enabled > -- > > Key: CAMEL-18617 > URL: https://issues.apache.org/jira/browse/CAMEL-18617 > Project: Camel > Issue Type: Bug > Components: camel-health, camel-microprofile-health >Affects Versions: 3.18.2, 3.19.0 >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 3.20.0 > > > As follow up of https://issues.apache.org/jira/browse/CAMEL-18483, when > enabling the supervise route controller, some heath checks are not included. > With the supervisor disabled, we can see a camel-kafka check: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "name": "camel-kafka", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} > However with the supervisor enabled, the camel-kafka check is not reported: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18617) Some health checks are hidden when running withg supervised controller enabled
[ https://issues.apache.org/jira/browse/CAMEL-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620869#comment-17620869 ] Luca Burgazzoli commented on CAMEL-18617: - [~davsclaus] I can try to have a look, would be a ComponentHealthCheckRepositoy be the right name ? > Some health checks are hidden when running withg supervised controller enabled > -- > > Key: CAMEL-18617 > URL: https://issues.apache.org/jira/browse/CAMEL-18617 > Project: Camel > Issue Type: Bug > Components: camel-health, camel-microprofile-health >Affects Versions: 3.18.2, 3.19.0 >Reporter: Luca Burgazzoli >Priority: Major > Fix For: 3.20.0 > > > As follow up of https://issues.apache.org/jira/browse/CAMEL-18483, when > enabling the supervise route controller, some heath checks are not included. > With the supervisor disabled, we can see a camel-kafka check: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "name": "camel-kafka", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} > However with the supervisor enabled, the camel-kafka check is not reported: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18617) Some health checks are hidden when running withg supervised controller enabled
[ https://issues.apache.org/jira/browse/CAMEL-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-18617: Summary: Some health checks are hidden when running withg supervised controller enabled (was: Some health checks are hidden when running wiuthg supervised controller enabled) > Some health checks are hidden when running withg supervised controller enabled > -- > > Key: CAMEL-18617 > URL: https://issues.apache.org/jira/browse/CAMEL-18617 > Project: Camel > Issue Type: Bug > Components: camel-health, camel-microprofile-health >Affects Versions: 3.18.2, 3.19.0 >Reporter: Luca Burgazzoli >Priority: Major > > As follow up of https://issues.apache.org/jira/browse/CAMEL-18483, when > enabling the supervise route controller, some heath checks are not included. > With the supervisor disabled, we can see a camel-kafka check: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "name": "camel-kafka", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} > However with the supervisor enabled, the camel-kafka check is not reported: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18617) Some health checks are hidden when running wiuthg supervised controller enabled
[ https://issues.apache.org/jira/browse/CAMEL-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619494#comment-17619494 ] Luca Burgazzoli commented on CAMEL-18617: - /cc [~jamesnetherton] > Some health checks are hidden when running wiuthg supervised controller > enabled > --- > > Key: CAMEL-18617 > URL: https://issues.apache.org/jira/browse/CAMEL-18617 > Project: Camel > Issue Type: Bug > Components: camel-health, camel-microprofile-health >Affects Versions: 3.18.2, 3.19.0 >Reporter: Luca Burgazzoli >Priority: Major > > As follow up of https://issues.apache.org/jira/browse/CAMEL-18483, when > enabling the supervise route controller, some heath checks are not included. > With the supervisor disabled, we can see a camel-kafka check: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "name": "camel-kafka", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} > However with the supervisor enabled, the camel-kafka check is not reported: > {code:json} > { > "checks": [ > { > "name": "camel-routes", > "status": "UP" > }, > { > "data": { > "check.kind": "READINESS", > "context.name": "camel-q", > "context.status": "Started", > "context.version": "3.18.3-SNAPSHOT" > }, > "name": "context", > "status": "UP" > }, > { > "name": "camel-consumers", > "status": "UP" > } > ], > "status": "UP" > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18617) Some health checks are hidden when running wiuthg supervised controller enabled
Luca Burgazzoli created CAMEL-18617: --- Summary: Some health checks are hidden when running wiuthg supervised controller enabled Key: CAMEL-18617 URL: https://issues.apache.org/jira/browse/CAMEL-18617 Project: Camel Issue Type: Bug Components: camel-health, camel-microprofile-health Affects Versions: 3.19.0, 3.18.2 Reporter: Luca Burgazzoli As follow up of https://issues.apache.org/jira/browse/CAMEL-18483, when enabling the supervise route controller, some heath checks are not included. With the supervisor disabled, we can see a camel-kafka check: {code:json} { "checks": [ { "name": "camel-routes", "status": "UP" }, { "name": "camel-kafka", "status": "UP" }, { "data": { "check.kind": "READINESS", "context.name": "camel-q", "context.status": "Started", "context.version": "3.18.3-SNAPSHOT" }, "name": "context", "status": "UP" }, { "name": "camel-consumers", "status": "UP" } ], "status": "UP" } {code} However with the supervisor enabled, the camel-kafka check is not reported: {code:json} { "checks": [ { "name": "camel-routes", "status": "UP" }, { "data": { "check.kind": "READINESS", "context.name": "camel-q", "context.status": "Started", "context.version": "3.18.3-SNAPSHOT" }, "name": "context", "status": "UP" }, { "name": "camel-consumers", "status": "UP" } ], "status": "UP" } {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18592) Re-think header naming
Luca Burgazzoli created CAMEL-18592: --- Summary: Re-think header naming Key: CAMEL-18592 URL: https://issues.apache.org/jira/browse/CAMEL-18592 Project: Camel Issue Type: Improvement Reporter: Luca Burgazzoli Fix For: Future As today, there is no naming convention for headers so each component is free to define them, as a result we have as example: - CamelAwsS3BucketName - kafka.TOPIC Naming is also relevant for the header filter strategy that usually remove any header that has Camel as a prefix. We should probably define some better rules like: - headers starting with camel.* are used to carry any camel specific attribute - headers starting with the scheme of the component, ${scheme}.*, are meant to carry any system specific attribute - metadata required for additional internal processing logic should be set as exchange properties (https://issues.apache.org/jira/browse/CAMEL-18591) given the two header above, they would be translated into something like: {code} headers: aws-s3.bucket.name kafka.topic properties: camel.aws-s3.bucket.name {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18591) Store processing related metadata to properties instead of headers
[ https://issues.apache.org/jira/browse/CAMEL-18591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-18591: Priority: Minor (was: Major) > Store processing related metadata to properties instead of headers > -- > > Key: CAMEL-18591 > URL: https://issues.apache.org/jira/browse/CAMEL-18591 > Project: Camel > Issue Type: Improvement >Reporter: Luca Burgazzoli >Priority: Minor > > Some components rely on header values to react to exchange completion, as > example the AWS S3 component, uses the bucked name and key to delete or move > buckets on completion [1]. > As headers are often manipulated by users and may affect other downstream > processing logic, it would be better to move such information to the exchange > properties. > For backward compatibility we could add a double lookup like: > {code:java} > var name = exchange.getProperty(AWS2S3Constants.BUCKET_NAME, String.class); > if (name == null) { > name = exchange.getMessage().getHeader(AWS2S3Constants.BUCKET_NAME, > String.class); > } > {code} > [1] > https://github.com/apache/camel/blob/2263301d9701d4ddfe306ea52aa05deffdd7b0b9/components/camel-aws/camel-aws2-s3/src/main/java/org/apache/camel/component/aws2/s3/AWS2S3Consumer.java#L314-L315 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18591) Store processing related metadata to properties instead of headers
[ https://issues.apache.org/jira/browse/CAMEL-18591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-18591: Fix Version/s: 3.x > Store processing related metadata to properties instead of headers > -- > > Key: CAMEL-18591 > URL: https://issues.apache.org/jira/browse/CAMEL-18591 > Project: Camel > Issue Type: Improvement >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 3.x > > > Some components rely on header values to react to exchange completion, as > example the AWS S3 component, uses the bucked name and key to delete or move > buckets on completion [1]. > As headers are often manipulated by users and may affect other downstream > processing logic, it would be better to move such information to the exchange > properties. > For backward compatibility we could add a double lookup like: > {code:java} > var name = exchange.getProperty(AWS2S3Constants.BUCKET_NAME, String.class); > if (name == null) { > name = exchange.getMessage().getHeader(AWS2S3Constants.BUCKET_NAME, > String.class); > } > {code} > [1] > https://github.com/apache/camel/blob/2263301d9701d4ddfe306ea52aa05deffdd7b0b9/components/camel-aws/camel-aws2-s3/src/main/java/org/apache/camel/component/aws2/s3/AWS2S3Consumer.java#L314-L315 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18591) Store processing related metadata to properties instead of headers
Luca Burgazzoli created CAMEL-18591: --- Summary: Store processing related metadata to properties instead of headers Key: CAMEL-18591 URL: https://issues.apache.org/jira/browse/CAMEL-18591 Project: Camel Issue Type: Improvement Reporter: Luca Burgazzoli Some components rely on header values to react to exchange completion, as example the AWS S3 component, uses the bucked name and key to delete or move buckets on completion [1]. As headers are often manipulated by users and may affect other downstream processing logic, it would be better to move such information to the exchange properties. For backward compatibility we could add a double lookup like: {code:java} var name = exchange.getProperty(AWS2S3Constants.BUCKET_NAME, String.class); if (name == null) { name = exchange.getMessage().getHeader(AWS2S3Constants.BUCKET_NAME, String.class); } {code} [1] https://github.com/apache/camel/blob/2263301d9701d4ddfe306ea52aa05deffdd7b0b9/components/camel-aws/camel-aws2-s3/src/main/java/org/apache/camel/component/aws2/s3/AWS2S3Consumer.java#L314-L315 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18477) knative producer with ProducerTemplate is missing the fromRouteId
[ https://issues.apache.org/jira/browse/CAMEL-18477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601317#comment-17601317 ] Luca Burgazzoli commented on CAMEL-18477: - I'd say that it works as designed as the component tries to se some sensible defaults but some of the attributes are expected to be set the the user. This is particularly true for source and event type as those are business attributes an we cannot reliably compute/derive them. The idea is that if you need to customize any attribute, then a user should set one of the CamelCloudEvent* header so with the ProducerTemplate tou should use sendBodyWithHeader or similar methods > knative producer with ProducerTemplate is missing the fromRouteId > - > > Key: CAMEL-18477 > URL: https://issues.apache.org/jira/browse/CAMEL-18477 > Project: Camel > Issue Type: Bug > Components: camel-knative >Affects Versions: 3.18.1 >Reporter: Zineb Bendhiba >Assignee: Zineb Bendhiba >Priority: Major > Fix For: 3.18.3, 3.19.0 > > > Knative camel producer creates CloudEvents. To have a valid CloudEvent, > there's the need to have a field named `source`. > The knative camel producer sets this value by putting the "fromRouteId" > value. This value is set by DefaultConsumer when creating the extended > exchange. > However, when using the knative producer via ProducerTemplate, we miss this > value. And the event is rejected because source is required by knative. > Log : > {code:java} > {"level":"warn","ts":"2022-09-07T10:28:15.844Z","logger":"mt_broker_ingress","caller":"ingress/ingress_handler.go:145","msg":"failed > to validate extracted event","error":"source: REQUIRED\n"} {code} > As a temporary fix, we could ask user to override the source value, as in > this configuration example : > {code:java} > { > "type": "event", > "name": "YOUR_NAME_EVENT", > "url": "YOUR_LINK_TO_BROKER", > "metadata": { > "camel.endpoint.kind": "sink" > }, > "ceOverrides": { > "ce-source": "YOUR_SOURCE_NAME" > } > } {code} > However, it doesn't seem right to suppose in the code this value is coming > necessarly from a Camel Consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-17719) camel-salesforce: allow to retrieve CDC json schema from meta service
[ https://issues.apache.org/jira/browse/CAMEL-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597072#comment-17597072 ] Luca Burgazzoli commented on CAMEL-17719: - [~jeremyross] sorry for the very long delay, the oneOf solution seems very good > camel-salesforce: allow to retrieve CDC json schema from meta service > - > > Key: CAMEL-17719 > URL: https://issues.apache.org/jira/browse/CAMEL-17719 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Luca Burgazzoli >Assignee: Jeremy Ross >Priority: Minor > > To get the full schema of a change event message, it it possible to make a > GET request to the REST API that includes the schema ID sent in the event > message, as example: > {code} > /vXX.X/event/eventSchema/ > {code} > or by using the event name: > {code} > /vXX.X/sobjects//eventSchema > {code} > It would be nice if the meta data extension would be able to return the json > schema of the -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18436) camel-core - Avoid using java.net.URI for endpoint parsing
[ https://issues.apache.org/jira/browse/CAMEL-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597071#comment-17597071 ] Luca Burgazzoli commented on CAMEL-18436: - This and https://issues.apache.org/jira/browse/CAMEL-16221 would be a very good addition (IMHO) > camel-core - Avoid using java.net.URI for endpoint parsing > -- > > Key: CAMEL-18436 > URL: https://issues.apache.org/jira/browse/CAMEL-18436 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0 > > > The java.net.URI have historically been used for camel endpoint uri parsing > because of lack of own parser. But the java.net.URI has some drawbacks as it > enforces the toString representation to alter the text to use safe uri > charachters and percentage encoding such as %20 as space and %25 as > percentage sign. > So we had to come up with RAW(xxx) to avoid parsing specific parts of the > endpoint uri, as a kinda workaround. > We should flip the table, and keep the uri as-is, and then for specific > components that need to use java.net.URI style (eg HTTP based) then these > components will internally transform to java.net.URI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16221) Rethink endpoints URI usage for camel internals
[ https://issues.apache.org/jira/browse/CAMEL-16221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-16221: Fix Version/s: 4.0 (was: 3.x) > Rethink endpoints URI usage for camel internals > --- > > Key: CAMEL-16221 > URL: https://issues.apache.org/jira/browse/CAMEL-16221 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Luca Burgazzoli >Priority: Major > Fix For: 4.0 > > > As today URIs are the primary mechanism Camel uses internally to describe > endpoints but I think it is time to re-consider the dependency on URIs for > camel internals and leave the URIs as an external representation of endpoints > As example: > - the Endpoint DSL is required to generate the related endpoint URI to > leverage Camel's APIs but to create an endpoint, the schema and a map of > options, would be more than enough. > - components that wrap other components, such as kamelets, master & co may > need to re-create URIs to create instances of the delegated endpoints which > is cumbersome as there's lot of options to take into account (RAW, > url-encoding, placeholders) > - the YAML DSL and camel-kafka-connectors are using and Endpoint DSL alike > syntax where a user can define endpoints by scheme + option pairs without the > need of writing URIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18374) camel-core - Route template should be able to specify stream-caching option
[ https://issues.apache.org/jira/browse/CAMEL-18374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577847#comment-17577847 ] Luca Burgazzoli commented on CAMEL-18374: - Add support for setting the ExchangePattern {code:java} .setExchangePattern(ExchangePattern.InOnly) {code} > camel-core - Route template should be able to specify stream-caching option > --- > > Key: CAMEL-18374 > URL: https://issues.apache.org/jira/browse/CAMEL-18374 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 3.18.0 >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.18.2, 3.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18370) Bidning properties to route template local beans do not honor RAW()
Luca Burgazzoli created CAMEL-18370: --- Summary: Bidning properties to route template local beans do not honor RAW() Key: CAMEL-18370 URL: https://issues.apache.org/jira/browse/CAMEL-18370 Project: Camel Issue Type: Improvement Components: camel-core, camel-kamelet Reporter: Luca Burgazzoli Assuming we have a kamelet where the route template is defined as: {code:yaml} template: beans: - name: local-salesforce type: "#class:org.apache.camel.component.salesforce.SalesforceComponent" properties: clientId: "{{clientId}}" clientSecret: "{{clientSecret}}" userName: "{{userName}}" password: "{{password}}" loginUrl: "{{loginUrl}}" from: uri: kamelet:source steps: - to: uri: "{{local-salesforce}}:createSObject" parameters: sObjectName: "{{sObjectName}}" rawPayload: "true" format: "JSON" {code} Where we define the _userName_ as something like _foo+bar@acme.com_. With such parameter, the login would fail as the parameter would become _foo bar@acme.com_ in the component (as the parameter is taken from the kamelet uri hence, it gets decoded). An attempt to fix that is to use RAW, as example _userName: "RAW{{userName}}"_ but this also would fail the login as the parameter would become _RAW(foo b...@acme.com)_ in the component. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18208) vault: allow to retrieve a specific secret version/revision
Luca Burgazzoli created CAMEL-18208: --- Summary: vault: allow to retrieve a specific secret version/revision Key: CAMEL-18208 URL: https://issues.apache.org/jira/browse/CAMEL-18208 Project: Camel Issue Type: Improvement Reporter: Luca Burgazzoli The vaults for which we have support in Apache Camel support versioned secrets (i.e. [1][2]) and it would be very useful to have an option to include the verison/revision of the secret in the vault property syntax, as example: {{aws:username@123}} This would mean to get the secret named username and version 123 from the aws vault. [1] https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html [2] https://learn.hashicorp.com/tutorials/vault/versioned-kv#step-7-configure-automatic-data-deletion -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (CAMEL-18208) vault: allow to retrieve a specific secret version/revision
[ https://issues.apache.org/jira/browse/CAMEL-18208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-18208: --- Assignee: Andrea Cosentino > vault: allow to retrieve a specific secret version/revision > --- > > Key: CAMEL-18208 > URL: https://issues.apache.org/jira/browse/CAMEL-18208 > Project: Camel > Issue Type: Improvement >Reporter: Luca Burgazzoli >Assignee: Andrea Cosentino >Priority: Minor > > The vaults for which we have support in Apache Camel support versioned > secrets (i.e. [1][2]) and it would be very useful to have an option to > include the verison/revision of the secret in the vault property syntax, as > example: > {{aws:username@123}} > This would mean to get the secret named username and version 123 from the > aws vault. > [1] > https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html > [2] > https://learn.hashicorp.com/tutorials/vault/versioned-kv#step-7-configure-automatic-data-deletion -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CAMEL-18187) slack: inconsistent message payload when batch ends
[ https://issues.apache.org/jira/browse/CAMEL-18187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553058#comment-17553058 ] Luca Burgazzoli commented on CAMEL-18187: - It seems to be related to exchange pooling as if *camel.main.exchange-factory* is set to *prototype*, then the problem disappear. > slack: inconsistent message payload when batch ends > --- > > Key: CAMEL-18187 > URL: https://issues.apache.org/jira/browse/CAMEL-18187 > Project: Camel > Issue Type: Bug > Components: camel-slack >Reporter: Luca Burgazzoli >Priority: Major > > When polling multiple events from slack, there is an inconsistent of the > payload generated for the exchange that complete the batch: > - This is an exchange part of the batch (CamelBatchComplete=false) and as it > can be observed, the bodyType is com.slack.api.model.Message > {code} > 10:47:28.470 INFO [raw] (Camel (camel-1) thread #1 - slack://demo) Exchange[ > Id: B2F6BECBBE1B6C2-0001 > ExchangePattern: InOnly > Properties: > {camel.route.route1.B2F6BECBBE1B6C2-0001=io.smallrye.metrics.app.TimerImpl$Context@1bcda3c3, > CamelBatchComplete=false, CamelBatchIndex=0, CamelBatchSize=2, > CamelToEndpoint=log://raw?multiline=true=true, > eventTimer:camel.exchange=io.smallrye.metrics.app.TimerImpl@7d791b4c, > eventTimerContext:camel.exchange=io.smallrye.metrics.app.TimerImpl$Context@53f8d078} > Headers: {} > BodyType: com.slack.api.model.Message > Body: Message(...) > ] > {code} > - This is the exchange that closes the batch (CamelBatchComplete=true) and as > it can be observed, the bodyType is byte[]: > {code} > 10:47:28.477 INFO [raw] (Camel (camel-1) thread #1 - slack://demo) Exchange[ > Id: B2F6BECBBE1B6C2-0001 > ExchangePattern: InOnly > Properties: > {camel.route.route1.B2F6BECBBE1B6C2-0001=io.smallrye.metrics.app.TimerImpl$Context@328e8fdf, > CamelBatchComplete=true, CamelBatchIndex=1, CamelBatchSize=2, > CamelToEndpoint=log://raw?multiline=true=true, > eventTimer:camel.exchange=io.smallrye.metrics.app.TimerImpl@7d791b4c, > eventTimerContext:camel.exchange=io.smallrye.metrics.app.TimerImpl$Context@53f8d078} > Headers: {Content-Type=application/json, > org.apache.kafka.clients.producer.RecordMetadata=[]} > BodyType: byte[] > Body: {"type":"message","subtype":"bot_message", ... } > ] > {code} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18187) slack: inconsistent message payload when batch ends
Luca Burgazzoli created CAMEL-18187: --- Summary: slack: inconsistent message payload when batch ends Key: CAMEL-18187 URL: https://issues.apache.org/jira/browse/CAMEL-18187 Project: Camel Issue Type: Bug Components: camel-slack Reporter: Luca Burgazzoli When polling multiple events from slack, there is an inconsistent of the payload generated for the exchange that complete the batch: - This is an exchange part of the batch (CamelBatchComplete=false) and as it can be observed, the bodyType is com.slack.api.model.Message {code} 10:47:28.470 INFO [raw] (Camel (camel-1) thread #1 - slack://demo) Exchange[ Id: B2F6BECBBE1B6C2-0001 ExchangePattern: InOnly Properties: {camel.route.route1.B2F6BECBBE1B6C2-0001=io.smallrye.metrics.app.TimerImpl$Context@1bcda3c3, CamelBatchComplete=false, CamelBatchIndex=0, CamelBatchSize=2, CamelToEndpoint=log://raw?multiline=true=true, eventTimer:camel.exchange=io.smallrye.metrics.app.TimerImpl@7d791b4c, eventTimerContext:camel.exchange=io.smallrye.metrics.app.TimerImpl$Context@53f8d078} Headers: {} BodyType: com.slack.api.model.Message Body: Message(...) ] {code} - This is the exchange that closes the batch (CamelBatchComplete=true) and as it can be observed, the bodyType is byte[]: {code} 10:47:28.477 INFO [raw] (Camel (camel-1) thread #1 - slack://demo) Exchange[ Id: B2F6BECBBE1B6C2-0001 ExchangePattern: InOnly Properties: {camel.route.route1.B2F6BECBBE1B6C2-0001=io.smallrye.metrics.app.TimerImpl$Context@328e8fdf, CamelBatchComplete=true, CamelBatchIndex=1, CamelBatchSize=2, CamelToEndpoint=log://raw?multiline=true=true, eventTimer:camel.exchange=io.smallrye.metrics.app.TimerImpl@7d791b4c, eventTimerContext:camel.exchange=io.smallrye.metrics.app.TimerImpl$Context@53f8d078} Headers: {Content-Type=application/json, org.apache.kafka.clients.producer.RecordMetadata=[]} BodyType: byte[] Body: {"type":"message","subtype":"bot_message", ... } ] {code} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CAMEL-18185) slack: npe when processing batch messages
[ https://issues.apache.org/jira/browse/CAMEL-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553052#comment-17553052 ] Luca Burgazzoli commented on CAMEL-18185: - I'm trying to create one but I was unable so far > slack: npe when processing batch messages > - > > Key: CAMEL-18185 > URL: https://issues.apache.org/jira/browse/CAMEL-18185 > Project: Camel > Issue Type: Bug > Components: camel-core, camel-slack >Reporter: Luca Burgazzoli >Priority: Major > > Running a camel component to read from slack lead to the following error: > {code} > Exchange[854F138824ACA43-0003]. Caused by: > [org.apache.camel.NoTypeConversionAvailableException - No type converter > available to convert from type: null to the required type: > java.io.InputStream with value null] > at > org.apache.camel.support.MessageSupport.getMandatoryBody(MessageSupport.java:125) > at > org.apache.camel.support.processor.UnmarshalProcessor.process(UnmarshalProcessor.java:58) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:812) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:720) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:193) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:64) > at org.apache.camel.processor.Pipeline.process(Pipeline.java:184) > at > org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:398) > at > org.apache.camel.component.slack.SlackConsumer.processBatch(SlackConsumer.java:133) > at > org.apache.camel.component.slack.SlackConsumer.poll(SlackConsumer.java:87) > at > org.apache.camel.support.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:202) > at > org.apache.camel.support.ScheduledPollConsumer.run(ScheduledPollConsumer.java:116) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at > java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:829) > Caused by: org.apache.camel.NoTypeConversionAvailableException: No type > converter available to convert from type: null to the required type: > java.io.InputStream with value null > at > org.apache.camel.impl.converter.CoreTypeConverterRegistry.mandatoryConvertTo(CoreTypeConverterRegistry.java:275) > at > org.apache.camel.support.MessageSupport.getMandatoryBody(MessageSupport.java:123) > ... 17 more > {code} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18185) slack: npe when processing batch messages
Luca Burgazzoli created CAMEL-18185: --- Summary: slack: npe when processing batch messages Key: CAMEL-18185 URL: https://issues.apache.org/jira/browse/CAMEL-18185 Project: Camel Issue Type: Bug Components: camel-core, camel-slack Reporter: Luca Burgazzoli Running a camel component to read from slack lead to the following error: {code} Exchange[854F138824ACA43-0003]. Caused by: [org.apache.camel.NoTypeConversionAvailableException - No type converter available to convert from type: null to the required type: java.io.InputStream with value null] at org.apache.camel.support.MessageSupport.getMandatoryBody(MessageSupport.java:125) at org.apache.camel.support.processor.UnmarshalProcessor.process(UnmarshalProcessor.java:58) at org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:812) at org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:720) at org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:193) at org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:64) at org.apache.camel.processor.Pipeline.process(Pipeline.java:184) at org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:398) at org.apache.camel.component.slack.SlackConsumer.processBatch(SlackConsumer.java:133) at org.apache.camel.component.slack.SlackConsumer.poll(SlackConsumer.java:87) at org.apache.camel.support.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:202) at org.apache.camel.support.ScheduledPollConsumer.run(ScheduledPollConsumer.java:116) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: org.apache.camel.NoTypeConversionAvailableException: No type converter available to convert from type: null to the required type: java.io.InputStream with value null at org.apache.camel.impl.converter.CoreTypeConverterRegistry.mandatoryConvertTo(CoreTypeConverterRegistry.java:275) at org.apache.camel.support.MessageSupport.getMandatoryBody(MessageSupport.java:123) ... 17 more {code} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18177) slack: honor Retry-After when requests are reate-limited
Luca Burgazzoli created CAMEL-18177: --- Summary: slack: honor Retry-After when requests are reate-limited Key: CAMEL-18177 URL: https://issues.apache.org/jira/browse/CAMEL-18177 Project: Camel Issue Type: Improvement Components: camel-slack Reporter: Luca Burgazzoli Fix For: 3.x According to slack's doc: {code} If you exceed a rate limit when using any of our HTTP-based APIs (including Incoming Webhooks), Slack will return a HTTP 429 Too Many Requests error, and a Retry-After HTTP header containing the number of seconds until you can retry. {code} We should explore if we can honor the Retry-After seconds to perform the next poll. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18172) Eagerly resolve ref language
Luca Burgazzoli created CAMEL-18172: --- Summary: Eagerly resolve ref language Key: CAMEL-18172 URL: https://issues.apache.org/jira/browse/CAMEL-18172 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Luca Burgazzoli Fix For: 3.18.0 The default RefLanguage component lazily resolve the ref expression hence it does not work with kamelets as the route template engine leverages a ThreadLocal bean repository to reify the route template, then such repo si cleared out and not more known by the routing engine. A way to workaround it is to create a custom ref language, as example: {code:java} import org.apache.camel.Expression; import org.apache.camel.Predicate; import org.apache.camel.language.ref.RefLanguage; import org.apache.camel.support.PredicateToExpressionAdapter; import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class EagerRefLanguage extends RefLanguage { private static final Logger LOGGER = LoggerFactory.getLogger(EagerRefLanguage.class); @Override public Expression createExpression(final String expression) { Expression exp = getCamelContext().getRegistry().lookupByNameAndType(expression, Expression.class); if (exp != null) { LOGGER.debug("Found and instance of {} expression in the registry {}", expression, exp); exp.init(getCamelContext()); return exp; } Predicate pred = getCamelContext().getRegistry().lookupByNameAndType(expression, Predicate.class); if (pred != null) { LOGGER.debug("Found and instance of {} predicate in the registry {}", expression, pred); pred.init(getCamelContext()); return PredicateToExpressionAdapter.toExpression(pred); } return super.createExpression(expression); } } {code} And bind it to the registry so camel will use as beans from the registry ahve priority over discovery form service loader. This is clearly an hack but we may want to bring such optimization to camel core, so i.e. if a ref expression is not dynamic, then we can load it when the ref is reified. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (CAMEL-14847) Create a camel-jq component
[ https://issues.apache.org/jira/browse/CAMEL-14847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-14847. - Resolution: Fixed > Create a camel-jq component > --- > > Key: CAMEL-14847 > URL: https://issues.apache.org/jira/browse/CAMEL-14847 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 3.18.0 > > > [https://github.com/arakelian/java-jq] > We can use this library, it's MIT licensed, so it is ok. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CAMEL-18165) camel-jackson: split the uber type converter
[ https://issues.apache.org/jira/browse/CAMEL-18165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17545851#comment-17545851 ] Luca Burgazzoli commented on CAMEL-18165: - Original discussion: https://github.com/apache/camel/pull/7715#issuecomment-1145717274 > camel-jackson: split the uber type converter > - > > Key: CAMEL-18165 > URL: https://issues.apache.org/jira/browse/CAMEL-18165 > Project: Camel > Issue Type: Improvement > Components: camel-jackson >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 3.x > > > In the camel-jackson component, the Jackson Type converter must explicitly be > enabled but I wonder if some basic conversion (i.e. > InputStream/String/byte[]/Map <--> JsonNode) can be enabled by default. > The reason for that is that in may case, including the new camel-jq component > I'm working on, being able to converts to/from JsonNode out of the box > without having to explicitly enable the type conversion would be a very nice > enhancement. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (CAMEL-18165) camel-jackson: split the uber type converter
[ https://issues.apache.org/jira/browse/CAMEL-18165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli updated CAMEL-18165: Fix Version/s: 3.x > camel-jackson: split the uber type converter > - > > Key: CAMEL-18165 > URL: https://issues.apache.org/jira/browse/CAMEL-18165 > Project: Camel > Issue Type: Improvement > Components: camel-jackson >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 3.x > > > In the camel-jackson component, the Jackson Type converter must explicitly be > enabled but I wonder if some basic conversion (i.e. > InputStream/String/byte[]/Map <--> JsonNode) can be enabled by default. > The reason for that is that in may case, including the new camel-jq component > I'm working on, being able to converts to/from JsonNode out of the box > without having to explicitly enable the type conversion would be a very nice > enhancement. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18165) camel-jackson: split the uber type converter
Luca Burgazzoli created CAMEL-18165: --- Summary: camel-jackson: split the uber type converter Key: CAMEL-18165 URL: https://issues.apache.org/jira/browse/CAMEL-18165 Project: Camel Issue Type: Improvement Components: camel-jackson Reporter: Luca Burgazzoli In the camel-jackson component, the Jackson Type converter must explicitly be enabled but I wonder if some basic conversion (i.e. InputStream/String/byte[]/Map <--> JsonNode) can be enabled by default. The reason for that is that in may case, including the new camel-jq component I'm working on, being able to converts to/from JsonNode out of the box without having to explicitly enable the type conversion would be a very nice enhancement. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work started] (CAMEL-14847) Create a camel-jq component
[ https://issues.apache.org/jira/browse/CAMEL-14847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-14847 started by Luca Burgazzoli. --- > Create a camel-jq component > --- > > Key: CAMEL-14847 > URL: https://issues.apache.org/jira/browse/CAMEL-14847 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 3.x > > > [https://github.com/arakelian/java-jq] > We can use this library, it's MIT licensed, so it is ok. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (CAMEL-14847) Create a camel-jq component
[ https://issues.apache.org/jira/browse/CAMEL-14847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli reassigned CAMEL-14847: --- Assignee: Luca Burgazzoli (was: Andrea Cosentino) > Create a camel-jq component > --- > > Key: CAMEL-14847 > URL: https://issues.apache.org/jira/browse/CAMEL-14847 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Luca Burgazzoli >Priority: Major > Fix For: 3.x > > > [https://github.com/arakelian/java-jq] > We can use this library, it's MIT licensed, so it is ok. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work started] (CAMEL-18072) mongodb: add a type converter to convert from byte[] to Document
[ https://issues.apache.org/jira/browse/CAMEL-18072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-18072 started by Luca Burgazzoli. --- > mongodb: add a type converter to convert from byte[] to Document > > > Key: CAMEL-18072 > URL: https://issues.apache.org/jira/browse/CAMEL-18072 > Project: Camel > Issue Type: New Feature > Components: camel-mongodb >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 3.18.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CAMEL-18072) mongodb: add a type converter to convert from byte[] to Document
Luca Burgazzoli created CAMEL-18072: --- Summary: mongodb: add a type converter to convert from byte[] to Document Key: CAMEL-18072 URL: https://issues.apache.org/jira/browse/CAMEL-18072 Project: Camel Issue Type: New Feature Components: camel-mongodb Reporter: Luca Burgazzoli Fix For: 3.18.0 -- This message was sent by Atlassian Jira (v8.20.7#820007)