[jira] [Comment Edited] (CAMEL-16825) can not use endChoice() in nest choice DSL

2022-09-13 Thread Dirk Vanhaute (Jira)


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

Dirk Vanhaute edited comment on CAMEL-16825 at 9/13/22 10:16 PM:
-

Hi Claus,  I believe this is what you are looking for: 
[https://github.com/apache/camel/pull/5890]

It does what I explained here :
{quote}WhenDefinition and OtherwiseDefinition are indeed on top of 
ChoiceDefinition.
It is a special construction. It is a child of choice, and 
ChoiceDefinition.when creates the new WhenDefinition or OtherwiseDefinition, 
but returns the current ChoiceDefinition instead.

Thus, indeed, I agree, endChoice should test first on being on level 
ChoiceDefinition and, if so, decide we're fine, not end the choice, but just 
return itself.
{quote}
What I explained further is that in CAMEL-4050, endParent was created in 
ProcessorDefinition and overridden in WhenDefinition but not in 
OtherDefinition.  The reasoning might have been that after an otherwise, the 
choice ends, and there is no reason to return to ChoiceDefinition.  

The NestedChoiceIssueTest is also constructed in this way of thinking :

{{.to("mock:big").otherwise().to("mock:med")}}
{{.endChoice().otherwise().to("mock:low").end();}}

The endChoice in this sequence should be followed by end() to terminate the 
inner choice, but the boolean construction onlyWhenOrOtherwise fails to notice 
this because it is followed by an otherwise.  This explains why his PR failed. 
The inner choice got the two otherwises.

It might also be this endParent thing that makes it impossible to use endChoice 
in a nested choice where it is not necessarry ( see my first example for a test 
).


was (Author: d.vanhaute):
Hi Claus,  I believe this is what you are looking for: 
[https://github.com/apache/camel/pull/5890]

It does what I explained here : 
{quote}WhenDefinition and OtherwiseDefinition are indeed on top of 
ChoiceDefinition.
It is a special construction. It is a child of choice, and 
ChoiceDefinition.when creates the new WhenDefinition or OtherwiseDefinition, 
but returns the current ChoiceDefinition instead.

Thus, indeed, I agree, endChoice should test first on being on level 
ChoiceDefinition and, if so, decide we're fine, not end the choice, but just 
return itself.
{quote}
But since the original test failed, I am not sure this is a correct analysis of 
what happened.

What I explained further is in CAMEL-4050, endParent was created in 
ProcessorDefinition and overridden in WhenDefinition but not in 
OtherDefinition.  It might be this whole parent thing that makes it impossible 
to use endChoice in a nested choice where it is not necessarry ( see my first 
example for a test ).

> can not use endChoice() in nest choice DSL
> --
>
> Key: CAMEL-16825
> URL: https://issues.apache.org/jira/browse/CAMEL-16825
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, eip
>Affects Versions: 3.6.0, 3.11.0
>Reporter: tang honggang
>Priority: Minor
> Fix For: 3.x
>
>
> I want to use nest choice DSL to finish some job, but it doesn't work well in 
> my test case.  When I use endChoice() in the inner choice clause, it return 
> back to the outer choice definition actually. 
> And this is the test case:
> ProcessorDefinition end = from("timer:foo?period=5000=true")
>  .transform(simple("${random(1000)}"))
>  .choice()
>  .when(simple("${body} > 500"))
>  .log("High number ${body}")
>  .choice()
>  .when(simple("${body} > 750"))
>  .log("High number >750 ${body}")
>  .endChoice()
>  .otherwise()
>  .log("High number <750 ${body}")
>  .endChoice()
>  .endChoice()
>  .otherwise()
>  .log("Low number ${body}")
>  .endChoice();
>  
> Though in this case, I can fix the problem by not use endChoice(), I see the 
> code of endChoice(). I found that change the sequence of the two judgement 
> below can fix my problem, but I am not sure the influence. So I hope you can 
> give me an answer, thx!
> // are we nested choice?
> ProcessorDefinition def = this;
> if (def.getParent() instanceof WhenDefinition) {
>  return (ChoiceDefinition) def.getParent().getParent();
> }
> // are we already a choice?
> if (def instanceof ChoiceDefinition) {
>  return (ChoiceDefinition) def;
> }
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CAMEL-16825) can not use endChoice() in nest choice DSL

2022-09-13 Thread Dirk Vanhaute (Jira)


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

Dirk Vanhaute commented on CAMEL-16825:
---

Hi Claus,  I believe this is what you are looking for: 
[https://github.com/apache/camel/pull/5890]

It does what I explained here : 
{quote}WhenDefinition and OtherwiseDefinition are indeed on top of 
ChoiceDefinition.
It is a special construction. It is a child of choice, and 
ChoiceDefinition.when creates the new WhenDefinition or OtherwiseDefinition, 
but returns the current ChoiceDefinition instead.

Thus, indeed, I agree, endChoice should test first on being on level 
ChoiceDefinition and, if so, decide we're fine, not end the choice, but just 
return itself.
{quote}
But since the original test failed, I am not sure this is a correct analysis of 
what happened.

What I explained further is in CAMEL-4050, endParent was created in 
ProcessorDefinition and overridden in WhenDefinition but not in 
OtherDefinition.  It might be this whole parent thing that makes it impossible 
to use endChoice in a nested choice where it is not necessarry ( see my first 
example for a test ).

> can not use endChoice() in nest choice DSL
> --
>
> Key: CAMEL-16825
> URL: https://issues.apache.org/jira/browse/CAMEL-16825
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, eip
>Affects Versions: 3.6.0, 3.11.0
>Reporter: tang honggang
>Priority: Minor
> Fix For: 3.x
>
>
> I want to use nest choice DSL to finish some job, but it doesn't work well in 
> my test case.  When I use endChoice() in the inner choice clause, it return 
> back to the outer choice definition actually. 
> And this is the test case:
> ProcessorDefinition end = from("timer:foo?period=5000=true")
>  .transform(simple("${random(1000)}"))
>  .choice()
>  .when(simple("${body} > 500"))
>  .log("High number ${body}")
>  .choice()
>  .when(simple("${body} > 750"))
>  .log("High number >750 ${body}")
>  .endChoice()
>  .otherwise()
>  .log("High number <750 ${body}")
>  .endChoice()
>  .endChoice()
>  .otherwise()
>  .log("Low number ${body}")
>  .endChoice();
>  
> Though in this case, I can fix the problem by not use endChoice(), I see the 
> code of endChoice(). I found that change the sequence of the two judgement 
> below can fix my problem, but I am not sure the influence. So I hope you can 
> give me an answer, thx!
> // are we nested choice?
> ProcessorDefinition def = this;
> if (def.getParent() instanceof WhenDefinition) {
>  return (ChoiceDefinition) def.getParent().getParent();
> }
> // are we already a choice?
> if (def instanceof ChoiceDefinition) {
>  return (ChoiceDefinition) def;
> }
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (CAMEL-18503) Configure max ack extension period parameter in PubSub subscriber

2022-09-13 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-18503.
-
Fix Version/s: 3.19.0
   Resolution: Fixed

Thanks for reporting and the PR

> Configure max ack extension period parameter in PubSub subscriber
> -
>
> Key: CAMEL-18503
> URL: https://issues.apache.org/jira/browse/CAMEL-18503
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-google-pubsub
>Affects Versions: 3.18.2
>Reporter: Vincent Paturet
>Priority: Major
> Fix For: 3.19.0
>
>
> In recent versions of the Google PubSub client library, the message ack 
> deadline can be extended up to 1 hour by default before the message is marked 
> as expired:
> [https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96]
> To prevent long-running operations (more than 1 hour) from being executed 
> multiple times due to message redelivery, it is necessary to configure the 
> max ack extension period to a higher value using 
> Subscriber.Builder.setMaxAckExtensionPeriod()
> Proposed new feature: add a per-route parameter to configure the max ack 
> extension period:
> google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400
>  
> PR: [https://github.com/apache/camel/pull/8363]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (CAMEL-18504) camel-google - Add dev console for secrets

2022-09-13 Thread Claus Ibsen (Jira)


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

Claus Ibsen reassigned CAMEL-18504:
---

Assignee: Andrea Cosentino

> camel-google - Add dev console for secrets
> --
>
> Key: CAMEL-18504
> URL: https://issues.apache.org/jira/browse/CAMEL-18504
> Project: Camel
>  Issue Type: Sub-task
>  Components: camel-google
>Reporter: Claus Ibsen
>Assignee: Andrea Cosentino
>Priority: Minor
>
> We have for AWS here
> https://github.com/apache/camel/blob/main/components/camel-aws/camel-aws-secrets-manager/src/main/java/org/apache/camel/component/aws/secretsmanager/SecretsDevConsole.java
> We need similar for camel-google-secret-manager



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (CAMEL-18504) camel-google - Add dev console for secrets

2022-09-13 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-18504:

Priority: Minor  (was: Major)

> camel-google - Add dev console for secrets
> --
>
> Key: CAMEL-18504
> URL: https://issues.apache.org/jira/browse/CAMEL-18504
> Project: Camel
>  Issue Type: Sub-task
>  Components: camel-google
>Reporter: Claus Ibsen
>Priority: Minor
>
> We have for AWS here
> https://github.com/apache/camel/blob/main/components/camel-aws/camel-aws-secrets-manager/src/main/java/org/apache/camel/component/aws/secretsmanager/SecretsDevConsole.java
> We need similar for camel-google-secret-manager



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (CAMEL-18504) camel-google - Add dev console for secrets

2022-09-13 Thread Claus Ibsen (Jira)
Claus Ibsen created CAMEL-18504:
---

 Summary: camel-google - Add dev console for secrets
 Key: CAMEL-18504
 URL: https://issues.apache.org/jira/browse/CAMEL-18504
 Project: Camel
  Issue Type: Sub-task
  Components: camel-google
Reporter: Claus Ibsen


We have for AWS here
https://github.com/apache/camel/blob/main/components/camel-aws/camel-aws-secrets-manager/src/main/java/org/apache/camel/component/aws/secretsmanager/SecretsDevConsole.java

We need similar for camel-google-secret-manager



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (CAMEL-18502) Support Secrets Reload from Vault/Cloud Service in camel-spring-boot - Google Secret Manager

2022-09-13 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino resolved CAMEL-18502.
--
Resolution: Fixed

> Support Secrets Reload from Vault/Cloud Service in camel-spring-boot - Google 
> Secret Manager
> 
>
> Key: CAMEL-18502
> URL: https://issues.apache.org/jira/browse/CAMEL-18502
> Project: Camel
>  Issue Type: Sub-task
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 3.19.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (CAMEL-18501) Camel-Google-Secret-Manager: Create a task looking for secrets update in PubSub

2022-09-13 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino resolved CAMEL-18501.
--
Resolution: Fixed

> Camel-Google-Secret-Manager: Create a task looking for secrets update in 
> PubSub
> ---
>
> Key: CAMEL-18501
> URL: https://issues.apache.org/jira/browse/CAMEL-18501
> Project: Camel
>  Issue Type: Sub-task
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 3.19.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (CAMEL-18503) Configure max ack extension period parameter in PubSub subscriber

2022-09-13 Thread Vincent Paturet (Jira)


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

Vincent Paturet updated CAMEL-18503:

Description: 
In recent versions of the Google PubSub client library, the message ack 
deadline can be extended up to 1 hour by default before the message is marked 
as expired:
[https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96]
To prevent long-running operations (more than 1 hour) from being executed 
multiple times due to message redelivery, it is necessary to configure the max 
ack extension period to a higher value using 
Subscriber.Builder.setMaxAckExtensionPeriod()
Proposed new feature: add a per-route parameter to configure the max ack 
extension period:

google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400

 

PR: [https://github.com/apache/camel/pull/8363]

  was:
In recent versions of the Google PubSub client library, the message ack 
deadline can be extended up to 1 hour by default before the message is marked 
as expired:
[https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96]
To prevent long-running operations (more than 1 hour) to be executed multiple 
times due to message redelivery, it is necessary to configure the max ack 
extension period to a higher value using 
Subscriber.Builder.setMaxAckExtensionPeriod()
Proposed new feature: add a per-route parameter to configure the max ack 
extension period:

google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400

 

PR: [https://github.com/apache/camel/pull/8363]


> Configure max ack extension period parameter in PubSub subscriber
> -
>
> Key: CAMEL-18503
> URL: https://issues.apache.org/jira/browse/CAMEL-18503
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-google-pubsub
>Affects Versions: 3.18.2
>Reporter: Vincent Paturet
>Priority: Major
>
> In recent versions of the Google PubSub client library, the message ack 
> deadline can be extended up to 1 hour by default before the message is marked 
> as expired:
> [https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96]
> To prevent long-running operations (more than 1 hour) from being executed 
> multiple times due to message redelivery, it is necessary to configure the 
> max ack extension period to a higher value using 
> Subscriber.Builder.setMaxAckExtensionPeriod()
> Proposed new feature: add a per-route parameter to configure the max ack 
> extension period:
> google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400
>  
> PR: [https://github.com/apache/camel/pull/8363]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (CAMEL-18503) Configure max ack extension period parameter in PubSub subscriber

2022-09-13 Thread Vincent Paturet (Jira)


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

Vincent Paturet updated CAMEL-18503:

Description: 
In recent versions of the Google PubSub client library, the message ack 
deadline can be extended up to 1 hour by default before the message is marked 
as expired:
[https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96]
To prevent long-running operations (more than 1 hour) to be executed multiple 
times due to message redelivery, it is necessary to configure the max ack 
extension period to a higher value using 
Subscriber.Builder.setMaxAckExtensionPeriod()
Proposed new feature: add a per-route parameter to configure the max ack 
extension period:

google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400

 

PR: [https://github.com/apache/camel/pull/8363]

  was:
In recent version of the Google PubSub client library, the message ack deadline 
can be extended up to 1 hour by default before the message is marked as expired:
[https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96]
To prevent long-running operations (more than 1 hour) to be executed multiple 
times due to message redelivery, it is necessary to configure the max ack 
extension period to a higher value using 
Subscriber.Builder.setMaxAckExtensionPeriod()
Proposed new feature: add a per-route parameter to configure the max ack 
extension period:

google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400

 

PR: https://github.com/apache/camel/pull/8363


> Configure max ack extension period parameter in PubSub subscriber
> -
>
> Key: CAMEL-18503
> URL: https://issues.apache.org/jira/browse/CAMEL-18503
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-google-pubsub
>Affects Versions: 3.18.2
>Reporter: Vincent Paturet
>Priority: Major
>
> In recent versions of the Google PubSub client library, the message ack 
> deadline can be extended up to 1 hour by default before the message is marked 
> as expired:
> [https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96]
> To prevent long-running operations (more than 1 hour) to be executed multiple 
> times due to message redelivery, it is necessary to configure the max ack 
> extension period to a higher value using 
> Subscriber.Builder.setMaxAckExtensionPeriod()
> Proposed new feature: add a per-route parameter to configure the max ack 
> extension period:
> google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400
>  
> PR: [https://github.com/apache/camel/pull/8363]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (CAMEL-18503) Configure max ack extension period parameter in PubSub subscriber

2022-09-13 Thread Vincent Paturet (Jira)


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

Vincent Paturet updated CAMEL-18503:

Description: 
In recent version of the Google PubSub client library, the message ack deadline 
can be extended up to 1 hour by default before the message is marked as expired:
[https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96]
To prevent long-running operations (more than 1 hour) to be executed multiple 
times due to message redelivery, it is necessary to configure the max ack 
extension period to a higher value using 
Subscriber.Builder.setMaxAckExtensionPeriod()
Proposed new feature: add a per-route parameter to configure the max ack 
extension period:

google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400

 

PR: https://github.com/apache/camel/pull/8363

  was:
In recent version of the Google PubSub client library, the message ack deadline 
can be extended up to 1 hour by default before the message is marked as expired:
https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96
To prevent long-running operations (more than 1 hour) to be executed multiple 
times due to message redelivery, it is necessary to configure the max ack 
extension period to a higher value using 
Subscriber.Builder.setMaxAckExtensionPeriod()
Proposed new feature: add a per-route parameter to configure the max ack 
extension period:

google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400


> Configure max ack extension period parameter in PubSub subscriber
> -
>
> Key: CAMEL-18503
> URL: https://issues.apache.org/jira/browse/CAMEL-18503
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-google-pubsub
>Affects Versions: 3.18.2
>Reporter: Vincent Paturet
>Priority: Major
>
> In recent version of the Google PubSub client library, the message ack 
> deadline can be extended up to 1 hour by default before the message is marked 
> as expired:
> [https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96]
> To prevent long-running operations (more than 1 hour) to be executed multiple 
> times due to message redelivery, it is necessary to configure the max ack 
> extension period to a higher value using 
> Subscriber.Builder.setMaxAckExtensionPeriod()
> Proposed new feature: add a per-route parameter to configure the max ack 
> extension period:
> google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400
>  
> PR: https://github.com/apache/camel/pull/8363



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (CAMEL-18503) Configure max ack extension period parameter in PubSub subscriber

2022-09-13 Thread Vincent Paturet (Jira)
Vincent Paturet created CAMEL-18503:
---

 Summary: Configure max ack extension period parameter in PubSub 
subscriber
 Key: CAMEL-18503
 URL: https://issues.apache.org/jira/browse/CAMEL-18503
 Project: Camel
  Issue Type: New Feature
  Components: camel-google-pubsub
Affects Versions: 3.18.2
Reporter: Vincent Paturet


In recent version of the Google PubSub client library, the message ack deadline 
can be extended up to 1 hour by default before the message is marked as expired:
https://github.com/googleapis/java-pubsub/blob/9add53894981d862ac1348d0b641e472b3b3aa79/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/v1/Subscriber.java#L96
To prevent long-running operations (more than 1 hour) to be executed multiple 
times due to message redelivery, it is necessary to configure the max ack 
extension period to a higher value using 
Subscriber.Builder.setMaxAckExtensionPeriod()
Proposed new feature: add a per-route parameter to configure the max ack 
extension period:

google-pubsub:myProject:mySubscription?maxAckExtensionPeriod=14400



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (CAMEL-18502) Support Secrets Reload from Vault/Cloud Service in camel-spring-boot - Google Secret Manager

2022-09-13 Thread Andrea Cosentino (Jira)
Andrea Cosentino created CAMEL-18502:


 Summary: Support Secrets Reload from Vault/Cloud Service in 
camel-spring-boot - Google Secret Manager
 Key: CAMEL-18502
 URL: https://issues.apache.org/jira/browse/CAMEL-18502
 Project: Camel
  Issue Type: Sub-task
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
 Fix For: 3.19.0






--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (CAMEL-18478) Support Secrets Reload from Vault/Cloud Service in camel-spring-boot - AWS Secrets Manager

2022-09-13 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino updated CAMEL-18478:
-
Summary: Support Secrets Reload from Vault/Cloud Service in 
camel-spring-boot - AWS Secrets Manager  (was: Support Secrets Reload from 
Vault/Cloud Service in camel-spring-boot )

> Support Secrets Reload from Vault/Cloud Service in camel-spring-boot - AWS 
> Secrets Manager
> --
>
> Key: CAMEL-18478
> URL: https://issues.apache.org/jira/browse/CAMEL-18478
> Project: Camel
>  Issue Type: Sub-task
>  Components: camel-spring-boot
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 3.19.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (CAMEL-18296) camel-example tag is using snapshot camel version

2022-09-13 Thread Nicolas Filotto (Jira)


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

Nicolas Filotto edited comment on CAMEL-18296 at 9/13/22 9:38 AM:
--

Tag 3.18.0 recreated with Camel version fixed


was (Author: JIRAUSER285918):
Tag 3.18.0 recreated

> camel-example tag is using snapshot camel version
> -
>
> Key: CAMEL-18296
> URL: https://issues.apache.org/jira/browse/CAMEL-18296
> Project: Camel
>  Issue Type: Task
>  Components: examples
>Affects Versions: 3.18.0
>Reporter: Aurélien Pupier
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 3.18.3, 3.19.0
>
>
> see 
> https://github.com/apache/camel-examples/blob/27d60cbd1f113036df48daffd7edea8375a954aa/examples/pom.xml#L170



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (CAMEL-18296) camel-example tag is using snapshot camel version

2022-09-13 Thread Nicolas Filotto (Jira)


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

Nicolas Filotto resolved CAMEL-18296.
-
Resolution: Fixed

Tag 3.18.0 recreated

> camel-example tag is using snapshot camel version
> -
>
> Key: CAMEL-18296
> URL: https://issues.apache.org/jira/browse/CAMEL-18296
> Project: Camel
>  Issue Type: Task
>  Components: examples
>Affects Versions: 3.18.0
>Reporter: Aurélien Pupier
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 3.18.3, 3.19.0
>
>
> see 
> https://github.com/apache/camel-examples/blob/27d60cbd1f113036df48daffd7edea8375a954aa/examples/pom.xml#L170



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (CAMEL-18296) camel-example tag is using snapshot camel version

2022-09-13 Thread Nicolas Filotto (Jira)


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

Nicolas Filotto reassigned CAMEL-18296:
---

Assignee: Nicolas Filotto

> camel-example tag is using snapshot camel version
> -
>
> Key: CAMEL-18296
> URL: https://issues.apache.org/jira/browse/CAMEL-18296
> Project: Camel
>  Issue Type: Task
>  Components: examples
>Affects Versions: 3.18.0
>Reporter: Aurélien Pupier
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 3.18.3, 3.19.0
>
>
> see 
> https://github.com/apache/camel-examples/blob/27d60cbd1f113036df48daffd7edea8375a954aa/examples/pom.xml#L170



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (CAMEL-18238) camel-jbang - Used configmaps/secrets should captured

2022-09-13 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-18238:

Fix Version/s: 3.20.0
   (was: 3.19.0)

> camel-jbang - Used configmaps/secrets should captured
> -
>
> Key: CAMEL-18238
> URL: https://issues.apache.org/jira/browse/CAMEL-18238
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.20.0
>
>
> With CAMEL-18171 then when using configmap or secret then we should capture 
> these names so we know what are in use.
> This can aid for deployment which allows us to generate manifest files that 
> refer to the used cm/secrets so k8s can mount these automatic.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CAMEL-18346) Remove use of Xalan

2022-09-13 Thread Claus Ibsen (Jira)


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

Claus Ibsen commented on CAMEL-18346:
-

Okay so I think this is as-far we can take this.

> Remove use of Xalan
> ---
>
> Key: CAMEL-18346
> URL: https://issues.apache.org/jira/browse/CAMEL-18346
> Project: Camel
>  Issue Type: Task
>  Components: build system
>Reporter: PJ Fanning
>Assignee: Thomas Cunningham
>Priority: Minor
> Fix For: 3.19.0
>
>
> Xalan-J has an unfixed CVE. It is possible that this will be fixed in the 
> future but Xalan-J has had only one release since 2008 (in 2014).
> https://www.cvedetails.com/cve/CVE-2022-34169/
> Java has built-in support for TransformerFactory and XPathFactory. This means 
> most apps that use Xalan-J can readily switch away. Saxon-HE is another well 
> maintained alternative.
> Places where Camel still uses Xalan:
> * 
> https://github.com/apache/camel/blob/9d6ad653b6faa16e3c09047da66cd3bca94783ee/components/camel-xmlsecurity/pom.xml
> * 
> https://github.com/apache/camel/blob/9d6ad653b6faa16e3c09047da66cd3bca94783ee/tooling/maven/camel-eip-documentation-enricher-maven-plugin/pom.xml#L73
> There are profiles for testing in a number of poms:
> eg 
> https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (CAMEL-18492) Enterprise Feature of Saxon is Disabled in Camel 3.x versions.

2022-09-13 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-18492.
-
Resolution: Fixed

There is a new option you can set to turn off secure processing

> Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
> --
>
> Key: CAMEL-18492
> URL: https://issues.apache.org/jira/browse/CAMEL-18492
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-saxon, camel-xslt
>Affects Versions: 3.0.0
>Reporter: Harish Annamalai
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.19.0
>
>
> Hi All, 
> We use Camel-Saxon for one of our product. We use Saxon Enterprise Edition 
> 9.9.1.6. 
> We are migrating our product from camel 2.x to camel 3.x (2.24 to 3.15 to be 
> exact). 
> We use a paid feature of Saxon; Invoking *External Java Functions* in XSL 
> Transformations.
> We also *Extension Functions,* which we pass to camel-xslt-saxon component. 
> What we have observed in camel 3.x versions and above, In class 
> {{{*}XsltSaxonEndpoint{*}.java}} During the registration of extension 
> functions, at line 202, {{registerSaxonExtensionFunctions}} method of 
> {{{*}XsltSaxonHelper{*}.java}} is called. 
>  
> In XsltSaxonHelper.class, the method, 
> {{{}registerSaxonExtensionFunctions{}}}, at line 55, sets a feature of 
> {*}XMLConstants.FEATURE_SECURE_PROCESSING{*}.
> Unfortunately, Setting this Feature disables the External Java Function 
> calls. 
> We checked in Camel 2.x versions, this Feature is not set and therefore the 
> External Java Calls work fine. 
>  
> We see this as a bug - The Feature *XMLConstants.FEATURE_SECURE_PROCESSING* 
> is being introduced in 3.x and breaks a paid/Enterprise feature of Saxon.
>  
> Sample Code to test:
> {{import javax.xml.XMLConstants;}}
> {{import javax.xml.transform.Transformer;}}
> {{import javax.xml.transform.TransformerException;}}
> {{import javax.xml.transform.TransformerFactory;}}
> {{import javax.xml.transform.stream.StreamResult;}}
> {{import javax.xml.transform.stream.StreamSource;}}
> {{import java.io.File;}}
> {{public class SaxonTransformationTester {}}
> {{ public static void main(String[] args) throws TransformerException {}}
> {{ String foo_xml = "src/main/resources/in.xml"; // input xml}}
> {{ String foo_xsl = "src/main/resources/transf.xml"; // input xsl}}
> {{ EnterpriseTransformerFactory eef = 
> SaxonEEConsumerFactory.getEnterpriseTransformerFactoryInstance();}}
> {{ 
> eef.getConfiguration().getConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS);}}
> {{ eef.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); //This 
> causes External Functions to break}}
> {{ 
> eef.getConfiguration().setConfigurationProperty("http://saxon.sf.net/feature/trace-external-functions;,
>  false);}}
> {{ Transformer transformer = eef.newTransformer(new StreamSource(}}
> {{ new File(foo_xsl)));}}
> {{ transformer.transform(new StreamSource(new File(foo_xml)),}}
> {{ new StreamResult(System.out));}}
> {{ }}}
> {{}}}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (CAMEL-18492) Enterprise Feature of Saxon is Disabled in Camel 3.x versions.

2022-09-13 Thread Claus Ibsen (Jira)


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

Claus Ibsen reassigned CAMEL-18492:
---

Assignee: Claus Ibsen

> Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
> --
>
> Key: CAMEL-18492
> URL: https://issues.apache.org/jira/browse/CAMEL-18492
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-saxon, camel-xslt
>Affects Versions: 3.0.0
>Reporter: Harish Annamalai
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.19.0
>
>
> Hi All, 
> We use Camel-Saxon for one of our product. We use Saxon Enterprise Edition 
> 9.9.1.6. 
> We are migrating our product from camel 2.x to camel 3.x (2.24 to 3.15 to be 
> exact). 
> We use a paid feature of Saxon; Invoking *External Java Functions* in XSL 
> Transformations.
> We also *Extension Functions,* which we pass to camel-xslt-saxon component. 
> What we have observed in camel 3.x versions and above, In class 
> {{{*}XsltSaxonEndpoint{*}.java}} During the registration of extension 
> functions, at line 202, {{registerSaxonExtensionFunctions}} method of 
> {{{*}XsltSaxonHelper{*}.java}} is called. 
>  
> In XsltSaxonHelper.class, the method, 
> {{{}registerSaxonExtensionFunctions{}}}, at line 55, sets a feature of 
> {*}XMLConstants.FEATURE_SECURE_PROCESSING{*}.
> Unfortunately, Setting this Feature disables the External Java Function 
> calls. 
> We checked in Camel 2.x versions, this Feature is not set and therefore the 
> External Java Calls work fine. 
>  
> We see this as a bug - The Feature *XMLConstants.FEATURE_SECURE_PROCESSING* 
> is being introduced in 3.x and breaks a paid/Enterprise feature of Saxon.
>  
> Sample Code to test:
> {{import javax.xml.XMLConstants;}}
> {{import javax.xml.transform.Transformer;}}
> {{import javax.xml.transform.TransformerException;}}
> {{import javax.xml.transform.TransformerFactory;}}
> {{import javax.xml.transform.stream.StreamResult;}}
> {{import javax.xml.transform.stream.StreamSource;}}
> {{import java.io.File;}}
> {{public class SaxonTransformationTester {}}
> {{ public static void main(String[] args) throws TransformerException {}}
> {{ String foo_xml = "src/main/resources/in.xml"; // input xml}}
> {{ String foo_xsl = "src/main/resources/transf.xml"; // input xsl}}
> {{ EnterpriseTransformerFactory eef = 
> SaxonEEConsumerFactory.getEnterpriseTransformerFactoryInstance();}}
> {{ 
> eef.getConfiguration().getConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS);}}
> {{ eef.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); //This 
> causes External Functions to break}}
> {{ 
> eef.getConfiguration().setConfigurationProperty("http://saxon.sf.net/feature/trace-external-functions;,
>  false);}}
> {{ Transformer transformer = eef.newTransformer(new StreamSource(}}
> {{ new File(foo_xsl)));}}
> {{ transformer.transform(new StreamSource(new File(foo_xml)),}}
> {{ new StreamResult(System.out));}}
> {{ }}}
> {{}}}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (CAMEL-18216) camel-core - expose universal error handlers in all DSLs

2022-09-13 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-18216:

Fix Version/s: 3.20.0
   (was: 3.19.0)

> camel-core - expose universal error handlers in all DSLs
> 
>
> Key: CAMEL-18216
> URL: https://issues.apache.org/jira/browse/CAMEL-18216
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.20.0
>
>
> Outstanding work from CAMEL-16834



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CAMEL-18499) camel-kubernetes - Upgrade to 6.x

2022-09-13 Thread James Netherton (Jira)


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

James Netherton commented on CAMEL-18499:
-

I can try to do this for 3.19.0. There's a quite a few breaking changes, so 
can't guarantee that I'll make the release cut-off in time.

> camel-kubernetes - Upgrade to 6.x
> -
>
> Key: CAMEL-18499
> URL: https://issues.apache.org/jira/browse/CAMEL-18499
> Project: Camel
>  Issue Type: Dependency upgrade
>  Components: camel-kubernetes
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 3.19.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (CAMEL-18499) camel-kubernetes - Upgrade to 6.x

2022-09-13 Thread James Netherton (Jira)


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

James Netherton reassigned CAMEL-18499:
---

Assignee: James Netherton

> camel-kubernetes - Upgrade to 6.x
> -
>
> Key: CAMEL-18499
> URL: https://issues.apache.org/jira/browse/CAMEL-18499
> Project: Camel
>  Issue Type: Dependency upgrade
>  Components: camel-kubernetes
>Reporter: Claus Ibsen
>Assignee: James Netherton
>Priority: Major
> Fix For: 3.19.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)