[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)
