[jira] [Commented] (CAMEL-15731) Add support for receiving MLLP messages without sending any acknowledgment
[ https://issues.apache.org/jira/browse/CAMEL-15731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218770#comment-17218770 ] Claus Ibsen commented on CAMEL-15731: - Are you able to work on improving this? > Add support for receiving MLLP messages without sending any acknowledgment > -- > > Key: CAMEL-15731 > URL: https://issues.apache.org/jira/browse/CAMEL-15731 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Affects Versions: 3.6.0 >Reporter: Rafal >Priority: Major > > Currently when reading HL7 messages using camel-mllp we always have to send > back some acknowledgment. Even with autoAck=false there has to be some ack > set though MLLP_ACKNOWLEDGEMENT property, or the MllpTcpServerConsumer throws > MllpInvalidAcknowledgementException. This is a big limitation when migrating > for example from Mirth to camel since Mirth supports that (see pages 330-331 > in > [https://www.nextgen.com/-/media/files/nextgen-connect/nextgen-connect-39-user-guide.pdf).] > > The camel-mllp component should allow receiving messages without sending back > any ack, the same way Mirth does it. I believe it should stop throwing > exceptions if autoAck=false, synchronous=false and no ack is being set by any > of the MLLP_ACKNOWLEDGEMENT properties. Or we could introduce new property to > support this mode. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-15728) [cdi] @ContextName does not exist anymore
[ https://issues.apache.org/jira/browse/CAMEL-15728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15728. - Fix Version/s: (was: 3.x) 3.7.0 Resolution: Fixed > [cdi] @ContextName does not exist anymore > - > > Key: CAMEL-15728 > URL: https://issues.apache.org/jira/browse/CAMEL-15728 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.7.0 > > > Its mention should probably be dropped from > org.apache.camel.cdi.CdiCamelContext javadoc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15728) [cdi] @ContextName does not exist anymore
[ https://issues.apache.org/jira/browse/CAMEL-15728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15728: Component/s: camel-cdi > [cdi] @ContextName does not exist anymore > - > > Key: CAMEL-15728 > URL: https://issues.apache.org/jira/browse/CAMEL-15728 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > Its mention should probably be dropped from > org.apache.camel.cdi.CdiCamelContext javadoc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15728) [cdi] @ContextName does not exist anymore
[ https://issues.apache.org/jira/browse/CAMEL-15728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15728: Priority: Minor (was: Major) > [cdi] @ContextName does not exist anymore > - > > Key: CAMEL-15728 > URL: https://issues.apache.org/jira/browse/CAMEL-15728 > Project: Camel > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > Its mention should probably be dropped from > org.apache.camel.cdi.CdiCamelContext javadoc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15725) Make camel-cdi OSGi CDI friendly
[ https://issues.apache.org/jira/browse/CAMEL-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15725: Component/s: camel-cdi > Make camel-cdi OSGi CDI friendly > > > Key: CAMEL-15725 > URL: https://issues.apache.org/jira/browse/CAMEL-15725 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 3.x > > > Needs to exposes the cdi extension in capabilities mainly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15717) Skip archetype integration tests in deploy profile
[ https://issues.apache.org/jira/browse/CAMEL-15717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15717: Fix Version/s: 3.7.0 > Skip archetype integration tests in deploy profile > -- > > Key: CAMEL-15717 > URL: https://issues.apache.org/jira/browse/CAMEL-15717 > Project: Camel > Issue Type: Task > Components: build system >Reporter: Jan Bednar >Assignee: Jan Bednar >Priority: Major > Fix For: 3.7.0 > > > See problems during latest release > http://camel.465427.n5.nabble.com/Apache-Camel-3-6-this-October-tp5887752p5889984.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15724) Decouple camel-cdi from JTA
[ https://issues.apache.org/jira/browse/CAMEL-15724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15724: Priority: Minor (was: Major) > Decouple camel-cdi from JTA > --- > > Key: CAMEL-15724 > URL: https://issues.apache.org/jira/browse/CAMEL-15724 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > JTA is fully optional and when undesired it makes camel-cdi module unusable. > Would be great to keep camel-cdi only depending on CDI and have a jta > integration either in a new module or in a jta module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15724) Decouple camel-cdi from JTA
[ https://issues.apache.org/jira/browse/CAMEL-15724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15724: Component/s: camel-cdi > Decouple camel-cdi from JTA > --- > > Key: CAMEL-15724 > URL: https://issues.apache.org/jira/browse/CAMEL-15724 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 3.x > > > JTA is fully optional and when undesired it makes camel-cdi module unusable. > Would be great to keep camel-cdi only depending on CDI and have a jta > integration either in a new module or in a jta module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15725) Make camel-cdi OSGi CDI friendly
[ https://issues.apache.org/jira/browse/CAMEL-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15725: Priority: Minor (was: Major) > Make camel-cdi OSGi CDI friendly > > > Key: CAMEL-15725 > URL: https://issues.apache.org/jira/browse/CAMEL-15725 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > Needs to exposes the cdi extension in capabilities mainly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15727) Simplify camel-cdi dependencies
[ https://issues.apache.org/jira/browse/CAMEL-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15727: Priority: Minor (was: Major) > Simplify camel-cdi dependencies > --- > > Key: CAMEL-15727 > URL: https://issues.apache.org/jira/browse/CAMEL-15727 > Project: Camel > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > seems mock and main dependencies should be dropped in favor of > camel-core-languages (and camel-core-engine but it is transitive from > language one). Other ones can be added in a camel-cdi-main module or so but > are undesired for main deployments IMHO. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15727) Simplify camel-cdi dependencies
[ https://issues.apache.org/jira/browse/CAMEL-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15727: Component/s: camel-cdi > Simplify camel-cdi dependencies > --- > > Key: CAMEL-15727 > URL: https://issues.apache.org/jira/browse/CAMEL-15727 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > seems mock and main dependencies should be dropped in favor of > camel-core-languages (and camel-core-engine but it is transitive from > language one). Other ones can be added in a camel-cdi-main module or so but > are undesired for main deployments IMHO. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15717) Skip archetype integration tests in deploy profile
[ https://issues.apache.org/jira/browse/CAMEL-15717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15717: Priority: Major (was: Critical) > Skip archetype integration tests in deploy profile > -- > > Key: CAMEL-15717 > URL: https://issues.apache.org/jira/browse/CAMEL-15717 > Project: Camel > Issue Type: Task > Components: build system >Reporter: Jan Bednar >Assignee: Jan Bednar >Priority: Major > > See problems during latest release > http://camel.465427.n5.nabble.com/Apache-Camel-3-6-this-October-tp5887752p5889984.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15686) Enable EndpointDSL with simple expressions within an Endpoint Builder bean
[
https://issues.apache.org/jira/browse/CAMEL-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218663#comment-17218663
]
Franky Georg commented on CAMEL-15686:
--
So somehow Camel is starting the KafkaEndpointBuilder as its own route.
But only in my project, which I can't share.
In case there's some conflict, I've tried:
* removing any use of CamelContext
* removing any other toD
> Enable EndpointDSL with simple expressions within an Endpoint Builder bean
> --
>
> Key: CAMEL-15686
> URL: https://issues.apache.org/jira/browse/CAMEL-15686
> Project: Camel
> Issue Type: Improvement
> Components: camel-endpointdsl
> Environment: Experienced with
> * Camel 3.4.4
> * Spring Boot 2.3.4
>Reporter: Franky Georg
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.7.0
>
>
> Injecting an EndpointProducerBuilder bean that uses a simple expression
> causes an exception.
> {code:java}
> @Configuration
> public class MyTestRoute extends EndpointRouteBuilder {
>private static final String MY_TOPIC = "testTopic";
>@Autowired
>private EndpointProducerBuilder myKafkaBean;
>@Override
>public void configure() {
> from(timer("myTimer").repeatCount(1))
> .setBody(constant("THIS IS A TEST MESSAGE"))
> .setProperty("destination2", constant(MY_TOPIC))
> .to("direct:publish-to-kafka2")
> ;
> from("direct:publish-to-kafka2")
> .toD(myKafkaBean)
> ;
> from(kafka(MY_TOPIC))
> .log("Received: ${body}")
> ;
>}
>@Bean
>public EndpointProducerBuilder myKafkaBean() {
> return kafka("${exchangeProperty.destination2}");
>}
> }{code}
> Exception from org.apache.kafka.clients.Metadata:
> {code:java}
> Metadata response reported invalid topics
> [${exchangeProperty.destination}]{code}
> I don't have to _use_ the bean for the error to manifest, it's enough to
> @Autowire it.
>
> It _does_ work for static endpoints:
> {code:java}
> return kafka("myTopic"); // This works fine from an
> EndpointProducerBuilder bean{code}
> And it _does_ work for dynamic endpoints in URI form:
> {code:java}
> return "kafka:${exchangeProperty.destination}"; // This works fine but
> you lose type safety{code}
>
> Creating beans like this is useful for unit testing as they can be overridden
> to return mock/direct/whatever-is-useful, _without_ _first creating the
> original endpoint_, which can significantly reduce execution time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-15686) Enable EndpointDSL with simple expressions within an Endpoint Builder bean
[
https://issues.apache.org/jira/browse/CAMEL-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218035#comment-17218035
]
Franky Georg edited comment on CAMEL-15686 at 10/21/20, 10:53 PM:
--
Updated description with a full test class. Using properties:
camel.springboot.main-run-controller=true
camel.component.kafka.brokers=localhost:9092
-I get no errors in a clean project on 1st PC.-
-In an existing project on 2nd PC:-
I get no errors in a clean project.
The following occurs when adding the same code to my existing project:
# The 3 expected routes are created
# The message is sent to Kafka via 'testTopic'
# The message is received from Kafka via 'testTopic'
# _Camel creates an unexpected new route_
```Route: route7 started and consuming from:
kafka://${exchangeProperty.destination2}```
# Camel tries to create a new topic named '${exchangeProperty.destination}'
and throws an error about it being an invalid topic name
Clearly it's something to do with my existing project/environment. I'll
continue trying to narrow it down, but to me it's looking more like a bug than
an enhancement request at this point.
was (Author: frankyg):
Updated description with a full test class. Using properties:
camel.springboot.main-run-controller=true
camel.component.kafka.brokers=localhost:9092
-I get no errors in a clean project on 1st PC.-
-In an existing project on 2nd PC:-
I get no errors in a clean project.
The following occurs when adding the same code to my existing project:
# The 3 expected routes are created
# The message is sent to Kafka via 'testTopic'
# The message is received from Kafka via 'testTopic'
# _Camel creates an unexpected new route_
`Route: route7 started and consuming from:
kafka://${exchangeProperty.destination2}`
# Camel tries to create a new topic named '${exchangeProperty.destination}'
and throws an error about it being an invalid topic name
Clearly it's something to do with my existing project/environment. I'll
continue trying to narrow it down, but to me it's looking more like a bug than
an enhancement request at this point.
> Enable EndpointDSL with simple expressions within an Endpoint Builder bean
> --
>
> Key: CAMEL-15686
> URL: https://issues.apache.org/jira/browse/CAMEL-15686
> Project: Camel
> Issue Type: Improvement
> Components: camel-endpointdsl
> Environment: Experienced with
> * Camel 3.4.4
> * Spring Boot 2.3.4
>Reporter: Franky Georg
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.7.0
>
>
> Injecting an EndpointProducerBuilder bean that uses a simple expression
> causes an exception.
> {code:java}
> @Configuration
> public class MyTestRoute extends EndpointRouteBuilder {
>private static final String MY_TOPIC = "testTopic";
>@Autowired
>private EndpointProducerBuilder myKafkaBean;
>@Override
>public void configure() {
> from(timer("myTimer").repeatCount(1))
> .setBody(constant("THIS IS A TEST MESSAGE"))
> .setProperty("destination2", constant(MY_TOPIC))
> .to("direct:publish-to-kafka2")
> ;
> from("direct:publish-to-kafka2")
> .toD(myKafkaBean)
> ;
> from(kafka(MY_TOPIC))
> .log("Received: ${body}")
> ;
>}
>@Bean
>public EndpointProducerBuilder myKafkaBean() {
> return kafka("${exchangeProperty.destination2}");
>}
> }{code}
> Exception from org.apache.kafka.clients.Metadata:
> {code:java}
> Metadata response reported invalid topics
> [${exchangeProperty.destination}]{code}
> I don't have to _use_ the bean for the error to manifest, it's enough to
> @Autowire it.
>
> It _does_ work for static endpoints:
> {code:java}
> return kafka("myTopic"); // This works fine from an
> EndpointProducerBuilder bean{code}
> And it _does_ work for dynamic endpoints in URI form:
> {code:java}
> return "kafka:${exchangeProperty.destination}"; // This works fine but
> you lose type safety{code}
>
> Creating beans like this is useful for unit testing as they can be overridden
> to return mock/direct/whatever-is-useful, _without_ _first creating the
> original endpoint_, which can significantly reduce execution time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-15686) Enable EndpointDSL with simple expressions within an Endpoint Builder bean
[
https://issues.apache.org/jira/browse/CAMEL-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218035#comment-17218035
]
Franky Georg edited comment on CAMEL-15686 at 10/21/20, 10:53 PM:
--
Updated description with a full test class. Using properties:
camel.springboot.main-run-controller=true
camel.component.kafka.brokers=localhost:9092
-I get no errors in a clean project on 1st PC.-
-In an existing project on 2nd PC:-
I get no errors in a clean project.
The following occurs when adding the same code to my existing project:
# The 3 expected routes are created
# The message is sent to Kafka via 'testTopic'
# The message is received from Kafka via 'testTopic'
# _Camel creates an unexpected new route_
{{Route: route7 started and consuming from:
kafka://${exchangeProperty.destination2}}}
# Camel tries to create a new topic named '${exchangeProperty.destination}'
and throws an error about it being an invalid topic name
Clearly it's something to do with my existing project/environment. I'll
continue trying to narrow it down, but to me it's looking more like a bug than
an enhancement request at this point.
was (Author: frankyg):
Updated description with a full test class. Using properties:
camel.springboot.main-run-controller=true
camel.component.kafka.brokers=localhost:9092
-I get no errors in a clean project on 1st PC.-
-In an existing project on 2nd PC:-
I get no errors in a clean project.
The following occurs when adding the same code to my existing project:
# The 3 expected routes are created
# The message is sent to Kafka via 'testTopic'
# The message is received from Kafka via 'testTopic'
# _Camel creates an unexpected new route_
```Route: route7 started and consuming from:
kafka://${exchangeProperty.destination2}```
# Camel tries to create a new topic named '${exchangeProperty.destination}'
and throws an error about it being an invalid topic name
Clearly it's something to do with my existing project/environment. I'll
continue trying to narrow it down, but to me it's looking more like a bug than
an enhancement request at this point.
> Enable EndpointDSL with simple expressions within an Endpoint Builder bean
> --
>
> Key: CAMEL-15686
> URL: https://issues.apache.org/jira/browse/CAMEL-15686
> Project: Camel
> Issue Type: Improvement
> Components: camel-endpointdsl
> Environment: Experienced with
> * Camel 3.4.4
> * Spring Boot 2.3.4
>Reporter: Franky Georg
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.7.0
>
>
> Injecting an EndpointProducerBuilder bean that uses a simple expression
> causes an exception.
> {code:java}
> @Configuration
> public class MyTestRoute extends EndpointRouteBuilder {
>private static final String MY_TOPIC = "testTopic";
>@Autowired
>private EndpointProducerBuilder myKafkaBean;
>@Override
>public void configure() {
> from(timer("myTimer").repeatCount(1))
> .setBody(constant("THIS IS A TEST MESSAGE"))
> .setProperty("destination2", constant(MY_TOPIC))
> .to("direct:publish-to-kafka2")
> ;
> from("direct:publish-to-kafka2")
> .toD(myKafkaBean)
> ;
> from(kafka(MY_TOPIC))
> .log("Received: ${body}")
> ;
>}
>@Bean
>public EndpointProducerBuilder myKafkaBean() {
> return kafka("${exchangeProperty.destination2}");
>}
> }{code}
> Exception from org.apache.kafka.clients.Metadata:
> {code:java}
> Metadata response reported invalid topics
> [${exchangeProperty.destination}]{code}
> I don't have to _use_ the bean for the error to manifest, it's enough to
> @Autowire it.
>
> It _does_ work for static endpoints:
> {code:java}
> return kafka("myTopic"); // This works fine from an
> EndpointProducerBuilder bean{code}
> And it _does_ work for dynamic endpoints in URI form:
> {code:java}
> return "kafka:${exchangeProperty.destination}"; // This works fine but
> you lose type safety{code}
>
> Creating beans like this is useful for unit testing as they can be overridden
> to return mock/direct/whatever-is-useful, _without_ _first creating the
> original endpoint_, which can significantly reduce execution time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-15686) Enable EndpointDSL with simple expressions within an Endpoint Builder bean
[
https://issues.apache.org/jira/browse/CAMEL-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218035#comment-17218035
]
Franky Georg edited comment on CAMEL-15686 at 10/21/20, 10:53 PM:
--
Updated description with a full test class. Using properties:
camel.springboot.main-run-controller=true
camel.component.kafka.brokers=localhost:9092
-I get no errors in a clean project on 1st PC.-
-In an existing project on 2nd PC:-
I get no errors in a clean project.
The following occurs when adding the same code to my existing project:
# The 3 expected routes are created
# The message is sent to Kafka via 'testTopic'
# The message is received from Kafka via 'testTopic'
# _Camel creates an unexpected new route_
`Route: route7 started and consuming from:
kafka://${exchangeProperty.destination2}`
# Camel tries to create a new topic named '${exchangeProperty.destination}'
and throws an error about it being an invalid topic name
Clearly it's something to do with my existing project/environment. I'll
continue trying to narrow it down, but to me it's looking more like a bug than
an enhancement request at this point.
was (Author: frankyg):
Updated description with a full test class. Using properties:
camel.springboot.main-run-controller=true
camel.component.kafka.brokers=localhost:9092
I get no errors in a clean project on 1st PC.
In an existing project on 2nd PC:
# The 3 expected routes are created
# The message is sent to Kafka via 'testTopic'
# The message is received from Kafka via 'testTopic'
# Camel tries to create a new topic named '${exchangeProperty.destination}'
and throws an error about it being an invalid topic name
Clearly it's something to do with my existing project/environment. I'll
continue trying to narrow it down, but to me it's looking more like a bug than
an enhancement request at this point.
> Enable EndpointDSL with simple expressions within an Endpoint Builder bean
> --
>
> Key: CAMEL-15686
> URL: https://issues.apache.org/jira/browse/CAMEL-15686
> Project: Camel
> Issue Type: Improvement
> Components: camel-endpointdsl
> Environment: Experienced with
> * Camel 3.4.4
> * Spring Boot 2.3.4
>Reporter: Franky Georg
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.7.0
>
>
> Injecting an EndpointProducerBuilder bean that uses a simple expression
> causes an exception.
> {code:java}
> @Configuration
> public class MyTestRoute extends EndpointRouteBuilder {
>private static final String MY_TOPIC = "testTopic";
>@Autowired
>private EndpointProducerBuilder myKafkaBean;
>@Override
>public void configure() {
> from(timer("myTimer").repeatCount(1))
> .setBody(constant("THIS IS A TEST MESSAGE"))
> .setProperty("destination2", constant(MY_TOPIC))
> .to("direct:publish-to-kafka2")
> ;
> from("direct:publish-to-kafka2")
> .toD(myKafkaBean)
> ;
> from(kafka(MY_TOPIC))
> .log("Received: ${body}")
> ;
>}
>@Bean
>public EndpointProducerBuilder myKafkaBean() {
> return kafka("${exchangeProperty.destination2}");
>}
> }{code}
> Exception from org.apache.kafka.clients.Metadata:
> {code:java}
> Metadata response reported invalid topics
> [${exchangeProperty.destination}]{code}
> I don't have to _use_ the bean for the error to manifest, it's enough to
> @Autowire it.
>
> It _does_ work for static endpoints:
> {code:java}
> return kafka("myTopic"); // This works fine from an
> EndpointProducerBuilder bean{code}
> And it _does_ work for dynamic endpoints in URI form:
> {code:java}
> return "kafka:${exchangeProperty.destination}"; // This works fine but
> you lose type safety{code}
>
> Creating beans like this is useful for unit testing as they can be overridden
> to return mock/direct/whatever-is-useful, _without_ _first creating the
> original endpoint_, which can significantly reduce execution time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-15731) Add support for receiving MLLP messages without sending any acknowledgment
[ https://issues.apache.org/jira/browse/CAMEL-15731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafal updated CAMEL-15731: -- Summary: Add support for receiving MLLP messages without sending any acknowledgment (was: Add support for receiving MLLP messages without any acknowledgment) > Add support for receiving MLLP messages without sending any acknowledgment > -- > > Key: CAMEL-15731 > URL: https://issues.apache.org/jira/browse/CAMEL-15731 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Affects Versions: 3.6.0 >Reporter: Rafal >Priority: Major > > Currently when reading HL7 messages using camel-mllp we always have to send > back some acknowledgment. Even with autoAck=false there has to be some ack > set though MLLP_ACKNOWLEDGEMENT property, or the MllpTcpServerConsumer throws > MllpInvalidAcknowledgementException. This is a big limitation when migrating > for example from Mirth to camel since Mirth supports that (see pages 330-331 > in > [https://www.nextgen.com/-/media/files/nextgen-connect/nextgen-connect-39-user-guide.pdf).] > > The camel-mllp component should allow receiving messages without sending back > any ack, the same way Mirth does it. I believe it should stop throwing > exceptions if autoAck=false, synchronous=false and no ack is being set by any > of the MLLP_ACKNOWLEDGEMENT properties. Or we could introduce new property to > support this mode. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15732) camel-core - Untangle reifier from impl and builder
Claus Ibsen created CAMEL-15732: --- Summary: 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 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] [Updated] (CAMEL-15731) Add support for receiving MLLP messages without any acknowledgment
[ https://issues.apache.org/jira/browse/CAMEL-15731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafal updated CAMEL-15731: -- Summary: Add support for receiving MLLP messages without any acknowledgment (was: Add support for receiving messages without any acknowledgment) > Add support for receiving MLLP messages without any acknowledgment > -- > > Key: CAMEL-15731 > URL: https://issues.apache.org/jira/browse/CAMEL-15731 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Affects Versions: 3.6.0 >Reporter: Rafal >Priority: Major > > Currently when reading HL7 messages using camel-mllp we always have to send > back some acknowledgment. Even with autoAck=false there has to be some ack > set though MLLP_ACKNOWLEDGEMENT property, or the MllpTcpServerConsumer throws > MllpInvalidAcknowledgementException. This is a big limitation when migrating > for example from Mirth to camel since Mirth supports that (see pages 330-331 > in > [https://www.nextgen.com/-/media/files/nextgen-connect/nextgen-connect-39-user-guide.pdf).] > > The camel-mllp component should allow receiving messages without sending back > any ack, the same way Mirth does it. I believe it should stop throwing > exceptions if autoAck=false, synchronous=false and no ack is being set by any > of the MLLP_ACKNOWLEDGEMENT properties. Or we could introduce new property to > support this mode. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15731) Add support for receiving messages without any acknowledgment
Rafal created CAMEL-15731: - Summary: Add support for receiving messages without any acknowledgment Key: CAMEL-15731 URL: https://issues.apache.org/jira/browse/CAMEL-15731 Project: Camel Issue Type: Improvement Components: camel-mllp Affects Versions: 3.6.0 Reporter: Rafal Currently when reading HL7 messages using camel-mllp we always have to send back some acknowledgment. Even with autoAck=false there has to be some ack set though MLLP_ACKNOWLEDGEMENT property, or the MllpTcpServerConsumer throws MllpInvalidAcknowledgementException. This is a big limitation when migrating for example from Mirth to camel since Mirth supports that (see pages 330-331 in [https://www.nextgen.com/-/media/files/nextgen-connect/nextgen-connect-39-user-guide.pdf).] The camel-mllp component should allow receiving messages without sending back any ack, the same way Mirth does it. I believe it should stop throwing exceptions if autoAck=false, synchronous=false and no ack is being set by any of the MLLP_ACKNOWLEDGEMENT properties. Or we could introduce new property to support this mode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-15730) camel-core - SimpleBuilder should just be a facade
[ https://issues.apache.org/jira/browse/CAMEL-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15730. - Resolution: Fixed Okay we got a bit further - however its a bit tougher to make SimpleBuilder not as a predicate/expression but as a intermediate holder that gets replaced when the route model is built. > camel-core - SimpleBuilder should just be a facade > -- > > Key: CAMEL-15730 > URL: https://issues.apache.org/jira/browse/CAMEL-15730 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.7.0 > > > Due to how the java dsl was designed in the beginning then we have > SimpleBuilder that are used for defining simple expressions/predicates which > is a bit different than what else is done. > But we can untangle that and make it just a facade and transfer the > configuration to Simple Language definition like the DSL works in general. > We should also untangle SimpleBuilder from the reifier so they are not direct > dependent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15679) LevelDB: Consider replacing of serizalization via org.fusesource.hawtbuf:hawtbuf with Jackson
[ https://issues.apache.org/jira/browse/CAMEL-15679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218479#comment-17218479 ] Claus Ibsen commented on CAMEL-15679: - We would need spring boot starter for the legacy component, and also karaf features to be updated > LevelDB: Consider replacing of serizalization via > org.fusesource.hawtbuf:hawtbuf with Jackson > - > > Key: CAMEL-15679 > URL: https://issues.apache.org/jira/browse/CAMEL-15679 > Project: Camel > Issue Type: Improvement > Components: camel-leveldb >Affects Versions: 3.5.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Major > Fix For: 3.7.0 > > > Current implementation of serialization is based on > `org.fusesource.hawtbuf:hawtbuf` and java object serialization. It would be > better to use Jackson instead. Here are some reasons: > # Serialization with Jackson is faster (see > [http://rick-hightower.blogspot.com/2014/04/which-is-faster-java-object.html]) > # Camel-quarkus can not use java object serialization in native (see > [https://github.com/oracle/graal/issues/460]) Current workaround uses Jackson > instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15730) camel-core - SimpleBuilder should just be a facade
[ https://issues.apache.org/jira/browse/CAMEL-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218467#comment-17218467 ] Claus Ibsen commented on CAMEL-15730: - There are some places where this reveal where we could improve as some EIPs take in SimpleBuilder and dont transform it to SimpleExpression model as other EIPs does in general. Its for EIPs with special expression options like wiretap, aggregator etc. > camel-core - SimpleBuilder should just be a facade > -- > > Key: CAMEL-15730 > URL: https://issues.apache.org/jira/browse/CAMEL-15730 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.7.0 > > > Due to how the java dsl was designed in the beginning then we have > SimpleBuilder that are used for defining simple expressions/predicates which > is a bit different than what else is done. > But we can untangle that and make it just a facade and transfer the > configuration to Simple Language definition like the DSL works in general. > We should also untangle SimpleBuilder from the reifier so they are not direct > dependent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15730) camel-core - SimpleBuilder should just be a facade
Claus Ibsen created CAMEL-15730: --- Summary: camel-core - SimpleBuilder should just be a facade Key: CAMEL-15730 URL: https://issues.apache.org/jira/browse/CAMEL-15730 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 3.7.0 Due to how the java dsl was designed in the beginning then we have SimpleBuilder that are used for defining simple expressions/predicates which is a bit different than what else is done. But we can untangle that and make it just a facade and transfer the configuration to Simple Language definition like the DSL works in general. We should also untangle SimpleBuilder from the reifier so they are not direct dependent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-15722) endpoint uri builder: add an option to URL encode the returned uri or not
[ https://issues.apache.org/jira/browse/CAMEL-15722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-15722. - Resolution: Fixed > endpoint uri builder: add an option to URL encode the returned uri or not > - > > Key: CAMEL-15722 > URL: https://issues.apache.org/jira/browse/CAMEL-15722 > Project: Camel > Issue Type: Improvement > Components: camel-core-engine >Affects Versions: 3.6.0 >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-15721) camel-core - Simple with external resource should load resource once during init
[
https://issues.apache.org/jira/browse/CAMEL-15721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-15721.
-
Resolution: Fixed
> camel-core - Simple with external resource should load resource once during
> init
>
>
> Key: CAMEL-15721
> URL: https://issues.apache.org/jira/browse/CAMEL-15721
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> To optimize simple language if you do
> simple("resource:foo.txt")
> Then foo.txt should be loaded once.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-15729) Graphql integration does not allow for TLS using private CAs
Tim Kaczynski created CAMEL-15729: - Summary: Graphql integration does not allow for TLS using private CAs Key: CAMEL-15729 URL: https://issues.apache.org/jira/browse/CAMEL-15729 Project: Camel Issue Type: New Feature Components: camel-graphql Affects Versions: 3.6.0 Environment: OCP 4.5 on X using Apache Camel Operator 1.2.0, but other environments apply as well. Reporter: Tim Kaczynski This enhancement request was generated from a question on zulipchat: [https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Adding.20a.20trustStore.20for.20graphql/near/213944005] We are writing an integration that needs to produce messages to a graphql server. The graphql server is using TLS and its certificate was generated by an internal CA. There does not appear to be a way to provide a trust store to the graphql producer, like there is for say the Kafka integrations. Connections to graphql fail due to the inability to build a trusted certificate chain. Possible non-trivial solutions include assuming the graphql integration is using the apache HTTP client, and setting up a new protocol that uses a custom trust store. Also (using camel-k) using the JVM taint to alter the JSSE configuration / java properties, adding a trust store containing the CA. However both of these solutions require assumptions about the implementation that may not always be true (and we have not tested them yet). Could also use the HTTP[4] integration directly to talk to graphql but this requires coding the REST request manually. If there were a parameter on the graphql integration where we could input a trust store, type, and password, that would be an ideal solution. Or perhaps some other way of modifying the default trust store using camel-k (this would benefit all integrations). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-15726) camel-core - Simple language concat expressions optimize for constant parts
[
https://issues.apache.org/jira/browse/CAMEL-15726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-15726.
-
Resolution: Fixed
> camel-core - Simple language concat expressions optimize for constant parts
> ---
>
> Key: CAMEL-15726
> URL: https://issues.apache.org/jira/browse/CAMEL-15726
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> If you have a simple expression
> Hello ${body} how are you
> Then its 3 parts: constant, body, constant
> And at runtime they get evaluated and appended together as string.
> We could potentially optimize this for constant and pre eval then as string
> and then skip the noop eval when they are assembled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-15727) Simplify camel-cdi dependencies
[ https://issues.apache.org/jira/browse/CAMEL-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-15727: - Fix Version/s: 3.x > Simplify camel-cdi dependencies > --- > > Key: CAMEL-15727 > URL: https://issues.apache.org/jira/browse/CAMEL-15727 > Project: Camel > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 3.x > > > seems mock and main dependencies should be dropped in favor of > camel-core-languages (and camel-core-engine but it is transitive from > language one). Other ones can be added in a camel-cdi-main module or so but > are undesired for main deployments IMHO. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15725) Make camel-cdi OSGi CDI friendly
[ https://issues.apache.org/jira/browse/CAMEL-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-15725: - Fix Version/s: 3.x > Make camel-cdi OSGi CDI friendly > > > Key: CAMEL-15725 > URL: https://issues.apache.org/jira/browse/CAMEL-15725 > Project: Camel > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 3.x > > > Needs to exposes the cdi extension in capabilities mainly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15728) [cdi] @ContextName does not exist anymore
[ https://issues.apache.org/jira/browse/CAMEL-15728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-15728: - Fix Version/s: 3.x > [cdi] @ContextName does not exist anymore > - > > Key: CAMEL-15728 > URL: https://issues.apache.org/jira/browse/CAMEL-15728 > Project: Camel > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 3.x > > > Its mention should probably be dropped from > org.apache.camel.cdi.CdiCamelContext javadoc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15728) [cdi] @ContextName does not exist anymore
Romain Manni-Bucau created CAMEL-15728: -- Summary: [cdi] @ContextName does not exist anymore Key: CAMEL-15728 URL: https://issues.apache.org/jira/browse/CAMEL-15728 Project: Camel Issue Type: Task Reporter: Romain Manni-Bucau Its mention should probably be dropped from org.apache.camel.cdi.CdiCamelContext javadoc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15724) Decouple camel-cdi from JTA
[ https://issues.apache.org/jira/browse/CAMEL-15724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-15724: - Fix Version/s: 3.x > Decouple camel-cdi from JTA > --- > > Key: CAMEL-15724 > URL: https://issues.apache.org/jira/browse/CAMEL-15724 > Project: Camel > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 3.x > > > JTA is fully optional and when undesired it makes camel-cdi module unusable. > Would be great to keep camel-cdi only depending on CDI and have a jta > integration either in a new module or in a jta module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15727) Simplify camel-cdi dependencies
Romain Manni-Bucau created CAMEL-15727: -- Summary: Simplify camel-cdi dependencies Key: CAMEL-15727 URL: https://issues.apache.org/jira/browse/CAMEL-15727 Project: Camel Issue Type: Task Reporter: Romain Manni-Bucau seems mock and main dependencies should be dropped in favor of camel-core-languages (and camel-core-engine but it is transitive from language one). Other ones can be added in a camel-cdi-main module or so but are undesired for main deployments IMHO. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15726) camel-core - Simple language concat expressions optimize for constant parts
Claus Ibsen created CAMEL-15726:
---
Summary: camel-core - Simple language concat expressions optimize
for constant parts
Key: CAMEL-15726
URL: https://issues.apache.org/jira/browse/CAMEL-15726
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 3.7.0
If you have a simple expression
Hello ${body} how are you
Then its 3 parts: constant, body, constant
And at runtime they get evaluated and appended together as string.
We could potentially optimize this for constant and pre eval then as string and
then skip the noop eval when they are assembled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-15725) Make camel-cdi OSGi CDI friendly
Romain Manni-Bucau created CAMEL-15725: -- Summary: Make camel-cdi OSGi CDI friendly Key: CAMEL-15725 URL: https://issues.apache.org/jira/browse/CAMEL-15725 Project: Camel Issue Type: Task Reporter: Romain Manni-Bucau Needs to exposes the cdi extension in capabilities mainly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15724) Decouple camel-cdi from JTA
Romain Manni-Bucau created CAMEL-15724: -- Summary: Decouple camel-cdi from JTA Key: CAMEL-15724 URL: https://issues.apache.org/jira/browse/CAMEL-15724 Project: Camel Issue Type: Task Reporter: Romain Manni-Bucau JTA is fully optional and when undesired it makes camel-cdi module unusable. Would be great to keep camel-cdi only depending on CDI and have a jta integration either in a new module or in a jta module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15723) NPE when using PostgresAggregationRepository
[
https://issues.apache.org/jira/browse/CAMEL-15723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218210#comment-17218210
]
Claus Ibsen commented on CAMEL-15723:
-
I think we fixed something related to this. Can you try latest 3.4.x release.
> NPE when using PostgresAggregationRepository
>
>
> Key: CAMEL-15723
> URL: https://issues.apache.org/jira/browse/CAMEL-15723
> Project: Camel
> Issue Type: Bug
> Components: camel-sql
>Affects Versions: 3.4.2
> Environment: * Apache Camel 3.4.2
> * Spring Boot 2.3.4.RELEASE
> * Postgres database as an aggregate repository
>Reporter: Corina Roman
>Priority: Major
>
> Hi,
> we are getting production errors (NPE) when using a Postgres aggregate
> repository and Camel code attempts to write to that table (under concurrent
> use):
> {noformat}
> org.apache.camel.RuntimeCamelException: java.lang.RuntimeException: Error
> adding to repository lb_data_uploads with key *** at
> org.apache.camel.RuntimeCamelException.wrapRuntimeCamelException(RuntimeCamelException.java:52)
> at
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:142)
> at
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregationRepositoryAdd(AggregateProcessor.java:644)
> at
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregation(AggregateProcessor.java:598)
> at
> org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:406)
> at
> org.apache.camel.processor.aggregate.AggregateProcessor.doInOptimisticLock(AggregateProcessor.java:372)
> at
> org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:362)
> at
> org.apache.camel.processor.aggregate.AggregateProcessor.process(AggregateProcessor.java:320)
> at
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:702)
> at
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:616)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:148)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:60)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:147) at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:286)
> at
> org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
> at
> org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:40)
> at
> org.apache.camel.component.kafka.KafkaConsumer$KafkaFetchRecords.doRun(KafkaConsumer.java:346)
> at
> org.apache.camel.component.kafka.KafkaConsumer$KafkaFetchRecords.run(KafkaConsumer.java:222)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834) Caused by:
> java.lang.RuntimeException: Error adding to repository lb_data_uploads with
> key *** at
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:176)
> at
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:149)
> at
> org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140)
> at
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:149)
> at
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:137)
> ... 21 common frames omitted Caused by: java.lang.NullPointerException: null
> at
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:167)
> ... 25 common frames omitted{noformat}
>
> The problematic code seems to be at *JdbcAggregationRepository.java* line 167:
> {noformat}
> private static final String VERSION_PROPERTY = "CamelOptimisticLockVersion";
>
> long version = exchange.getProperty(VERSION_PROPERTY, Long.class);
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-15723) NPE when using PostgresAggregationRepository
Corina Roman created CAMEL-15723:
Summary: NPE when using PostgresAggregationRepository
Key: CAMEL-15723
URL: https://issues.apache.org/jira/browse/CAMEL-15723
Project: Camel
Issue Type: Bug
Components: camel-sql
Affects Versions: 3.4.2
Environment: * Apache Camel 3.4.2
* Spring Boot 2.3.4.RELEASE
* Postgres database as an aggregate repository
Reporter: Corina Roman
Hi,
we are getting production errors (NPE) when using a Postgres aggregate
repository and Camel code attempts to write to that table (under concurrent
use):
{noformat}
org.apache.camel.RuntimeCamelException: java.lang.RuntimeException: Error
adding to repository lb_data_uploads with key *** at
org.apache.camel.RuntimeCamelException.wrapRuntimeCamelException(RuntimeCamelException.java:52)
at
org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:142)
at
org.apache.camel.processor.aggregate.AggregateProcessor.doAggregationRepositoryAdd(AggregateProcessor.java:644)
at
org.apache.camel.processor.aggregate.AggregateProcessor.doAggregation(AggregateProcessor.java:598)
at
org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:406)
at
org.apache.camel.processor.aggregate.AggregateProcessor.doInOptimisticLock(AggregateProcessor.java:372)
at
org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:362)
at
org.apache.camel.processor.aggregate.AggregateProcessor.process(AggregateProcessor.java:320)
at
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:702)
at
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:616)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:148)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:60)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:147) at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:286)
at
org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
at
org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:40)
at
org.apache.camel.component.kafka.KafkaConsumer$KafkaFetchRecords.doRun(KafkaConsumer.java:346)
at
org.apache.camel.component.kafka.KafkaConsumer$KafkaFetchRecords.run(KafkaConsumer.java:222)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834) Caused by:
java.lang.RuntimeException: Error adding to repository lb_data_uploads with key
*** at
org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:176)
at
org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:149)
at
org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140)
at
org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:149)
at
org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:137)
... 21 common frames omitted Caused by: java.lang.NullPointerException: null
at
org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:167)
... 25 common frames omitted{noformat}
The problematic code seems to be at *JdbcAggregationRepository.java* line 167:
{noformat}
private static final String VERSION_PROPERTY = "CamelOptimisticLockVersion";
long version = exchange.getProperty(VERSION_PROPERTY, Long.class);
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-15722) endpoint uri builder: add an option to URL encode the returned uri or not
Luca Burgazzoli created CAMEL-15722: --- Summary: endpoint uri builder: add an option to URL encode the returned uri or not Key: CAMEL-15722 URL: https://issues.apache.org/jira/browse/CAMEL-15722 Project: Camel Issue Type: Improvement Components: camel-core-engine Affects Versions: 3.6.0 Reporter: Luca Burgazzoli Assignee: Luca Burgazzoli Fix For: 3.7.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15721) camel-core - Simple with external resource should load resource once during init
Claus Ibsen created CAMEL-15721:
---
Summary: camel-core - Simple with external resource should load
resource once during init
Key: CAMEL-15721
URL: https://issues.apache.org/jira/browse/CAMEL-15721
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 3.7.0
To optimize simple language if you do
simple("resource:foo.txt")
Then foo.txt should be loaded once.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs
[ https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218152#comment-17218152 ] ASF GitHub Bot commented on CAMEL-15392: zregvart commented on pull request #471: URL: https://github.com/apache/camel-website/pull/471#issuecomment-713367576 I'm rather tied up with other tasks, so I didn't have the time to look at this yesterday, I'll try to find some time today. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Provide a modified neat card layout for community & docs > > > Key: CAMEL-15392 > URL: https://issues.apache.org/jira/browse/CAMEL-15392 > Project: Camel > Issue Type: Improvement > Components: website >Reporter: Aemie >Priority: Major > Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from > 2020-08-18 02-52-37.png, button-community-badges.png, > button-link-docs-sub-project.png, camel-core-button-card.png, > community-design-card.png, contributing-design-card.png > > > The card layout design for the documentation and community page seemed plain > compared to the other pages of the website. Thus, included rounded background > over the links for the pages and rounded border over the section to provide > the card-like layout. This will fit with the new design for the front page. I > have created a PR regarding it with a minimal design approach however I came > up with a few more designs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15720) camel-core - Optimize calling bean with noarg method
Claus Ibsen created CAMEL-15720: --- Summary: camel-core - Optimize calling bean with noarg method Key: CAMEL-15720 URL: https://issues.apache.org/jira/browse/CAMEL-15720 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 3.7.0 When using bean language, method call, ref etc and a method name is specified and its a noarg method (or args is hardcoded) then we can optimize to do less discovery on each invocation and reuse last discovery. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-15705) camel 2.x - camel-chronicle feature install failed due to xstream-java8 version
[
https://issues.apache.org/jira/browse/CAMEL-15705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CAMEL-15705.
-
Resolution: Fixed
> camel 2.x - camel-chronicle feature install failed due to xstream-java8
> version
>
>
> Key: CAMEL-15705
> URL: https://issues.apache.org/jira/browse/CAMEL-15705
> Project: Camel
> Issue Type: Bug
> Components: osgi
>Affects Versions: 2.25.2
> Environment: Java 8
>Reporter: Xilai Dai
>Priority: Minor
> Fix For: 2.25.3
>
>
> Start karaf 4.2.9 OSGi container, execute:
> karaf@root()> feature:repo-add camel 2.25.2
> karaf@root()> feature:install camel-chronicle
> {code}
> Caused by: java.io.IOException: Error resolving artifact
> org.apache.servicemix.bundles:org.apache.servicemix.bundles.xstream-java8:jar:1.4.11.1_1:
> [Could not find artifact
> org.apache.servicemix.bundles:org.apache.servicemix.bundles.xstream-java8:jar:1.4.11.1_1
> in central (https://repo1.maven.org/maven2/)]
> {code}
> The bundle "xstream-java8" has to be corrected to "xstream".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (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
]
James Netherton updated CAMEL-15716:
Fix Version/s: 3.7.0
> 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] [Assigned] (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
]
James Netherton reassigned CAMEL-15716:
---
Assignee: James Netherton
> 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
>
> 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] [Commented] (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:comment-tabpanel=17218134#comment-17218134
]
James Netherton commented on CAMEL-15716:
-
I can take a look into this. It should be quite simple to add support for
subprotocols. In VertxWebSocketEndpoint.getWebSocket(), where the WS connection
is established with client.webSocket(), it needs to use the signature that
allows you to pass an instance of WebSocketConnectOptions, as that can hold
info about subprotocols.
> 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
>Priority: Minor
>
> 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)
