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