[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)
[jira] [Assigned] (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 ] Luca Burgazzoli reassigned CAMEL-18072: --- Assignee: 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] [Commented] (CAMEL-17719) camel-saleforce: 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=17513421#comment-17513421
]
Luca Burgazzoli commented on CAMEL-17719:
-
Yes correct, I need the schema for the whole cdc event
> camel-saleforce: 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
>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.1#820001)
[jira] [Commented] (CAMEL-17719) camel-saleforce: 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=17513416#comment-17513416
]
Luca Burgazzoli commented on CAMEL-17719:
-
I didn't went into the detail but what I noticed is that the
SalesforceMetaDataExtension fails when you want to get the schema of a cdc event
> camel-saleforce: 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
>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.1#820001)
