[jira] [Commented] (CAMEL-17495) camel-as2 - No support for application/xml content type

[Claus Ibsen (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476555#comment-17476555
 ] 

Claus Ibsen commented on CAMEL-17495:
-

Can you add more details about this, and is this something you would work on 
implementing?

> camel-as2 - No support for application/xml content type
> ---
>
> Key: CAMEL-17495
> URL: https://issues.apache.org/jira/browse/CAMEL-17495
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-as2
>Affects Versions: 3.14.0
>Reporter: Joey
>Priority: Minor
>
> I found that AS2 component could not support application/xml content type, 
> which is part of the requirement for AS2 message.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17495) camel-as2 - No support for application/xml content type

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-17495:

Priority: Minor  (was: Major)

> camel-as2 - No support for application/xml content type
> ---
>
> Key: CAMEL-17495
> URL: https://issues.apache.org/jira/browse/CAMEL-17495
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-as2
>Affects Versions: 3.14.0
>Reporter: Joey
>Priority: Minor
>
> I found that AS2 component could not support application/xml content type, 
> which is part of the requirement for AS2 message.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17495) camel-as2 - No support for application/xml content type

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-17495:

Summary: camel-as2 - No support for application/xml content type  (was: No 
support for application/xml content type)

> camel-as2 - No support for application/xml content type
> ---
>
> Key: CAMEL-17495
> URL: https://issues.apache.org/jira/browse/CAMEL-17495
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-as2
>Affects Versions: 3.14.0
>Reporter: Joey
>Priority: Major
>
> I found that AS2 component could not support application/xml content type, 
> which is part of the requirement for AS2 message.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (CAMEL-17492) CamelBeanPostProcessor fails if @Producer is used in EventNotifier

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned CAMEL-17492:
---

Assignee: Claus Ibsen

> CamelBeanPostProcessor fails if @Producer is used in EventNotifier
> --
>
> Key: CAMEL-17492
> URL: https://issues.apache.org/jira/browse/CAMEL-17492
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-spring-boot
>Affects Versions: 3.12.0, 3.13.0, 3.14.0
>Reporter: Michael Rambichler
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.15.0
>
>
> If you use a @Produce annotation in an EventNotifier Camel fails at startup.
> *Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
> Routebuilder.
> I have reproduced it with the spring boot example: 
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
>  
> Fails since Camel > 3.11
>  
> Initialization of bean failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error post 
> processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> 
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> post processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> at 
> org.apache.camel.spring.spi.CamelBeanPostProcessor.postProcessBeforeInitialization(CamelBeanPostProcessor.java:160)
>  ~[camel-spring-3.14.0.jar:3.14.0]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> ... 122 common frames omitted
>  
>  
> *Example*
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
> {{TestEventNotifier.java}}
>  
> {{@Component}}
> {{public class TestEventNotifier extends EventNotifierSupport {}}
> {{   @Produce("stream:out")}}
> {{   TestProducer producer;}}
> {{   @Override}}
> {{   public void notify(CamelEvent event) throws Exception {}}
> {{      System.err.println(event);}}
> {{      //producer.publish("some notification");}}
> {{   }}}
> {{}}}
> {{---}}
> {{TestProducer.java:}}
> {{import org.apache.camel.InOnly;}}
> {{@InOnly}}
> {{public interface TestProducer {}}
> {{   void publish(String event);}}
> {{}}}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17496) camel-core - Exchange events toString polish

[Claus Ibsen (Jira)]

Claus Ibsen created CAMEL-17496:
---

 Summary: camel-core - Exchange events toString polish
 Key: CAMEL-17496
 URL: https://issues.apache.org/jira/browse/CAMEL-17496
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 3.15.0


09E4FE8399FEB29-0001 exchange 
Exchange[09E4FE8399FEB29-0001] sent to: stream://out took: 0 ms.
09E4FE8399FEB29-0001 exchange completed: 
Exchange[09E4FE8399FEB29-0001]
09E4FE8399FEB29-0002 exchange created: 
Exchange[09E4FE8399FEB29-0002]
09E4FE8399FEB29-0002 exchange 
Exchange[09E4FE8399FEB29-0002] sending to: stream://out
Hello World I am invoked 3 times
09E4FE8399FEB29-0002 exchange 
Exchange[09E4FE8399FEB29-0002] sent to: stream://out took: 0 ms.
09E4FE8399FEB29-0002 exchange completed: 
Exchange[09E4FE8399FEB29-0002]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17495) No support for application/xml content type

[Joey (Jira)]

Joey created CAMEL-17495:


 Summary: No support for application/xml content type
 Key: CAMEL-17495
 URL: https://issues.apache.org/jira/browse/CAMEL-17495
 Project: Camel
  Issue Type: New Feature
  Components: camel-as2
Affects Versions: 3.14.0
Reporter: Joey


I found that AS2 component could not support application/xml content type, 
which is part of the requirement for AS2 message.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476544#comment-17476544
 ] 

ASF GitHub Bot commented on CAMEL-17154:


davsclaus merged pull request #756:
URL: https://github.com/apache/camel-website/pull/756


   


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17494) camel-spring-boot: ServiceRegistry not started

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-17494:

Issue Type: Test  (was: Bug)

> camel-spring-boot: ServiceRegistry not started
> --
>
> Key: CAMEL-17494
> URL: https://issues.apache.org/jira/browse/CAMEL-17494
> Project: Camel
>  Issue Type: Test
>  Components: camel-spring-boot-starters
>Reporter: Freeman Yue Fang
>Priority: Major
>
> we can this test failure like this
> {code}
> Expecting actual not to be null
> {code}
> Three tests affected
> ZooKeeperClusterServiceTest
> ZooKeeperServiceRegistryTest
> ConsulServiceRegistryIT 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476447#comment-17476447
 ] 

ASF GitHub Bot commented on CAMEL-17154:


github-actions[bot] commented on pull request #756:
URL: https://github.com/apache/camel-website/pull/756#issuecomment-1013500252


    Preview is available at https://pr-756--camel.netlify.app


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by 

[jira] [Commented] (CAMEL-17494) camel-spring-boot: ServiceRegistry not started

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476445#comment-17476445
 ] 

Freeman Yue Fang commented on CAMEL-17494:
--

The cause behind this is same, ServiceRegistry service(ConsulServiceRegistry 
and ZooKeeperServiceRegistry) used in test never get chance to start. If I do 
change like
{code}
final CamelContext camelContext =  context.getBean(CamelContext.class);
-final ServiceRegistry serviceRegistry = 
camelContext.hasService(ServiceRegistry.class);
+final ServiceRegistry serviceRegistry = 
context.getBean(ServiceRegistry.class);
+
 
 assertThat(serviceRegistry).isNotNull();
-
+serviceRegistry.start();
{code}
tests passed

> camel-spring-boot: ServiceRegistry not started
> --
>
> Key: CAMEL-17494
> URL: https://issues.apache.org/jira/browse/CAMEL-17494
> Project: Camel
>  Issue Type: Bug
>  Components: camel-spring-boot-starters
>Reporter: Freeman Yue Fang
>Priority: Major
>
> we can this test failure like this
> {code}
> Expecting actual not to be null
> {code}
> Three tests affected
> ZooKeeperClusterServiceTest
> ZooKeeperServiceRegistryTest
> ConsulServiceRegistryIT 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17494) camel-spring-boot: ServiceRegistry not started

[Freeman Yue Fang (Jira)]

Freeman Yue Fang created CAMEL-17494:


 Summary: camel-spring-boot: ServiceRegistry not started
 Key: CAMEL-17494
 URL: https://issues.apache.org/jira/browse/CAMEL-17494
 Project: Camel
  Issue Type: Bug
  Components: camel-spring-boot-starters
Reporter: Freeman Yue Fang


we can this test failure like this
{code}
Expecting actual not to be null
{code}
Three tests affected
ZooKeeperClusterServiceTest
ZooKeeperServiceRegistryTest
ConsulServiceRegistryIT 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476421#comment-17476421
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 opened a new pull request #756:
URL: https://github.com/apache/camel-website/pull/756


   I messed up the external image link syntax, and fixed it in this merge 
request.


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by Atlassian Jira

[jira] [Commented] (CAMEL-17492) CamelBeanPostProcessor fails if @Producer is used in EventNotifier

[Michael Rambichler (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476345#comment-17476345
 ] 

Michael Rambichler commented on CAMEL-17492:


[~davsclaus] i suppose so. But what change between 3.11 -> 3.12 leads to that. 
spring version is the same.

> CamelBeanPostProcessor fails if @Producer is used in EventNotifier
> --
>
> Key: CAMEL-17492
> URL: https://issues.apache.org/jira/browse/CAMEL-17492
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-spring-boot
>Affects Versions: 3.12.0, 3.13.0, 3.14.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.15.0
>
>
> If you use a @Produce annotation in an EventNotifier Camel fails at startup.
> *Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
> Routebuilder.
> I have reproduced it with the spring boot example: 
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
>  
> Fails since Camel > 3.11
>  
> Initialization of bean failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error post 
> processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> 
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> post processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> at 
> org.apache.camel.spring.spi.CamelBeanPostProcessor.postProcessBeforeInitialization(CamelBeanPostProcessor.java:160)
>  ~[camel-spring-3.14.0.jar:3.14.0]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> ... 122 common frames omitted
>  
>  
> *Example*
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
> {{TestEventNotifier.java}}
>  
> {{@Component}}
> {{public class TestEventNotifier extends EventNotifierSupport {}}
> {{   @Produce("stream:out")}}
> {{   TestProducer producer;}}
> {{   @Override}}
> {{   public void notify(CamelEvent event) throws Exception {}}
> {{      System.err.println(event);}}
> {{      //producer.publish("some notification");}}
> {{   }}}
> {{}}}
> {{---}}
> {{TestProducer.java:}}
> {{import org.apache.camel.InOnly;}}
> {{@InOnly}}
> {{public interface TestProducer {}}
> {{   void publish(String event);}}
> {{}}}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17493) camel-kafka: safe unsubscription should ignore safe exceptions

[Otavio Rodolfo Piske (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Otavio Rodolfo Piske updated CAMEL-17493:
-
Fix Version/s: 3.15.0
   3.14.0

> camel-kafka: safe unsubscription should ignore safe exceptions
> --
>
> Key: CAMEL-17493
> URL: https://issues.apache.org/jira/browse/CAMEL-17493
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Fix For: 3.14.0, 3.15.0
>
>
> When unsubscribing from Kafka, the code passes to the handler any exception 
> that it receives. However, for some scenarios (i.e.: when the consumer is 
> closed) it should be safe to ignore it.
>  
> See: [https://github.com/apache/camel/pull/6751#issuecomment-1013109427]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17489) camel-kafka - Unsubscribing fails due to already closed consumer

[Otavio Rodolfo Piske (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476293#comment-17476293
 ] 

Otavio Rodolfo Piske commented on CAMEL-17489:
--

FYI: I logged CAMEL-17493 for the safeUnsubscribe change.

 

> camel-kafka - Unsubscribing fails due to already closed consumer
> 
>
> Key: CAMEL-17489
> URL: https://issues.apache.org/jira/browse/CAMEL-17489
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 3.14.0
>Reporter: Rafał Gała
>Priority: Minor
> Fix For: 3.15.0
>
>
> In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
> method, the consumer is closed in finally block:
> {code:java}
> finally {
> lock.unlock();
> // only close if not retry
> if (!isRetrying()) {
> LOG.debug("Closing consumer {}", threadId);
> IOHelper.close(consumer);
> }
> } {code}
>  and then unsubscribing in *run* method fails with "This consumer has already 
> been closed"
> {code:java}
> LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
> threadId, topicName);
> safeUnsubscribe();
> IOHelper.close(consumer); {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17493) camel-kafka: safe unsubscription should ignore safe exceptions

[Otavio Rodolfo Piske (Jira)]

Otavio Rodolfo Piske created CAMEL-17493:


 Summary: camel-kafka: safe unsubscription should ignore safe 
exceptions
 Key: CAMEL-17493
 URL: https://issues.apache.org/jira/browse/CAMEL-17493
 Project: Camel
  Issue Type: Bug
  Components: camel-kafka
Reporter: Otavio Rodolfo Piske
Assignee: Otavio Rodolfo Piske


When unsubscribing from Kafka, the code passes to the handler any exception 
that it receives. However, for some scenarios (i.e.: when the consumer is 
closed) it should be safe to ignore it.

 

See: [https://github.com/apache/camel/pull/6751#issuecomment-1013109427]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17492) CamelBeanPostProcessor fails if @Producer is used in EventNotifier

[Claus Ibsen (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476291#comment-17476291
 ] 

Claus Ibsen commented on CAMEL-17492:
-

Its *** spring that creates this class too soon, as camel context is not 
created first - the class is @component so spring decides the order they are 
created

> CamelBeanPostProcessor fails if @Producer is used in EventNotifier
> --
>
> Key: CAMEL-17492
> URL: https://issues.apache.org/jira/browse/CAMEL-17492
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-spring-boot
>Affects Versions: 3.12.0, 3.13.0, 3.14.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.15.0
>
>
> If you use a @Produce annotation in an EventNotifier Camel fails at startup.
> *Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
> Routebuilder.
> I have reproduced it with the spring boot example: 
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
>  
> Fails since Camel > 3.11
>  
> Initialization of bean failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error post 
> processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> 
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> post processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> at 
> org.apache.camel.spring.spi.CamelBeanPostProcessor.postProcessBeforeInitialization(CamelBeanPostProcessor.java:160)
>  ~[camel-spring-3.14.0.jar:3.14.0]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> ... 122 common frames omitted
>  
>  
> *Example*
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
> {{TestEventNotifier.java}}
>  
> {{@Component}}
> {{public class TestEventNotifier extends EventNotifierSupport {}}
> {{   @Produce("stream:out")}}
> {{   TestProducer producer;}}
> {{   @Override}}
> {{   public void notify(CamelEvent event) throws Exception {}}
> {{      System.err.println(event);}}
> {{      //producer.publish("some notification");}}
> {{   }}}
> {{}}}
> {{---}}
> {{TestProducer.java:}}
> {{import org.apache.camel.InOnly;}}
> {{@InOnly}}
> {{public interface TestProducer {}}
> {{   void publish(String event);}}
> {{}}}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476270#comment-17476270
 ] 

ASF GitHub Bot commented on CAMEL-17154:


zregvart merged pull request #753:
URL: https://github.com/apache/camel-website/pull/753


   


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17492) CamelBeanPostProcessor fails if @Producer is used in EventNotifier

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-17492:

Component/s: camel-core
 camel-spring-boot

> CamelBeanPostProcessor fails if @Producer is used in EventNotifier
> --
>
> Key: CAMEL-17492
> URL: https://issues.apache.org/jira/browse/CAMEL-17492
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-spring-boot
>Affects Versions: 3.12.0, 3.13.0, 3.14.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.15.0
>
>
> If you use a @Produce annotation in an EventNotifier Camel fails at startup.
> *Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
> Routebuilder.
> I have reproduced it with the spring boot example: 
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
>  
> Fails since Camel > 3.11
>  
> Initialization of bean failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error post 
> processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> 
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> post processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> at 
> org.apache.camel.spring.spi.CamelBeanPostProcessor.postProcessBeforeInitialization(CamelBeanPostProcessor.java:160)
>  ~[camel-spring-3.14.0.jar:3.14.0]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> ... 122 common frames omitted
>  
>  
> *Example*
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
> {{TestEventNotifier.java}}
>  
> {{@Component}}
> {{public class TestEventNotifier extends EventNotifierSupport {}}
> {{   @Produce("stream:out")}}
> {{   TestProducer producer;}}
> {{   @Override}}
> {{   public void notify(CamelEvent event) throws Exception {}}
> {{      System.err.println(event);}}
> {{      //producer.publish("some notification");}}
> {{   }}}
> {{}}}
> {{---}}
> {{TestProducer.java:}}
> {{import org.apache.camel.InOnly;}}
> {{@InOnly}}
> {{public interface TestProducer {}}
> {{   void publish(String event);}}
> {{}}}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17478) camel-aws2-s3 Operation downloadLink requires aws credentails even if client is aurowired from registry

[Claus Ibsen (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476268#comment-17476268
 ] 

Claus Ibsen commented on CAMEL-17478:
-

Thanks PR merged

> camel-aws2-s3 Operation downloadLink requires aws credentails even if client 
> is aurowired from registry
> ---
>
> Key: CAMEL-17478
> URL: https://issues.apache.org/jira/browse/CAMEL-17478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-aws2
>Affects Versions: 3.15.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
> Fix For: 3.15.0
>
>
> It is possible to use "custom" aws s3 client by providing a client in 
> registry.
> If operation "downloadLink" is executed with a component with autowired 
> client, it fails.
> I understand that creation of a link is not possible without credentials and 
> the only solution for user is to provide credentials (in the same way as in 
> [test|https://github.com/apache/camel/blob/main/components/camel-aws/camel-aws2-s3/src/test/java/org/apache/camel/component/aws2/s3/integration/S3CreateDownloadLinkOperationIT.java#L84])
> I think that this behavior should be mentioned in the documentation and 
> covered by the test. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17492) CamelBeanPostProcessor fails if @Producer is used in EventNotifier

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-17492:

Fix Version/s: 3.15.0

> CamelBeanPostProcessor fails if @Producer is used in EventNotifier
> --
>
> Key: CAMEL-17492
> URL: https://issues.apache.org/jira/browse/CAMEL-17492
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.12.0, 3.13.0, 3.14.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.15.0
>
>
> If you use a @Produce annotation in an EventNotifier Camel fails at startup.
> *Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
> Routebuilder.
> I have reproduced it with the spring boot example: 
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
>  
> Fails since Camel > 3.11
>  
> Initialization of bean failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error post 
> processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> 
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> post processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> at 
> org.apache.camel.spring.spi.CamelBeanPostProcessor.postProcessBeforeInitialization(CamelBeanPostProcessor.java:160)
>  ~[camel-spring-3.14.0.jar:3.14.0]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> ... 122 common frames omitted
>  
>  
> *Example*
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
> {{TestEventNotifier.java}}
>  
> {{@Component}}
> {{public class TestEventNotifier extends EventNotifierSupport {}}
> {{   @Produce("stream:out")}}
> {{   TestProducer producer;}}
> {{   @Override}}
> {{   public void notify(CamelEvent event) throws Exception {}}
> {{      System.err.println(event);}}
> {{      //producer.publish("some notification");}}
> {{   }}}
> {{}}}
> {{---}}
> {{TestProducer.java:}}
> {{import org.apache.camel.InOnly;}}
> {{@InOnly}}
> {{public interface TestProducer {}}
> {{   void publish(String event);}}
> {{}}}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (CAMEL-17478) camel-aws2-s3 Operation downloadLink requires aws credentails even if client is aurowired from registry

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-17478.
-
Resolution: Fixed

> camel-aws2-s3 Operation downloadLink requires aws credentails even if client 
> is aurowired from registry
> ---
>
> Key: CAMEL-17478
> URL: https://issues.apache.org/jira/browse/CAMEL-17478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-aws2
>Affects Versions: 3.15.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
> Fix For: 3.15.0
>
>
> It is possible to use "custom" aws s3 client by providing a client in 
> registry.
> If operation "downloadLink" is executed with a component with autowired 
> client, it fails.
> I understand that creation of a link is not possible without credentials and 
> the only solution for user is to provide credentials (in the same way as in 
> [test|https://github.com/apache/camel/blob/main/components/camel-aws/camel-aws2-s3/src/test/java/org/apache/camel/component/aws2/s3/integration/S3CreateDownloadLinkOperationIT.java#L84])
> I think that this behavior should be mentioned in the documentation and 
> covered by the test. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17491) camel-openapi-java - Operation paths are incorrect if contextPath is set

[Claus Ibsen (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476267#comment-17476267
 ] 

Claus Ibsen commented on CAMEL-17491:
-

[~klease78] you have fixed before in openapi, wonder if you could take a look 
later?

> camel-openapi-java - Operation paths are incorrect if contextPath is set
> 
>
> Key: CAMEL-17491
> URL: https://issues.apache.org/jira/browse/CAMEL-17491
> Project: Camel
>  Issue Type: Bug
>  Components: camel-openapi-java
>Affects Versions: 3.13.0, 3.14.0
>Reporter: James Netherton
>Priority: Major
> Fix For: 3.15.0
>
>
> Consider this REST configuration:
> {code}
> restConfiguration()
> .host("localhost")
> .apiHost("localhost")
> .contextPath("/api")
> .port(8080)
> .apiContextPath("/api-docs");
> rest("/service")
> .get("/testing").description("Test Service")
> .outType(String.class)
> .route().setBody().constant("Hello World");
> {code}
> The 'paths' object in the generated OpenAPI document is incorrect. It should 
> not have the '/api' context path prefix.
> {code}
> {
>   "openapi" : "3.0.2",
>   "info" : { },
>   "servers" : [ {
> "url" : "/api"
>   } ],
>   "paths" : {
> "/api/service/testing" : {
>   "get" : {
> "tags" : [ "/service" ],
> "responses" : {
>   "200" : { }
> },
> "operationId" : "verb1",
> "summary" : "Test Service"
>   }
> }
>   },
>   "components" : { },
>   "tags" : [ {
> "name" : "/service"
>   } ]
> }
> {code}
> The OpenAPI spec states: 
> "Unless specified otherwise, all properties that are URLs MAY be relative 
> references as defined by RFC3986. Relative references are resolved using the 
> URLs defined in the Server Object as a Base URI.".
> If you try to execute the service in the Swagger UI, then it tries to hit 
> http://localhost:8080/api/api/service/testing (duplicate /api/api in the 
> path).
> Maybe the code we had before CAMEL-17063 was implemented was more correct?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17491) camel-openapi-java - Operation paths are incorrect if contextPath is set

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-17491:

Fix Version/s: 3.15.0

> camel-openapi-java - Operation paths are incorrect if contextPath is set
> 
>
> Key: CAMEL-17491
> URL: https://issues.apache.org/jira/browse/CAMEL-17491
> Project: Camel
>  Issue Type: Bug
>  Components: camel-openapi-java
>Affects Versions: 3.13.0, 3.14.0
>Reporter: James Netherton
>Priority: Major
> Fix For: 3.15.0
>
>
> Consider this REST configuration:
> {code}
> restConfiguration()
> .host("localhost")
> .apiHost("localhost")
> .contextPath("/api")
> .port(8080)
> .apiContextPath("/api-docs");
> rest("/service")
> .get("/testing").description("Test Service")
> .outType(String.class)
> .route().setBody().constant("Hello World");
> {code}
> The 'paths' object in the generated OpenAPI document is incorrect. It should 
> not have the '/api' context path prefix.
> {code}
> {
>   "openapi" : "3.0.2",
>   "info" : { },
>   "servers" : [ {
> "url" : "/api"
>   } ],
>   "paths" : {
> "/api/service/testing" : {
>   "get" : {
> "tags" : [ "/service" ],
> "responses" : {
>   "200" : { }
> },
> "operationId" : "verb1",
> "summary" : "Test Service"
>   }
> }
>   },
>   "components" : { },
>   "tags" : [ {
> "name" : "/service"
>   } ]
> }
> {code}
> The OpenAPI spec states: 
> "Unless specified otherwise, all properties that are URLs MAY be relative 
> references as defined by RFC3986. Relative references are resolved using the 
> URLs defined in the Server Object as a Base URI.".
> If you try to execute the service in the Swagger UI, then it tries to hit 
> http://localhost:8080/api/api/service/testing (duplicate /api/api in the 
> path).
> Maybe the code we had before CAMEL-17063 was implemented was more correct?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (CAMEL-17490) camel-debezium - Upgrade to 1.8

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-17490.
-
Fix Version/s: 3.15.0
 Assignee: Claus Ibsen
   Resolution: Fixed

> camel-debezium - Upgrade to 1.8
> ---
>
> Key: CAMEL-17490
> URL: https://issues.apache.org/jira/browse/CAMEL-17490
> Project: Camel
>  Issue Type: Dependency upgrade
>  Components: camel-debezium
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.15.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17492) CamelBeanPostProcessor fails if @Producer is used in EventNotifier

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-17492:

Priority: Minor  (was: Major)

> CamelBeanPostProcessor fails if @Producer is used in EventNotifier
> --
>
> Key: CAMEL-17492
> URL: https://issues.apache.org/jira/browse/CAMEL-17492
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.12.0, 3.13.0, 3.14.0
>Reporter: Michael Rambichler
>Priority: Minor
>
> If you use a @Produce annotation in an EventNotifier Camel fails at startup.
> *Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
> Routebuilder.
> I have reproduced it with the spring boot example: 
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
>  
> Fails since Camel > 3.11
>  
> Initialization of bean failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error post 
> processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> 
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> post processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> at 
> org.apache.camel.spring.spi.CamelBeanPostProcessor.postProcessBeforeInitialization(CamelBeanPostProcessor.java:160)
>  ~[camel-spring-3.14.0.jar:3.14.0]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> ... 122 common frames omitted
>  
>  
> *Example*
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
> {{TestEventNotifier.java}}
>  
> {{@Component}}
> {{public class TestEventNotifier extends EventNotifierSupport {}}
> {{   @Produce("stream:out")}}
> {{   TestProducer producer;}}
> {{   @Override}}
> {{   public void notify(CamelEvent event) throws Exception {}}
> {{      System.err.println(event);}}
> {{      //producer.publish("some notification");}}
> {{   }}}
> {{}}}
> {{---}}
> {{TestProducer.java:}}
> {{import org.apache.camel.InOnly;}}
> {{@InOnly}}
> {{public interface TestProducer {}}
> {{   void publish(String event);}}
> {{}}}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476258#comment-17476258
 ] 

ASF GitHub Bot commented on CAMEL-17154:


github-actions[bot] commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013269805


    Preview is available at https://pr-753--camel.netlify.app


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476252#comment-17476252
 ] 

ASF GitHub Bot commented on CAMEL-17154:


zregvart commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013263176


   GitHub workflow seems to have hanged at the very end. Checks look good now. 
Let's give it a bit and see if we need to retry to get a preview or we can 
merge and touch-up on after it gets published?


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> 

[jira] [Updated] (CAMEL-17492) CamelBeanPostProcessor fails if @Producer is used in EventNotifier

[Michael Rambichler (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Rambichler updated CAMEL-17492:
---
Description: 
If you use a @Produce annotation in an EventNotifier Camel fails at startup.

*Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
Routebuilder.
I have reproduced it with the spring boot example: 
[https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
and added the EventNotifier below.
 
Fails since Camel > 3.11
 
Initialization of bean failed; nested exception is 
org.springframework.beans.factory.BeanCreationException: Error post processing 
bean: testEventNotifier; nested exception is java.lang.NullPointerException

Caused by: org.springframework.beans.factory.BeanCreationException: Error post 
processing bean: testEventNotifier; nested exception is 
java.lang.NullPointerException
at 
org.apache.camel.spring.spi.CamelBeanPostProcessor.postProcessBeforeInitialization(CamelBeanPostProcessor.java:160)
 ~[camel-spring-3.14.0.jar:3.14.0]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440)
 ~[spring-beans-5.3.14.jar:5.3.14]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
 ~[spring-beans-5.3.14.jar:5.3.14]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)
 ~[spring-beans-5.3.14.jar:5.3.14]
... 122 common frames omitted

 

 

*Example*

[https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
and added the EventNotifier below.

{{TestEventNotifier.java}}

 

{{@Component}}
{{public class TestEventNotifier extends EventNotifierSupport {}}

{{   @Produce("stream:out")}}
{{   TestProducer producer;}}

{{   @Override}}
{{   public void notify(CamelEvent event) throws Exception {}}
{{      System.err.println(event);}}
{{      //producer.publish("some notification");}}
{{   }}}
{{}}}

{{---}}

{{TestProducer.java:}}

{{import org.apache.camel.InOnly;}}

{{@InOnly}}
{{public interface TestProducer {}}
{{   void publish(String event);}}
{{}}}

 

  was:
If you use a @Produce annotation in an EventNotifier Camel fails at startup.


*Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
Routebuilder.
I have reproduced it with the spring boot example: 
[https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
and added the EventNotifier below.
 
Fails since Camel > 3.11
 
Initialization of bean failed; nested exception is 
org.springframework.beans.factory.BeanCreationException: Error post processing 
bean: testEventNotifier; nested exception is java.lang.NullPointerException

Caused by: org.springframework.beans.factory.BeanCreationException: Error post 
processing bean: testEventNotifier; nested exception is 
java.lang.NullPointerException
at 
org.apache.camel.spring.spi.CamelBeanPostProcessor.postProcessBeforeInitialization(CamelBeanPostProcessor.java:160)
 ~[camel-spring-3.14.0.jar:3.14.0]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440)
 ~[spring-beans-5.3.14.jar:5.3.14]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
 ~[spring-beans-5.3.14.jar:5.3.14]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)
 ~[spring-beans-5.3.14.jar:5.3.14]
... 122 common frames omitted


> CamelBeanPostProcessor fails if @Producer is used in EventNotifier
> --
>
> Key: CAMEL-17492
> URL: https://issues.apache.org/jira/browse/CAMEL-17492
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.12.0, 3.13.0, 3.14.0
>Reporter: Michael Rambichler
>Priority: Major
>
> If you use a @Produce annotation in an EventNotifier Camel fails at startup.
> *Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
> Routebuilder.
> I have reproduced it with the spring boot example: 
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
>  
> Fails since Camel > 3.11
>  
> Initialization of bean failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error post 
> processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> 
> Caused by: org.springframework.beans.factory.BeanCreationException: 

[jira] [Updated] (CAMEL-17492) CamelBeanPostProcessor fails if @Producer is used in EventNotifier

[Michael Rambichler (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Rambichler updated CAMEL-17492:
---
Environment: (was: {{TestEventNotifier.java}}

 

{{@Component}}
{{public class TestEventNotifier extends EventNotifierSupport {}}

{{   @Produce("stream:out")}}
{{   TestProducer producer;}}

{{   @Override}}
{{   public void notify(CamelEvent event) throws Exception {}}
{{      System.err.println(event);}}
{{      //producer.publish("some notification");}}
{{   }}}
{{}}}

{{---}}

{{TestProducer.java:}}

{{import org.apache.camel.InOnly;}}

{{@InOnly}}
{{public interface TestProducer {}}
{{   void publish(String event);}}
{{}}})

> CamelBeanPostProcessor fails if @Producer is used in EventNotifier
> --
>
> Key: CAMEL-17492
> URL: https://issues.apache.org/jira/browse/CAMEL-17492
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 3.12.0, 3.13.0, 3.14.0
>Reporter: Michael Rambichler
>Priority: Major
>
> If you use a @Produce annotation in an EventNotifier Camel fails at startup.
> *Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
> Routebuilder.
> I have reproduced it with the spring boot example: 
> [https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
> and added the EventNotifier below.
>  
> Fails since Camel > 3.11
>  
> Initialization of bean failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error post 
> processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> 
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> post processing bean: testEventNotifier; nested exception is 
> java.lang.NullPointerException
> at 
> org.apache.camel.spring.spi.CamelBeanPostProcessor.postProcessBeforeInitialization(CamelBeanPostProcessor.java:160)
>  ~[camel-spring-3.14.0.jar:3.14.0]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)
>  ~[spring-beans-5.3.14.jar:5.3.14]
> ... 122 common frames omitted



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17492) CamelBeanPostProcessor fails if @Producer is used in EventNotifier

[Michael Rambichler (Jira)]

Michael Rambichler created CAMEL-17492:
--

 Summary: CamelBeanPostProcessor fails if @Producer is used in 
EventNotifier
 Key: CAMEL-17492
 URL: https://issues.apache.org/jira/browse/CAMEL-17492
 Project: Camel
  Issue Type: Bug
Affects Versions: 3.14.0, 3.13.0, 3.12.0
 Environment: {{TestEventNotifier.java}}

 

{{@Component}}
{{public class TestEventNotifier extends EventNotifierSupport {}}

{{   @Produce("stream:out")}}
{{   TestProducer producer;}}

{{   @Override}}
{{   public void notify(CamelEvent event) throws Exception {}}
{{      System.err.println(event);}}
{{      //producer.publish("some notification");}}
{{   }}}
{{}}}

{{---}}

{{TestProducer.java:}}

{{import org.apache.camel.InOnly;}}

{{@InOnly}}
{{public interface TestProducer {}}
{{   void publish(String event);}}
{{}}}
Reporter: Michael Rambichler


If you use a @Produce annotation in an EventNotifier Camel fails at startup.


*Reproducable with:* Custom EventNotifier in a plain Camel + Springboot 
Routebuilder.
I have reproduced it with the spring boot example: 
[https://github.com/apache/camel-spring-boot-examples/tree/main/spring-boot] 
and added the EventNotifier below.
 
Fails since Camel > 3.11
 
Initialization of bean failed; nested exception is 
org.springframework.beans.factory.BeanCreationException: Error post processing 
bean: testEventNotifier; nested exception is java.lang.NullPointerException

Caused by: org.springframework.beans.factory.BeanCreationException: Error post 
processing bean: testEventNotifier; nested exception is 
java.lang.NullPointerException
at 
org.apache.camel.spring.spi.CamelBeanPostProcessor.postProcessBeforeInitialization(CamelBeanPostProcessor.java:160)
 ~[camel-spring-3.14.0.jar:3.14.0]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440)
 ~[spring-beans-5.3.14.jar:5.3.14]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796)
 ~[spring-beans-5.3.14.jar:5.3.14]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)
 ~[spring-beans-5.3.14.jar:5.3.14]
... 122 common frames omitted



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17491) camel-openapi-java - Operation paths are incorrect if contextPath is set

[James Netherton (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476178#comment-17476178
 ] 

James Netherton commented on CAMEL-17491:
-

Originally reported here:

https://github.com/apache/camel-quarkus/issues/3457

> camel-openapi-java - Operation paths are incorrect if contextPath is set
> 
>
> Key: CAMEL-17491
> URL: https://issues.apache.org/jira/browse/CAMEL-17491
> Project: Camel
>  Issue Type: Bug
>  Components: camel-openapi-java
>Affects Versions: 3.13.0, 3.14.0
>Reporter: James Netherton
>Priority: Major
>
> Consider this REST configuration:
> {code}
> restConfiguration()
> .host("localhost")
> .apiHost("localhost")
> .contextPath("/api")
> .port(8080)
> .apiContextPath("/api-docs");
> rest("/service")
> .get("/testing").description("Test Service")
> .outType(String.class)
> .route().setBody().constant("Hello World");
> {code}
> The 'paths' object in the generated OpenAPI document is incorrect. It should 
> not have the '/api' context path prefix.
> {code}
> {
>   "openapi" : "3.0.2",
>   "info" : { },
>   "servers" : [ {
> "url" : "/api"
>   } ],
>   "paths" : {
> "/api/service/testing" : {
>   "get" : {
> "tags" : [ "/service" ],
> "responses" : {
>   "200" : { }
> },
> "operationId" : "verb1",
> "summary" : "Test Service"
>   }
> }
>   },
>   "components" : { },
>   "tags" : [ {
> "name" : "/service"
>   } ]
> }
> {code}
> The OpenAPI spec states: 
> "Unless specified otherwise, all properties that are URLs MAY be relative 
> references as defined by RFC3986. Relative references are resolved using the 
> URLs defined in the Server Object as a Base URI.".
> If you try to execute the service in the Swagger UI, then it tries to hit 
> http://localhost:8080/api/api/service/testing (duplicate /api/api in the 
> path).
> Maybe the code we had before CAMEL-17063 was implemented was more correct?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17491) camel-openapi-java - Operation paths are incorrect if contextPath is set

[James Netherton (Jira)]

James Netherton created CAMEL-17491:
---

 Summary: camel-openapi-java - Operation paths are incorrect if 
contextPath is set
 Key: CAMEL-17491
 URL: https://issues.apache.org/jira/browse/CAMEL-17491
 Project: Camel
  Issue Type: Bug
  Components: camel-openapi-java
Affects Versions: 3.14.0, 3.13.0
Reporter: James Netherton


Consider this REST configuration:

{code}
restConfiguration()
.host("localhost")
.apiHost("localhost")
.contextPath("/api")
.port(8080)
.apiContextPath("/api-docs");


rest("/service")
.get("/testing").description("Test Service")
.outType(String.class)
.route().setBody().constant("Hello World");
{code}

The 'paths' object in the generated OpenAPI document is incorrect. It should 
not have the '/api' context path prefix.

{code}
{
  "openapi" : "3.0.2",
  "info" : { },
  "servers" : [ {
"url" : "/api"
  } ],
  "paths" : {
"/api/service/testing" : {
  "get" : {
"tags" : [ "/service" ],
"responses" : {
  "200" : { }
},
"operationId" : "verb1",
"summary" : "Test Service"
  }
}
  },
  "components" : { },
  "tags" : [ {
"name" : "/service"
  } ]
}
{code}

The OpenAPI spec states: 

"Unless specified otherwise, all properties that are URLs MAY be relative 
references as defined by RFC3986. Relative references are resolved using the 
URLs defined in the Server Object as a Base URI.".

If you try to execute the service in the Swagger UI, then it tries to hit 
http://localhost:8080/api/api/service/testing (duplicate /api/api in the path).

Maybe the code we had before CAMEL-17063 was implemented was more correct?




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17490) camel-debezium - Upgrade to 1.8

[Claus Ibsen (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476151#comment-17476151
 ] 

Claus Ibsen commented on CAMEL-17490:
-

It may be that this requires kafka 3.0 clients

> camel-debezium - Upgrade to 1.8
> ---
>
> Key: CAMEL-17490
> URL: https://issues.apache.org/jira/browse/CAMEL-17490
> Project: Camel
>  Issue Type: Dependency upgrade
>  Components: camel-debezium
>Reporter: Claus Ibsen
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17489) camel-kafka - Unsubscribing fails due to already closed consumer

[Jira]

[ 
https://issues.apache.org/jira/browse/CAMEL-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476149#comment-17476149
 ] 

Rafał Gała commented on CAMEL-17489:


My solution will only make sure the unsubscribe is called before a consumer 
instance is called so it will most probably not prevent the error from 
occuring. I think that to prevent this error from occuring a boolean variable 
should be created and set to true after a consumer has been closed. The 
variable would then be checked inside *safeUnsubscribe* to prevent calls to 
unsubscribe on an already closed consumer.

 

What I could also try is to introduce a check in *safeUnsubscribe* method that 
would check a result of *consumer.subscription()* and call unsubscribe only in 
a case where non empty set has been returned. I could also introduce a boolean 
variable that I would set to true after first call to unsubscribe to prevent 
multiple calls.

 

Let me know what you think and I'll make changes in the code :)

> camel-kafka - Unsubscribing fails due to already closed consumer
> 
>
> Key: CAMEL-17489
> URL: https://issues.apache.org/jira/browse/CAMEL-17489
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 3.14.0
>Reporter: Rafał Gała
>Priority: Minor
> Fix For: 3.15.0
>
>
> In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
> method, the consumer is closed in finally block:
> {code:java}
> finally {
> lock.unlock();
> // only close if not retry
> if (!isRetrying()) {
> LOG.debug("Closing consumer {}", threadId);
> IOHelper.close(consumer);
> }
> } {code}
>  and then unsubscribing in *run* method fails with "This consumer has already 
> been closed"
> {code:java}
> LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
> threadId, topicName);
> safeUnsubscribe();
> IOHelper.close(consumer); {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17490) camel-debezium - Upgrade to 1.8

[Claus Ibsen (Jira)]

Claus Ibsen created CAMEL-17490:
---

 Summary: camel-debezium - Upgrade to 1.8
 Key: CAMEL-17490
 URL: https://issues.apache.org/jira/browse/CAMEL-17490
 Project: Camel
  Issue Type: Dependency upgrade
  Components: camel-debezium
Reporter: Claus Ibsen






--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (CAMEL-17478) camel-aws2-s3 Operation downloadLink requires aws credentails even if client is aurowired from registry

[Jiri Ondrusek (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476039#comment-17476039
 ] 

Jiri Ondrusek edited comment on CAMEL-17478 at 1/14/22, 1:21 PM:
-

-I looked into the issue and because the client could be autowired, there is no 
way how to get credentials, which are required for downloadLink operation other 
then providing them as parameters. The small change in the doc explains it and 
it is all needed as a solution (#1).-

-I can see one small improvement. In case that s3 client is created via 
component (aws2 credentials are passed into the component), credentials might 
be used instead of parameters for the operation. But it will create an 
inconsistency.-
 * -We could define 2 ways how to get credentials for DownloadLink operation:-

 # -if user provides aws credentials as parameters (current state), parameters 
will be used-
 # -if parameters are not provided for operation: If aws credentials are 
defined for the component: credentials can be reused for downloadLink. (This 
could make the usage of the component a little bit easier). If client is 
autowired, endpoint will fail-

I just discovered that current implementation behaves exactly as I described 
above. I'll rephrase the doc (very slightly) and add junit test covering the 
test case with client from registry. 


was (Author: jondruse):
I looked into the issue and because the client could be autowired, there is no 
way how to get credentials, which are required for downloadLink operation other 
then providing them as parameters. The small change in the doc explains it and 
it is all needed as a solution (#1).

I can see one small improvement. In case that s3 client is created via 
component (aws2 credentials are passed into the component), credentials might 
be used instead of parameters for the operation. But it will create an 
inconsistency.
* We could define 2 ways how to get credentials for DownloadLink operation:
# if user provides aws credentials as parameters (current state), parameters 
will be used 
# if parameters are not provided for operation: If aws credentials are defined 
for the component - credentials can be reused for downloadLink. (This could 
make the usage of the component a little bit easier).  If client is autowired, 
endpoint will fail. 

[~davsclaus] Should I add such behavior?

> camel-aws2-s3 Operation downloadLink requires aws credentails even if client 
> is aurowired from registry
> ---
>
> Key: CAMEL-17478
> URL: https://issues.apache.org/jira/browse/CAMEL-17478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-aws2
>Affects Versions: 3.15.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
> Fix For: 3.15.0
>
>
> It is possible to use "custom" aws s3 client by providing a client in 
> registry.
> If operation "downloadLink" is executed with a component with autowired 
> client, it fails.
> I understand that creation of a link is not possible without credentials and 
> the only solution for user is to provide credentials (in the same way as in 
> [test|https://github.com/apache/camel/blob/main/components/camel-aws/camel-aws2-s3/src/test/java/org/apache/camel/component/aws2/s3/integration/S3CreateDownloadLinkOperationIT.java#L84])
> I think that this behavior should be mentioned in the documentation and 
> covered by the test. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17489) camel-kafka - Unsubscribing fails due to already closed consumer

[Claus Ibsen (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476139#comment-17476139
 ] 

Claus Ibsen commented on CAMEL-17489:
-

So with your PR then you do not see this exception anymore?

I think the safeUnsubscribe method should catch IllegalStateException and then 
catch
throw new IllegalStateException("This consumer has already been closed.");
As that is what kafka throws on purpose.

And you cannot know if its closed already, as there are no method like 
isClosed()

> camel-kafka - Unsubscribing fails due to already closed consumer
> 
>
> Key: CAMEL-17489
> URL: https://issues.apache.org/jira/browse/CAMEL-17489
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 3.14.0
>Reporter: Rafał Gała
>Priority: Minor
>
> In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
> method, the consumer is closed in finally block:
> {code:java}
> finally {
> lock.unlock();
> // only close if not retry
> if (!isRetrying()) {
> LOG.debug("Closing consumer {}", threadId);
> IOHelper.close(consumer);
> }
> } {code}
>  and then unsubscribing in *run* method fails with "This consumer has already 
> been closed"
> {code:java}
> LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
> threadId, topicName);
> safeUnsubscribe();
> IOHelper.close(consumer); {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17489) camel-kafka - Unsubscribing fails due to already closed consumer

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-17489:

Fix Version/s: 3.15.0

> camel-kafka - Unsubscribing fails due to already closed consumer
> 
>
> Key: CAMEL-17489
> URL: https://issues.apache.org/jira/browse/CAMEL-17489
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 3.14.0
>Reporter: Rafał Gała
>Priority: Minor
> Fix For: 3.15.0
>
>
> In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
> method, the consumer is closed in finally block:
> {code:java}
> finally {
> lock.unlock();
> // only close if not retry
> if (!isRetrying()) {
> LOG.debug("Closing consumer {}", threadId);
> IOHelper.close(consumer);
> }
> } {code}
>  and then unsubscribing in *run* method fails with "This consumer has already 
> been closed"
> {code:java}
> LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
> threadId, topicName);
> safeUnsubscribe();
> IOHelper.close(consumer); {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (CAMEL-17488) camel-cloudevent - Drop old 0.x specs

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-17488.
-
Resolution: Fixed

> camel-cloudevent - Drop old 0.x specs
> -
>
> Key: CAMEL-17488
> URL: https://issues.apache.org/jira/browse/CAMEL-17488
> Project: Camel
>  Issue Type: Improvement
>Affects Versions: 3.15.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.15.0
>
>
> Ported over camel-cloudevents from camel-k-runtime
> The only specs online are 1.0.0 and 1.0.1. So lets remove the old 0.1 0.2 and 
> 0.3 specs



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (CAMEL-15275) Create camel-knative component in main Camel components based on camel-knative for camel-k

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-15275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-15275.
-
Resolution: Fixed

> Create camel-knative component in main Camel components based on 
> camel-knative for camel-k 
> ---
>
> Key: CAMEL-15275
> URL: https://issues.apache.org/jira/browse/CAMEL-15275
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 3.4.0
>Reporter: Omar Al-Safi
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.15.0
>
>
> Currently we have [{{camel-knative}} 
> component|https://github.com/apache/camel-k-runtime/tree/master/camel-knative]
>  in camel-k that enables camel routes deployed in with camel-k to interact 
> with knative components like eventing. However, currently it is only 
> exclusive to camel-k, hence it will make sense to bring/create this component 
> as part of the main Camel components in order in order to enable non-camel-k 
> routes that deployed with knative (e.g: camel-quarkus, camel-spring-boot) to 
> utilize and interact in kantive. 
> FYI [~davsclaus] [~lb]] thoughts on this? I recall there was some discussion 
> on brining this component to main Camel components.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476094#comment-17476094
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013061486


   @zregvart let me fix the link that I missed.  One moment...


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by Atlassian 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476084#comment-17476084
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013049492


   > @Steve973 no worries, not much work at all. I'll create a separate PR for 
the changes in the POM though, I think that'll get the blog post merged faster. 
I am going to force-push to your branch so just be aware of that.
   
   Thank you, again, for your help.  I am a new contributor here, so I am 
trying to learn how your team does things.  If it comes to a point where you 
need me to fix whatever I did wrong, just let me know.  I am at work now, where 
my local time is just before 7am at the time of this comment, so I might not be 
able to do much for approximately another 7 - 8 hours.


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The 

[jira] [Updated] (CAMEL-17489) camel-kafka - Unsubscribing fails due to already closed consumer

[Jira]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafał Gała updated CAMEL-17489:
---
Description: 
In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
method, the consumer is closed in finally block:
{code:java}
finally {
lock.unlock();

// only close if not retry
if (!isRetrying()) {
LOG.debug("Closing consumer {}", threadId);
IOHelper.close(consumer);
}
} {code}
 and then unsubscribing in *run* method fails with "This consumer has already 
been closed"
{code:java}
LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
threadId, topicName);
safeUnsubscribe();
IOHelper.close(consumer); {code}

  was:
In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
method, the consumer is closed in finally block:
{code:java}
finally {
lock.unlock();

// only close if not retry
if (!isRetrying()) {
LOG.debug("Closing consumer {}", threadId);
IOHelper.close(consumer);
}
} {code}
 and then unsibscribing in *run* method fails with "Consumer already closed 
error"

 
{code:java}
LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
threadId, topicName);
safeUnsubscribe();
IOHelper.close(consumer); {code}


> camel-kafka - Unsubscribing fails due to already closed consumer
> 
>
> Key: CAMEL-17489
> URL: https://issues.apache.org/jira/browse/CAMEL-17489
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 3.14.0
>Reporter: Rafał Gała
>Priority: Minor
>
> In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
> method, the consumer is closed in finally block:
> {code:java}
> finally {
> lock.unlock();
> // only close if not retry
> if (!isRetrying()) {
> LOG.debug("Closing consumer {}", threadId);
> IOHelper.close(consumer);
> }
> } {code}
>  and then unsubscribing in *run* method fails with "This consumer has already 
> been closed"
> {code:java}
> LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
> threadId, topicName);
> safeUnsubscribe();
> IOHelper.close(consumer); {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17489) camel-kafka - Unsubscribing fails due to already closed consumer

[Jira]

[ 
https://issues.apache.org/jira/browse/CAMEL-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476075#comment-17476075
 ] 

Rafał Gała commented on CAMEL-17489:


There you go

 
{noformat}
2022-01-14 11:59:27.612 [Camel (camel-1) thread #778 - 
KafkaConsumer[***masked***]] WARN  
org.apache.camel.component.kafka.KafkaConsumer.log:214 - Error unsubscribing 
***masked***-Thread 0 from kafka topic ***masked***. Caused by: 
[java.lang.IllegalStateException - This consumer has already been closed.]
java.lang.IllegalStateException: This consumer has already been closed.
    at 
org.apache.kafka.clients.consumer.KafkaConsumer.acquireAndEnsureOpen(KafkaConsumer.java:2437)
    at 
org.apache.kafka.clients.consumer.KafkaConsumer.unsubscribe(KafkaConsumer.java:1062)
    at 
org.apache.camel.component.kafka.KafkaFetchRecords.safeUnsubscribe(KafkaFetchRecords.java:239)
    at 
org.apache.camel.component.kafka.KafkaFetchRecords.run(KafkaFetchRecords.java:105)
    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){noformat}

> camel-kafka - Unsubscribing fails due to already closed consumer
> 
>
> Key: CAMEL-17489
> URL: https://issues.apache.org/jira/browse/CAMEL-17489
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 3.14.0
>Reporter: Rafał Gała
>Priority: Minor
>
> In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
> method, the consumer is closed in finally block:
> {code:java}
> finally {
> lock.unlock();
> // only close if not retry
> if (!isRetrying()) {
> LOG.debug("Closing consumer {}", threadId);
> IOHelper.close(consumer);
> }
> } {code}
>  and then unsibscribing in *run* method fails with "Consumer already closed 
> error"
>  
> {code:java}
> LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
> threadId, topicName);
> safeUnsubscribe();
> IOHelper.close(consumer); {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (CAMEL-17489) camel-kafka - Unsubscribing fails due to already closed consumer

[Jira]

[ 
https://issues.apache.org/jira/browse/CAMEL-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476075#comment-17476075
 ] 

Rafał Gała edited comment on CAMEL-17489 at 1/14/22, 11:26 AM:
---

There you go:

 
{noformat}
2022-01-14 11:59:27.612 [Camel (camel-1) thread #778 - 
KafkaConsumer[***masked***]] WARN  
org.apache.camel.component.kafka.KafkaConsumer.log:214 - Error unsubscribing 
***masked***-Thread 0 from kafka topic ***masked***. Caused by: 
[java.lang.IllegalStateException - This consumer has already been closed.]
java.lang.IllegalStateException: This consumer has already been closed.
    at 
org.apache.kafka.clients.consumer.KafkaConsumer.acquireAndEnsureOpen(KafkaConsumer.java:2437)
    at 
org.apache.kafka.clients.consumer.KafkaConsumer.unsubscribe(KafkaConsumer.java:1062)
    at 
org.apache.camel.component.kafka.KafkaFetchRecords.safeUnsubscribe(KafkaFetchRecords.java:239)
    at 
org.apache.camel.component.kafka.KafkaFetchRecords.run(KafkaFetchRecords.java:105)
    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){noformat}


was (Author: rgala):
There you go

 
{noformat}
2022-01-14 11:59:27.612 [Camel (camel-1) thread #778 - 
KafkaConsumer[***masked***]] WARN  
org.apache.camel.component.kafka.KafkaConsumer.log:214 - Error unsubscribing 
***masked***-Thread 0 from kafka topic ***masked***. Caused by: 
[java.lang.IllegalStateException - This consumer has already been closed.]
java.lang.IllegalStateException: This consumer has already been closed.
    at 
org.apache.kafka.clients.consumer.KafkaConsumer.acquireAndEnsureOpen(KafkaConsumer.java:2437)
    at 
org.apache.kafka.clients.consumer.KafkaConsumer.unsubscribe(KafkaConsumer.java:1062)
    at 
org.apache.camel.component.kafka.KafkaFetchRecords.safeUnsubscribe(KafkaFetchRecords.java:239)
    at 
org.apache.camel.component.kafka.KafkaFetchRecords.run(KafkaFetchRecords.java:105)
    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){noformat}

> camel-kafka - Unsubscribing fails due to already closed consumer
> 
>
> Key: CAMEL-17489
> URL: https://issues.apache.org/jira/browse/CAMEL-17489
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 3.14.0
>Reporter: Rafał Gała
>Priority: Minor
>
> In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
> method, the consumer is closed in finally block:
> {code:java}
> finally {
> lock.unlock();
> // only close if not retry
> if (!isRetrying()) {
> LOG.debug("Closing consumer {}", threadId);
> IOHelper.close(consumer);
> }
> } {code}
>  and then unsibscribing in *run* method fails with "Consumer already closed 
> error"
>  
> {code:java}
> LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
> threadId, topicName);
> safeUnsubscribe();
> IOHelper.close(consumer); {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17489) camel-kafka - Unsubscribing fails due to already closed consumer

[Claus Ibsen (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476074#comment-17476074
 ] 

Claus Ibsen commented on CAMEL-17489:
-

Can you post the stractrace / error you see from the logs

> camel-kafka - Unsubscribing fails due to already closed consumer
> 
>
> Key: CAMEL-17489
> URL: https://issues.apache.org/jira/browse/CAMEL-17489
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 3.14.0
>Reporter: Rafał Gała
>Priority: Minor
>
> In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
> method, the consumer is closed in finally block:
> {code:java}
> finally {
> lock.unlock();
> // only close if not retry
> if (!isRetrying()) {
> LOG.debug("Closing consumer {}", threadId);
> IOHelper.close(consumer);
> }
> } {code}
>  and then unsibscribing in *run* method fails with "Consumer already closed 
> error"
>  
> {code:java}
> LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
> threadId, topicName);
> safeUnsubscribe();
> IOHelper.close(consumer); {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17489) camel-kafka - Unsubscribing fails due to already closed consumer

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-17489:

Summary: camel-kafka - Unsubscribing fails due to already closed consumer  
(was: Unsubscribing fails due to already closed consumer)

> camel-kafka - Unsubscribing fails due to already closed consumer
> 
>
> Key: CAMEL-17489
> URL: https://issues.apache.org/jira/browse/CAMEL-17489
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 3.14.0
>Reporter: Rafał Gała
>Priority: Minor
>
> In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
> method, the consumer is closed in finally block:
> {code:java}
> finally {
> lock.unlock();
> // only close if not retry
> if (!isRetrying()) {
> LOG.debug("Closing consumer {}", threadId);
> IOHelper.close(consumer);
> }
> } {code}
>  and then unsibscribing in *run* method fails with "Consumer already closed 
> error"
>  
> {code:java}
> LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
> threadId, topicName);
> safeUnsubscribe();
> IOHelper.close(consumer); {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17489) Unsubscribing fails due to already closed consumer

[Jira]

Rafał Gała created CAMEL-17489:
--

 Summary: Unsubscribing fails due to already closed consumer
 Key: CAMEL-17489
 URL: https://issues.apache.org/jira/browse/CAMEL-17489
 Project: Camel
  Issue Type: Bug
  Components: camel-kafka
Affects Versions: 3.14.0
Reporter: Rafał Gała


In {*}KafkaFetchRecords{*}, when an exception occurs inside *startPolling* 
method, the consumer is closed in finally block:
{code:java}
finally {
lock.unlock();

// only close if not retry
if (!isRetrying()) {
LOG.debug("Closing consumer {}", threadId);
IOHelper.close(consumer);
}
} {code}
 and then unsibscribing in *run* method fails with "Consumer already closed 
error"

 
{code:java}
LOG.info("Terminating KafkaConsumer thread: {} receiving from topic: {}", 
threadId, topicName);
safeUnsubscribe();
IOHelper.close(consumer); {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476065#comment-17476065
 ] 

ASF GitHub Bot commented on CAMEL-17154:


zregvart commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013007658


   @Steve973 no worries, not much work at all. I'll create a separate PR for 
the changes in the POM though, I think that'll get the blog post merged faster. 
I am going to force-push to your branch so just be aware of that.


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476064#comment-17476064
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 edited a comment on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013004793


   > @Steve973 there seems to be something wrong with the merge resolution and 
now we have changes in files that are not related to the blog post. I'll rebase 
this and hopefully that'll fix it. It will change your own branch, but 
hopefully for the last time before we merge.
   
   @zregvart That reminds me that I fixed the maven build, so those changes in 
the pom.xml are undoubtedly some unrelated changes.  I woke for work this 
morning, saw that I had left "draft:true" in the blog post, so I wanted to make 
that quick change and re-commit.  In the future, I will switch branches when I 
do any experimenting.  I apologize for creating more work for you, although I 
appreciate it.


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476062#comment-17476062
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013004793


   > @Steve973 there seems to be something wrong with the merge resolution and 
now we have changes in files that are not related to the blog post. I'll rebase 
this and hopefully that'll fix it. It will change your own branch, but 
hopefully for the last time before we merge.
   
   @zregvart That reminds me that I fixed the maven build, so those changes in 
the pom.xml are undoubtedly some unrelated changes.  I woke for work this 
morning, saw that I had left "draft:true" in the blog post, so I wanted to make 
that quick change and re-commit.  In the future, I will switch branches when I 
do any experimenting.


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476059#comment-17476059
 ] 

ASF GitHub Bot commented on CAMEL-17154:


zregvart commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013002063


   @Steve973 there seems to be something wrong with the merge resolution and 
now we have changes in files that are not related to the blog post. I'll rebase 
this and hopefully that'll fix it. It will change your own branch, but 
hopefully for the last time before we merge.


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The 

[jira] [Assigned] (CAMEL-17488) camel-cloudevent - Drop old 0.x specs

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned CAMEL-17488:
---

Assignee: Claus Ibsen

> camel-cloudevent - Drop old 0.x specs
> -
>
> Key: CAMEL-17488
> URL: https://issues.apache.org/jira/browse/CAMEL-17488
> Project: Camel
>  Issue Type: Improvement
>Affects Versions: 3.15.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.15.0
>
>
> Ported over camel-cloudevents from camel-k-runtime
> The only specs online are 1.0.0 and 1.0.1. So lets remove the old 0.1 0.2 and 
> 0.3 specs



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17488) camel-cloudevent - Drop old 0.x specs

[Claus Ibsen (Jira)]

Claus Ibsen created CAMEL-17488:
---

 Summary: camel-cloudevent - Drop old 0.x specs
 Key: CAMEL-17488
 URL: https://issues.apache.org/jira/browse/CAMEL-17488
 Project: Camel
  Issue Type: Improvement
Affects Versions: 3.15.0
Reporter: Claus Ibsen
 Fix For: 3.15.0


Ported over camel-cloudevents from camel-k-runtime

The only specs online are 1.0.0 and 1.0.1. So lets remove the old 0.1 0.2 and 
0.3 specs



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476041#comment-17476041
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1012937775


   Oh, I do remember that I was supposed to remove the draft line, now that
   you mention it. Thank you!
   
   On Fri, Jan 14, 2022, 12:52 AM djencks ***@***.***> wrote:
   
   > I built it locally and don't see any problems from the time in the date,
   > but the draft:true appears to prevent it being published.
   >
   > —
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   > You are receiving this because you authored the thread.Message ID:
   > ***@***.***>
   >
   


-- 
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.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange 

[jira] [Commented] (CAMEL-17478) camel-aws2-s3 Operation downloadLink requires aws credentails even if client is aurowired from registry

[Jiri Ondrusek (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476039#comment-17476039
 ] 

Jiri Ondrusek commented on CAMEL-17478:
---

I looked into the issue and because the client could be autowired, there is no 
way how to get credentials, which are required for downloadLink operation other 
then providing them as parameters. The small change in the doc explains it and 
it is all needed as a solution (#1).

I can see one small improvement. In case that s3 client is created via 
component (aws2 credentials are passed into the component), credentials might 
be used instead of parameters for the operation. But it will create an 
inconsistency.
* We could define 2 ways how to get credentials for DownloadLink operation:
# if user provides aws credentials as parameters (current state), parameters 
will be used 
# if parameters are not provided for operation: If aws credentials are defined 
for the component - credentials can be reused for downloadLink. (This could 
make the usage of the component a little bit easier).  If client is autowired, 
endpoint will fail. 

[~davsclaus] Should I add such behavior?

> camel-aws2-s3 Operation downloadLink requires aws credentails even if client 
> is aurowired from registry
> ---
>
> Key: CAMEL-17478
> URL: https://issues.apache.org/jira/browse/CAMEL-17478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-aws2
>Affects Versions: 3.15.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
> Fix For: 3.15.0
>
>
> It is possible to use "custom" aws s3 client by providing a client in 
> registry.
> If operation "downloadLink" is executed with a component with autowired 
> client, it fails.
> I understand that creation of a link is not possible without credentials and 
> the only solution for user is to provide credentials (in the same way as in 
> [test|https://github.com/apache/camel/blob/main/components/camel-aws/camel-aws2-s3/src/test/java/org/apache/camel/component/aws2/s3/integration/S3CreateDownloadLinkOperationIT.java#L84])
> I think that this behavior should be mentioned in the documentation and 
> covered by the test. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (CAMEL-17057) camel-mongodb - Make it easier to configuring that dreadful MongoDBClientURI

[Karen Lease (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karen Lease reassigned CAMEL-17057:
---

Assignee: Karen Lease

> camel-mongodb - Make it easier to configuring that dreadful MongoDBClientURI
> 
>
> Key: CAMEL-17057
> URL: https://issues.apache.org/jira/browse/CAMEL-17057
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-mongodb
>Reporter: Claus Ibsen
>Assignee: Karen Lease
>Priority: Major
> Fix For: 3.15.0
>
>
> Using mongodb is not as easy to configure when you need to use that mongodb 
> client url that has a ton of configurations in a string. 
> Today you have to create that MongoDBClient instance yourself via 
> constructors, so you end up having to write Java code.
> For *** sake could they not just make their client api easier to configure.
> On chat forum
> https://camel.zulipchat.com/#narrow/stream/257299-camel-k/topic/MongoDB.20connection.20configuration



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (CAMEL-15275) Create camel-knative component in main Camel components based on camel-knative for camel-k

[Claus Ibsen (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-15275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned CAMEL-15275:
---

Assignee: Claus Ibsen

> Create camel-knative component in main Camel components based on 
> camel-knative for camel-k 
> ---
>
> Key: CAMEL-15275
> URL: https://issues.apache.org/jira/browse/CAMEL-15275
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 3.4.0
>Reporter: Omar Al-Safi
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.15.0
>
>
> Currently we have [{{camel-knative}} 
> component|https://github.com/apache/camel-k-runtime/tree/master/camel-knative]
>  in camel-k that enables camel routes deployed in with camel-k to interact 
> with knative components like eventing. However, currently it is only 
> exclusive to camel-k, hence it will make sense to bring/create this component 
> as part of the main Camel components in order in order to enable non-camel-k 
> routes that deployed with knative (e.g: camel-quarkus, camel-spring-boot) to 
> utilize and interact in kantive. 
> FYI [~davsclaus] [~lb]] thoughts on this? I recall there was some discussion 
> on brining this component to main Camel components.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)