[jira] [Resolved] (CAMEL-21019) Add a component for TensorFlow Serving
[ https://issues.apache.org/jira/browse/CAMEL-21019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato resolved CAMEL-21019. Resolution: Fixed > Add a component for TensorFlow Serving > -- > > Key: CAMEL-21019 > URL: https://issues.apache.org/jira/browse/CAMEL-21019 > Project: Camel > Issue Type: New Feature > Components: camel-ai >Affects Versions: 4.7.0 >Reporter: Tadayoshi Sato >Assignee: Tadayoshi Sato >Priority: Major > Fix For: 4.10.0 > > > Running a TensorFlow model is already supported through Camel DJL component. > However, Camel users might prefer to externalise inferencing to an external > server instead of running it inside the Camel route. For TensorFlow models, > it is generally done with [TensorFlow > Serving|https://www.tensorflow.org/tfx/guide/serving], which is a REST API > server for inferencing with TensorFlow. Camel should provide a producer > component that makes it easy to invoke the TensorFlow specific REST API from > the routes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-21281) camel-jbang - Remove camel k plugin
[ https://issues.apache.org/jira/browse/CAMEL-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-21281. - Resolution: Fixed > camel-jbang - Remove camel k plugin > --- > > Key: CAMEL-21281 > URL: https://issues.apache.org/jira/browse/CAMEL-21281 > Project: Camel > Issue Type: Task > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-21515) camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub Publisher
[ https://issues.apache.org/jira/browse/CAMEL-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-21515: --- Assignee: Claus Ibsen > camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub > Publisher > --- > > Key: CAMEL-21515 > URL: https://issues.apache.org/jira/browse/CAMEL-21515 > Project: Camel > Issue Type: Improvement > Components: camel-google-pubsub >Affects Versions: 3.14.0 >Reporter: Sateesh Divvela >Assignee: Claus Ibsen >Priority: Minor > Labels: google, publish, pubsub > Fix For: 4.10.0 > > Attachments: CAMEL-21515.patch > > > The current implementation of the Google Pub/Sub publisher does not allow for > customization of retry settings. To address this, we propose adding a new > "retry" option to the Google Pub/Sub endpoint that enables users to pass in > their own custom RetrySettings instance. This will provide greater > flexibility and control over retries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-21515) camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub Publisher
[ https://issues.apache.org/jira/browse/CAMEL-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-21515. - Resolution: Fixed Thanks for reporting and the patch. > camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub > Publisher > --- > > Key: CAMEL-21515 > URL: https://issues.apache.org/jira/browse/CAMEL-21515 > Project: Camel > Issue Type: Improvement > Components: camel-google-pubsub >Affects Versions: 3.14.0 >Reporter: Sateesh Divvela >Assignee: Claus Ibsen >Priority: Minor > Labels: google, publish, pubsub > Fix For: 4.10.0 > > Attachments: CAMEL-21515.patch > > > The current implementation of the Google Pub/Sub publisher does not allow for > customization of retry settings. To address this, we propose adding a new > "retry" option to the Google Pub/Sub endpoint that enables users to pass in > their own custom RetrySettings instance. This will provide greater > flexibility and control over retries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-21515) camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub Publisher
[ https://issues.apache.org/jira/browse/CAMEL-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-21515: Fix Version/s: 4.10.0 > camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub > Publisher > --- > > Key: CAMEL-21515 > URL: https://issues.apache.org/jira/browse/CAMEL-21515 > Project: Camel > Issue Type: Improvement > Components: camel-google-pubsub >Affects Versions: 3.14.0 >Reporter: Sateesh Divvela >Priority: Minor > Labels: google, publish, pubsub > Fix For: 4.10.0 > > Attachments: CAMEL-21515.patch > > > The current implementation of the Google Pub/Sub publisher does not allow for > customization of retry settings. To address this, we propose adding a new > "retry" option to the Google Pub/Sub endpoint that enables users to pass in > their own custom RetrySettings instance. This will provide greater > flexibility and control over retries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21019) Add a component for TensorFlow Serving
[ https://issues.apache.org/jira/browse/CAMEL-21019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17903199#comment-17903199 ] Tadayoshi Sato commented on CAMEL-21019: [~davsclaus] Yes, I will. > Add a component for TensorFlow Serving > -- > > Key: CAMEL-21019 > URL: https://issues.apache.org/jira/browse/CAMEL-21019 > Project: Camel > Issue Type: New Feature > Components: camel-ai >Affects Versions: 4.7.0 >Reporter: Tadayoshi Sato >Assignee: Tadayoshi Sato >Priority: Major > Fix For: 4.10.0 > > > Running a TensorFlow model is already supported through Camel DJL component. > However, Camel users might prefer to externalise inferencing to an external > server instead of running it inside the Camel route. For TensorFlow models, > it is generally done with [TensorFlow > Serving|https://www.tensorflow.org/tfx/guide/serving], which is a REST API > server for inferencing with TensorFlow. Camel should provide a producer > component that makes it easy to invoke the TensorFlow specific REST API from > the routes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17902932#comment-17902932
]
Pasquale Congiusti commented on CAMEL-21472:
I have identified the main reason of the failure which is the fact we're
closing the scope too fast. I still need to verify the mechanism to restart the
trace once the exchange is complete. This is the traces I am getting:
{code}
10:13:21.909 [9e8c45a66385b66a603a75b4cf089c8d, f4e0aee994b9d56c] in timer route
10:13:21.916 [9e8c45a66385b66a603a75b4cf089c8d, 411bbecf3add1bcc] in
aSlowerRoute
10:13:21.920 [9e8c45a66385b66a603a75b4cf089c8d, 411bbecf3add1bcc] still in
aSlowerRoute
10:13:21.921 [9e8c45a66385b66a603a75b4cf089c8d, a6e5da0571573e03] in
aFasterRoute
10:13:21.926 [9e8c45a66385b66a603a75b4cf089c8d, a6e5da0571573e03] still in
aFasterRoute
10:13:31.885 [9e8c45a66385b66a603a75b4cf089c8d, 950d66e2a86c8dd5] in timer route
10:13:31.886 [9e8c45a66385b66a603a75b4cf089c8d, 625c85843b506435] in
aSlowerRoute
10:13:31.888 [9e8c45a66385b66a603a75b4cf089c8d, 625c85843b506435] still in
aSlowerRoute
10:13:31.889 [9e8c45a66385b66a603a75b4cf089c8d, 263bfaf1847fac78] in
aFasterRoute
10:13:31.893 [9e8c45a66385b66a603a75b4cf089c8d, 263bfaf1847fac78] still in
aFasterRoute
10:13:41.886 [9e8c45a66385b66a603a75b4cf089c8d, 6f1cea732bd351c3] in timer route
10:13:41.886 [9e8c45a66385b66a603a75b4cf089c8d, a103fc4b3a433864] in
aSlowerRoute
10:13:41.888 [9e8c45a66385b66a603a75b4cf089c8d, a103fc4b3a433864] still in
aSlowerRoute
10:13:41.889 [9e8c45a66385b66a603a75b4cf089c8d, 7b525d393fa4af89] in
aFasterRoute
10:13:41.893 [9e8c45a66385b66a603a75b4cf089c8d, 7b525d393fa4af89] still in
aFasterRoute
{code}
However we really have a problem with the MDC context propagation that is not
working out of the box. The above traces are taken when using the MDC
instrumentation provided by Opentelemetry, which, IMO, should be the proper way
to handle. I'll continue working to see how to reset the trace properly and we
can have a further discussion once that is over.
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.3, 4.10.0
>
> Attachments: image-2024-11-26-09-59-35-555.png,
> image-2024-11-29-17-04-16-581.png, image-2024-11-29-17-06-26-116.png,
> image-2024-11-29-17-06-42-860.png, image-2024-11-29-17-12-49-768.png,
> image-2024-11-29-17-12-58-036.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-21509) camel-kubernetes - Upgrade to v7 of fabric8-client
Claus Ibsen created CAMEL-21509: --- Summary: camel-kubernetes - Upgrade to v7 of fabric8-client Key: CAMEL-21509 URL: https://issues.apache.org/jira/browse/CAMEL-21509 Project: Camel Issue Type: Dependency upgrade Components: camel-kubernetes Reporter: Claus Ibsen Fix For: 4.x [https://blog.marcnuri.com/fabric8-kubernetes-client-7-0] The CEQ project may need to upgrade as well to make this work on Quarkus. A -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21510) Kubernetes plugin support for parameter name
Bruno Meseguer created CAMEL-21510:
--
Summary: Kubernetes plugin support for parameter name
Key: CAMEL-21510
URL: https://issues.apache.org/jira/browse/CAMEL-21510
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Reporter: Bruno Meseguer
The current implementation of the Kubernetes plugin selects as the deployment
name the first file source listed in the deployment command, for example, in:
{code:java}
camel kubernetes run main.yaml{code}
would result in a deployment name "main"
Adding support for a parameter --name would help gaining control over the
deployment name. For example:
{code:java}
camel kubernetes run main.yaml --name=price{code}
resulting in deploying an integration using the name "price"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-21510) Kubernetes plugin support for parameter name
[
https://issues.apache.org/jira/browse/CAMEL-21510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Meseguer updated CAMEL-21510:
---
Description:
The current implementation of the Kubernetes plugin selects as the deployment
name the first file source listed in the deployment command, for example, in:
{code:java}
camel kubernetes run main.yaml{code}
would result in a deployment name "main"
Adding support for a parameter --name would help gaining control over the
deployment name. For example:
{code:java}
camel kubernetes run main.yaml --name=price{code}
resulting in deploying an integration using the name "price"
was:
The current implementation of the Kubernetes plugin selects as the deployment
name the first file source listed in the deployment command, for example, in:
{code:java}
camel kubernetes run main.yaml{code}
would result in a deployment name "main"
Adding support for a parameter --name would help gaining control over the
deployment name. For example:
{code:java}
camel kubernetes run main.yaml --name=price{code}
resulting in deploying an integration using the name "price"
> Kubernetes plugin support for parameter name
> -
>
> Key: CAMEL-21510
> URL: https://issues.apache.org/jira/browse/CAMEL-21510
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
>Reporter: Bruno Meseguer
>Priority: Major
>
> The current implementation of the Kubernetes plugin selects as the deployment
> name the first file source listed in the deployment command, for example, in:
> {code:java}
> camel kubernetes run main.yaml{code}
> would result in a deployment name "main"
> Adding support for a parameter --name would help gaining control over the
> deployment name. For example:
> {code:java}
> camel kubernetes run main.yaml --name=price{code}
> resulting in deploying an integration using the name "price"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-21510) Kubernetes plugin support for parameter name
[
https://issues.apache.org/jira/browse/CAMEL-21510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Meseguer updated CAMEL-21510:
---
Description:
The current implementation of the Kubernetes plugin selects as the deployment
name the first file source listed in the deployment command, for example, in:
{code:java}
camel kubernetes run main.yaml{code}
would result in a deployment name "main"
Adding support for a parameter --name would help gaining control over the
deployment name. For example:
{code:java}
camel kubernetes run main.yaml --name=price{code}
resulting in deploying an integration using the name "price"
was:
The current implementation of the Kubernetes plugin selects as the deployment
name the first file source listed in the deployment command, for example, in:
{code:java}
camel kubernetes run main.yaml{code}
would result in a deployment name "main"
Adding support for a parameter --name would help gaining control over the
deployment name. For example:
{code:java}
camel kubernetes run main.yaml --name=price{code}
resulting in deploying an integration using the name "price"
> Kubernetes plugin support for parameter name
> -
>
> Key: CAMEL-21510
> URL: https://issues.apache.org/jira/browse/CAMEL-21510
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
>Reporter: Bruno Meseguer
>Priority: Major
>
> The current implementation of the Kubernetes plugin selects as the deployment
> name the first file source listed in the deployment command, for example, in:
> {code:java}
> camel kubernetes run main.yaml{code}
> would result in a deployment name "main"
> Adding support for a parameter --name would help gaining control over the
> deployment name. For example:
> {code:java}
> camel kubernetes run main.yaml --name=price{code}
>
> resulting in deploying an integration using the name "price"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-21510) Kubernetes plugin support for parameter name
[
https://issues.apache.org/jira/browse/CAMEL-21510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Meseguer updated CAMEL-21510:
---
Description:
The current implementation of the Kubernetes plugin selects as the deployment
name the first file source listed in the deployment command, for example, in:
{code:java}
camel kubernetes run main.yaml{code}
Would result in a deployment name "main"
Adding support for a parameter --name would help gain control over the
deployment name. For example:
{code:java}
camel kubernetes run main.yaml --name=price{code}
Resulting in deploying an integration using the name "price"
was:
The current implementation of the Kubernetes plugin selects as the deployment
name the first file source listed in the deployment command, for example, in:
{code:java}
camel kubernetes run main.yaml{code}
would result in a deployment name "main"
Adding support for a parameter --name would help gaining control over the
deployment name. For example:
{code:java}
camel kubernetes run main.yaml --name=price{code}
resulting in deploying an integration using the name "price"
> Kubernetes plugin support for parameter name
> -
>
> Key: CAMEL-21510
> URL: https://issues.apache.org/jira/browse/CAMEL-21510
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
>Reporter: Bruno Meseguer
>Priority: Major
>
> The current implementation of the Kubernetes plugin selects as the deployment
> name the first file source listed in the deployment command, for example, in:
> {code:java}
> camel kubernetes run main.yaml{code}
> Would result in a deployment name "main"
> Adding support for a parameter --name would help gain control over the
> deployment name. For example:
> {code:java}
> camel kubernetes run main.yaml --name=price{code}
> Resulting in deploying an integration using the name "price"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-21511) camel-jbang - camel transform route with rest-dsl should not inline routes
Claus Ibsen created CAMEL-21511: --- Summary: camel-jbang - camel transform route with rest-dsl should not inline routes Key: CAMEL-21511 URL: https://issues.apache.org/jira/browse/CAMEL-21511 Project: Camel Issue Type: Improvement Components: camel-jbang Reporter: Claus Ibsen Fix For: 4.10.0 If you transform a route that uses rest-dsl then Camel will inlined routes by default, and the dump cannot have the routes included. So we need to make Camel run without inlining. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21512) camel-jbang - camel transform route with multiple only include last
Claus Ibsen created CAMEL-21512: --- Summary: camel-jbang - camel transform route with multiple only include last Key: CAMEL-21512 URL: https://issues.apache.org/jira/browse/CAMEL-21512 Project: Camel Issue Type: Bug Components: camel-jbang Reporter: Claus Ibsen Fix For: 4.10.0 If you have multiple seperated ... then it appears that the transformed output is only including the last block. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21513) CoreTypeRegistry can create unpredictable type to converter mappings
Nathan created CAMEL-21513: -- Summary: CoreTypeRegistry can create unpredictable type to converter mappings Key: CAMEL-21513 URL: https://issues.apache.org/jira/browse/CAMEL-21513 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 4.4.4 Reporter: Nathan *Context* The CoreTypeConverterRegistry uses a map of converters to find a converter for a TypeConvertible. If there is no known converter it attempts to find one in the existing converter map based on the idea that an existing converter on a super class can be used. This logic is contained in the TypeResolverHelper.tryMatch method. The tryMatch method will do an exhaustive search on the types in the converter and the super classes of the to convert value. To do this tryMatch will iterate over all the existing converters. Each existing converter will then be compared to the super classes of the TypeConvertible. *Problem* The problem is that the TypeResolverHelper.tryMatch can be highly random in selecting a converter. The first converter that matches is chosen and stored for all future usage of this specific type conversion. But the order of iteration for the converter map is not guaranteed to be the same every time. It is very likely that it is different for every load, since it depends on the order that converters have been added and there is no order guarantee on HashMap entry set iteration. This is not only theoretical, we already had a problem with the type conversion of DeferredElementNSImpl to CxfPayload. DeferredElementNSImpl implements both org.w3c.dom.Element and org.w3c.dom.NodeList. Both of those have converters in the CxfPayloadConverterLoader. But the converter chosen was random and often changed after application restarts. This caused problems for us since the NodeList to CxfPayload did not transform the DeferredElementNSImpl as expected. *Workaround* There is an easy workaround by defining your own converters to ensure the correct conversion happens, but this workaround can be cumbersome for applications with a lot of implicit type conversions. Especially if the correct conversion does exist, but is just not used. *Solution?* I do think there is a potential solution, the converter iteration is random and it would be inefficient to order it. That would also not necessarily fix anything since any order could be wrong for some specific conversion. Instead the TypeResolverHelper.tryMatch could change things by iterating over the super classes of the from first. And try to find a converter for each super class. The complication is that the super class iteration is done in the TypeConvertible, so it would have to be duplicated or moved into the TypeResolverHelper to do that. The method getInterfaces that is used in the TypeConvertible is ordered by the JDK, so there would be no randomness. Instead it would select the first existing converter that is actually closest to the target class. This is much better than just the first converter that happens to match with an interface removed 5 super classes. For the DeferredElementNSImpl it would then go: look for DeferredElementNSImpl -> not found look for ElementNSImpl -> not found look for ElementImpl -> not found Look for Element -> found CxfPayloadConverter.elementToCxfPayload -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-21514) camel-jgropus - Upgrade to 5.4 and remove cluster lock
[ https://issues.apache.org/jira/browse/CAMEL-21514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-21514: Priority: Minor (was: Major) > camel-jgropus - Upgrade to 5.4 and remove cluster lock > -- > > Key: CAMEL-21514 > URL: https://issues.apache.org/jira/browse/CAMEL-21514 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-jgroups >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.10.0 > > > See > https://github.com/belaban/JGroups/discussions/870#discussioncomment-11460448 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-21514) camel-jgropus - Upgrade to 5.4 and remove cluster lock
Claus Ibsen created CAMEL-21514: --- Summary: camel-jgropus - Upgrade to 5.4 and remove cluster lock Key: CAMEL-21514 URL: https://issues.apache.org/jira/browse/CAMEL-21514 Project: Camel Issue Type: Dependency upgrade Components: camel-jgroups Reporter: Claus Ibsen Fix For: 4.10.0 See https://github.com/belaban/JGroups/discussions/870#discussioncomment-11460448 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-21510) Kubernetes plugin support for parameter name
[
https://issues.apache.org/jira/browse/CAMEL-21510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-21510:
---
Assignee: Thomas Diesler
> Kubernetes plugin support for parameter name
> -
>
> Key: CAMEL-21510
> URL: https://issues.apache.org/jira/browse/CAMEL-21510
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
>Reporter: Bruno Meseguer
>Assignee: Thomas Diesler
>Priority: Major
>
> The current implementation of the Kubernetes plugin selects as the deployment
> name the first file source listed in the deployment command, for example, in:
> {code:java}
> camel kubernetes run main.yaml{code}
> Would result in a deployment name "main"
> Adding support for a parameter --name would help gain control over the
> deployment name. For example:
> {code:java}
> camel kubernetes run main.yaml --name=price{code}
> Resulting in deploying an integration using the name "price"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-21514) camel-jgropus - Upgrade to 5.4 and remove cluster lock
[ https://issues.apache.org/jira/browse/CAMEL-21514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-21514: --- Assignee: Claus Ibsen > camel-jgropus - Upgrade to 5.4 and remove cluster lock > -- > > Key: CAMEL-21514 > URL: https://issues.apache.org/jira/browse/CAMEL-21514 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-jgroups >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.10.0 > > > See > https://github.com/belaban/JGroups/discussions/870#discussioncomment-11460448 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-21325) camel-jbang - Kubernetes run should cleanup old temp folders
[ https://issues.apache.org/jira/browse/CAMEL-21325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-21325. - Resolution: Fixed > camel-jbang - Kubernetes run should cleanup old temp folders > > > Key: CAMEL-21325 > URL: https://issues.apache.org/jira/browse/CAMEL-21325 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Thomas Diesler >Priority: Major > Fix For: 4.10.0 > > > camel kubernetes run, stores temp data in .camel-jbang-run/NNN folder > where N is some random numbers. > We should cleanup old folders when they are not in use anymore -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-21510) Kubernetes plugin support for parameter name
[
https://issues.apache.org/jira/browse/CAMEL-21510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-21510:
Fix Version/s: 4.10.0
> Kubernetes plugin support for parameter name
> -
>
> Key: CAMEL-21510
> URL: https://issues.apache.org/jira/browse/CAMEL-21510
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
>Reporter: Bruno Meseguer
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.10.0
>
>
> The current implementation of the Kubernetes plugin selects as the deployment
> name the first file source listed in the deployment command, for example, in:
> {code:java}
> camel kubernetes run main.yaml{code}
> Would result in a deployment name "main"
> Adding support for a parameter --name would help gain control over the
> deployment name. For example:
> {code:java}
> camel kubernetes run main.yaml --name=price{code}
> Resulting in deploying an integration using the name "price"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-21514) camel-jgropus - Upgrade to 5.4 and remove cluster lock
[ https://issues.apache.org/jira/browse/CAMEL-21514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-21514. - Resolution: Fixed > camel-jgropus - Upgrade to 5.4 and remove cluster lock > -- > > Key: CAMEL-21514 > URL: https://issues.apache.org/jira/browse/CAMEL-21514 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-jgroups >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.10.0 > > > See > https://github.com/belaban/JGroups/discussions/870#discussioncomment-11460448 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21495) camel-quarkus: REST route inlining works incorrectly when testing
[
https://issues.apache.org/jira/browse/CAMEL-21495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17902993#comment-17902993
]
James Netherton commented on CAMEL-21495:
-
I converted the reproducer app to use camel-main, did 100 tests runs and it
passed.
Something strange is happening on CQ. The test passes sometimes but fails on
other runs.
[~samipeltola] is this only an issue when running tests? Or do you observe it
when running from quarkus-run.jar? I only see the issue happen at test time.
> camel-quarkus: REST route inlining works incorrectly when testing
> -
>
> Key: CAMEL-21495
> URL: https://issues.apache.org/jira/browse/CAMEL-21495
> Project: Camel
> Issue Type: Bug
> Components: camel-rest-openapi
>Affects Versions: 4.8.1
>Reporter: Sami Peltola
>Priority: Minor
> Attachments: quarkus-camel-rest-inline-issue.zip
>
>
> h2. The Issue: REST-route inlining works incorrectly/inconsistently when
> testing
> Encountered when running tests, sometimes the wrong subroute gets inlined to
> the rest-route and causes failures.
> Referring to:
> [https://camel.apache.org/manual/rest-dsl.html#_inline_rest_dsl_as_a_single_route]
> I've attached an example project. When running the tests, a test called
> "FailingTest" should have "camel.rest.inline-routes" enabled and should fail,
> as opposed to "SucceedingTest" which has the option disabled and does not
> fail.
> It seems like when inlining the routes, the subroute "get-from-db-route" gets
> inlined when actually route "quarkuscamelexampleservice-http-get-route"
> should be inlined as it is the subroute that is called from the REST-route.
> For some reason, the tests failing also seems a bit flaky, so you might have
> to run all the tests in a loop to replicate the issue, i've included a script
> "run-test-in-loop.sh".
> When the test fails, it only shows routes:
> {code:java}
> 2024-12-02 10:45:20,687 INFO [org.apa.cam.qua.cor.CamelBootstrapRecorder]
> (main) Apache Camel Quarkus 3.16.0 is starting
> 2024-12-02 10:45:20,687 INFO [org.apa.cam.mai.MainSupport] (main) Apache
> Camel (Main) 4.8.1 is starting
> 2024-12-02 10:45:20,716 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> Auto-configuration summary
> 2024-12-02 10:45:20,716 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> [MicroProfilePropertiesSource] camel.main.dumpRoutes = xml
> 2024-12-02 10:45:20,716 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> [JVM System Property] camel.rest.inlineRoutes = true
> 2024-12-02 10:45:20,882 INFO [org.apa.cam.imp.eng.AbstractCamelContext]
> (main) Apache Camel 4.8.1 (camel-1) is starting
> 2024-12-02 10:45:20,894 INFO [org.apa.cam.imp.DefaultDumpRoutesStrategy]
> (main) Dumping 5 routes as XML
> 2024-12-02 10:45:20,895 INFO [org.apa.cam.imp.DefaultDumpRoutesStrategy]
> (main)
>
>
>
> java.lang.Exception
>
>
> Error with database backend:
> ${exception.message}
>
>
>
>
>
>
> {code}
>
> Sometimes it works correctly, and shows how it actually should have inlined
> the routes with the route "subroute-for-get" not being inlined to the
> REST-route,but instead existing as a separate route in the context:
> {code:java}
> 2024-12-02 10:40:11,095 INFO [org.apa.cam.qua.cor.CamelBootstrapRecorder]
> (main) Apache Camel Quarkus 3.16.0 is starting
> 2024-12-02 10:40:11,096 INFO [org.apa.cam.mai.MainSupport] (main) Apache
> Camel (Main) 4.8.1 is starting
> 2024-12-02 10:40:11,198 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> Auto-configuration summary
> 2024-12-02 10:40:11,198 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> [MicroProfilePropertiesSource] camel.main.dumpRoutes = xml
> 2024-12-02 10:40:11,199 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> [JVM System Property] camel.rest.inlineRoutes = true
> 2024-12-02 10:40:11,857 INFO [org.apa.cam.imp.eng.AbstractCamelContext]
> (main) Apache Camel 4.8.1 (camel-1) is starting
> 2024-12-02 10:40:11,923 INFO [org.apa.cam.imp.DefaultDumpRoutesStrategy]
> (main) Dumping 6 routes as XML
> 2024-12-02 10:40:11,924 INFO [org.apa.cam.imp.DefaultDumpRoutesStrategy]
> (main)
>
>
>
> java.lang.Exception
>
>
> Error with database backend:
> ${exception.message}
>
>
>
>
>
>
>
>
>
> java.lang.Exception
>
>
> Error with http backend: ${exception.message}
>
>
>
>
>
>
> {code}
> I have not had any is
[jira] [Updated] (CAMEL-21513) camel-core - CoreTypeRegistry can create unpredictable type to converter mappings
[ https://issues.apache.org/jira/browse/CAMEL-21513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-21513: Summary: camel-core - CoreTypeRegistry can create unpredictable type to converter mappings (was: CoreTypeRegistry can create unpredictable type to converter mappings) > camel-core - CoreTypeRegistry can create unpredictable type to converter > mappings > - > > Key: CAMEL-21513 > URL: https://issues.apache.org/jira/browse/CAMEL-21513 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.4.4 >Reporter: Nathan >Priority: Minor > Fix For: 4.x > > > *Context* > The CoreTypeConverterRegistry uses a map of converters to find a converter > for a TypeConvertible. > If there is no known converter it attempts to find one in the existing > converter map based on the idea that an existing converter on a super class > can be used. > This logic is contained in the TypeResolverHelper.tryMatch method. The > tryMatch method will do an exhaustive search on the types in the converter > and the super classes of the to convert value. > To do this tryMatch will iterate over all the existing converters. Each > existing converter will then be compared to the super classes of the > TypeConvertible. > *Problem* > The problem is that the TypeResolverHelper.tryMatch can be highly random in > selecting a converter. The first converter that matches is chosen and stored > for all future usage of this specific type conversion. > But the order of iteration for the converter map is not guaranteed to be the > same every time. It is very likely that it is different for every load, since > it depends on the order that converters have been added and there is no order > guarantee on HashMap entry set iteration. > This is not only theoretical, we already had a problem with the type > conversion of DeferredElementNSImpl to CxfPayload. DeferredElementNSImpl > implements both org.w3c.dom.Element and org.w3c.dom.NodeList. Both of those > have converters in the CxfPayloadConverterLoader. > But the converter chosen was random and often changed after application > restarts. This caused problems for us since the NodeList to CxfPayload did > not transform the DeferredElementNSImpl as expected. > *Workaround* > There is an easy workaround by defining your own converters to ensure the > correct conversion happens, but this workaround can be cumbersome for > applications with a lot of implicit type conversions. > Especially if the correct conversion does exist, but is just not used. > *Solution?* > I do think there is a potential solution, the converter iteration is random > and it would be inefficient to order it. That would also not necessarily fix > anything since any order could be wrong for some specific conversion. > Instead the TypeResolverHelper.tryMatch could change things by iterating over > the super classes of the from first. And try to find a converter for each > super class. > The complication is that the super class iteration is done in the > TypeConvertible, so it would have to be duplicated or moved into the > TypeResolverHelper to do that. > The method getInterfaces that is used in the TypeConvertible is ordered by > the JDK, so there would be no randomness. Instead it would select the first > existing converter that is actually closest to the target class. > This is much better than just the first converter that happens to match with > an interface removed 5 super classes. > For the DeferredElementNSImpl it would then go: > look for DeferredElementNSImpl -> not found > look for ElementNSImpl -> not found > look for ElementImpl -> not found > Look for Element -> found CxfPayloadConverter.elementToCxfPayload -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21513) CoreTypeRegistry can create unpredictable type to converter mappings
[ https://issues.apache.org/jira/browse/CAMEL-21513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17903008#comment-17903008 ] Claus Ibsen commented on CAMEL-21513: - You are welcome to work on a proposed path and send a PR or attach code to this JIRA > CoreTypeRegistry can create unpredictable type to converter mappings > > > Key: CAMEL-21513 > URL: https://issues.apache.org/jira/browse/CAMEL-21513 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.4.4 >Reporter: Nathan >Priority: Minor > > *Context* > The CoreTypeConverterRegistry uses a map of converters to find a converter > for a TypeConvertible. > If there is no known converter it attempts to find one in the existing > converter map based on the idea that an existing converter on a super class > can be used. > This logic is contained in the TypeResolverHelper.tryMatch method. The > tryMatch method will do an exhaustive search on the types in the converter > and the super classes of the to convert value. > To do this tryMatch will iterate over all the existing converters. Each > existing converter will then be compared to the super classes of the > TypeConvertible. > *Problem* > The problem is that the TypeResolverHelper.tryMatch can be highly random in > selecting a converter. The first converter that matches is chosen and stored > for all future usage of this specific type conversion. > But the order of iteration for the converter map is not guaranteed to be the > same every time. It is very likely that it is different for every load, since > it depends on the order that converters have been added and there is no order > guarantee on HashMap entry set iteration. > This is not only theoretical, we already had a problem with the type > conversion of DeferredElementNSImpl to CxfPayload. DeferredElementNSImpl > implements both org.w3c.dom.Element and org.w3c.dom.NodeList. Both of those > have converters in the CxfPayloadConverterLoader. > But the converter chosen was random and often changed after application > restarts. This caused problems for us since the NodeList to CxfPayload did > not transform the DeferredElementNSImpl as expected. > *Workaround* > There is an easy workaround by defining your own converters to ensure the > correct conversion happens, but this workaround can be cumbersome for > applications with a lot of implicit type conversions. > Especially if the correct conversion does exist, but is just not used. > *Solution?* > I do think there is a potential solution, the converter iteration is random > and it would be inefficient to order it. That would also not necessarily fix > anything since any order could be wrong for some specific conversion. > Instead the TypeResolverHelper.tryMatch could change things by iterating over > the super classes of the from first. And try to find a converter for each > super class. > The complication is that the super class iteration is done in the > TypeConvertible, so it would have to be duplicated or moved into the > TypeResolverHelper to do that. > The method getInterfaces that is used in the TypeConvertible is ordered by > the JDK, so there would be no randomness. Instead it would select the first > existing converter that is actually closest to the target class. > This is much better than just the first converter that happens to match with > an interface removed 5 super classes. > For the DeferredElementNSImpl it would then go: > look for DeferredElementNSImpl -> not found > look for ElementNSImpl -> not found > look for ElementImpl -> not found > Look for Element -> found CxfPayloadConverter.elementToCxfPayload -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-21513) CoreTypeRegistry can create unpredictable type to converter mappings
[ https://issues.apache.org/jira/browse/CAMEL-21513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-21513: Fix Version/s: 4.x > CoreTypeRegistry can create unpredictable type to converter mappings > > > Key: CAMEL-21513 > URL: https://issues.apache.org/jira/browse/CAMEL-21513 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.4.4 >Reporter: Nathan >Priority: Minor > Fix For: 4.x > > > *Context* > The CoreTypeConverterRegistry uses a map of converters to find a converter > for a TypeConvertible. > If there is no known converter it attempts to find one in the existing > converter map based on the idea that an existing converter on a super class > can be used. > This logic is contained in the TypeResolverHelper.tryMatch method. The > tryMatch method will do an exhaustive search on the types in the converter > and the super classes of the to convert value. > To do this tryMatch will iterate over all the existing converters. Each > existing converter will then be compared to the super classes of the > TypeConvertible. > *Problem* > The problem is that the TypeResolverHelper.tryMatch can be highly random in > selecting a converter. The first converter that matches is chosen and stored > for all future usage of this specific type conversion. > But the order of iteration for the converter map is not guaranteed to be the > same every time. It is very likely that it is different for every load, since > it depends on the order that converters have been added and there is no order > guarantee on HashMap entry set iteration. > This is not only theoretical, we already had a problem with the type > conversion of DeferredElementNSImpl to CxfPayload. DeferredElementNSImpl > implements both org.w3c.dom.Element and org.w3c.dom.NodeList. Both of those > have converters in the CxfPayloadConverterLoader. > But the converter chosen was random and often changed after application > restarts. This caused problems for us since the NodeList to CxfPayload did > not transform the DeferredElementNSImpl as expected. > *Workaround* > There is an easy workaround by defining your own converters to ensure the > correct conversion happens, but this workaround can be cumbersome for > applications with a lot of implicit type conversions. > Especially if the correct conversion does exist, but is just not used. > *Solution?* > I do think there is a potential solution, the converter iteration is random > and it would be inefficient to order it. That would also not necessarily fix > anything since any order could be wrong for some specific conversion. > Instead the TypeResolverHelper.tryMatch could change things by iterating over > the super classes of the from first. And try to find a converter for each > super class. > The complication is that the super class iteration is done in the > TypeConvertible, so it would have to be duplicated or moved into the > TypeResolverHelper to do that. > The method getInterfaces that is used in the TypeConvertible is ordered by > the JDK, so there would be no randomness. Instead it would select the first > existing converter that is actually closest to the target class. > This is much better than just the first converter that happens to match with > an interface removed 5 super classes. > For the DeferredElementNSImpl it would then go: > look for DeferredElementNSImpl -> not found > look for ElementNSImpl -> not found > look for ElementImpl -> not found > Look for Element -> found CxfPayloadConverter.elementToCxfPayload -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21486) camel k8s ... cannot push to image-registry.openshift-image-registry.svc:5000
[ https://issues.apache.org/jira/browse/CAMEL-21486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17903018#comment-17903018 ] Claus Ibsen commented on CAMEL-21486: - The trait changes has been backported now, thanks. > camel k8s ... cannot push to image-registry.openshift-image-registry.svc:5000 > - > > Key: CAMEL-21486 > URL: https://issues.apache.org/jira/browse/CAMEL-21486 > Project: Camel > Issue Type: Bug > Components: camel-jbang >Affects Versions: 4.8.1 >Reporter: Andrea Cosentino >Assignee: Thomas Diesler >Priority: Major > Fix For: 4.8.3, 4.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-21511) camel-jbang - camel transform route with rest-dsl should not inline routes
[ https://issues.apache.org/jira/browse/CAMEL-21511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-21511: Priority: Minor (was: Major) > camel-jbang - camel transform route with rest-dsl should not inline routes > -- > > Key: CAMEL-21511 > URL: https://issues.apache.org/jira/browse/CAMEL-21511 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.10.0 > > > If you transform a route that uses rest-dsl then Camel will inlined routes by > default, and the dump cannot have the routes included. So we need to make > Camel run without inlining. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-21281) camel-jbang - Remove camel k plugin
[ https://issues.apache.org/jira/browse/CAMEL-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-21281: --- Assignee: Claus Ibsen > camel-jbang - Remove camel k plugin > --- > > Key: CAMEL-21281 > URL: https://issues.apache.org/jira/browse/CAMEL-21281 > Project: Camel > Issue Type: Task > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-21499) Error while loading Spring XML context when using Eclipselink MOXy as the JAXB implementation
[
https://issues.apache.org/jira/browse/CAMEL-21499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-21499.
-
Resolution: Information Provided
> Error while loading Spring XML context when using Eclipselink MOXy as the
> JAXB implementation
> -
>
> Key: CAMEL-21499
> URL: https://issues.apache.org/jira/browse/CAMEL-21499
> Project: Camel
> Issue Type: Bug
> Components: camel-spring-xml
>Affects Versions: 4.8.0
>Reporter: Adriano Machado
>Priority: Minor
>
> The following error message is shown on a unit test after upgrading the Camel
> version from 4.4.0 to 4.8.0:
> {code:java}
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> Caused by: jakarta.xml.bind.JAXBException:
> Exception Description: An attempt was made to set more than one XmlAnyElement
> property on class [org.apache.camel.model.app.BeansDefinition]. Property
> [blueprintBeans] cannot be set as XmlAnyElement, because property
> [springBeans] is already set as XmlAnyElement.
> - with linked exception:
> [Exception [EclipseLink-50032] (Eclipse Persistence Services -
> 4.0.4.v202407190748-059428cdd2583c46f1f3e50d235854840a6fa9a7):
> org.eclipse.persistence.exceptions.JAXBException
> Exception Description: An attempt was made to set more than one XmlAnyElement
> property on class [org.apache.camel.model.app.BeansDefinition]. Property
> [blueprintBeans] cannot be set as XmlAnyElement, because property
> [springBeans] is already set as XmlAnyElement.]
> at
> org.eclipse.persistence.jaxb.JAXBContext$ContextPathInput.createContextState(JAXBContext.java:994)
> at
> org.eclipse.persistence.jaxb.JAXBContext$ContextPathInput.createContextState(JAXBContext.java:923)
> at
> org.eclipse.persistence.jaxb.JAXBContext.(JAXBContext.java:208)
> at
> org.eclipse.persistence.jaxb.JAXBContextFactory.createContext(JAXBContextFactory.java:131)
> at
> org.eclipse.persistence.jaxb.XMLBindingContextFactory.createContext(XMLBindingContextFactory.java:61)
> at jakarta.xml.bind.ContextFinder.find(ContextFinder.java:322)
> at jakarta.xml.bind.JAXBContext.newInstance(JAXBContext.java:392)
> at jakarta.xml.bind.JAXBContext.newInstance(JAXBContext.java:349)
> at
> org.apache.camel.xml.jaxb.DefaultModelJAXBContextFactory.newJAXBContext(DefaultModelJAXBContextFactory.java:44)
> at
> org.apache.camel.spring.xml.handler.CamelNamespaceHandler.getJaxbContext(CamelNamespaceHandler.java:206)
> at
> org.apache.camel.spring.xml.handler.CamelNamespaceHandler$CamelContextBeanDefinitionParser.doParse(CamelNamespaceHandler.java:428)
> ... 72 more
> Caused by: Exception [EclipseLink-50032] (Eclipse Persistence Services -
> 4.0.4.v202407190748-059428cdd2583c46f1f3e50d235854840a6fa9a7):
> org.eclipse.persistence.exceptions.JAXBException
> Exception Description: An attempt was made to set more than one XmlAnyElement
> property on class [org.apache.camel.model.app.BeansDefinition]. Property
> [blueprintBeans] cannot be set as XmlAnyElement, because property
> [springBeans] is already set as XmlAnyElement.
> at
> org.eclipse.persistence.exceptions.JAXBException.xmlAnyElementAlreadySet(JAXBException.java:489)
> at
> org.eclipse.persistence.jaxb.compiler.AnnotationsProcessor.finalizeProperties(AnnotationsProcessor.java:1036)
> at
> org.eclipse.persistence.jaxb.compiler.AnnotationsProcessor.processClassesAndProperties(AnnotationsProcessor.java:309)
> at
> org.eclipse.persistence.jaxb.compiler.Generator.(Generator.java:112)
> at
> org.eclipse.persistence.jaxb.JAXBContext$ContextPathInput.createContextState(JAXBContext.java:991)
> ... 82 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-21515) camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub Publisher
Sateesh Divvela created CAMEL-21515: --- Summary: camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub Publisher Key: CAMEL-21515 URL: https://issues.apache.org/jira/browse/CAMEL-21515 Project: Camel Issue Type: Improvement Components: camel-google-pubsub Affects Versions: 3.14.0 Reporter: Sateesh Divvela Fix For: 3.14.0 The current implementation of the Google Pub/Sub publisher does not allow for customization of retry settings. To address this, we propose adding a new "retry" option to the Google Pub/Sub endpoint that enables users to pass in their own custom RetrySettings instance. This will provide greater flexibility and control over retries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-21515) camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub Publisher
[ https://issues.apache.org/jira/browse/CAMEL-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-21515: Fix Version/s: (was: 3.14.0) > camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub > Publisher > --- > > Key: CAMEL-21515 > URL: https://issues.apache.org/jira/browse/CAMEL-21515 > Project: Camel > Issue Type: Improvement > Components: camel-google-pubsub >Affects Versions: 3.14.0 >Reporter: Sateesh Divvela >Priority: Major > Labels: google, publish, pubsub > > The current implementation of the Google Pub/Sub publisher does not allow for > customization of retry settings. To address this, we propose adding a new > "retry" option to the Google Pub/Sub endpoint that enables users to pass in > their own custom RetrySettings instance. This will provide greater > flexibility and control over retries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-21515) camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub Publisher
[ https://issues.apache.org/jira/browse/CAMEL-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-21515: Priority: Minor (was: Major) > camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub > Publisher > --- > > Key: CAMEL-21515 > URL: https://issues.apache.org/jira/browse/CAMEL-21515 > Project: Camel > Issue Type: Improvement > Components: camel-google-pubsub >Affects Versions: 3.14.0 >Reporter: Sateesh Divvela >Priority: Minor > Labels: google, publish, pubsub > > The current implementation of the Google Pub/Sub publisher does not allow for > customization of retry settings. To address this, we propose adding a new > "retry" option to the Google Pub/Sub endpoint that enables users to pass in > their own custom RetrySettings instance. This will provide greater > flexibility and control over retries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16358) camel-spring-rabbitmq - Configure consumer retry strategies more easily
[ https://issues.apache.org/jira/browse/CAMEL-16358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Divvela updated CAMEL-16358: Attachment: (was: CAMEL-21515.patch) > camel-spring-rabbitmq - Configure consumer retry strategies more easily > --- > > Key: CAMEL-16358 > URL: https://issues.apache.org/jira/browse/CAMEL-16358 > Project: Camel > Issue Type: Improvement > Components: camel-rabbitmq >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.9.0 > > > Currently it will retry forever. > We should add a default that retries X times and then move to DLQ. > And allow to configure a custom strategy via spring-retry via Java code. > See chat > https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/camel-spring-rabbitmq -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-21515) camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub Publisher
[ https://issues.apache.org/jira/browse/CAMEL-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Divvela updated CAMEL-21515: Attachment: CAMEL-21515.patch > camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub > Publisher > --- > > Key: CAMEL-21515 > URL: https://issues.apache.org/jira/browse/CAMEL-21515 > Project: Camel > Issue Type: Improvement > Components: camel-google-pubsub >Affects Versions: 3.14.0 >Reporter: Sateesh Divvela >Priority: Minor > Labels: google, publish, pubsub > Attachments: CAMEL-21515.patch > > > The current implementation of the Google Pub/Sub publisher does not allow for > customization of retry settings. To address this, we propose adding a new > "retry" option to the Google Pub/Sub endpoint that enables users to pass in > their own custom RetrySettings instance. This will provide greater > flexibility and control over retries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-21515) camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub Publisher
[ https://issues.apache.org/jira/browse/CAMEL-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Divvela updated CAMEL-21515: Patch Info: Patch Available > camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub > Publisher > --- > > Key: CAMEL-21515 > URL: https://issues.apache.org/jira/browse/CAMEL-21515 > Project: Camel > Issue Type: Improvement > Components: camel-google-pubsub >Affects Versions: 3.14.0 >Reporter: Sateesh Divvela >Priority: Minor > Labels: google, publish, pubsub > Attachments: CAMEL-21515.patch > > > The current implementation of the Google Pub/Sub publisher does not allow for > customization of retry settings. To address this, we propose adding a new > "retry" option to the Google Pub/Sub endpoint that enables users to pass in > their own custom RetrySettings instance. This will provide greater > flexibility and control over retries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21515) camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub Publisher
[ https://issues.apache.org/jira/browse/CAMEL-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17903107#comment-17903107 ] Sateesh Divvela commented on CAMEL-21515: - [~davsclaus] Thank you for your quick response. After verifying the latest version (4.8.2) of google-pubsub component, I realized that this option is not yet implemented. To address this, I've attached a patch file with the necessary changes. Could you please provide guidance on the earliest version of google-pubsub that this change can be integrated into? > camel-google-pubsub - Add Support for Custom Retry Settings in Google Pub/Sub > Publisher > --- > > Key: CAMEL-21515 > URL: https://issues.apache.org/jira/browse/CAMEL-21515 > Project: Camel > Issue Type: Improvement > Components: camel-google-pubsub >Affects Versions: 3.14.0 >Reporter: Sateesh Divvela >Priority: Minor > Labels: google, publish, pubsub > Attachments: CAMEL-21515.patch > > > The current implementation of the Google Pub/Sub publisher does not allow for > customization of retry settings. To address this, we propose adding a new > "retry" option to the Google Pub/Sub endpoint that enables users to pass in > their own custom RetrySettings instance. This will provide greater > flexibility and control over retries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17902915#comment-17902915
]
Pasquale Congiusti commented on CAMEL-21472:
[~ganteth] no worries. More than removing the feature it would be substituting
it with some alternative and more appropriate mechanisms, eg, the MDC support
provided by Opentelemetry. I am actively working on these issues and I am about
to open a thread on the mailing list to discuss about the possible options we
have in front of us. Keep tuned.
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.3, 4.10.0
>
> Attachments: image-2024-11-26-09-59-35-555.png,
> image-2024-11-29-17-04-16-581.png, image-2024-11-29-17-06-26-116.png,
> image-2024-11-29-17-06-42-860.png, image-2024-11-29-17-12-49-768.png,
> image-2024-11-29-17-12-58-036.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-21486) camel k8s ... cannot push to image-registry.openshift-image-registry.svc:5000
[ https://issues.apache.org/jira/browse/CAMEL-21486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregor Zurowski updated CAMEL-21486: Fix Version/s: 4.10.0 (was: 4.9.0) > camel k8s ... cannot push to image-registry.openshift-image-registry.svc:5000 > - > > Key: CAMEL-21486 > URL: https://issues.apache.org/jira/browse/CAMEL-21486 > Project: Camel > Issue Type: Bug > Components: camel-jbang >Affects Versions: 4.8.1 >Reporter: Andrea Cosentino >Assignee: Thomas Diesler >Priority: Major > Fix For: 4.8.3, 4.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21495) camel-quarkus: REST route inlining works incorrectly when testing
[
https://issues.apache.org/jira/browse/CAMEL-21495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17903207#comment-17903207
]
Sami Peltola commented on CAMEL-21495:
--
[~jamesnetherton]
I've also only encountered this while testing. I haven't yet run the service in
production or or any lower env, it's still a PoC, but while running in
dev-mode, there haven't been any issues.
FYI, it seemed like when I had an actual http endpoint request in the route and
Wiremock mocking it in the tests, the exception seemed to happen more often.
> camel-quarkus: REST route inlining works incorrectly when testing
> -
>
> Key: CAMEL-21495
> URL: https://issues.apache.org/jira/browse/CAMEL-21495
> Project: Camel
> Issue Type: Bug
> Components: camel-rest-openapi
>Affects Versions: 4.8.1
>Reporter: Sami Peltola
>Priority: Minor
> Attachments: quarkus-camel-rest-inline-issue.zip
>
>
> h2. The Issue: REST-route inlining works incorrectly/inconsistently when
> testing
> Encountered when running tests, sometimes the wrong subroute gets inlined to
> the rest-route and causes failures.
> Referring to:
> [https://camel.apache.org/manual/rest-dsl.html#_inline_rest_dsl_as_a_single_route]
> I've attached an example project. When running the tests, a test called
> "FailingTest" should have "camel.rest.inline-routes" enabled and should fail,
> as opposed to "SucceedingTest" which has the option disabled and does not
> fail.
> It seems like when inlining the routes, the subroute "get-from-db-route" gets
> inlined when actually route "quarkuscamelexampleservice-http-get-route"
> should be inlined as it is the subroute that is called from the REST-route.
> For some reason, the tests failing also seems a bit flaky, so you might have
> to run all the tests in a loop to replicate the issue, i've included a script
> "run-test-in-loop.sh".
> When the test fails, it only shows routes:
> {code:java}
> 2024-12-02 10:45:20,687 INFO [org.apa.cam.qua.cor.CamelBootstrapRecorder]
> (main) Apache Camel Quarkus 3.16.0 is starting
> 2024-12-02 10:45:20,687 INFO [org.apa.cam.mai.MainSupport] (main) Apache
> Camel (Main) 4.8.1 is starting
> 2024-12-02 10:45:20,716 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> Auto-configuration summary
> 2024-12-02 10:45:20,716 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> [MicroProfilePropertiesSource] camel.main.dumpRoutes = xml
> 2024-12-02 10:45:20,716 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> [JVM System Property] camel.rest.inlineRoutes = true
> 2024-12-02 10:45:20,882 INFO [org.apa.cam.imp.eng.AbstractCamelContext]
> (main) Apache Camel 4.8.1 (camel-1) is starting
> 2024-12-02 10:45:20,894 INFO [org.apa.cam.imp.DefaultDumpRoutesStrategy]
> (main) Dumping 5 routes as XML
> 2024-12-02 10:45:20,895 INFO [org.apa.cam.imp.DefaultDumpRoutesStrategy]
> (main)
>
>
>
> java.lang.Exception
>
>
> Error with database backend:
> ${exception.message}
>
>
>
>
>
>
> {code}
>
> Sometimes it works correctly, and shows how it actually should have inlined
> the routes with the route "subroute-for-get" not being inlined to the
> REST-route,but instead existing as a separate route in the context:
> {code:java}
> 2024-12-02 10:40:11,095 INFO [org.apa.cam.qua.cor.CamelBootstrapRecorder]
> (main) Apache Camel Quarkus 3.16.0 is starting
> 2024-12-02 10:40:11,096 INFO [org.apa.cam.mai.MainSupport] (main) Apache
> Camel (Main) 4.8.1 is starting
> 2024-12-02 10:40:11,198 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> Auto-configuration summary
> 2024-12-02 10:40:11,198 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> [MicroProfilePropertiesSource] camel.main.dumpRoutes = xml
> 2024-12-02 10:40:11,199 INFO [org.apa.cam.mai.BaseMainSupport] (main)
> [JVM System Property] camel.rest.inlineRoutes = true
> 2024-12-02 10:40:11,857 INFO [org.apa.cam.imp.eng.AbstractCamelContext]
> (main) Apache Camel 4.8.1 (camel-1) is starting
> 2024-12-02 10:40:11,923 INFO [org.apa.cam.imp.DefaultDumpRoutesStrategy]
> (main) Dumping 6 routes as XML
> 2024-12-02 10:40:11,924 INFO [org.apa.cam.imp.DefaultDumpRoutesStrategy]
> (main)
>
>
>
> java.lang.Exception
>
>
> Error with database backend:
> ${exception.message}
>
>
>
>
>
>
>
>
>
> java.lang.Exception
>
>
> Error with http backend: ${exception.message}
>
>
>
>
>
>
