[jira] [Updated] (CAMEL-9258) camel-boon - Serializing/Deserializing Lists, Maps with camel-boon
[ https://issues.apache.org/jira/browse/CAMEL-9258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9258: --- Summary: camel-boon - Serializing/Deserializing Lists, Maps with camel-boon (was: Serializing/Deserializing Lists, Maps with camel-boon) > camel-boon - Serializing/Deserializing Lists, Maps with camel-boon > -- > > Key: CAMEL-9258 > URL: https://issues.apache.org/jira/browse/CAMEL-9258 > Project: Camel > Issue Type: Improvement > Components: camel-boon >Affects Versions: 2.16.0 >Reporter: Khaled Daham > > Any thoughts on how to add support for list, maps of pojos. > I did a simple patch that mimicked the behaviour of camel-jackson and added a > useList method on BoonDataFormat to tell the component that a List was to be > expected. > ps. camel-boon is missing as a choosable component when creating issues. .ds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9258) Serializing/Deserializing Lists, Maps with camel-boon
[ https://issues.apache.org/jira/browse/CAMEL-9258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9258: --- Environment: (was: Component camel-boon (missing in the list of components)) > Serializing/Deserializing Lists, Maps with camel-boon > - > > Key: CAMEL-9258 > URL: https://issues.apache.org/jira/browse/CAMEL-9258 > Project: Camel > Issue Type: Improvement > Components: camel-boon >Affects Versions: 2.16.0 >Reporter: Khaled Daham > > Any thoughts on how to add support for list, maps of pojos. > I did a simple patch that mimicked the behaviour of camel-jackson and added a > useList method on BoonDataFormat to tell the component that a List was to be > expected. > ps. camel-boon is missing as a choosable component when creating issues. .ds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9258) Serializing/Deserializing Lists, Maps with camel-boon
[ https://issues.apache.org/jira/browse/CAMEL-9258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14975897#comment-14975897 ] Claus Ibsen commented on CAMEL-9258: Sounds good a patch is welcome. > Serializing/Deserializing Lists, Maps with camel-boon > - > > Key: CAMEL-9258 > URL: https://issues.apache.org/jira/browse/CAMEL-9258 > Project: Camel > Issue Type: Improvement > Components: camel-boon >Affects Versions: 2.16.0 >Reporter: Khaled Daham > > Any thoughts on how to add support for list, maps of pojos. > I did a simple patch that mimicked the behaviour of camel-jackson and added a > useList method on BoonDataFormat to tell the component that a List was to be > expected. > ps. camel-boon is missing as a choosable component when creating issues. .ds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9259) enableTrace of the Main class doesn't work
[
https://issues.apache.org/jira/browse/CAMEL-9259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14975894#comment-14975894
]
Claus Ibsen commented on CAMEL-9259:
Yeah good catch, that fix seems correct to do it in the post process.
> enableTrace of the Main class doesn't work
> --
>
> Key: CAMEL-9259
> URL: https://issues.apache.org/jira/browse/CAMEL-9259
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.15.3
>Reporter: Charles Moulliard
>Priority: Minor
> Fix For: 2.17.0, 2.16.1, 2.15.5
>
>
> The enableTrace() method of the Camel Main class doesn't work.
> When we setup the code as such
> {code}
> public static void main(String... args) throws Exception {
> Main main = new Main();
> main.enableHangupSupport();
> main.addRouteBuilder(new MyRouteBuilder());
> main.enableTrace();
> main.run(args);
> {code}
> and launch the Main class, than the messages reported by the route in the log
> are not traced at all.
> If we debug, we can see that there is not CamelContext object when this
> method of the MainSupport class is called
> {code}
> public void enableTrace() {
> this.trace = true;
> for (CamelContext context : camelContexts) { // EMPTY
> context.setTracing(true);
> }
> }
> {code}
> The workaround is to enable the tracing within the route definition
> {code}
> public void configure() {
> getContext().setTracing(true);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9258) Serializing/Deserializing Lists, Maps with camel-boon
[ https://issues.apache.org/jira/browse/CAMEL-9258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9258: --- Component/s: camel-boon > Serializing/Deserializing Lists, Maps with camel-boon > - > > Key: CAMEL-9258 > URL: https://issues.apache.org/jira/browse/CAMEL-9258 > Project: Camel > Issue Type: Improvement > Components: camel-boon >Affects Versions: 2.16.0 >Reporter: Khaled Daham > > Any thoughts on how to add support for list, maps of pojos. > I did a simple patch that mimicked the behaviour of camel-jackson and added a > useList method on BoonDataFormat to tell the component that a List was to be > expected. > ps. camel-boon is missing as a choosable component when creating issues. .ds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9225) camel-exec - Enrich exception with stdout/stderr
[ https://issues.apache.org/jira/browse/CAMEL-9225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9225. Resolution: Fixed Assignee: Claus Ibsen Thanks Timo for the patch. I had to fix some checkstyle issues. You can run a check from mvn command line. See details at: http://camel.apache.org/building > camel-exec - Enrich exception with stdout/stderr > > > Key: CAMEL-9225 > URL: https://issues.apache.org/jira/browse/CAMEL-9225 > Project: Camel > Issue Type: Improvement > Components: camel-exec >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.17.0 > > Attachments: camel-9225.patch > > > So users can get access to the output that may have been written to > stdout/stderr during the processing. > See nabble > http://camel.465427.n5.nabble.com/Output-of-exec-used-for-exception-handling-to-enable-message-redelivery-tp5772641.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9259) enableTrace of the Main class doesn't work
[
https://issues.apache.org/jira/browse/CAMEL-9259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14975870#comment-14975870
]
Charles Moulliard commented on CAMEL-9259:
--
Fix required. Add the trace option if the boolean is true when the postProcess
method is called
{code}
protected void postProcessContext() throws Exception {
Map map = getCamelContextMap();
Set> entries = map.entrySet();
int size = entries.size();
for (Map.Entry entry : entries) {
String name = entry.getKey();
CamelContext camelContext = entry.getValue();
{code}
> enableTrace of the Main class doesn't work
> --
>
> Key: CAMEL-9259
> URL: https://issues.apache.org/jira/browse/CAMEL-9259
> Project: Camel
> Issue Type: Bug
> Components: camel-core, el-core
>Affects Versions: 2.15.3
>Reporter: Charles Moulliard
>
> The enableTrace() method of the Camel Main class doesn't work.
> When we setup the code as such
> {code}
> public static void main(String... args) throws Exception {
> Main main = new Main();
> main.enableHangupSupport();
> main.addRouteBuilder(new MyRouteBuilder());
> main.enableTrace();
> main.run(args);
> {code}
> and launch the Main class, than the messages reported by the route in the log
> are not traced at all.
> If we debug, we can see that there is not CamelContext object when this
> method of the MainSupport class is called
> {code}
> public void enableTrace() {
> this.trace = true;
> for (CamelContext context : camelContexts) { // EMPTY
> context.setTracing(true);
> }
> }
> {code}
> The workaround is to enable the tracing within the route definition
> {code}
> public void configure() {
> getContext().setTracing(true);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9259) enableTrace of the Main class doesn't work
[
https://issues.apache.org/jira/browse/CAMEL-9259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9259:
---
Fix Version/s: 2.15.5
2.16.1
2.17.0
> enableTrace of the Main class doesn't work
> --
>
> Key: CAMEL-9259
> URL: https://issues.apache.org/jira/browse/CAMEL-9259
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.15.3
>Reporter: Charles Moulliard
>Priority: Minor
> Fix For: 2.17.0, 2.16.1, 2.15.5
>
>
> The enableTrace() method of the Camel Main class doesn't work.
> When we setup the code as such
> {code}
> public static void main(String... args) throws Exception {
> Main main = new Main();
> main.enableHangupSupport();
> main.addRouteBuilder(new MyRouteBuilder());
> main.enableTrace();
> main.run(args);
> {code}
> and launch the Main class, than the messages reported by the route in the log
> are not traced at all.
> If we debug, we can see that there is not CamelContext object when this
> method of the MainSupport class is called
> {code}
> public void enableTrace() {
> this.trace = true;
> for (CamelContext context : camelContexts) { // EMPTY
> context.setTracing(true);
> }
> }
> {code}
> The workaround is to enable the tracing within the route definition
> {code}
> public void configure() {
> getContext().setTracing(true);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9259) enableTrace of the Main class doesn't work
[
https://issues.apache.org/jira/browse/CAMEL-9259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9259:
---
Component/s: (was: el-core)
> enableTrace of the Main class doesn't work
> --
>
> Key: CAMEL-9259
> URL: https://issues.apache.org/jira/browse/CAMEL-9259
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.15.3
>Reporter: Charles Moulliard
> Fix For: 2.17.0, 2.16.1, 2.15.5
>
>
> The enableTrace() method of the Camel Main class doesn't work.
> When we setup the code as such
> {code}
> public static void main(String... args) throws Exception {
> Main main = new Main();
> main.enableHangupSupport();
> main.addRouteBuilder(new MyRouteBuilder());
> main.enableTrace();
> main.run(args);
> {code}
> and launch the Main class, than the messages reported by the route in the log
> are not traced at all.
> If we debug, we can see that there is not CamelContext object when this
> method of the MainSupport class is called
> {code}
> public void enableTrace() {
> this.trace = true;
> for (CamelContext context : camelContexts) { // EMPTY
> context.setTracing(true);
> }
> }
> {code}
> The workaround is to enable the tracing within the route definition
> {code}
> public void configure() {
> getContext().setTracing(true);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9255) documentType not used for XPath predicates in XML DSL
[ https://issues.apache.org/jira/browse/CAMEL-9255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9255. Resolution: Fixed Assignee: Claus Ibsen Fix Version/s: 2.15.5 2.16.1 2.17.0 > documentType not used for XPath predicates in XML DSL > - > > Key: CAMEL-9255 > URL: https://issues.apache.org/jira/browse/CAMEL-9255 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.3, 2.15.3, 2.16.0 >Reporter: Stephan Siano >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.17.0, 2.16.1, 2.15.5 > > Attachments: > 0001-CAMEL-9255-documentType-not-used-for-XPath-predicate.patch > > > the documentType paramter is not used for XPath predicates in XML DSL. It > works for XPath expression and in Java DSL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9255) documentType not used for XPath predicates in XML DSL
[ https://issues.apache.org/jira/browse/CAMEL-9255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14975905#comment-14975905 ] Claus Ibsen commented on CAMEL-9255: Thanks for the patch. > documentType not used for XPath predicates in XML DSL > - > > Key: CAMEL-9255 > URL: https://issues.apache.org/jira/browse/CAMEL-9255 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.3, 2.15.3, 2.16.0 >Reporter: Stephan Siano >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.17.0, 2.16.1, 2.15.5 > > Attachments: > 0001-CAMEL-9255-documentType-not-used-for-XPath-predicate.patch > > > the documentType paramter is not used for XPath predicates in XML DSL. It > works for XPath expression and in Java DSL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9257) route stop/start doesn't work for camel-websocket producer
[
https://issues.apache.org/jira/browse/CAMEL-9257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976026#comment-14976026
]
Claus Ibsen commented on CAMEL-9257:
Try with suspend/resume to see if that works better.
> route stop/start doesn't work for camel-websocket producer
> --
>
> Key: CAMEL-9257
> URL: https://issues.apache.org/jira/browse/CAMEL-9257
> Project: Camel
> Issue Type: Bug
> Components: camel-websocket
>Affects Versions: 2.17.0
>Reporter: Tomohisa Igarashi
> Attachments: WebsocketProducerRouteRestartTest.java
>
>
> If you just add stopRoute()() at the beginning of
> WebsocketProducerRouteExampleTest#testWSHttpCall(), it fails with 404 not
> found.
> {code}
> java.util.concurrent.ExecutionException">java.util.concurrent.ExecutionException:
> java.lang.IllegalStateException: Invalid Status Code 404
> at
> com.ning.http.client.providers.netty.future.NettyResponseFuture.done(NettyResponseFuture.java:220)
> at
> com.ning.http.client.providers.netty.handler.WebSocketProtocol.handle(WebSocketProtocol.java:102)
> at
> com.ning.http.client.providers.netty.handler.Processor.messageReceived(Processor.java:88)
> ..
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9238) NPE while GenericFile.changeFileName
[
https://issues.apache.org/jira/browse/CAMEL-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976134#comment-14976134
]
Claus Ibsen commented on CAMEL-9238:
If your intention is to store the files in the parent directory then use .., eg
{code}
move=../input.bak/${date:now:MMdd}/${file:onlyname}
{code}
> NPE while GenericFile.changeFileName
>
>
> Key: CAMEL-9238
> URL: https://issues.apache.org/jira/browse/CAMEL-9238
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.15.2, 2.15.3
> Environment: Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM
> 25.60-b23
> System: Mac OS X version 10.10.5 running on x86_64; UTF-8; de_DE
>Reporter: Adi König
>
> If a relative file path is specified for the {{move}} or {{moveFailed}}
> Attribute of the file2 component, a NullPointerException is thrown while
> processing the onCompletion commit resp. rollback strategy.
> And because the processed file cannot be moved away, the processing is
> restarted again and so on...
> Wrong code line (GenericFile.java:203 in camel-core V2.15.3):
> {code:java}
> ObjectHelper.after(newFileName, newEndpointPath + File.separatorChar);
> {code}
> when {{newFileName}} and {{newEndpointPath}} are both relative paths.
> Stacktrace:
> {code:java}
> java.lang.NullPointerException
> at java.io.File.(File.java:277) ~[?:1.8.0_60]
> at
> org.apache.camel.component.file.GenericFile.changeFileName(GenericFile.java:207)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.strategy.GenericFileExpressionRenamer.renameFile(GenericFileExpressionRenamer.java:41)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:87)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:124)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:80)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:54)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:104)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:637)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:605)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:239)
> [camel-core-2.15.3.jar:2.15.3]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:106)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:439)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:175)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:174)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:101)
> [camel-core-2.15.3.jar:2.15.3]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_60]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_60]
> {code}
--
This message
[jira] [Created] (CAMEL-9260) Dataformat Apache Any23
Greg A. created CAMEL-9260: -- Summary: Dataformat Apache Any23 Key: CAMEL-9260 URL: https://issues.apache.org/jira/browse/CAMEL-9260 Project: Camel Issue Type: New Feature Reporter: Greg A. Priority: Minor Apache Any23 is the official Microformat lib. We could implements this lib as a Dataformat feature. I am working to understand what we could include for the first release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9260) Dataformat Apache Any23
[ https://issues.apache.org/jira/browse/CAMEL-9260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg A. updated CAMEL-9260: --- Description: Apache Any23 is the official Microformat lib. We could implements this lib as a Dataformat feature. I am working to understand what we could include for the first release. http://any23.apache.org/ http://any23.apache.org/getting-started.html was: Apache Any23 is the official Microformat lib. We could implements this lib as a Dataformat feature. I am working to understand what we could include for the first release. > Dataformat Apache Any23 > --- > > Key: CAMEL-9260 > URL: https://issues.apache.org/jira/browse/CAMEL-9260 > Project: Camel > Issue Type: New Feature >Reporter: Greg A. >Priority: Minor > > Apache Any23 is the official Microformat lib. > We could implements this lib as a Dataformat feature. > I am working to understand what we could include for the first release. > http://any23.apache.org/ > http://any23.apache.org/getting-started.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9261) Claim Check EIP - DataStore spi and out of the box stores
Claus Ibsen created CAMEL-9261: -- Summary: Claim Check EIP - DataStore spi and out of the box stores Key: CAMEL-9261 URL: https://issues.apache.org/jira/browse/CAMEL-9261 Project: Camel Issue Type: New Feature Components: camel-core, eip Reporter: Claus Ibsen Fix For: Future We should consider a ClaimCheckRepository API (or potentially allow to reuse aggregate repository) and add into the DSL to make it easy to store / claim. A blog about this http://www.javaprocess.com/2015/10/distributed-services-with-apache-camel-part2.html And the eip http://camel.apache.org/claim-check.html Likely the aggregator repository is the best suited to reuse/extend from as its to store with a key -> exchange. And have apis to remove as well. But we need to give it a bit more thought. The idea is for the implementations to make them reusable so we do not have to implement this again for JDBC, hazelcast and what else we have today for repositories. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9247) rest-dsl with api-doc should allow multiple rest's
[ https://issues.apache.org/jira/browse/CAMEL-9247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976112#comment-14976112 ] Jussi Nupponen commented on CAMEL-9247: --- Thanks for the fix! I updated your answer in SO to show the workaround. > rest-dsl with api-doc should allow multiple rest's > -- > > Key: CAMEL-9247 > URL: https://issues.apache.org/jira/browse/CAMEL-9247 > Project: Camel > Issue Type: Bug > Components: camel-core, rest >Affects Versions: 2.16.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.17.0, 2.16.1 > > > See SO > http://stackoverflow.com/questions/33291657/how-to-have-multiple-camel-rest-dsl-definitions-with-swagger > The api-doc endpoint should _merge_ multiple rest's together. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-9238) NPE while GenericFile.changeFileName
[
https://issues.apache.org/jira/browse/CAMEL-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-9238:
--
Assignee: Claus Ibsen
> NPE while GenericFile.changeFileName
>
>
> Key: CAMEL-9238
> URL: https://issues.apache.org/jira/browse/CAMEL-9238
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.15.2, 2.15.3
> Environment: Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM
> 25.60-b23
> System: Mac OS X version 10.10.5 running on x86_64; UTF-8; de_DE
>Reporter: Adi König
>Assignee: Claus Ibsen
> Fix For: 2.17.0, 2.16.1, 2.15.5
>
>
> If a relative file path is specified for the {{move}} or {{moveFailed}}
> Attribute of the file2 component, a NullPointerException is thrown while
> processing the onCompletion commit resp. rollback strategy.
> And because the processed file cannot be moved away, the processing is
> restarted again and so on...
> Wrong code line (GenericFile.java:203 in camel-core V2.15.3):
> {code:java}
> ObjectHelper.after(newFileName, newEndpointPath + File.separatorChar);
> {code}
> when {{newFileName}} and {{newEndpointPath}} are both relative paths.
> Stacktrace:
> {code:java}
> java.lang.NullPointerException
> at java.io.File.(File.java:277) ~[?:1.8.0_60]
> at
> org.apache.camel.component.file.GenericFile.changeFileName(GenericFile.java:207)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.strategy.GenericFileExpressionRenamer.renameFile(GenericFileExpressionRenamer.java:41)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:87)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:124)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:80)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:54)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:104)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:637)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:605)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:239)
> [camel-core-2.15.3.jar:2.15.3]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:106)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:439)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:175)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:174)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:101)
> [camel-core-2.15.3.jar:2.15.3]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_60]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_60]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9238) NPE while GenericFile.changeFileName
[
https://issues.apache.org/jira/browse/CAMEL-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9238:
---
Fix Version/s: 2.15.5
2.16.1
2.17.0
> NPE while GenericFile.changeFileName
>
>
> Key: CAMEL-9238
> URL: https://issues.apache.org/jira/browse/CAMEL-9238
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.15.2, 2.15.3
> Environment: Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM
> 25.60-b23
> System: Mac OS X version 10.10.5 running on x86_64; UTF-8; de_DE
>Reporter: Adi König
> Fix For: 2.17.0, 2.16.1, 2.15.5
>
>
> If a relative file path is specified for the {{move}} or {{moveFailed}}
> Attribute of the file2 component, a NullPointerException is thrown while
> processing the onCompletion commit resp. rollback strategy.
> And because the processed file cannot be moved away, the processing is
> restarted again and so on...
> Wrong code line (GenericFile.java:203 in camel-core V2.15.3):
> {code:java}
> ObjectHelper.after(newFileName, newEndpointPath + File.separatorChar);
> {code}
> when {{newFileName}} and {{newEndpointPath}} are both relative paths.
> Stacktrace:
> {code:java}
> java.lang.NullPointerException
> at java.io.File.(File.java:277) ~[?:1.8.0_60]
> at
> org.apache.camel.component.file.GenericFile.changeFileName(GenericFile.java:207)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.strategy.GenericFileExpressionRenamer.renameFile(GenericFileExpressionRenamer.java:41)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:87)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:124)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:80)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:54)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:104)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:637)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:605)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:239)
> [camel-core-2.15.3.jar:2.15.3]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:106)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:439)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:175)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:174)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:101)
> [camel-core-2.15.3.jar:2.15.3]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_60]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_60]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9225) camel-exec - Enrich exception with stdout/stderr
[ https://issues.apache.org/jira/browse/CAMEL-9225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976133#comment-14976133 ] Timo Brückner commented on CAMEL-9225: -- Oh sorry, will have a look at it next time ;) > camel-exec - Enrich exception with stdout/stderr > > > Key: CAMEL-9225 > URL: https://issues.apache.org/jira/browse/CAMEL-9225 > Project: Camel > Issue Type: Improvement > Components: camel-exec >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.17.0 > > Attachments: camel-9225.patch > > > So users can get access to the output that may have been written to > stdout/stderr during the processing. > See nabble > http://camel.465427.n5.nabble.com/Output-of-exec-used-for-exception-handling-to-enable-message-redelivery-tp5772641.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9259) enableTrace of the Main class doesn't work
Charles Moulliard created CAMEL-9259:
Summary: enableTrace of the Main class doesn't work
Key: CAMEL-9259
URL: https://issues.apache.org/jira/browse/CAMEL-9259
Project: Camel
Issue Type: Bug
Components: el-core, camel-core
Affects Versions: 2.15.3
Reporter: Charles Moulliard
The enableTrace() method of the Camel Main class doesn't work.
When we setup the code as such
{code}
public static void main(String... args) throws Exception {
Main main = new Main();
main.enableHangupSupport();
main.addRouteBuilder(new MyRouteBuilder());
main.enableTrace();
main.run(args);
{code}
and launch the Main class, than the messages reported by the route in the log
are not traced at all.
If we debug, we can see that there is not CamelContext object when this method
of the MainSupport class is called
{code}
public void enableTrace() {
this.trace = true;
for (CamelContext context : camelContexts) { // EMPTY
context.setTracing(true);
}
}
{code}
The workaround is to enable the tracing within the route definition
{code}
public void configure() {
getContext().setTracing(true);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9238) NPE while GenericFile.changeFileName
[
https://issues.apache.org/jira/browse/CAMEL-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9238.
Resolution: Fixed
Thanks for reporting.
> NPE while GenericFile.changeFileName
>
>
> Key: CAMEL-9238
> URL: https://issues.apache.org/jira/browse/CAMEL-9238
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.15.2, 2.15.3
> Environment: Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM
> 25.60-b23
> System: Mac OS X version 10.10.5 running on x86_64; UTF-8; de_DE
>Reporter: Adi König
>Assignee: Claus Ibsen
> Fix For: 2.17.0, 2.16.1, 2.15.5
>
>
> If a relative file path is specified for the {{move}} or {{moveFailed}}
> Attribute of the file2 component, a NullPointerException is thrown while
> processing the onCompletion commit resp. rollback strategy.
> And because the processed file cannot be moved away, the processing is
> restarted again and so on...
> Wrong code line (GenericFile.java:203 in camel-core V2.15.3):
> {code:java}
> ObjectHelper.after(newFileName, newEndpointPath + File.separatorChar);
> {code}
> when {{newFileName}} and {{newEndpointPath}} are both relative paths.
> Stacktrace:
> {code:java}
> java.lang.NullPointerException
> at java.io.File.(File.java:277) ~[?:1.8.0_60]
> at
> org.apache.camel.component.file.GenericFile.changeFileName(GenericFile.java:207)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.strategy.GenericFileExpressionRenamer.renameFile(GenericFileExpressionRenamer.java:41)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:87)
> ~[camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:124)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:80)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:54)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:104)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:637)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:605)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:239)
> [camel-core-2.15.3.jar:2.15.3]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:106)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:439)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:175)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:174)
> [camel-core-2.15.3.jar:2.15.3]
> at
> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:101)
> [camel-core-2.15.3.jar:2.15.3]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_60]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_60]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9259) enableTrace of the Main class doesn't work
[
https://issues.apache.org/jira/browse/CAMEL-9259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9259.
Resolution: Fixed
Assignee: Claus Ibsen
> enableTrace of the Main class doesn't work
> --
>
> Key: CAMEL-9259
> URL: https://issues.apache.org/jira/browse/CAMEL-9259
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.15.3
>Reporter: Charles Moulliard
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.17.0, 2.16.1, 2.15.5
>
>
> The enableTrace() method of the Camel Main class doesn't work.
> When we setup the code as such
> {code}
> public static void main(String... args) throws Exception {
> Main main = new Main();
> main.enableHangupSupport();
> main.addRouteBuilder(new MyRouteBuilder());
> main.enableTrace();
> main.run(args);
> {code}
> and launch the Main class, than the messages reported by the route in the log
> are not traced at all.
> If we debug, we can see that there is not CamelContext object when this
> method of the MainSupport class is called
> {code}
> public void enableTrace() {
> this.trace = true;
> for (CamelContext context : camelContexts) { // EMPTY
> context.setTracing(true);
> }
> }
> {code}
> The workaround is to enable the tracing within the route definition
> {code}
> public void configure() {
> getContext().setTracing(true);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9262) stopOnSuccess in Multicast, RecipientList
[
https://issues.apache.org/jira/browse/CAMEL-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976610#comment-14976610
]
Jyrki Ruuskanen commented on CAMEL-9262:
This seems to be possible with nested doTrys, but the nesting will quickly get
deep. Also, handled(false) in doCatch, which allows us to fall back to context
level error handler, seems to be deprecated.
{code:title=Nested doTry example}
.doTry()
.log("connecting #1")
.to("ftp://localhost;)
.doCatch(Exception.class)
.doTry()
.log("connecting #2")
.to("ftp://localhost/2;)
.doCatch(Exception.class)
.handled(false)
.end()
.end();
{code}
> stopOnSuccess in Multicast, RecipientList
> -
>
> Key: CAMEL-9262
> URL: https://issues.apache.org/jira/browse/CAMEL-9262
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Jyrki Ruuskanen
>Priority: Minor
>
> Let's say we have an endpoint where we should send a message and if sending
> fails there are a number of fallback endpoints we should try stopping after
> the first successful sending (=no exception thrown during sending).
> This sounds like a case for doTry..doCatch, but then we can't use
> defaultErrorHander and friends.
> I think it would look quite right if we could say .stopOnSuccess() or
> .shortCircuit() on multicast and have it stop after the first successful send.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-9262) stopOnSuccess in Multicast, RecipientList
[
https://issues.apache.org/jira/browse/CAMEL-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976610#comment-14976610
]
Jyrki Ruuskanen edited comment on CAMEL-9262 at 10/27/15 4:12 PM:
--
This seems to be possible with nested doTrys, but the nesting will quickly get
deep. Also, handled(false) in doCatch, which allows us to fall back to context
level error handler, seems to be deprecated.
{code:title=Nested doTry example}
.doTry()
.log("connecting #1")
.to("ftp://localhost;)
.doCatch(Exception.class)
.doTry()
.log("connecting #2")
.to("ftp://localhost/2;)
.doCatch(Exception.class)
.handled(false)
.end()
.end();
{code}
I guess handled(false) can be replaced with something like:
{{.throwException(new Exception("All producers failed"))}}, but it's not quite
the same.
was (Author: yuruki):
This seems to be possible with nested doTrys, but the nesting will quickly get
deep. Also, handled(false) in doCatch, which allows us to fall back to context
level error handler, seems to be deprecated.
{code:title=Nested doTry example}
.doTry()
.log("connecting #1")
.to("ftp://localhost;)
.doCatch(Exception.class)
.doTry()
.log("connecting #2")
.to("ftp://localhost/2;)
.doCatch(Exception.class)
.handled(false)
.end()
.end();
{code}
> stopOnSuccess in Multicast, RecipientList
> -
>
> Key: CAMEL-9262
> URL: https://issues.apache.org/jira/browse/CAMEL-9262
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Jyrki Ruuskanen
>Priority: Minor
>
> Let's say we have an endpoint where we should send a message and if sending
> fails there are a number of fallback endpoints we should try stopping after
> the first successful sending (=no exception thrown during sending).
> This sounds like a case for doTry..doCatch, but then we can't use
> defaultErrorHander and friends.
> I think it would look quite right if we could say .stopOnSuccess() or
> .shortCircuit() on multicast and have it stop after the first successful send.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-8241) Exec command failures using Java 8 on Unix
[ https://issues.apache.org/jira/browse/CAMEL-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976953#comment-14976953 ] Daniel Davis edited comment on CAMEL-8241 at 10/27/15 7:15 PM: --- I can confirm the same error on RHEL 6.x using ServiceMix 5.5.0, Camel 2.15.2 and Oracle Java 1.8_66. The source code for the exec component has the workaround described above. The stack trace is: 2015-10-27 14:39:58,830 | WARN | ora.apim.update] | EndpointMessageListener | 124 - org.apache.camel.camel-core - 2.15.2 | Execution of JMS message listener failed. Caused by: [org.apache.camel.component.exec.ExecException - Unable to execute command ExecCommand [args=[-f, staging/ID-oris-srv03-si-edu-51333-1445886844310-7-158], executable=rm, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false]] org.apache.camel.component.exec.ExecException: Unable to execute command ExecCommand [args=[-f, staging/ID-oris-srv03-si-edu-51333-1445886844310-7-158], executable=rm, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false] at org.apache.camel.component.exec.impl.DefaultExecCommandExecutor.execute(DefaultExecCommandExecutor.java:102)[230:org.apache.camel.camel-exec:2.15.2] at org.apache.camel.component.exec.ExecProducer.process(ExecProducer.java:53)[230:org.apache.camel.camel-exec:2.15.2] at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[124:org.apache.camel.camel-core:2.15.2] at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:448)[124:org.apache.camel.camel-core:2.15.2] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[124:org.apache.camel.camel-core:2.15.2] was (Author: davisda): I can confirm the same error on RHEL 6.x using ServiceMix 5.5.0, Camel 2.15.2 and Oracle Java 1.8_66. > Exec command failures using Java 8 on Unix > -- > > Key: CAMEL-8241 > URL: https://issues.apache.org/jira/browse/CAMEL-8241 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.0 > Environment: JDK 1.8 on Unix systems >Reporter: Dave Heath >Assignee: Claus Ibsen > Fix For: 2.14.2, 2.15.0 > > Attachments: CamelExecTest.java > > > I'm attaching a test case that shows an issue I've been running into with the > exec command since updating my environment to Java 8. It appears that I'm > running into a race condition where a stream is sometimes closed prematurely > before DefaultExecutor has a chance to close it, causing > DefaultExecCommandExecutor to throw and exit (even though the command did > execute properly). I've tested this against the updated version of > commons-exec as well just to make sure this hasn't somehow been fixed in that > library. > Please note that the attached test doesn't always fail; you may need to run > it a few times before the error will show up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-8241) Exec command failures using Java 8 on Unix
[ https://issues.apache.org/jira/browse/CAMEL-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976953#comment-14976953 ] Daniel Davis edited comment on CAMEL-8241 at 10/27/15 7:40 PM: --- I can confirm the same error on RHEL 6.x using ServiceMix 5.5.0, Camel 2.15.2 and Oracle Java 1.8_66. The source code for the exec component in branch camel-2.15.x has the workaround described above. It appears that the workaround is not in the ServiceMix distribution so I built 2.15.5.SNAPSHOT from the source and it seems to be working correctly. The stack trace is: 2015-10-27 14:39:58,830 | WARN | ora.apim.update] | EndpointMessageListener | 124 - org.apache.camel.camel-core - 2.15.2 | Execution of JMS message listener failed. Caused by: [org.apache.camel.component.exec.ExecException - Unable to execute command ExecCommand [args=[-f, staging/ID-oris-srv03-si-edu-51333-1445886844310-7-158], executable=rm, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false]] org.apache.camel.component.exec.ExecException: Unable to execute command ExecCommand [args=[-f, staging/ID-oris-srv03-si-edu-51333-1445886844310-7-158], executable=rm, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false] at org.apache.camel.component.exec.impl.DefaultExecCommandExecutor.execute(DefaultExecCommandExecutor.java:102)[230:org.apache.camel.camel-exec:2.15.2] at org.apache.camel.component.exec.ExecProducer.process(ExecProducer.java:53)[230:org.apache.camel.camel-exec:2.15.2] at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[124:org.apache.camel.camel-core:2.15.2] at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:448)[124:org.apache.camel.camel-core:2.15.2] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[124:org.apache.camel.camel-core:2.15.2] was (Author: davisda): I can confirm the same error on RHEL 6.x using ServiceMix 5.5.0, Camel 2.15.2 and Oracle Java 1.8_66. The source code for the exec component in branch camel-2.15.x has the workaround described above. The stack trace is: 2015-10-27 14:39:58,830 | WARN | ora.apim.update] | EndpointMessageListener | 124 - org.apache.camel.camel-core - 2.15.2 | Execution of JMS message listener failed. Caused by: [org.apache.camel.component.exec.ExecException - Unable to execute command ExecCommand [args=[-f, staging/ID-oris-srv03-si-edu-51333-1445886844310-7-158], executable=rm, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false]] org.apache.camel.component.exec.ExecException: Unable to execute command ExecCommand [args=[-f, staging/ID-oris-srv03-si-edu-51333-1445886844310-7-158], executable=rm, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false] at org.apache.camel.component.exec.impl.DefaultExecCommandExecutor.execute(DefaultExecCommandExecutor.java:102)[230:org.apache.camel.camel-exec:2.15.2] at org.apache.camel.component.exec.ExecProducer.process(ExecProducer.java:53)[230:org.apache.camel.camel-exec:2.15.2] at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[124:org.apache.camel.camel-core:2.15.2] at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:448)[124:org.apache.camel.camel-core:2.15.2] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[124:org.apache.camel.camel-core:2.15.2] > Exec command failures using Java 8 on Unix > -- > > Key: CAMEL-8241 > URL: https://issues.apache.org/jira/browse/CAMEL-8241 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.0 > Environment: JDK 1.8 on Unix systems >Reporter: Dave Heath >Assignee: Claus Ibsen > Fix For: 2.14.2, 2.15.0 > > Attachments: CamelExecTest.java > > > I'm attaching a test case that shows an issue I've been running into with the > exec command since updating my environment to Java 8. It appears that I'm > running into a race condition where a stream is sometimes closed prematurely > before DefaultExecutor has a chance to close it, causing > DefaultExecCommandExecutor to throw and exit (even though the command did > execute properly). I've tested this against the updated version of > commons-exec as well just to make sure this hasn't somehow been fixed in that > library. > Please note that the attached test doesn't always fail; you
[jira] [Commented] (CAMEL-8241) Exec command failures using Java 8 on Unix
[ https://issues.apache.org/jira/browse/CAMEL-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976953#comment-14976953 ] Daniel Davis commented on CAMEL-8241: - I can confirm the same error on RHEL 6.x using ServiceMix 5.5.0, Camel 2.15.2 and Oracle Java 1.8_66. > Exec command failures using Java 8 on Unix > -- > > Key: CAMEL-8241 > URL: https://issues.apache.org/jira/browse/CAMEL-8241 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.0 > Environment: JDK 1.8 on Unix systems >Reporter: Dave Heath >Assignee: Claus Ibsen > Fix For: 2.14.2, 2.15.0 > > Attachments: CamelExecTest.java > > > I'm attaching a test case that shows an issue I've been running into with the > exec command since updating my environment to Java 8. It appears that I'm > running into a race condition where a stream is sometimes closed prematurely > before DefaultExecutor has a chance to close it, causing > DefaultExecCommandExecutor to throw and exit (even though the command did > execute properly). I've tested this against the updated version of > commons-exec as well just to make sure this hasn't somehow been fixed in that > library. > Please note that the attached test doesn't always fail; you may need to run > it a few times before the error will show up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-8241) Exec command failures using Java 8 on Unix
[ https://issues.apache.org/jira/browse/CAMEL-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976953#comment-14976953 ] Daniel Davis edited comment on CAMEL-8241 at 10/27/15 7:18 PM: --- I can confirm the same error on RHEL 6.x using ServiceMix 5.5.0, Camel 2.15.2 and Oracle Java 1.8_66. The source code for the exec component in branch camel-2.15.x has the workaround described above. The stack trace is: 2015-10-27 14:39:58,830 | WARN | ora.apim.update] | EndpointMessageListener | 124 - org.apache.camel.camel-core - 2.15.2 | Execution of JMS message listener failed. Caused by: [org.apache.camel.component.exec.ExecException - Unable to execute command ExecCommand [args=[-f, staging/ID-oris-srv03-si-edu-51333-1445886844310-7-158], executable=rm, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false]] org.apache.camel.component.exec.ExecException: Unable to execute command ExecCommand [args=[-f, staging/ID-oris-srv03-si-edu-51333-1445886844310-7-158], executable=rm, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false] at org.apache.camel.component.exec.impl.DefaultExecCommandExecutor.execute(DefaultExecCommandExecutor.java:102)[230:org.apache.camel.camel-exec:2.15.2] at org.apache.camel.component.exec.ExecProducer.process(ExecProducer.java:53)[230:org.apache.camel.camel-exec:2.15.2] at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[124:org.apache.camel.camel-core:2.15.2] at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:448)[124:org.apache.camel.camel-core:2.15.2] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[124:org.apache.camel.camel-core:2.15.2] was (Author: davisda): I can confirm the same error on RHEL 6.x using ServiceMix 5.5.0, Camel 2.15.2 and Oracle Java 1.8_66. The source code for the exec component has the workaround described above. The stack trace is: 2015-10-27 14:39:58,830 | WARN | ora.apim.update] | EndpointMessageListener | 124 - org.apache.camel.camel-core - 2.15.2 | Execution of JMS message listener failed. Caused by: [org.apache.camel.component.exec.ExecException - Unable to execute command ExecCommand [args=[-f, staging/ID-oris-srv03-si-edu-51333-1445886844310-7-158], executable=rm, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false]] org.apache.camel.component.exec.ExecException: Unable to execute command ExecCommand [args=[-f, staging/ID-oris-srv03-si-edu-51333-1445886844310-7-158], executable=rm, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false] at org.apache.camel.component.exec.impl.DefaultExecCommandExecutor.execute(DefaultExecCommandExecutor.java:102)[230:org.apache.camel.camel-exec:2.15.2] at org.apache.camel.component.exec.ExecProducer.process(ExecProducer.java:53)[230:org.apache.camel.camel-exec:2.15.2] at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[124:org.apache.camel.camel-core:2.15.2] at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:448)[124:org.apache.camel.camel-core:2.15.2] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[124:org.apache.camel.camel-core:2.15.2] > Exec command failures using Java 8 on Unix > -- > > Key: CAMEL-8241 > URL: https://issues.apache.org/jira/browse/CAMEL-8241 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.0 > Environment: JDK 1.8 on Unix systems >Reporter: Dave Heath >Assignee: Claus Ibsen > Fix For: 2.14.2, 2.15.0 > > Attachments: CamelExecTest.java > > > I'm attaching a test case that shows an issue I've been running into with the > exec command since updating my environment to Java 8. It appears that I'm > running into a race condition where a stream is sometimes closed prematurely > before DefaultExecutor has a chance to close it, causing > DefaultExecCommandExecutor to throw and exit (even though the command did > execute properly). I've tested this against the updated version of > commons-exec as well just to make sure this hasn't somehow been fixed in that > library. > Please note that the attached test doesn't always fail; you may need to run > it a few times before the error will show up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9262) stopOnSuccess in Multicast, RecipientList
Jyrki Ruuskanen created CAMEL-9262: -- Summary: stopOnSuccess in Multicast, RecipientList Key: CAMEL-9262 URL: https://issues.apache.org/jira/browse/CAMEL-9262 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Jyrki Ruuskanen Priority: Minor Let's say we have an endpoint where we should send a message and if sending fails there are a number of fallback endpoints we should try stopping after the first successful sending (=no exception thrown during sending). This sounds like a case for doTry..doCatch, but then we can't use defaultErrorHander and friends. I think it would look quite right if we could say .stopOnSuccess() or .shortCircuit() on multicast and have it stop after the first successful send. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
