[jira] [Updated] (CAMEL-20613) ConcurrentModificationException when a new endpoint is created with toD
[
https://issues.apache.org/jira/browse/CAMEL-20613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20613:
Fix Version/s: 4.6.0
> ConcurrentModificationException when a new endpoint is created with toD
> ---
>
> Key: CAMEL-20613
> URL: https://issues.apache.org/jira/browse/CAMEL-20613
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.22.1, 4.4.1
>Reporter: Bartosz Popiela
>Priority: Major
> Fix For: 4.6.0
>
>
> _java.util.ConcurrentModificationException_ is thrown when a thread modifies
> org.apache.camel.impl.engine.AbstractCamelContext#endpointStrategies e.g.
> while creating an instance of a route template / kamelet with
> _interceptSendToEndpoint_ (see
> org.apache.camel.reifier.InterceptSendToEndpointReifier#createProcessor) and
> another thread iterates over this list. There are several methods that
> iterate over this field (see stacktraces below).
> A possible fix would be to replace ArrayList with a different thread-safe
> collection, but there may be a case where a newly added
> _org.apache.camel.spi.EndpointStrategy_ is not applied to an endpoint that
> was being created in parallel (currently it is also possible). A more robust
> solution would be to synchronise all methods that modify or iterate over the
> list of endpoint strategies in
> org.apache.camel.impl.engine.AbstractCamelContext (fortunately the field is
> private and
> org.apache.camel.impl.engine.AbstractCamelContext#getEndpointStrategies is
> package-private):
> - org.apache.camel.impl.engine.AbstractCamelContext#doGetEndpoint
> - org.apache.camel.impl.engine.AbstractCamelContext#addEndpointToRegistry
> However, it can slow down the startup of and updates to the Camel context. It
> may also introduce new deadlock issues.
> Pull requests with the former fix attached.
> {code:java}
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint:
> kamelet://my-kamelet?someParameter=someValue due to: null
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doGetEndpoint(AbstractCamelContext.java:869)
> at
> org.apache.camel.impl.engine.DefaultCamelContextExtension.getEndpoint(DefaultCamelContextExtension.java:156)
> at
> org.apache.camel.support.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:74)
> at
> org.apache.camel.support.ExchangeHelper.resolveEndpoint(ExchangeHelper.java:115)
> at
> org.apache.camel.support.ExchangeHelper.resolveEndpoint(ExchangeHelper.java:94)
> at
> org.apache.camel.processor.SendDynamicProcessor.resolveEndpoint(SendDynamicProcessor.java:295)
> at
> org.apache.camel.processor.SendDynamicProcessor.process(SendDynamicProcessor.java:156)
> at
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:475)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeReactiveWork(DefaultReactiveExecutor.java:196)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:164)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.schedule(DefaultReactiveExecutor.java:54)
> at
> org.apache.camel.processor.MulticastProcessor.lambda$schedule$1(MulticastProcessor.java:369)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
> at
> java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:317)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1589)
> Caused by: java.util.ConcurrentModificationException: null
> at
> java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1013)
> at java.base/java.util.ArrayList$Itr.next(ArrayList.java:967)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.addEndpointToRegistry(AbstractCamelContext.java:911)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doGetEndpoint(AbstractCamelContext.java:855)
> ... 17 common frames omitted
> {code}
> {code:java}
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint:
> kamelet://my-kamelet?someParameter=someValue to:
> org.apache.camel.component.kamelet.KameletNotFoundException: Kamelet with id
> my-kamelet not found in locations: classpath:/kamelets
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doGetEndpoint(AbstractCamelContext.java:869)
> at
>
[jira] [Updated] (CAMEL-20613) ConcurrentModificationException when a new endpoint is created with toD
[
https://issues.apache.org/jira/browse/CAMEL-20613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20613:
Fix Version/s: 4.4.2
> ConcurrentModificationException when a new endpoint is created with toD
> ---
>
> Key: CAMEL-20613
> URL: https://issues.apache.org/jira/browse/CAMEL-20613
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.22.1, 4.4.1
>Reporter: Bartosz Popiela
>Priority: Major
> Fix For: 4.4.2, 4.6.0
>
>
> _java.util.ConcurrentModificationException_ is thrown when a thread modifies
> org.apache.camel.impl.engine.AbstractCamelContext#endpointStrategies e.g.
> while creating an instance of a route template / kamelet with
> _interceptSendToEndpoint_ (see
> org.apache.camel.reifier.InterceptSendToEndpointReifier#createProcessor) and
> another thread iterates over this list. There are several methods that
> iterate over this field (see stacktraces below).
> A possible fix would be to replace ArrayList with a different thread-safe
> collection, but there may be a case where a newly added
> _org.apache.camel.spi.EndpointStrategy_ is not applied to an endpoint that
> was being created in parallel (currently it is also possible). A more robust
> solution would be to synchronise all methods that modify or iterate over the
> list of endpoint strategies in
> org.apache.camel.impl.engine.AbstractCamelContext (fortunately the field is
> private and
> org.apache.camel.impl.engine.AbstractCamelContext#getEndpointStrategies is
> package-private):
> - org.apache.camel.impl.engine.AbstractCamelContext#doGetEndpoint
> - org.apache.camel.impl.engine.AbstractCamelContext#addEndpointToRegistry
> However, it can slow down the startup of and updates to the Camel context. It
> may also introduce new deadlock issues.
> Pull requests with the former fix attached.
> {code:java}
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint:
> kamelet://my-kamelet?someParameter=someValue due to: null
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doGetEndpoint(AbstractCamelContext.java:869)
> at
> org.apache.camel.impl.engine.DefaultCamelContextExtension.getEndpoint(DefaultCamelContextExtension.java:156)
> at
> org.apache.camel.support.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:74)
> at
> org.apache.camel.support.ExchangeHelper.resolveEndpoint(ExchangeHelper.java:115)
> at
> org.apache.camel.support.ExchangeHelper.resolveEndpoint(ExchangeHelper.java:94)
> at
> org.apache.camel.processor.SendDynamicProcessor.resolveEndpoint(SendDynamicProcessor.java:295)
> at
> org.apache.camel.processor.SendDynamicProcessor.process(SendDynamicProcessor.java:156)
> at
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:475)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeReactiveWork(DefaultReactiveExecutor.java:196)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:164)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.schedule(DefaultReactiveExecutor.java:54)
> at
> org.apache.camel.processor.MulticastProcessor.lambda$schedule$1(MulticastProcessor.java:369)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
> at
> java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:317)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1589)
> Caused by: java.util.ConcurrentModificationException: null
> at
> java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1013)
> at java.base/java.util.ArrayList$Itr.next(ArrayList.java:967)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.addEndpointToRegistry(AbstractCamelContext.java:911)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doGetEndpoint(AbstractCamelContext.java:855)
> ... 17 common frames omitted
> {code}
> {code:java}
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint:
> kamelet://my-kamelet?someParameter=someValue to:
> org.apache.camel.component.kamelet.KameletNotFoundException: Kamelet with id
> my-kamelet not found in locations: classpath:/kamelets
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doGetEndpoint(AbstractCamelContext.java:869)
> at
>
[jira] [Updated] (CAMEL-20614) KameletConsumerNotAvailableException is thrown when two or more threads call toD
[
https://issues.apache.org/jira/browse/CAMEL-20614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20614:
Fix Version/s: 4.4.2
> KameletConsumerNotAvailableException is thrown when two or more threads call
> toD
>
>
> Key: CAMEL-20614
> URL: https://issues.apache.org/jira/browse/CAMEL-20614
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.22.1, 4.4.1
>Reporter: Bartosz Popiela
>Priority: Major
> Fix For: 4.4.2, 4.6.0
>
>
> When two or more threads try to instantiate a route template / kamelet
> parallelly with toD, the following exception is thrown:
> {code:java}
> Thread[#77,Camel (camel-1) thread #15 - Split,5,main]
> org.apache.camel.component.kamelet.KameletConsumerNotAvailableException: No
> consumers available on endpoint:
> kamelet://my-kamelet?someParameter=someValue.
> Exchange[17F2F4997569083-000C]
> at
> org.apache.camel.component.kamelet.KameletProducer.process(KameletProducer.java:78)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:172)
> at
> org.apache.camel.processor.errorhandler.NoErrorHandler.process(NoErrorHandler.java:46)
> at
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:383)
> at
> org.apache.camel.processor.Pipeline$PipelineTask.run(Pipeline.java:102)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeReactiveWork(DefaultReactiveExecutor.java:196)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:164)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.schedule(DefaultReactiveExecutor.java:54)
> at
> org.apache.camel.processor.MulticastProcessor.lambda$schedule$1(MulticastProcessor.java:369)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
> at
> java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:317)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1589)
> {code}
> The sequence of events leading to this exception is as follows:
> 1. Thread A creates an endpoint with
> _org.apache.camel.impl.engine.AbstractCamelContext#doGetEndpoint_
> 2. Thread A initiates the endpoint with
> _org.apache.camel.component.kamelet.KameletEndpoint#doInit_ and sets a key,
> e.g. my-kamelet-1
> 3. Thread A creates a new instance of a route template / kamelet with
> {_}org.apache.camel.impl.DefaultModel#addRouteFromTemplate{_}. This method
> delegates to
> _org.apache.camel.model.RouteTemplateDefinition#asRouteDefinition_ which
> copies RouteDefinition from the template, but {*}it is only a shallow copy
> (not a deep copy){*}, so any referenced fields (e.g. RouteDefinition#input,
> RouteDefinition#outputs) are shared between threads.
> 4. Thread A updates the id of RouteDefinition (routeId=1) and URI-s of
> RouteDefinition#input (kamelet://source?routeId=1) and
> RouteDefinition#outputs (kamelet://sink?routeId=1) (see
> {_}org.apache.camel.component.kamelet.Kamelet#templateToRoute{_}) which is
> also reflected in the template's RouteDefinition.
> 5. Thread B executes steps 1-4 and overwrites the URI-s of in the template's
> RouteDefinition (my-kamelet-2), hence in the shallow-copied RouteDefinition
> referenced by Thread A.
> 6. Thread A instantiates a Consumer for the URI from RouteDefinition#input,
> but because it has been modified by Thread B, it will create a Consumer for
> my-kamelet-2 instead of my-kamelet-1.
> 7. Thread A tries to send an Exchange to the route my-kamelet-1 and creates a
> Producer with the same key (my-kamelet-1). This Producer searches for a
> Consumer with the same key (my-kamelet-1), but it can't find it because in
> the previous step a Consumer with a different key (my-kamelet-2) was created
> and it throws
> {_}org.apache.camel.component.kamelet.KameletConsumerNotAvailableException{_}.
> As a solution _org.apache.camel.component.kamelet.Kamelet#templateToRoute_
> can be synchronised and referenced fields that are modified in this method
> should also be copied.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20614) KameletConsumerNotAvailableException is thrown when two or more threads call toD
[
https://issues.apache.org/jira/browse/CAMEL-20614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20614:
Fix Version/s: 4.6.0
> KameletConsumerNotAvailableException is thrown when two or more threads call
> toD
>
>
> Key: CAMEL-20614
> URL: https://issues.apache.org/jira/browse/CAMEL-20614
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.22.1, 4.4.1
>Reporter: Bartosz Popiela
>Priority: Major
> Fix For: 4.6.0
>
>
> When two or more threads try to instantiate a route template / kamelet
> parallelly with toD, the following exception is thrown:
> {code:java}
> Thread[#77,Camel (camel-1) thread #15 - Split,5,main]
> org.apache.camel.component.kamelet.KameletConsumerNotAvailableException: No
> consumers available on endpoint:
> kamelet://my-kamelet?someParameter=someValue.
> Exchange[17F2F4997569083-000C]
> at
> org.apache.camel.component.kamelet.KameletProducer.process(KameletProducer.java:78)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:172)
> at
> org.apache.camel.processor.errorhandler.NoErrorHandler.process(NoErrorHandler.java:46)
> at
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:383)
> at
> org.apache.camel.processor.Pipeline$PipelineTask.run(Pipeline.java:102)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeReactiveWork(DefaultReactiveExecutor.java:196)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:164)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.schedule(DefaultReactiveExecutor.java:54)
> at
> org.apache.camel.processor.MulticastProcessor.lambda$schedule$1(MulticastProcessor.java:369)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
> at
> java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:317)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1589)
> {code}
> The sequence of events leading to this exception is as follows:
> 1. Thread A creates an endpoint with
> _org.apache.camel.impl.engine.AbstractCamelContext#doGetEndpoint_
> 2. Thread A initiates the endpoint with
> _org.apache.camel.component.kamelet.KameletEndpoint#doInit_ and sets a key,
> e.g. my-kamelet-1
> 3. Thread A creates a new instance of a route template / kamelet with
> {_}org.apache.camel.impl.DefaultModel#addRouteFromTemplate{_}. This method
> delegates to
> _org.apache.camel.model.RouteTemplateDefinition#asRouteDefinition_ which
> copies RouteDefinition from the template, but {*}it is only a shallow copy
> (not a deep copy){*}, so any referenced fields (e.g. RouteDefinition#input,
> RouteDefinition#outputs) are shared between threads.
> 4. Thread A updates the id of RouteDefinition (routeId=1) and URI-s of
> RouteDefinition#input (kamelet://source?routeId=1) and
> RouteDefinition#outputs (kamelet://sink?routeId=1) (see
> {_}org.apache.camel.component.kamelet.Kamelet#templateToRoute{_}) which is
> also reflected in the template's RouteDefinition.
> 5. Thread B executes steps 1-4 and overwrites the URI-s of in the template's
> RouteDefinition (my-kamelet-2), hence in the shallow-copied RouteDefinition
> referenced by Thread A.
> 6. Thread A instantiates a Consumer for the URI from RouteDefinition#input,
> but because it has been modified by Thread B, it will create a Consumer for
> my-kamelet-2 instead of my-kamelet-1.
> 7. Thread A tries to send an Exchange to the route my-kamelet-1 and creates a
> Producer with the same key (my-kamelet-1). This Producer searches for a
> Consumer with the same key (my-kamelet-1), but it can't find it because in
> the previous step a Consumer with a different key (my-kamelet-2) was created
> and it throws
> {_}org.apache.camel.component.kamelet.KameletConsumerNotAvailableException{_}.
> As a solution _org.apache.camel.component.kamelet.Kamelet#templateToRoute_
> can be synchronised and referenced fields that are modified in this method
> should also be copied.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20685) camel-jbang - Debug with doTry .. doCatch .. doFinally should only step actual used
[ https://issues.apache.org/jira/browse/CAMEL-20685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20685: Attachment: Screenshot 2024-04-17 at 16.59.07.png > camel-jbang - Debug with doTry .. doCatch .. doFinally should only step > actual used > --- > > Key: CAMEL-20685 > URL: https://issues.apache.org/jira/browse/CAMEL-20685 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.5.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.x > > Attachments: Screenshot 2024-04-17 at 16.59.07.png > > > In a route that only has > doTry > // stuff > doCatch > // some stuff > And no doFinally will show doCatch / doFinally in the debugger step even if > they are not called when the route completed succesfully. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20685) camel-jbang - Debug with doTry .. doCatch .. doFinally should only step actual used
Claus Ibsen created CAMEL-20685: --- Summary: camel-jbang - Debug with doTry .. doCatch .. doFinally should only step actual used Key: CAMEL-20685 URL: https://issues.apache.org/jira/browse/CAMEL-20685 Project: Camel Issue Type: Improvement Components: camel-jbang Affects Versions: 4.5.0 Reporter: Claus Ibsen Fix For: 4.x Attachments: Screenshot 2024-04-17 at 16.59.07.png In a route that only has doTry // stuff doCatch // some stuff And no doFinally will show doCatch / doFinally in the debugger step even if they are not called when the route completed succesfully. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20685) camel-jbang - Debug with doTry .. doCatch .. doFinally should only step actual used
[ https://issues.apache.org/jira/browse/CAMEL-20685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838239#comment-17838239 ] Claus Ibsen commented on CAMEL-20685: - Was trying this example https://github.com/apache/camel-karavan/issues/1132 > camel-jbang - Debug with doTry .. doCatch .. doFinally should only step > actual used > --- > > Key: CAMEL-20685 > URL: https://issues.apache.org/jira/browse/CAMEL-20685 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.5.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.x > > Attachments: Screenshot 2024-04-17 at 16.59.07.png > > > In a route that only has > doTry > // stuff > doCatch > // some stuff > And no doFinally will show doCatch / doFinally in the debugger step even if > they are not called when the route completed succesfully. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19779) camel-core: investigate externalizing large builtin texts
[ https://issues.apache.org/jira/browse/CAMEL-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838157#comment-17838157 ] Claus Ibsen commented on CAMEL-19779: - Fix merged > camel-core: investigate externalizing large builtin texts > - > > Key: CAMEL-19779 > URL: https://issues.apache.org/jira/browse/CAMEL-19779 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.0.0, 4.1.0 >Reporter: Otavio Rodolfo Piske >Assignee: Guillaume Nodet >Priority: Major > Labels: help-wanted > Fix For: 4.6.0 > > > This is about a comment I raised here: > https://github.com/apache/camel/pull/11181/files#r1302680683 > Long story short, we have lots of places in the code base where we generate > large strings (i.e.: dump stuff to xml, json, java, SQL, etc) and we keep > those strings builtin into the code base. > From a readability and maintainability perspective this is extremely hard to > maintain, debug and read. Ideally, we should investigate a way to externalize > those strings. For some cases, we might need to find a templating solution > that is suitable and acceptable for the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20667) YAML DSL Consistency question - ErrorHandlerDefinition vs ErrorHandlerFactory
[ https://issues.apache.org/jira/browse/CAMEL-20667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20667. - Resolution: Fixed > YAML DSL Consistency question - ErrorHandlerDefinition vs ErrorHandlerFactory > - > > Key: CAMEL-20667 > URL: https://issues.apache.org/jira/browse/CAMEL-20667 > Project: Camel > Issue Type: Improvement > Components: camel-yaml-dsl >Affects Versions: 4.5.0 >Reporter: Marat Gubaidullin >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.6.0 > > > We have > [org.apache.camel.model.ErrorHandlerDefinition|https://github.com/apache/camel/blob/afc1eb789c7c0cb3488f8610afe2aa477b366500/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camelYamlDsl.json#L1461] > and > [org.apache.camel.ErrorHandlerFactory|https://github.com/apache/camel/blob/afc1eb789c7c0cb3488f8610afe2aa477b366500/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camelYamlDsl.json#L210C8-L210C44] > in camelYamlDsl.json > These elements have same properties and used to define error handler. > What is the goal to have similar classes with different names? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19779) camel-core: investigate externalizing large builtin texts
[ https://issues.apache.org/jira/browse/CAMEL-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-19779. - Resolution: Fixed > camel-core: investigate externalizing large builtin texts > - > > Key: CAMEL-19779 > URL: https://issues.apache.org/jira/browse/CAMEL-19779 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.0.0, 4.1.0 >Reporter: Otavio Rodolfo Piske >Assignee: Guillaume Nodet >Priority: Major > Labels: help-wanted > Fix For: 4.6.0 > > > This is about a comment I raised here: > https://github.com/apache/camel/pull/11181/files#r1302680683 > Long story short, we have lots of places in the code base where we generate > large strings (i.e.: dump stuff to xml, json, java, SQL, etc) and we keep > those strings builtin into the code base. > From a readability and maintainability perspective this is extremely hard to > maintain, debug and read. Ideally, we should investigate a way to externalize > those strings. For some cases, we might need to find a templating solution > that is suitable and acceptable for the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (CAMEL-20667) YAML DSL Consistency question - ErrorHandlerDefinition vs ErrorHandlerFactory
[ https://issues.apache.org/jira/browse/CAMEL-20667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reopened CAMEL-20667: - > YAML DSL Consistency question - ErrorHandlerDefinition vs ErrorHandlerFactory > - > > Key: CAMEL-20667 > URL: https://issues.apache.org/jira/browse/CAMEL-20667 > Project: Camel > Issue Type: Improvement > Components: camel-yaml-dsl >Affects Versions: 4.5.0 >Reporter: Marat Gubaidullin >Assignee: Claus Ibsen >Priority: Minor > > We have > [org.apache.camel.model.ErrorHandlerDefinition|https://github.com/apache/camel/blob/afc1eb789c7c0cb3488f8610afe2aa477b366500/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camelYamlDsl.json#L1461] > and > [org.apache.camel.ErrorHandlerFactory|https://github.com/apache/camel/blob/afc1eb789c7c0cb3488f8610afe2aa477b366500/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camelYamlDsl.json#L210C8-L210C44] > in camelYamlDsl.json > These elements have same properties and used to define error handler. > What is the goal to have similar classes with different names? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19779) camel-core: investigate externalizing large builtin texts
[
https://issues.apache.org/jira/browse/CAMEL-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838117#comment-17838117
]
Otavio Rodolfo Piske edited comment on CAMEL-19779 at 4/17/24 11:20 AM:
I was looking at a failure of one of my PRs and, after bisecting it, it it
pointed to this change as being the root cause of the failure. The test in case
is {{{}DumpModelAsXmlNamespaceTest{}}}.
was (Author: orpiske):
I was looking at a failure of one of my PRs and, after bisecting it, it it
pointed to this change as being the root cause of the failure. The test in case
is DumpModelAsXmlNamespaceTest.
> camel-core: investigate externalizing large builtin texts
> -
>
> Key: CAMEL-19779
> URL: https://issues.apache.org/jira/browse/CAMEL-19779
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 4.0.0, 4.1.0
>Reporter: Otavio Rodolfo Piske
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: help-wanted
> Fix For: 4.6.0
>
>
> This is about a comment I raised here:
> https://github.com/apache/camel/pull/11181/files#r1302680683
> Long story short, we have lots of places in the code base where we generate
> large strings (i.e.: dump stuff to xml, json, java, SQL, etc) and we keep
> those strings builtin into the code base.
> From a readability and maintainability perspective this is extremely hard to
> maintain, debug and read. Ideally, we should investigate a way to externalize
> those strings. For some cases, we might need to find a templating solution
> that is suitable and acceptable for the project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19779) camel-core: investigate externalizing large builtin texts
[ https://issues.apache.org/jira/browse/CAMEL-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838122#comment-17838122 ] Claus Ibsen commented on CAMEL-19779: - Yeah I have that too, have a fix at https://github.com/apache/camel/pull/13841 > camel-core: investigate externalizing large builtin texts > - > > Key: CAMEL-19779 > URL: https://issues.apache.org/jira/browse/CAMEL-19779 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.0.0, 4.1.0 >Reporter: Otavio Rodolfo Piske >Assignee: Guillaume Nodet >Priority: Major > Labels: help-wanted > Fix For: 4.6.0 > > > This is about a comment I raised here: > https://github.com/apache/camel/pull/11181/files#r1302680683 > Long story short, we have lots of places in the code base where we generate > large strings (i.e.: dump stuff to xml, json, java, SQL, etc) and we keep > those strings builtin into the code base. > From a readability and maintainability perspective this is extremely hard to > maintain, debug and read. Ideally, we should investigate a way to externalize > those strings. For some cases, we might need to find a templating solution > that is suitable and acceptable for the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19779) camel-core: investigate externalizing large builtin texts
[ https://issues.apache.org/jira/browse/CAMEL-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838117#comment-17838117 ] Otavio Rodolfo Piske commented on CAMEL-19779: -- I was looking at a failure of one of my PRs and, after bisecting it, it it pointed to this change as being the root cause of the failure. The test in case is DumpModelAsXmlNamespaceTest. > camel-core: investigate externalizing large builtin texts > - > > Key: CAMEL-19779 > URL: https://issues.apache.org/jira/browse/CAMEL-19779 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.0.0, 4.1.0 >Reporter: Otavio Rodolfo Piske >Assignee: Guillaume Nodet >Priority: Major > Labels: help-wanted > Fix For: 4.6.0 > > > This is about a comment I raised here: > https://github.com/apache/camel/pull/11181/files#r1302680683 > Long story short, we have lots of places in the code base where we generate > large strings (i.e.: dump stuff to xml, json, java, SQL, etc) and we keep > those strings builtin into the code base. > From a readability and maintainability perspective this is extremely hard to > maintain, debug and read. Ideally, we should investigate a way to externalize > those strings. For some cases, we might need to find a templating solution > that is suitable and acceptable for the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20667) YAML DSL Consistency question - ErrorHandlerDefinition vs ErrorHandlerFactory
[ https://issues.apache.org/jira/browse/CAMEL-20667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20667: Fix Version/s: 4.6.0 > YAML DSL Consistency question - ErrorHandlerDefinition vs ErrorHandlerFactory > - > > Key: CAMEL-20667 > URL: https://issues.apache.org/jira/browse/CAMEL-20667 > Project: Camel > Issue Type: Improvement > Components: camel-yaml-dsl >Affects Versions: 4.5.0 >Reporter: Marat Gubaidullin >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.6.0 > > > We have > [org.apache.camel.model.ErrorHandlerDefinition|https://github.com/apache/camel/blob/afc1eb789c7c0cb3488f8610afe2aa477b366500/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camelYamlDsl.json#L1461] > and > [org.apache.camel.ErrorHandlerFactory|https://github.com/apache/camel/blob/afc1eb789c7c0cb3488f8610afe2aa477b366500/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camelYamlDsl.json#L210C8-L210C44] > in camelYamlDsl.json > These elements have same properties and used to define error handler. > What is the goal to have similar classes with different names? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20667) YAML DSL Consistency question - ErrorHandlerDefinition vs ErrorHandlerFactory
[ https://issues.apache.org/jira/browse/CAMEL-20667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838078#comment-17838078 ] Claus Ibsen commented on CAMEL-20667: - We can maybe take a 2nd look in camel-yaml-dsl to see if we can harmonize this, but since its error handler is a little bit complex > YAML DSL Consistency question - ErrorHandlerDefinition vs ErrorHandlerFactory > - > > Key: CAMEL-20667 > URL: https://issues.apache.org/jira/browse/CAMEL-20667 > Project: Camel > Issue Type: Improvement > Components: camel-yaml-dsl >Affects Versions: 4.5.0 >Reporter: Marat Gubaidullin >Assignee: Claus Ibsen >Priority: Minor > > We have > [org.apache.camel.model.ErrorHandlerDefinition|https://github.com/apache/camel/blob/afc1eb789c7c0cb3488f8610afe2aa477b366500/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camelYamlDsl.json#L1461] > and > [org.apache.camel.ErrorHandlerFactory|https://github.com/apache/camel/blob/afc1eb789c7c0cb3488f8610afe2aa477b366500/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camelYamlDsl.json#L210C8-L210C44] > in camelYamlDsl.json > These elements have same properties and used to define error handler. > What is the goal to have similar classes with different names? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20672) Camel-jbang does not use application.properties when run with --source-dir
[
https://issues.apache.org/jira/browse/CAMEL-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838070#comment-17838070
]
Claus Ibsen commented on CAMEL-20672:
-
okay i found out and have a fix
> Camel-jbang does not use application.properties when run with --source-dir
> --
>
> Key: CAMEL-20672
> URL: https://issues.apache.org/jira/browse/CAMEL-20672
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.5.0
>Reporter: Marat Gubaidullin
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.6.0
>
>
> When run with
> {code}--source-dir{code} option camel-jbang does not use
> {code}application.properties{code} from the source-dir folder,
> so it is not possible to set any properties.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20672) Camel-jbang does not use application.properties when run with --source-dir
[
https://issues.apache.org/jira/browse/CAMEL-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20672.
-
Resolution: Fixed
> Camel-jbang does not use application.properties when run with --source-dir
> --
>
> Key: CAMEL-20672
> URL: https://issues.apache.org/jira/browse/CAMEL-20672
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.5.0
>Reporter: Marat Gubaidullin
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.6.0
>
>
> When run with
> {code}--source-dir{code} option camel-jbang does not use
> {code}application.properties{code} from the source-dir folder,
> so it is not possible to set any properties.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20675) camel-spring-boot: move cluster service implementations to dedicated starters
[ https://issues.apache.org/jira/browse/CAMEL-20675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-20675. - Resolution: Fixed > camel-spring-boot: move cluster service implementations to dedicated starters > - > > Key: CAMEL-20675 > URL: https://issues.apache.org/jira/browse/CAMEL-20675 > Project: Camel > Issue Type: Improvement > Components: camel-spring-boot-starters >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 4.6.0 > > > As today the auto configuration of a Cluster Service implementation is > provided as part of the related component starters, as an example, the > Kubernetes Cluster Service auto configuration is provided by the > camel-kubernetes-startes module and it is an opt in so a user has to explicit > enable it. > However, the goal of starters is usually to enable some behavior by just > adding the starter to the classpath, hence I think it would be nice to move > the Cluster Service auto configuration to dedicated starters and > automatically enable them when the starter is on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20684) camel-microprofile-fault-tolerance: ThreadTimer should be a singleton
James Netherton created CAMEL-20684: --- Summary: camel-microprofile-fault-tolerance: ThreadTimer should be a singleton Key: CAMEL-20684 URL: https://issues.apache.org/jira/browse/CAMEL-20684 Project: Camel Issue Type: Improvement Components: camel-microprofile-fault-tolerance Reporter: James Netherton Fix For: 4.6.0 Something I missed when upgrading SmallRye Fault Tolerance to 6.3.0 is that the use of ThreadTimer requires it to be a singleton. You can't create a multiple instances with a custom executor on each init of FaultToleranceProcessor. [https://github.com/smallrye/smallrye-fault-tolerance/blob/3d92e94269619115062a55f145b6b07eda18452f/implementation/core/src/main/java/io/smallrye/faulttolerance/core/timer/ThreadTimer.java#L67] For Quarkus, there's already a singleton scoped CDI bean containing the ThreadTimer, so we could wire that into the Camel registry and look it up later. Not sure how best to manage it for non-quarkus apps. You'd need to manage the lifecycle of the ThreadTimer & executor on Camel startup / shutdown. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20684) camel-microprofile-fault-tolerance: ThreadTimer should be a singleton
[ https://issues.apache.org/jira/browse/CAMEL-20684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton updated CAMEL-20684: Description: Something I missed when upgrading SmallRye Fault Tolerance to 6.3.0 is that the use of ThreadTimer requires it to be a singleton. You can't create multiple instances with a custom executor on each init of FaultToleranceProcessor. [https://github.com/smallrye/smallrye-fault-tolerance/blob/3d92e94269619115062a55f145b6b07eda18452f/implementation/core/src/main/java/io/smallrye/faulttolerance/core/timer/ThreadTimer.java#L67] For Quarkus, there's already a singleton scoped CDI bean containing the ThreadTimer, so we could wire that into the Camel registry and look it up later. Not sure how best to manage it for non-quarkus apps. You'd need to manage the lifecycle of the ThreadTimer & executor on Camel startup / shutdown. was: Something I missed when upgrading SmallRye Fault Tolerance to 6.3.0 is that the use of ThreadTimer requires it to be a singleton. You can't create a multiple instances with a custom executor on each init of FaultToleranceProcessor. [https://github.com/smallrye/smallrye-fault-tolerance/blob/3d92e94269619115062a55f145b6b07eda18452f/implementation/core/src/main/java/io/smallrye/faulttolerance/core/timer/ThreadTimer.java#L67] For Quarkus, there's already a singleton scoped CDI bean containing the ThreadTimer, so we could wire that into the Camel registry and look it up later. Not sure how best to manage it for non-quarkus apps. You'd need to manage the lifecycle of the ThreadTimer & executor on Camel startup / shutdown. > camel-microprofile-fault-tolerance: ThreadTimer should be a singleton > - > > Key: CAMEL-20684 > URL: https://issues.apache.org/jira/browse/CAMEL-20684 > Project: Camel > Issue Type: Improvement > Components: camel-microprofile-fault-tolerance >Reporter: James Netherton >Priority: Minor > Fix For: 4.6.0 > > > Something I missed when upgrading SmallRye Fault Tolerance to 6.3.0 is that > the use of ThreadTimer requires it to be a singleton. You can't create > multiple instances with a custom executor on each init of > FaultToleranceProcessor. > [https://github.com/smallrye/smallrye-fault-tolerance/blob/3d92e94269619115062a55f145b6b07eda18452f/implementation/core/src/main/java/io/smallrye/faulttolerance/core/timer/ThreadTimer.java#L67] > For Quarkus, there's already a singleton scoped CDI bean containing the > ThreadTimer, so we could wire that into the Camel registry and look it up > later. > Not sure how best to manage it for non-quarkus apps. You'd need to manage the > lifecycle of the ThreadTimer & executor on Camel startup / shutdown. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20672) Camel-jbang does not use application.properties when run with --source-dir
[
https://issues.apache.org/jira/browse/CAMEL-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838009#comment-17838009
]
Claus Ibsen commented on CAMEL-20672:
-
Can you clarify which properties that is not possible to set?
As jbang seems to be loaded the application.properties file, though I have a
hunch that its camel.jbang.xxx properties that you talk about.
> Camel-jbang does not use application.properties when run with --source-dir
> --
>
> Key: CAMEL-20672
> URL: https://issues.apache.org/jira/browse/CAMEL-20672
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.5.0
>Reporter: Marat Gubaidullin
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.6.0
>
>
> When run with
> {code}--source-dir{code} option camel-jbang does not use
> {code}application.properties{code} from the source-dir folder,
> so it is not possible to set any properties.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20672) Camel-jbang does not use application.properties when run with --source-dir
[
https://issues.apache.org/jira/browse/CAMEL-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20672:
Description:
When run with --source-dir option camel-jbang does not use
{{application.properties}} from --source-dir folder,
so it is not possible to set any properties.
was:
When run with {{--source-dir}} option camel-jbang does not use
{{application.properties}} from {{--source-dir}} folder,
so it is not possible to set any properties.
> Camel-jbang does not use application.properties when run with --source-dir
> --
>
> Key: CAMEL-20672
> URL: https://issues.apache.org/jira/browse/CAMEL-20672
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.5.0
>Reporter: Marat Gubaidullin
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.6.0
>
>
> When run with --source-dir option camel-jbang does not use
> {{application.properties}} from --source-dir folder,
> so it is not possible to set any properties.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20669) Camel-jbang export does not work if camel.jbang.metrics=true
[
https://issues.apache.org/jira/browse/CAMEL-20669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20669.
-
Resolution: Fixed
> Camel-jbang export does not work if camel.jbang.metrics=true
>
>
> Key: CAMEL-20669
> URL: https://issues.apache.org/jira/browse/CAMEL-20669
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.5.0
>Reporter: Marat Gubaidullin
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.6.0
>
>
> if *application.properties* contains *camel.jbang.metrics=true*
> then *jbang "-Dcamel.jbang.version=4.5.0" camel@apache/camel export* throws
> {code:java}
> org.apache.camel.NoSuchBeanException: No bean could be found in the registry
> for: platform-http-router of type:
> org.apache.camel.component.platform.http.vertx.VertxPlatformHttpRouter
> at
> org.apache.camel.support.CamelContextHelper.mandatoryLookup(CamelContextHelper.java:249)
> at
> org.apache.camel.component.platform.http.vertx.VertxPlatformHttpRouter.lookup(VertxPlatformHttpRouter.java:290)
> at
> org.apache.camel.component.micrometer.prometheus.MicrometerPrometheus.doStart(MicrometerPrometheus.java:348)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:113)
> at
> org.apache.camel.support.service.ServiceHelper.startService(ServiceHelper.java:126)
> at
> org.apache.camel.impl.engine.DeferServiceStartupListener.doStart(DeferServiceStartupListener.java:63)
> at
> org.apache.camel.impl.engine.DeferServiceStartupListener.onCamelContextStarting(DeferServiceStartupListener.java:49)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartCamel(AbstractCamelContext.java:2775)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartContext(AbstractCamelContext.java:2486)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStart(AbstractCamelContext.java:2441)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:113)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2046)
> at
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:212)
> at org.apache.camel.main.KameletMain.doStart(KameletMain.java:363)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:113)
> at
> org.apache.camel.dsl.jbang.core.commands.Run.runKameletMain(Run.java:1125)
> at org.apache.camel.dsl.jbang.core.commands.Run.run(Run.java:811)
> at
> org.apache.camel.dsl.jbang.core.commands.Run.runSilent(Run.java:311)
> at
> org.apache.camel.dsl.jbang.core.commands.ExportBaseCommand.runSilently(ExportBaseCommand.java:298)
> at
> org.apache.camel.dsl.jbang.core.commands.ExportCamelMain.export(ExportCamelMain.java:67)
> at
> org.apache.camel.dsl.jbang.core.commands.Export.export(Export.java:138)
> at
> org.apache.camel.dsl.jbang.core.commands.Export.export(Export.java:59)
> at
> org.apache.camel.dsl.jbang.core.commands.ExportBaseCommand.doCall(ExportBaseCommand.java:238)
> at
> org.apache.camel.dsl.jbang.core.commands.Export.doCall(Export.java:28)
> 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:164)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:60)
> at main.CamelJBang.main(CamelJBang.java:36)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20672) Camel-jbang does not use application.properties when run with --source-dir
[
https://issues.apache.org/jira/browse/CAMEL-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20672:
Description:
When run with
{code}--source-dir{code} option camel-jbang does not use
{code}application.properties{code} from the source-dir folder,
so it is not possible to set any properties.
was:
When run with --source-dir option camel-jbang does not use
{{application.properties}} from --source-dir folder,
so it is not possible to set any properties.
> Camel-jbang does not use application.properties when run with --source-dir
> --
>
> Key: CAMEL-20672
> URL: https://issues.apache.org/jira/browse/CAMEL-20672
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.5.0
>Reporter: Marat Gubaidullin
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.6.0
>
>
> When run with
> {code}--source-dir{code} option camel-jbang does not use
> {code}application.properties{code} from the source-dir folder,
> so it is not possible to set any properties.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19779) camel-core: investigate externalizing large builtin texts
[ https://issues.apache.org/jira/browse/CAMEL-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838007#comment-17838007 ] Claus Ibsen commented on CAMEL-19779: - Thanks, so the main can build again > camel-core: investigate externalizing large builtin texts > - > > Key: CAMEL-19779 > URL: https://issues.apache.org/jira/browse/CAMEL-19779 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.0.0, 4.1.0 >Reporter: Otavio Rodolfo Piske >Assignee: Guillaume Nodet >Priority: Major > Labels: help-wanted > Fix For: 4.6.0 > > > This is about a comment I raised here: > https://github.com/apache/camel/pull/11181/files#r1302680683 > Long story short, we have lots of places in the code base where we generate > large strings (i.e.: dump stuff to xml, json, java, SQL, etc) and we keep > those strings builtin into the code base. > From a readability and maintainability perspective this is extremely hard to > maintain, debug and read. Ideally, we should investigate a way to externalize > those strings. For some cases, we might need to find a templating solution > that is suitable and acceptable for the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20669) Camel-jbang export does not work if camel.jbang.metrics=true
[
https://issues.apache.org/jira/browse/CAMEL-20669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20669:
Fix Version/s: 4.4.2
> Camel-jbang export does not work if camel.jbang.metrics=true
>
>
> Key: CAMEL-20669
> URL: https://issues.apache.org/jira/browse/CAMEL-20669
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.5.0
>Reporter: Marat Gubaidullin
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.4.2, 4.6.0
>
>
> if *application.properties* contains *camel.jbang.metrics=true*
> then *jbang "-Dcamel.jbang.version=4.5.0" camel@apache/camel export* throws
> {code:java}
> org.apache.camel.NoSuchBeanException: No bean could be found in the registry
> for: platform-http-router of type:
> org.apache.camel.component.platform.http.vertx.VertxPlatformHttpRouter
> at
> org.apache.camel.support.CamelContextHelper.mandatoryLookup(CamelContextHelper.java:249)
> at
> org.apache.camel.component.platform.http.vertx.VertxPlatformHttpRouter.lookup(VertxPlatformHttpRouter.java:290)
> at
> org.apache.camel.component.micrometer.prometheus.MicrometerPrometheus.doStart(MicrometerPrometheus.java:348)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:113)
> at
> org.apache.camel.support.service.ServiceHelper.startService(ServiceHelper.java:126)
> at
> org.apache.camel.impl.engine.DeferServiceStartupListener.doStart(DeferServiceStartupListener.java:63)
> at
> org.apache.camel.impl.engine.DeferServiceStartupListener.onCamelContextStarting(DeferServiceStartupListener.java:49)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartCamel(AbstractCamelContext.java:2775)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartContext(AbstractCamelContext.java:2486)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStart(AbstractCamelContext.java:2441)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:113)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2046)
> at
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:212)
> at org.apache.camel.main.KameletMain.doStart(KameletMain.java:363)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:113)
> at
> org.apache.camel.dsl.jbang.core.commands.Run.runKameletMain(Run.java:1125)
> at org.apache.camel.dsl.jbang.core.commands.Run.run(Run.java:811)
> at
> org.apache.camel.dsl.jbang.core.commands.Run.runSilent(Run.java:311)
> at
> org.apache.camel.dsl.jbang.core.commands.ExportBaseCommand.runSilently(ExportBaseCommand.java:298)
> at
> org.apache.camel.dsl.jbang.core.commands.ExportCamelMain.export(ExportCamelMain.java:67)
> at
> org.apache.camel.dsl.jbang.core.commands.Export.export(Export.java:138)
> at
> org.apache.camel.dsl.jbang.core.commands.Export.export(Export.java:59)
> at
> org.apache.camel.dsl.jbang.core.commands.ExportBaseCommand.doCall(ExportBaseCommand.java:238)
> at
> org.apache.camel.dsl.jbang.core.commands.Export.doCall(Export.java:28)
> 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:164)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:60)
> at main.CamelJBang.main(CamelJBang.java:36)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19779) camel-core: investigate externalizing large builtin texts
[ https://issues.apache.org/jira/browse/CAMEL-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837976#comment-17837976 ] Guillaume Nodet commented on CAMEL-19779: - YEs, last minute refactoring I'll push a fix in a couple of minutes > camel-core: investigate externalizing large builtin texts > - > > Key: CAMEL-19779 > URL: https://issues.apache.org/jira/browse/CAMEL-19779 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.0.0, 4.1.0 >Reporter: Otavio Rodolfo Piske >Assignee: Guillaume Nodet >Priority: Major > Labels: help-wanted > Fix For: 4.6.0 > > > This is about a comment I raised here: > https://github.com/apache/camel/pull/11181/files#r1302680683 > Long story short, we have lots of places in the code base where we generate > large strings (i.e.: dump stuff to xml, json, java, SQL, etc) and we keep > those strings builtin into the code base. > From a readability and maintainability perspective this is extremely hard to > maintain, debug and read. Ideally, we should investigate a way to externalize > those strings. For some cases, we might need to find a templating solution > that is suitable and acceptable for the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
