[jira] [Commented] (CAMEL-8142) camel-sql: store query result in header instead of body
[ https://issues.apache.org/jira/browse/CAMEL-8142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14247935#comment-14247935 ] Claus Ibsen commented on CAMEL-8142: enricher eip is a general solution that works with all components. But as you say it would require a bit more configuration and currently need to setup an aggregation strategty to only merge the result to a header. Though in a future Camel release we could look into making that use-case easier. > camel-sql: store query result in header instead of body > --- > > Key: CAMEL-8142 > URL: https://issues.apache.org/jira/browse/CAMEL-8142 > Project: Camel > Issue Type: New Feature > Components: camel-sql >Reporter: Daniel Pocock >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.15.0 > > > The SQL component stores query results in the message body, clobbering the > existing body. It would be nice to store the results of some queries in a > header. > This would be particularly useful when combined with outputType=SelectOne to > store a value such as a primary key / object ID into a header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8156) SNSClient should setup endpoint before creating the topic
Willem Jiang created CAMEL-8156: --- Summary: SNSClient should setup endpoint before creating the topic Key: CAMEL-8156 URL: https://issues.apache.org/jira/browse/CAMEL-8156 Project: Camel Issue Type: Bug Components: el-aws, camel-aws Affects Versions: 2.14.1, 2.13.3 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.13.4, 2.14.2, 2.15.0 When using camel-aws-sns endpoint, it always create the topic on the default endpoint. Here is the mailing thread about [it|http://camel.465427.n5.nabble.com/missing-region-property-in-aws-sns-component-tp4303687p5760674.html] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8157) camel-http - NPE after recent changes
Claus Ibsen created CAMEL-8157: -- Summary: camel-http - NPE after recent changes Key: CAMEL-8157 URL: https://issues.apache.org/jira/browse/CAMEL-8157 Project: Camel Issue Type: Bug Components: camel-http Reporter: Claus Ibsen Fix For: 2.15.0 I suspect its due a recent bugfix for something about deleting temp files. To reproduce then set in the camel-example-servlet-tomcat, and deploy the WAR to Tomcat and run it. You get a NPE then {code} java.lang.NullPointerException at org.apache.camel.component.http.HttpMessage.getEndpoint(HttpMessage.java:73) at org.apache.camel.component.http.HttpMessage.createBody(HttpMessage.java:66) at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:41) at org.apache.camel.processor.CamelInternalProcessor$StreamCachingAdvice.after(CamelInternalProcessor.java:758) at org.apache.camel.processor.CamelInternalProcessor$StreamCachingAdvice.after(CamelInternalProcessor.java:728) at org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:240) at org.apache.camel.processor.RedeliveryErrorHandler.deliverToFailureProcessor(RedeliveryErrorHandler.java:888) at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:364) at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:105) at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:87) at org.apache.camel.component.http.CamelServlet.service(CamelServlet.java:144) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:744) {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8158) Provide way to specify fields to patch in google drive endpoints
Jonathan Anstey created CAMEL-8158: -- Summary: Provide way to specify fields to patch in google drive endpoints Key: CAMEL-8158 URL: https://issues.apache.org/jira/browse/CAMEL-8158 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.2, 2.15.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8158) Provide way to specify fields to patch in google drive endpoints
[ https://issues.apache.org/jira/browse/CAMEL-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8158. Resolution: Fixed http://git-wip-us.apache.org/repos/asf/camel/commit/52b7b945 > Provide way to specify fields to patch in google drive endpoints > > > Key: CAMEL-8158 > URL: https://issues.apache.org/jira/browse/CAMEL-8158 > Project: Camel > Issue Type: Bug >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.14.2, 2.15.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8154) allow configuration of fallbackTimeout in BacklogDebugger
[ https://issues.apache.org/jira/browse/CAMEL-8154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-8154: --- Assignee: Willem Jiang > allow configuration of fallbackTimeout in BacklogDebugger > - > > Key: CAMEL-8154 > URL: https://issues.apache.org/jira/browse/CAMEL-8154 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Mark Ford >Assignee: Willem Jiang > > There is a hard coded timeout of 5 minutes for suspended exchanges. This is > reasonable for most cases but what if a user needs more time? I could imagine > it being really annoying if my IDE resumed my Java breakpoints after 5 > minutes automatically. > A simple getter/setter on the fallbackTimeout value would be nice. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8156) SNSClient should setup endpoint before creating the topic
[ https://issues.apache.org/jira/browse/CAMEL-8156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-8156. - Resolution: Fixed Applied the patch into camel master, camel-2.14.x and camel-2.13.x branches. > SNSClient should setup endpoint before creating the topic > - > > Key: CAMEL-8156 > URL: https://issues.apache.org/jira/browse/CAMEL-8156 > Project: Camel > Issue Type: Bug > Components: camel-aws, el-aws >Affects Versions: 2.13.3, 2.14.1 >Reporter: Willem Jiang >Assignee: Willem Jiang > Fix For: 2.13.4, 2.14.2, 2.15.0 > > > When using camel-aws-sns endpoint, it always create the topic on the default > endpoint. > Here is the mailing thread about > [it|http://camel.465427.n5.nabble.com/missing-region-property-in-aws-sns-component-tp4303687p5760674.html] > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8157) camel-http - NPE after recent changes
[ https://issues.apache.org/jira/browse/CAMEL-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-8157: --- Assignee: Willem Jiang > camel-http - NPE after recent changes > - > > Key: CAMEL-8157 > URL: https://issues.apache.org/jira/browse/CAMEL-8157 > Project: Camel > Issue Type: Bug > Components: camel-http >Reporter: Claus Ibsen >Assignee: Willem Jiang > Fix For: 2.15.0 > > > I suspect its due a recent bugfix for something about deleting temp files. > To reproduce then set in the > camel-example-servlet-tomcat, and deploy the WAR to Tomcat and run it. > You get a NPE then > {code} > java.lang.NullPointerException > at > org.apache.camel.component.http.HttpMessage.getEndpoint(HttpMessage.java:73) > at > org.apache.camel.component.http.HttpMessage.createBody(HttpMessage.java:66) > at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:41) > at > org.apache.camel.processor.CamelInternalProcessor$StreamCachingAdvice.after(CamelInternalProcessor.java:758) > at > org.apache.camel.processor.CamelInternalProcessor$StreamCachingAdvice.after(CamelInternalProcessor.java:728) > at > org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:240) > at > org.apache.camel.processor.RedeliveryErrorHandler.deliverToFailureProcessor(RedeliveryErrorHandler.java:888) > at > org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:364) > at > org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) > at > org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) > at > org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:105) > at > org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:87) > at > org.apache.camel.component.http.CamelServlet.service(CamelServlet.java:144) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) > at > org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655) > at > org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:744) > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8154) allow configuration of fallbackTimeout in BacklogDebugger
[ https://issues.apache.org/jira/browse/CAMEL-8154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-8154. - Resolution: Fixed Fix Version/s: 2.15.0 2.14.2 2.13.4 Applied the patch into camel master, camel-2.14.x and camel-2.13.x branches. > allow configuration of fallbackTimeout in BacklogDebugger > - > > Key: CAMEL-8154 > URL: https://issues.apache.org/jira/browse/CAMEL-8154 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Mark Ford >Assignee: Willem Jiang > Fix For: 2.13.4, 2.14.2, 2.15.0 > > > There is a hard coded timeout of 5 minutes for suspended exchanges. This is > reasonable for most cases but what if a user needs more time? I could imagine > it being really annoying if my IDE resumed my Java breakpoints after 5 > minutes automatically. > A simple getter/setter on the fallbackTimeout value would be nice. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8154) allow configuration of fallbackTimeout in BacklogDebugger
[ https://issues.apache.org/jira/browse/CAMEL-8154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249544#comment-14249544 ] Claus Ibsen commented on CAMEL-8154: The option also needs to be exposed as an read/write attribute on the mbean. > allow configuration of fallbackTimeout in BacklogDebugger > - > > Key: CAMEL-8154 > URL: https://issues.apache.org/jira/browse/CAMEL-8154 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Mark Ford >Assignee: Willem Jiang > Fix For: 2.13.4, 2.14.2, 2.15.0 > > > There is a hard coded timeout of 5 minutes for suspended exchanges. This is > reasonable for most cases but what if a user needs more time? I could imagine > it being really annoying if my IDE resumed my Java breakpoints after 5 > minutes automatically. > A simple getter/setter on the fallbackTimeout value would be nice. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-5842) camel-ldap - Allow to configure SSL using Camels SSL support
[ https://issues.apache.org/jira/browse/CAMEL-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249558#comment-14249558 ] Claus Ibsen commented on CAMEL-5842: Yeah you are welcome to update the wiki with the solution. > camel-ldap - Allow to configure SSL using Camels SSL support > > > Key: CAMEL-5842 > URL: https://issues.apache.org/jira/browse/CAMEL-5842 > Project: Camel > Issue Type: New Feature > Components: camel-ldap >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > Lets see if it would be possible for end users to use the great SSL support > in Camel to configure the camel-ldap component > See nabble > http://camel.465427.n5.nabble.com/LDAP-connection-via-SSL-tp5723224.html > And Camel SSL configuration > http://camel.apache.org/camel-configuration-utilities.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8153) Fix potential connection leak in StreamList mode
[ https://issues.apache.org/jira/browse/CAMEL-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8153: --- Issue Type: Bug (was: Improvement) > Fix potential connection leak in StreamList mode > > > Key: CAMEL-8153 > URL: https://issues.apache.org/jira/browse/CAMEL-8153 > Project: Camel > Issue Type: Bug > Components: camel-jdbc >Affects Versions: 2.14.0 > Environment: Linux, Apache Tomcat 7.0.41 >Reporter: Konstantin V. Salikhov >Priority: Minor > Fix For: 2.14.2, 2.15.0 > > Attachments: leakPatch.diff > > > When using camel-jdbc component with newly introduced StreamList mode I've > faced a 100% reproducible connection leak issue. > My investigation leads me to Tomcat connection pool implementation - it has > problem with returing current connection from Statement object - instead of > returning pool specific proxy it returns actual JDBC connection. > There is `statement.getConnection()` line in > `org.apache.camel.component.jdbc.ResultSetIterator` so in my particular > scenario things work like this: > 1) Camel borrows connection from Tomcat pool > 2) Camel leaves JDBC connection and ResultSet intact as we use StreamList > mode of camel-jdbc component > 3) Route processes resultset in streaming mode and completes successfully > 4) Camel tries to close connection, but due to connection pool implementation > issue it closes actual JDBC connection instead of returing it to the pool > 5) Actual JDBC connection is closed an connection pool is unaware of this > fact thinking it's still open and in use by application > It would be more error prone to pass proper connection object to > ResultSetIterator along with result set and not rely on > statement.getConnection() call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8153) Fix potential connection leak in StreamList mode
[ https://issues.apache.org/jira/browse/CAMEL-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8153: --- Fix Version/s: 2.15.0 2.14.2 > Fix potential connection leak in StreamList mode > > > Key: CAMEL-8153 > URL: https://issues.apache.org/jira/browse/CAMEL-8153 > Project: Camel > Issue Type: Improvement > Components: camel-jdbc >Affects Versions: 2.14.0 > Environment: Linux, Apache Tomcat 7.0.41 >Reporter: Konstantin V. Salikhov >Priority: Minor > Fix For: 2.14.2, 2.15.0 > > Attachments: leakPatch.diff > > > When using camel-jdbc component with newly introduced StreamList mode I've > faced a 100% reproducible connection leak issue. > My investigation leads me to Tomcat connection pool implementation - it has > problem with returing current connection from Statement object - instead of > returning pool specific proxy it returns actual JDBC connection. > There is `statement.getConnection()` line in > `org.apache.camel.component.jdbc.ResultSetIterator` so in my particular > scenario things work like this: > 1) Camel borrows connection from Tomcat pool > 2) Camel leaves JDBC connection and ResultSet intact as we use StreamList > mode of camel-jdbc component > 3) Route processes resultset in streaming mode and completes successfully > 4) Camel tries to close connection, but due to connection pool implementation > issue it closes actual JDBC connection instead of returing it to the pool > 5) Actual JDBC connection is closed an connection pool is unaware of this > fact thinking it's still open and in use by application > It would be more error prone to pass proper connection object to > ResultSetIterator along with result set and not rely on > statement.getConnection() call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8153) Fix potential connection leak in StreamList mode
[ https://issues.apache.org/jira/browse/CAMEL-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8153. Resolution: Fixed Assignee: Claus Ibsen Thanks for the detailed report and the patch. > Fix potential connection leak in StreamList mode > > > Key: CAMEL-8153 > URL: https://issues.apache.org/jira/browse/CAMEL-8153 > Project: Camel > Issue Type: Bug > Components: camel-jdbc >Affects Versions: 2.14.0 > Environment: Linux, Apache Tomcat 7.0.41 >Reporter: Konstantin V. Salikhov >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.14.2, 2.15.0 > > Attachments: leakPatch.diff > > > When using camel-jdbc component with newly introduced StreamList mode I've > faced a 100% reproducible connection leak issue. > My investigation leads me to Tomcat connection pool implementation - it has > problem with returing current connection from Statement object - instead of > returning pool specific proxy it returns actual JDBC connection. > There is `statement.getConnection()` line in > `org.apache.camel.component.jdbc.ResultSetIterator` so in my particular > scenario things work like this: > 1) Camel borrows connection from Tomcat pool > 2) Camel leaves JDBC connection and ResultSet intact as we use StreamList > mode of camel-jdbc component > 3) Route processes resultset in streaming mode and completes successfully > 4) Camel tries to close connection, but due to connection pool implementation > issue it closes actual JDBC connection instead of returing it to the pool > 5) Actual JDBC connection is closed an connection pool is unaware of this > fact thinking it's still open and in use by application > It would be more error prone to pass proper connection object to > ResultSetIterator along with result set and not rely on > statement.getConnection() call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8150) camel-hdfs sending message per chunk, not per file
[ https://issues.apache.org/jira/browse/CAMEL-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8150. Resolution: Fixed Fix Version/s: 2.15.0 2.14.2 Assignee: Claus Ibsen I added a note to the documentation about this. > camel-hdfs sending message per chunk, not per file > -- > > Key: CAMEL-8150 > URL: https://issues.apache.org/jira/browse/CAMEL-8150 > Project: Camel > Issue Type: Task > Components: camel-hdfs, documentation >Affects Versions: 2.14.0 >Reporter: Josef Ludvíček >Assignee: Claus Ibsen > Fix For: 2.14.2, 2.15.0 > > > When hdfs consumer picks orinary file, it sends message per data chunk. > Not message per file as one could expect. > In the docs it is mentioned only in option description, which can be > overlooked very easily. > It should be explicitly written in the beginning of the [component doc page | > https://camel.apache.org/hdfs2]. > Option description from docs > |chunkSize | 4096 | When reading a normal file, this is split into chunks > producing a message per chunk. | > Sample camel route (workaround could be to add {{?fileExist=Append}} to file > component) > {code:xml} > > > > > > > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8150) camel-hdfs sending message per chunk, not per file
[ https://issues.apache.org/jira/browse/CAMEL-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8150: --- Issue Type: Task (was: Improvement) > camel-hdfs sending message per chunk, not per file > -- > > Key: CAMEL-8150 > URL: https://issues.apache.org/jira/browse/CAMEL-8150 > Project: Camel > Issue Type: Task > Components: camel-hdfs, documentation >Affects Versions: 2.14.0 >Reporter: Josef Ludvíček > > When hdfs consumer picks orinary file, it sends message per data chunk. > Not message per file as one could expect. > In the docs it is mentioned only in option description, which can be > overlooked very easily. > It should be explicitly written in the beginning of the [component doc page | > https://camel.apache.org/hdfs2]. > Option description from docs > |chunkSize | 4096 | When reading a normal file, this is split into chunks > producing a message per chunk. | > Sample camel route (workaround could be to add {{?fileExist=Append}} to file > component) > {code:xml} > > > > > > > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8145) Mina Consumer doesn't send the message back if the response is set on in message
[ https://issues.apache.org/jira/browse/CAMEL-8145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8145. Resolution: Fixed > Mina Consumer doesn't send the message back if the response is set on in > message > > > Key: CAMEL-8145 > URL: https://issues.apache.org/jira/browse/CAMEL-8145 > Project: Camel > Issue Type: Improvement > Components: camel-mina, camel-mina2 >Reporter: Willem Jiang >Assignee: Willem Jiang > Fix For: 2.13.4, 2.14.2, 2.15.0 > > > Mina should send the message back if the user just set the in message body. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8129) XAdES BES/EPES for XML Signature Signer
[ https://issues.apache.org/jira/browse/CAMEL-8129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-8129: -- Assignee: Claus Ibsen > XAdES BES/EPES for XML Signature Signer > --- > > Key: CAMEL-8129 > URL: https://issues.apache.org/jira/browse/CAMEL-8129 > Project: Camel > Issue Type: Improvement > Components: camel-xmlsecurity >Reporter: Franz Forsthofer >Assignee: Claus Ibsen > Fix For: 2.15.0 > > Attachments: 0001-XAdES-BES-EPES-for-XML-Signature-signer.patch > > > XAdES is a standard from the European Telecomunications Standars Institute > (ETSI). This standard is based on XML Signature and defines enhancements > which are placed into the 'SignatureProperties' element of the XML Signature. > You can find the latest version of the standard in > http://www.etsi.org/deliver/etsi_ts%5C101900_101999%5C101903%5C01.04.02_60%5Cts_101903v010402p.pdf. > The attached patch implements the form Basic Electronic Signature (XAdES-BES) > and the form Explicit Policy based Electronic Signature (XAdES-EPES) for the > XML Signature signer endpoint. It supports all current versions of XAdES > (1.4.2, 1.4.1, 1.3.2., 1.2.2, 1.1.1). > The implementation has the following limitations: > - No support for 'QualifyingPropertiesReference' (see section 6.3.2 of spec). > - No support for Transforms element contained in SignaturePolicyId element > contained in SignaturePolicyIdentifier > - No support of CounterSignature element > - AllDataObjectsTimeStamp element is not supported > - IndividualDataObjectsTimeStamp element is not supported > It is possible to overcome the limitations in a later improvement. > I can do the wiki-update. > Regards Franz Forsthofer > - > SAP SE > e-mail: franz.forstho...@sap.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8129) XAdES BES/EPES for XML Signature Signer
[ https://issues.apache.org/jira/browse/CAMEL-8129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249571#comment-14249571 ] Claus Ibsen commented on CAMEL-8129: Thanks a lot Franz. I have merged the code to master branch. You are very welcome to update the documentation. > XAdES BES/EPES for XML Signature Signer > --- > > Key: CAMEL-8129 > URL: https://issues.apache.org/jira/browse/CAMEL-8129 > Project: Camel > Issue Type: Improvement > Components: camel-xmlsecurity >Reporter: Franz Forsthofer >Assignee: Claus Ibsen > Fix For: 2.15.0 > > Attachments: 0001-XAdES-BES-EPES-for-XML-Signature-signer.patch > > > XAdES is a standard from the European Telecomunications Standars Institute > (ETSI). This standard is based on XML Signature and defines enhancements > which are placed into the 'SignatureProperties' element of the XML Signature. > You can find the latest version of the standard in > http://www.etsi.org/deliver/etsi_ts%5C101900_101999%5C101903%5C01.04.02_60%5Cts_101903v010402p.pdf. > The attached patch implements the form Basic Electronic Signature (XAdES-BES) > and the form Explicit Policy based Electronic Signature (XAdES-EPES) for the > XML Signature signer endpoint. It supports all current versions of XAdES > (1.4.2, 1.4.1, 1.3.2., 1.2.2, 1.1.1). > The implementation has the following limitations: > - No support for 'QualifyingPropertiesReference' (see section 6.3.2 of spec). > - No support for Transforms element contained in SignaturePolicyId element > contained in SignaturePolicyIdentifier > - No support of CounterSignature element > - AllDataObjectsTimeStamp element is not supported > - IndividualDataObjectsTimeStamp element is not supported > It is possible to overcome the limitations in a later improvement. > I can do the wiki-update. > Regards Franz Forsthofer > - > SAP SE > e-mail: franz.forstho...@sap.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7794) Topics support in camel-hazelcast
[ https://issues.apache.org/jira/browse/CAMEL-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249572#comment-14249572 ] Claus Ibsen commented on CAMEL-7794: Did you have a chance to update the documentation? > Topics support in camel-hazelcast > - > > Key: CAMEL-7794 > URL: https://issues.apache.org/jira/browse/CAMEL-7794 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Affects Versions: 2.13.2 >Reporter: Juan Jose Vazquez Delgado >Assignee: Claus Ibsen > Fix For: 2.15.0 > > > As discussed in developer mailing list [1], we needed to add support for > Hazelcast distributed topics in Camel. We provide a PR that addresses this > [2]. > [1] > http://camel.465427.n5.nabble.com/Topics-support-in-camel-hazelcast-td5756233.html > [2] https://github.com/apache/camel/pull/263 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7786) Global exception handling breaks routeId
[ https://issues.apache.org/jira/browse/CAMEL-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7786. Resolution: Cannot Reproduce Assignee: Claus Ibsen > Global exception handling breaks routeId > > > Key: CAMEL-7786 > URL: https://issues.apache.org/jira/browse/CAMEL-7786 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.12.0 >Reporter: Serge Smertin >Assignee: Claus Ibsen > > This is somehow related to CAMEL-2109. Using Java DSL and code like > {code} > onException(Error.class).to("errorChannel"); > from(somethingChannel).routeId("triggerDoingSomething") > .inOnly("bean:foo") > .inOnly("bean:blah"); > /// later doing > context.getRouteDefinition("triggerDoingSomething").adviceWith(context, new > AdviceWithRouteBuilder() { > @Override > public void configure() throws Exception { > weaveAddFirst().process(new Processor() { > @Override > public void process(Exchange exchange) throws > Exception { > dumpSomeValues(); > } > }); > } > }); > {code} > does not work, as {code}OnException[[class java.lang.Error] -> > [To[errorChannel]]]{code} has no parent and `AdviseWithTask` never gets > `match = true` in a loop. I guess it would not even work with multiple > OnException definitions. > Exception thrown with this code is generated by > {code} > if (!match) { > throw new IllegalArgumentException("There are no outputs > which matches: " + matchBy.getId() + " in the route: " + route); > } > {code} > workaround? `weaveByType(OnExceptionDefinition.class)`? Ideas? Is it the > right use of route identifiers? -- This message was sent by Atlassian JIRA (v6.3.4#6332)