[jira] [Commented] (CAMEL-11427) camel-leveldb does not work on Solaris -- no native code library and no Java fallback
[ https://issues.apache.org/jira/browse/CAMEL-11427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064337#comment-16064337 ] Grzegorz Grzybek commented on CAMEL-11427: -- Improved logging [here|https://github.com/apache/camel/commit/2feec9d29308272dfe9f6c31331763f51ac0b892] in master Improved logging [here|https://github.com/apache/camel/commit/fc3647c210bceb9ca51e750cc7ccee06136b9c94] in camel-2.19.x Improved logging [here|https://github.com/apache/camel/commit/c25149322dd8db1a7d8c1f333ac4a7c80a1868ce] in camel-2.18.x > camel-leveldb does not work on Solaris -- no native code library and no Java > fallback > - > > Key: CAMEL-11427 > URL: https://issues.apache.org/jira/browse/CAMEL-11427 > Project: Camel > Issue Type: Bug > Components: camel-leveldb >Affects Versions: 2.17.7, 2.18.4, 2.19.0 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek > Fix For: 2.18.5, 2.19.1, 2.20.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11437) Bug using file endpoint probeContentType and preMove attributes together causes Exchange.FILE_CONTENT_TYPE to get dropped. (2.19.0)
[
https://issues.apache.org/jira/browse/CAMEL-11437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064332#comment-16064332
]
onder sezgin commented on CAMEL-11437:
--
well yes that s for sure that unnecessary multiple probing for the file content
is not what we would want, imho, too. however, what you secondly describe is
another issue and requires a bit more investigation,imho. initially and what
you reported was correct because probeXontentType is not passed right to
renameprocess strategy. and that s what we fixed. feel free to lg another jira.
we can look into it
> Bug using file endpoint probeContentType and preMove attributes together
> causes Exchange.FILE_CONTENT_TYPE to get dropped. (2.19.0)
>
>
> Key: CAMEL-11437
> URL: https://issues.apache.org/jira/browse/CAMEL-11437
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.19.0
>Reporter: David R. Hoffman
>Assignee: onder sezgin
>Priority: Minor
> Fix For: 2.19.2, 2.20.0
>
>
> We have a route:
> {quote}
> from("file:inbox?probeContentType=true&preMove=inprogress/$\{file:name}&renameUsingCopy=true")
> .transacted()
> .bean(MimeTypeParser.class, "populateFileTypeHeaderFields")
> .to("seda:somewhere")
> {quote}
>
> The probeContentType executes before preMove & renameUsingCopy and correctly
> sets the Exchange.FILE_CONTENT_TYPE header.
> The problem happens during the preMove & renameUsingCopy part where
> GenericFileExpressionRenamer calls the GenericFile method GenericFile
> copyFrom(GenericFile source).
> This "copy constructor" method does not copy the header
> Exchange.FILE_CONTENT_TYPE, nor does it preserve the value of the GenericFile
> probeContentType field.
> The class GenericFileRenameProcessStrategy calls GenericFileExpressionRenamer
> from the method begin() which in turn calls
> GenericFile.bindToExchange(Exchange exchange).
> GenericFile.bindToExchange() clears all "CamelFile*" headers and then calls
> GenericFile.populateHeaders(GenericFileMessage message) which would call
> Files.probeContentType(Path path) if the GenericFile probeContentType field
> weren't now false.
> When our route gets to the MimeTypeParser bean the "CamelFileContentType"
> header is lost, and that is what we are looking for.
> One work-around is to put something like this between .transacted() and the
> .bean():
> {quote}
> .process(exchange -> \{
> Path path = exchange.getIn().getBody(File.class).toPath();
> exchange.getIn().setHeader(Exchange.FILE_CONTENT_TYPE,
> Files.probeContentType(path));
> })
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11457) camel-atomix - No new leader when all nodes are killed forcefully
[
https://issues.apache.org/jira/browse/CAMEL-11457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064304#comment-16064304
]
Luca Burgazzoli commented on CAMEL-11457:
-
Yeah, looks like an issue with the persistent member which can be reproduced
outside camel.
Will add an option to use ephemeral members so we have a workaround till I
found a way to properly recover from this.
> camel-atomix - No new leader when all nodes are killed forcefully
> -
>
> Key: CAMEL-11457
> URL: https://issues.apache.org/jira/browse/CAMEL-11457
> Project: Camel
> Issue Type: Bug
> Components: camel-atomix
>Reporter: Nicola Ferraro
>Assignee: Luca Burgazzoli
>Priority: Minor
>
> I'm testing the leader service with the following scenario.
> Client mode with an external bootstrap service on Openshift. Using a
> spring-boot application.
> The service configuration is:
> {code}
> AtomixClusterClientService service = new AtomixClusterClientService();
> service.setId(InetAddress.getLocalHost().getHostName());
> service.setNodes(Collections.singletonList(new Address("atomix-boot-node",
> 8700)));
> {code}
> Steps:
> - I start 3 pods of the application, one is the leader.
> - Once started, I kill forcefully all three pods (calling
> "Runtime.getRuntime().halt(1)" from the JVM code) one after the other at
> short distance (few seconds)
> When all three pods become available again, the "leadershipChanged" callback
> is not called in any of the pods (waited > 1 hour). If I restart one pod
> after some time, that one become the leader. The other two pods receive the
> notification that there's a new leader.
> It seems that a timeout occurs, so that a new leader can be determined upon
> restart, but nobody participate in the election if pods are started before
> the timeout.
> [~lb] any idea?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CAMEL-11457) camel-atomix - No new leader when all nodes are killed forcefully
[
https://issues.apache.org/jira/browse/CAMEL-11457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Burgazzoli reassigned CAMEL-11457:
---
Assignee: Luca Burgazzoli
> camel-atomix - No new leader when all nodes are killed forcefully
> -
>
> Key: CAMEL-11457
> URL: https://issues.apache.org/jira/browse/CAMEL-11457
> Project: Camel
> Issue Type: Bug
> Components: camel-atomix
>Reporter: Nicola Ferraro
>Assignee: Luca Burgazzoli
>Priority: Minor
>
> I'm testing the leader service with the following scenario.
> Client mode with an external bootstrap service on Openshift. Using a
> spring-boot application.
> The service configuration is:
> {code}
> AtomixClusterClientService service = new AtomixClusterClientService();
> service.setId(InetAddress.getLocalHost().getHostName());
> service.setNodes(Collections.singletonList(new Address("atomix-boot-node",
> 8700)));
> {code}
> Steps:
> - I start 3 pods of the application, one is the leader.
> - Once started, I kill forcefully all three pods (calling
> "Runtime.getRuntime().halt(1)" from the JVM code) one after the other at
> short distance (few seconds)
> When all three pods become available again, the "leadershipChanged" callback
> is not called in any of the pods (waited > 1 hour). If I restart one pod
> after some time, that one become the leader. The other two pods receive the
> notification that there's a new leader.
> It seems that a timeout occurs, so that a new leader can be determined upon
> restart, but nobody participate in the election if pods are started before
> the timeout.
> [~lb] any idea?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11457) camel-atomix - No new leader when all nodes are killed forcefully
[
https://issues.apache.org/jira/browse/CAMEL-11457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064278#comment-16064278
]
Luca Burgazzoli commented on CAMEL-11457:
-
I need to digg into this a little bit more but the client nodes are "persistent
nodes" which requires them to explicit leave the cluster so halt may mess
things up.
> camel-atomix - No new leader when all nodes are killed forcefully
> -
>
> Key: CAMEL-11457
> URL: https://issues.apache.org/jira/browse/CAMEL-11457
> Project: Camel
> Issue Type: Bug
> Components: camel-atomix
>Reporter: Nicola Ferraro
>Priority: Minor
>
> I'm testing the leader service with the following scenario.
> Client mode with an external bootstrap service on Openshift. Using a
> spring-boot application.
> The service configuration is:
> {code}
> AtomixClusterClientService service = new AtomixClusterClientService();
> service.setId(InetAddress.getLocalHost().getHostName());
> service.setNodes(Collections.singletonList(new Address("atomix-boot-node",
> 8700)));
> {code}
> Steps:
> - I start 3 pods of the application, one is the leader.
> - Once started, I kill forcefully all three pods (calling
> "Runtime.getRuntime().halt(1)" from the JVM code) one after the other at
> short distance (few seconds)
> When all three pods become available again, the "leadershipChanged" callback
> is not called in any of the pods (waited > 1 hour). If I restart one pod
> after some time, that one become the leader. The other two pods receive the
> notification that there's a new leader.
> It seems that a timeout occurs, so that a new leader can be determined upon
> restart, but nobody participate in the election if pods are started before
> the timeout.
> [~lb] any idea?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11437) Bug using file endpoint probeContentType and preMove attributes together causes Exchange.FILE_CONTENT_TYPE to get dropped. (2.19.0)
[
https://issues.apache.org/jira/browse/CAMEL-11437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063861#comment-16063861
]
David R. Hoffman commented on CAMEL-11437:
--
[~onders]; [~davsclaus] - It seems to me that while this will fix the issue it
will also cause probeContentType to get called multiple times. It would appear
from the new code that it would get called anytime
GenericFileRenameProcessStrategy.begin() gets called, but also anytime
GenericFile.bindToExchange(Exchange exchange) gets called and
GenericFile.probeConentType == true. If the route attributes have
&probeContentType, &preMove and &move with this solution wouldn't
probeContentType get called three times per file on the FileEndpoint. Probing
a file's content time could be fairly costly from a computational point of
view, so I'd think you wouldn't want to do it more than absolutely necessarily
- imho.
> Bug using file endpoint probeContentType and preMove attributes together
> causes Exchange.FILE_CONTENT_TYPE to get dropped. (2.19.0)
>
>
> Key: CAMEL-11437
> URL: https://issues.apache.org/jira/browse/CAMEL-11437
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.19.0
>Reporter: David R. Hoffman
>Assignee: onder sezgin
>Priority: Minor
> Fix For: 2.19.2, 2.20.0
>
>
> We have a route:
> {quote}
> from("file:inbox?probeContentType=true&preMove=inprogress/$\{file:name}&renameUsingCopy=true")
> .transacted()
> .bean(MimeTypeParser.class, "populateFileTypeHeaderFields")
> .to("seda:somewhere")
> {quote}
>
> The probeContentType executes before preMove & renameUsingCopy and correctly
> sets the Exchange.FILE_CONTENT_TYPE header.
> The problem happens during the preMove & renameUsingCopy part where
> GenericFileExpressionRenamer calls the GenericFile method GenericFile
> copyFrom(GenericFile source).
> This "copy constructor" method does not copy the header
> Exchange.FILE_CONTENT_TYPE, nor does it preserve the value of the GenericFile
> probeContentType field.
> The class GenericFileRenameProcessStrategy calls GenericFileExpressionRenamer
> from the method begin() which in turn calls
> GenericFile.bindToExchange(Exchange exchange).
> GenericFile.bindToExchange() clears all "CamelFile*" headers and then calls
> GenericFile.populateHeaders(GenericFileMessage message) which would call
> Files.probeContentType(Path path) if the GenericFile probeContentType field
> weren't now false.
> When our route gets to the MimeTypeParser bean the "CamelFileContentType"
> header is lost, and that is what we are looking for.
> One work-around is to put something like this between .transacted() and the
> .bean():
> {quote}
> .process(exchange -> \{
> Path path = exchange.getIn().getBody(File.class).toPath();
> exchange.getIn().setHeader(Exchange.FILE_CONTENT_TYPE,
> Files.probeContentType(path));
> })
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (CAMEL-11445) Declare JEE namespace in beans.xml
[ https://issues.apache.org/jira/browse/CAMEL-11445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoran Regvart closed CAMEL-11445. - Resolution: Not A Problem > Declare JEE namespace in beans.xml > -- > > Key: CAMEL-11445 > URL: https://issues.apache.org/jira/browse/CAMEL-11445 > Project: Camel > Issue Type: Improvement > Components: camel-cdi >Affects Versions: 2.19.1 >Reporter: Zoran Regvart >Assignee: Zoran Regvart > Fix For: 2.20.0 > > > We seem to be missing namespace declaration in beans.xml. > Link to [user > forum|http://camel.465427.n5.nabble.com/microprofile-wildfly-swarm-camel-cdi-tp5805089.html] > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11445) Declare JEE namespace in beans.xml
[ https://issues.apache.org/jira/browse/CAMEL-11445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063504#comment-16063504 ] ASF GitHub Bot commented on CAMEL-11445: Github user zregvart closed the pull request at: https://github.com/apache/camel/pull/1782 > Declare JEE namespace in beans.xml > -- > > Key: CAMEL-11445 > URL: https://issues.apache.org/jira/browse/CAMEL-11445 > Project: Camel > Issue Type: Improvement > Components: camel-cdi >Affects Versions: 2.19.1 >Reporter: Zoran Regvart >Assignee: Zoran Regvart > Fix For: 2.20.0 > > > We seem to be missing namespace declaration in beans.xml. > Link to [user > forum|http://camel.465427.n5.nabble.com/microprofile-wildfly-swarm-camel-cdi-tp5805089.html] > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11457) camel-atomix - No new leader when all nodes are killed forcefully
Nicola Ferraro created CAMEL-11457:
--
Summary: camel-atomix - No new leader when all nodes are killed
forcefully
Key: CAMEL-11457
URL: https://issues.apache.org/jira/browse/CAMEL-11457
Project: Camel
Issue Type: Bug
Components: camel-atomix
Reporter: Nicola Ferraro
Priority: Minor
I'm testing the leader service with the following scenario.
Client mode with an external bootstrap service on Openshift. Using a
spring-boot application.
The service configuration is:
{code}
AtomixClusterClientService service = new AtomixClusterClientService();
service.setId(InetAddress.getLocalHost().getHostName());
service.setNodes(Collections.singletonList(new Address("atomix-boot-node",
8700)));
{code}
Steps:
- I start 3 pods of the application, one is the leader.
- Once started, I kill forcefully all three pods (calling
"Runtime.getRuntime().halt(1)" from the JVM code) one after the other at short
distance (few seconds)
When all three pods become available again, the "leadershipChanged" callback is
not called in any of the pods (waited > 1 hour). If I restart one pod after
some time, that one become the leader. The other two pods receive the
notification that there's a new leader.
It seems that a timeout occurs, so that a new leader can be determined upon
restart, but nobody participate in the election if pods are started before the
timeout.
[~lb] any idea?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11456) Make the camel-grpc component more cloud service friendly
[ https://issues.apache.org/jira/browse/CAMEL-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063460#comment-16063460 ] ASF GitHub Bot commented on CAMEL-11456: GitHub user dmvolod opened a pull request: https://github.com/apache/camel/pull/1787 CAMEL-11456: Make the camel-grpc component more cloud service friendly @nicolaferraro , could you please to look at this PR. I've changed an URI format to be component consumer and producer more cloud service friendly. Thank you. You can merge this pull request into a Git repository by running: $ git pull https://github.com/dmvolod/camel CAMEL-11456 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/1787.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1787 commit 3a175877e95e698967b4c3bce0426583348bc615 Author: Dmitry Volodin Date: 2017-06-26T17:20:59Z CAMEL-11456: Make the camel-grpc component more cloud service friendly > Make the camel-grpc component more cloud service friendly > - > > Key: CAMEL-11456 > URL: https://issues.apache.org/jira/browse/CAMEL-11456 > Project: Camel > Issue Type: Improvement > Components: camel-grpc >Reporter: Dmitry Volodin >Assignee: Dmitry Volodin >Priority: Minor > > Change an URI to be able expose and call component in cloud service > infrastructure easy > Now, the component URI is looks like grpc:host:port/service instead of > passing host and port via parameters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work started] (CAMEL-11456) Make the camel-grpc component more cloud service friendly
[ https://issues.apache.org/jira/browse/CAMEL-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-11456 started by Dmitry Volodin. -- > Make the camel-grpc component more cloud service friendly > - > > Key: CAMEL-11456 > URL: https://issues.apache.org/jira/browse/CAMEL-11456 > Project: Camel > Issue Type: Improvement > Components: camel-grpc >Reporter: Dmitry Volodin >Assignee: Dmitry Volodin >Priority: Minor > > Change an URI to be able expose and call component in cloud service > infrastructure easy > Now, the component URI is looks like grpc:host:port/service instead of > passing host and port via parameters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CAMEL-11456) Make the camel-grpc component more cloud service friendly
[ https://issues.apache.org/jira/browse/CAMEL-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Volodin reassigned CAMEL-11456: -- Assignee: Dmitry Volodin > Make the camel-grpc component more cloud service friendly > - > > Key: CAMEL-11456 > URL: https://issues.apache.org/jira/browse/CAMEL-11456 > Project: Camel > Issue Type: Improvement > Components: camel-grpc >Reporter: Dmitry Volodin >Assignee: Dmitry Volodin >Priority: Minor > > Change an URI to be able expose and call component in cloud service > infrastructure easy > Now, the component URI is looks like grpc:host:port/service instead of > passing host and port via parameters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11456) Make the camel-grpc component more cloud service friendly
Dmitry Volodin created CAMEL-11456: -- Summary: Make the camel-grpc component more cloud service friendly Key: CAMEL-11456 URL: https://issues.apache.org/jira/browse/CAMEL-11456 Project: Camel Issue Type: Improvement Components: camel-grpc Reporter: Dmitry Volodin Priority: Minor Change an URI to be able expose and call component in cloud service infrastructure easy Now, the component URI is looks like grpc:host:port/service instead of passing host and port via parameters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11325) Upgrade to Apache Spark 2.x
[ https://issues.apache.org/jira/browse/CAMEL-11325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063163#comment-16063163 ] ASF GitHub Bot commented on CAMEL-11325: GitHub user vrlgohel opened a pull request: https://github.com/apache/camel/pull/1786 [CAMEL-11325] Upgrade Apache Spark version to 2.1.1 Possible fix for https://issues.apache.org/jira/browse/CAMEL-11325 Upgraded Apache Spark version to 2.1.1. You can merge this pull request into a Git repository by running: $ git pull https://github.com/vrlgohel/camel-1 master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/1786.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1786 commit 777eafa28bed5d924edead624e9b934f7c08a9fc Author: None Date: 2017-06-26T14:15:37Z [CAMEL-11325] Upgrade Apache Spark version to 2.1.1 > Upgrade to Apache Spark 2.x > --- > > Key: CAMEL-11325 > URL: https://issues.apache.org/jira/browse/CAMEL-11325 > Project: Camel > Issue Type: Task > Components: camel-spark >Reporter: Claus Ibsen > Fix For: 2.20.0 > > > We currently are on 1.x, and there is a newer 2.x release out which we should > upgrade to. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11455) Automatic transform String to DBObject after previous conversion error
[ https://issues.apache.org/jira/browse/CAMEL-11455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrizio Spataro updated CAMEL-11455: - Attachment: jsonFormatterDisappear.zip The source code > Automatic transform String to DBObject after previous conversion error > -- > > Key: CAMEL-11455 > URL: https://issues.apache.org/jira/browse/CAMEL-11455 > Project: Camel > Issue Type: Bug > Components: camel-core, camel-mongodb, camel-mongodb3 >Affects Versions: 2.19.1 >Reporter: Fabrizio Spataro > Attachments: jsonFormatterDisappear.zip > > > Hello, > i found a bug. To reproduce it you can execute the code (see attachment file). > The bug is simple: > After an invalid conversion, the automatic String -> JSON transformation used > to put a document into MongoDB collection, fail! > Application flow: > # First document can be convert to JSON, Mongodb create a document (correct) > # Second document has an error, Mongodb cannot create a document (correct) > # Third document can be convert to JSON but Mongodb cannot create a document > into collection because automatic conversion is broken!!! (BUG) > Kings regards -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11455) Automatic transform String to DBObject after previous conversion error
Fabrizio Spataro created CAMEL-11455: Summary: Automatic transform String to DBObject after previous conversion error Key: CAMEL-11455 URL: https://issues.apache.org/jira/browse/CAMEL-11455 Project: Camel Issue Type: Bug Components: camel-core, camel-mongodb, camel-mongodb3 Affects Versions: 2.19.1 Reporter: Fabrizio Spataro Hello, i found a bug. To reproduce it you can execute the code (see attachment file). The bug is simple: After an invalid conversion, the automatic String -> JSON transformation used to put a document into MongoDB collection, fail! Application flow: # First document can be convert to JSON, Mongodb create a document (correct) # Second document has an error, Mongodb cannot create a document (correct) # Third document can be convert to JSON but Mongodb cannot create a document into collection because automatic conversion is broken!!! (BUG) Kings regards -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11454) camel-zipfile dataformat cannot remove successfully processed files
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Summary: camel-zipfile dataformat cannot remove successfully processed
files (was: camel-zipfile cannot remove successfully processed files)
> camel-zipfile dataformat cannot remove successfully processed files
> ---
>
> Key: CAMEL-11454
> URL: https://issues.apache.org/jira/browse/CAMEL-11454
> Project: Camel
> Issue Type: Bug
> Components: camel-zipfile
>Affects Versions: 2.18.3
> Environment: Windows 7 x64
>Reporter: Adrien PAILHES
>Assignee: onder sezgin
>Priority: Minor
>
> When creating a route as follows:
> {code:xml}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:camel="http://camel.apache.org/schema/spring";
> xmlns:context="http://www.springframework.org/schema/context";
> xmlns:util="http://www.springframework.org/schema/util";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
> http://www.springframework.org/schema/context
> http://www.springframework.org/schema/context/spring-context-4.2.xsd
> http://camel.apache.org/schema/spring
> http://camel.apache.org/schema/spring/camel-spring.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
>class="org.apache.camel.dataformat.zipfile.ZipFileDataFormat">
>
>
> http://camel.apache.org/schema/spring";
> streamCache="true">
>
>
>
>
> ${body}
>
>
>
>
>
>
>
> {code}
> the renaming of the file fails with
> {code}
> Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
> 'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
> file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
> {code}
> The file stays in input folder and gets processed over and over again.
> h2. Investigation
> Problem only occurs if:
> * you try to move the file at the end of the exchange (not with noop but with
> delete, for example)
> * if ZipFile dataformat is used (not with ZipSplitter)
> * if usingIterator is true (not if false and Zip file with 1 entry)
> It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
> {code}
> InputStream inputStream = inputMessage.getBody(InputStream.class);
> {code}
> will create a new input stream instead of using the one already opened:
> inputStream parameter when using
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
> This one won't be closed and you won't be able to release the resource unless
> you kill the process.
> So, two solutions:
> * close the inputStream parameter in
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
> ZipIterator constructor
> * use inputStream parameter instead of creating a new one when using
> dataformat (that's the implementation provided in the pull request)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-11454) camel-zipfile cannot remove successfully processed files
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Summary: camel-zipfile cannot remove successfully processed files (was:
camel-zipfile cannot move file after succesfully processed)
> camel-zipfile cannot remove successfully processed files
>
>
> Key: CAMEL-11454
> URL: https://issues.apache.org/jira/browse/CAMEL-11454
> Project: Camel
> Issue Type: Bug
> Components: camel-zipfile
>Affects Versions: 2.18.3
> Environment: Windows 7 x64
>Reporter: Adrien PAILHES
>Assignee: onder sezgin
>Priority: Minor
>
> When creating a route as follows:
> {code:xml}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:camel="http://camel.apache.org/schema/spring";
> xmlns:context="http://www.springframework.org/schema/context";
> xmlns:util="http://www.springframework.org/schema/util";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
> http://www.springframework.org/schema/context
> http://www.springframework.org/schema/context/spring-context-4.2.xsd
> http://camel.apache.org/schema/spring
> http://camel.apache.org/schema/spring/camel-spring.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
>class="org.apache.camel.dataformat.zipfile.ZipFileDataFormat">
>
>
> http://camel.apache.org/schema/spring";
> streamCache="true">
>
>
>
>
> ${body}
>
>
>
>
>
>
>
> {code}
> the renaming of the file fails with
> {code}
> Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
> 'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
> file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
> {code}
> The file stays in input folder and gets processed over and over again.
> h2. Investigation
> Problem only occurs if:
> * you try to move the file at the end of the exchange (not with noop but with
> delete, for example)
> * if ZipFile dataformat is used (not with ZipSplitter)
> * if usingIterator is true (not if false and Zip file with 1 entry)
> It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
> {code}
> InputStream inputStream = inputMessage.getBody(InputStream.class);
> {code}
> will create a new input stream instead of using the one already opened:
> inputStream parameter when using
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
> This one won't be closed and you won't be able to release the resource unless
> you kill the process.
> So, two solutions:
> * close the inputStream parameter in
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
> ZipIterator constructor
> * use inputStream parameter instead of creating a new one when using
> dataformat (that's the implementation provided in the pull request)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-11454) camel-zipfile cannot move file after succesfully processed
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Summary: camel-zipfile cannot move file after succesfully processed (was:
camel-zipfile cannot move file after succesful processing)
> camel-zipfile cannot move file after succesfully processed
> --
>
> Key: CAMEL-11454
> URL: https://issues.apache.org/jira/browse/CAMEL-11454
> Project: Camel
> Issue Type: Bug
> Components: camel-zipfile
>Affects Versions: 2.18.3
> Environment: Windows 7 x64
>Reporter: Adrien PAILHES
>Assignee: onder sezgin
>Priority: Minor
>
> When creating a route as follows:
> {code:xml}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:camel="http://camel.apache.org/schema/spring";
> xmlns:context="http://www.springframework.org/schema/context";
> xmlns:util="http://www.springframework.org/schema/util";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
> http://www.springframework.org/schema/context
> http://www.springframework.org/schema/context/spring-context-4.2.xsd
> http://camel.apache.org/schema/spring
> http://camel.apache.org/schema/spring/camel-spring.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
>class="org.apache.camel.dataformat.zipfile.ZipFileDataFormat">
>
>
> http://camel.apache.org/schema/spring";
> streamCache="true">
>
>
>
>
> ${body}
>
>
>
>
>
>
>
> {code}
> the renaming of the file fails with
> {code}
> Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
> 'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
> file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
> {code}
> The file stays in input folder and gets processed over and over again.
> h2. Investigation
> Problem only occurs if:
> * you try to move the file at the end of the exchange (not with noop but with
> delete, for example)
> * if ZipFile dataformat is used (not with ZipSplitter)
> * if usingIterator is true (not if false and Zip file with 1 entry)
> It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
> {code}
> InputStream inputStream = inputMessage.getBody(InputStream.class);
> {code}
> will create a new input stream instead of using the one already opened:
> inputStream parameter when using
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
> This one won't be closed and you won't be able to release the resource unless
> you kill the process.
> So, two solutions:
> * close the inputStream parameter in
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
> ZipIterator constructor
> * use inputStream parameter instead of creating a new one when using
> dataformat (that's the implementation provided in the pull request)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-11454) camel-zipfile cannot move file after succesful processing
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Summary: camel-zipfile cannot move file after succesful processing (was:
camel-zipfile does cannot move file after succesful processing)
> camel-zipfile cannot move file after succesful processing
> -
>
> Key: CAMEL-11454
> URL: https://issues.apache.org/jira/browse/CAMEL-11454
> Project: Camel
> Issue Type: Bug
> Components: camel-zipfile
>Affects Versions: 2.18.3
> Environment: Windows 7 x64
>Reporter: Adrien PAILHES
>Assignee: onder sezgin
>Priority: Minor
>
> When creating a route as follows:
> {code:xml}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:camel="http://camel.apache.org/schema/spring";
> xmlns:context="http://www.springframework.org/schema/context";
> xmlns:util="http://www.springframework.org/schema/util";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
> http://www.springframework.org/schema/context
> http://www.springframework.org/schema/context/spring-context-4.2.xsd
> http://camel.apache.org/schema/spring
> http://camel.apache.org/schema/spring/camel-spring.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
>class="org.apache.camel.dataformat.zipfile.ZipFileDataFormat">
>
>
> http://camel.apache.org/schema/spring";
> streamCache="true">
>
>
>
>
> ${body}
>
>
>
>
>
>
>
> {code}
> the renaming of the file fails with
> {code}
> Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
> 'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
> file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
> {code}
> The file stays in input folder and gets processed over and over again.
> h2. Investigation
> Problem only occurs if:
> * you try to move the file at the end of the exchange (not with noop but with
> delete, for example)
> * if ZipFile dataformat is used (not with ZipSplitter)
> * if usingIterator is true (not if false and Zip file with 1 entry)
> It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
> {code}
> InputStream inputStream = inputMessage.getBody(InputStream.class);
> {code}
> will create a new input stream instead of using the one already opened:
> inputStream parameter when using
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
> This one won't be closed and you won't be able to release the resource unless
> you kill the process.
> So, two solutions:
> * close the inputStream parameter in
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
> ZipIterator constructor
> * use inputStream parameter instead of creating a new one when using
> dataformat (that's the implementation provided in the pull request)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-11454) camel-zipfile does cannot move file after succesful processing
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Summary: camel-zipfile does cannot move file after succesful processing
(was: Camel ZipFile does cannot move file after succesful processing)
> camel-zipfile does cannot move file after succesful processing
> --
>
> Key: CAMEL-11454
> URL: https://issues.apache.org/jira/browse/CAMEL-11454
> Project: Camel
> Issue Type: Bug
> Components: camel-zipfile
>Affects Versions: 2.18.3
> Environment: Windows 7 x64
>Reporter: Adrien PAILHES
>Assignee: onder sezgin
>Priority: Minor
>
> When creating a route as follows:
> {code:xml}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:camel="http://camel.apache.org/schema/spring";
> xmlns:context="http://www.springframework.org/schema/context";
> xmlns:util="http://www.springframework.org/schema/util";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
> http://www.springframework.org/schema/context
> http://www.springframework.org/schema/context/spring-context-4.2.xsd
> http://camel.apache.org/schema/spring
> http://camel.apache.org/schema/spring/camel-spring.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
>class="org.apache.camel.dataformat.zipfile.ZipFileDataFormat">
>
>
> http://camel.apache.org/schema/spring";
> streamCache="true">
>
>
>
>
> ${body}
>
>
>
>
>
>
>
> {code}
> the renaming of the file fails with
> {code}
> Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
> 'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
> file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
> {code}
> The file stays in input folder and gets processed over and over again.
> h2. Investigation
> Problem only occurs if:
> * you try to move the file at the end of the exchange (not with noop but with
> delete, for example)
> * if ZipFile dataformat is used (not with ZipSplitter)
> * if usingIterator is true (not if false and Zip file with 1 entry)
> It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
> {code}
> InputStream inputStream = inputMessage.getBody(InputStream.class);
> {code}
> will create a new input stream instead of using the one already opened:
> inputStream parameter when using
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
> This one won't be closed and you won't be able to release the resource unless
> you kill the process.
> So, two solutions:
> * close the inputStream parameter in
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
> ZipIterator constructor
> * use inputStream parameter instead of creating a new one when using
> dataformat (that's the implementation provided in the pull request)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11454) Camel ZipFile does cannot move file after succesful processing
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062906#comment-16062906
]
ASF GitHub Bot commented on CAMEL-11454:
GitHub user adioss opened a pull request:
https://github.com/apache/camel/pull/1785
CAMEL-11454 use provided input stream when unmarshalling instead of
creating a new one
see JIRA ticket for more information (investigation part)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/adioss/camel CAMEL-11454
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/1785.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1785
commit e1e07cf886c4bea71b94a3f6c7170e7ad7ddb3b3
Author: Adrien PAILHES
Date: 2017-06-26T10:43:12Z
CAMEL-11454 use provided input stream when unmarshalling instead of
creating a new one
> Camel ZipFile does cannot move file after succesful processing
> --
>
> Key: CAMEL-11454
> URL: https://issues.apache.org/jira/browse/CAMEL-11454
> Project: Camel
> Issue Type: Bug
> Components: camel-zipfile
>Affects Versions: 2.18.3
> Environment: Windows 7 x64
>Reporter: Adrien PAILHES
>Assignee: onder sezgin
>Priority: Minor
>
> When creating a route as follows:
> {code:xml}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:camel="http://camel.apache.org/schema/spring";
> xmlns:context="http://www.springframework.org/schema/context";
> xmlns:util="http://www.springframework.org/schema/util";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
> http://www.springframework.org/schema/context
> http://www.springframework.org/schema/context/spring-context-4.2.xsd
> http://camel.apache.org/schema/spring
> http://camel.apache.org/schema/spring/camel-spring.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
>class="org.apache.camel.dataformat.zipfile.ZipFileDataFormat">
>
>
> http://camel.apache.org/schema/spring";
> streamCache="true">
>
>
>
>
> ${body}
>
>
>
>
>
>
>
> {code}
> the renaming of the file fails with
> {code}
> Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
> 'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
> file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
> {code}
> The file stays in input folder and gets processed over and over again.
> h2. Investigation
> Problem only occurs if:
> * you try to move the file at the end of the exchange (not with noop but with
> delete, for example)
> * if ZipFile dataformat is used (not with ZipSplitter)
> * if usingIterator is true (not if false and Zip file with 1 entry)
> It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
> {code}
> InputStream inputStream = inputMessage.getBody(InputStream.class);
> {code}
> will create a new input stream instead of using the one already opened:
> inputStream parameter when using
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
> This one won't be closed and you won't be able to release the resource unless
> you kill the process.
> So, two solutions:
> * close the inputStream parameter in
> org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
> ZipIterator constructor
> * use inputStream parameter instead of creating a new one when using
> dataformat (that's the implementation provided in the pull request)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-11454) Camel ZipFile does cannot move file after succesful processing
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Description:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h2. Investigation
Problem only occurs if:
* you try to move the file at the end of the exchange (not with noop but with
delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* is usingIterator is true (not if false and Zip file with 1 entry)
It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
{code}
InputStream inputStream = inputMessage.getBody(InputStream.class);
{code}
will create a new input stream instead of using the one already opened:
inputStream parameter when using
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
This one won't be closed and you won't be able to release the resource unless
you kill the process.
So, two solutions:
* close the inputStream parameter in
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
ZipIterator constructor
* use inputStream parameter instead of creating a new one when using dataformat
(that's the implementation provided in the pull request)
was:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h2. Investigation
Problem only occurs if:
* you try to move the file at the end of the exchange (so not with noop but
with delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* is usingIterator is true (not if false and Zip file with 1 entry)
It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
{code}
InputStream inputStream = inputMessage.getBody(InputStream.class);
{code}
will create a new input stream instead of using the one already opened:
inputStream parameter when using
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
This one won't be closed and you won't be able to release the resource unless
you kill the process.
So, two solutions:
* close the inputStream parameter in
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
ZipIterator constructor
* use inputStream parameter instead of creating a new one when using dataformat
(that's the implementation provided in the pull request)
> Camel ZipFile does cannot move file after succesful processing
>
[jira] [Updated] (CAMEL-11454) Camel ZipFile does cannot move file after succesful processing
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Description:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h2. Investigation
Problem only occurs if:
* you try to move the file at the end of the exchange (not with noop but with
delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* if usingIterator is true (not if false and Zip file with 1 entry)
It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
{code}
InputStream inputStream = inputMessage.getBody(InputStream.class);
{code}
will create a new input stream instead of using the one already opened:
inputStream parameter when using
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
This one won't be closed and you won't be able to release the resource unless
you kill the process.
So, two solutions:
* close the inputStream parameter in
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
ZipIterator constructor
* use inputStream parameter instead of creating a new one when using dataformat
(that's the implementation provided in the pull request)
was:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h2. Investigation
Problem only occurs if:
* you try to move the file at the end of the exchange (not with noop but with
delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* is usingIterator is true (not if false and Zip file with 1 entry)
It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
{code}
InputStream inputStream = inputMessage.getBody(InputStream.class);
{code}
will create a new input stream instead of using the one already opened:
inputStream parameter when using
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
This one won't be closed and you won't be able to release the resource unless
you kill the process.
So, two solutions:
* close the inputStream parameter in
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
ZipIterator constructor
* use inputStream parameter instead of creating a new one when using dataformat
(that's the implementation provided in the pull request)
> Camel ZipFile does cannot move file after succesful processing
> ---
[jira] [Updated] (CAMEL-11454) Camel ZipFile does cannot move file after succesful processing
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Description:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h3. Investigation
Problem only occur if:
* you try to move the file at the end of the exchange (so not with noop but
with delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* is usingIterator is true (not if false and Zip file with 1 entry)
It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
{code}
InputStream inputStream = inputMessage.getBody(InputStream.class);
{code}
will create a new input stream instead of using the one already opened:
inputStream parameter when using
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
This one won't be closed and you won't be able to release the resource unless
you kill the process.
So, two solutions:
* close the inputStream parameter in
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
ZipIterator constructor
* use inputStream parameter instead of creating a new one when using dataformat
(that's the implementation provided in the pull request)
was:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h3. Investigation
Problem only occur if:
* you try to move the file at the end of the exchange (so not with noop but
with delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* is usingIterator is true (not if false and Zip file with 1 entry)
> Camel ZipFile does cannot move file after succesful processing
> --
>
> Key: CAMEL-11454
> URL: https://issues.apache.org/jira/browse/CAMEL-11454
> Project: Camel
> Issue Type: Bug
> Components: camel-zipfile
>Affects Versions: 2.18.3
> Environment: Windows 7 x64
>Reporter: Adrien PAILHES
>Assignee: onder sezgin
>Priority: Minor
>
> When creating a route as follows:
> {code:xml}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:camel="http://camel.apache.org/schema/spring";
> xmlns:context="http://www.springframework.org/schema/context";
> xmlns:util="http://www.springframework.org/sche
[jira] [Updated] (CAMEL-11454) Camel ZipFile does cannot move file after succesful processing
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Description:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h2. Investigation
Problem only occur if:
* you try to move the file at the end of the exchange (so not with noop but
with delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* is usingIterator is true (not if false and Zip file with 1 entry)
It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
{code}
InputStream inputStream = inputMessage.getBody(InputStream.class);
{code}
will create a new input stream instead of using the one already opened:
inputStream parameter when using
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
This one won't be closed and you won't be able to release the resource unless
you kill the process.
So, two solutions:
* close the inputStream parameter in
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
ZipIterator constructor
* use inputStream parameter instead of creating a new one when using dataformat
(that's the implementation provided in the pull request)
was:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h3. Investigation
Problem only occur if:
* you try to move the file at the end of the exchange (so not with noop but
with delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* is usingIterator is true (not if false and Zip file with 1 entry)
It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
{code}
InputStream inputStream = inputMessage.getBody(InputStream.class);
{code}
will create a new input stream instead of using the one already opened:
inputStream parameter when using
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
This one won't be closed and you won't be able to release the resource unless
you kill the process.
So, two solutions:
* close the inputStream parameter in
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
ZipIterator constructor
* use inputStream parameter instead of creating a new one when using dataformat
(that's the implementation provided in the pull request)
> Camel ZipFile does cannot move file after succesful processing
> ---
[jira] [Updated] (CAMEL-11454) Camel ZipFile does cannot move file after succesful processing
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Description:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h2. Investigation
Problem only occurs if:
* you try to move the file at the end of the exchange (so not with noop but
with delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* is usingIterator is true (not if false and Zip file with 1 entry)
It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
{code}
InputStream inputStream = inputMessage.getBody(InputStream.class);
{code}
will create a new input stream instead of using the one already opened:
inputStream parameter when using
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
This one won't be closed and you won't be able to release the resource unless
you kill the process.
So, two solutions:
* close the inputStream parameter in
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
ZipIterator constructor
* use inputStream parameter instead of creating a new one when using dataformat
(that's the implementation provided in the pull request)
was:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h2. Investigation
Problem only occur if:
* you try to move the file at the end of the exchange (so not with noop but
with delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* is usingIterator is true (not if false and Zip file with 1 entry)
It's because in org.apache.camel.dataformat.zipfile.ZipIterator constructor:
{code}
InputStream inputStream = inputMessage.getBody(InputStream.class);
{code}
will create a new input stream instead of using the one already opened:
inputStream parameter when using
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal.
This one won't be closed and you won't be able to release the resource unless
you kill the process.
So, two solutions:
* close the inputStream parameter in
org.apache.camel.dataformat.zipfile.ZipFileDataFormat#unmarshal before using
ZipIterator constructor
* use inputStream parameter instead of creating a new one when using dataformat
(that's the implementation provided in the pull request)
> Camel ZipFile does cannot move file after succesful processing
> --
[jira] [Updated] (CAMEL-11454) Camel ZipFile does cannot move file after succesful processing
[
https://issues.apache.org/jira/browse/CAMEL-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien PAILHES updated CAMEL-11454:
---
Description:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
h3. Investigation
Problem only occur if:
* you try to move the file at the end of the exchange (so not with noop but
with delete, for example)
* if ZipFile dataformat is used (not with ZipSplitter)
* is usingIterator is true (not if false and Zip file with 1 entry)
was:
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
> Camel ZipFile does cannot move file after succesful processing
> --
>
> Key: CAMEL-11454
> URL: https://issues.apache.org/jira/browse/CAMEL-11454
> Project: Camel
> Issue Type: Bug
> Components: camel-zipfile
>Affects Versions: 2.18.3
> Environment: Windows 7 x64
>Reporter: Adrien PAILHES
>Assignee: onder sezgin
>Priority: Minor
>
> When creating a route as follows:
> {code:xml}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:camel="http://camel.apache.org/schema/spring";
> xmlns:context="http://www.springframework.org/schema/context";
> xmlns:util="http://www.springframework.org/schema/util";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
> http://www.springframework.org/schema/context
> http://www.springframework.org/schema/context/spring-context-4.2.xsd
> http://camel.apache.org/schema/spring
> http://camel.apache.org/schema/spring/camel-spring.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
>class="org.apache.camel.dataformat.zipfile.ZipFileDataFormat">
>
>
> http://camel.apache.org/schema/spring";
> streamCache="true">
>
>
>
>
> ${body}
>
>
>
>
>
>
>
> {code}
> the renaming of the file fails with
> {code}
> Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
> 'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
> file 'C:\camelTest\
[jira] [Created] (CAMEL-11454) Camel ZipFile does cannot move file after succesful processing
Adrien PAILHES created CAMEL-11454:
--
Summary: Camel ZipFile does cannot move file after succesful
processing
Key: CAMEL-11454
URL: https://issues.apache.org/jira/browse/CAMEL-11454
Project: Camel
Issue Type: Bug
Components: camel-zipfile
Affects Versions: 2.18.3
Environment: Windows 7 x64
Reporter: Adrien PAILHES
Assignee: onder sezgin
Priority: Minor
When creating a route as follows:
{code:xml}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:context="http://www.springframework.org/schema/context";
xmlns:util="http://www.springframework.org/schema/util";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.2.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd";>
http://camel.apache.org/schema/spring";
streamCache="true">
${body}
{code}
the renaming of the file fails with
{code}
Renaming file from 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' to
'C:\camelTest\in\.camel\20161201T0030Z_1D_BE00_EQ.zip' failed: Cannot delete
file 'C:\camelTest\in\20161201T0030Z_1D_BE00_EQ.zip' after copy succeeded
{code}
The file stays in input folder and gets processed over and over again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11450) Optimise - Calling a bean without method name defined can be optimised
[ https://issues.apache.org/jira/browse/CAMEL-11450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-11450. - Resolution: Fixed > Optimise - Calling a bean without method name defined can be optimised > -- > > Key: CAMEL-11450 > URL: https://issues.apache.org/jira/browse/CAMEL-11450 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.20.0 > > > We can optimise > org.apache.camel.component.bean.AbstractBeanProcessor#allowProcessor > Where we can pre-calculate the allow processor instead of doing this per > method call, and store the result of the processor type conversion. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CAMEL-11453) Fix camel-box feature
[
https://issues.apache.org/jira/browse/CAMEL-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino resolved CAMEL-11453.
--
Resolution: Fixed
> Fix camel-box feature
> -
>
> Key: CAMEL-11453
> URL: https://issues.apache.org/jira/browse/CAMEL-11453
> Project: Camel
> Issue Type: Bug
> Components: camel-box
>Affects Versions: 2.19.1
> Environment: Karaf 4.1.1 (latest at time of writing)
>Reporter: John Poth
>Assignee: Andrea Cosentino
> Fix For: 2.19.2, 2.20.0
>
>
> Some dependencies from mvn:com.box/box-java-sdk are missing in the camel-box
> feature. This happens when using the default authentication type
> (APP_USER_AUTHENTICATION). Below are some stack traces. I cam provide a PR:
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/bouncycastle/openssl/PEMParser
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.decryptPrivateKey(BoxDeveloperEditionAPIConnection.java:366)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.constructJWTAssertion(BoxDeveloperEditionAPIConnection.java:327)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.authenticate(BoxDeveloperEditionAPIConnection.java:237)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.tryRestoreUsingAccessTokenCache(BoxDeveloperEditionAPIConnection.java:305)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.getAppUserConnection(BoxDeveloperEditionAPIConnection.java:212)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/jose4j/lang/JoseException
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.ClassNotFoundException:
> com.eclipsesource.json.JsonObject not found by
> wrap_file__home_jpoth_.m2_repository_com_box_box-java-sdk_2.1.1_box-java-sdk-2.1.1.jar
> [413]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1550)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:79)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1958)
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> at com.box.sdk.BoxAPIConnection.authenticate(BoxAPIConnection.java:149)
> ~[?:?]
> at com.box.sdk.BoxAPIConnection.(BoxAPIConnection.java:98) ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createStandardAuthenticatedConnection(BoxConnectionHelper.java:202)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:91)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:203)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:3106)
> ~[?:?]
> at
> org.apache.camel.impl.Def
[jira] [Commented] (CAMEL-11453) Fix camel-box feature
[
https://issues.apache.org/jira/browse/CAMEL-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062811#comment-16062811
]
ASF GitHub Bot commented on CAMEL-11453:
Github user asfgit closed the pull request at:
https://github.com/apache/camel/pull/1784
> Fix camel-box feature
> -
>
> Key: CAMEL-11453
> URL: https://issues.apache.org/jira/browse/CAMEL-11453
> Project: Camel
> Issue Type: Bug
> Components: camel-box
>Affects Versions: 2.19.1
> Environment: Karaf 4.1.1 (latest at time of writing)
>Reporter: John Poth
>Assignee: Andrea Cosentino
> Fix For: 2.19.2, 2.20.0
>
>
> Some dependencies from mvn:com.box/box-java-sdk are missing in the camel-box
> feature. This happens when using the default authentication type
> (APP_USER_AUTHENTICATION). Below are some stack traces. I cam provide a PR:
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/bouncycastle/openssl/PEMParser
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.decryptPrivateKey(BoxDeveloperEditionAPIConnection.java:366)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.constructJWTAssertion(BoxDeveloperEditionAPIConnection.java:327)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.authenticate(BoxDeveloperEditionAPIConnection.java:237)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.tryRestoreUsingAccessTokenCache(BoxDeveloperEditionAPIConnection.java:305)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.getAppUserConnection(BoxDeveloperEditionAPIConnection.java:212)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/jose4j/lang/JoseException
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.ClassNotFoundException:
> com.eclipsesource.json.JsonObject not found by
> wrap_file__home_jpoth_.m2_repository_com_box_box-java-sdk_2.1.1_box-java-sdk-2.1.1.jar
> [413]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1550)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:79)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1958)
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> at com.box.sdk.BoxAPIConnection.authenticate(BoxAPIConnection.java:149)
> ~[?:?]
> at com.box.sdk.BoxAPIConnection.(BoxAPIConnection.java:98) ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createStandardAuthenticatedConnection(BoxConnectionHelper.java:202)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:91)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:203)
> ~[?:?]
> at
> org.
[jira] [Assigned] (CAMEL-11453) Fix camel-box feature
[
https://issues.apache.org/jira/browse/CAMEL-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino reassigned CAMEL-11453:
Assignee: Andrea Cosentino
> Fix camel-box feature
> -
>
> Key: CAMEL-11453
> URL: https://issues.apache.org/jira/browse/CAMEL-11453
> Project: Camel
> Issue Type: Bug
> Components: camel-box
>Affects Versions: 2.19.1
> Environment: Karaf 4.1.1 (latest at time of writing)
>Reporter: John Poth
>Assignee: Andrea Cosentino
> Fix For: 2.19.2, 2.20.0
>
>
> Some dependencies from mvn:com.box/box-java-sdk are missing in the camel-box
> feature. This happens when using the default authentication type
> (APP_USER_AUTHENTICATION). Below are some stack traces. I cam provide a PR:
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/bouncycastle/openssl/PEMParser
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.decryptPrivateKey(BoxDeveloperEditionAPIConnection.java:366)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.constructJWTAssertion(BoxDeveloperEditionAPIConnection.java:327)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.authenticate(BoxDeveloperEditionAPIConnection.java:237)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.tryRestoreUsingAccessTokenCache(BoxDeveloperEditionAPIConnection.java:305)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.getAppUserConnection(BoxDeveloperEditionAPIConnection.java:212)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/jose4j/lang/JoseException
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.ClassNotFoundException:
> com.eclipsesource.json.JsonObject not found by
> wrap_file__home_jpoth_.m2_repository_com_box_box-java-sdk_2.1.1_box-java-sdk-2.1.1.jar
> [413]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1550)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:79)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1958)
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> at com.box.sdk.BoxAPIConnection.authenticate(BoxAPIConnection.java:149)
> ~[?:?]
> at com.box.sdk.BoxAPIConnection.(BoxAPIConnection.java:98) ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createStandardAuthenticatedConnection(BoxConnectionHelper.java:202)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:91)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:203)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:3106)
> ~[?:?]
> at
> org.apache.
[jira] [Updated] (CAMEL-11453) Fix camel-box feature
[
https://issues.apache.org/jira/browse/CAMEL-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-11453:
-
Fix Version/s: 2.20.0
> Fix camel-box feature
> -
>
> Key: CAMEL-11453
> URL: https://issues.apache.org/jira/browse/CAMEL-11453
> Project: Camel
> Issue Type: Bug
> Components: camel-box
>Affects Versions: 2.19.1
> Environment: Karaf 4.1.1 (latest at time of writing)
>Reporter: John Poth
>Assignee: Andrea Cosentino
> Fix For: 2.19.2, 2.20.0
>
>
> Some dependencies from mvn:com.box/box-java-sdk are missing in the camel-box
> feature. This happens when using the default authentication type
> (APP_USER_AUTHENTICATION). Below are some stack traces. I cam provide a PR:
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/bouncycastle/openssl/PEMParser
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.decryptPrivateKey(BoxDeveloperEditionAPIConnection.java:366)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.constructJWTAssertion(BoxDeveloperEditionAPIConnection.java:327)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.authenticate(BoxDeveloperEditionAPIConnection.java:237)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.tryRestoreUsingAccessTokenCache(BoxDeveloperEditionAPIConnection.java:305)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.getAppUserConnection(BoxDeveloperEditionAPIConnection.java:212)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/jose4j/lang/JoseException
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.ClassNotFoundException:
> com.eclipsesource.json.JsonObject not found by
> wrap_file__home_jpoth_.m2_repository_com_box_box-java-sdk_2.1.1_box-java-sdk-2.1.1.jar
> [413]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1550)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:79)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1958)
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> at com.box.sdk.BoxAPIConnection.authenticate(BoxAPIConnection.java:149)
> ~[?:?]
> at com.box.sdk.BoxAPIConnection.(BoxAPIConnection.java:98) ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createStandardAuthenticatedConnection(BoxConnectionHelper.java:202)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:91)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:203)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:3106)
> ~[?:?]
> at
> org.apache.camel.impl.D
[jira] [Updated] (CAMEL-11453) Fix camel-box feature
[
https://issues.apache.org/jira/browse/CAMEL-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-11453:
-
Fix Version/s: 2.19.2
> Fix camel-box feature
> -
>
> Key: CAMEL-11453
> URL: https://issues.apache.org/jira/browse/CAMEL-11453
> Project: Camel
> Issue Type: Bug
> Components: camel-box
>Affects Versions: 2.19.1
> Environment: Karaf 4.1.1 (latest at time of writing)
>Reporter: John Poth
>Assignee: Andrea Cosentino
> Fix For: 2.19.2, 2.20.0
>
>
> Some dependencies from mvn:com.box/box-java-sdk are missing in the camel-box
> feature. This happens when using the default authentication type
> (APP_USER_AUTHENTICATION). Below are some stack traces. I cam provide a PR:
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/bouncycastle/openssl/PEMParser
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.decryptPrivateKey(BoxDeveloperEditionAPIConnection.java:366)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.constructJWTAssertion(BoxDeveloperEditionAPIConnection.java:327)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.authenticate(BoxDeveloperEditionAPIConnection.java:237)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.tryRestoreUsingAccessTokenCache(BoxDeveloperEditionAPIConnection.java:305)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.getAppUserConnection(BoxDeveloperEditionAPIConnection.java:212)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/jose4j/lang/JoseException
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.ClassNotFoundException:
> com.eclipsesource.json.JsonObject not found by
> wrap_file__home_jpoth_.m2_repository_com_box_box-java-sdk_2.1.1_box-java-sdk-2.1.1.jar
> [413]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1550)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:79)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1958)
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> at com.box.sdk.BoxAPIConnection.authenticate(BoxAPIConnection.java:149)
> ~[?:?]
> at com.box.sdk.BoxAPIConnection.(BoxAPIConnection.java:98) ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createStandardAuthenticatedConnection(BoxConnectionHelper.java:202)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:91)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:203)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:3106)
> ~[?:?]
> at
> org.apache.camel.impl.D
[jira] [Commented] (CAMEL-11453) Fix camel-box feature
[
https://issues.apache.org/jira/browse/CAMEL-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062807#comment-16062807
]
ASF GitHub Bot commented on CAMEL-11453:
GitHub user johnpoth opened a pull request:
https://github.com/apache/camel/pull/1784
CAMEL-11453 fix camel-box feature
https://issues.apache.org/jira/browse/CAMEL-11453
Thanks!
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/johnpoth/camel CAMEL-11453
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/1784.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1784
commit b612a50bcb3afa15da3b2b3da212fb038b0dbb7b
Author: jpoth
Date: 2017-06-26T08:54:37Z
CAMEL-11453 fix camel-box feature
> Fix camel-box feature
> -
>
> Key: CAMEL-11453
> URL: https://issues.apache.org/jira/browse/CAMEL-11453
> Project: Camel
> Issue Type: Bug
> Components: camel-box
>Affects Versions: 2.19.1
> Environment: Karaf 4.1.1 (latest at time of writing)
>Reporter: John Poth
>
> Some dependencies from mvn:com.box/box-java-sdk are missing in the camel-box
> feature. This happens when using the default authentication type
> (APP_USER_AUTHENTICATION). Below are some stack traces. I cam provide a PR:
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/bouncycastle/openssl/PEMParser
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.decryptPrivateKey(BoxDeveloperEditionAPIConnection.java:366)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.constructJWTAssertion(BoxDeveloperEditionAPIConnection.java:327)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.authenticate(BoxDeveloperEditionAPIConnection.java:237)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.tryRestoreUsingAccessTokenCache(BoxDeveloperEditionAPIConnection.java:305)
> ~[?:?]
> at
> com.box.sdk.BoxDeveloperEditionAPIConnection.getAppUserConnection(BoxDeveloperEditionAPIConnection.java:212)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
> ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/jose4j/lang/JoseException
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85)
> ~[?:?]
> at
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
> ~[?:?]
> {code}
> {code}
> Caused by: java.lang.ClassNotFoundException:
> com.eclipsesource.json.JsonObject not found by
> wrap_file__home_jpoth_.m2_repository_com_box_box-java-sdk_2.1.1_box-java-sdk-2.1.1.jar
> [413]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1550)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:79)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1958)
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> at com.box.sdk.BoxAPIConnection.authenticate(BoxAPIConnection.java:149)
> ~[?:?]
> at com.box.sdk.BoxAPIConnection.(BoxAPIConnection.java:98) ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createStandardAuthenticatedConnection(BoxConnectionHelper.java:202)
> ~[?:?]
> at
> org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:91)
> ~[?:?]
> at
> org.apache.camel.component.box.BoxComponent.doStart(BoxC
[jira] [Created] (CAMEL-11453) Fix camel-box feature
John Poth created CAMEL-11453:
-
Summary: Fix camel-box feature
Key: CAMEL-11453
URL: https://issues.apache.org/jira/browse/CAMEL-11453
Project: Camel
Issue Type: Bug
Components: camel-box
Affects Versions: 2.19.1
Environment: Karaf 4.1.1 (latest at time of writing)
Reporter: John Poth
Some dependencies from mvn:com.box/box-java-sdk are missing in the camel-box
feature. This happens when using the default authentication type
(APP_USER_AUTHENTICATION). Below are some stack traces. I cam provide a PR:
{code}
Caused by: java.lang.NoClassDefFoundError: org/bouncycastle/openssl/PEMParser
at
com.box.sdk.BoxDeveloperEditionAPIConnection.decryptPrivateKey(BoxDeveloperEditionAPIConnection.java:366)
~[?:?]
at
com.box.sdk.BoxDeveloperEditionAPIConnection.constructJWTAssertion(BoxDeveloperEditionAPIConnection.java:327)
~[?:?]
at
com.box.sdk.BoxDeveloperEditionAPIConnection.authenticate(BoxDeveloperEditionAPIConnection.java:237)
~[?:?]
at
com.box.sdk.BoxDeveloperEditionAPIConnection.tryRestoreUsingAccessTokenCache(BoxDeveloperEditionAPIConnection.java:305)
~[?:?]
at
com.box.sdk.BoxDeveloperEditionAPIConnection.getAppUserConnection(BoxDeveloperEditionAPIConnection.java:212)
~[?:?]
at
org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
~[?:?]
at
org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
~[?:?]
at
org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85) ~[?:?]
at
org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
at
org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
~[?:?]
at
org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
~[?:?]
at
org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
~[?:?]
{code}
{code}
Caused by: java.lang.NoClassDefFoundError: org/jose4j/lang/JoseException
at
org.apache.camel.component.box.internal.BoxConnectionHelper.createAppUserAuthenticatedConnection(BoxConnectionHelper.java:238)
~[?:?]
at
org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:89)
~[?:?]
at
org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85) ~[?:?]
at
org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
at
org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
~[?:?]
{code}
{code}
Caused by: java.lang.ClassNotFoundException: com.eclipsesource.json.JsonObject
not found by
wrap_file__home_jpoth_.m2_repository_com_box_box-java-sdk_2.1.1_box-java-sdk-2.1.1.jar
[413]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1550)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:79)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1958)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
at com.box.sdk.BoxAPIConnection.authenticate(BoxAPIConnection.java:149)
~[?:?]
at com.box.sdk.BoxAPIConnection.(BoxAPIConnection.java:98) ~[?:?]
at
org.apache.camel.component.box.internal.BoxConnectionHelper.createStandardAuthenticatedConnection(BoxConnectionHelper.java:202)
~[?:?]
at
org.apache.camel.component.box.internal.BoxConnectionHelper.createConnection(BoxConnectionHelper.java:91)
~[?:?]
at
org.apache.camel.component.box.BoxComponent.doStart(BoxComponent.java:85) ~[?:?]
at
org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
at
org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3555)
~[?:?]
at
org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:3561)
~[?:?]
at
org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3295)
~[?:?]
at
org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:203)
~[?:?]
at
org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:3106)
~[?:?]
at
org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:3102)
~[?:?]
at
org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:3125)
~[?:?]
at
org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:3102)
~[?:?]
at
org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
at
org.apache.camel.
[jira] [Updated] (CAMEL-11452) It should be possible to add extra headers for STOMP subscriptions
[ https://issues.apache.org/jira/browse/CAMEL-11452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-11452: Priority: Major (was: Critical) > It should be possible to add extra headers for STOMP subscriptions > --- > > Key: CAMEL-11452 > URL: https://issues.apache.org/jira/browse/CAMEL-11452 > Project: Camel > Issue Type: Improvement > Components: camel-stomp >Affects Versions: 2.19.1 >Reporter: Oliver Holzmann > > I need to subscribe to a stomp destination providing extra custom stomp > headers. This is currently not possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11452) It should be possible to add extra headers for STOMP subscriptions
[ https://issues.apache.org/jira/browse/CAMEL-11452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062647#comment-16062647 ] Claus Ibsen commented on CAMEL-11452: - You are welcome to work on a contribution http://camel.apache.org/contributing > It should be possible to add extra headers for STOMP subscriptions > --- > > Key: CAMEL-11452 > URL: https://issues.apache.org/jira/browse/CAMEL-11452 > Project: Camel > Issue Type: Improvement > Components: camel-stomp >Affects Versions: 2.19.1 >Reporter: Oliver Holzmann > > I need to subscribe to a stomp destination providing extra custom stomp > headers. This is currently not possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11452) It should be possible to add extra headers for STOMP subscriptions
Oliver Holzmann created CAMEL-11452: --- Summary: It should be possible to add extra headers for STOMP subscriptions Key: CAMEL-11452 URL: https://issues.apache.org/jira/browse/CAMEL-11452 Project: Camel Issue Type: Improvement Components: camel-stomp Affects Versions: 2.19.1 Reporter: Oliver Holzmann Priority: Critical I need to subscribe to a stomp destination providing extra custom stomp headers. This is currently not possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11451) Create camel component for Atomix v2
Luca Burgazzoli created CAMEL-11451: --- Summary: Create camel component for Atomix v2 Key: CAMEL-11451 URL: https://issues.apache.org/jira/browse/CAMEL-11451 Project: Camel Issue Type: New Feature Reporter: Luca Burgazzoli Assignee: Luca Burgazzoli Priority: Minor Fix For: Future Atomix will get a major refactoring in v2.0 (no ETA yet, should be released before EOY) so it may be nice to have a separate component instead of upgrading the existing one. See https://github.com/atomix/atomix/tree/2.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
