[jira] [Created] (CAMEL-15747) [camel-azure-strorage-blob] Regex is not supported by Consumer
Denis Istomin created CAMEL-15747: - Summary: [camel-azure-strorage-blob] Regex is not supported by Consumer Key: CAMEL-15747 URL: https://issues.apache.org/jira/browse/CAMEL-15747 Project: Camel Issue Type: Bug Components: camel-azure Reporter: Denis Istomin Assignee: Denis Istomin Currently `regex` property supported by Producer only. Support of `regex` needs to be implemented on Consumer side. There is also Disabled integration test that needs to be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (CAMEL-15661) [camel-azure-strorage-blob] Use Testcontainers and Azurite at integration tests
[ https://issues.apache.org/jira/browse/CAMEL-15661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-15661 started by Denis Istomin. - > [camel-azure-strorage-blob] Use Testcontainers and Azurite at integration > tests > --- > > Key: CAMEL-15661 > URL: https://issues.apache.org/jira/browse/CAMEL-15661 > Project: Camel > Issue Type: Improvement > Components: camel-azure >Affects Versions: Future >Reporter: Denis Istomin >Assignee: Denis Istomin >Priority: Major > Fix For: Future > > > Currently there are: > # unit-tests > # integration tests, that runs manually using real cloud azure services > (need to specify `accountName`, `accessKey`) > Proposal: > # Use Testcontainers and Azurite for integration tesing > # Reuse integration tests codebase > # Enable testcontainers integration tests by default > # Do not remove possibilty to run integration tests on cloud azure services > using different maven profile -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15746) json-path - Add support for jsonsurfer for streaming splitting
Claus Ibsen created CAMEL-15746: --- Summary: json-path - Add support for jsonsurfer for streaming splitting Key: CAMEL-15746 URL: https://issues.apache.org/jira/browse/CAMEL-15746 Project: Camel Issue Type: Improvement Components: camel-jsonpath Reporter: Claus Ibsen Fix For: 3.x It would be good to add support for https://github.com/jsurfer/JsonSurfer So we can plug that into camel-jsonpath (and others) and then you can use that in streaming mode, such as splitting big json files (GB sizes). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-15718) Camel lumberjack server component not thread safe
[ https://issues.apache.org/jira/browse/CAMEL-15718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zineb BENDHIBA reassigned CAMEL-15718: -- Assignee: Zineb BENDHIBA > Camel lumberjack server component not thread safe > - > > Key: CAMEL-15718 > URL: https://issues.apache.org/jira/browse/CAMEL-15718 > Project: Camel > Issue Type: Bug >Affects Versions: 3.5.0, 3.6.0 > Environment: camel 3.5.0, filebeat 7.9.1, jdk 1.8.0_242, Debian 10, > Linux 4.19.0-6-amd64 >Reporter: Erik Zimmermann >Assignee: Zineb BENDHIBA >Priority: Major > > I am new to camel. I use a filebeat source that delivers logfile data over > the lumberjack v2 batch protocol. As a receiving server I use the camel > lumberjack component to further process the data in a camel pipeline. > I realized that the LumberjackSessionHandler of camels lumberjack component > is not stateless but is being used by camel for all parallel lumberjack > connection requests. Thus, new incoming connections with their own batch > windows mess up any ongoing process of the already existing window, e.g. > window size settings and counting acknowledges. > Many different combinations of multicast().parallelProcessing().threads(...) > with filebeats workers/pipelines showed the same result. > The states of the stateful LumberjackSessionHandler are mixed up and the > handling of parallel windows is broken which results in unwanted/unfinished > acknowledges. As a result it hangs up the whole communication process to the > filebeat source. > The LumberjackSessionHandler is not able to handle multiple threads, but > camel uses it as it would be able to. > How can I tell camel to use separate LumberjackSessionHandlers and processing > pipelines for each lumberjack batch request? Or do I misunderstand the > concept of how camel uses components? > Sorry, I wasn't able to find a more specific "camel-lumberjack" component in > the list of issue proposals above so I selected camel-core... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15718) Camel lumberjack server component not thread safe
[ https://issues.apache.org/jira/browse/CAMEL-15718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219660#comment-17219660 ] Zineb BENDHIBA commented on CAMEL-15718: Thanks [~bedla] for the analyse. I'll work on this issue !! > Camel lumberjack server component not thread safe > - > > Key: CAMEL-15718 > URL: https://issues.apache.org/jira/browse/CAMEL-15718 > Project: Camel > Issue Type: Bug >Affects Versions: 3.5.0, 3.6.0 > Environment: camel 3.5.0, filebeat 7.9.1, jdk 1.8.0_242, Debian 10, > Linux 4.19.0-6-amd64 >Reporter: Erik Zimmermann >Priority: Major > > I am new to camel. I use a filebeat source that delivers logfile data over > the lumberjack v2 batch protocol. As a receiving server I use the camel > lumberjack component to further process the data in a camel pipeline. > I realized that the LumberjackSessionHandler of camels lumberjack component > is not stateless but is being used by camel for all parallel lumberjack > connection requests. Thus, new incoming connections with their own batch > windows mess up any ongoing process of the already existing window, e.g. > window size settings and counting acknowledges. > Many different combinations of multicast().parallelProcessing().threads(...) > with filebeats workers/pipelines showed the same result. > The states of the stateful LumberjackSessionHandler are mixed up and the > handling of parallel windows is broken which results in unwanted/unfinished > acknowledges. As a result it hangs up the whole communication process to the > filebeat source. > The LumberjackSessionHandler is not able to handle multiple threads, but > camel uses it as it would be able to. > How can I tell camel to use separate LumberjackSessionHandlers and processing > pipelines for each lumberjack batch request? Or do I misunderstand the > concept of how camel uses components? > Sorry, I wasn't able to find a more specific "camel-lumberjack" component in > the list of issue proposals above so I selected camel-core... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-15732) camel-core - Untangle reifier from impl and builder
[ https://issues.apache.org/jira/browse/CAMEL-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15732. - Resolution: Fixed > camel-core - Untangle reifier from impl and builder > --- > > Key: CAMEL-15732 > URL: https://issues.apache.org/jira/browse/CAMEL-15732 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.7.0 > > > We should untangle reifiers some more from using builder and impl directly, > so we can get further ahead of being able to seperate reifier and model from > camel-core-engine - eg eventually maybe so you can have those at built time, > and then at runtime they can be removed / not needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-15732) camel-core - Untangle reifier from impl and builder
[ https://issues.apache.org/jira/browse/CAMEL-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219583#comment-17219583 ] Claus Ibsen edited comment on CAMEL-15732 at 10/23/20, 12:08 PM: - lookupErrorHandlerFactory in ErrorHandlerReifier to be moved out of reifier *DONE* was (Author: davsclaus): lookupErrorHandlerFactory in ErrorHandlerReifier to be moved out of reifier > camel-core - Untangle reifier from impl and builder > --- > > Key: CAMEL-15732 > URL: https://issues.apache.org/jira/browse/CAMEL-15732 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.7.0 > > > We should untangle reifiers some more from using builder and impl directly, > so we can get further ahead of being able to seperate reifier and model from > camel-core-engine - eg eventually maybe so you can have those at built time, > and then at runtime they can be removed / not needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15740) camel-core - camel-core-builder
[ https://issues.apache.org/jira/browse/CAMEL-15740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219635#comment-17219635 ] Claus Ibsen commented on CAMEL-15740: - At first we are moving the reifiers out as they are now seperated. camel-base <- camel-core-reifier camel-base<- camel-core-engine camel-core-reifier <- camel-core-engine > camel-core - camel-core-builder > --- > > Key: CAMEL-15740 > URL: https://issues.apache.org/jira/browse/CAMEL-15740 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.7.0 > > > We can move the model and builder into its own module so we help keep a > cleaner api and separate concerns. > Then we have > camel-base -> camel-core-builder -> camel-core-engine > The reifier is a mix that sits between builder and engine to build the actual > processors, ideally we may move them into camel-core-builder if that becomes > possible, as then we can get to a point where we can dead code eliminate this > entire JAR when you have built routes from the builder/model and then at > runtime its just the engine. But that is more to untangle to get there. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-15732) camel-core - Untangle reifier from impl and builder
[ https://issues.apache.org/jira/browse/CAMEL-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218868#comment-17218868 ] Claus Ibsen edited comment on CAMEL-15732 at 10/23/20, 11:22 AM: - error handlers *DONE* and route *DONE* are the remainder now. was (Author: davsclaus): error handlers and route *DONE* are the remainder now. > camel-core - Untangle reifier from impl and builder > --- > > Key: CAMEL-15732 > URL: https://issues.apache.org/jira/browse/CAMEL-15732 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.7.0 > > > We should untangle reifiers some more from using builder and impl directly, > so we can get further ahead of being able to seperate reifier and model from > camel-core-engine - eg eventually maybe so you can have those at built time, > and then at runtime they can be removed / not needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15745) Rest DSL input/output type class
Ioannis Sarantidis created CAMEL-15745: -- Summary: Rest DSL input/output type class Key: CAMEL-15745 URL: https://issues.apache.org/jira/browse/CAMEL-15745 Project: Camel Issue Type: Improvement Components: rest Affects Versions: 3.6.0 Reporter: Ioannis Sarantidis Currently RestDefinition methods: * _type(Class classType)_ * _outType(Class classType)_ use the methods _setType, setOutType_ from _VerbDefinition_ that accept a string instead of their variants that accept the class or should at least use both variants if they are really needed. The reason for opening this that setting the class name only in verb definition, in my OSGI application, causes ClassNotFoundException in _RestBindingReifier#setupJson_. As a workaround at the moment, after configuring the RestDefinition object I retrieve the VerbDefinitions in it and set the _typeClass_ and _outTypeClass_ manually there. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15732) camel-core - Untangle reifier from impl and builder
[ https://issues.apache.org/jira/browse/CAMEL-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219583#comment-17219583 ] Claus Ibsen commented on CAMEL-15732: - lookupErrorHandlerFactory in ErrorHandlerReifier to be moved out of reifier > camel-core - Untangle reifier from impl and builder > --- > > Key: CAMEL-15732 > URL: https://issues.apache.org/jira/browse/CAMEL-15732 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.7.0 > > > We should untangle reifiers some more from using builder and impl directly, > so we can get further ahead of being able to seperate reifier and model from > camel-core-engine - eg eventually maybe so you can have those at built time, > and then at runtime they can be removed / not needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15744) camel-micrometer: add ability to get micrometer metrics from Kafka Client
Stefan Stus created CAMEL-15744: --- Summary: camel-micrometer: add ability to get micrometer metrics from Kafka Client Key: CAMEL-15744 URL: https://issues.apache.org/jira/browse/CAMEL-15744 Project: Camel Issue Type: New Feature Components: camel-kafka, camel-micrometer Reporter: Stefan Stus In Mirometer introduces an ability to get technical metrics from Kafka's consumers and producers. It seems to be production-ready since 1.5.4 based on our production experience and available since 1.4.0. See: [Micrometer implementation|https://github.com/micrometer-metrics/micrometer/blob/master/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/kafka/KafkaClientMetrics.java] I tried to add a custom implementation to my project to extract those metrics from Camel. I found out that I'm unable to do it for the Kafka Consumer since the actual Kafka Consumer hides [deeply inside|https://github.com/apache/camel/blob/master/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaConsumer.java#L174-L176] KafkaConsumer Camel class. At the same time, I'm able to get KafkaProducer from Camel class [here. |https://github.com/apache/camel/blob/master/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaProducer.java#L83] *Desired Solution:* Add additional CamelKafkaMicrometerRoutePolicy to extract Kafka technical metrics. Add the ability to inject CamelKafkaMicrometerRoutePolicy into Consumer and Producer components. Will this feature be welcomed in Camel? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-15635) Some Kudu tests are failing in JDK >= 12 builds
[ https://issues.apache.org/jira/browse/CAMEL-15635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Dettinger reassigned CAMEL-15635: -- Assignee: Alex Dettinger > Some Kudu tests are failing in JDK >= 12 builds > --- > > Key: CAMEL-15635 > URL: https://issues.apache.org/jira/browse/CAMEL-15635 > Project: Camel > Issue Type: Test > Components: camel-kudu >Affects Versions: 3.6.0 >Reporter: Alex Dettinger >Assignee: Alex Dettinger >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15743) camel 2.x - SendProcessor has not been started when another route is stopped
[
https://issues.apache.org/jira/browse/CAMEL-15743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219545#comment-17219545
]
Claus Ibsen commented on CAMEL-15743:
-
Camel 2.x is not really active maintained. I suggest to move to Camel 3.x if
you can, or find a workaround for your use case.
For any chance of us fixing this you should build a sample application as a
reproducer or some unit test etc. The more you can help us the better.
> camel 2.x - SendProcessor has not been started when another route is stopped
>
>
> Key: CAMEL-15743
> URL: https://issues.apache.org/jira/browse/CAMEL-15743
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 2.25.2
>Reporter: wupenghuai
>Priority: Minor
>
> I used DeadLetterChannelBuilder as ErrorHandlerBuilder. I specify the bean
> named onExceptionProcessor as deadLetterChannel. I expect the bean to handle
> exceptions when route error.
> But when I stop any route, the ErrorHandler for the other route will fail.
> The exception stack is as follows:
>
> {code:java}
> java.lang.IllegalStateException: SendProcessor has not been started:
> sendTo(bean://onExceptionProcessor)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:121)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.FatalFallbackErrorHandler.process(FatalFallbackErrorHandler.java:82)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.deliverToFailureProcessor(RedeliveryErrorHandler.java:1063)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:474)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> ~[camel-core-2.25.2.jar:2.25.2]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
> ~[camel-core-2.25.2.jar:2.25.2]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelContinuationServlet.doService(CamelContinuationServlet.java:220)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:79)
> ~[camel-http-common-2.25.2.jar:2.25.2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ~[javax.servlet-api-3.1.0.jar:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:51)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:51)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>
[jira] [Updated] (CAMEL-15743) camel 2.x - SendProcessor has not been started when another route is stopped
[
https://issues.apache.org/jira/browse/CAMEL-15743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-15743:
Summary: camel 2.x - SendProcessor has not been started when another route
is stopped (was: camel-core - SendProcessor has not been started)
> camel 2.x - SendProcessor has not been started when another route is stopped
>
>
> Key: CAMEL-15743
> URL: https://issues.apache.org/jira/browse/CAMEL-15743
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 2.25.2
>Reporter: wupenghuai
>Priority: Minor
> Fix For: 2.25.3
>
>
> I used DeadLetterChannelBuilder as ErrorHandlerBuilder. I specify the bean
> named onExceptionProcessor as deadLetterChannel. I expect the bean to handle
> exceptions when route error.
> But when I stop any route, the ErrorHandler for the other route will fail.
> The exception stack is as follows:
>
> {code:java}
> java.lang.IllegalStateException: SendProcessor has not been started:
> sendTo(bean://onExceptionProcessor)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:121)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.FatalFallbackErrorHandler.process(FatalFallbackErrorHandler.java:82)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.deliverToFailureProcessor(RedeliveryErrorHandler.java:1063)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:474)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> ~[camel-core-2.25.2.jar:2.25.2]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
> ~[camel-core-2.25.2.jar:2.25.2]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelContinuationServlet.doService(CamelContinuationServlet.java:220)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:79)
> ~[camel-http-common-2.25.2.jar:2.25.2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ~[javax.servlet-api-3.1.0.jar:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:51)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:51)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>
[jira] [Updated] (CAMEL-15743) camel 2.x - SendProcessor has not been started when another route is stopped
[
https://issues.apache.org/jira/browse/CAMEL-15743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-15743:
Fix Version/s: (was: 2.25.3)
> camel 2.x - SendProcessor has not been started when another route is stopped
>
>
> Key: CAMEL-15743
> URL: https://issues.apache.org/jira/browse/CAMEL-15743
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 2.25.2
>Reporter: wupenghuai
>Priority: Minor
>
> I used DeadLetterChannelBuilder as ErrorHandlerBuilder. I specify the bean
> named onExceptionProcessor as deadLetterChannel. I expect the bean to handle
> exceptions when route error.
> But when I stop any route, the ErrorHandler for the other route will fail.
> The exception stack is as follows:
>
> {code:java}
> java.lang.IllegalStateException: SendProcessor has not been started:
> sendTo(bean://onExceptionProcessor)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:121)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.FatalFallbackErrorHandler.process(FatalFallbackErrorHandler.java:82)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.deliverToFailureProcessor(RedeliveryErrorHandler.java:1063)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:474)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> ~[camel-core-2.25.2.jar:2.25.2]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
> ~[camel-core-2.25.2.jar:2.25.2]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelContinuationServlet.doService(CamelContinuationServlet.java:220)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:79)
> ~[camel-http-common-2.25.2.jar:2.25.2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ~[javax.servlet-api-3.1.0.jar:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:51)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:51)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>
[jira] [Updated] (CAMEL-15743) camel-core - SendProcessor has not been started
[
https://issues.apache.org/jira/browse/CAMEL-15743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-15743:
Priority: Minor (was: Major)
> camel-core - SendProcessor has not been started
> ---
>
> Key: CAMEL-15743
> URL: https://issues.apache.org/jira/browse/CAMEL-15743
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 2.25.2
>Reporter: wupenghuai
>Priority: Minor
> Fix For: 2.25.3
>
>
> I used DeadLetterChannelBuilder as ErrorHandlerBuilder. I specify the bean
> named onExceptionProcessor as deadLetterChannel. I expect the bean to handle
> exceptions when route error.
> But when I stop any route, the ErrorHandler for the other route will fail.
> The exception stack is as follows:
>
> {code:java}
> java.lang.IllegalStateException: SendProcessor has not been started:
> sendTo(bean://onExceptionProcessor)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:121)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.FatalFallbackErrorHandler.process(FatalFallbackErrorHandler.java:82)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.deliverToFailureProcessor(RedeliveryErrorHandler.java:1063)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:474)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> ~[camel-core-2.25.2.jar:2.25.2]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
> ~[camel-core-2.25.2.jar:2.25.2]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> ~[camel-core-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelContinuationServlet.doService(CamelContinuationServlet.java:220)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:79)
> ~[camel-http-common-2.25.2.jar:2.25.2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ~[javax.servlet-api-3.1.0.jar:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:51)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:51)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
> ~[camel-jetty-common-2.25.2.jar:2.25.2]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> ~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
> ~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>
[jira] [Created] (CAMEL-15743) camel-core - SendProcessor has not been started
wupenghuai created CAMEL-15743:
--
Summary: camel-core - SendProcessor has not been started
Key: CAMEL-15743
URL: https://issues.apache.org/jira/browse/CAMEL-15743
Project: Camel
Issue Type: Bug
Components: came-core
Affects Versions: 2.25.2
Reporter: wupenghuai
Fix For: 2.25.3
I used DeadLetterChannelBuilder as ErrorHandlerBuilder. I specify the bean
named onExceptionProcessor as deadLetterChannel. I expect the bean to handle
exceptions when route error.
But when I stop any route, the ErrorHandler for the other route will fail. The
exception stack is as follows:
{code:java}
java.lang.IllegalStateException: SendProcessor has not been started:
sendTo(bean://onExceptionProcessor)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:121)
~[camel-core-2.25.2.jar:2.25.2]
at
org.apache.camel.processor.FatalFallbackErrorHandler.process(FatalFallbackErrorHandler.java:82)
~[camel-core-2.25.2.jar:2.25.2]
at
org.apache.camel.processor.RedeliveryErrorHandler.deliverToFailureProcessor(RedeliveryErrorHandler.java:1063)
~[camel-core-2.25.2.jar:2.25.2]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:474)
~[camel-core-2.25.2.jar:2.25.2]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
~[camel-core-2.25.2.jar:2.25.2]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
~[camel-core-2.25.2.jar:2.25.2]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
~[camel-core-2.25.2.jar:2.25.2]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
~[camel-core-2.25.2.jar:2.25.2]
at
org.apache.camel.component.jetty.CamelContinuationServlet.doService(CamelContinuationServlet.java:220)
~[camel-jetty-common-2.25.2.jar:2.25.2]
at
org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:79)
~[camel-http-common-2.25.2.jar:2.25.2]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
~[javax.servlet-api-3.1.0.jar:3.1.0]
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873)
~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623)
~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:51)
~[camel-jetty-common-2.25.2.jar:2.25.2]
at
org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
~[camel-jetty-common-2.25.2.jar:2.25.2]
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:51)
~[camel-jetty-common-2.25.2.jar:2.25.2]
at
org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
~[camel-jetty-common-2.25.2.jar:2.25.2]
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
~[jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
at org.eclipse.jetty.server.Server.handle(Server.java:505)
~[jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
[jira] [Comment Edited] (CAMEL-15732) camel-core - Untangle reifier from impl and builder
[ https://issues.apache.org/jira/browse/CAMEL-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218868#comment-17218868 ] Claus Ibsen edited comment on CAMEL-15732 at 10/23/20, 7:33 AM: error handlers and route *DONE* are the remainder now. was (Author: davsclaus): error handlers and route are the remainder now. > camel-core - Untangle reifier from impl and builder > --- > > Key: CAMEL-15732 > URL: https://issues.apache.org/jira/browse/CAMEL-15732 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.7.0 > > > We should untangle reifiers some more from using builder and impl directly, > so we can get further ahead of being able to seperate reifier and model from > camel-core-engine - eg eventually maybe so you can have those at built time, > and then at runtime they can be removed / not needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-15732) camel-core - Untangle reifier from impl and builder
[ https://issues.apache.org/jira/browse/CAMEL-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219053#comment-17219053 ] Claus Ibsen edited comment on CAMEL-15732 at 10/23/20, 7:33 AM: It would be good to move adviceWith away from RouteReifier so we can have it another place as Reifier should not really be exposed to end users *DONE* was (Author: davsclaus): It would be good to move adviceWith away from RouteReifier so we can have it another place as Reifier should not really be exposed to end users > camel-core - Untangle reifier from impl and builder > --- > > Key: CAMEL-15732 > URL: https://issues.apache.org/jira/browse/CAMEL-15732 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.7.0 > > > We should untangle reifiers some more from using builder and impl directly, > so we can get further ahead of being able to seperate reifier and model from > camel-core-engine - eg eventually maybe so you can have those at built time, > and then at runtime they can be removed / not needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15734) Karaf 4.2.10 jetty incompability with Camel 3.4.4 (or 3.6.0)
[ https://issues.apache.org/jira/browse/CAMEL-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219517#comment-17219517 ] Claus Ibsen commented on CAMEL-15734: - You can install the war feature from karaf itself first, then it installs jetty > Karaf 4.2.10 jetty incompability with Camel 3.4.4 (or 3.6.0) > > > Key: CAMEL-15734 > URL: https://issues.apache.org/jira/browse/CAMEL-15734 > Project: Camel > Issue Type: Bug > Components: camel-servlet >Affects Versions: 3.4.4, 3.6.0 > Environment: Camel 3.4.4 or 3.6.0 with Karaf 4.2.10 , OpenJDK 11, > Linux >Reporter: Tapio Piironen >Priority: Minor > > Karaf just released 4.2.10 version and seems like Jetty is again upgraded and > causes incompability issues. Not sure if this is Camel or Karaf project > issue, but reporting here. Stack trace below when installing camel-servlet > component: > 2020-10-22T12:29:23,689 | ERROR | Karaf ssh console user karaf | ShellUtil | > 36 - org.apache.karaf.shell.core - 4.2.10 | Exception caught while executing > command org.apache.karaf.features.internal.util.MultiException: Error > restarting bundles: Activator start error in bundle > org.ops4j.pax.web.pax-web-jetty [255]. at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1045) > ~[?:?] at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1062) > ~[?:?] at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998) > ~[?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] at java.lang.Thread.run(Thread.java:834) [?:?] Suppressed: > org.osgi.framework.BundleException: Activator start error in bundle > org.ops4j.pax.web.pax-web-jetty [255]. at > org.apache.felix.framework.Felix.activateBundle(Felix.java:2290) ~[?:?] at > org.apache.felix.framework.Felix.startBundle(Felix.java:2146) ~[?:?] at > org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?] at > org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984) ~[?:?] at > org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:165) > ~[?:?] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1153) > ~[?:?] at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1037) > ~[?:?] at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1062) > ~[?:?] at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998) > ~[?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] at java.lang.Thread.run(Thread.java:834) [?:?] Caused by: > java.lang.NoClassDefFoundError: > org/eclipse/jetty/server/HttpConfiguration$Customizer at > org.ops4j.pax.web.service.jetty.internal.Activator.start(Activator.java:109) > ~[?:?] at > org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697) > ~[?:?] at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240) > ~[?:?] ... 12 more Caused by: java.lang.ClassNotFoundException: > org.eclipse.jetty.server.HttpConfiguration$Customizer not found by > org.eclipse.jetty.aggregate.jetty-all-server [253] > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639) > ~[?:?] at > org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) > ~[?:?] at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) > ~[?:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?] at > org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1414) > ~[?:?] at > org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1660) > ~[?:?] at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1590) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) > ~[?:?] at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) > ~[?:?] > at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?] >
[jira] [Resolved] (CAMEL-15710) OpenTracingTracer does not activate created span
[
https://issues.apache.org/jira/browse/CAMEL-15710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-15710.
-
Resolution: Fixed
Thanks for reporting and the PRs
> OpenTracingTracer does not activate created span
>
>
> Key: CAMEL-15710
> URL: https://issues.apache.org/jira/browse/CAMEL-15710
> Project: Camel
> Issue Type: Bug
> Components: camel-opentracing
>Affects Versions: 3.4.1
>Reporter: Bogdan Ilchyshyn
>Priority: Major
> Fix For: 3.4.5, 3.7.0
>
>
> {{OpenTracingTracer}} does not activate the span it creates in
> {{onExchangeBegin}} (i.e. does not invoke {{tracer.activateSpan}}). Whenever
> there is processor invoked down the route, and this processor code is
> instrumented for OpenTracing (for instance, JDBC calls via
> {{opentracing-contrib/java-spring-cloud}}), the newly created spans are not
> aware about a trace being active and start a new trace. This leads to all
> such spans being detached from the route trace. It is a major issue for Camel
> routes observability via OpenTracing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-15716) Allow to specify subprotocol when using camel-vertx-websocket component
[
https://issues.apache.org/jira/browse/CAMEL-15716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-15716.
-
Resolution: Fixed
> Allow to specify subprotocol when using camel-vertx-websocket component
> ---
>
> Key: CAMEL-15716
> URL: https://issues.apache.org/jira/browse/CAMEL-15716
> Project: Camel
> Issue Type: Improvement
> Components: camel-vertx
>Affects Versions: 3.5.0
>Reporter: ncasaux
>Assignee: James Netherton
>Priority: Minor
> Fix For: 3.7.0
>
>
> Hello,
> I would like to use the component *camel-vertx-websocket* to do some Stomp
> over Websocket with an existing Websocket server (ActiveMQ in my use case).
> However, netty logs keep saying this:
>
> {code:java}
> Caused by:
> io.netty.handler.codec.http.websocketx.WebSocketHandshakeException:
> Invalid subprotocol. Actual: stomp. Expected one of: null
> {code}
> I would like to pass a value for the subprotocol (like v12.stomp), but I
> don't know if it's possible.
> However, I can see in the netty class
>
> {code:java}
> io.netty.handler.codec.http.websocketx.WebSocketClientHandshaker{code}
>
> that there are constructors that can take a subprotocol as a parameter:
>
> {code:java}
> /**
> * Base constructor
> *
> * @param uri
> * URL for web socket communications. e.g "ws://myhost.com/mypath".
> Subsequent web socket frames will be
> * sent to this URL.
> * @param version
> * Version of web socket specification to use to connect to the server
> * @param subprotocol
> * Sub protocol request sent to the server.
> * @param customHeaders
> * Map of custom headers to add to the client request
> * @param maxFramePayloadLength
> * Maximum length of a frame's payload
> */
> protected WebSocketClientHandshaker(URI uri, WebSocketVersion version, String
> subprotocol,
> HttpHeaders customHeaders, int maxFramePayloadLength) {
> this(uri, version, subprotocol, customHeaders, maxFramePayloadLength,
> DEFAULT_FORCE_CLOSE_TIMEOUT_MILLIS);
> }{code}
>
> That would be great if we could pass this subprotocol to netty, to do some
> Stomp over Websocket :)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-15742) xpath uses previous return type definition
[
https://issues.apache.org/jira/browse/CAMEL-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-15742.
-
Resolution: Fixed
Yes its a little bug which is now fixed. Thanks for reporting and with the
sample code
> xpath uses previous return type definition
> --
>
> Key: CAMEL-15742
> URL: https://issues.apache.org/jira/browse/CAMEL-15742
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.6.0
>Reporter: Dennis
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> The 3.6.0 version brakes our route tests.
> In the code below we have two xpath expressions. Debugging shows, that the
> second one in split uses Long.class as return type for evaluation which is
> wrong and split silently fails (No split done).
> if you remove
> {code:java}
> .setProperty("BOOK_COUNT", xpath( "//Books/@count", Long.class))
> {code}
> test will pass.
> Verified by test based on Camel Quarkus :: Examples :: Rest Json
> 1.3.0
> 1.9.0.Final
> {code:java}
> package org.acme.rest.json;
> import org.apache.camel.builder.RouteBuilder;
> import java.util.concurrent.atomic.AtomicInteger;
> public class Routes extends RouteBuilder {
> private AtomicInteger splitCount = new AtomicInteger();
> @Override
> public void configure() throws Exception {
> from("platform-http:/xpathtest?httpMethodRestrict=POST")
> .process(exchange -> splitCount.set(0))
> .setProperty("BOOK_COUNT", xpath( "//Books/@count",
> Long.class))
> .split(xpath("//Books/Book"))
> .process(exchange -> splitCount.getAndIncrement())
> .end()
> .setBody(exchange -> splitCount.get())
> .marshal().json();
> }
> }
> {code}
> *TEST: *
> {code:java}
> package org.acme.rest.json;import io.quarkus.test.junit.QuarkusTest;
> import org.junit.jupiter.api.Test;import static
> io.restassured.RestAssured.given;
> import static org.hamcrest.CoreMatchers.is;@QuarkusTest
> public class RestJsonTest {@Test
> public void xpath() {
> given()
> .body("\n" +
> " ISBN=\"1\">First " +
> "SECOND
> " +
> "")
> .header("Content-Type", "application/xml")
> .when()
> .post("/xpathtest")
> .then()
> .statusCode(200)
> .body(is("2"));
> }}
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
