[jira] [Resolved] (CAMEL-13025) camel-core - File read lock changed - If file gets deleted then break out loop
[ https://issues.apache.org/jira/browse/CAMEL-13025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-13025. - Resolution: Fixed Fix Version/s: 2.23.1 2.22.3 2.21.4 > camel-core - File read lock changed - If file gets deleted then break out loop > -- > > Key: CAMEL-13025 > URL: https://issues.apache.org/jira/browse/CAMEL-13025 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.18.5 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 2.21.4, 2.22.3, 3.0.0, 2.24.0, 2.23.1 > > Time Spent: 40m > Remaining Estimate: 0h > > See SO > https://stackoverflow.com/questions/53865940/apache-camel-route-hangs-when-file-is-deleted-during-processing?noredirect=1#comment94587192_53865940 > So if the target file gets deleted during the check interval and you have > timeout = 0, then it will keep looping. So we should add a check if the file > still exists in the looping. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13030) Thread lock using same mqtt endpoint into SpringDSL and Bean
[
https://issues.apache.org/jira/browse/CAMEL-13030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-13030:
Priority: Major (was: Blocker)
> Thread lock using same mqtt endpoint into SpringDSL and Bean
>
>
> Key: CAMEL-13030
> URL: https://issues.apache.org/jira/browse/CAMEL-13030
> Project: Camel
> Issue Type: Bug
> Components: camel-mqtt
>Affects Versions: 3.0.0
>Reporter: Fabrizio Spataro
>Priority: Major
>
> Into my camel application, the thread is blocked when use same mqtt endpoint
> specified into:
> - Spring Application Context (Spring DSL)
> - Spring bean (using ProducerTemplate inject by *EndpointInject* annotation)
> I wrote a junit file into my github repo
> https://github.com/Fabryprog/camel/tree/CAMEL-13030
> You can reproduce it by:
> {code:java}
> mvn clean
> -Dtest=org.apache.camel.component.mqtt.MQTTEndpointInjectTemplateTest test
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (CAMEL-13025) camel-core - File read lock changed - If file gets deleted then break out loop
[
https://issues.apache.org/jira/browse/CAMEL-13025?focusedWorklogId=178142=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-178142
]
ASF GitHub Bot logged work on CAMEL-13025:
--
Author: ASF GitHub Bot
Created on: 21/Dec/18 20:32
Start Date: 21/Dec/18 20:32
Worklog Time Spent: 10m
Work Description: davsclaus closed pull request #2684:
CAMEL-13025:FileDeletionWithZeroTimeout
URL: https://github.com/apache/camel/pull/2684
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/camel-core/src/main/java/org/apache/camel/component/file/strategy/FileChangedExclusiveReadLockStrategy.java
b/camel-core/src/main/java/org/apache/camel/component/file/strategy/FileChangedExclusiveReadLockStrategy.java
index ab2f552125d..33c546b4697 100644
---
a/camel-core/src/main/java/org/apache/camel/component/file/strategy/FileChangedExclusiveReadLockStrategy.java
+++
b/camel-core/src/main/java/org/apache/camel/component/file/strategy/FileChangedExclusiveReadLockStrategy.java
@@ -71,6 +71,11 @@ public boolean
acquireExclusiveReadLock(GenericFileOperations operations,
}
}
+if(!target.exists()) {
+CamelLogger.log(LOG,readLockLoggingLevel,"File
"+target.getName()+" got deleted.");
+ return false;
+}
+
long newLastModified = target.lastModified();
long newLength = target.length();
long newOlderThan = startTime + watch.taken() - minAge;
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 178142)
Time Spent: 40m (was: 0.5h)
> camel-core - File read lock changed - If file gets deleted then break out loop
> --
>
> Key: CAMEL-13025
> URL: https://issues.apache.org/jira/browse/CAMEL-13025
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 2.18.5
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 3.0.0, 2.24.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> See SO
> https://stackoverflow.com/questions/53865940/apache-camel-route-hangs-when-file-is-deleted-during-processing?noredirect=1#comment94587192_53865940
> So if the target file gets deleted during the check interval and you have
> timeout = 0, then it will keep looping. So we should add a check if the file
> still exists in the looping.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CAMEL-13025) camel-core - File read lock changed - If file gets deleted then break out loop
[ https://issues.apache.org/jira/browse/CAMEL-13025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-13025: --- Assignee: Claus Ibsen > camel-core - File read lock changed - If file gets deleted then break out loop > -- > > Key: CAMEL-13025 > URL: https://issues.apache.org/jira/browse/CAMEL-13025 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.18.5 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 2.24.0 > > Time Spent: 40m > Remaining Estimate: 0h > > See SO > https://stackoverflow.com/questions/53865940/apache-camel-route-hangs-when-file-is-deleted-during-processing?noredirect=1#comment94587192_53865940 > So if the target file gets deleted during the check interval and you have > timeout = 0, then it will keep looping. So we should add a check if the file > still exists in the looping. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13025) camel-core - File read lock changed - If file gets deleted then break out loop
[ https://issues.apache.org/jira/browse/CAMEL-13025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16727039#comment-16727039 ] Claus Ibsen commented on CAMEL-13025: - There is also another read lock which needed same improvement. > camel-core - File read lock changed - If file gets deleted then break out loop > -- > > Key: CAMEL-13025 > URL: https://issues.apache.org/jira/browse/CAMEL-13025 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.18.5 >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 2.24.0 > > Time Spent: 40m > Remaining Estimate: 0h > > See SO > https://stackoverflow.com/questions/53865940/apache-camel-route-hangs-when-file-is-deleted-during-processing?noredirect=1#comment94587192_53865940 > So if the target file gets deleted during the check interval and you have > timeout = 0, then it will keep looping. So we should add a check if the file > still exists in the looping. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13030) Thread lock using same mqtt endpoint into SpringDSL and Bean
[
https://issues.apache.org/jira/browse/CAMEL-13030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabrizio Spataro updated CAMEL-13030:
-
Description:
Into my camel application, the thread is blocked when use same mqtt endpoint
specified into:
- Spring Application Context (Spring DSL)
- Spring bean (using ProducerTemplate inject by *EndpointInject* annotation)
I wrote a junit file into my github repo
https://github.com/Fabryprog/camel/tree/CAMEL-13030
You can reproduce it by:
{code:java}
mvn clean -Dtest=org.apache.camel.component.mqtt.MQTTEndpointInjectTemplateTest
test
{code}
was:
Into my camel application, the thread is blocked when use same mqtt endpoint
specified into:
- Spring Application Context (Spring DSL)
- Spring bean (using ProducerTemplate inject by *EndpointInject* annotation)
I wrote a junit file into my github repo
You can reproduce it by:
{code:java}
mvn clean -Dtest=org.apache.camel.component.mqtt.MQTTEndpointInjectTemplateTest
test
{code}
> Thread lock using same mqtt endpoint into SpringDSL and Bean
>
>
> Key: CAMEL-13030
> URL: https://issues.apache.org/jira/browse/CAMEL-13030
> Project: Camel
> Issue Type: Bug
> Components: camel-mqtt
>Affects Versions: 3.0.0
>Reporter: Fabrizio Spataro
>Priority: Blocker
>
> Into my camel application, the thread is blocked when use same mqtt endpoint
> specified into:
> - Spring Application Context (Spring DSL)
> - Spring bean (using ProducerTemplate inject by *EndpointInject* annotation)
> I wrote a junit file into my github repo
> https://github.com/Fabryprog/camel/tree/CAMEL-13030
> You can reproduce it by:
> {code:java}
> mvn clean
> -Dtest=org.apache.camel.component.mqtt.MQTTEndpointInjectTemplateTest test
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13030) Thread lock using same mqtt endpoint into SpringDSL and Bean
Fabrizio Spataro created CAMEL-13030:
Summary: Thread lock using same mqtt endpoint into SpringDSL and
Bean
Key: CAMEL-13030
URL: https://issues.apache.org/jira/browse/CAMEL-13030
Project: Camel
Issue Type: Bug
Components: camel-mqtt
Affects Versions: 3.0.0
Reporter: Fabrizio Spataro
Into my camel application, the thread is blocked when use same mqtt endpoint
specified into:
- Spring Application Context (Spring DSL)
- Spring bean (using ProducerTemplate inject by *EndpointInject* annotation)
I wrote a junit file into my github repo
You can reproduce it by:
{code:java}
mvn clean -Dtest=org.apache.camel.component.mqtt.MQTTEndpointInjectTemplateTest
test
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CAMEL-13028) camel-undertow - When using SSL with rest-dsl and api-doc then you can get a port already bound exception
[
https://issues.apache.org/jira/browse/CAMEL-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-13028.
-
Resolution: Fixed
Fix Version/s: 2.21.4
> camel-undertow - When using SSL with rest-dsl and api-doc then you can get a
> port already bound exception
> -
>
> Key: CAMEL-13028
> URL: https://issues.apache.org/jira/browse/CAMEL-13028
> Project: Camel
> Issue Type: Bug
> Components: camel-undertow
>Affects Versions: 2.23.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.21.4, 2.22.3, 3.0.0, 2.24.0, 2.23.1
>
>
> For example this route cannot startup
> {code}
> public void configure() throws Exception {
>
> restConfiguration().scheme("https").component("undertow").port().contextPath("/").host("0.0.0.0")
> .apiContextPath("/swagger.json")
> .dataFormatProperty("prettyPrint", "true")
> .apiProperty("api.schemes", "https")
> .apiProperty("api.title", "Rest swagger")
> .apiProperty("api.description", "Camel Rest App
> with Swagger");
> rest("/user").get().to("direct:start");
> from("direct:start").setBody().constant("Hi Camels");
> }
> {code}
> With a
> {code}
> Caused by: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method) ~[na:1.8.0_181]
> at sun.nio.ch.Net.bind(Net.java:433) ~[na:1.8.0_181]
> at sun.nio.ch.Net.bind(Net.java:425) ~[na:1.8.0_181]
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> ~[na:1.8.0_181]
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> ~[na:1.8.0_181]
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CAMEL-13029) camel-swagger-java - Should default use scheme from rest-dsl configuration in swagger doc
[
https://issues.apache.org/jira/browse/CAMEL-13029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-13029.
-
Resolution: Fixed
Fix Version/s: 2.21.4
> camel-swagger-java - Should default use scheme from rest-dsl configuration in
> swagger doc
> -
>
> Key: CAMEL-13029
> URL: https://issues.apache.org/jira/browse/CAMEL-13029
> Project: Camel
> Issue Type: Improvement
> Components: camel-swagger
>Affects Versions: 2.23.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.21.4, 2.22.3, 3.0.0, 2.24.0, 2.23.1
>
>
> Because http is default then we have not noticed before. But if you use https
> as the scheme in the rest-dsl for the rest service then the swagger doc
> generated is outputting http by default. We should use the scheme setting
> from the rest-dsl out of the box.
> You can configure it explicit via
> .apiProperty("schemes", "https")
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13026) Header written out on each message when marshalling
[
https://issues.apache.org/jira/browse/CAMEL-13026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726832#comment-16726832
]
Christian Ribeaud commented on CAMEL-13026:
---
What you are describing is a workaround. I should basically have two
{{CSVFormats}}, one for _empty_ file and one for _non-empty_ one.
When writing out a _huge_ *CSV* file, you do not want to keep the content in
the memory. Instead, you prefer to append to an existing file. And because it
is possible to specify a header in {{CSVFormat}}, I would expect
{{CsvMarshaller}} being smart enough to be able to handle such case.
But, I see your point, maybe one DOES want to write out a new file for each
message. And they all should contain the header.
However, instead of making my routing more complicate, how about being able to:
# Extend {{CsvMarshaller}} to customize it to my needs? (currently not possible)
# Specify a message property to tackle my use case?
> Header written out on each message when marshalling
> ---
>
> Key: CAMEL-13026
> URL: https://issues.apache.org/jira/browse/CAMEL-13026
> Project: Camel
> Issue Type: Improvement
> Components: camel-csv
>Reporter: Christian Ribeaud
>Priority: Major
>
> When *CSV* marshalling, the header is written out on each message.
> Additionally, {{CsvMarshaller}} is so opaque, making it difficult for
> customization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13029) camel-swagger-java - Should default use scheme from rest-dsl configuration in swagger doc
Claus Ibsen created CAMEL-13029:
---
Summary: camel-swagger-java - Should default use scheme from
rest-dsl configuration in swagger doc
Key: CAMEL-13029
URL: https://issues.apache.org/jira/browse/CAMEL-13029
Project: Camel
Issue Type: Improvement
Components: camel-swagger
Affects Versions: 2.23.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 2.22.3, 3.0.0, 2.24.0, 2.23.1
Because http is default then we have not noticed before. But if you use https
as the scheme in the rest-dsl for the rest service then the swagger doc
generated is outputting http by default. We should use the scheme setting from
the rest-dsl out of the box.
You can configure it explicit via
.apiProperty("schemes", "https")
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13028) camel-undertow - When using SSL with rest-dsl and api-doc then you can get a port already bound exception
Claus Ibsen created CAMEL-13028:
---
Summary: camel-undertow - When using SSL with rest-dsl and api-doc
then you can get a port already bound exception
Key: CAMEL-13028
URL: https://issues.apache.org/jira/browse/CAMEL-13028
Project: Camel
Issue Type: Bug
Components: camel-undertow
Affects Versions: 2.23.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 2.22.3, 3.0.0, 2.24.0, 2.23.1
For example this route cannot startup
{code}
public void configure() throws Exception {
restConfiguration().scheme("https").component("undertow").port().contextPath("/").host("0.0.0.0")
.apiContextPath("/swagger.json")
.dataFormatProperty("prettyPrint", "true")
.apiProperty("api.schemes", "https")
.apiProperty("api.title", "Rest swagger")
.apiProperty("api.description", "Camel Rest App
with Swagger");
rest("/user").get().to("direct:start");
from("direct:start").setBody().constant("Hi Camels");
}
{code}
With a
{code}
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method) ~[na:1.8.0_181]
at sun.nio.ch.Net.bind(Net.java:433) ~[na:1.8.0_181]
at sun.nio.ch.Net.bind(Net.java:425) ~[na:1.8.0_181]
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
~[na:1.8.0_181]
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
~[na:1.8.0_181]
...
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CAMEL-13027) Camel-AWS: Create a Camel-AWS EKS component
[ https://issues.apache.org/jira/browse/CAMEL-13027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-13027. -- Resolution: Fixed > Camel-AWS: Create a Camel-AWS EKS component > --- > > Key: CAMEL-13027 > URL: https://issues.apache.org/jira/browse/CAMEL-13027 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12980) Bundle in 'Active' State but Camel Context not initialized
[ https://issues.apache.org/jira/browse/CAMEL-12980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726768#comment-16726768 ] Claus Ibsen commented on CAMEL-12980: - No But there is some existing Camel tooling that can check your source code and report potential issues. See the maven tooling validate at: https://github.com/apache/camel/blob/master/tooling/maven/camel-maven-plugin/src/main/docs/camel-maven-plugin.adoc > Bundle in 'Active' State but Camel Context not initialized > -- > > Key: CAMEL-12980 > URL: https://issues.apache.org/jira/browse/CAMEL-12980 > Project: Camel > Issue Type: Bug > Components: camel-blueprint >Affects Versions: 2.20.1, 2.21.1 >Reporter: Xilai Dai >Assignee: Grzegorz Grzybek >Priority: Critical > Fix For: 2.22.3, 3.0.0, 2.24.0, 2.23.1 > > Attachments: blueprint.xml > > > The camel context can't get initialized when validation of the > RouteDefinition failed (e.g. typo in Uri or add an unsupported option in > Uri), but when deploy the blueprint, the CamelContext startup and then > shutdown, but the bundle status is still 'Active', only a > FailedToCreateRouteException ERROR is logged. > 318 │ Active │ 80 │ 0.0.0 │ blueprint.xml > Attached the simple blueprint.xml for reproduce it. > The expected behaviour is the bundle is in the 'Failure' status in this case. > The fix proposal from my side is, move the call of "this.maybeStart()" from > blueprintEvent() method to the constructor of the BlueprintCamelContext > class. then this kind of Route definition error can be processed during the > Blueprint "CREATING" phase. Currently, the start() is invoked after Blueprint > in "CREATED" phase. (I tested this fix locally and have the expected > 'Failure' bundle status) > (This issue is found in Camel 2.20.x, 2.21.x, but it may affects also on > master branch) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13026) Header written out on each message when marshalling
[
https://issues.apache.org/jira/browse/CAMEL-13026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726766#comment-16726766
]
Claus Ibsen commented on CAMEL-13026:
-
Ah okay this is expected as each message is independent and you write to an
existing file the message body as-is.
So you would need to do a content based router and check if the file is empty
and then include the header, and if the file is not empty, then do not include
the header.
> Header written out on each message when marshalling
> ---
>
> Key: CAMEL-13026
> URL: https://issues.apache.org/jira/browse/CAMEL-13026
> Project: Camel
> Issue Type: Improvement
> Components: camel-csv
>Reporter: Christian Ribeaud
>Priority: Major
>
> When *CSV* marshalling, the header is written out on each message.
> Additionally, {{CsvMarshaller}} is so opaque, making it difficult for
> customization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (CAMEL-13025) camel-core - File read lock changed - If file gets deleted then break out loop
[ https://issues.apache.org/jira/browse/CAMEL-13025?focusedWorklogId=177981=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-177981 ] ASF GitHub Bot logged work on CAMEL-13025: -- Author: ASF GitHub Bot Created on: 21/Dec/18 14:12 Start Date: 21/Dec/18 14:12 Worklog Time Spent: 10m Work Description: vgvineet4 opened a new pull request #2684: CAMEL-13025:FileDeletionWithZeroTimeout URL: https://github.com/apache/camel/pull/2684 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 177981) Time Spent: 0.5h (was: 20m) > camel-core - File read lock changed - If file gets deleted then break out loop > -- > > Key: CAMEL-13025 > URL: https://issues.apache.org/jira/browse/CAMEL-13025 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.18.5 >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 2.24.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > See SO > https://stackoverflow.com/questions/53865940/apache-camel-route-hangs-when-file-is-deleted-during-processing?noredirect=1#comment94587192_53865940 > So if the target file gets deleted during the check interval and you have > timeout = 0, then it will keep looping. So we should add a check if the file > still exists in the looping. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13027) Camel-AWS: Create a Camel-AWS EKS component
Andrea Cosentino created CAMEL-13027: Summary: Camel-AWS: Create a Camel-AWS EKS component Key: CAMEL-13027 URL: https://issues.apache.org/jira/browse/CAMEL-13027 Project: Camel Issue Type: New Feature Components: camel-aws Reporter: Andrea Cosentino Assignee: Andrea Cosentino Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-13026) Header written out on each message when marshalling
[
https://issues.apache.org/jira/browse/CAMEL-13026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726743#comment-16726743
]
Christian Ribeaud edited comment on CAMEL-13026 at 12/21/18 1:41 PM:
-
See *Unit* test referenced by [this|https://github.com/apache/camel/pull/2683]
pull request. We got _4_ lines (instead of _3_). On each append, the headers
are written out. Test is currently green, demonstrating the current behavior.
Following *Unit* test code:
{code:java}
package org.apache.camel.dataformat.csv;
import org.apache.camel.Exchange;
import org.apache.camel.Produce;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.RoutesBuilder;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TemporaryFolder;
import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.*;
import java.util.stream.Collectors;
/**
* Camel based test cases for {@link
org.apache.camel.dataformat.csv.CsvDataFormat}.
*/
public class CsvMarshalHeaderTest extends CamelTestSupport {
@Rule
public TemporaryFolder folder = new TemporaryFolder();
@Produce(uri = "direct:start")
private ProducerTemplate producerTemplate;
private File outputFile;
@Override
protected void doPreSetup() throws Exception {
outputFile = new File(folder.newFolder(), "output.csv");
}
@Test
public void testSendBody() throws IOException {
Map body = new LinkedHashMap<>();
body.put("first_name", "John");
body.put("last_name", "Doe");
String fileName = outputFile.getName();
assertEquals("output.csv", fileName);
producerTemplate.sendBodyAndHeader(body, Exchange.FILE_NAME, fileName);
body = new LinkedHashMap<>();
body.put("first_name", "Max");
body.put("last_name", "Mustermann");
producerTemplate.sendBodyAndHeader(body, Exchange.FILE_NAME, fileName);
List lines = Files.lines(Paths.get(outputFile.toURI()))
.filter(l -> l.trim().length() >
0).collect(Collectors.toList());
// We got twice the headers... :(
assertEquals(4, lines.size());
}
@Test
public void testSendBodyWithList() throws IOException {
List> body =
Collections.singletonList(Arrays.asList("John", "Doe"));
String fileName = outputFile.getName();
assertEquals("output.csv", fileName);
producerTemplate.sendBodyAndHeader(body, Exchange.FILE_NAME, fileName);
body = Collections.singletonList(Arrays.asList("Max", "Mustermann"));
producerTemplate.sendBodyAndHeader(body, Exchange.FILE_NAME, fileName);
List lines = Files.lines(Paths.get(outputFile.toURI()))
.filter(l -> l.trim().length() >
0).collect(Collectors.toList());
// We got twice the headers... :(
assertEquals(4, lines.size());
}
@Override
protected RoutesBuilder createRouteBuilder() {
return new RouteBuilder() {
@Override
public void configure() {
String uri =
String.format("file:%s?charset=utf-8=Append",
outputFile.getParentFile().getAbsolutePath());
from("direct:start").marshal(createCsvDataFormat()).to(uri);
}
};
}
private static CsvDataFormat createCsvDataFormat() {
CsvDataFormat dataFormat = new CsvDataFormat();
dataFormat.setDelimiter('\t');
dataFormat.setTrim(true);
dataFormat.setIgnoreSurroundingSpaces(true);
dataFormat.setHeader((String[]) Arrays.asList("first_name",
"last_name").toArray());
return dataFormat;
}
}
{code}
was (Author: christianr):
See *Unit* test referenced by [this|https://github.com/apache/camel/pull/2683]
pull request. We got _4_ lines (instead of _3_). On each append, the headers
are written out. Test is currently green, demonstrating the current behavior.
Following the Unit test code:
{code:java}
package org.apache.camel.dataformat.csv;
import org.apache.camel.Exchange;
import org.apache.camel.Produce;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.RoutesBuilder;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TemporaryFolder;
import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.*;
import java.util.stream.Collectors;
/**
* Camel based test cases for {@link
org.apache.camel.dataformat.csv.CsvDataFormat}.
*/
public class CsvMarshalHeaderTest extends CamelTestSupport {
@Rule
public TemporaryFolder folder = new TemporaryFolder();
@Produce(uri = "direct:start")
private
[jira] [Commented] (CAMEL-13026) Header written out on each message when marshalling
[
https://issues.apache.org/jira/browse/CAMEL-13026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726743#comment-16726743
]
Christian Ribeaud commented on CAMEL-13026:
---
See *Unit* test referenced by [this|https://github.com/apache/camel/pull/2683]
pull request. We got _4_ lines (instead of _3_). On each append, the headers
are written out. Test is currently green, demonstrating the current behavior.
Following the Unit test code:
{code:java}
package org.apache.camel.dataformat.csv;
import org.apache.camel.Exchange;
import org.apache.camel.Produce;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.RoutesBuilder;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TemporaryFolder;
import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.*;
import java.util.stream.Collectors;
/**
* Camel based test cases for {@link
org.apache.camel.dataformat.csv.CsvDataFormat}.
*/
public class CsvMarshalHeaderTest extends CamelTestSupport {
@Rule
public TemporaryFolder folder = new TemporaryFolder();
@Produce(uri = "direct:start")
private ProducerTemplate producerTemplate;
private File outputFile;
@Override
protected void doPreSetup() throws Exception {
outputFile = new File(folder.newFolder(), "output.csv");
}
@Test
public void testSendBody() throws IOException {
Map body = new LinkedHashMap<>();
body.put("first_name", "John");
body.put("last_name", "Doe");
String fileName = outputFile.getName();
assertEquals("output.csv", fileName);
producerTemplate.sendBodyAndHeader(body, Exchange.FILE_NAME, fileName);
body = new LinkedHashMap<>();
body.put("first_name", "Max");
body.put("last_name", "Mustermann");
producerTemplate.sendBodyAndHeader(body, Exchange.FILE_NAME, fileName);
List lines = Files.lines(Paths.get(outputFile.toURI()))
.filter(l -> l.trim().length() >
0).collect(Collectors.toList());
// We got twice the headers... :(
assertEquals(4, lines.size());
}
@Test
public void testSendBodyWithList() throws IOException {
List> body =
Collections.singletonList(Arrays.asList("John", "Doe"));
String fileName = outputFile.getName();
assertEquals("output.csv", fileName);
producerTemplate.sendBodyAndHeader(body, Exchange.FILE_NAME, fileName);
body = Collections.singletonList(Arrays.asList("Max", "Mustermann"));
producerTemplate.sendBodyAndHeader(body, Exchange.FILE_NAME, fileName);
List lines = Files.lines(Paths.get(outputFile.toURI()))
.filter(l -> l.trim().length() >
0).collect(Collectors.toList());
// We got twice the headers... :(
assertEquals(4, lines.size());
}
@Override
protected RoutesBuilder createRouteBuilder() {
return new RouteBuilder() {
@Override
public void configure() {
String uri =
String.format("file:%s?charset=utf-8=Append",
outputFile.getParentFile().getAbsolutePath());
from("direct:start").marshal(createCsvDataFormat()).to(uri);
}
};
}
private static CsvDataFormat createCsvDataFormat() {
CsvDataFormat dataFormat = new CsvDataFormat();
dataFormat.setDelimiter('\t');
dataFormat.setTrim(true);
dataFormat.setIgnoreSurroundingSpaces(true);
dataFormat.setHeader((String[]) Arrays.asList("first_name",
"last_name").toArray());
return dataFormat;
}
}
{code}
> Header written out on each message when marshalling
> ---
>
> Key: CAMEL-13026
> URL: https://issues.apache.org/jira/browse/CAMEL-13026
> Project: Camel
> Issue Type: Improvement
> Components: camel-csv
>Reporter: Christian Ribeaud
>Priority: Major
>
> When *CSV* marshalling, the header is written out on each message.
> Additionally, {{CsvMarshaller}} is so opaque, making it difficult for
> customization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13026) Header written out on each message when marshalling
[
https://issues.apache.org/jira/browse/CAMEL-13026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726741#comment-16726741
]
Claus Ibsen commented on CAMEL-13026:
-
Can you be more specific and provide an example or something, as this
description is too vague
> Header written out on each message when marshalling
> ---
>
> Key: CAMEL-13026
> URL: https://issues.apache.org/jira/browse/CAMEL-13026
> Project: Camel
> Issue Type: Improvement
> Components: camel-csv
>Reporter: Christian Ribeaud
>Priority: Major
>
> When *CSV* marshalling, the header is written out on each message.
> Additionally, {{CsvMarshaller}} is so opaque, making it difficult for
> customization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12982) Add support for alternative RAW() syntax
[
https://issues.apache.org/jira/browse/CAMEL-12982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726736#comment-16726736
]
Claus Ibsen commented on CAMEL-12982:
-
Ah a simpler just support double or triple with the same style as today:
- RAW((xxx))
- RAW(((xxx)))
> Add support for alternative RAW() syntax
>
>
> Key: CAMEL-12982
> URL: https://issues.apache.org/jira/browse/CAMEL-12982
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0, 2.24.0
>
>
> In some edge case you may have a password=foo)+bar which you want to use
> as-is. The + sign gets escaped and therefore you need to use RAW syntax. But
> the closing paranthesis is used the first one. And the parser is not always
> smart enough. But this can be tricky to improve as you can use =v as will
> and the parser thinks its a new option etc.
> So instead we should add an alternative syntax such as RAW{} where we use
> curly brackets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (CAMEL-13025) camel-core - File read lock changed - If file gets deleted then break out loop
[ https://issues.apache.org/jira/browse/CAMEL-13025?focusedWorklogId=177962=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-177962 ] ASF GitHub Bot logged work on CAMEL-13025: -- Author: ASF GitHub Bot Created on: 21/Dec/18 13:25 Start Date: 21/Dec/18 13:25 Worklog Time Spent: 10m Work Description: vgvineet4 opened a new pull request #2682: CAMEL-13025:PreventionFileReadLock URL: https://github.com/apache/camel/pull/2682 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 177962) Time Spent: 10m Remaining Estimate: 0h > camel-core - File read lock changed - If file gets deleted then break out loop > -- > > Key: CAMEL-13025 > URL: https://issues.apache.org/jira/browse/CAMEL-13025 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.18.5 >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 2.24.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See SO > https://stackoverflow.com/questions/53865940/apache-camel-route-hangs-when-file-is-deleted-during-processing?noredirect=1#comment94587192_53865940 > So if the target file gets deleted during the check interval and you have > timeout = 0, then it will keep looping. So we should add a check if the file > still exists in the looping. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13026) Header written out on each message when marshalling
Christian Ribeaud created CAMEL-13026:
-
Summary: Header written out on each message when marshalling
Key: CAMEL-13026
URL: https://issues.apache.org/jira/browse/CAMEL-13026
Project: Camel
Issue Type: Improvement
Components: camel-csv
Reporter: Christian Ribeaud
When *CSV* marshalling, the header is written out on each message.
Additionally, {{CsvMarshaller}} is so opaque, making it difficult for
customization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12982) Add support for alternative RAW() syntax
[
https://issues.apache.org/jira/browse/CAMEL-12982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726704#comment-16726704
]
Zoran Regvart edited comment on CAMEL-12982 at 12/21/18 12:50 PM:
--
Perhaps a good way to handle this would be to support syntax of RAW and three
consecutive characters to start and end the raw syntax, with the addition of
handling opening and closing braces, so all these would be valid:
* RAW\{\{\{{{...\}\}\}}}
* RAW[[[...]]]
* RAW(((...)))
* RAW```...```
* RAW\\\...\\\
* RAWaaa...aaa
* RAW(...) - the existing syntax
was (Author: zregvart):
Perhaps a good way to handle this would be to support syntax of RAW and three
consecutive characters to start and end the raw syntax, with the addition of
handling opening and closing braces, so all these would be valid:
* RAW\{{{...}}}
* RAW[[[...]]]
* RAW(((...)))
* RAW```...```
* RAW\\\...\\\
* RAWaaa...aaa
* RAW(...) - the existing syntax
> Add support for alternative RAW() syntax
>
>
> Key: CAMEL-12982
> URL: https://issues.apache.org/jira/browse/CAMEL-12982
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0, 2.24.0
>
>
> In some edge case you may have a password=foo)+bar which you want to use
> as-is. The + sign gets escaped and therefore you need to use RAW syntax. But
> the closing paranthesis is used the first one. And the parser is not always
> smart enough. But this can be tricky to improve as you can use =v as will
> and the parser thinks its a new option etc.
> So instead we should add an alternative syntax such as RAW{} where we use
> curly brackets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12982) Add support for alternative RAW() syntax
[
https://issues.apache.org/jira/browse/CAMEL-12982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726704#comment-16726704
]
Zoran Regvart commented on CAMEL-12982:
---
Perhaps a good way to handle this would be to support syntax of RAW and three
consecutive characters to start and end the raw syntax, with the addition of
handling opening and closing braces, so all these would be valid:
* RAW{...}
* RAW[[[...]]]
* RAW(((...)))
* RAW```...```
* RAW\\\...\\\
* RAWaaa...aaa
* RAW(...) - the existing syntax
> Add support for alternative RAW() syntax
>
>
> Key: CAMEL-12982
> URL: https://issues.apache.org/jira/browse/CAMEL-12982
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0, 2.24.0
>
>
> In some edge case you may have a password=foo)+bar which you want to use
> as-is. The + sign gets escaped and therefore you need to use RAW syntax. But
> the closing paranthesis is used the first one. And the parser is not always
> smart enough. But this can be tricky to improve as you can use =v as will
> and the parser thinks its a new option etc.
> So instead we should add an alternative syntax such as RAW{} where we use
> curly brackets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12982) Add support for alternative RAW() syntax
[
https://issues.apache.org/jira/browse/CAMEL-12982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726704#comment-16726704
]
Zoran Regvart edited comment on CAMEL-12982 at 12/21/18 12:50 PM:
--
Perhaps a good way to handle this would be to support syntax of RAW and three
consecutive characters to start and end the raw syntax, with the addition of
handling opening and closing braces, so all these would be valid:
* RAW\{{{...}}}
* RAW[[[...]]]
* RAW(((...)))
* RAW```...```
* RAW\\\...\\\
* RAWaaa...aaa
* RAW(...) - the existing syntax
was (Author: zregvart):
Perhaps a good way to handle this would be to support syntax of RAW and three
consecutive characters to start and end the raw syntax, with the addition of
handling opening and closing braces, so all these would be valid:
* RAW{...}
* RAW[[[...]]]
* RAW(((...)))
* RAW```...```
* RAW\\\...\\\
* RAWaaa...aaa
* RAW(...) - the existing syntax
> Add support for alternative RAW() syntax
>
>
> Key: CAMEL-12982
> URL: https://issues.apache.org/jira/browse/CAMEL-12982
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0, 2.24.0
>
>
> In some edge case you may have a password=foo)+bar which you want to use
> as-is. The + sign gets escaped and therefore you need to use RAW syntax. But
> the closing paranthesis is used the first one. And the parser is not always
> smart enough. But this can be tricky to improve as you can use =v as will
> and the parser thinks its a new option etc.
> So instead we should add an alternative syntax such as RAW{} where we use
> curly brackets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CAMEL-8913) Camel-Jclouds: Add Loadbalancer component
[ https://issues.apache.org/jira/browse/CAMEL-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reassigned CAMEL-8913: --- Assignee: (was: Andrea Cosentino) > Camel-Jclouds: Add Loadbalancer component > - > > Key: CAMEL-8913 > URL: https://issues.apache.org/jira/browse/CAMEL-8913 > Project: Camel > Issue Type: New Feature > Components: camel-jclouds >Reporter: Andrea Cosentino >Priority: Minor > Fix For: Future > > > We have to add Jclouds Loadbalancer support, since we already have support > for Blobstore service and compute service. > Even if the Loadbalancer documentation is not available in the same form of > Blobstore and Compute service, we can use Javadoc and code samples to develop > our component. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12948) Camel-Box: Download file version
[ https://issues.apache.org/jira/browse/CAMEL-12948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-12948: - Fix Version/s: 3.0.0 > Camel-Box: Download file version > > > Key: CAMEL-12948 > URL: https://issues.apache.org/jira/browse/CAMEL-12948 > Project: Camel > Issue Type: Bug > Components: camel-box >Affects Versions: 2.22.1 >Reporter: Vladimir >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.0.0, 2.24.0 > > > Provided endpoint is not functional. > Exception : Failed to resolve endpoint: box://files/downloadVersion due to: > No matching method for files/downloadVersion, with arguments []. > The issue is explained here : > [http://camel.465427.n5.nabble.com/Camel-box-download-file-version-td5825974.html] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-13013) Camel-AWS: Being able to create a subscription between an AWS SNS Topic and an AWS SQS Queue
[ https://issues.apache.org/jira/browse/CAMEL-13013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-13013. -- Resolution: Fixed > Camel-AWS: Being able to create a subscription between an AWS SNS Topic and > an AWS SQS Queue > > > Key: CAMEL-13013 > URL: https://issues.apache.org/jira/browse/CAMEL-13013 > Project: Camel > Issue Type: Task > Components: camel-aws >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.0.0 > > > https://aws.amazon.com/it/blogs/developer/subscribing-queues-to-topics/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (CAMEL-12982) Add support for alternative RAW() syntax
[
https://issues.apache.org/jira/browse/CAMEL-12982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-12982 started by Tadayoshi Sato.
--
> Add support for alternative RAW() syntax
>
>
> Key: CAMEL-12982
> URL: https://issues.apache.org/jira/browse/CAMEL-12982
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0, 2.24.0
>
>
> In some edge case you may have a password=foo)+bar which you want to use
> as-is. The + sign gets escaped and therefore you need to use RAW syntax. But
> the closing paranthesis is used the first one. And the parser is not always
> smart enough. But this can be tricky to improve as you can use =v as will
> and the parser thinks its a new option etc.
> So instead we should add an alternative syntax such as RAW{} where we use
> curly brackets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
