[jira] [Commented] (CAMEL-17474) camel-core: deadlock with multicast in a transacted context
[ https://issues.apache.org/jira/browse/CAMEL-17474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492959#comment-17492959 ] Zheng Feng commented on CAMEL-17474: [~davsclaus] I'm sorry to hear that and hope all of you will recovery very soon. [~jondruse] Thanks so much to investigate this and yeah, I think most codes of the jta TransactionErrorHandler was borrowed from the spring one just replace the spring transaction template. I will dive into this sychronous executions in TransactionErrorHandler to see if we can find a way to fix it. > camel-core: deadlock with multicast in a transacted context > --- > > Key: CAMEL-17474 > URL: https://issues.apache.org/jira/browse/CAMEL-17474 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.13.0, 3.14.0 >Reporter: Jeremy Ross >Assignee: Jiri Ondrusek >Priority: Major > > Using a multicast with more than one child in a transacted context causes a > deadlock. Reproducer here > https://github.com/jeremyross/camel-transacted-multicast. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17652) camel-minio - Auto create bucket should not be done in endpoint
Claus Ibsen created CAMEL-17652: --- Summary: camel-minio - Auto create bucket should not be done in endpoint Key: CAMEL-17652 URL: https://issues.apache.org/jira/browse/CAMEL-17652 Project: Camel Issue Type: Improvement Components: camel-minio Reporter: Claus Ibsen Fix For: 3.16.0 https://ci-builds.apache.org/job/Camel/job/Apache%20Camel/job/main/108/testReport/junit/org.apache.camel.component.minio.integration/MinioConsumerIT/sendIn/ If the bucket cannot be created such as minio service is unavailable (http status 503) then the endpoint fails and camel fails to start. The consumer already have logic for auto-create in its start method, which you can configure to keep restarting the route on failure with the route controller. I am not sure if the producer needs this as the operations are get / list etc - and whether they would fail if bucket does not exist - then this logic needs to be moved to the producer also -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17651) RouteWatcherReloadStrategy crashes on Windows or if pattern is not specified
[ https://issues.apache.org/jira/browse/CAMEL-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492866#comment-17492866 ] JP Moresmau commented on CAMEL-17651: - PR sent. Probably messed up the formatting as I don't understand how to pass formatting checks. > RouteWatcherReloadStrategy crashes on Windows or if pattern is not specified > > > Key: CAMEL-17651 > URL: https://issues.apache.org/jira/browse/CAMEL-17651 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.15.0 > Environment: Windows >Reporter: JP Moresmau >Priority: Minor > Fix For: 3.16.0 > > > On Windows, the FileFilter fails because we try to split the path using '/'. > If I don't set a pattern, it's set to null, and pattern.split(',') fails. > The doc states that the default pattern is \*.yaml,*.xml, so it should be > possible not to set a pattern. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17651) RouteWatcherReloadStrategy crashes on Windows or if pattern is not specified
[ https://issues.apache.org/jira/browse/CAMEL-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492862#comment-17492862 ] Claus Ibsen commented on CAMEL-17651: - You are welcome to send a PR and test it on windows > RouteWatcherReloadStrategy crashes on Windows or if pattern is not specified > > > Key: CAMEL-17651 > URL: https://issues.apache.org/jira/browse/CAMEL-17651 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.15.0 > Environment: Windows >Reporter: JP Moresmau >Priority: Minor > Fix For: 3.16.0 > > > On Windows, the FileFilter fails because we try to split the path using '/'. > If I don't set a pattern, it's set to null, and pattern.split(',') fails. > The doc states that the default pattern is \*.yaml,*.xml, so it should be > possible not to set a pattern. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17651) RouteWatcherReloadStrategy crashes on Windows or if pattern is not specified
[ https://issues.apache.org/jira/browse/CAMEL-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17651: Priority: Minor (was: Major) > RouteWatcherReloadStrategy crashes on Windows or if pattern is not specified > > > Key: CAMEL-17651 > URL: https://issues.apache.org/jira/browse/CAMEL-17651 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.15.0 > Environment: Windows >Reporter: JP Moresmau >Priority: Minor > Fix For: 3.16.0 > > > On Windows, the FileFilter fails because we try to split the path using '/'. > If I don't set a pattern, it's set to null, and pattern.split(',') fails. > The doc states that the default pattern is \*.yaml,*.xml, so it should be > possible not to set a pattern. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17651) RouteWatcherReloadStrategy crashes on Windows or if pattern is not specified
[ https://issues.apache.org/jira/browse/CAMEL-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JP Moresmau updated CAMEL-17651: Description: On Windows, the FileFilter fails because we try to split the path using '/'. If I don't set a pattern, it's set to null, and pattern.split(',') fails. The doc states that the default pattern is \*.yaml,*.xml, so it should be possible not to set a pattern. was: On Windows, the FileFilter fails because we try to split the path using '/'. If I don't set a pattern, it's set to null, and pattern.split(',') fails. The doc states that the default pattern is *.yaml{*},{*}*.xml, so it should be possible not to set a pattern. > RouteWatcherReloadStrategy crashes on Windows or if pattern is not specified > > > Key: CAMEL-17651 > URL: https://issues.apache.org/jira/browse/CAMEL-17651 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.15.0 > Environment: Windows >Reporter: JP Moresmau >Priority: Major > Fix For: 3.16.0 > > > On Windows, the FileFilter fails because we try to split the path using '/'. > If I don't set a pattern, it's set to null, and pattern.split(',') fails. > The doc states that the default pattern is \*.yaml,*.xml, so it should be > possible not to set a pattern. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17651) RouteWatcherReloadStrategy crashes on Windows or if pattern is not specified
JP Moresmau created CAMEL-17651: --- Summary: RouteWatcherReloadStrategy crashes on Windows or if pattern is not specified Key: CAMEL-17651 URL: https://issues.apache.org/jira/browse/CAMEL-17651 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 3.15.0 Environment: Windows Reporter: JP Moresmau Fix For: 3.16.0 On Windows, the FileFilter fails because we try to split the path using '/'. If I don't set a pattern, it's set to null, and pattern.split(',') fails. The doc states that the default pattern is *.yaml{*},{*}*.xml, so it should be possible not to set a pattern. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CAMEL-17649) Examples for setHeader in example are outdated: it contains name attribute instead of headerName
[ https://issues.apache.org/jira/browse/CAMEL-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-17649. - Resolution: Cannot Reproduce > Examples for setHeader in example are outdated: it contains name attribute > instead of headerName > > > Key: CAMEL-17649 > URL: https://issues.apache.org/jira/browse/CAMEL-17649 > Project: Camel > Issue Type: Task > Components: documentation, eip >Affects Versions: 3.15.0 >Reporter: Aurélien Pupier >Priority: Minor > > see > https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header > {noformat} > > > > test > > > > {noformat} > I think that it should be: > {noformat} > > > > test > > > > {noformat} > it was renamed with 3.0 > https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CAMEL-17645) camel-jbang - Reload on modeline changes
[ https://issues.apache.org/jira/browse/CAMEL-17645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-17645. - Resolution: Fixed > camel-jbang - Reload on modeline changes > > > Key: CAMEL-17645 > URL: https://issues.apache.org/jira/browse/CAMEL-17645 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.16.0 > > > If you change a property then we should update this also, currently they are > not affected. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-14104) Update FHIR to latest version
[ https://issues.apache.org/jira/browse/CAMEL-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492730#comment-17492730 ] Paul Coombes commented on CAMEL-14104: -- I was wondering if there had been any progress with camel-fhir / camel 3 and osgi/karaf? Is this something that I could potentially help with? > Update FHIR to latest version > - > > Key: CAMEL-14104 > URL: https://issues.apache.org/jira/browse/CAMEL-14104 > Project: Camel > Issue Type: Improvement > Components: camel-fhir >Reporter: John Poth >Assignee: John Poth >Priority: Major > Fix For: 3.x > > > This will introduce new features and minor breaking changes so should > probably be for Camel 3 only -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CAMEL-17474) camel-core: deadlock with multicast in a transacted context
[ https://issues.apache.org/jira/browse/CAMEL-17474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492692#comment-17492692 ] Jiri Ondrusek edited comment on CAMEL-17474 at 2/15/22, 4:09 PM: - [~zhfeng] I have a theory, what could be reason of this error. As you can see here: [https://github.com/apache/camel/blob/main/components/camel-jta/src/main/java/org/apache/camel/jta/TransactionErrorHandler.java#L91] {code:java} @Override public void process(Exchange exchange) throws Exception { // we have to run this synchronously as a JTA Transaction does *not* // support using multiple threads to span a transaction {code} JtaTransactionErrorHandler has to be run synchronously. Unfortunately the change from [https://github.com/apache/camel/commit/961ad0e56e9331e71c386415ec67676e586ea629#diff-592328b1c35a306fa6ba3875f63b872de065e6d973ea89870d579bbab505cfadR214], which replaces "reactiveExecutor.scheduleSync(task);" with "reactiveExecutor.scheduleQueue(task);" changed synchronous executions to asynchronous. With that changed, jta/TransactionErrorHandler does not work correctly. Quick fix is to revert back synchronous behavior, but I'm sure that it is not correct. Do you have an idea how this could be fixed? I see a possibility to define synchronous executions in case that camel-jta transactions are used. I'm ot sure whether it will be p At least this explains why spring transaction works (does not need synchronous executions)... was (Author: jondruse): [~zhfeng] I have a theory, what could be reason of this error. As you can see here: [https://github.com/apache/camel/blob/main/components/camel-jta/src/main/java/org/apache/camel/jta/TransactionErrorHandler.java#L91] {code:java} @Override public void process(Exchange exchange) throws Exception { // we have to run this synchronously as a JTA Transaction does *not* // support using multiple threads to span a transaction {code} JtaTransactionErrorHandler has to be run synchronously. Unfortunately the change from [https://github.com/apache/camel/commit/961ad0e56e9331e71c386415ec67676e586ea629#diff-592328b1c35a306fa6ba3875f63b872de065e6d973ea89870d579bbab505cfadR214], which replaces "reactiveExecutor.scheduleSync(task);" with "reactiveExecutor.scheduleQueue(task);" changed synchronous executions to asynchronous. With that changed, jta/TransactionErrorHandler does not work correctly. Quick fix is to revert back synchronous behavior, but I'm sure that it is not correct. Do you have an idea how this could be fixed? At least this explains why spring transaction works (does not need synchronous executions)... > camel-core: deadlock with multicast in a transacted context > --- > > Key: CAMEL-17474 > URL: https://issues.apache.org/jira/browse/CAMEL-17474 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.13.0, 3.14.0 >Reporter: Jeremy Ross >Assignee: Jiri Ondrusek >Priority: Major > > Using a multicast with more than one child in a transacted context causes a > deadlock. Reproducer here > https://github.com/jeremyross/camel-transacted-multicast. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17474) camel-core: deadlock with multicast in a transacted context
[ https://issues.apache.org/jira/browse/CAMEL-17474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492692#comment-17492692 ] Jiri Ondrusek commented on CAMEL-17474: --- [~zhfeng] I have a theory, what could be reason of this error. As you can see here: [https://github.com/apache/camel/blob/main/components/camel-jta/src/main/java/org/apache/camel/jta/TransactionErrorHandler.java#L91] {code:java} @Override public void process(Exchange exchange) throws Exception { // we have to run this synchronously as a JTA Transaction does *not* // support using multiple threads to span a transaction {code} JtaTransactionErrorHandler has to be run synchronously. Unfortunately the change from [https://github.com/apache/camel/commit/961ad0e56e9331e71c386415ec67676e586ea629#diff-592328b1c35a306fa6ba3875f63b872de065e6d973ea89870d579bbab505cfadR214], which replaces "reactiveExecutor.scheduleSync(task);" with "reactiveExecutor.scheduleQueue(task);" changed synchronous executions to asynchronous. With that changed, jta/TransactionErrorHandler does not work correctly. Quick fix is to revert back synchronous behavior, but I'm sure that it is not correct. Do you have an idea how this could be fixed? At least this explains why spring transaction works (does not need synchronous executions)... > camel-core: deadlock with multicast in a transacted context > --- > > Key: CAMEL-17474 > URL: https://issues.apache.org/jira/browse/CAMEL-17474 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.13.0, 3.14.0 >Reporter: Jeremy Ross >Assignee: Jiri Ondrusek >Priority: Major > > Using a multicast with more than one child in a transacted context causes a > deadlock. Reproducer here > https://github.com/jeremyross/camel-transacted-multicast. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CAMEL-17646) camel-vertx-websocket - Server exception handler should check for cause ConnectionBase.CLOSED_EXCEPTION
[ https://issues.apache.org/jira/browse/CAMEL-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-17646. - Resolution: Fixed > camel-vertx-websocket - Server exception handler should check for cause > ConnectionBase.CLOSED_EXCEPTION > --- > > Key: CAMEL-17646 > URL: https://issues.apache.org/jira/browse/CAMEL-17646 > Project: Camel > Issue Type: Improvement > Components: camel-vertx-websocket >Affects Versions: 3.11.5, 3.14.1, 3.15.0 >Reporter: James Netherton >Assignee: James Netherton >Priority: Minor > Fix For: 3.14.2, 3.11.6, 3.16.0 > > > Whenever a client closes an established connection to the WebSocket server, > the Vert.x exception handler is triggered which results in the exception > being propagated to the Camel exception handler. > This is not really necessary because the WS server already has a close > handler registered. Therefore, it's safe to ignore any instances of > ConnectionBase.CLOSED_EXCEPTION. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CAMEL-17650) camel-vertx-websocket: sendToAll operation should consider the path WebSocket clients are connected to
[ https://issues.apache.org/jira/browse/CAMEL-17650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Netherton resolved CAMEL-17650. - Resolution: Fixed > camel-vertx-websocket: sendToAll operation should consider the path WebSocket > clients are connected to > -- > > Key: CAMEL-17650 > URL: https://issues.apache.org/jira/browse/CAMEL-17650 > Project: Camel > Issue Type: Improvement > Components: camel-vertx-websocket >Affects Versions: 3.11.5, 3.14.1, 3.15.0 >Reporter: James Netherton >Assignee: James Netherton >Priority: Major > Fix For: 3.14.2, 3.11.6, 3.16.0 > > > When the sendToAll option is used on the vertx-websocket producer, it should > take the path that WebSocket clients are connected on into consideration. > Currently the logic to match connected peers is done only on the combination > of host & port. This means that there's the potential for clients to receive > messages that they are not strictly interested in. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17040) rest-dsl - Add option to return http 204 when no data in response
[ https://issues.apache.org/jira/browse/CAMEL-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492590#comment-17492590 ] Claus Ibsen commented on CAMEL-17040: - Yeah an empty string or null body etc > rest-dsl - Add option to return http 204 when no data in response > - > > Key: CAMEL-17040 > URL: https://issues.apache.org/jira/browse/CAMEL-17040 > Project: Camel > Issue Type: Improvement > Components: camel-core, rest >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > For example if you have a json response as an empty list, then you can get a > 200 OK with [] as response. > Or with an XML then it may be an empty xml root object. > It may be desirable to have an option you can set to true to let Camel > auto-detect this and return no body and 204 instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17040) rest-dsl - Add option to return http 204 when no data in response
[ https://issues.apache.org/jira/browse/CAMEL-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492560#comment-17492560 ] Neo Xu commented on CAMEL-17040: If it is json response, can it be three different cases [], {}, ""? > rest-dsl - Add option to return http 204 when no data in response > - > > Key: CAMEL-17040 > URL: https://issues.apache.org/jira/browse/CAMEL-17040 > Project: Camel > Issue Type: Improvement > Components: camel-core, rest >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > For example if you have a json response as an empty list, then you can get a > 200 OK with [] as response. > Or with an XML then it may be an empty xml root object. > It may be desirable to have an option you can set to true to let Camel > auto-detect this and return no body and 204 instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CAMEL-17647) camel-core - Properties component should support pluggable functions
[ https://issues.apache.org/jira/browse/CAMEL-17647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-17647. - Resolution: Fixed > camel-core - Properties component should support pluggable functions > > > Key: CAMEL-17647 > URL: https://issues.apache.org/jira/browse/CAMEL-17647 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.16.0 > > > So we can provide custom functions in their own components that have specific > implementation, such as connecting to vault systems, or end users can make > custom functions that can lookup from a database etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17644) Support ability to load properties from Vault/Secrets cloud services
[ https://issues.apache.org/jira/browse/CAMEL-17644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492532#comment-17492532 ] Andrea Cosentino commented on CAMEL-17644: -- By leveraging, CAMEL-17647, we can move the functions in their own component. > Support ability to load properties from Vault/Secrets cloud services > > > Key: CAMEL-17644 > URL: https://issues.apache.org/jira/browse/CAMEL-17644 > Project: Camel > Issue Type: Improvement >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.x > > > This is slightly different from CAMEL-11030 > With this I'd like to able to do stuff like: > {code:bash} > {{aws:token}} > {code} > and get the secret value from the secret token on AWS Secrets Manager, this > could be done for also GCP and Azure. > For the beginning we are not considering secret rotations, but we'll arrive > at that during development cycle. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17649) Examples for setHeader in example are outdated: it contains name attribute instead of headerName
[ https://issues.apache.org/jira/browse/CAMEL-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17649: Issue Type: Task (was: Bug) > Examples for setHeader in example are outdated: it contains name attribute > instead of headerName > > > Key: CAMEL-17649 > URL: https://issues.apache.org/jira/browse/CAMEL-17649 > Project: Camel > Issue Type: Task > Components: documentation, eip >Affects Versions: 3.15.0 >Reporter: Aurélien Pupier >Priority: Major > > see > https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header > {noformat} > > > > test > > > > {noformat} > I think that it should be: > {noformat} > > > > test > > > > {noformat} > it was renamed with 3.0 > https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17649) Examples for setHeader in example are outdated: it contains name attribute instead of headerName
[ https://issues.apache.org/jira/browse/CAMEL-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17649: Priority: Minor (was: Major) > Examples for setHeader in example are outdated: it contains name attribute > instead of headerName > > > Key: CAMEL-17649 > URL: https://issues.apache.org/jira/browse/CAMEL-17649 > Project: Camel > Issue Type: Task > Components: documentation, eip >Affects Versions: 3.15.0 >Reporter: Aurélien Pupier >Priority: Minor > > see > https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header > {noformat} > > > > test > > > > {noformat} > I think that it should be: > {noformat} > > > > test > > > > {noformat} > it was renamed with 3.0 > https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17650) camel-vertx-websocket: sendToAll operation should consider the path WebSocket clients are connected to
James Netherton created CAMEL-17650: --- Summary: camel-vertx-websocket: sendToAll operation should consider the path WebSocket clients are connected to Key: CAMEL-17650 URL: https://issues.apache.org/jira/browse/CAMEL-17650 Project: Camel Issue Type: Improvement Components: camel-vertx-websocket Affects Versions: 3.15.0, 3.14.1, 3.11.5 Reporter: James Netherton Assignee: James Netherton Fix For: 3.14.2, 3.11.6, 3.16.0 When the sendToAll option is used on the vertx-websocket producer, it should take the path that WebSocket clients are connected on into consideration. Currently the logic to match connected peers is done only on the combination of host & port. This means that there's the potential for clients to receive messages that they are not strictly interested in. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CAMEL-17649) Examples for setHeader in example are outdated: it contains name attribute instead of headerName
[ https://issues.apache.org/jira/browse/CAMEL-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492528#comment-17492528 ] Claus Ibsen edited comment on CAMEL-17649 at 2/15/22, 10:45 AM: You are likely using an outdated XSD, see setHeaderDefinition in the camel-spring.xsd file, such as from online: https://camel.apache.org/schema/spring/camel-spring.xsd was (Author: davsclaus): You are likely using an outdated XSD, see setHeaderDefinition in the camel-spring.xsd file. > Examples for setHeader in example are outdated: it contains name attribute > instead of headerName > > > Key: CAMEL-17649 > URL: https://issues.apache.org/jira/browse/CAMEL-17649 > Project: Camel > Issue Type: Task > Components: documentation, eip >Affects Versions: 3.15.0 >Reporter: Aurélien Pupier >Priority: Minor > > see > https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header > {noformat} > > > > test > > > > {noformat} > I think that it should be: > {noformat} > > > > test > > > > {noformat} > it was renamed with 3.0 > https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17649) Examples for setHeader in example are outdated: it contains name attribute instead of headerName
[ https://issues.apache.org/jira/browse/CAMEL-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492528#comment-17492528 ] Claus Ibsen commented on CAMEL-17649: - You are likely using an outdated XSD, see setHeaderDefinition in the camel-spring.xsd file. > Examples for setHeader in example are outdated: it contains name attribute > instead of headerName > > > Key: CAMEL-17649 > URL: https://issues.apache.org/jira/browse/CAMEL-17649 > Project: Camel > Issue Type: Bug > Components: documentation, eip >Affects Versions: 3.15.0 >Reporter: Aurélien Pupier >Priority: Major > > see > https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header > {noformat} > > > > test > > > > {noformat} > I think that it should be: > {noformat} > > > > test > > > > {noformat} > it was renamed with 3.0 > https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CAMEL-17649) Examples for setHeader in example are outdated: it contains name attribute instead of headerName
[ https://issues.apache.org/jira/browse/CAMEL-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492510#comment-17492510 ] Aurélien Pupier edited comment on CAMEL-17649 at 2/15/22, 10:27 AM: it seems that in fact, usage of headerName or name attributes depends on more parameters: using route attribute directly, when loading, iI need to use the name: {noformat} value of header 1 value of header 2 value of property 1 value of property 2 {noformat} when using the spring and camelcontext, I need to use the headerName: {noformat} http://www.springframework.org/schema/beans; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=" http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://camel.apache.org/schema/spring https://camel.apache.org/schema/spring/camel-spring.xsd;> http://camel.apache.org/schema/spring;> value of header 1 value of header 2 value of property 1 value of property 2 {noformat} was (Author: apupier): it seems that in fact, usage of headerName or name attributes depends on more parameters: using route attribute directly, when loading, iI need to use the name: {noformat} value of header 1 value of header 2 value of property 1 value of property 2 {noformat} when using the spring and camelcontext, I need to use the headerName: {noformaŧ} http://www.springframework.org/schema/beans; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=" http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://camel.apache.org/schema/spring https://camel.apache.org/schema/spring/camel-spring.xsd;> http://camel.apache.org/schema/spring;> value of header 1 value of header 2 value of property 1 value of property 2 {noformat} > Examples for setHeader in example are outdated: it contains name attribute > instead of headerName > > > Key: CAMEL-17649 > URL: https://issues.apache.org/jira/browse/CAMEL-17649 > Project: Camel > Issue Type: Bug > Components: documentation, eip >Affects Versions: 3.15.0 >Reporter: Aurélien Pupier >Priority: Major > > see > https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header > {noformat} > > > > test > > > > {noformat} > I think that it should be: > {noformat} > > > > test > > > > {noformat} > it was renamed with 3.0 > https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17649) Examples for setHeader in example are outdated: it contains name attribute instead of headerName
[ https://issues.apache.org/jira/browse/CAMEL-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492510#comment-17492510 ] Aurélien Pupier commented on CAMEL-17649: - it seems that in fact, usage of headerName or name attributes depends on more parameters: using route attribute directly, when loading, iI need to use the name: {noformat} value of header 1 value of header 2 value of property 1 value of property 2 {noformat} when using the spring and camelcontext, I need to use the headerName: {noformaŧ} http://www.springframework.org/schema/beans; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=" http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://camel.apache.org/schema/spring https://camel.apache.org/schema/spring/camel-spring.xsd;> http://camel.apache.org/schema/spring;> value of header 1 value of header 2 value of property 1 value of property 2 {noformat} > Examples for setHeader in example are outdated: it contains name attribute > instead of headerName > > > Key: CAMEL-17649 > URL: https://issues.apache.org/jira/browse/CAMEL-17649 > Project: Camel > Issue Type: Bug > Components: documentation, eip >Affects Versions: 3.15.0 >Reporter: Aurélien Pupier >Priority: Major > > see > https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header > {noformat} > > > > test > > > > {noformat} > I think that it should be: > {noformat} > > > > test > > > > {noformat} > it was renamed with 3.0 > https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17649) Examples for setHeader in example are outdated: it contains name attribute instead of headerName
[ https://issues.apache.org/jira/browse/CAMEL-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aurélien Pupier updated CAMEL-17649: Description: see https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header {noformat} test {noformat} I think that it should be: {noformat} test {noformat} it was renamed with 3.0 https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl was: see https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header {noformat} test {noformat} I think that it should be: {noformat} test {noformat} it was renamed with 3.0 https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl > Examples for setHeader in example are outdated: it contains name attribute > instead of headerName > > > Key: CAMEL-17649 > URL: https://issues.apache.org/jira/browse/CAMEL-17649 > Project: Camel > Issue Type: Bug > Components: documentation, eip >Affects Versions: 3.15.0 >Reporter: Aurélien Pupier >Priority: Major > > see > https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header > {noformat} > > > > test > > > > {noformat} > I think that it should be: > {noformat} > > > > test > > > > {noformat} > it was renamed with 3.0 > https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17649) Examples for setHeader in example are outdated: it contains name attribute instead of headerName
[ https://issues.apache.org/jira/browse/CAMEL-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aurélien Pupier updated CAMEL-17649: Description: see https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header {noformat} test {noformat} I think that it should be: {noformat} test {noformat} it was renamed with 3.0 https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl was: see https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header {noformat} test {noformat} I think that it should be: {noformat} test {noformat} > Examples for setHeader in example are outdated: it contains name attribute > instead of headerName > > > Key: CAMEL-17649 > URL: https://issues.apache.org/jira/browse/CAMEL-17649 > Project: Camel > Issue Type: Bug > Components: documentation, eip >Affects Versions: 3.15.0 >Reporter: Aurélien Pupier >Priority: Major > > see > https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header > {noformat} > > > > test > > > > {noformat} > I think that it should be: > {noformat} > > > > test > > > > {noformat} > it was renamed with 3.0 > https://camel.apache.org/manual/camel-3-migration-guide.html#_setheader_and_setproperty_in_xml_dsl -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17649) Examples for setHeader in example are outdated: it contains name attribute instead of headerName
Aurélien Pupier created CAMEL-17649: --- Summary: Examples for setHeader in example are outdated: it contains name attribute instead of headerName Key: CAMEL-17649 URL: https://issues.apache.org/jira/browse/CAMEL-17649 Project: Camel Issue Type: Bug Components: documentation, eip Affects Versions: 3.15.0 Reporter: Aurélien Pupier see https://camel.apache.org/components/3.15.x/eips/setHeader-eip.html#_using_set_header {noformat} test {noformat} I think that it should be: {noformat} test {noformat} -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (CAMEL-17647) camel-core - Properties component should support pluggable functions
[ https://issues.apache.org/jira/browse/CAMEL-17647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-17647: --- Assignee: Claus Ibsen > camel-core - Properties component should support pluggable functions > > > Key: CAMEL-17647 > URL: https://issues.apache.org/jira/browse/CAMEL-17647 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.16.0 > > > So we can provide custom functions in their own components that have specific > implementation, such as connecting to vault systems, or end users can make > custom functions that can lookup from a database etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17648) Optimizing File component performance when filtering file names.
[ https://issues.apache.org/jira/browse/CAMEL-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492463#comment-17492463 ] Ja commented on CAMEL-17648: With this optimalization in mind, also would be nice to have query parameter to limit directory size (the number of files contained in the directory) just after getting its content. So we could don’t even try polling hundreds of thousands of files. > Optimizing File component performance when filtering file names. > > > Key: CAMEL-17648 > URL: https://issues.apache.org/jira/browse/CAMEL-17648 > Project: Camel > Issue Type: Improvement > Components: camel-file >Reporter: Ja >Priority: Minor > Fix For: 3.x > > > Currently FileConsumer matches file names after creating GenericFile object > for each file witch can be time consuming especially in shared network > directories. > This could be optimized by matching on name based query parameters (fileName, > include, exclude, antExclude, antInclude, includeExt, excludeExt) before > creating GenericFile objects. > If the file name does not match creating GenericFile objects would not be > necessary. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17648) Optimizing File component performance when filtering file names.
[ https://issues.apache.org/jira/browse/CAMEL-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492447#comment-17492447 ] Claus Ibsen commented on CAMEL-17648: - Oh yeah we can likely do this kind of optimization when its filter only on the name - mind that the generic file component is also used by camel-ftp so changes in camel-file is also affecting this component. > Optimizing File component performance when filtering file names. > > > Key: CAMEL-17648 > URL: https://issues.apache.org/jira/browse/CAMEL-17648 > Project: Camel > Issue Type: Improvement > Components: camel-file >Reporter: Ja >Priority: Minor > > Currently FileConsumer matches file names after creating GenericFile object > for each file witch can be time consuming especially in shared network > directories. > This could be optimized by matching on name based query parameters (fileName, > include, exclude, antExclude, antInclude, includeExt, excludeExt) before > creating GenericFile objects. > If the file name does not match creating GenericFile objects would not be > necessary. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17648) Optimizing File component performance when filtering file names.
[ https://issues.apache.org/jira/browse/CAMEL-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17648: Fix Version/s: 3.x > Optimizing File component performance when filtering file names. > > > Key: CAMEL-17648 > URL: https://issues.apache.org/jira/browse/CAMEL-17648 > Project: Camel > Issue Type: Improvement > Components: camel-file >Reporter: Ja >Priority: Minor > Fix For: 3.x > > > Currently FileConsumer matches file names after creating GenericFile object > for each file witch can be time consuming especially in shared network > directories. > This could be optimized by matching on name based query parameters (fileName, > include, exclude, antExclude, antInclude, includeExt, excludeExt) before > creating GenericFile objects. > If the file name does not match creating GenericFile objects would not be > necessary. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17648) Optimizing File component performance when filtering file names.
[ https://issues.apache.org/jira/browse/CAMEL-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17648: Priority: Minor (was: Major) > Optimizing File component performance when filtering file names. > > > Key: CAMEL-17648 > URL: https://issues.apache.org/jira/browse/CAMEL-17648 > Project: Camel > Issue Type: Improvement > Components: camel-file >Reporter: Ja >Priority: Minor > > Currently FileConsumer matches file names after creating GenericFile object > for each file witch can be time consuming especially in shared network > directories. > This could be optimized by matching on name based query parameters (fileName, > include, exclude, antExclude, antInclude, includeExt, excludeExt) before > creating GenericFile objects. > If the file name does not match creating GenericFile objects would not be > necessary. -- This message was sent by Atlassian Jira (v8.20.1#820001)