[jira] [Resolved] (CAMEL-21207) Camel-Opensearch: Provide a parameter to set HostNameVerifier on client

2024-09-12 Thread Andrea Cosentino (Jira)


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

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

> Camel-Opensearch: Provide a parameter to set HostNameVerifier on client
> ---
>
> Key: CAMEL-21207
> URL: https://issues.apache.org/jira/browse/CAMEL-21207
> Project: Camel
>  Issue Type: New Feature
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 4.9.0
>
>




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


[jira] [Commented] (CAMEL-21210) camel-jbang - Optimized backlog tracer may miss information about which endpoint sent to

2024-09-12 Thread Claus Ibsen (Jira)


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

Claus Ibsen commented on CAMEL-21210:
-

TODO: backport to 4.8.x branch

> camel-jbang - Optimized backlog tracer may miss information about which 
> endpoint sent to
> 
>
> Key: CAMEL-21210
> URL: https://issues.apache.org/jira/browse/CAMEL-21210
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jbang
>Affects Versions: 4.8.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.8.1, 4.9.0
>
>




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


[jira] [Updated] (CAMEL-21210) camel-jbang - Optimized backlog tracer may miss information about which endpoint sent to

2024-09-12 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21210:

Fix Version/s: 4.8.1

> camel-jbang - Optimized backlog tracer may miss information about which 
> endpoint sent to
> 
>
> Key: CAMEL-21210
> URL: https://issues.apache.org/jira/browse/CAMEL-21210
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jbang
>Affects Versions: 4.8.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.8.1, 4.9.0
>
>




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


[jira] [Created] (CAMEL-21210) camel-jbang - Optimized backlog tracer may miss information about which endpoint sent to

2024-09-12 Thread Claus Ibsen (Jira)
Claus Ibsen created CAMEL-21210:
---

 Summary: camel-jbang - Optimized backlog tracer may miss 
information about which endpoint sent to
 Key: CAMEL-21210
 URL: https://issues.apache.org/jira/browse/CAMEL-21210
 Project: Camel
  Issue Type: Bug
  Components: camel-jbang
Affects Versions: 4.8.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 4.9.0






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


[jira] [Created] (CAMEL-21209) camel-langchain4j-tools: incorrect metadata prevents usage for tooling

2024-09-12 Thread Otavio Rodolfo Piske (Jira)
Otavio Rodolfo Piske created CAMEL-21209:


 Summary: camel-langchain4j-tools: incorrect metadata prevents 
usage for tooling
 Key: CAMEL-21209
 URL: https://issues.apache.org/jira/browse/CAMEL-21209
 Project: Camel
  Issue Type: Bug
  Components: camel-langchain4j-tools
Affects Versions: 4.8.0
Reporter: Otavio Rodolfo Piske
Assignee: Otavio Rodolfo Piske
 Fix For: 4.8.1, 4.9.0


The enums parameter on the LangChain4jToolsEndpoint class makes it much harder 
for tooling to generate valid YAML out of it.



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


[jira] [Updated] (CAMEL-21208) camel-jbang: use a template engine for code generation

2024-09-12 Thread Otavio Rodolfo Piske (Jira)


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

Otavio Rodolfo Piske updated CAMEL-21208:
-
Description: 
We have several places were we [create the export files by 
code|https://github.com/apache/camel/blob/main/dsl/camel-jbang/camel-jbang-core/src/main/java/org/apache/camel/dsl/jbang/core/commands/Run.java#L1265-L1281].
 Not only this bug-prone, but this is also [extremely hard to read, test, 
maintain and 
evolve|https://sonarcloud.io/project/issues?directories=dsl%2Fcamel-jbang%2Fcamel-jbang-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fcamel%2Fdsl%2Fjbang%2Fcore%2Fcommands&issueStatuses=OPEN%2CCONFIRMED&id=apache_camel&open=AX4xQ6i72wn0z3gD8D78].
 The code on Camel JBang is full of code like this. 

Using a template engine allow us to separate the template source, from the 
text/code generation logic, resulting in a code that is easier to maintain. 

We should pick a template engine, convert the all that code to the appropriate 
format and cleanup the code generation.




  was:
We have several places were we [create the export files by 
code|https://github.com/apache/camel/blob/main/dsl/camel-jbang/camel-jbang-core/src/main/java/org/apache/camel/dsl/jbang/core/commands/Run.java#L1265-L1281].
 Not only this bug-prone, but this is also extremely hard to read, test, 
maintain and evolve. The code on Camel JBang is full of code like this. 

Using a template engine allow us to separate the template source, from the 
text/code generation logic, resulting in a code that is easier to maintain. 

We should pick a template engine, convert the all that code to the appropriate 
format and cleanup the code generation.





> camel-jbang: use a template engine for code generation
> --
>
> Key: CAMEL-21208
> URL: https://issues.apache.org/jira/browse/CAMEL-21208
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Affects Versions: 4.7.0, 4.8.0
>Reporter: Otavio Rodolfo Piske
>Priority: Major
>
> We have several places were we [create the export files by 
> code|https://github.com/apache/camel/blob/main/dsl/camel-jbang/camel-jbang-core/src/main/java/org/apache/camel/dsl/jbang/core/commands/Run.java#L1265-L1281].
>  Not only this bug-prone, but this is also [extremely hard to read, test, 
> maintain and 
> evolve|https://sonarcloud.io/project/issues?directories=dsl%2Fcamel-jbang%2Fcamel-jbang-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fcamel%2Fdsl%2Fjbang%2Fcore%2Fcommands&issueStatuses=OPEN%2CCONFIRMED&id=apache_camel&open=AX4xQ6i72wn0z3gD8D78].
>  The code on Camel JBang is full of code like this. 
> Using a template engine allow us to separate the template source, from the 
> text/code generation logic, resulting in a code that is easier to maintain. 
> We should pick a template engine, convert the all that code to the 
> appropriate format and cleanup the code generation.



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


[jira] [Commented] (CAMEL-21208) camel-jbang: use a template engine for code generation

2024-09-12 Thread Otavio Rodolfo Piske (Jira)


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

Otavio Rodolfo Piske commented on CAMEL-21208:
--

There is some similarity with CAMEL-21181, but I feel that one is more about 
serializing objects, than generating code. Nonetheless, it may be possible to 
come up with a solution that fits both of the problems. 

> camel-jbang: use a template engine for code generation
> --
>
> Key: CAMEL-21208
> URL: https://issues.apache.org/jira/browse/CAMEL-21208
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Affects Versions: 4.7.0, 4.8.0
>Reporter: Otavio Rodolfo Piske
>Priority: Major
>
> We have several places were we [create the export files by 
> code|https://github.com/apache/camel/blob/main/dsl/camel-jbang/camel-jbang-core/src/main/java/org/apache/camel/dsl/jbang/core/commands/Run.java#L1265-L1281].
>  Not only this bug-prone, but this is also extremely hard to read, test, 
> maintain and evolve. The code on Camel JBang is full of code like this. 
> Using a template engine allow us to separate the template source, from the 
> text/code generation logic, resulting in a code that is easier to maintain. 
> We should pick a template engine, convert the all that code to the 
> appropriate format and cleanup the code generation.



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


[jira] [Created] (CAMEL-21208) camel-jbang: use a template engine for code generation

2024-09-12 Thread Otavio Rodolfo Piske (Jira)
Otavio Rodolfo Piske created CAMEL-21208:


 Summary: camel-jbang: use a template engine for code generation
 Key: CAMEL-21208
 URL: https://issues.apache.org/jira/browse/CAMEL-21208
 Project: Camel
  Issue Type: Improvement
  Components: camel-jbang
Affects Versions: 4.7.0, 4.8.0
Reporter: Otavio Rodolfo Piske


We have several places were we [create the export files by 
code|https://github.com/apache/camel/blob/main/dsl/camel-jbang/camel-jbang-core/src/main/java/org/apache/camel/dsl/jbang/core/commands/Run.java#L1265-L1281].
 Not only this bug-prone, but this is also extremely hard to read, test, 
maintain and evolve. The code on Camel JBang is full of code like this. 

Using a template engine allow us to separate the template source, from the 
text/code generation logic, resulting in a code that is easier to maintain. 

We should pick a template engine, convert the all that code to the appropriate 
format and cleanup the code generation.






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


[jira] [Updated] (CAMEL-20888) Remove Kotlin DSL and API

2024-09-11 Thread Jira


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

Aurélien Pupier updated CAMEL-20888:

Summary: Remove Kotlin DSL and API  (was: Remove Kotlin DSL)

> Remove Kotlin DSL and API
> -
>
> Key: CAMEL-20888
> URL: https://issues.apache.org/jira/browse/CAMEL-20888
> Project: Camel
>  Issue Type: Task
>  Components: camel-kotlin
>Affects Versions: 4.7.0
>Reporter: Aurélien Pupier
>Assignee: Aurélien Pupier
>Priority: Major
> Fix For: 4.9.0
>
>
> Kotlin DSL was deprecated in 4.7.0



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


[jira] [Resolved] (CAMEL-20888) Remove Kotlin DSL and API

2024-09-11 Thread Jira


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

Aurélien Pupier resolved CAMEL-20888.
-
Resolution: Fixed

> Remove Kotlin DSL and API
> -
>
> Key: CAMEL-20888
> URL: https://issues.apache.org/jira/browse/CAMEL-20888
> Project: Camel
>  Issue Type: Task
>  Components: camel-kotlin
>Affects Versions: 4.7.0
>Reporter: Aurélien Pupier
>Assignee: Aurélien Pupier
>Priority: Major
> Fix For: 4.9.0
>
>
> Kotlin DSL was deprecated in 4.7.0



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


[jira] [Created] (CAMEL-21207) Camel-Opensearch: Provide a parameter to set HostNameVerifier on client

2024-09-11 Thread Andrea Cosentino (Jira)
Andrea Cosentino created CAMEL-21207:


 Summary: Camel-Opensearch: Provide a parameter to set 
HostNameVerifier on client
 Key: CAMEL-21207
 URL: https://issues.apache.org/jira/browse/CAMEL-21207
 Project: Camel
  Issue Type: New Feature
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
 Fix For: 4.9.0






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


[jira] [Resolved] (CAMEL-21206) Camel-Google-Storage: Support prefix in ListObjects operation

2024-09-11 Thread Andrea Cosentino (Jira)


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

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

> Camel-Google-Storage: Support prefix in ListObjects operation
> -
>
> Key: CAMEL-21206
> URL: https://issues.apache.org/jira/browse/CAMEL-21206
> Project: Camel
>  Issue Type: New Feature
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 4.9.0
>
>




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


[jira] [Created] (CAMEL-21206) Camel-Google-Storage: Support prefix in ListObjects operation

2024-09-11 Thread Andrea Cosentino (Jira)
Andrea Cosentino created CAMEL-21206:


 Summary: Camel-Google-Storage: Support prefix in ListObjects 
operation
 Key: CAMEL-21206
 URL: https://issues.apache.org/jira/browse/CAMEL-21206
 Project: Camel
  Issue Type: New Feature
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
 Fix For: 4.9.0






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


[jira] [Updated] (CAMEL-21205) Remove Groovy DSL

2024-09-11 Thread Jira


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

Aurélien Pupier updated CAMEL-21205:

Description: 
it was experimental butnot marked as deprecated,, maybe need to state it as 
experimental for 4.9 and remove in 4.10 only?


Note: take care to remove only the DSL part, not the language expression part.

  was:it was experimental butnot marked as deprecated,, maybe need to state it 
as experimental for 4.9 and remove in 4.10 only?


> Remove Groovy DSL
> -
>
> Key: CAMEL-21205
> URL: https://issues.apache.org/jira/browse/CAMEL-21205
> Project: Camel
>  Issue Type: Task
>Reporter: Aurélien Pupier
>Priority: Major
>
> it was experimental butnot marked as deprecated,, maybe need to state it as 
> experimental for 4.9 and remove in 4.10 only?
> Note: take care to remove only the DSL part, not the language expression part.



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


[jira] [Created] (CAMEL-21205) Remove Groovy DSL

2024-09-11 Thread Jira
Aurélien Pupier created CAMEL-21205:
---

 Summary: Remove Groovy DSL
 Key: CAMEL-21205
 URL: https://issues.apache.org/jira/browse/CAMEL-21205
 Project: Camel
  Issue Type: Task
Reporter: Aurélien Pupier


it was experimental butnot marked as deprecated,, maybe need to state it as 
experimental for 4.9 and remove in 4.10 only?



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


[jira] [Created] (CAMEL-21204) Remove JavaScript DSL

2024-09-11 Thread Jira
Aurélien Pupier created CAMEL-21204:
---

 Summary: Remove JavaScript DSL
 Key: CAMEL-21204
 URL: https://issues.apache.org/jira/browse/CAMEL-21204
 Project: Camel
  Issue Type: Task
Reporter: Aurélien Pupier
 Fix For: 4.9.0


JavaScript DSl was deprecated in 4.6



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


[jira] [Created] (CAMEL-21203) Remove JavaShell DSL

2024-09-11 Thread Jira
Aurélien Pupier created CAMEL-21203:
---

 Summary: Remove JavaShell DSL
 Key: CAMEL-21203
 URL: https://issues.apache.org/jira/browse/CAMEL-21203
 Project: Camel
  Issue Type: Task
Reporter: Aurélien Pupier
 Fix For: 4.9.0


JavaShell DSL was deprecated in 4.6



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


[jira] [Updated] (CAMEL-21200) camel-activemq - OSGi javax.jms range is wrong

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21200:

Summary: camel-activemq - OSGi javax.jms range is wrong  (was: OSGi 
javax.jms range is wrong)

> camel-activemq - OSGi javax.jms range is wrong
> --
>
> Key: CAMEL-21200
> URL: https://issues.apache.org/jira/browse/CAMEL-21200
> Project: Camel
>  Issue Type: Bug
>  Components: camel-activemq
>Affects Versions: 3.22.0
>Reporter: Francois Papon
>Priority: Major
> Fix For: 3.22.3
>
>
> The OSGi range of the javax.jms is not correct and break the installation of 
> the bundle in Karaf.
> The range is define is *javax.jms;version="[1.1,2)"* but the bundle depend on 
> *camel-jms* which the range is *javax.jms;version="[1.1,3)"*
> We should align the range of *camel-activemq* to the {*}camel-jms one{*}.



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


[jira] [Resolved] (CAMEL-21200) OSGi javax.jms range is wrong

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-21200.
-
Resolution: Fixed

> OSGi javax.jms range is wrong
> -
>
> Key: CAMEL-21200
> URL: https://issues.apache.org/jira/browse/CAMEL-21200
> Project: Camel
>  Issue Type: Bug
>  Components: camel-activemq
>Affects Versions: 3.22.0
>Reporter: Francois Papon
>Priority: Major
> Fix For: 3.22.3
>
>
> The OSGi range of the javax.jms is not correct and break the installation of 
> the bundle in Karaf.
> The range is define is *javax.jms;version="[1.1,2)"* but the bundle depend on 
> *camel-jms* which the range is *javax.jms;version="[1.1,3)"*
> We should align the range of *camel-activemq* to the {*}camel-jms one{*}.



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


[jira] [Updated] (CAMEL-21200) camel-activemq - OSGi javax.jms range is wrong

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21200:

Component/s: karaf

> camel-activemq - OSGi javax.jms range is wrong
> --
>
> Key: CAMEL-21200
> URL: https://issues.apache.org/jira/browse/CAMEL-21200
> Project: Camel
>  Issue Type: Bug
>  Components: camel-activemq, karaf
>Affects Versions: 3.22.0
>Reporter: Francois Papon
>Priority: Minor
> Fix For: 3.22.3
>
>
> The OSGi range of the javax.jms is not correct and break the installation of 
> the bundle in Karaf.
> The range is define is *javax.jms;version="[1.1,2)"* but the bundle depend on 
> *camel-jms* which the range is *javax.jms;version="[1.1,3)"*
> We should align the range of *camel-activemq* to the {*}camel-jms one{*}.



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


[jira] [Updated] (CAMEL-21200) camel-activemq - OSGi javax.jms range is wrong

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21200:

Priority: Minor  (was: Major)

> camel-activemq - OSGi javax.jms range is wrong
> --
>
> Key: CAMEL-21200
> URL: https://issues.apache.org/jira/browse/CAMEL-21200
> Project: Camel
>  Issue Type: Bug
>  Components: camel-activemq
>Affects Versions: 3.22.0
>Reporter: Francois Papon
>Priority: Minor
> Fix For: 3.22.3
>
>
> The OSGi range of the javax.jms is not correct and break the installation of 
> the bundle in Karaf.
> The range is define is *javax.jms;version="[1.1,2)"* but the bundle depend on 
> *camel-jms* which the range is *javax.jms;version="[1.1,3)"*
> We should align the range of *camel-activemq* to the {*}camel-jms one{*}.



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


[jira] [Updated] (CAMEL-21200) OSGi javax.jms range is wrong

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21200:

Affects Version/s: 3.22.0
   (was: 3.x)

> OSGi javax.jms range is wrong
> -
>
> Key: CAMEL-21200
> URL: https://issues.apache.org/jira/browse/CAMEL-21200
> Project: Camel
>  Issue Type: Bug
>  Components: camel-activemq
>Affects Versions: 3.22.0
>Reporter: Francois Papon
>Priority: Major
> Fix For: 3.22.3
>
>
> The OSGi range of the javax.jms is not correct and break the installation of 
> the bundle in Karaf.
> The range is define is *javax.jms;version="[1.1,2)"* but the bundle depend on 
> *camel-jms* which the range is *javax.jms;version="[1.1,3)"*
> We should align the range of *camel-activemq* to the {*}camel-jms one{*}.



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


[jira] [Created] (CAMEL-21202) Add a ThreadPoolFactory to propagate OpenTelemetry contexts

2024-09-11 Thread Adriano Machado (Jira)
Adriano Machado created CAMEL-21202:
---

 Summary: Add a ThreadPoolFactory to propagate OpenTelemetry 
contexts
 Key: CAMEL-21202
 URL: https://issues.apache.org/jira/browse/CAMEL-21202
 Project: Camel
  Issue Type: New Feature
  Components: camel-opentelemetry
Affects Versions: 4.4.0
Reporter: Adriano Machado
Assignee: Adriano Machado


Add a ThreadPoolFactory to propagate OpenTelemetry contexts, as per 
OpenTelemetry's documentation:

[https://opentelemetry.io/docs/languages/java/instrumentation/#context-propagation-between-threads]



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


[jira] [Resolved] (CAMEL-21201) camel-ftp - Enrich exception with FTP client error codes if failing to upload file

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-21201.
-
Resolution: Fixed

> camel-ftp - Enrich exception with FTP client error codes if failing to upload 
> file
> --
>
> Key: CAMEL-21201
> URL: https://issues.apache.org/jira/browse/CAMEL-21201
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.9.0
>
>
> You see a generic exception such as
>  
> ileOperationFailedException - Error writing file 
> [ID-2925776a-703a-11ef-9df5-3ab92e8528c7]]
> org.apache.camel.component.file.GenericFileOperationFailedException: Error 
> writing file [ID-2925776a-703a-11ef-9df5-3ab92e8528c7]
>  
> But the FTP client has status code and text which we should include so the 
> user can understand the error better.



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


[jira] [Updated] (CAMEL-20626) deprecate JavaScript and JavaShell experimental DSLs

2024-09-11 Thread Jira


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

Aurélien Pupier updated CAMEL-20626:

Summary: deprecate JavaScript and JavaShell experimental DSLs  (was: 
deprecate experimental DSLs)

> deprecate JavaScript and JavaShell experimental DSLs
> 
>
> Key: CAMEL-20626
> URL: https://issues.apache.org/jira/browse/CAMEL-20626
> Project: Camel
>  Issue Type: Task
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.6.0
>
>
> camel-js-dsl and camel-jsh-dsl.
> They were some very basic prototypes. You can use javascript with camel with 
> the camel-javascript component.



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


[jira] [Commented] (CAMEL-21068) Add support for `camel kubernetes run` for all runtimes

2024-09-11 Thread Thomas Diesler (Jira)


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

Thomas Diesler commented on CAMEL-21068:


This provides basic run functionality. I'd still like to review --wait --dev 
--log and a few other settings across all runtimes

> Add support for `camel kubernetes run` for all runtimes
> ---
>
> Key: CAMEL-21068
> URL: https://issues.apache.org/jira/browse/CAMEL-21068
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
>  `camel kubernetes run ...` is currently limited to `--runtime=quarkus`



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


[jira] [Commented] (CAMEL-21201) camel-ftp - Enrich exception with FTP client error codes if failing to upload file

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen commented on CAMEL-21201:
-

org.apache.camel.component.file.GenericFileOperationFailedException: File 
operation failed: 500 Illegal PORT command.
 Error writing file [ID-06f198e5-703c-11ef-b52b-3ab92e8528c7]. Code: 500
    at 
org.apache.camel.component.file.remote.FtpOperations.storeFile(FtpOperations.java:717)
 ~[camel-ftp-4.9.0-SNAPSHOT.jar:4.9.0-SNAPSHOT]
    at 
org.apache.camel.component.file.GenericFileProducer.writeFile(GenericFileProducer.java:342)
 ~[camel-file-4.9.0-SNAPSHOT.jar:4.9.0-SNAPSHOT]
    at 
org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:154)
 ~[camel-file-4.9.0-SNAPSHOT.jar:4.9.0-SNAPSHOT]
    at 
org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:61)
 ~[camel-ftp-4.9.0-SNAPSHOT.jar:4.9.0-SNAPSHOT]

> camel-ftp - Enrich exception with FTP client error codes if failing to upload 
> file
> --
>
> Key: CAMEL-21201
> URL: https://issues.apache.org/jira/browse/CAMEL-21201
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.9.0
>
>
> You see a generic exception such as
>  
> ileOperationFailedException - Error writing file 
> [ID-2925776a-703a-11ef-9df5-3ab92e8528c7]]
> org.apache.camel.component.file.GenericFileOperationFailedException: Error 
> writing file [ID-2925776a-703a-11ef-9df5-3ab92e8528c7]
>  
> But the FTP client has status code and text which we should include so the 
> user can understand the error better.



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


[jira] [Created] (CAMEL-21201) camel-ftp - Enrich exception with FTP client error codes if failing to upload file

2024-09-11 Thread Claus Ibsen (Jira)
Claus Ibsen created CAMEL-21201:
---

 Summary: camel-ftp - Enrich exception with FTP client error codes 
if failing to upload file
 Key: CAMEL-21201
 URL: https://issues.apache.org/jira/browse/CAMEL-21201
 Project: Camel
  Issue Type: Improvement
  Components: camel-ftp
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 4.9.0


You see a generic exception such as

 

ileOperationFailedException - Error writing file 
[ID-2925776a-703a-11ef-9df5-3ab92e8528c7]]
org.apache.camel.component.file.GenericFileOperationFailedException: Error 
writing file [ID-2925776a-703a-11ef-9df5-3ab92e8528c7]

 

But the FTP client has status code and text which we should include so the user 
can understand the error better.



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


[jira] [Created] (CAMEL-21200) OSGi javax.jms range is wrong

2024-09-11 Thread Francois Papon (Jira)
Francois Papon created CAMEL-21200:
--

 Summary: OSGi javax.jms range is wrong
 Key: CAMEL-21200
 URL: https://issues.apache.org/jira/browse/CAMEL-21200
 Project: Camel
  Issue Type: Bug
  Components: camel-activemq
Affects Versions: 3.x
Reporter: Francois Papon
 Fix For: 3.22.3


The OSGi range of the javax.jms is not correct and break the installation of 
the bundle in Karaf.

The range is define is *javax.jms;version="[1.1,2)"* but the bundle depend on 
*camel-jms* which the range is *javax.jms;version="[1.1,3)"*

We should align the range of *camel-activemq* to the {*}camel-jms one{*}.



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


[jira] [Updated] (CAMEL-21192) jbang camel k8s run may fail with NPE

2024-09-11 Thread Thomas Diesler (Jira)


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

Thomas Diesler updated CAMEL-21192:
---
Fix Version/s: (was: 4.9.0)

> jbang camel k8s run may fail with NPE
> -
>
> Key: CAMEL-21192
> URL: https://issues.apache.org/jira/browse/CAMEL-21192
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
>
> {code}
> [jbang] Resolving dependencies...
> [jbang]    org.apache.camel:camel-bom:4.9.0-SNAPSHOT@pom
> [jbang]    org.apache.camel:camel-jbang-core:4.9.0-SNAPSHOT
> [jbang]    org.apache.camel.kamelets:camel-kamelets:4.7.0
> [jbang] Dependencies resolved
> Exporting application ...
> *java.lang.NullPointerException: Cannot invoke 
> "io.fabric8.kubernetes.api.model.Pod.getStatus()" because "it" is null*
>  _at 
> org.apache.camel.dsl.jbang.core.commands.kubernetes.KubernetesRun.lambda$doCall$0(KubernetesRun.java:322)_
>  _at 
> io.fabric8.kubernetes.client.dsl.internal.BaseOperation.lambda$waitUntilCondition$9(BaseOperation.java:935)_
>  _at 
> io.fabric8.kubernetes.client.dsl.internal.BaseOperation.lambda$informOnCondition$12(BaseOperation.java:967)_
>  _at 
> io.fabric8.kubernetes.client.dsl.internal.BaseOperation$3.onNothing(BaseOperation.java:993)_
>  _at 
> io.fabric8.kubernetes.client.informers.impl.cache.ProcessorStore.lambda$retainAll$2(ProcessorStore.java:106)_
>  _at 
> io.fabric8.kubernetes.client.informers.impl.cache.SharedProcessor.lambda$distribute$1(SharedProcessor.java:114)_
>  _at 
> io.fabric8.kubernetes.client.utils.internal.SerialExecutor.lambda$execute$0(SerialExecutor.java:57)_
>  _at 
> io.fabric8.kubernetes.client.utils.internal.SerialExecutor.scheduleNext(SerialExecutor.java:75)_
>  _at 
> io.fabric8.kubernetes.client.utils.internal.SerialExecutor.execute(SerialExecutor.java:69)_
> {code}



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


[jira] [Resolved] (CAMEL-21192) jbang camel k8s run may fail with NPE

2024-09-11 Thread Thomas Diesler (Jira)


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

Thomas Diesler resolved CAMEL-21192.

Resolution: Implemented

Out of Date

> jbang camel k8s run may fail with NPE
> -
>
> Key: CAMEL-21192
> URL: https://issues.apache.org/jira/browse/CAMEL-21192
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
> {code}
> [jbang] Resolving dependencies...
> [jbang]    org.apache.camel:camel-bom:4.9.0-SNAPSHOT@pom
> [jbang]    org.apache.camel:camel-jbang-core:4.9.0-SNAPSHOT
> [jbang]    org.apache.camel.kamelets:camel-kamelets:4.7.0
> [jbang] Dependencies resolved
> Exporting application ...
> *java.lang.NullPointerException: Cannot invoke 
> "io.fabric8.kubernetes.api.model.Pod.getStatus()" because "it" is null*
>  _at 
> org.apache.camel.dsl.jbang.core.commands.kubernetes.KubernetesRun.lambda$doCall$0(KubernetesRun.java:322)_
>  _at 
> io.fabric8.kubernetes.client.dsl.internal.BaseOperation.lambda$waitUntilCondition$9(BaseOperation.java:935)_
>  _at 
> io.fabric8.kubernetes.client.dsl.internal.BaseOperation.lambda$informOnCondition$12(BaseOperation.java:967)_
>  _at 
> io.fabric8.kubernetes.client.dsl.internal.BaseOperation$3.onNothing(BaseOperation.java:993)_
>  _at 
> io.fabric8.kubernetes.client.informers.impl.cache.ProcessorStore.lambda$retainAll$2(ProcessorStore.java:106)_
>  _at 
> io.fabric8.kubernetes.client.informers.impl.cache.SharedProcessor.lambda$distribute$1(SharedProcessor.java:114)_
>  _at 
> io.fabric8.kubernetes.client.utils.internal.SerialExecutor.lambda$execute$0(SerialExecutor.java:57)_
>  _at 
> io.fabric8.kubernetes.client.utils.internal.SerialExecutor.scheduleNext(SerialExecutor.java:75)_
>  _at 
> io.fabric8.kubernetes.client.utils.internal.SerialExecutor.execute(SerialExecutor.java:69)_
> {code}



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


[jira] [Resolved] (CAMEL-21068) Add support for `camel kubernetes run` for all runtimes

2024-09-11 Thread Thomas Diesler (Jira)


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

Thomas Diesler resolved CAMEL-21068.

Resolution: Fixed

Done

> Add support for `camel kubernetes run` for all runtimes
> ---
>
> Key: CAMEL-21068
> URL: https://issues.apache.org/jira/browse/CAMEL-21068
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
>  `camel kubernetes run ...` is currently limited to `--runtime=quarkus`



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


[jira] [Comment Edited] (CAMEL-21199) Camel-jackson not properly marshalling 4-byte characters

2024-09-11 Thread Radovan Netuka (Jira)


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

Radovan Netuka edited comment on CAMEL-21199 at 9/11/24 11:48 AM:
--

It's problem of Jackson-core's {_}UTF8JsonGenerator{_}. Their other generator - 
_WriterBasedJsonGenerator_ - doesn't seem to suffer from this issue. 

 

While it'd be great to have this fixed on Jackson side, they keep the issue 
open from 2015 and rejected several PRs which were trying to provide a fix.

 

PR bellow tries to avoid the issue by forcing Jackson to use 
_WriterBasedJsonGenerator._ 

 

PR:

[https://github.com/apache/camel/pull/15515]


was (Author: rnetuka):
It's problem of Jackson-core's {_}UTF8JsonGenerator{_}. Their other generator - 
_WriterBasedJsonGenerator_ doesn't seem to suffer from this issue. 

 

While it'd be great to have this fixed on Jackson side, they keep the issue 
opened from 2015 and rejected several PRs which were trying to provide a fix.

 

PR bellow tries to avoid the issue by forcing Jackson to use 
_WriterBasedJsonGenerator._ 

 

PR:

https://github.com/apache/camel/pull/15515

> Camel-jackson not properly marshalling 4-byte characters
> 
>
> Key: CAMEL-21199
> URL: https://issues.apache.org/jira/browse/CAMEL-21199
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jackson
>Reporter: Radovan Netuka
>Assignee: Radovan Netuka
>Priority: Major
>
> Camel-jackson doesn't handle 4-byte characters well. Marshalling a 4-byte 
> Japanese kanji character results in two UTF-16 escapes to be written instead 
> of the character itself. While this is ok for emoji an such, it's not for 
> natural languages.
> Jackson issue: 
> [FasterXML/jackson-core#223|https://github.com/FasterXML/jackson-core/issues/223]
>  
> Reproducer:
> {code:java}
> from("file:data?file-name=input.txt&noop=true")
> .log("${body}")
> .unmarshal().json(JsonLibrary.Jackson)
> .log("${body[0]['name']}")
> .marshal().json(JsonLibrary.Jackson, true)
> .log("${body}"); {code}
>  
> with the file input.txt containing:
> {code:java}
> [{"name": "システム𩸽"}] {code}
>  
> Expected output seen in the log: *"システム𩸽"*
> Actual output seen in the log: *"システム\uD867\uDE3D"*



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


[jira] [Updated] (CAMEL-21199) Camel-jackson not properly marshalling 4-byte characters

2024-09-11 Thread Radovan Netuka (Jira)


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

Radovan Netuka updated CAMEL-21199:
---
External issue URL: https://github.com/FasterXML/jackson-core/issues/223

> Camel-jackson not properly marshalling 4-byte characters
> 
>
> Key: CAMEL-21199
> URL: https://issues.apache.org/jira/browse/CAMEL-21199
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jackson
>Reporter: Radovan Netuka
>Assignee: Radovan Netuka
>Priority: Major
>
> Camel-jackson doesn't handle 4-byte characters well. Marshalling a 4-byte 
> Japanese kanji character results in two UTF-16 escapes to be written instead 
> of the character itself. While this is ok for emoji an such, it's not for 
> natural languages.
> Jackson issue: 
> [FasterXML/jackson-core#223|https://github.com/FasterXML/jackson-core/issues/223]
>  
> Reproducer:
> {code:java}
> from("file:data?file-name=input.txt&noop=true")
> .log("${body}")
> .unmarshal().json(JsonLibrary.Jackson)
> .log("${body[0]['name']}")
> .marshal().json(JsonLibrary.Jackson, true)
> .log("${body}"); {code}
>  
> with the file input.txt containing:
> {code:java}
> [{"name": "システム𩸽"}] {code}
>  
> Expected output seen in the log: *"システム𩸽"*
> Actual output seen in the log: *"システム\uD867\uDE3D"*



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


[jira] [Commented] (CAMEL-21068) Add support for `camel kubernetes run` for all runtimes

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen commented on CAMEL-21068:
-

Thanks Thomas. Is there more work or can this ticket be resolved

> Add support for `camel kubernetes run` for all runtimes
> ---
>
> Key: CAMEL-21068
> URL: https://issues.apache.org/jira/browse/CAMEL-21068
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
>  `camel kubernetes run ...` is currently limited to `--runtime=quarkus`



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


[jira] [Updated] (CAMEL-21199) Camel-jackson not properly marshalling 4-byte characters

2024-09-11 Thread Radovan Netuka (Jira)


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

Radovan Netuka updated CAMEL-21199:
---
Description: 
Camel-jackson doesn't handle 4-byte characters well. Marshalling a 4-byte 
Japanese kanji character results in two UTF-16 escapes to be written instead of 
the character itself. While this is ok for emoji an such, it's not for natural 
languages.

Jackson issue: 
[FasterXML/jackson-core#223|https://github.com/FasterXML/jackson-core/issues/223]

 

Reproducer:
{code:java}
from("file:data?file-name=input.txt&noop=true")
.log("${body}")
.unmarshal().json(JsonLibrary.Jackson)
.log("${body[0]['name']}")
.marshal().json(JsonLibrary.Jackson, true)
.log("${body}"); {code}
 
with the file input.txt containing:
{code:java}
[{"name": "システム𩸽"}] {code}
 

Expected output seen in the log: *"システム𩸽"*

Actual output seen in the log: *"システム\uD867\uDE3D"*

  was:
Camel-jackson doesn't handle 4-byte characters well. Marshalling a 4-byte 
Japanese kanji character results in two UTF-16 escapes to be written instead of 
the character itself. While this is ok for emoji an such, it's not for natural 
languages.

Jackson issue: 
[FasterXML/jackson-core#223|https://github.com/FasterXML/jackson-core/issues/223]

 

Reproducer:
{code:java}
from("file:data?file-name=input.txt&noop=true")
.log("${body}")
.unmarshal().json(JsonLibrary.Jackson)
.log("${body[0]['name']}")
.marshal().json(JsonLibrary.Jackson, true)
.log("${body}"); {code}

 
with the file input.txt containing:
{code:java}
[{"name": "システム𩸽"}] {code}


> Camel-jackson not properly marshalling 4-byte characters
> 
>
> Key: CAMEL-21199
> URL: https://issues.apache.org/jira/browse/CAMEL-21199
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jackson
>Reporter: Radovan Netuka
>Assignee: Radovan Netuka
>Priority: Major
>
> Camel-jackson doesn't handle 4-byte characters well. Marshalling a 4-byte 
> Japanese kanji character results in two UTF-16 escapes to be written instead 
> of the character itself. While this is ok for emoji an such, it's not for 
> natural languages.
> Jackson issue: 
> [FasterXML/jackson-core#223|https://github.com/FasterXML/jackson-core/issues/223]
>  
> Reproducer:
> {code:java}
> from("file:data?file-name=input.txt&noop=true")
> .log("${body}")
> .unmarshal().json(JsonLibrary.Jackson)
> .log("${body[0]['name']}")
> .marshal().json(JsonLibrary.Jackson, true)
> .log("${body}"); {code}
>  
> with the file input.txt containing:
> {code:java}
> [{"name": "システム𩸽"}] {code}
>  
> Expected output seen in the log: *"システム𩸽"*
> Actual output seen in the log: *"システム\uD867\uDE3D"*



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


[jira] [Updated] (CAMEL-21199) Camel-jackson not properly marshalling 4-byte characters

2024-09-11 Thread Radovan Netuka (Jira)


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

Radovan Netuka updated CAMEL-21199:
---
Description: 
Camel-jackson doesn't handle 4-byte characters well. Marshalling a 4-byte 
Japanese kanji character results in two UTF-16 escapes to be written instead of 
the character itself. While this is ok for emoji an such, it's not for natural 
languages.

Jackson issue: 
[FasterXML/jackson-core#223|https://github.com/FasterXML/jackson-core/issues/223]

 

Reproducer:
{code:java}
from("file:data?file-name=input.txt&noop=true")
.log("${body}")
.unmarshal().json(JsonLibrary.Jackson)
.log("${body[0]['name']}")
.marshal().json(JsonLibrary.Jackson, true)
.log("${body}"); {code}

 
with the file input.txt containing:
{code:java}
[{"name": "システム𩸽"}] {code}

  was:
Camel-jackson doesn't handle 4-byte characters well. Marshalling a 4-byte 
Japanese kanji character results in two UTF-16 escapes to be written instead of 
the character itself. While this is ok for emoji an such, it's not for natural 
languages.

Jackson issue: 
[FasterXML/jackson-core#223|https://github.com/FasterXML/jackson-core/issues/223]

 

Reproducer:
from("file:data?file-name=input.txt&noop=true")
.log("${body}")
.unmarshal().json(JsonLibrary.Jackson)
.log("${body[0]['name']}")
.marshal().json(JsonLibrary.Jackson, true)
.log("${body}");
 
with the file input.txt containing:
{code:java}
[{"name": "システム𩸽"}] {code}


> Camel-jackson not properly marshalling 4-byte characters
> 
>
> Key: CAMEL-21199
> URL: https://issues.apache.org/jira/browse/CAMEL-21199
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jackson
>Reporter: Radovan Netuka
>Assignee: Radovan Netuka
>Priority: Major
>
> Camel-jackson doesn't handle 4-byte characters well. Marshalling a 4-byte 
> Japanese kanji character results in two UTF-16 escapes to be written instead 
> of the character itself. While this is ok for emoji an such, it's not for 
> natural languages.
> Jackson issue: 
> [FasterXML/jackson-core#223|https://github.com/FasterXML/jackson-core/issues/223]
>  
> Reproducer:
> {code:java}
> from("file:data?file-name=input.txt&noop=true")
> .log("${body}")
> .unmarshal().json(JsonLibrary.Jackson)
> .log("${body[0]['name']}")
> .marshal().json(JsonLibrary.Jackson, true)
> .log("${body}"); {code}
>  
> with the file input.txt containing:
> {code:java}
> [{"name": "システム𩸽"}] {code}



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


[jira] [Commented] (CAMEL-20888) Remove Kotlin DSL

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen commented on CAMEL-20888:
-

The 4.9 migration doc needs to have details about the removed JARs

> Remove Kotlin DSL
> -
>
> Key: CAMEL-20888
> URL: https://issues.apache.org/jira/browse/CAMEL-20888
> Project: Camel
>  Issue Type: Task
>  Components: camel-kotlin
>Affects Versions: 4.7.0
>Reporter: Aurélien Pupier
>Assignee: Aurélien Pupier
>Priority: Major
> Fix For: 4.9.0
>
>
> Kotlin DSL was deprecated in 4.7.0



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


[jira] [Commented] (CAMEL-21199) Camel-jackson not properly marshalling 4-byte characters

2024-09-11 Thread Radovan Netuka (Jira)


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

Radovan Netuka commented on CAMEL-21199:


It's problem of Jackson-core's {_}UTF8JsonGenerator{_}. Their other generator - 
_WriterBasedJsonGenerator_ doesn't seem to suffer from this issue. 

 

While it'd be great to have this fixed on Jackson side, they keep the issue 
opened from 2015 and rejected several PRs which were trying to provide a fix.

 

PR bellow tries to avoid the issue by forcing Jackson to use 
_WriterBasedJsonGenerator._ 

 

PR:

https://github.com/apache/camel/pull/15515

> Camel-jackson not properly marshalling 4-byte characters
> 
>
> Key: CAMEL-21199
> URL: https://issues.apache.org/jira/browse/CAMEL-21199
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jackson
>Reporter: Radovan Netuka
>Assignee: Radovan Netuka
>Priority: Major
>
> Camel-jackson doesn't handle 4-byte characters well. Marshalling a 4-byte 
> Japanese kanji character results in two UTF-16 escapes to be written instead 
> of the character itself. While this is ok for emoji an such, it's not for 
> natural languages.
> Jackson issue: 
> [FasterXML/jackson-core#223|https://github.com/FasterXML/jackson-core/issues/223]
>  
> Reproducer:
> from("file:data?file-name=input.txt&noop=true")
> .log("${body}")
> .unmarshal().json(JsonLibrary.Jackson)
> .log("${body[0]['name']}")
> .marshal().json(JsonLibrary.Jackson, true)
> .log("${body}");
>  
> with the file input.txt containing:
> {code:java}
> [{"name": "システム𩸽"}] {code}



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


[jira] [Created] (CAMEL-21199) Camel-jackson not properly marshalling 4-byte characters

2024-09-11 Thread Radovan Netuka (Jira)
Radovan Netuka created CAMEL-21199:
--

 Summary: Camel-jackson not properly marshalling 4-byte characters
 Key: CAMEL-21199
 URL: https://issues.apache.org/jira/browse/CAMEL-21199
 Project: Camel
  Issue Type: Bug
  Components: camel-jackson
Reporter: Radovan Netuka
Assignee: Radovan Netuka


Camel-jackson doesn't handle 4-byte characters well. Marshalling a 4-byte 
Japanese kanji character results in two UTF-16 escapes to be written instead of 
the character itself. While this is ok for emoji an such, it's not for natural 
languages.

Jackson issue: 
[FasterXML/jackson-core#223|https://github.com/FasterXML/jackson-core/issues/223]

 

Reproducer:
from("file:data?file-name=input.txt&noop=true")
.log("${body}")
.unmarshal().json(JsonLibrary.Jackson)
.log("${body[0]['name']}")
.marshal().json(JsonLibrary.Jackson, true)
.log("${body}");
 
with the file input.txt containing:
{code:java}
[{"name": "システム𩸽"}] {code}



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


[jira] [Resolved] (CAMEL-21187) camel-disruptor - Interrupted exception in some unit tests

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-21187.
-
Resolution: Cannot Reproduce

Cannot see these problems today

> camel-disruptor - Interrupted exception in some unit tests
> --
>
> Key: CAMEL-21187
> URL: https://issues.apache.org/jira/browse/CAMEL-21187
> Project: Camel
>  Issue Type: Test
>  Components: camel-disruptor
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 4.x
>
>
> [INFO] Running 
> org.apache.camel.component.disruptor.vm.DisruptorVmInOutChainedTest
> Exception in thread "Camel (camel-84) thread #391 - disruptor-vm://a" 
> java.lang.RuntimeException: java.lang.InterruptedException
>     at 
> com.lmax.disruptor.FatalExceptionHandler.handleEventException(FatalExceptionHandler.java:45)
>     at 
> com.lmax.disruptor.dsl.ExceptionHandlerWrapper.handleEventException(ExceptionHandlerWrapper.java:18)
>     at 
> com.lmax.disruptor.BatchEventProcessor.handleEventException(BatchEventProcessor.java:257)
>     at 
> com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:187)
>     at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>     at java.base/java.lang.Thread.run(Thread.java:840)
> Caused by: java.lang.InterruptedException
>     at 
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1640)
>     at 
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:47)
>     at 
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>     at 
> com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159)
>     ... 4 more
> Exception in thread "Camel (camel-84) thread #392 - disruptor-vm://b" 
> java.lang.RuntimeException: java.lang.InterruptedException
>     at 
> com.lmax.disruptor.FatalExceptionHandler.handleEventException(FatalExceptionHandler.java:45)
>     at 
> com.lmax.disruptor.dsl.ExceptionHandlerWrapper.handleEventException(ExceptionHandlerWrapper.java:18)
>     at 
> com.lmax.disruptor.BatchEventProcessor.handleEventException(BatchEventProcessor.java:257)
>     at 
> com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:187)
>     at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>     at java.base/java.lang.Thread.run(Thread.java:840)
> Caused by: java.lang.InterruptedException
>     at 
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1640)
>     at 
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:47)
>     at 
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>     at 
> com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159)
>     ... 4 more
> Exception in thread "Camel (camel-84) thread #393 - disruptor-vm://c" 
> java.lang.RuntimeException: java.lang.InterruptedException
>     at 
> com.lmax.disruptor.FatalExceptionHandler.handleEventException(FatalExceptionHandler.java:45)
>     at 
> com.lmax.disruptor.dsl.ExceptionHandlerWrapper.handleEventException(ExceptionHandlerWrapper.java:18)
>     at 
> com.lmax.disruptor.BatchEventProcessor.handleEventException(BatchEventProcessor.java:257)
>     at 
> com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:187)
>     at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>     at java.base/java.lang.Thread.run(Thread.java:840)
> Caused by: java.lang.InterruptedException
>     at 
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1640)
>     at 
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:47

[jira] [Updated] (CAMEL-21068) Add support for `camel kubernetes run` for all runtimes

2024-09-11 Thread Thomas Diesler (Jira)


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

Thomas Diesler updated CAMEL-21068:
---
Description:  `camel kubernetes run ...` is currently limited to 
`--runtime=quarkus`  (was: This currently seems to be limited to 
`--runtime=quarkus`)

> Add support for `camel kubernetes run` for all runtimes
> ---
>
> Key: CAMEL-21068
> URL: https://issues.apache.org/jira/browse/CAMEL-21068
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
>  `camel kubernetes run ...` is currently limited to `--runtime=quarkus`



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


[jira] [Comment Edited] (CAMEL-21197) URISupport.parseQuery is not decoding correctly

2024-09-11 Thread Dirk Fiedler (Jira)


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

Dirk Fiedler edited comment on CAMEL-21197 at 9/11/24 9:33 AM:
---

Hi Claus,

we are using the Apache Camel LRA within a Java SpringBoot project.

Until last week, we are using Narayana as an LRA Coordinator .. now we try 
to switch to Oracle MicroTX.

We found two problems.

This one occurs while 'org.apache.camel.service.lra.LRASagaRoutes' is verifying 
the incomming request from the LRA Coordinator. The call is URL encoded from 
Oracle:
{code:java}
PUT 
/camel/complete?Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete 
HTTP/1.1Host{code}
Within LRASagaService the util is used:
{code:java}
URISupport.parseQuery(exchange.getIn().getHeader(Exchange.HTTP_QUERY, 
String.class)); {code}
The LRA code expects / needs the decoded value, but get the encoded one from 
the Util.

For the second problem i am preparing a solution .. will create a Jira ticket 
and will try to contribute ..

Before i do this, i want to be sure, that i understood this util correct ..

best regards

Dirk


was (Author: JIRAUSER306992):
Hi Claus,

we are using the Apache Camel LRA within a Java SpringBoot project.

Until last week, we are using Narayana as an LRA Coordinator .. now we try 
to switch to Oracle MicroTX. 

We found two problems.

This one occurs while 'org.apache.camel.service.lra.LRASagaService' is 
verifying 
the incomming request from the LRA Coordinator. The call is URL encoded from 
Oracle:


{code:java}
PUT 
/camel/complete?Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete 
HTTP/1.1Host{code}
Within LRASagaService the util is used:


{code:java}
URISupport.parseQuery(exchange.getIn().getHeader(Exchange.HTTP_QUERY, 
String.class)); {code}

The LRA code expects / needs the decoded value, but get the encoded one from 
the Util.

For the second problem i am preparing a solution .. will create a Jira ticket 
and will try to contribute ..

Before i do this, i want to be sure, that i understood this util correct ..

best regards

Dirk

> URISupport.parseQuery is not decoding correctly
> ---
>
> Key: CAMEL-21197
> URL: https://issues.apache.org/jira/browse/CAMEL-21197
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 4.7.0
>Reporter: Dirk Fiedler
>Priority: Minor
>
> {color:#00}Hi team,{color}
> {color:#00}while using *URISupport.parseQuery* the given query was not 
> correctly decoded:{color}
> *{color:#00}Sample JUnit test 
> (org.apache.camel.util.URISupportTest):{color}*
>  
> {code:java}
> @Test
> public void testParseQueryDFi() throws Exception {
>     Map map = 
> URISupport.parseQuery("Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete");
>     assertEquals(1, map.size());
>     assertEquals("direct://saga1_sagaService_complete", 
> map.get("Camel-Saga-Complete"));
> } {code}
> {color:#00}If i handover the query 
> 'Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete' 
> i expect the decoded value {color}{color:#00}for 'Camel-Saga-Complete' as 
> 'direct://saga1_sagaService_complete'.{color}
> {color:#00}I am wrong? Did i understand the utility class wrong?{color}
> {color:#00}Within the code i can see, that the string was adjusted to 
> replace '%', this is {color}
> {color:#00}causing the issue:{color}
> *{color:#00}URIScanner.addParameter:{color}*
>  
> {code:java}
> if (isRaw) {
>     text = value.toString();
> } else {
>     // need to replace % with %25 to avoid losing "%" when decoding
>     final String s = replacePercent(value.toString());    
> text = URLDecoder.decode(s, CHARSET);
> }{code}
>  
> {color:#00}best regards{color}
> {color:#00}Dirk{color}



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


[jira] [Commented] (CAMEL-21197) URISupport.parseQuery is not decoding correctly

2024-09-11 Thread Dirk Fiedler (Jira)


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

Dirk Fiedler commented on CAMEL-21197:
--

Hi Claus,

we are using the Apache Camel LRA within a Java SpringBoot project.

Until last week, we are using Narayana as an LRA Coordinator .. now we try 
to switch to Oracle MicroTX. 

We found two problems.

This one occurs while 'org.apache.camel.service.lra.LRASagaService' is 
verifying 
the incomming request from the LRA Coordinator. The call is URL encoded from 
Oracle:


{code:java}
PUT 
/camel/complete?Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete 
HTTP/1.1Host{code}
Within LRASagaService the util is used:


{code:java}
URISupport.parseQuery(exchange.getIn().getHeader(Exchange.HTTP_QUERY, 
String.class)); {code}

The LRA code expects / needs the decoded value, but get the encoded one from 
the Util.

For the second problem i am preparing a solution .. will create a Jira ticket 
and will try to contribute ..

Before i do this, i want to be sure, that i understood this util correct ..

best regards

Dirk

> URISupport.parseQuery is not decoding correctly
> ---
>
> Key: CAMEL-21197
> URL: https://issues.apache.org/jira/browse/CAMEL-21197
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 4.7.0
>Reporter: Dirk Fiedler
>Priority: Minor
>
> {color:#00}Hi team,{color}
> {color:#00}while using *URISupport.parseQuery* the given query was not 
> correctly decoded:{color}
> *{color:#00}Sample JUnit test 
> (org.apache.camel.util.URISupportTest):{color}*
>  
> {code:java}
> @Test
> public void testParseQueryDFi() throws Exception {
>     Map map = 
> URISupport.parseQuery("Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete");
>     assertEquals(1, map.size());
>     assertEquals("direct://saga1_sagaService_complete", 
> map.get("Camel-Saga-Complete"));
> } {code}
> {color:#00}If i handover the query 
> 'Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete' 
> i expect the decoded value {color}{color:#00}for 'Camel-Saga-Complete' as 
> 'direct://saga1_sagaService_complete'.{color}
> {color:#00}I am wrong? Did i understand the utility class wrong?{color}
> {color:#00}Within the code i can see, that the string was adjusted to 
> replace '%', this is {color}
> {color:#00}causing the issue:{color}
> *{color:#00}URIScanner.addParameter:{color}*
>  
> {code:java}
> if (isRaw) {
>     text = value.toString();
> } else {
>     // need to replace % with %25 to avoid losing "%" when decoding
>     final String s = replacePercent(value.toString());    
> text = URLDecoder.decode(s, CHARSET);
> }{code}
>  
> {color:#00}best regards{color}
> {color:#00}Dirk{color}



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


[jira] [Created] (CAMEL-21198) Create an IBM Secrets Manager component

2024-09-11 Thread Andrea Cosentino (Jira)
Andrea Cosentino created CAMEL-21198:


 Summary: Create an IBM Secrets Manager component
 Key: CAMEL-21198
 URL: https://issues.apache.org/jira/browse/CAMEL-21198
 Project: Camel
  Issue Type: New Feature
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
 Fix For: 4.x


https://github.com/IBM/secrets-manager-java-sdk



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


[jira] [Commented] (CAMEL-21197) URISupport.parseQuery is not decoding correctly

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen commented on CAMEL-21197:
-

What are you trying to do for real

> URISupport.parseQuery is not decoding correctly
> ---
>
> Key: CAMEL-21197
> URL: https://issues.apache.org/jira/browse/CAMEL-21197
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 4.7.0
>Reporter: Dirk Fiedler
>Priority: Minor
>
> {color:#00}Hi team,{color}
> {color:#00}while using *URISupport.parseQuery* the given query was not 
> correctly decoded:{color}
> *{color:#00}Sample JUnit test 
> (org.apache.camel.util.URISupportTest):{color}*
>  
> {code:java}
> @Test
> public void testParseQueryDFi() throws Exception {
>     Map map = 
> URISupport.parseQuery("Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete");
>     assertEquals(1, map.size());
>     assertEquals("direct://saga1_sagaService_complete", 
> map.get("Camel-Saga-Complete"));
> } {code}
> {color:#00}If i handover the query 
> 'Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete' 
> i expect the decoded value {color}{color:#00}for 'Camel-Saga-Complete' as 
> 'direct://saga1_sagaService_complete'.{color}
> {color:#00}I am wrong? Did i understand the utility class wrong?{color}
> {color:#00}Within the code i can see, that the string was adjusted to 
> replace '%', this is {color}
> {color:#00}causing the issue:{color}
> *{color:#00}URIScanner.addParameter:{color}*
>  
> {code:java}
> if (isRaw) {
>     text = value.toString();
> } else {
>     // need to replace % with %25 to avoid losing "%" when decoding
>     final String s = replacePercent(value.toString());    
> text = URLDecoder.decode(s, CHARSET);
> }{code}
>  
> {color:#00}best regards{color}
> {color:#00}Dirk{color}



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


[jira] [Updated] (CAMEL-21197) URISupport.parseQuery is not decoding correctly

2024-09-11 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21197:

Priority: Minor  (was: Major)

> URISupport.parseQuery is not decoding correctly
> ---
>
> Key: CAMEL-21197
> URL: https://issues.apache.org/jira/browse/CAMEL-21197
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 4.7.0
>Reporter: Dirk Fiedler
>Priority: Minor
>
> {color:#00}Hi team,{color}
> {color:#00}while using *URISupport.parseQuery* the given query was not 
> correctly decoded:{color}
> *{color:#00}Sample JUnit test 
> (org.apache.camel.util.URISupportTest):{color}*
>  
> {code:java}
> @Test
> public void testParseQueryDFi() throws Exception {
>     Map map = 
> URISupport.parseQuery("Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete");
>     assertEquals(1, map.size());
>     assertEquals("direct://saga1_sagaService_complete", 
> map.get("Camel-Saga-Complete"));
> } {code}
> {color:#00}If i handover the query 
> 'Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete' 
> i expect the decoded value {color}{color:#00}for 'Camel-Saga-Complete' as 
> 'direct://saga1_sagaService_complete'.{color}
> {color:#00}I am wrong? Did i understand the utility class wrong?{color}
> {color:#00}Within the code i can see, that the string was adjusted to 
> replace '%', this is {color}
> {color:#00}causing the issue:{color}
> *{color:#00}URIScanner.addParameter:{color}*
>  
> {code:java}
> if (isRaw) {
>     text = value.toString();
> } else {
>     // need to replace % with %25 to avoid losing "%" when decoding
>     final String s = replacePercent(value.toString());    
> text = URLDecoder.decode(s, CHARSET);
> }{code}
>  
> {color:#00}best regards{color}
> {color:#00}Dirk{color}



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


[jira] [Resolved] (CAMEL-21186) AWS Secrets Manager: Support Batch Retrieval for Secrets

2024-09-11 Thread Andrea Cosentino (Jira)


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

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

> AWS Secrets Manager: Support Batch Retrieval for Secrets
> 
>
> Key: CAMEL-21186
> URL: https://issues.apache.org/jira/browse/CAMEL-21186
> Project: Camel
>  Issue Type: New Feature
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 4.9.0
>
>
> https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_BatchGetSecretValue.html
> This will help on the cost side.



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


[jira] [Created] (CAMEL-21197) URISupport.parseQuery is not decoding correctly

2024-09-11 Thread Dirk Fiedler (Jira)
Dirk Fiedler created CAMEL-21197:


 Summary: URISupport.parseQuery is not decoding correctly
 Key: CAMEL-21197
 URL: https://issues.apache.org/jira/browse/CAMEL-21197
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 4.7.0
Reporter: Dirk Fiedler


{color:#00}Hi team,{color}

{color:#00}while using *URISupport.parseQuery* the given query was not 
correctly decoded:{color}

*{color:#00}Sample JUnit test 
(org.apache.camel.util.URISupportTest):{color}*
 
{code:java}
@Test
public void testParseQueryDFi() throws Exception {
    Map map = 
URISupport.parseQuery("Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete");
    assertEquals(1, map.size());
    assertEquals("direct://saga1_sagaService_complete", 
map.get("Camel-Saga-Complete"));
} {code}
{color:#00}If i handover the query 
'Camel-Saga-Complete=direct%3A%2F%2Fsaga1_sagaService_complete' 
i expect the decoded value {color}{color:#00}for 'Camel-Saga-Complete' as 
'direct://saga1_sagaService_complete'.{color}

{color:#00}I am wrong? Did i understand the utility class wrong?{color}

{color:#00}Within the code i can see, that the string was adjusted to 
replace '%', this is {color}
{color:#00}causing the issue:{color}

*{color:#00}URIScanner.addParameter:{color}*

 
{code:java}
if (isRaw) {
    text = value.toString();
} else {
    // need to replace % with %25 to avoid losing "%" when decoding
    final String s = replacePercent(value.toString());    
text = URLDecoder.decode(s, CHARSET);
}{code}
 

{color:#00}best regards{color}
{color:#00}Dirk{color}



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


[jira] [Created] (CAMEL-21196) camel-core: modernize throws/no throws assertions

2024-09-11 Thread Otavio Rodolfo Piske (Jira)
Otavio Rodolfo Piske created CAMEL-21196:


 Summary: camel-core: modernize throws/no throws assertions
 Key: CAMEL-21196
 URL: https://issues.apache.org/jira/browse/CAMEL-21196
 Project: Camel
  Issue Type: Test
Affects Versions: 4.8.0
Reporter: Otavio Rodolfo Piske
Assignee: Nikita_Konovalov
 Fix For: 4.x


Code like the one below should be modified to use modern JUnit 5 assertions:


{code:java}
try {
DefaultFluentProducerTemplate.on(context).withBody("Hello 
World").to("direct:exception").request();
fail("Should have thrown RuntimeCamelException");
} catch (RuntimeCamelException e) {
boolean b = e.getCause() instanceof IllegalArgumentException;
assertTrue(b);
assertEquals("Forced exception by unit test", 
e.getCause().getMessage());
}
{code}



This should be replaced with {{Assertions.assertDoesNotThrow}} and 
{{Assertions.assertThrows}} as needed.



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


[jira] [Resolved] (CAMEL-19742) Create a new base test class

2024-09-11 Thread Otavio Rodolfo Piske (Jira)


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

Otavio Rodolfo Piske resolved CAMEL-19742.
--
Resolution: Abandoned

Due to recent changes in testing APIs, we are abandoning this. We will revisit 
it in the future. 

> Create a new base test class
> 
>
> Key: CAMEL-19742
> URL: https://issues.apache.org/jira/browse/CAMEL-19742
> Project: Camel
>  Issue Type: Task
>Reporter: Otavio Rodolfo Piske
>Assignee: Nikita_Konovalov
>Priority: Major
>
> If we want to be able to convert the Camel tests to use the 
> camel-test-infra-core and, if we expect that at some point in the future, 
> users would want to use that as well ... we should make the process *as easy 
> as possible*.
> Currently, converting the code is not complex, however is does require a few 
> steps to 
> [convert|https://github.com/apache/camel/tree/camel-4.0.0/test-infra/camel-test-infra-core].
>  This can be discouraging to contributors willing to help convert the code as 
> well to users (in the medium). 
> As such, we should provide supporting classes that facilitate the work of 
> converting the code. Ideally we should aim to make this effort as easy as a 
> drop in replacement. To achieve that, one class that *must* be provided is a 
> new version of the 
> [CamelTestSupport|https://github.com/apache/camel/blob/camel-4.0.0/components/camel-test/camel-test-junit5/src/main/java/org/apache/camel/test/junit5/CamelTestSupport.java]
>  that is based on the camel-test-infra-core and provide the same facilities 
> (methods, protected member variables and other API related items). 



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


[jira] [Resolved] (CAMEL-19538) camel-mllp: replace Thread.sleep in tests

2024-09-11 Thread Otavio Rodolfo Piske (Jira)


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

Otavio Rodolfo Piske resolved CAMEL-19538.
--
Fix Version/s: 4.9.0
   Resolution: Fixed

Resolved with the linked PR.

> camel-mllp: replace Thread.sleep in tests
> -
>
> Key: CAMEL-19538
> URL: https://issues.apache.org/jira/browse/CAMEL-19538
> Project: Camel
>  Issue Type: Task
>  Components: camel-mllp, tests
>Affects Versions: 4.0.0
>Reporter: Otavio Rodolfo Piske
>Assignee: Nikita_Konovalov
>Priority: Minor
>  Labels: easy, help-wanted
> Fix For: 4.9.0
>
>
> We have many tests which use Thread.sleep for synchronization. This is bug 
> prone and can introduce flakiness when running on environments with different 
> capacities.
> Ideally we should replace these with:
>  * [Awaitility|http://www.awaitility.org/]
>  * Java's native syncronization mechanism (Latches, Phasers, Locks, etc)
>  * Nothing (i.e.; in some cases the sleep can simply be removed)
>  
>  



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


[jira] [Created] (CAMEL-21195) tests: resolve flaky tests

2024-09-11 Thread Otavio Rodolfo Piske (Jira)
Otavio Rodolfo Piske created CAMEL-21195:


 Summary: tests: resolve flaky tests
 Key: CAMEL-21195
 URL: https://issues.apache.org/jira/browse/CAMEL-21195
 Project: Camel
  Issue Type: Test
  Components: camel-core
Affects Versions: 4.8.0
Reporter: Otavio Rodolfo Piske
Assignee: Nikita_Konovalov
 Fix For: 4.9.0


Fix flaky tests for Camel 4.9. 

Some flakies: 
https://ge.apache.org/scans/tests?search.rootProjectNames=Camel&search.tasks=verify&search.timeZoneId=Europe%2FParis



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


[jira] [Updated] (CAMEL-20468) Camel-AWS-Bedrock: Support available models

2024-09-10 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino updated CAMEL-20468:
-
Fix Version/s: 4.8.0
   (was: 4.x)

> Camel-AWS-Bedrock: Support available models
> ---
>
> Key: CAMEL-20468
> URL: https://issues.apache.org/jira/browse/CAMEL-20468
> Project: Camel
>  Issue Type: New Feature
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 4.8.0
>
>




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


[jira] [Resolved] (CAMEL-20468) Camel-AWS-Bedrock: Support available models

2024-09-10 Thread Andrea Cosentino (Jira)


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

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

> Camel-AWS-Bedrock: Support available models
> ---
>
> Key: CAMEL-20468
> URL: https://issues.apache.org/jira/browse/CAMEL-20468
> Project: Camel
>  Issue Type: New Feature
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 4.8.0
>
>




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


[jira] [Resolved] (CAMEL-21179) Secret Properties Functions: Supporting secret name containing "/"

2024-09-10 Thread Andrea Cosentino (Jira)


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

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

> Secret Properties Functions: Supporting secret name containing "/"
> --
>
> Key: CAMEL-21179
> URL: https://issues.apache.org/jira/browse/CAMEL-21179
> Project: Camel
>  Issue Type: New Feature
> Environment: 
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 4.9.0
>
>
> There was a question about Hashicorp Vault support in Camel-Karavan
> https://github.com/apache/camel-karavan/issues/1348
> As of today, this is not feasible, mainly because the "/" symbol is used to 
> distinguish between the secret name and the subkey you want to resolve.
> To complete this issue we might need to review the syntax, so something like 
> this should be done
> {code:java}
> {{hashicorp:secrets_engine:secret_name/with_slash#subkey:default_value@version}}
> {code}
> This could extended to the other functions, but since it is a breaking change 
> it won't go in 4.8.0 and it will need to be documented in the migration guide.
> Essentially we'll need to introduce a different symbol for prefixing the 
> subkey.



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


[jira] [Updated] (CAMEL-21191) camel-catalog - Beans for aggregation repository are wrongly declared as aggregation strategy

2024-09-10 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21191:

Fix Version/s: 4.8.0
   (was: 4.9.0)
   (was: 4.8.1)

> camel-catalog - Beans for aggregation repository are wrongly declared as 
> aggregation strategy
> -
>
> Key: CAMEL-21191
> URL: https://issues.apache.org/jira/browse/CAMEL-21191
> Project: Camel
>  Issue Type: Bug
>  Components: camel-catalog
>Affects Versions: 4.8.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.8.0
>
>




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


[jira] (CAMEL-21191) camel-catalog - Beans for aggregation repository are wrongly declared as aggregation strategy

2024-09-10 Thread Claus Ibsen (Jira)


[ https://issues.apache.org/jira/browse/CAMEL-21191 ]


Claus Ibsen deleted comment on CAMEL-21191:
-

was (Author: davsclaus):
TODO: backport to 4.8.x branch

> camel-catalog - Beans for aggregation repository are wrongly declared as 
> aggregation strategy
> -
>
> Key: CAMEL-21191
> URL: https://issues.apache.org/jira/browse/CAMEL-21191
> Project: Camel
>  Issue Type: Bug
>  Components: camel-catalog
>Affects Versions: 4.8.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.8.0
>
>




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


[jira] [Updated] (CAMEL-21194) camel-jbang - Cannot run xxx.camel.yaml files

2024-09-10 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21194:

Affects Version/s: 4.8.0

> camel-jbang - Cannot run xxx.camel.yaml files
> -
>
> Key: CAMEL-21194
> URL: https://issues.apache.org/jira/browse/CAMEL-21194
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jbang
>Affects Versions: 4.8.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 4.8.0
>
>
> The camel run unfortuantely has a bug that causes it to not detect file 
> extensions correctly for yaml kamelets and routes, and will fail.
>  
> For example this example
> [https://github.com/apache/camel-kamelets-examples/tree/main/jbang/hello-yaml]
> camel run *
> or 
> camel run hello.camel.yaml
> All causes failure
> org.apache.camel.RuntimeCamelException: Failed to resolve source file: 
> hello.camel.yaml
>     at 
> org.apache.camel.dsl.jbang.core.common.SourceHelper.resolveSource(SourceHelper.java:46)
>     at org.apache.camel.dsl.jbang.core.commands.Run.knownFile(Run.java:1544)
>     at org.apache.camel.dsl.jbang.core.commands.Run.run(Run.java:645)
>     at org.apache.camel.dsl.jbang.core.commands.Run.doCall(Run.java:310)
>     at 
> org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:71)
>     at 
> org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:37)
>     at picocli.CommandLine.executeUserObject(CommandLine.java:2045)
>     at picocli.CommandLine.access$1500(CommandLine.java:148)
>     at 
> picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2465)
>     at picocli.CommandLine$RunLast.handle(CommandLine.java:2457)
>     at picocli.CommandLine$RunLast.handle(CommandLine.java:2419)
>     at 
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2277)
>     at picocli.CommandLine$RunLast.execute(CommandLine.java:2421)
>     at picocli.CommandLine.execute(CommandLine.java:2174)
>     at 
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:173)
>     at 
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:62)
>     at main.CamelJBang.main(CamelJBang.java:36)



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


[jira] [Resolved] (CAMEL-21194) camel-jbang - Cannot run xxx.camel.yaml files

2024-09-10 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-21194.
-
Resolution: Fixed

> camel-jbang - Cannot run xxx.camel.yaml files
> -
>
> Key: CAMEL-21194
> URL: https://issues.apache.org/jira/browse/CAMEL-21194
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jbang
>Affects Versions: 4.8.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 4.8.0
>
>
> The camel run unfortuantely has a bug that causes it to not detect file 
> extensions correctly for yaml kamelets and routes, and will fail.
>  
> For example this example
> [https://github.com/apache/camel-kamelets-examples/tree/main/jbang/hello-yaml]
> camel run *
> or 
> camel run hello.camel.yaml
> All causes failure
> org.apache.camel.RuntimeCamelException: Failed to resolve source file: 
> hello.camel.yaml
>     at 
> org.apache.camel.dsl.jbang.core.common.SourceHelper.resolveSource(SourceHelper.java:46)
>     at org.apache.camel.dsl.jbang.core.commands.Run.knownFile(Run.java:1544)
>     at org.apache.camel.dsl.jbang.core.commands.Run.run(Run.java:645)
>     at org.apache.camel.dsl.jbang.core.commands.Run.doCall(Run.java:310)
>     at 
> org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:71)
>     at 
> org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:37)
>     at picocli.CommandLine.executeUserObject(CommandLine.java:2045)
>     at picocli.CommandLine.access$1500(CommandLine.java:148)
>     at 
> picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2465)
>     at picocli.CommandLine$RunLast.handle(CommandLine.java:2457)
>     at picocli.CommandLine$RunLast.handle(CommandLine.java:2419)
>     at 
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2277)
>     at picocli.CommandLine$RunLast.execute(CommandLine.java:2421)
>     at picocli.CommandLine.execute(CommandLine.java:2174)
>     at 
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:173)
>     at 
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:62)
>     at main.CamelJBang.main(CamelJBang.java:36)



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


[jira] [Resolved] (CAMEL-21191) camel-catalog - Beans for aggregation repository are wrongly declared as aggregation strategy

2024-09-10 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-21191.
-
Resolution: Fixed

> camel-catalog - Beans for aggregation repository are wrongly declared as 
> aggregation strategy
> -
>
> Key: CAMEL-21191
> URL: https://issues.apache.org/jira/browse/CAMEL-21191
> Project: Camel
>  Issue Type: Bug
>  Components: camel-catalog
>Affects Versions: 4.8.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.8.0
>
>




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


[jira] [Comment Edited] (CAMEL-21179) Secret Properties Functions: Supporting secret name containing "/"

2024-09-10 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino edited comment on CAMEL-21179 at 9/10/24 2:10 PM:
---

Hashicorp Vault - Done.
AWS Secrets Manager - Done.
Google Secret Manager - Done, but just to harmonize the syntax, since GCP 
Secret Manager doesn't allow to use / in the secret name.
Azure Key Vault -  Done, but just to harmonize the syntax, since Azure Key 
Vault doesn't allow to use / in the secret name.


was (Author: ancosen):
Hashicorp Vault - Done.
AWS Secrets Manager - Done.
Google Secret Manager - Done, but just to harmonize the syntax, since GCP 
Secret Manager doesn't allow to use / in the secret name.

> Secret Properties Functions: Supporting secret name containing "/"
> --
>
> Key: CAMEL-21179
> URL: https://issues.apache.org/jira/browse/CAMEL-21179
> Project: Camel
>  Issue Type: New Feature
> Environment: 
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 4.9.0
>
>
> There was a question about Hashicorp Vault support in Camel-Karavan
> https://github.com/apache/camel-karavan/issues/1348
> As of today, this is not feasible, mainly because the "/" symbol is used to 
> distinguish between the secret name and the subkey you want to resolve.
> To complete this issue we might need to review the syntax, so something like 
> this should be done
> {code:java}
> {{hashicorp:secrets_engine:secret_name/with_slash#subkey:default_value@version}}
> {code}
> This could extended to the other functions, but since it is a breaking change 
> it won't go in 4.8.0 and it will need to be documented in the migration guide.
> Essentially we'll need to introduce a different symbol for prefixing the 
> subkey.



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


[jira] [Commented] (CAMEL-20888) Remove Kotlin DSL

2024-09-10 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on CAMEL-20888:


apupier merged PR #1225:
URL: https://github.com/apache/camel-website/pull/1225




> Remove Kotlin DSL
> -
>
> Key: CAMEL-20888
> URL: https://issues.apache.org/jira/browse/CAMEL-20888
> Project: Camel
>  Issue Type: Task
>  Components: camel-kotlin
>Affects Versions: 4.7.0
>Reporter: Aurélien Pupier
>Assignee: Aurélien Pupier
>Priority: Major
> Fix For: 4.9.0
>
>
> Kotlin DSL was deprecated in 4.7.0



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


[jira] [Commented] (CAMEL-20888) Remove Kotlin DSL

2024-09-10 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on CAMEL-20888:


github-actions[bot] commented on PR #1225:
URL: https://github.com/apache/camel-website/pull/1225#issuecomment-2340931841

   🚀 Preview is available at https://pr-1225--camel.netlify.app




> Remove Kotlin DSL
> -
>
> Key: CAMEL-20888
> URL: https://issues.apache.org/jira/browse/CAMEL-20888
> Project: Camel
>  Issue Type: Task
>  Components: camel-kotlin
>Affects Versions: 4.7.0
>Reporter: Aurélien Pupier
>Assignee: Aurélien Pupier
>Priority: Major
> Fix For: 4.9.0
>
>
> Kotlin DSL was deprecated in 4.7.0



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


[jira] [Comment Edited] (CAMEL-21179) Secret Properties Functions: Supporting secret name containing "/"

2024-09-10 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino edited comment on CAMEL-21179 at 9/10/24 12:44 PM:


Hashicorp Vault - Done.
AWS Secrets Manager - Done.
Google Secret Manager - Done, but just to harmonize the syntax, since GCP 
Secret Manager doesn't allow to use / in the secret name.


was (Author: ancosen):
Hashicorp Vault - Done.
AWS Secrets Manager - Done.

> Secret Properties Functions: Supporting secret name containing "/"
> --
>
> Key: CAMEL-21179
>     URL: https://issues.apache.org/jira/browse/CAMEL-21179
> Project: Camel
>  Issue Type: New Feature
> Environment: 
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 4.9.0
>
>
> There was a question about Hashicorp Vault support in Camel-Karavan
> https://github.com/apache/camel-karavan/issues/1348
> As of today, this is not feasible, mainly because the "/" symbol is used to 
> distinguish between the secret name and the subkey you want to resolve.
> To complete this issue we might need to review the syntax, so something like 
> this should be done
> {code:java}
> {{hashicorp:secrets_engine:secret_name/with_slash#subkey:default_value@version}}
> {code}
> This could extended to the other functions, but since it is a breaking change 
> it won't go in 4.8.0 and it will need to be documented in the migration guide.
> Essentially we'll need to introduce a different symbol for prefixing the 
> subkey.



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


[jira] [Commented] (CAMEL-20888) Remove Kotlin DSL

2024-09-10 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on CAMEL-20888:


apupier opened a new pull request, #1225:
URL: https://github.com/apache/camel-website/pull/1225

   (no comment)




> Remove Kotlin DSL
> -
>
> Key: CAMEL-20888
> URL: https://issues.apache.org/jira/browse/CAMEL-20888
> Project: Camel
>  Issue Type: Task
>  Components: camel-kotlin
>Affects Versions: 4.7.0
>Reporter: Aurélien Pupier
>Assignee: Aurélien Pupier
>Priority: Major
> Fix For: 4.9.0
>
>
> Kotlin DSL was deprecated in 4.7.0



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


[jira] [Created] (CAMEL-21193) camel-jbang - Add receive command

2024-09-10 Thread Claus Ibsen (Jira)
Claus Ibsen created CAMEL-21193:
---

 Summary: camel-jbang - Add receive command
 Key: CAMEL-21193
 URL: https://issues.apache.org/jira/browse/CAMEL-21193
 Project: Camel
  Issue Type: New Feature
  Components: camel-jbang
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 4.9.0


You can send via `camel cmd send` but we need a `camel cmd receive` so you can 
just listen to new messages from a system such as kafka, jms, sql, file etc.

 



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


[jira] [Updated] (CAMEL-21184) Make more components Browseable

2024-09-10 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21184:

Fix Version/s: 4.9.0
   (was: 4.x)

> Make more components Browseable
> ---
>
> Key: CAMEL-21184
> URL: https://issues.apache.org/jira/browse/CAMEL-21184
> Project: Camel
>  Issue Type: Improvement
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.9.0
>
>
> Lets see if we can make more components support BrowseableEndpoint



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


[jira] [Created] (CAMEL-21191) camel-catalog - Beans for aggregation repository are wrongly declared as aggregation strategy

2024-09-10 Thread Claus Ibsen (Jira)
Claus Ibsen created CAMEL-21191:
---

 Summary: camel-catalog - Beans for aggregation repository are 
wrongly declared as aggregation strategy
 Key: CAMEL-21191
 URL: https://issues.apache.org/jira/browse/CAMEL-21191
 Project: Camel
  Issue Type: Bug
  Components: camel-catalog
Affects Versions: 4.8.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 4.8.1






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


[jira] [Resolved] (CAMEL-21189) camel-jms: Add idleReceivesPerTaskLimit

2024-09-09 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-21189.
-
Resolution: Fixed

> camel-jms: Add idleReceivesPerTaskLimit
> ---
>
> Key: CAMEL-21189
> URL: https://issues.apache.org/jira/browse/CAMEL-21189
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jms
>Reporter: Pascal Schumacher
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.9.0
>
>
> Spring 5.3.5 added DefaultMessageListenerContainer#idleReceivesPerTaskLimit 
> in https://github.com/spring-projects/spring-framework/issues/26195 as a 
> better way than DefaultMessageListenerContainer#maxMessagesPerTask to control 
> the number of dynamic concurrent consumers. It would be great to have this be 
> supported by camel-jms.



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


[jira] [Resolved] (CAMEL-21188) No EndpointBuilder for camel-activemq6

2024-09-09 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-21188.
-
Resolution: Fixed

> No EndpointBuilder for camel-activemq6
> --
>
> Key: CAMEL-21188
> URL: https://issues.apache.org/jira/browse/CAMEL-21188
> Project: Camel
>  Issue Type: Bug
>  Components: camel-endpointdsl
>Affects Versions: 4.7.0
>Reporter: Pascal Schumacher
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.9.0
>
>
> For Camel 4.7.0 camel-activemq was reverted to Active MQ 5.x and 
> camel-activemq6 was created for Active MQ 6.x, but there is no 
> EndpointBuilder for camel-activemq6, so the Java DSL can not be used to 
> configure endpoints for this component.



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


[jira] [Assigned] (CAMEL-21188) No EndpointBuilder for camel-activemq6

2024-09-09 Thread Claus Ibsen (Jira)


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

Claus Ibsen reassigned CAMEL-21188:
---

Assignee: Claus Ibsen

> No EndpointBuilder for camel-activemq6
> --
>
> Key: CAMEL-21188
> URL: https://issues.apache.org/jira/browse/CAMEL-21188
> Project: Camel
>  Issue Type: Bug
>  Components: camel-endpointdsl
>Affects Versions: 4.7.0
>Reporter: Pascal Schumacher
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.9.0
>
>
> For Camel 4.7.0 camel-activemq was reverted to Active MQ 5.x and 
> camel-activemq6 was created for Active MQ 6.x, but there is no 
> EndpointBuilder for camel-activemq6, so the Java DSL can not be used to 
> configure endpoints for this component.



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


[jira] [Resolved] (CAMEL-21183) camel-core - BrowseEndpoint should have limit parameter

2024-09-09 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-21183.
-
Resolution: Fixed

> camel-core - BrowseEndpoint should have limit parameter
> ---
>
> Key: CAMEL-21183
> URL: https://issues.apache.org/jira/browse/CAMEL-21183
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.9.0
>
>
> The method currently
>  
> List getExchanges();
>  
> Should have a limit and filter predicate so you can filter first
>  



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


[jira] [Assigned] (CAMEL-20888) Remove Kotlin DSL

2024-09-09 Thread Jira


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

Aurélien Pupier reassigned CAMEL-20888:
---

Assignee: Aurélien Pupier

> Remove Kotlin DSL
> -
>
> Key: CAMEL-20888
> URL: https://issues.apache.org/jira/browse/CAMEL-20888
> Project: Camel
>  Issue Type: Task
>  Components: camel-kotlin
>Affects Versions: 4.7.0
>Reporter: Aurélien Pupier
>Assignee: Aurélien Pupier
>Priority: Major
> Fix For: 4.9.0
>
>
> Kotlin DSL was deprecated in 4.7.0



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


[jira] [Updated] (CAMEL-21188) No EndpointBuilder for camel-activemq6

2024-09-08 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21188:

Fix Version/s: 4.9.0

> No EndpointBuilder for camel-activemq6
> --
>
> Key: CAMEL-21188
> URL: https://issues.apache.org/jira/browse/CAMEL-21188
> Project: Camel
>  Issue Type: Bug
>  Components: camel-endpointdsl
>Affects Versions: 4.7.0
>Reporter: Pascal Schumacher
>Priority: Minor
> Fix For: 4.9.0
>
>
> For Camel 4.7.0 camel-activemq was reverted to Active MQ 5.x and 
> camel-activemq6 was created for Active MQ 6.x, but there is no 
> EndpointBuilder for camel-activemq6, so the Java DSL can not be used to 
> configure endpoints for this component.



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


[jira] [Comment Edited] (CAMEL-21183) camel-core - BrowseEndpoint should have limit parameter

2024-09-08 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-21183 at 9/9/24 5:11 AM:
-

TODO: BrowsableEndpoint to have getter/setter for limit (default 100) so we do 
not capture too much data OOTB - But users can see the latest 100 messages 
*DONE*

TODO: MBean to have dump as json *DONE*

TODO: catalog to have browseable: true|false


was (Author: davsclaus):
TODO: BrowsableEndpoint to have getter/setter for limit (default 100) so we do 
not capture too much data OOTB - But users can see the latest 100 messages

TODO: MBean to have dump as json

TODO: catalog to have browseable: true|false

> camel-core - BrowseEndpoint should have limit parameter
> ---
>
> Key: CAMEL-21183
> URL: https://issues.apache.org/jira/browse/CAMEL-21183
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.9.0
>
>
> The method currently
>  
> List getExchanges();
>  
> Should have a limit and filter predicate so you can filter first
>  



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


[jira] [Created] (CAMEL-21189) camel-jms: Add idleReceivesPerTaskLimit

2024-09-08 Thread Pascal Schumacher (Jira)
Pascal Schumacher created CAMEL-21189:
-

 Summary: camel-jms: Add idleReceivesPerTaskLimit
 Key: CAMEL-21189
 URL: https://issues.apache.org/jira/browse/CAMEL-21189
 Project: Camel
  Issue Type: Improvement
  Components: camel-jms
Reporter: Pascal Schumacher


Spring 5.3.5 added DefaultMessageListenerContainer#idleReceivesPerTaskLimit in 
https://github.com/spring-projects/spring-framework/issues/26195 as a better 
way than DefaultMessageListenerContainer#maxMessagesPerTask to control the 
number of dynamic concurrent consumers. It would be great to have this be 
supported by camel-jms.



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


[jira] [Created] (CAMEL-21188) No EndpointBuilder for camel-activemq6

2024-09-08 Thread Pascal Schumacher (Jira)
Pascal Schumacher created CAMEL-21188:
-

 Summary: No EndpointBuilder for camel-activemq6
 Key: CAMEL-21188
 URL: https://issues.apache.org/jira/browse/CAMEL-21188
 Project: Camel
  Issue Type: Bug
  Components: camel-endpointdsl
Affects Versions: 4.7.0
Reporter: Pascal Schumacher


For Camel 4.7.0 camel-activemq was reverted to Active MQ 5.x and 
camel-activemq6 was created for Active MQ 6.x, but there is no EndpointBuilder 
for camel-activemq6, so the Java DSL can not be used to configure endpoints for 
this component.



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


[jira] [Assigned] (CAMEL-21184) Make more components Browseable

2024-09-08 Thread Claus Ibsen (Jira)


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

Claus Ibsen reassigned CAMEL-21184:
---

Assignee: Claus Ibsen

> Make more components Browseable
> ---
>
> Key: CAMEL-21184
> URL: https://issues.apache.org/jira/browse/CAMEL-21184
> Project: Camel
>  Issue Type: Improvement
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.x
>
>
> Lets see if we can make more components support BrowseableEndpoint



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


[jira] [Comment Edited] (CAMEL-21183) camel-core - BrowseEndpoint should have limit parameter

2024-09-07 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-21183 at 9/7/24 5:21 PM:
-

TODO: BrowsableEndpoint to have getter/setter for limit (default 100) so we do 
not capture too much data OOTB - But users can see the latest 100 messages

TODO: MBean to have dump as json


was (Author: davsclaus):
TODO: BrowsableEndpoint to have getter/setter for limit (default 100) so we do 
not capture too much data OOTB - But users can see the latest 100 messages

> camel-core - BrowseEndpoint should have limit parameter
> ---
>
> Key: CAMEL-21183
> URL: https://issues.apache.org/jira/browse/CAMEL-21183
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.9.0
>
>
> The method currently
>  
> List getExchanges();
>  
> Should have a limit and filter predicate so you can filter first
>  



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


[jira] [Comment Edited] (CAMEL-21185) DefaultShutdownStrategy cannot set timeout via JMX

2024-09-06 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-21185 at 9/7/24 6:34 AM:
-

The timeout can also be set in the camel context mbean


was (Author: davsclaus):
The timeout is on camel context mbean

> DefaultShutdownStrategy cannot set timeout via JMX
> --
>
> Key: CAMEL-21185
> URL: https://issues.apache.org/jira/browse/CAMEL-21185
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Mark Wimpory
>Assignee: Claus Ibsen
>Priority: Minor
> Attachments: image-2024-09-06-09-07-11-268.png
>
>
> The docs state that the shutdown timeout can be set via JMX.  However I 
> cannot find this setting on the bean.  I will attach a screenshot
> !image-2024-09-06-09-07-11-268.png!



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


[jira] [Assigned] (CAMEL-21185) DefaultShutdownStrategy cannot set timeout via JMX

2024-09-06 Thread Claus Ibsen (Jira)


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

Claus Ibsen reassigned CAMEL-21185:
---

Assignee: Claus Ibsen

> DefaultShutdownStrategy cannot set timeout via JMX
> --
>
> Key: CAMEL-21185
> URL: https://issues.apache.org/jira/browse/CAMEL-21185
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Mark Wimpory
>Assignee: Claus Ibsen
>Priority: Minor
> Attachments: image-2024-09-06-09-07-11-268.png
>
>
> The docs state that the shutdown timeout can be set via JMX.  However I 
> cannot find this setting on the bean.  I will attach a screenshot
> !image-2024-09-06-09-07-11-268.png!



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


[jira] [Updated] (CAMEL-21186) AWS Secrets Manager: Support Batch Retrieval for Secrets

2024-09-06 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino updated CAMEL-21186:
-
Priority: Minor  (was: Major)

> AWS Secrets Manager: Support Batch Retrieval for Secrets
> 
>
> Key: CAMEL-21186
> URL: https://issues.apache.org/jira/browse/CAMEL-21186
> Project: Camel
>  Issue Type: New Feature
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 4.9.0
>
>
> https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_BatchGetSecretValue.html
> This will help on the cost side.



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


[jira] [Created] (CAMEL-21186) AWS Secrets Manager: Support Batch Retrieval for Secrets

2024-09-06 Thread Andrea Cosentino (Jira)
Andrea Cosentino created CAMEL-21186:


 Summary: AWS Secrets Manager: Support Batch Retrieval for Secrets
 Key: CAMEL-21186
 URL: https://issues.apache.org/jira/browse/CAMEL-21186
 Project: Camel
  Issue Type: New Feature
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
 Fix For: 4.9.0


https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_BatchGetSecretValue.html

This will help on the cost side.



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


[jira] [Commented] (CAMEL-20593) camel-kafka - Use official ASF docker images instead of confluent

2024-09-06 Thread Jira


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

Aurélien Pupier commented on CAMEL-20593:
-

I started to look at it.

I removed Kafka 2 as it is end of life: 
https://github.com/apache/camel/pull/15470

I started to do the migration for kafka 3 with this branch (based on the one 
removing kafka 2):
https://github.com/apupier/camel/pull/new/20593-useApacheKafkaContainerImageForTest

Currently all Idempotent tests are failing with:
{noformat}
org.apache.camel.FailedToStartRouteException: Failed to start route
route1 because of java.lang.IllegalArgumentException: Target offsets
must be non-empty
at 
org.apache.camel.impl.engine.RouteService.warmUp(RouteService.java:125)
{noformat}

i tried with 3.7.1 and 3.8.0

> camel-kafka - Use official ASF docker images instead of confluent
> -
>
> Key: CAMEL-20593
> URL: https://issues.apache.org/jira/browse/CAMEL-20593
> Project: Camel
>  Issue Type: Dependency upgrade
>  Components: camel-kafka
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 4.x
>
>
> There are ASF images now we should favour using
> https://hub.docker.com/r/apache/kafka/tags



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


[jira] [Resolved] (CAMEL-21039) Align quarkus generated k8s resources with other runtimes

2024-09-06 Thread Thomas Diesler (Jira)


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

Thomas Diesler resolved CAMEL-21039.

Resolution: Won't Fix

We decided to not use JKube for runtime quarkus

> Align quarkus generated k8s resources with other runtimes
> -
>
> Key: CAMEL-21039
> URL: https://issues.apache.org/jira/browse/CAMEL-21039
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
> Currently, we use different techniques for generating k8s resources depending 
> on {{--runtime}}. Although very similar, the result is not identical. Check, 
> whether it makes sense to use JKube for {{--runtime=quarkus}} too.



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


[jira] [Work stopped] (CAMEL-21039) Align quarkus generated k8s resources with other runtimes

2024-09-06 Thread Thomas Diesler (Jira)


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

Work on CAMEL-21039 stopped by Thomas Diesler.
--
> Align quarkus generated k8s resources with other runtimes
> -
>
> Key: CAMEL-21039
> URL: https://issues.apache.org/jira/browse/CAMEL-21039
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
> Currently, we use different techniques for generating k8s resources depending 
> on {{--runtime}}. Although very similar, the result is not identical. Check, 
> whether it makes sense to use JKube for {{--runtime=quarkus}} too.



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


[jira] [Updated] (CAMEL-18701) Reorganize components to avoid circular dependencies

2024-09-06 Thread Otavio Rodolfo Piske (Jira)


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

Otavio Rodolfo Piske updated CAMEL-18701:
-
Labels: help-wanted  (was: )

> Reorganize components to avoid circular dependencies
> 
>
> Key: CAMEL-18701
> URL: https://issues.apache.org/jira/browse/CAMEL-18701
> Project: Camel
>  Issue Type: Task
>  Components: camel-core, camel-file, camel-test
>Reporter: Otavio Rodolfo Piske
>Priority: Minor
>  Labels: help-wanted
> Fix For: Future
>
>
> Currently, the tests for core components are in the camel-core module (such 
> as those for file). Not only this causes confusion, as the tests are not 
> really in the component code, but also may lead to strange circular 
> dependencies. We should investigate reorganizing the project layout so that 
> the dependency tree is simpler and doesn't contain circular dependencies.



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


[jira] [Updated] (CAMEL-21063) Provide health endpoint for k8s export main

2024-09-06 Thread Thomas Diesler (Jira)


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

Thomas Diesler updated CAMEL-21063:
---
Summary: Provide health endpoint for k8s export main  (was: Provide a 
health endpoint for exported cloud projects)

> Provide health endpoint for k8s export main
> ---
>
> Key: CAMEL-21063
> URL: https://issues.apache.org/jira/browse/CAMEL-21063
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
> `camel export` used to provide a health endpoint for all runtimes (i.e. main, 
> quarkus, spring boot) - this is no longer the case for main.
> I suppose a health endpoint is useful in the context of cloud deployments and 
> should therefore always be generated through `camel kubernetes export`



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


[jira] [Updated] (CAMEL-21063) Provide a health endpoint for exported cloud projects

2024-09-06 Thread Thomas Diesler (Jira)


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

Thomas Diesler updated CAMEL-21063:
---
Summary: Provide a health endpoint for exported cloud projects  (was: 
Provide a heath endpoint for exported cloud projects)

> Provide a health endpoint for exported cloud projects
> -
>
> Key: CAMEL-21063
> URL: https://issues.apache.org/jira/browse/CAMEL-21063
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
> `camel export` used to provide a health endpoint for all runtimes (i.e. main, 
> quarkus, spring boot) - this is no longer the case for main.
> I suppose a health endpoint is useful in the context of cloud deployments and 
> should therefore always be generated through `camel kubernetes export`



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


[jira] [Updated] (CAMEL-21063) Provide a heath endpoint for exported cloud projects

2024-09-06 Thread Thomas Diesler (Jira)


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

Thomas Diesler updated CAMEL-21063:
---
Summary: Provide a heath endpoint for exported cloud projects  (was: 
Uniformly provide a heath endpoint for exported cloud projects)

> Provide a heath endpoint for exported cloud projects
> 
>
> Key: CAMEL-21063
> URL: https://issues.apache.org/jira/browse/CAMEL-21063
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
> `camel export` used to provide a health endpoint for all runtimes (i.e. main, 
> quarkus, spring boot) - this is no longer the case for main.
> I suppose a health endpoint is useful in the context of cloud deployments and 
> should therefore always be generated through `camel kubernetes export`



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


[jira] [Updated] (CAMEL-21181) camel-core: create a more elegant string generation API

2024-09-06 Thread Otavio Rodolfo Piske (Jira)


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

Otavio Rodolfo Piske updated CAMEL-21181:
-
Description: 
Currently our code has a very rudimentary way to generate String-based output 
(i.e.: such as those used for the DevConsole). 
Typically, we generate those strings appending code using a StringBuilder over 
multiple append calls, spawning several lines of code and, in many cases, 
generating transient objects in the process.
In some other (much worse) cases, we concatenate them. 

The code snippets below present some examples of the kind of thing we do. 

*JvmDevConsoleFile*: 


{code:java}
sb.append(String.format("Java Name: %s\n", mb.getVmName()));
{code}

...
{code:java}
String cp = String.join("\n", mb.getBootClassPath().split("[:|;]"));
sb.append("\n").append(cp).append("\n");
{code}

*DefaultAsyncProcessorAwaitManager*:

{code:java}sb.append(style("Id:")).append(entry.getBlockedThread().getId()).append("\n");
{code}

*BacklogTracer*:


{code:java}
private static String wrapAroundRootTag(List events) 
{
StringBuilder sb = new StringBuilder(512);
sb.append("<").append(BacklogTracerEventMessage.ROOT_TAG).append("s>");
for (BacklogTracerEventMessage event : events) {
sb.append("\n").append(event.toXml(2));
}

sb.append("\n");
return sb.toString();
}
{code}

This approach has several problems: 

1. Maintenance hell: this approach leads to code that is hard to read, modify 
and maintain. It is also usually hard to test due to tightly coupling the 
String generation with the data sources.
2. It leads to performance degradation if the underlying buffer is not properly 
sized. 
3. It can also lead to performance degradation due to increased GC pressure 
caused by an excessive creation of transient objects. 
4. Typically, the methods generating the objects are so large that they are not 
inlinable by JIT. 

-In particular, problem number 3 makes the whole set of *Console classes 
entirely unsuitable for high-performing / low-latency integrations. -

*Update*: I had originally singled out console code as a pain point, but 
looking further, there are other places that could lead to code like this in 
production (i.e.: the code in camel-management is also badly affected by this).

  was:
Currently our code has a very rudimentary way to generate String-based output 
(i.e.: such as those used for the DevConsole). 
Typically, we generate those strings appending code using a StringBuilder over 
multiple append calls, spawning several lines of code and, in many cases, 
generating transient objects in the process.
In some other (much worse) cases, we concatenate them. 

The code snippets below present some examples of the kind of thing we do. 

*JvmDevConsoleFile*: 


{code:java}
sb.append(String.format("Java Name: %s\n", mb.getVmName()));
{code}

...
{code:java}
String cp = String.join("\n", mb.getBootClassPath().split("[:|;]"));
sb.append("\n").append(cp).append("\n");
{code}

*DefaultAsyncProcessorAwaitManager*:

{code:java}sb.append(style("Id:")).append(entry.getBlockedThread().getId()).append("\n");
{code}

*BacklogTracer*:


{code:java}
private static String wrapAroundRootTag(List events) 
{
StringBuilder sb = new StringBuilder(512);
sb.append("<").append(BacklogTracerEventMessage.ROOT_TAG).append("s>");
for (BacklogTracerEventMessage event : events) {
sb.append("\n").append(event.toXml(2));
}

sb.append("\n");
return sb.toString();
}
{code}

This approach has several problems: 

1. Maintenance hell: this approach leads to code that is hard to read, modify 
and maintain. It is also usually hard to test due to tightly coupling the 
String generation with the data sources.
2. It leads to performance degradation if the underlying buffer is not properly 
sized. 
3. It can also lead to performance degradation due to increased GC pressure 
caused by an excessive creation of transient objects. 
4. Typically, the methods generating the objects are so large that they are not 
inlinable by JIT. 

In particular, problem number 3 makes the whole set of *Console classes 
entirely unsuitable for high-performing / low-latency integrations. 




> camel-core: create a more elegant string generation API
> ---
>
> Key: CAMEL-21181
> URL: https://issues.apache.org/jira/browse/CAMEL-21181
> Project: Camel
>  Issue Type: Improvement
>Reporter: Otavio Rodolfo Piske
>Priority: Minor
>

[jira] [Commented] (CAMEL-21181) camel-core: create a more elegant string generation API

2024-09-06 Thread Otavio Rodolfo Piske (Jira)


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

Otavio Rodolfo Piske commented on CAMEL-21181:
--

BTW, although I had singled out the DevConsoles are the worst offenders, they 
are not the only ones abusing this bad practice. We have quite a few other 
places with code that is just as bad (i.e.: CSimpleCodeGenerator, 
DefaultBacklogTracerEventMessage, DefaultManagementObjectNameStrategy) ... 
camel-management is pretty full of these as well.

> camel-core: create a more elegant string generation API
> ---
>
> Key: CAMEL-21181
> URL: https://issues.apache.org/jira/browse/CAMEL-21181
> Project: Camel
>  Issue Type: Improvement
>Reporter: Otavio Rodolfo Piske
>Priority: Minor
>  Labels: help-wanted
>
> Currently our code has a very rudimentary way to generate String-based output 
> (i.e.: such as those used for the DevConsole). 
> Typically, we generate those strings appending code using a StringBuilder 
> over multiple append calls, spawning several lines of code and, in many 
> cases, generating transient objects in the process.
> In some other (much worse) cases, we concatenate them. 
> The code snippets below present some examples of the kind of thing we do. 
> *JvmDevConsoleFile*: 
> {code:java}
> sb.append(String.format("Java Name: %s\n", mb.getVmName()));
> {code}
> ...
> {code:java}
> String cp = String.join("\n", mb.getBootClassPath().split("[:|;]"));
> sb.append("\n").append(cp).append("\n");
> {code}
> *DefaultAsyncProcessorAwaitManager*:
> {code:java}sb.append(style("Id:")).append(entry.getBlockedThread().getId()).append("\n");
> {code}
> *BacklogTracer*:
> {code:java}
> private static String wrapAroundRootTag(List 
> events) {
> StringBuilder sb = new StringBuilder(512);
> 
> sb.append("<").append(BacklogTracerEventMessage.ROOT_TAG).append("s>");
> for (BacklogTracerEventMessage event : events) {
> sb.append("\n").append(event.toXml(2));
> }
> 
> sb.append("\n");
> return sb.toString();
> }
> {code}
> This approach has several problems: 
> 1. Maintenance hell: this approach leads to code that is hard to read, modify 
> and maintain. It is also usually hard to test due to tightly coupling the 
> String generation with the data sources.
> 2. It leads to performance degradation if the underlying buffer is not 
> properly sized. 
> 3. It can also lead to performance degradation due to increased GC pressure 
> caused by an excessive creation of transient objects. 
> 4. Typically, the methods generating the objects are so large that they are 
> not inlinable by JIT. 
> In particular, problem number 3 makes the whole set of *Console classes 
> entirely unsuitable for high-performing / low-latency integrations. 



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


[jira] [Updated] (CAMEL-21063) Uniformly provide a heath endpoint for exported cloud projects

2024-09-06 Thread Thomas Diesler (Jira)


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

Thomas Diesler updated CAMEL-21063:
---
Description: 
`camel export` used to provide a health endpoint for all runtimes (i.e. main, 
quarkus, spring boot) - this is no longer the case for main.

I suppose a health endpoint is useful in the context of cloud deployments and 
should therefore always be generated through `camel kubernetes export`

  was:
`camel export` used to provide a health endpoint for all runtimes (i.e. main, 
quarkus, spring boot) - this is no longer the case for main + quarkus.

I suppose a health endpoint is useful in the context of cloud deployments and 
should therefore always be generated through `camel kubernetes export`


> Uniformly provide a heath endpoint for exported cloud projects
> --
>
> Key: CAMEL-21063
> URL: https://issues.apache.org/jira/browse/CAMEL-21063
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jbang
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 4.9.0
>
>
> `camel export` used to provide a health endpoint for all runtimes (i.e. main, 
> quarkus, spring boot) - this is no longer the case for main.
> I suppose a health endpoint is useful in the context of cloud deployments and 
> should therefore always be generated through `camel kubernetes export`



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


[jira] [Created] (CAMEL-21185) DefaultShutdownStrategy cannot set timeout via JMX

2024-09-06 Thread Mark Wimpory (Jira)
Mark Wimpory created CAMEL-21185:


 Summary: DefaultShutdownStrategy cannot set timeout via JMX
 Key: CAMEL-21185
 URL: https://issues.apache.org/jira/browse/CAMEL-21185
 Project: Camel
  Issue Type: Bug
Affects Versions: 4.7.0
Reporter: Mark Wimpory
 Attachments: image-2024-09-06-09-07-11-268.png

The docs state that the shutdown timeout can be set via JMX.  However I cannot 
find this setting on the bean.  I will attach a screenshot

!image-2024-09-06-09-07-11-268.png!



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


[jira] [Created] (CAMEL-21183) camel-core - BrowseEndpoint should have limit parameter

2024-09-05 Thread Claus Ibsen (Jira)
Claus Ibsen created CAMEL-21183:
---

 Summary: camel-core - BrowseEndpoint should have limit parameter
 Key: CAMEL-21183
 URL: https://issues.apache.org/jira/browse/CAMEL-21183
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Claus Ibsen
 Fix For: 4.9.0


The method currently

 
List getExchanges();
 
Should have a limit and filter predicate so you can filter first
 



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


[jira] [Resolved] (CAMEL-21182) camel-jbang - Run with json logging does not work

2024-09-05 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-21182.
-
Resolution: Fixed

> camel-jbang - Run with json logging does not work
> -
>
> Key: CAMEL-21182
> URL: https://issues.apache.org/jira/browse/CAMEL-21182
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jbang
>Affects Versions: 4.7.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.8.0
>
>
> ERROR StatusConsoleListener Unable to locate appender "out" for logger config 
> "loggingJson"



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


[jira] [Created] (CAMEL-21182) camel-jbang - Run with json logging does not work

2024-09-05 Thread Claus Ibsen (Jira)
Claus Ibsen created CAMEL-21182:
---

 Summary: camel-jbang - Run with json logging does not work
 Key: CAMEL-21182
 URL: https://issues.apache.org/jira/browse/CAMEL-21182
 Project: Camel
  Issue Type: Bug
  Components: camel-jbang
Affects Versions: 4.7.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 4.8.0


ERROR StatusConsoleListener Unable to locate appender "out" for logger config 
"loggingJson"



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


[jira] [Updated] (CAMEL-21181) camel-core: create a more elegant string generation API

2024-09-05 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21181:

Issue Type: Improvement  (was: Bug)

> camel-core: create a more elegant string generation API
> ---
>
> Key: CAMEL-21181
> URL: https://issues.apache.org/jira/browse/CAMEL-21181
> Project: Camel
>  Issue Type: Improvement
>Reporter: Otavio Rodolfo Piske
>Priority: Major
>  Labels: help-wanted
>
> Currently our code has a very rudimentary way to generate String-based output 
> (i.e.: such as those used for the DevConsole). 
> Typically, we generate those strings appending code using a StringBuilder 
> over multiple append calls, spawning several lines of code and, in many 
> cases, generating transient objects in the process.
> In some other (much worse) cases, we concatenate them. 
> The code snippets below present some examples of the kind of thing we do. 
> *JvmDevConsoleFile*: 
> {code:java}
> sb.append(String.format("Java Name: %s\n", mb.getVmName()));
> {code}
> ...
> {code:java}
> String cp = String.join("\n", mb.getBootClassPath().split("[:|;]"));
> sb.append("\n").append(cp).append("\n");
> {code}
> *DefaultAsyncProcessorAwaitManager*:
> {code:java}sb.append(style("Id:")).append(entry.getBlockedThread().getId()).append("\n");
> {code}
> *BacklogTracer*:
> {code:java}
> private static String wrapAroundRootTag(List 
> events) {
> StringBuilder sb = new StringBuilder(512);
> 
> sb.append("<").append(BacklogTracerEventMessage.ROOT_TAG).append("s>");
> for (BacklogTracerEventMessage event : events) {
> sb.append("\n").append(event.toXml(2));
> }
> 
> sb.append("\n");
> return sb.toString();
> }
> {code}
> This approach has several problems: 
> 1. Maintenance hell: this approach leads to code that is hard to read, modify 
> and maintain. It is also usually hard to test due to tightly coupling the 
> String generation with the data sources.
> 2. It leads to performance degradation if the underlying buffer is not 
> properly sized. 
> 3. It can also lead to performance degradation due to increased GC pressure 
> caused by an excessive creation of transient objects. 
> 4. Typically, the methods generating the objects are so large that they are 
> not inlinable by JIT. 
> In particular, problem number 3 makes the whole set of *Console classes 
> entirely unsuitable for high-performing / low-latency integrations. 



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


[jira] [Updated] (CAMEL-21181) camel-core: create a more elegant string generation API

2024-09-05 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-21181:

Priority: Minor  (was: Major)

> camel-core: create a more elegant string generation API
> ---
>
> Key: CAMEL-21181
> URL: https://issues.apache.org/jira/browse/CAMEL-21181
> Project: Camel
>  Issue Type: Improvement
>Reporter: Otavio Rodolfo Piske
>Priority: Minor
>  Labels: help-wanted
>
> Currently our code has a very rudimentary way to generate String-based output 
> (i.e.: such as those used for the DevConsole). 
> Typically, we generate those strings appending code using a StringBuilder 
> over multiple append calls, spawning several lines of code and, in many 
> cases, generating transient objects in the process.
> In some other (much worse) cases, we concatenate them. 
> The code snippets below present some examples of the kind of thing we do. 
> *JvmDevConsoleFile*: 
> {code:java}
> sb.append(String.format("Java Name: %s\n", mb.getVmName()));
> {code}
> ...
> {code:java}
> String cp = String.join("\n", mb.getBootClassPath().split("[:|;]"));
> sb.append("\n").append(cp).append("\n");
> {code}
> *DefaultAsyncProcessorAwaitManager*:
> {code:java}sb.append(style("Id:")).append(entry.getBlockedThread().getId()).append("\n");
> {code}
> *BacklogTracer*:
> {code:java}
> private static String wrapAroundRootTag(List 
> events) {
> StringBuilder sb = new StringBuilder(512);
> 
> sb.append("<").append(BacklogTracerEventMessage.ROOT_TAG).append("s>");
> for (BacklogTracerEventMessage event : events) {
> sb.append("\n").append(event.toXml(2));
> }
> 
> sb.append("\n");
> return sb.toString();
> }
> {code}
> This approach has several problems: 
> 1. Maintenance hell: this approach leads to code that is hard to read, modify 
> and maintain. It is also usually hard to test due to tightly coupling the 
> String generation with the data sources.
> 2. It leads to performance degradation if the underlying buffer is not 
> properly sized. 
> 3. It can also lead to performance degradation due to increased GC pressure 
> caused by an excessive creation of transient objects. 
> 4. Typically, the methods generating the objects are so large that they are 
> not inlinable by JIT. 
> In particular, problem number 3 makes the whole set of *Console classes 
> entirely unsuitable for high-performing / low-latency integrations. 



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


  1   2   3   4   5   6   7   8   9   10   >