[jira] [Updated] (CAMEL-20564) camel-xslt: Make variables available as xsl:param
[ https://issues.apache.org/jira/browse/CAMEL-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20564: Fix Version/s: 4.5.0 > camel-xslt: Make variables available as xsl:param > - > > Key: CAMEL-20564 > URL: https://issues.apache.org/jira/browse/CAMEL-20564 > Project: Camel > Issue Type: Improvement > Components: camel-xslt >Affects Versions: 4.4.0 >Reporter: Tomohisa Igarashi >Assignee: Tomohisa Igarashi >Priority: Major > Fix For: 4.5.0 > > > Just like we're doing already for exchange properties and message headers, it > would be nice to make variables available as xsl:param for camel-xslt. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20564) camel-xslt: Make variables available as xsl:param
Tomohisa Igarashi created CAMEL-20564: - Summary: camel-xslt: Make variables available as xsl:param Key: CAMEL-20564 URL: https://issues.apache.org/jira/browse/CAMEL-20564 Project: Camel Issue Type: Improvement Components: camel-xslt Affects Versions: 4.4.0 Reporter: Tomohisa Igarashi Assignee: Tomohisa Igarashi Just like we're doing already for exchange properties and message headers, it would be nice to make variables available as xsl:param for camel-xslt. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20561) camel-core - Properties component - Load properties in the same order as given when having multiple locations
[ https://issues.apache.org/jira/browse/CAMEL-20561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20561. - Resolution: Fixed > camel-core - Properties component - Load properties in the same order as > given when having multiple locations > - > > Key: CAMEL-20561 > URL: https://issues.apache.org/jira/browse/CAMEL-20561 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.5.0 > > > If you specify multiple locations such as > application-dev.properties,application.properties > Then we should load dev first, and generic second. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18090) camel-main - Loading properties with profiles for prod/dev/qa
[ https://issues.apache.org/jira/browse/CAMEL-18090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-18090. - Resolution: Fixed > camel-main - Loading properties with profiles for prod/dev/qa > - > > Key: CAMEL-18090 > URL: https://issues.apache.org/jira/browse/CAMEL-18090 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We may want to be able to have properties files that have property key=values > that are specific to profiles, so you can have %dev %prod %qa etc > Quarkus has something similar. > And spring boot have some kind of profile mechanism too. > However from tooling point of view its a bit more difficult as then a > properties file is not just plain key/value pairs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18090) camel-main - Loading properties with profiles for prod/dev/qa
[ https://issues.apache.org/jira/browse/CAMEL-18090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826043#comment-17826043 ] Claus Ibsen edited comment on CAMEL-18090 at 3/13/24 4:00 PM: -- TODO: camel-jbang export should have --profile so you can choose. *DONE* TODO: update camel-jbang docs with profile and naming convention: application-dev application-prod *DONE* TODO: mvn camel:run and camel:dev should support profiles (dev is in dev mode) *DONE* was (Author: davsclaus): TODO: camel-jbang export should have --profile so you can choose. *DONE* TODO: update camel-jbang docs with profile and naming convention: application-dev application-prod *DONE* TODO: mvn camel:run and camel:dev should support profiles (dev is in dev mode) > camel-main - Loading properties with profiles for prod/dev/qa > - > > Key: CAMEL-18090 > URL: https://issues.apache.org/jira/browse/CAMEL-18090 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We may want to be able to have properties files that have property key=values > that are specific to profiles, so you can have %dev %prod %qa etc > Quarkus has something similar. > And spring boot have some kind of profile mechanism too. > However from tooling point of view its a bit more difficult as then a > properties file is not just plain key/value pairs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18090) camel-main - Loading properties with profiles for prod/dev/qa
[ https://issues.apache.org/jira/browse/CAMEL-18090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826043#comment-17826043 ] Claus Ibsen edited comment on CAMEL-18090 at 3/13/24 3:58 PM: -- TODO: camel-jbang export should have --profile so you can choose. *DONE* TODO: update camel-jbang docs with profile and naming convention: application-dev application-prod *DONE* TODO: mvn camel:run and camel:dev should support profiles (dev is in dev mode) was (Author: davsclaus): TODO: camel-jbang export should have --profile so you can choose. *DONE* TODO: update camel-jbang docs with profile and naming convention: application-dev application-prod > camel-main - Loading properties with profiles for prod/dev/qa > - > > Key: CAMEL-18090 > URL: https://issues.apache.org/jira/browse/CAMEL-18090 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We may want to be able to have properties files that have property key=values > that are specific to profiles, so you can have %dev %prod %qa etc > Quarkus has something similar. > And spring boot have some kind of profile mechanism too. > However from tooling point of view its a bit more difficult as then a > properties file is not just plain key/value pairs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19667) camel-tracing: Context is not propagated from exchange header to OpenTelemetry Context
[
https://issues.apache.org/jira/browse/CAMEL-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826415#comment-17826415
]
Davin Taddeo commented on CAMEL-19667:
--
Can confirm that this is still an issue in 4.4.0. Been trying to get the
workaround working but struggling (I'm not a Java person), but can definitely
say that trace context is not properly being maintained. I have a repo to
reproduce this based off the repo linked in
[CAMEL-19469|https://issues.apache.org/jira/browse/CAMEL-19469]:
[camel-kafka-demo-tracing|https://github.com/tdarwin/camel-kafka-demo-tracing].
If you run through that, it will produce 4 traces. One will be the majority of
work, two will be manually spans that _should_ be part of the main trace as
well. Another will be a "pageviews-process" span that I believe should be the
real root of the main trace, but isn't even part of manual instrumentation,
It's just not getting the context... The attached screenshot shows a single
event, where a single message to the kafka topic triggers work by both
services. This should all still land in one trace...
!screenshot-1.png!
> camel-tracing: Context is not propagated from exchange header to
> OpenTelemetry Context
> --
>
> Key: CAMEL-19667
> URL: https://issues.apache.org/jira/browse/CAMEL-19667
> Project: Camel
> Issue Type: Improvement
> Components: camel-opentelemetry, camel-tracing
>Affects Versions: 3.20.5, 3.20.6, 3.21.0, 4.0-M3
>Reporter: Roman Kvasnytskyi
>Priority: Major
> Labels: bug, opentelemetry, tracing
> Fix For: 4.x
>
> Attachments: screenshot-1.png
>
>
> I am using OpenTelemetry Agent for tracing along with
> camel-opentelemetry-starter that configures OpenTelemetryTracer for Camel
> aligned with camel-tracing.
> I see my spans for Camel inside a single trace, but after control is passed
> to the Processor process method next spans are disassociated from the trace
> and are created in the separate trace.
> The tracing context does not seem to get propagated, and the resulting spans
> end up being disassociated. For example:
> {code:java}
> from("timer:tick?period=5s)
> .process("myProcessor");
> {code}
> {code:java}
> public class MyProcessor implements Processor {
> private final HttpClient someClient = new HttpClient();
> @Override
> public void process(Exchange exchange) {
> // http client is instrumented and also produces spans
> someClient.get('/example');
> }
> }
> {code}
> This results in 2 spans. One for timer:tick & another for a client call. The
> problem is that the parent span for client calls is not set, so they appear
> as 2 distinct traces.
> My exchange headers contain traceparent header with all data which should be
> put inside the OpenTelemetry context, but they do not.
> I have come up with a workaround. The idea is trivial - get traceparent
> header if it is present in exchange, parse trace metadata from it, create a
> SpanContext object, and put it as a parent for the current OpenTelemetry
> context.
> It looks like this:
> {code:java}
> public class TraceEnrichingProcessor implements Processor {
> private final Processor delegate;
> public TraceEnrichingProcessor(Processor delegate) {
> this.delegate = delegate;
> }
> @Override
> public void process(Exchange exchange) throws Exception {
> // Get the existing traceparent header from the Exchange
> String traceparent = exchange.getIn().getHeader("traceparent",
> String.class);
> if (traceparent != null && !traceparent.isEmpty()) {
> // Extract the traceId, parentSpanId and sampleFlag
> String[] parts = traceparent.split("-");
> String traceId = parts[1];
> String parentSpanId = parts[2];
> boolean isSampled = parts[3].equals("01");
> // Create the parent SpanContext
> SpanContext parentContext = SpanContext.create(
> traceId,
> parentSpanId,
> isSampled ? TraceFlags.getSampled() : TraceFlags.getDefault(),
> TraceState.getDefault()
> );
> // Attach the parent SpanContext to the current Context
> try (Scope scope =
> Context.current().with(Span.wrap(parentContext)).makeCurrent()) {
> // Now, the current Context has the parent SpanContext
> attached,
> // and any new spans created within this scope will use it as
> their parent
>
> // Pass control to the delegate processor
> delegate.process(exchange);
> }
> } else {
> // If no traceparent header is found, just
[jira] [Updated] (CAMEL-19667) camel-tracing: Context is not propagated from exchange header to OpenTelemetry Context
[
https://issues.apache.org/jira/browse/CAMEL-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davin Taddeo updated CAMEL-19667:
-
Attachment: screenshot-1.png
> camel-tracing: Context is not propagated from exchange header to
> OpenTelemetry Context
> --
>
> Key: CAMEL-19667
> URL: https://issues.apache.org/jira/browse/CAMEL-19667
> Project: Camel
> Issue Type: Improvement
> Components: camel-opentelemetry, camel-tracing
>Affects Versions: 3.20.5, 3.20.6, 3.21.0, 4.0-M3
>Reporter: Roman Kvasnytskyi
>Priority: Major
> Labels: bug, opentelemetry, tracing
> Fix For: 4.x
>
> Attachments: screenshot-1.png
>
>
> I am using OpenTelemetry Agent for tracing along with
> camel-opentelemetry-starter that configures OpenTelemetryTracer for Camel
> aligned with camel-tracing.
> I see my spans for Camel inside a single trace, but after control is passed
> to the Processor process method next spans are disassociated from the trace
> and are created in the separate trace.
> The tracing context does not seem to get propagated, and the resulting spans
> end up being disassociated. For example:
> {code:java}
> from("timer:tick?period=5s)
> .process("myProcessor");
> {code}
> {code:java}
> public class MyProcessor implements Processor {
> private final HttpClient someClient = new HttpClient();
> @Override
> public void process(Exchange exchange) {
> // http client is instrumented and also produces spans
> someClient.get('/example');
> }
> }
> {code}
> This results in 2 spans. One for timer:tick & another for a client call. The
> problem is that the parent span for client calls is not set, so they appear
> as 2 distinct traces.
> My exchange headers contain traceparent header with all data which should be
> put inside the OpenTelemetry context, but they do not.
> I have come up with a workaround. The idea is trivial - get traceparent
> header if it is present in exchange, parse trace metadata from it, create a
> SpanContext object, and put it as a parent for the current OpenTelemetry
> context.
> It looks like this:
> {code:java}
> public class TraceEnrichingProcessor implements Processor {
> private final Processor delegate;
> public TraceEnrichingProcessor(Processor delegate) {
> this.delegate = delegate;
> }
> @Override
> public void process(Exchange exchange) throws Exception {
> // Get the existing traceparent header from the Exchange
> String traceparent = exchange.getIn().getHeader("traceparent",
> String.class);
> if (traceparent != null && !traceparent.isEmpty()) {
> // Extract the traceId, parentSpanId and sampleFlag
> String[] parts = traceparent.split("-");
> String traceId = parts[1];
> String parentSpanId = parts[2];
> boolean isSampled = parts[3].equals("01");
> // Create the parent SpanContext
> SpanContext parentContext = SpanContext.create(
> traceId,
> parentSpanId,
> isSampled ? TraceFlags.getSampled() : TraceFlags.getDefault(),
> TraceState.getDefault()
> );
> // Attach the parent SpanContext to the current Context
> try (Scope scope =
> Context.current().with(Span.wrap(parentContext)).makeCurrent()) {
> // Now, the current Context has the parent SpanContext
> attached,
> // and any new spans created within this scope will use it as
> their parent
>
> // Pass control to the delegate processor
> delegate.process(exchange);
> }
> } else {
> // If no traceparent header is found, just delegate without
> modifying the Context
> delegate.process(exchange);
> }
> }
> } {code}
> Inside OpenTelemetry Agent, they dropped support of Camel 3.x+, because Camel
> provides its module for tracing, and they will not help with it.
> [Link|https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/4052]
> I wonder if that can be done inside Camel to propagate context from the
> processor implicitly without manual propagation of context.
> *UPD1:* I have verified that these behaviour is consistent across Camel
> 3.20.5, 3.20.6, 3.21.0 and 4.0.0-RC1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18090) camel-main - Loading properties with profiles for prod/dev/qa
[ https://issues.apache.org/jira/browse/CAMEL-18090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826043#comment-17826043 ] Claus Ibsen edited comment on CAMEL-18090 at 3/13/24 2:45 PM: -- TODO: camel-jbang export should have --profile so you can choose. *DONE* TODO: update camel-jbang docs with profile and naming convention: application-dev application-prod was (Author: davsclaus): TODO: camel-jbang export should have --profile so you can choose. TODO: update camel-jbang docs with profile and naming convention: application-dev application-prod > camel-main - Loading properties with profiles for prod/dev/qa > - > > Key: CAMEL-18090 > URL: https://issues.apache.org/jira/browse/CAMEL-18090 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We may want to be able to have properties files that have property key=values > that are specific to profiles, so you can have %dev %prod %qa etc > Quarkus has something similar. > And spring boot have some kind of profile mechanism too. > However from tooling point of view its a bit more difficult as then a > properties file is not just plain key/value pairs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20563) breakOnFirstError causes thread and memory leaks in camel-kafka
[ https://issues.apache.org/jira/browse/CAMEL-20563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826077#comment-17826077 ] Claus Ibsen commented on CAMEL-20563: - Try with 4.4.0 and 4.4.1 release (soon) > breakOnFirstError causes thread and memory leaks in camel-kafka > --- > > Key: CAMEL-20563 > URL: https://issues.apache.org/jira/browse/CAMEL-20563 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.5, 3.22.1 >Reporter: Aniket Jadhav >Priority: Major > Attachments: KafkaHeartBeatLeakThread.PNG > > > This has got fixed in > [CAMEL-16857|https://issues.apache.org/jira/browse/CAMEL-16857]. But Facing > same issue with 3.18.5, is it reintroduced at some point? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (CAMEL-20563) breakOnFirstError causes thread and memory leaks in camel-kafka
[ https://issues.apache.org/jira/browse/CAMEL-20563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aniket Jadhav reopened CAMEL-20563: --- Estimated Complexity: (was: Unknown) > breakOnFirstError causes thread and memory leaks in camel-kafka > --- > > Key: CAMEL-20563 > URL: https://issues.apache.org/jira/browse/CAMEL-20563 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.5, 3.22.1 >Reporter: Aniket Jadhav >Priority: Major > Attachments: KafkaHeartBeatLeakThread.PNG > > > This has got fixed in > [CAMEL-16857|https://issues.apache.org/jira/browse/CAMEL-16857]. But Facing > same issue with 3.18.5, is it reintroduced at some point? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20563) breakOnFirstError causes thread and memory leaks in camel-kafka
[ https://issues.apache.org/jira/browse/CAMEL-20563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aniket Jadhav updated CAMEL-20563: -- Affects Version/s: 3.22.1 > breakOnFirstError causes thread and memory leaks in camel-kafka > --- > > Key: CAMEL-20563 > URL: https://issues.apache.org/jira/browse/CAMEL-20563 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.5, 3.22.1 >Reporter: Aniket Jadhav >Priority: Major > Attachments: KafkaHeartBeatLeakThread.PNG > > > This has got fixed in > [CAMEL-16857|https://issues.apache.org/jira/browse/CAMEL-16857]. But Facing > same issue with 3.18.5, is it reintroduced at some point? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20563) breakOnFirstError causes thread and memory leaks in camel-kafka
[ https://issues.apache.org/jira/browse/CAMEL-20563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826066#comment-17826066 ] Aniket Jadhav commented on CAMEL-20563: --- [~davsclaus] facing same issue in 3.22 also > breakOnFirstError causes thread and memory leaks in camel-kafka > --- > > Key: CAMEL-20563 > URL: https://issues.apache.org/jira/browse/CAMEL-20563 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.5 >Reporter: Aniket Jadhav >Priority: Major > Attachments: KafkaHeartBeatLeakThread.PNG > > > This has got fixed in > [CAMEL-16857|https://issues.apache.org/jira/browse/CAMEL-16857]. But Facing > same issue with 3.18.5, is it reintroduced at some point? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20563) breakOnFirstError causes thread and memory leaks in camel-kafka
[ https://issues.apache.org/jira/browse/CAMEL-20563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aniket Jadhav updated CAMEL-20563: -- Attachment: KafkaHeartBeatLeakThread.PNG > breakOnFirstError causes thread and memory leaks in camel-kafka > --- > > Key: CAMEL-20563 > URL: https://issues.apache.org/jira/browse/CAMEL-20563 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.5 >Reporter: Aniket Jadhav >Priority: Major > Attachments: KafkaHeartBeatLeakThread.PNG > > > This has got fixed in > [CAMEL-16857|https://issues.apache.org/jira/browse/CAMEL-16857]. But Facing > same issue with 3.18.5, is it reintroduced at some point? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20563) breakOnFirstError causes thread and memory leaks in camel-kafka
[ https://issues.apache.org/jira/browse/CAMEL-20563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20563. - Resolution: Information Provided Camel 3.18 is EOL and not supported > breakOnFirstError causes thread and memory leaks in camel-kafka > --- > > Key: CAMEL-20563 > URL: https://issues.apache.org/jira/browse/CAMEL-20563 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.5 >Reporter: Aniket Jadhav >Priority: Major > > This has got fixed in > [CAMEL-16857|https://issues.apache.org/jira/browse/CAMEL-16857]. But Facing > same issue with 3.18.5, is it reintroduced at some point? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20563) breakOnFirstError causes thread and memory leaks in camel-kafka
Aniket Jadhav created CAMEL-20563: - Summary: breakOnFirstError causes thread and memory leaks in camel-kafka Key: CAMEL-20563 URL: https://issues.apache.org/jira/browse/CAMEL-20563 Project: Camel Issue Type: Bug Components: camel-kafka Affects Versions: 3.18.5 Reporter: Aniket Jadhav This has got fixed in [CAMEL-16857|https://issues.apache.org/jira/browse/CAMEL-16857]. But Facing same issue with 3.18.5, is it reintroduced at some point? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18090) camel-main - Loading properties with profiles for prod/dev/qa
[ https://issues.apache.org/jira/browse/CAMEL-18090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826043#comment-17826043 ] Claus Ibsen commented on CAMEL-18090: - TODO: camel-jbang export should have --profile so you can choose. > camel-main - Loading properties with profiles for prod/dev/qa > - > > Key: CAMEL-18090 > URL: https://issues.apache.org/jira/browse/CAMEL-18090 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We may want to be able to have properties files that have property key=values > that are specific to profiles, so you can have %dev %prod %qa etc > Quarkus has something similar. > And spring boot have some kind of profile mechanism too. > However from tooling point of view its a bit more difficult as then a > properties file is not just plain key/value pairs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18090) camel-main - Loading properties with profiles for prod/dev/qa
[ https://issues.apache.org/jira/browse/CAMEL-18090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826043#comment-17826043 ] Claus Ibsen edited comment on CAMEL-18090 at 3/13/24 12:52 PM: --- TODO: camel-jbang export should have --profile so you can choose. TODO: update camel-jbang docs with profile and naming convention: application-dev application-prod was (Author: davsclaus): TODO: camel-jbang export should have --profile so you can choose. > camel-main - Loading properties with profiles for prod/dev/qa > - > > Key: CAMEL-18090 > URL: https://issues.apache.org/jira/browse/CAMEL-18090 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We may want to be able to have properties files that have property key=values > that are specific to profiles, so you can have %dev %prod %qa etc > Quarkus has something similar. > And spring boot have some kind of profile mechanism too. > However from tooling point of view its a bit more difficult as then a > properties file is not just plain key/value pairs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20562) Camel-AWS-Bedrock: Support Mistral AI models
Andrea Cosentino created CAMEL-20562: Summary: Camel-AWS-Bedrock: Support Mistral AI models Key: CAMEL-20562 URL: https://issues.apache.org/jira/browse/CAMEL-20562 Project: Camel Issue Type: Sub-task Reporter: Andrea Cosentino Assignee: Andrea Cosentino Fix For: 4.5.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20560) Camel-AWS-Bedrock: Support Anthropic models
[ https://issues.apache.org/jira/browse/CAMEL-20560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-20560. -- Resolution: Fixed > Camel-AWS-Bedrock: Support Anthropic models > --- > > Key: CAMEL-20560 > URL: https://issues.apache.org/jira/browse/CAMEL-20560 > Project: Camel > Issue Type: Sub-task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.5.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (CAMEL-20556) FileConsumer OutOfMemory for big files in Unix
[
https://issues.apache.org/jira/browse/CAMEL-20556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reopened CAMEL-20556:
-
> FileConsumer OutOfMemory for big files in Unix
> --
>
> Key: CAMEL-20556
> URL: https://issues.apache.org/jira/browse/CAMEL-20556
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 3.20.9, 3.22.1
>Reporter: Alexander Anpilov
>Priority: Minor
>
> For clarity, I have tested and described issue with simple routes:
>
> 1. *FileConsumer*
> **
> {code:java}
> from("file:/path")
> .log("Received file: ${file:name}"); {code}
>
>
> 2. *File pollEnrich*
> {code:java}
> from("direct:start")
> .setProperty("SOURCE_URI", simple("{{path_to_folder}}"))
> .pollEnrich().exchangeProperty("SOURCE_URI").timeout(6)
> .log("Received file: ${file:name}"); {code}
> My process receive big files (more than 4x of Java XMX) and running as
> spring-boot app on Kubernetes.
> After upgrading from camel-3.20.2 to camel-3.20.9, the OutOfMemory error
> occurs on consume. I have rolled back and checked with camel-3.20.2 again on
> the same files - everything OK.
> It seems, that FileConsumer publish file content into memory, instead of
> using streams.
> The problem starts from version camel-3.20.3 and reproduced up to 3.20.9.
> *BUT:* I couldn't reproduce problem on Windows with Camel Test, only in Unix
> prod env. Maybe, there are some camel-test effects...
> *UPD:* I have tested camel-3.22.1 and received OutOfMemory
> *UPD*
> With some route modifications:
> {code:java}
> from("amq:start")
> .pollEnrich().simple("{{path_to_folder}}").timeout(5000)
> .log("Received file: ${file:name}"); {code}
> I have collected HeapDump and as I can see, Camel tries to convert file
> content to String
> {code:java}
> at java.lang.OutOfMemoryError.()
> at java.util.Arrays.copyOf()
> local variable: byte[]#206926
> at java.lang.AbstractStringBuilder.ensureCapacityInternal( string 0x0>)
> local variable: java.lang.StringBuilder#70
> at java.lang.AbstractStringBuilder.append()
> local variable: java.lang.StringBuilder#70
> local variable: char[]#3191
> at java.lang.StringBuilder.append()
> local variable: java.lang.StringBuilder#70
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:142)
> local variable: java.io.BufferedReader#1
> local variable: java.lang.StringBuilder#70
> local variable: char[]#3191
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:125)
> local variable: java.io.BufferedReader#1
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:121)
> local variable: java.io.BufferedReader#1
> at
> org.apache.camel.component.file.GenericFileConverter.genericFileToString(GenericFileConverter.java:149)
> local variable: org.apache.camel.component.file.GenericFile#1
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: java.io.BufferedReader#1
> at
> org.apache.camel.component.file.GenericFileConverterLoader.lambda$registerConverters$3(GenericFileConverterLoader.java:52)
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80.doConvert( string 0x0>)
> local variable:
> org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80#1
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
> local variable: class java.lang.String
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.support.SimpleTypeConverter.tryConvertTo(SimpleTypeConverter.java:90)
> at
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:477)
> local variable: org.apache.camel.impl.converter.DefaultTypeConverter#1
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> local variable: org.apache.camel.support.SimpleTypeConverter#26
> at
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:358)
> local variable: org.apache.camel.impl.converter.DefaultTypeConverter#1
> local variable: class java.lang.String
>
[jira] [Resolved] (CAMEL-20556) FileConsumer OutOfMemory for big files in Unix
[
https://issues.apache.org/jira/browse/CAMEL-20556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20556.
-
Resolution: Not A Bug
> FileConsumer OutOfMemory for big files in Unix
> --
>
> Key: CAMEL-20556
> URL: https://issues.apache.org/jira/browse/CAMEL-20556
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 3.20.9, 3.22.1
>Reporter: Alexander Anpilov
>Priority: Minor
>
> For clarity, I have tested and described issue with simple routes:
>
> 1. *FileConsumer*
> **
> {code:java}
> from("file:/path")
> .log("Received file: ${file:name}"); {code}
>
>
> 2. *File pollEnrich*
> {code:java}
> from("direct:start")
> .setProperty("SOURCE_URI", simple("{{path_to_folder}}"))
> .pollEnrich().exchangeProperty("SOURCE_URI").timeout(6)
> .log("Received file: ${file:name}"); {code}
> My process receive big files (more than 4x of Java XMX) and running as
> spring-boot app on Kubernetes.
> After upgrading from camel-3.20.2 to camel-3.20.9, the OutOfMemory error
> occurs on consume. I have rolled back and checked with camel-3.20.2 again on
> the same files - everything OK.
> It seems, that FileConsumer publish file content into memory, instead of
> using streams.
> The problem starts from version camel-3.20.3 and reproduced up to 3.20.9.
> *BUT:* I couldn't reproduce problem on Windows with Camel Test, only in Unix
> prod env. Maybe, there are some camel-test effects...
> *UPD:* I have tested camel-3.22.1 and received OutOfMemory
> *UPD*
> With some route modifications:
> {code:java}
> from("amq:start")
> .pollEnrich().simple("{{path_to_folder}}").timeout(5000)
> .log("Received file: ${file:name}"); {code}
> I have collected HeapDump and as I can see, Camel tries to convert file
> content to String
> {code:java}
> at java.lang.OutOfMemoryError.()
> at java.util.Arrays.copyOf()
> local variable: byte[]#206926
> at java.lang.AbstractStringBuilder.ensureCapacityInternal( string 0x0>)
> local variable: java.lang.StringBuilder#70
> at java.lang.AbstractStringBuilder.append()
> local variable: java.lang.StringBuilder#70
> local variable: char[]#3191
> at java.lang.StringBuilder.append()
> local variable: java.lang.StringBuilder#70
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:142)
> local variable: java.io.BufferedReader#1
> local variable: java.lang.StringBuilder#70
> local variable: char[]#3191
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:125)
> local variable: java.io.BufferedReader#1
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:121)
> local variable: java.io.BufferedReader#1
> at
> org.apache.camel.component.file.GenericFileConverter.genericFileToString(GenericFileConverter.java:149)
> local variable: org.apache.camel.component.file.GenericFile#1
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: java.io.BufferedReader#1
> at
> org.apache.camel.component.file.GenericFileConverterLoader.lambda$registerConverters$3(GenericFileConverterLoader.java:52)
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80.doConvert( string 0x0>)
> local variable:
> org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80#1
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
> local variable: class java.lang.String
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.support.SimpleTypeConverter.tryConvertTo(SimpleTypeConverter.java:90)
> at
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:477)
> local variable: org.apache.camel.impl.converter.DefaultTypeConverter#1
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> local variable: org.apache.camel.support.SimpleTypeConverter#26
> at
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:358)
> local variable: org.apache.camel.impl.converter.DefaultTypeConverter#1
> local variable:
[jira] [Closed] (CAMEL-20556) FileConsumer OutOfMemory for big files in Unix
[
https://issues.apache.org/jira/browse/CAMEL-20556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Anpilov closed CAMEL-20556.
-
Resolution: Fixed
BacklogTracing was tried to log file content.
You should disable tracing or disable tracing file content with properties
> FileConsumer OutOfMemory for big files in Unix
> --
>
> Key: CAMEL-20556
> URL: https://issues.apache.org/jira/browse/CAMEL-20556
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 3.20.9, 3.22.1
>Reporter: Alexander Anpilov
>Priority: Minor
>
> For clarity, I have tested and described issue with simple routes:
>
> 1. *FileConsumer*
> **
> {code:java}
> from("file:/path")
> .log("Received file: ${file:name}"); {code}
>
>
> 2. *File pollEnrich*
> {code:java}
> from("direct:start")
> .setProperty("SOURCE_URI", simple("{{path_to_folder}}"))
> .pollEnrich().exchangeProperty("SOURCE_URI").timeout(6)
> .log("Received file: ${file:name}"); {code}
> My process receive big files (more than 4x of Java XMX) and running as
> spring-boot app on Kubernetes.
> After upgrading from camel-3.20.2 to camel-3.20.9, the OutOfMemory error
> occurs on consume. I have rolled back and checked with camel-3.20.2 again on
> the same files - everything OK.
> It seems, that FileConsumer publish file content into memory, instead of
> using streams.
> The problem starts from version camel-3.20.3 and reproduced up to 3.20.9.
> *BUT:* I couldn't reproduce problem on Windows with Camel Test, only in Unix
> prod env. Maybe, there are some camel-test effects...
> *UPD:* I have tested camel-3.22.1 and received OutOfMemory
> *UPD*
> With some route modifications:
> {code:java}
> from("amq:start")
> .pollEnrich().simple("{{path_to_folder}}").timeout(5000)
> .log("Received file: ${file:name}"); {code}
> I have collected HeapDump and as I can see, Camel tries to convert file
> content to String
> {code:java}
> at java.lang.OutOfMemoryError.()
> at java.util.Arrays.copyOf()
> local variable: byte[]#206926
> at java.lang.AbstractStringBuilder.ensureCapacityInternal( string 0x0>)
> local variable: java.lang.StringBuilder#70
> at java.lang.AbstractStringBuilder.append()
> local variable: java.lang.StringBuilder#70
> local variable: char[]#3191
> at java.lang.StringBuilder.append()
> local variable: java.lang.StringBuilder#70
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:142)
> local variable: java.io.BufferedReader#1
> local variable: java.lang.StringBuilder#70
> local variable: char[]#3191
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:125)
> local variable: java.io.BufferedReader#1
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:121)
> local variable: java.io.BufferedReader#1
> at
> org.apache.camel.component.file.GenericFileConverter.genericFileToString(GenericFileConverter.java:149)
> local variable: org.apache.camel.component.file.GenericFile#1
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: java.io.BufferedReader#1
> at
> org.apache.camel.component.file.GenericFileConverterLoader.lambda$registerConverters$3(GenericFileConverterLoader.java:52)
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80.doConvert( string 0x0>)
> local variable:
> org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80#1
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
> local variable: class java.lang.String
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.support.SimpleTypeConverter.tryConvertTo(SimpleTypeConverter.java:90)
> at
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:477)
> local variable: org.apache.camel.impl.converter.DefaultTypeConverter#1
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> local variable: org.apache.camel.support.SimpleTypeConverter#26
> at
>
[jira] [Created] (CAMEL-20561) camel-core - Properties component - Load properties in the same order as given when having multiple locations
Claus Ibsen created CAMEL-20561: --- Summary: camel-core - Properties component - Load properties in the same order as given when having multiple locations Key: CAMEL-20561 URL: https://issues.apache.org/jira/browse/CAMEL-20561 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 4.5.0 If you specify multiple locations such as application-dev.properties,application.properties Then we should load dev first, and generic second. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20556) FileConsumer OutOfMemory for big files in Unix
[
https://issues.apache.org/jira/browse/CAMEL-20556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826007#comment-17826007
]
Alexander Anpilov commented on CAMEL-20556:
---
[~davsclaus] Thanks!
> FileConsumer OutOfMemory for big files in Unix
> --
>
> Key: CAMEL-20556
> URL: https://issues.apache.org/jira/browse/CAMEL-20556
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 3.20.9, 3.22.1
>Reporter: Alexander Anpilov
>Priority: Minor
>
> For clarity, I have tested and described issue with simple routes:
>
> 1. *FileConsumer*
> **
> {code:java}
> from("file:/path")
> .log("Received file: ${file:name}"); {code}
>
>
> 2. *File pollEnrich*
> {code:java}
> from("direct:start")
> .setProperty("SOURCE_URI", simple("{{path_to_folder}}"))
> .pollEnrich().exchangeProperty("SOURCE_URI").timeout(6)
> .log("Received file: ${file:name}"); {code}
> My process receive big files (more than 4x of Java XMX) and running as
> spring-boot app on Kubernetes.
> After upgrading from camel-3.20.2 to camel-3.20.9, the OutOfMemory error
> occurs on consume. I have rolled back and checked with camel-3.20.2 again on
> the same files - everything OK.
> It seems, that FileConsumer publish file content into memory, instead of
> using streams.
> The problem starts from version camel-3.20.3 and reproduced up to 3.20.9.
> *BUT:* I couldn't reproduce problem on Windows with Camel Test, only in Unix
> prod env. Maybe, there are some camel-test effects...
> *UPD:* I have tested camel-3.22.1 and received OutOfMemory
> *UPD*
> With some route modifications:
> {code:java}
> from("amq:start")
> .pollEnrich().simple("{{path_to_folder}}").timeout(5000)
> .log("Received file: ${file:name}"); {code}
> I have collected HeapDump and as I can see, Camel tries to convert file
> content to String
> {code:java}
> at java.lang.OutOfMemoryError.()
> at java.util.Arrays.copyOf()
> local variable: byte[]#206926
> at java.lang.AbstractStringBuilder.ensureCapacityInternal( string 0x0>)
> local variable: java.lang.StringBuilder#70
> at java.lang.AbstractStringBuilder.append()
> local variable: java.lang.StringBuilder#70
> local variable: char[]#3191
> at java.lang.StringBuilder.append()
> local variable: java.lang.StringBuilder#70
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:142)
> local variable: java.io.BufferedReader#1
> local variable: java.lang.StringBuilder#70
> local variable: char[]#3191
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:125)
> local variable: java.io.BufferedReader#1
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:121)
> local variable: java.io.BufferedReader#1
> at
> org.apache.camel.component.file.GenericFileConverter.genericFileToString(GenericFileConverter.java:149)
> local variable: org.apache.camel.component.file.GenericFile#1
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: java.io.BufferedReader#1
> at
> org.apache.camel.component.file.GenericFileConverterLoader.lambda$registerConverters$3(GenericFileConverterLoader.java:52)
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80.doConvert( string 0x0>)
> local variable:
> org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80#1
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
> local variable: class java.lang.String
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.support.SimpleTypeConverter.tryConvertTo(SimpleTypeConverter.java:90)
> at
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:477)
> local variable: org.apache.camel.impl.converter.DefaultTypeConverter#1
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> local variable: org.apache.camel.support.SimpleTypeConverter#26
> at
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:358)
> local variable:
[jira] [Commented] (CAMEL-20556) FileConsumer OutOfMemory for big files in Unix
[
https://issues.apache.org/jira/browse/CAMEL-20556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826002#comment-17826002
]
Claus Ibsen commented on CAMEL-20556:
-
Ah okay so you have backlog tracing enabled, and that will read the payload
into memory. You need to turn that off. Or configure the backlog tracer to not
include files
> FileConsumer OutOfMemory for big files in Unix
> --
>
> Key: CAMEL-20556
> URL: https://issues.apache.org/jira/browse/CAMEL-20556
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 3.20.9, 3.22.1
>Reporter: Alexander Anpilov
>Priority: Minor
>
> For clarity, I have tested and described issue with simple routes:
>
> 1. *FileConsumer*
> **
> {code:java}
> from("file:/path")
> .log("Received file: ${file:name}"); {code}
>
>
> 2. *File pollEnrich*
> {code:java}
> from("direct:start")
> .setProperty("SOURCE_URI", simple("{{path_to_folder}}"))
> .pollEnrich().exchangeProperty("SOURCE_URI").timeout(6)
> .log("Received file: ${file:name}"); {code}
> My process receive big files (more than 4x of Java XMX) and running as
> spring-boot app on Kubernetes.
> After upgrading from camel-3.20.2 to camel-3.20.9, the OutOfMemory error
> occurs on consume. I have rolled back and checked with camel-3.20.2 again on
> the same files - everything OK.
> It seems, that FileConsumer publish file content into memory, instead of
> using streams.
> The problem starts from version camel-3.20.3 and reproduced up to 3.20.9.
> *BUT:* I couldn't reproduce problem on Windows with Camel Test, only in Unix
> prod env. Maybe, there are some camel-test effects...
> *UPD:* I have tested camel-3.22.1 and received OutOfMemory
> *UPD*
> With some route modifications:
> {code:java}
> from("amq:start")
> .pollEnrich().simple("{{path_to_folder}}").timeout(5000)
> .log("Received file: ${file:name}"); {code}
> I have collected HeapDump and as I can see, Camel tries to convert file
> content to String
> {code:java}
> at java.lang.OutOfMemoryError.()
> at java.util.Arrays.copyOf()
> local variable: byte[]#206926
> at java.lang.AbstractStringBuilder.ensureCapacityInternal( string 0x0>)
> local variable: java.lang.StringBuilder#70
> at java.lang.AbstractStringBuilder.append()
> local variable: java.lang.StringBuilder#70
> local variable: char[]#3191
> at java.lang.StringBuilder.append()
> local variable: java.lang.StringBuilder#70
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:142)
> local variable: java.io.BufferedReader#1
> local variable: java.lang.StringBuilder#70
> local variable: char[]#3191
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:125)
> local variable: java.io.BufferedReader#1
> at org.apache.camel.util.IOHelper.toString(IOHelper.java:121)
> local variable: java.io.BufferedReader#1
> at
> org.apache.camel.component.file.GenericFileConverter.genericFileToString(GenericFileConverter.java:149)
> local variable: org.apache.camel.component.file.GenericFile#1
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: java.io.BufferedReader#1
> at
> org.apache.camel.component.file.GenericFileConverterLoader.lambda$registerConverters$3(GenericFileConverterLoader.java:52)
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80.doConvert( string 0x0>)
> local variable:
> org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80#1
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
> local variable: class java.lang.String
> local variable: org.apache.camel.component.file.GenericFile#1
> at
> org.apache.camel.support.SimpleTypeConverter.tryConvertTo(SimpleTypeConverter.java:90)
> at
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:477)
> local variable: org.apache.camel.impl.converter.DefaultTypeConverter#1
> local variable: class java.lang.String
> local variable: org.apache.camel.support.DefaultExchange#1
> local variable: org.apache.camel.component.file.GenericFile#1
> local variable: org.apache.camel.support.SimpleTypeConverter#26
> at
>
[jira] [Updated] (CAMEL-20556) FileConsumer OutOfMemory for big files in Unix
[
https://issues.apache.org/jira/browse/CAMEL-20556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Anpilov updated CAMEL-20556:
--
Description:
For clarity, I have tested and described issue with simple routes:
1. *FileConsumer*
**
{code:java}
from("file:/path")
.log("Received file: ${file:name}"); {code}
2. *File pollEnrich*
{code:java}
from("direct:start")
.setProperty("SOURCE_URI", simple("{{path_to_folder}}"))
.pollEnrich().exchangeProperty("SOURCE_URI").timeout(6)
.log("Received file: ${file:name}"); {code}
My process receive big files (more than 4x of Java XMX) and running as
spring-boot app on Kubernetes.
After upgrading from camel-3.20.2 to camel-3.20.9, the OutOfMemory error occurs
on consume. I have rolled back and checked with camel-3.20.2 again on the same
files - everything OK.
It seems, that FileConsumer publish file content into memory, instead of using
streams.
The problem starts from version camel-3.20.3 and reproduced up to 3.20.9.
*BUT:* I couldn't reproduce problem on Windows with Camel Test, only in Unix
prod env. Maybe, there are some camel-test effects...
*UPD:* I have tested camel-3.22.1 and received OutOfMemory
*UPD*
With some route modifications:
{code:java}
from("amq:start")
.pollEnrich().simple("{{path_to_folder}}").timeout(5000)
.log("Received file: ${file:name}"); {code}
I have collected HeapDump and as I can see, Camel tries to convert file content
to String
{code:java}
at java.lang.OutOfMemoryError.()
at java.util.Arrays.copyOf()
local variable: byte[]#206926
at java.lang.AbstractStringBuilder.ensureCapacityInternal()
local variable: java.lang.StringBuilder#70
at java.lang.AbstractStringBuilder.append()
local variable: java.lang.StringBuilder#70
local variable: char[]#3191
at java.lang.StringBuilder.append()
local variable: java.lang.StringBuilder#70
at org.apache.camel.util.IOHelper.toString(IOHelper.java:142)
local variable: java.io.BufferedReader#1
local variable: java.lang.StringBuilder#70
local variable: char[]#3191
at org.apache.camel.util.IOHelper.toString(IOHelper.java:125)
local variable: java.io.BufferedReader#1
at org.apache.camel.util.IOHelper.toString(IOHelper.java:121)
local variable: java.io.BufferedReader#1
at
org.apache.camel.component.file.GenericFileConverter.genericFileToString(GenericFileConverter.java:149)
local variable: org.apache.camel.component.file.GenericFile#1
local variable: org.apache.camel.support.DefaultExchange#1
local variable: java.io.BufferedReader#1
at
org.apache.camel.component.file.GenericFileConverterLoader.lambda$registerConverters$3(GenericFileConverterLoader.java:52)
local variable: class java.lang.String
local variable: org.apache.camel.support.DefaultExchange#1
local variable: org.apache.camel.component.file.GenericFile#1
at
org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80.doConvert()
local variable:
org.apache.camel.component.file.GenericFileConverterLoader$$Lambda$1150+0x7f36829dbc80#1
local variable: class java.lang.String
local variable: org.apache.camel.support.DefaultExchange#1
local variable: org.apache.camel.component.file.GenericFile#1
at
org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
local variable: class java.lang.String
local variable: org.apache.camel.component.file.GenericFile#1
at
org.apache.camel.support.SimpleTypeConverter.tryConvertTo(SimpleTypeConverter.java:90)
at
org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:477)
local variable: org.apache.camel.impl.converter.DefaultTypeConverter#1
local variable: class java.lang.String
local variable: org.apache.camel.support.DefaultExchange#1
local variable: org.apache.camel.component.file.GenericFile#1
local variable: org.apache.camel.support.SimpleTypeConverter#26
at
org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:358)
local variable: org.apache.camel.impl.converter.DefaultTypeConverter#1
local variable: class java.lang.String
local variable: org.apache.camel.support.DefaultExchange#1
local variable: org.apache.camel.component.file.GenericFile#1
at
org.apache.camel.impl.converter.CoreTypeConverterRegistry.tryConvertTo(CoreTypeConverterRegistry.java:347)
at
org.apache.camel.support.MessageHelper.extractValueForLogging(MessageHelper.java:386)
local variable: org.apache.camel.component.file.GenericFile#1
local variable: org.apache.camel.component.jms.JmsMessage#1
at
org.apache.camel.support.MessageHelper.extractValueForLogging(MessageHelper.java:316)
[jira] [Updated] (CAMEL-18090) camel-main - Loading properties with profiles for prod/dev/qa
[ https://issues.apache.org/jira/browse/CAMEL-18090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18090: Fix Version/s: 4.5.0 > camel-main - Loading properties with profiles for prod/dev/qa > - > > Key: CAMEL-18090 > URL: https://issues.apache.org/jira/browse/CAMEL-18090 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We may want to be able to have properties files that have property key=values > that are specific to profiles, so you can have %dev %prod %qa etc > Quarkus has something similar. > And spring boot have some kind of profile mechanism too. > However from tooling point of view its a bit more difficult as then a > properties file is not just plain key/value pairs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-18090) camel-main - Loading properties with profiles for prod/dev/qa
[ https://issues.apache.org/jira/browse/CAMEL-18090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-18090: --- Assignee: Claus Ibsen > camel-main - Loading properties with profiles for prod/dev/qa > - > > Key: CAMEL-18090 > URL: https://issues.apache.org/jira/browse/CAMEL-18090 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > > We may want to be able to have properties files that have property key=values > that are specific to profiles, so you can have %dev %prod %qa etc > Quarkus has something similar. > And spring boot have some kind of profile mechanism too. > However from tooling point of view its a bit more difficult as then a > properties file is not just plain key/value pairs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20560) Camel-AWS-Bedrock: Support Anthropic models
Andrea Cosentino created CAMEL-20560: Summary: Camel-AWS-Bedrock: Support Anthropic models Key: CAMEL-20560 URL: https://issues.apache.org/jira/browse/CAMEL-20560 Project: Camel Issue Type: Sub-task Reporter: Andrea Cosentino Assignee: Andrea Cosentino Fix For: 4.5.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20548) catalog: include a capability section to advertise which artifact provides a specific feature
[ https://issues.apache.org/jira/browse/CAMEL-20548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20548 started by Luca Burgazzoli. --- > catalog: include a capability section to advertise which artifact provides a > specific feature > - > > Key: CAMEL-20548 > URL: https://issues.apache.org/jira/browse/CAMEL-20548 > Project: Camel > Issue Type: Improvement > Components: camel-catalog >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > In the camel-k catalog there is a section that maps a capability to a > specific artifact [1] so as example, you can discovery that the a > circuit-breaker implementation is provided by the > camel-quarkus-microprofile-fault-tolerance component/artifact. > It would be nice to have the same in the camel catalog so tooling can > discover what artifacts are required for a specific feature in a runtime > agnosctic way. > This can be part for example of the RuntimeProvider interface so each runtime > can override it with its specific mapping. > [1] > https://github.com/apache/camel-k-runtime/blob/main/support/camel-k-maven-plugin/src/main/java/org/apache/camel/k/tooling/maven/GenerateCatalogMojo.java#L460-L529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20556) FileConsumer OutOfMemory for big files in Unix
[
https://issues.apache.org/jira/browse/CAMEL-20556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825973#comment-17825973
]
Claus Ibsen commented on CAMEL-20556:
-
And to be sure route 1 would also fail for you. And can you paste any
stacktrace / error log you have when OOME. And you can try to reproduce this
outside kubernetes if you have a linux/mac system.
> FileConsumer OutOfMemory for big files in Unix
> --
>
> Key: CAMEL-20556
> URL: https://issues.apache.org/jira/browse/CAMEL-20556
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 3.20.9, 3.22.1
>Reporter: Alexander Anpilov
>Priority: Minor
>
> For clarity, I have tested and described issue with simple routes:
>
> 1. *FileConsumer*
> **
> {code:java}
> from("file:/path")
> .log("Received file: ${file:name}"); {code}
>
>
> 2. *File pollEnrich*
> {code:java}
> from("direct:start")
> .setProperty("SOURCE_URI", simple("{{path_to_folder}}"))
> .pollEnrich().exchangeProperty("SOURCE_URI").timeout(6)
> .log("Received file: ${file:name}"); {code}
> My process receive big files (more than 4x of Java XMX) and running as
> spring-boot app on Kubernetes.
> After upgrading from camel-3.20.2 to camel-3.20.9, the OutOfMemory error
> occurs on consume. I have rolled back and checked with camel-3.20.2 again on
> the same files - everything OK.
> It seems, that FileConsumer publish file content into memory, instead of
> using streams.
> The problem starts from version camel-3.20.3 and reproduced up to 3.20.9.
> *BUT:* I couldn't reproduce problem on Windows with Camel Test, only in Unix
> prod env. Maybe, there are some camel-test effects...
> *UPD:* I have tested camel-3.22.1 and received OutOfMemory
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20550) Universal way to load resources
[
https://issues.apache.org/jira/browse/CAMEL-20550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825971#comment-17825971
]
Claus Ibsen commented on CAMEL-20550:
-
You can also build your own custom resource resolver, and use it
resource:myResolver:blah.xxx?
> Universal way to load resources
> ---
>
> Key: CAMEL-20550
> URL: https://issues.apache.org/jira/browse/CAMEL-20550
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 4.4.0
>Reporter: Raymond
>Priority: Minor
>
> Currently, the way resources are handled is fairly standardized. If a
> component uses a resourceURI then these resources can be loaded from
> classpath, file, http, ref, or bean.
> Still, there are some differences in the way they are loaded:
> 1. Some components allow to load a resource dynamically from *header*
> 2. Some components allow to load a resource as *expression*
> 3. Some have resourceType://path, while others have resource:resourceType:path
> For example:
> 1. Groovy can be loaded as “expression” from a string or from resource like
> this:
> resource:classpath:mygroovy.groovy
> 2. Some components allow resource, but enable by header
> xslt and velocity have resource by default, but also allow to enable to use
> header
> 3. Some only allow resourceUri
> For example jsonata
> ---
> I would like that every component allows:
> 1. Load from expression (string)
> 2. Load from resource (uri)
> 3. Load from metadata (header, property, variable)
> There could be a universal query param "allowDynamicResource". This means it
> can load during runtime (either be updating metadata or by updating resource).
> I also would like an easier registry to handle String resources persistently
> (now I use an external hosting for resource files as classpath/beans/file are
> not dynamic enough):
> context.getRegistry().bind("id","resourceAsString");
> or
> context.setResource("id","resourceAsString");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20559) camel-jbang-plugin-k run command error on a multi-valued trait property
[
https://issues.apache.org/jira/browse/CAMEL-20559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20559:
Priority: Minor (was: Major)
> camel-jbang-plugin-k run command error on a multi-valued trait property
> ---
>
> Key: CAMEL-20559
> URL: https://issues.apache.org/jira/browse/CAMEL-20559
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.4.0
> Environment: Jbang version : 0.114.0
> Camel version: 4.4.0
>Reporter: Gaëlle Fournier
>Priority: Minor
>
> Trying to execute the `run` command with trait property `-t
> toleration.taints=camel.apache.org/master:NoExecute:300` results in the
> following parsing error:
>
> {code:java}
> $ jbang run --deps=org.apache.camel:camel-jbang-plugin-k:4.4.0
> camel@apache/camel k run Test.java -t toleration.enabled=true -t
> toleration.taints=camel.apache.org/master:NoExecute:300
> org.apache.camel.RuntimeCamelException: Failed to parse trait options at
> org.apache.camel.dsl.jbang.core.commands.k.TraitHelper.parseTraits(TraitHelper.java:81)
> at
> org.apache.camel.dsl.jbang.core.commands.k.IntegrationRun.doCall(IntegrationRun.java:237)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:71)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:37)
> at picocli.CommandLine.executeUserObject(CommandLine.java:2041) at
> picocli.CommandLine.access$1500(CommandLine.java:148) at
> picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2453) at
> picocli.CommandLine$RunLast.handle(CommandLine.java:2415) at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
> at picocli.CommandLine$RunLast.execute(CommandLine.java:2417) at
> picocli.CommandLine.execute(CommandLine.java:2170) at
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:151)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:58)
> at main.CamelJBang.main(CamelJBang.java:36) Caused by:
> com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct
> instance of `java.util.ArrayList` (although at least one Creator exists): no
> String-argument constructor/factory method to deserialize from String value
> ('camel.apache.org/master:NoExecute:300') at [Source: REDACTED
> (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column:
> 25] (through reference chain:
> org.apache.camel.v1.integrationspec.Traits["toleration"]->org.apache.camel.v1.integrationspec.traits.Toleration["taints"])
> at
> com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:63)
> at
> com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1754)
> at
> com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1379)
> at
> com.fasterxml.jackson.databind.deser.std.StdDeserializer._deserializeFromString(StdDeserializer.java:311)
> at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.handleNonArray(StringCollectionDeserializer.java:286)
> at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:194)
> at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:184)
> at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:27)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:310)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:310)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:342)
> at
> com.fasterxml.jackson.databind.ObjectReader._bindAndClose(ObjectReader.java:2125)
> at
> com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:1566)
> at
> org.apache.camel.dsl.jbang.core.commands.k.TraitHelper.parseTraits(TraitHelper.java:78)
> ... 14 more
> {code}
>
> The trait
[jira] [Commented] (CAMEL-20540) Add RouteExchangeIn and RouteExchangeOut events
[
https://issues.apache.org/jira/browse/CAMEL-20540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825969#comment-17825969
]
Raymond commented on CAMEL-20540:
-
Thanks I will look into that. For as far I can see, these are my options:
1. Use a step within each route and use EventNotifier
2. Use a custom routePolicicy and set these on scope of specific routes
Both seems to alter the route a bit, but I can make it work.
> Add RouteExchangeIn and RouteExchangeOut events
> ---
>
> Key: CAMEL-20540
> URL: https://issues.apache.org/jira/browse/CAMEL-20540
> Project: Camel
> Issue Type: Wish
>Affects Versions: 4.4.0
>Reporter: Raymond
>Priority: Minor
>
> In my Camel based platform I currently use Camel 3. There, users can add a
> route or kamelet per task.
> Example:
> {code:java}
>
>
> //some task
>
>
>
>
> //some task
>
>
>
>
> //some task
>
> {code}
> I use the Event Notifier to get events to show the message that goes into
> each route. For this the event *ExchangeCreated* is used
> ([https://www.javadoc.io/doc/org.apache.camel/camel-api/latest/org/apache/camel/spi/CamelEvent.html)].
> For each route I get a copy of the message Exchange with the breadcrumbid.
> This works because the routes are connected either through:
> 1. direct-vm
> 2. vm
> 3. activemq
> Now I like to migrate to Camel 4. The issue is that direct-vm and vm aren't
> available anymore since Camel 4.0:
> [https://camel.apache.org/manual/camel-4-migration-guide.html]
> The problem is that a direct endpoint has only 1 ExchangeCreated event over
> multiple routes.
> I wish to have a RouteExchangeIn and RouteExchangeOut CamelEvent, so that I
> can still offer this functionality. The nice thing is that this then would
> work for all endpoints.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20559) camel-jbang-plugin-k run command error on a multi-valued trait property
Gaëlle Fournier created CAMEL-20559:
---
Summary: camel-jbang-plugin-k run command error on a multi-valued
trait property
Key: CAMEL-20559
URL: https://issues.apache.org/jira/browse/CAMEL-20559
Project: Camel
Issue Type: Bug
Components: camel-jbang
Affects Versions: 4.4.0
Environment: Jbang version : 0.114.0
Camel version: 4.4.0'
Reporter: Gaëlle Fournier
Trying to execute the `run` command with trait property `-t
toleration.taints=camel.apache.org/master:NoExecute:300` results in the
following parsing error:
{code:java}
$ jbang run --deps=org.apache.camel:camel-jbang-plugin-k:4.4.0
camel@apache/camel k run Test.java -t toleration.enabled=true -t
toleration.taints=camel.apache.org/master:NoExecute:300
org.apache.camel.RuntimeCamelException: Failed to parse trait options at
org.apache.camel.dsl.jbang.core.commands.k.TraitHelper.parseTraits(TraitHelper.java:81)
at
org.apache.camel.dsl.jbang.core.commands.k.IntegrationRun.doCall(IntegrationRun.java:237)
at
org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:71)
at
org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:37)
at picocli.CommandLine.executeUserObject(CommandLine.java:2041) at
picocli.CommandLine.access$1500(CommandLine.java:148) at
picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2453) at
picocli.CommandLine$RunLast.handle(CommandLine.java:2415) at
picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
at picocli.CommandLine$RunLast.execute(CommandLine.java:2417) at
picocli.CommandLine.execute(CommandLine.java:2170) at
org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:151)
at
org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:58)
at main.CamelJBang.main(CamelJBang.java:36) Caused by:
com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct
instance of `java.util.ArrayList` (although at least one Creator exists): no
String-argument constructor/factory method to deserialize from String value
('camel.apache.org/master:NoExecute:300') at [Source: REDACTED
(`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column: 25]
(through reference chain:
org.apache.camel.v1.integrationspec.Traits["toleration"]->org.apache.camel.v1.integrationspec.traits.Toleration["taints"])
at
com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:63)
at
com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1754)
at
com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1379)
at
com.fasterxml.jackson.databind.deser.std.StdDeserializer._deserializeFromString(StdDeserializer.java:311)
at
com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.handleNonArray(StringCollectionDeserializer.java:286)
at
com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:194)
at
com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:184)
at
com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:27)
at
com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:310)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
at
com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:310)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
at
com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:342)
at
com.fasterxml.jackson.databind.ObjectReader._bindAndClose(ObjectReader.java:2125)
at
com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:1566)
at
org.apache.camel.dsl.jbang.core.commands.k.TraitHelper.parseTraits(TraitHelper.java:78)
... 14 more
{code}
The trait property's type is described in the [Camel K's toleration trait
documentation|https://camel.apache.org/camel-k/next/traits/toleration.html].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20559) camel-jbang-plugin-k run command error on a multi-valued trait property
[
https://issues.apache.org/jira/browse/CAMEL-20559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaëlle Fournier updated CAMEL-20559:
Environment:
Jbang version : 0.114.0
Camel version: 4.4.0
was:
Jbang version : 0.114.0
Camel version: 4.4.0'
> camel-jbang-plugin-k run command error on a multi-valued trait property
> ---
>
> Key: CAMEL-20559
> URL: https://issues.apache.org/jira/browse/CAMEL-20559
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.4.0
> Environment: Jbang version : 0.114.0
> Camel version: 4.4.0
>Reporter: Gaëlle Fournier
>Priority: Major
>
> Trying to execute the `run` command with trait property `-t
> toleration.taints=camel.apache.org/master:NoExecute:300` results in the
> following parsing error:
>
> {code:java}
> $ jbang run --deps=org.apache.camel:camel-jbang-plugin-k:4.4.0
> camel@apache/camel k run Test.java -t toleration.enabled=true -t
> toleration.taints=camel.apache.org/master:NoExecute:300
> org.apache.camel.RuntimeCamelException: Failed to parse trait options at
> org.apache.camel.dsl.jbang.core.commands.k.TraitHelper.parseTraits(TraitHelper.java:81)
> at
> org.apache.camel.dsl.jbang.core.commands.k.IntegrationRun.doCall(IntegrationRun.java:237)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:71)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:37)
> at picocli.CommandLine.executeUserObject(CommandLine.java:2041) at
> picocli.CommandLine.access$1500(CommandLine.java:148) at
> picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2453) at
> picocli.CommandLine$RunLast.handle(CommandLine.java:2415) at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
> at picocli.CommandLine$RunLast.execute(CommandLine.java:2417) at
> picocli.CommandLine.execute(CommandLine.java:2170) at
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:151)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:58)
> at main.CamelJBang.main(CamelJBang.java:36) Caused by:
> com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct
> instance of `java.util.ArrayList` (although at least one Creator exists): no
> String-argument constructor/factory method to deserialize from String value
> ('camel.apache.org/master:NoExecute:300') at [Source: REDACTED
> (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column:
> 25] (through reference chain:
> org.apache.camel.v1.integrationspec.Traits["toleration"]->org.apache.camel.v1.integrationspec.traits.Toleration["taints"])
> at
> com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:63)
> at
> com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1754)
> at
> com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1379)
> at
> com.fasterxml.jackson.databind.deser.std.StdDeserializer._deserializeFromString(StdDeserializer.java:311)
> at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.handleNonArray(StringCollectionDeserializer.java:286)
> at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:194)
> at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:184)
> at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:27)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:310)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:310)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:342)
> at
> com.fasterxml.jackson.databind.ObjectReader._bindAndClose(ObjectReader.java:2125)
> at
> com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:1566)
> at
>
[jira] [Commented] (CAMEL-20550) Universal way to load resources
[
https://issues.apache.org/jira/browse/CAMEL-20550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825957#comment-17825957
]
Raymond commented on CAMEL-20550:
-
Yes, I had an inkling that this would be the outcome. I wanted to give some
feedback anyway, with the points I'm struggling with.
I do have a somewhat different vision on the use of beans. In my idea "beans"
are an anti-pattern in message-orientated middleware. This middleware is about
messages (like xml/json). Sure, Camel has a strong foot in the Java world, and
because it's Java based it tries to make maximum advantage of that. Beans
however hide flow logic and can cause side effects. I'll try to make Camel as
easy available to non-Java programmers, working with YAML or XML, but beans
don't help with that. Just my opinion.
And yes, I also use the resourceHelper to load strings into components or with
routeLoader, but rather want to avoid this step and use a more direct approach.
I may try to create a generic ResourceToVariable processor/bean and see how
that goes.
> Universal way to load resources
> ---
>
> Key: CAMEL-20550
> URL: https://issues.apache.org/jira/browse/CAMEL-20550
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 4.4.0
>Reporter: Raymond
>Priority: Minor
>
> Currently, the way resources are handled is fairly standardized. If a
> component uses a resourceURI then these resources can be loaded from
> classpath, file, http, ref, or bean.
> Still, there are some differences in the way they are loaded:
> 1. Some components allow to load a resource dynamically from *header*
> 2. Some components allow to load a resource as *expression*
> 3. Some have resourceType://path, while others have resource:resourceType:path
> For example:
> 1. Groovy can be loaded as “expression” from a string or from resource like
> this:
> resource:classpath:mygroovy.groovy
> 2. Some components allow resource, but enable by header
> xslt and velocity have resource by default, but also allow to enable to use
> header
> 3. Some only allow resourceUri
> For example jsonata
> ---
> I would like that every component allows:
> 1. Load from expression (string)
> 2. Load from resource (uri)
> 3. Load from metadata (header, property, variable)
> There could be a universal query param "allowDynamicResource". This means it
> can load during runtime (either be updating metadata or by updating resource).
> I also would like an easier registry to handle String resources persistently
> (now I use an external hosting for resource files as classpath/beans/file are
> not dynamic enough):
> context.getRegistry().bind("id","resourceAsString");
> or
> context.setResource("id","resourceAsString");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20558) Ability to use the old Micrometer meter names does not work on MicrometerExchangeEventNotifier
[
https://issues.apache.org/jira/browse/CAMEL-20558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20558.
-
Resolution: Fixed
Thanks for reporting and the patch
> Ability to use the old Micrometer meter names does not work on
> MicrometerExchangeEventNotifier
> --
>
> Key: CAMEL-20558
> URL: https://issues.apache.org/jira/browse/CAMEL-20558
> Project: Camel
> Issue Type: Bug
> Components: camel-micrometer
>Affects Versions: 3.22.1, 4.4.0
>Reporter: Sébastien Perpignane
>Priority: Minor
> Fix For: 3.21.5, 3.22.2, 4.0.5, 4.4.2, 4.5.0
>
> Attachments:
> CAMEL-20558_-_Allow_to_use_legacy_metric_naming_on_MicrometerExchangeEventNotifier.patch
>
>
> Doing this:
> {code:java}
> MicrometerExchangeEventNotifier exchangeEventNotifier = new
> MicrometerExchangeEventNotifier();
> exchangeEventNotifier.setNamingStrategy(MicrometerExchangeEventNotifierNamingStrategy.LEGACY);
> {code}
> does not change the ways metrics produced by the exchangeEventNotifier will
> be named.
>
> Please find attached a proposed patch to fix the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20558) Ability to use the old Micrometer meter names does not work on MicrometerExchangeEventNotifier
[
https://issues.apache.org/jira/browse/CAMEL-20558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20558:
Fix Version/s: 3.21.5
3.22.2
4.0.5
> Ability to use the old Micrometer meter names does not work on
> MicrometerExchangeEventNotifier
> --
>
> Key: CAMEL-20558
> URL: https://issues.apache.org/jira/browse/CAMEL-20558
> Project: Camel
> Issue Type: Bug
> Components: camel-micrometer
>Affects Versions: 3.22.1, 4.4.0
>Reporter: Sébastien Perpignane
>Priority: Minor
> Fix For: 3.21.5, 3.22.2, 4.0.5, 4.4.2, 4.5.0
>
> Attachments:
> CAMEL-20558_-_Allow_to_use_legacy_metric_naming_on_MicrometerExchangeEventNotifier.patch
>
>
> Doing this:
> {code:java}
> MicrometerExchangeEventNotifier exchangeEventNotifier = new
> MicrometerExchangeEventNotifier();
> exchangeEventNotifier.setNamingStrategy(MicrometerExchangeEventNotifierNamingStrategy.LEGACY);
> {code}
> does not change the ways metrics produced by the exchangeEventNotifier will
> be named.
>
> Please find attached a proposed patch to fix the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20558) Ability to use the old Micrometer meter names does not work on MicrometerExchangeEventNotifier
[
https://issues.apache.org/jira/browse/CAMEL-20558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Perpignane updated CAMEL-20558:
-
Attachment:
CAMEL-20558_-_Allow_to_use_legacy_metric_naming_on_MicrometerExchangeEventNotifier.patch
> Ability to use the old Micrometer meter names does not work on
> MicrometerExchangeEventNotifier
> --
>
> Key: CAMEL-20558
> URL: https://issues.apache.org/jira/browse/CAMEL-20558
> Project: Camel
> Issue Type: Bug
> Components: camel-micrometer
>Affects Versions: 3.22.1, 4.4.0
>Reporter: Sébastien Perpignane
>Priority: Minor
> Fix For: 4.4.2, 4.5.0
>
> Attachments:
> CAMEL-20558_-_Allow_to_use_legacy_metric_naming_on_MicrometerExchangeEventNotifier.patch
>
>
> Doing this:
> {code:java}
> MicrometerExchangeEventNotifier exchangeEventNotifier = new
> MicrometerExchangeEventNotifier();
> exchangeEventNotifier.setNamingStrategy(MicrometerExchangeEventNotifierNamingStrategy.LEGACY);
> {code}
> does not change the ways metrics produced by the exchangeEventNotifier will
> be named.
>
> Please find attached a proposed patch to fix the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20558) Ability to use the old Micrometer meter names does not work on MicrometerExchangeEventNotifier
[
https://issues.apache.org/jira/browse/CAMEL-20558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20558:
Fix Version/s: 4.4.2
4.5.0
> Ability to use the old Micrometer meter names does not work on
> MicrometerExchangeEventNotifier
> --
>
> Key: CAMEL-20558
> URL: https://issues.apache.org/jira/browse/CAMEL-20558
> Project: Camel
> Issue Type: Bug
> Components: camel-micrometer
>Affects Versions: 3.22.1, 4.4.0
>Reporter: Sébastien Perpignane
>Priority: Minor
> Fix For: 4.4.2, 4.5.0
>
> Attachments:
> CAMEL-20558_-_Allow_to_use_legacy_metric_naming_on_MicrometerExchangeEventNotifier.patch
>
>
> Doing this:
> {code:java}
> MicrometerExchangeEventNotifier exchangeEventNotifier = new
> MicrometerExchangeEventNotifier();
> exchangeEventNotifier.setNamingStrategy(MicrometerExchangeEventNotifierNamingStrategy.LEGACY);
> {code}
> does not change the ways metrics produced by the exchangeEventNotifier will
> be named.
>
> Please find attached a proposed patch to fix the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20558) Ability to use the old Micrometer meter names does not work on MicrometerExchangeEventNotifier
[
https://issues.apache.org/jira/browse/CAMEL-20558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Perpignane updated CAMEL-20558:
-
Attachment: (was:
CAMEL-20558_-_Allow_to_use_legacy_metric_naming_on_MicrometerExchangeEventNotifier.patch)
> Ability to use the old Micrometer meter names does not work on
> MicrometerExchangeEventNotifier
> --
>
> Key: CAMEL-20558
> URL: https://issues.apache.org/jira/browse/CAMEL-20558
> Project: Camel
> Issue Type: Bug
> Components: camel-micrometer
>Affects Versions: 3.22.1, 4.4.0
>Reporter: Sébastien Perpignane
>Priority: Minor
> Fix For: 4.4.2, 4.5.0
>
> Attachments:
> CAMEL-20558_-_Allow_to_use_legacy_metric_naming_on_MicrometerExchangeEventNotifier.patch
>
>
> Doing this:
> {code:java}
> MicrometerExchangeEventNotifier exchangeEventNotifier = new
> MicrometerExchangeEventNotifier();
> exchangeEventNotifier.setNamingStrategy(MicrometerExchangeEventNotifierNamingStrategy.LEGACY);
> {code}
> does not change the ways metrics produced by the exchangeEventNotifier will
> be named.
>
> Please find attached a proposed patch to fix the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20558) Ability to use the old Micrometer meter names does not work on MicrometerExchangeEventNotifier
[
https://issues.apache.org/jira/browse/CAMEL-20558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Perpignane updated CAMEL-20558:
-
Description:
Doing this:
{code:java}
MicrometerExchangeEventNotifier exchangeEventNotifier = new
MicrometerExchangeEventNotifier();
exchangeEventNotifier.setNamingStrategy(MicrometerExchangeEventNotifierNamingStrategy.LEGACY);
{code}
does not change the ways metrics produced by the exchangeEventNotifier will be
named.
Please find attached a proposed patch to fix the issue.
was:
Doing this:
{code:java}
MicrometerExchangeEventNotifier exchangeEventNotifier = new
MicrometerExchangeEventNotifier();
exchangeEventNotifier.setNamingStrategy(MicrometerExchangeEventNotifierNamingStrategy.LEGACY);
{code}
does not change the ways metrics produced by the exchangeEventNotifier will be
named.
> Ability to use the old Micrometer meter names does not work on
> MicrometerExchangeEventNotifier
> --
>
> Key: CAMEL-20558
> URL: https://issues.apache.org/jira/browse/CAMEL-20558
> Project: Camel
> Issue Type: Bug
> Components: camel-micrometer
>Affects Versions: 3.22.1, 4.4.0
>Reporter: Sébastien Perpignane
>Priority: Minor
> Attachments:
> CAMEL-20558_-_Allow_to_use_legacy_metric_naming_on_MicrometerExchangeEventNotifier.patch
>
>
> Doing this:
> {code:java}
> MicrometerExchangeEventNotifier exchangeEventNotifier = new
> MicrometerExchangeEventNotifier();
> exchangeEventNotifier.setNamingStrategy(MicrometerExchangeEventNotifierNamingStrategy.LEGACY);
> {code}
> does not change the ways metrics produced by the exchangeEventNotifier will
> be named.
>
> Please find attached a proposed patch to fix the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20558) Ability to use the old Micrometer meter names does not work on MicrometerExchangeEventNotifier
[
https://issues.apache.org/jira/browse/CAMEL-20558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Perpignane updated CAMEL-20558:
-
Attachment:
CAMEL-20558_-_Allow_to_use_legacy_metric_naming_on_MicrometerExchangeEventNotifier.patch
> Ability to use the old Micrometer meter names does not work on
> MicrometerExchangeEventNotifier
> --
>
> Key: CAMEL-20558
> URL: https://issues.apache.org/jira/browse/CAMEL-20558
> Project: Camel
> Issue Type: Bug
> Components: camel-micrometer
>Affects Versions: 3.22.1, 4.4.0
>Reporter: Sébastien Perpignane
>Priority: Minor
> Attachments:
> CAMEL-20558_-_Allow_to_use_legacy_metric_naming_on_MicrometerExchangeEventNotifier.patch
>
>
> Doing this:
> {code:java}
> MicrometerExchangeEventNotifier exchangeEventNotifier = new
> MicrometerExchangeEventNotifier();
> exchangeEventNotifier.setNamingStrategy(MicrometerExchangeEventNotifierNamingStrategy.LEGACY);
> {code}
> does not change the ways metrics produced by the exchangeEventNotifier will
> be named.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20558) Ability to use the old Micrometer meter names does not work on MicrometerExchangeEventNotifier
Sébastien Perpignane created CAMEL-20558:
Summary: Ability to use the old Micrometer meter names does not
work on MicrometerExchangeEventNotifier
Key: CAMEL-20558
URL: https://issues.apache.org/jira/browse/CAMEL-20558
Project: Camel
Issue Type: Bug
Components: camel-micrometer
Affects Versions: 4.4.0, 3.22.1
Reporter: Sébastien Perpignane
Doing this:
{code:java}
MicrometerExchangeEventNotifier exchangeEventNotifier = new
MicrometerExchangeEventNotifier();
exchangeEventNotifier.setNamingStrategy(MicrometerExchangeEventNotifierNamingStrategy.LEGACY);
{code}
does not change the ways metrics produced by the exchangeEventNotifier will be
named.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20556) FileConsumer OutOfMemory for big files in Unix
[
https://issues.apache.org/jira/browse/CAMEL-20556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825919#comment-17825919
]
Claus Ibsen commented on CAMEL-20556:
-
If you can debug the code yourself and see what happens. And also check the
code changes between 3.20.2 and 3.20.3 since you say that is where the thing
started to fail for you.
> FileConsumer OutOfMemory for big files in Unix
> --
>
> Key: CAMEL-20556
> URL: https://issues.apache.org/jira/browse/CAMEL-20556
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 3.20.9, 3.22.1
>Reporter: Alexander Anpilov
>Priority: Minor
>
> For clarity, I have tested and described issue with simple routes:
>
> 1. *FileConsumer*
> **
> {code:java}
> from("file:/path")
> .log("Received file: ${file:name}"); {code}
>
>
> 2. *File pollEnrich*
> {code:java}
> from("direct:start")
> .setProperty("SOURCE_URI", simple("{{path_to_folder}}"))
> .pollEnrich().exchangeProperty("SOURCE_URI").timeout(6)
> .log("Received file: ${file:name}"); {code}
> My process receive big files (more than 4x of Java XMX) and running as
> spring-boot app on Kubernetes.
> After upgrading from camel-3.20.2 to camel-3.20.9, the OutOfMemory error
> occurs on consume. I have rolled back and checked with camel-3.20.2 again on
> the same files - everything OK.
> It seems, that FileConsumer publish file content into memory, instead of
> using streams.
> The problem starts from version camel-3.20.3 and reproduced up to 3.20.9.
> *BUT:* I couldn't reproduce problem on Windows with Camel Test, only in Unix
> prod env. Maybe, there are some camel-test effects...
> *UPD:* I have tested camel-3.22.1 and received OutOfMemory
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20550) Universal way to load resources
[
https://issues.apache.org/jira/browse/CAMEL-20550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20550.
-
Resolution: Won't Fix
> Universal way to load resources
> ---
>
> Key: CAMEL-20550
> URL: https://issues.apache.org/jira/browse/CAMEL-20550
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 4.4.0
>Reporter: Raymond
>Priority: Minor
>
> Currently, the way resources are handled is fairly standardized. If a
> component uses a resourceURI then these resources can be loaded from
> classpath, file, http, ref, or bean.
> Still, there are some differences in the way they are loaded:
> 1. Some components allow to load a resource dynamically from *header*
> 2. Some components allow to load a resource as *expression*
> 3. Some have resourceType://path, while others have resource:resourceType:path
> For example:
> 1. Groovy can be loaded as “expression” from a string or from resource like
> this:
> resource:classpath:mygroovy.groovy
> 2. Some components allow resource, but enable by header
> xslt and velocity have resource by default, but also allow to enable to use
> header
> 3. Some only allow resourceUri
> For example jsonata
> ---
> I would like that every component allows:
> 1. Load from expression (string)
> 2. Load from resource (uri)
> 3. Load from metadata (header, property, variable)
> There could be a universal query param "allowDynamicResource". This means it
> can load during runtime (either be updating metadata or by updating resource).
> I also would like an easier registry to handle String resources persistently
> (now I use an external hosting for resource files as classpath/beans/file are
> not dynamic enough):
> context.getRegistry().bind("id","resourceAsString");
> or
> context.setResource("id","resourceAsString");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20540) Add RouteExchangeIn and RouteExchangeOut events
[
https://issues.apache.org/jira/browse/CAMEL-20540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20540.
-
Resolution: Won't Fix
> Add RouteExchangeIn and RouteExchangeOut events
> ---
>
> Key: CAMEL-20540
> URL: https://issues.apache.org/jira/browse/CAMEL-20540
> Project: Camel
> Issue Type: Wish
>Affects Versions: 4.4.0
>Reporter: Raymond
>Priority: Minor
>
> In my Camel based platform I currently use Camel 3. There, users can add a
> route or kamelet per task.
> Example:
> {code:java}
>
>
> //some task
>
>
>
>
> //some task
>
>
>
>
> //some task
>
> {code}
> I use the Event Notifier to get events to show the message that goes into
> each route. For this the event *ExchangeCreated* is used
> ([https://www.javadoc.io/doc/org.apache.camel/camel-api/latest/org/apache/camel/spi/CamelEvent.html)].
> For each route I get a copy of the message Exchange with the breadcrumbid.
> This works because the routes are connected either through:
> 1. direct-vm
> 2. vm
> 3. activemq
> Now I like to migrate to Camel 4. The issue is that direct-vm and vm aren't
> available anymore since Camel 4.0:
> [https://camel.apache.org/manual/camel-4-migration-guide.html]
> The problem is that a direct endpoint has only 1 ExchangeCreated event over
> multiple routes.
> I wish to have a RouteExchangeIn and RouteExchangeOut CamelEvent, so that I
> can still offer this functionality. The nice thing is that this then would
> work for all endpoints.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20540) Add RouteExchangeIn and RouteExchangeOut events
[
https://issues.apache.org/jira/browse/CAMEL-20540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825918#comment-17825918
]
Claus Ibsen commented on CAMEL-20540:
-
RoutePolicy and UnitOfWork also have means of tracking exchange route activity
> Add RouteExchangeIn and RouteExchangeOut events
> ---
>
> Key: CAMEL-20540
> URL: https://issues.apache.org/jira/browse/CAMEL-20540
> Project: Camel
> Issue Type: Wish
>Affects Versions: 4.4.0
>Reporter: Raymond
>Priority: Minor
>
> In my Camel based platform I currently use Camel 3. There, users can add a
> route or kamelet per task.
> Example:
> {code:java}
>
>
> //some task
>
>
>
>
> //some task
>
>
>
>
> //some task
>
> {code}
> I use the Event Notifier to get events to show the message that goes into
> each route. For this the event *ExchangeCreated* is used
> ([https://www.javadoc.io/doc/org.apache.camel/camel-api/latest/org/apache/camel/spi/CamelEvent.html)].
> For each route I get a copy of the message Exchange with the breadcrumbid.
> This works because the routes are connected either through:
> 1. direct-vm
> 2. vm
> 3. activemq
> Now I like to migrate to Camel 4. The issue is that direct-vm and vm aren't
> available anymore since Camel 4.0:
> [https://camel.apache.org/manual/camel-4-migration-guide.html]
> The problem is that a direct endpoint has only 1 ExchangeCreated event over
> multiple routes.
> I wish to have a RouteExchangeIn and RouteExchangeOut CamelEvent, so that I
> can still offer this functionality. The nice thing is that this then would
> work for all endpoints.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20550) Universal way to load resources
[
https://issues.apache.org/jira/browse/CAMEL-20550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825917#comment-17825917
]
Claus Ibsen commented on CAMEL-20550:
-
You cannot make this general. Some components have their own way of loading
because its baked into those libraries.
The resource:xxx syntax can already refer to a bean today (ref).
resource:ref:resourceAsString
And so does many that uses ResourceHelper to load it.
> Universal way to load resources
> ---
>
> Key: CAMEL-20550
> URL: https://issues.apache.org/jira/browse/CAMEL-20550
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 4.4.0
>Reporter: Raymond
>Priority: Minor
>
> Currently, the way resources are handled is fairly standardized. If a
> component uses a resourceURI then these resources can be loaded from
> classpath, file, http, ref, or bean.
> Still, there are some differences in the way they are loaded:
> 1. Some components allow to load a resource dynamically from *header*
> 2. Some components allow to load a resource as *expression*
> 3. Some have resourceType://path, while others have resource:resourceType:path
> For example:
> 1. Groovy can be loaded as “expression” from a string or from resource like
> this:
> resource:classpath:mygroovy.groovy
> 2. Some components allow resource, but enable by header
> xslt and velocity have resource by default, but also allow to enable to use
> header
> 3. Some only allow resourceUri
> For example jsonata
> ---
> I would like that every component allows:
> 1. Load from expression (string)
> 2. Load from resource (uri)
> 3. Load from metadata (header, property, variable)
> There could be a universal query param "allowDynamicResource". This means it
> can load during runtime (either be updating metadata or by updating resource).
> I also would like an easier registry to handle String resources persistently
> (now I use an external hosting for resource files as classpath/beans/file are
> not dynamic enough):
> context.getRegistry().bind("id","resourceAsString");
> or
> context.setResource("id","resourceAsString");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20550) Universal way to load resources
[
https://issues.apache.org/jira/browse/CAMEL-20550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20550:
Priority: Minor (was: Major)
> Universal way to load resources
> ---
>
> Key: CAMEL-20550
> URL: https://issues.apache.org/jira/browse/CAMEL-20550
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 4.4.0
>Reporter: Raymond
>Priority: Minor
>
> Currently, the way resources are handled is fairly standardized. If a
> component uses a resourceURI then these resources can be loaded from
> classpath, file, http, ref, or bean.
> Still, there are some differences in the way they are loaded:
> 1. Some components allow to load a resource dynamically from *header*
> 2. Some components allow to load a resource as *expression*
> 3. Some have resourceType://path, while others have resource:resourceType:path
> For example:
> 1. Groovy can be loaded as “expression” from a string or from resource like
> this:
> resource:classpath:mygroovy.groovy
> 2. Some components allow resource, but enable by header
> xslt and velocity have resource by default, but also allow to enable to use
> header
> 3. Some only allow resourceUri
> For example jsonata
> ---
> I would like that every component allows:
> 1. Load from expression (string)
> 2. Load from resource (uri)
> 3. Load from metadata (header, property, variable)
> There could be a universal query param "allowDynamicResource". This means it
> can load during runtime (either be updating metadata or by updating resource).
> I also would like an easier registry to handle String resources persistently
> (now I use an external hosting for resource files as classpath/beans/file are
> not dynamic enough):
> context.getRegistry().bind("id","resourceAsString");
> or
> context.setResource("id","resourceAsString");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
