[jira] [Commented] (CAMEL-9827) MongoDB - The unit tests have some issues
[
https://issues.apache.org/jira/browse/CAMEL-9827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229820#comment-15229820
]
Claus Ibsen commented on CAMEL-9827:
It looks like the embedded mongodb upgrade from 1.50.1 to 1.50.2 causes this
trouble. There is no less errors printed in the mongosb console when using that
older version.
But thee is this NPE during stopping
{code}
[mongod output] Exception in thread "Camel (camel-89) thread #68 -
mongodb://myDb" java.lang.NullPointerException
at com.mongodb.DBCursor.hasNext(DBCursor.java:156)
at
org.apache.camel.component.mongodb.MongoDbTailingProcess.doRun(MongoDbTailingProcess.java:144)
at
org.apache.camel.component.mongodb.MongoDbTailingProcess.run(MongoDbTailingProcess.java:99)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
I suspect its the cursor close hack that break out the doRun loop.
It seems the tryNext or try with a timeout is not so easy to get working.
> MongoDB - The unit tests have some issues
> -
>
> Key: CAMEL-9827
> URL: https://issues.apache.org/jira/browse/CAMEL-9827
> Project: Camel
> Issue Type: Test
> Components: camel-mongodb, tests
>Affects Versions: 2.17.0
>Reporter: Claus Ibsen
> Fix For: 2.18.0
>
>
> The tests outputs some errors in the mongo console and causes the thread to
> deadlock and die after the surefire test plugin timeout.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9827) MongoDB - The unit tests have some issues
[ https://issues.apache.org/jira/browse/CAMEL-9827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9827. Resolution: Fixed Assignee: Claus Ibsen Fix Version/s: 2.17.1 Okay the downgraded fixed most of them. That NPE is because of that stop hack. > MongoDB - The unit tests have some issues > - > > Key: CAMEL-9827 > URL: https://issues.apache.org/jira/browse/CAMEL-9827 > Project: Camel > Issue Type: Test > Components: camel-mongodb, tests >Affects Versions: 2.17.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.17.1, 2.18.0 > > > The tests outputs some errors in the mongo console and causes the thread to > deadlock and die after the surefire test plugin timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9789) CamelContext.getEndpoint should not start endpoint if Camel is starting up
[ https://issues.apache.org/jira/browse/CAMEL-9789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229856#comment-15229856 ] Hubertus Willuhn commented on CAMEL-9789: - That's good to know, i was a bit miss lead by the documentation. I think a sample for "good pratice" with spring boot, java config and camel would help Much to do at the moment, but i will try to zip a basic sample project and upload it to this JIRA > CamelContext.getEndpoint should not start endpoint if Camel is starting up > -- > > Key: CAMEL-9789 > URL: https://issues.apache.org/jira/browse/CAMEL-9789 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.18.0 > > > See nabble > http://camel.465427.n5.nabble.com/Quartz2-Endpoint-Exception-td5780221.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9828) Swagger seems to inject empty headers
Tim Dudgeon created CAMEL-9828:
--
Summary: Swagger seems to inject empty headers
Key: CAMEL-9828
URL: https://issues.apache.org/jira/browse/CAMEL-9828
Project: Camel
Issue Type: Bug
Components: camel-swagger
Affects Versions: 2.17.0
Reporter: Tim Dudgeon
See
http://camel.465427.n5.nabble.com/swagger-injects-empty-headers-in-2-17-0-td5780620.html
key part copied below.
I have routes built using REST DSL, and this includes swagger definitions.
With 2.1.6.2 all was good.
On switching to 2.17.0 I find that having a swagger query parameter definition
causes a header property to be defined as an empty string even when there is no
query parameter defined.
As an example, the REST DSL snippet looks like this:
.post("/{notebookid}/e").description("Description ...")
.bindingMode(RestBindingMode.json).produces("application/json")
.outType(Foo.class)
.param().name("notebookid").type(path).description("Notebook
ID").dataType("long").endParam()
.param().name("parent").type(query).description("The
parent").dataType("long").required(false).endParam()
.route()
.process((Exchange exch) -> {
Long parent = exch.getIn().getHeader("parent", Long.class);
...
})
.endRest()
"parent" is an optional query param.
With 2.16.2 there was no "parent" header.
With 2.17.0 a "parent" header is magically added with the value being the empty
string, which causes the TypeConversion to Long to blow up.
If I remove the swagger params then it works OK again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9829) camel-cxf namespace parser has hard dependency on jaxrs client
Niels Ull Harremoes created CAMEL-9829:
--
Summary: camel-cxf namespace parser has hard dependency on jaxrs
client
Key: CAMEL-9829
URL: https://issues.apache.org/jira/browse/CAMEL-9829
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.17.0
Reporter: Niels Ull Harremoes
Priority: Minor
I am trying to declare an endpoint like this in my spring context:
{code}
http://camel.apache.org/schema/cxf";
id="myEndpoint" address="${myUrl}"/>
{code}
I want to use it in a route like this:
.to("cxf:bean:myEndpoint?dataFormat=PAYLOAD")
I am not using rs, but the cxf NamespaceHandler has a dependency
CxfRsClientFactoryBeanDefinitionParser which again has a dependency on
org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean so I get a
java.lang.NoClassDefFoundError.
I found a workaround - not using the cxf namespace and declaring a bean of
class org.apache.camel.component.cxf.CxfSpringEndpoint.
But the error was a bit hard to diagnose.
Could the NamespaceHandler lazy-load the xxxBeanDefinitionParser instances so
that the class CxfRsClientFactoryBeanDefinitionParser doesn't get loaded if I
don't have a cxf:rsClient tag?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9830) camel-spring-javaconfig - Add routes like spring-boot does
Claus Ibsen created CAMEL-9830: -- Summary: camel-spring-javaconfig - Add routes like spring-boot does Key: CAMEL-9830 URL: https://issues.apache.org/jira/browse/CAMEL-9830 Project: Camel Issue Type: Improvement Components: camel-spring-javaconfig Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.18.0 This helps avoid those circular event issues you can get from spring. See CAMEL-9789 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9830) camel-spring-javaconfig - Add routes like spring-boot does
[ https://issues.apache.org/jira/browse/CAMEL-9830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9830. Resolution: Fixed > camel-spring-javaconfig - Add routes like spring-boot does > -- > > Key: CAMEL-9830 > URL: https://issues.apache.org/jira/browse/CAMEL-9830 > Project: Camel > Issue Type: Improvement > Components: camel-spring-javaconfig >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.18.0 > > > This helps avoid those circular event issues you can get from spring. > See CAMEL-9789 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9789) CamelContext.getEndpoint should not start endpoint if Camel is starting up
[ https://issues.apache.org/jira/browse/CAMEL-9789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229882#comment-15229882 ] Claus Ibsen commented on CAMEL-9789: Hubertus so I have modified camel-spring-javaconfig to be more like camel-spring-boot and add the routes after CamelContext has been fully created. So together with that fix and this ticket your issue should be fixed/improved a lot. > CamelContext.getEndpoint should not start endpoint if Camel is starting up > -- > > Key: CAMEL-9789 > URL: https://issues.apache.org/jira/browse/CAMEL-9789 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.18.0 > > > See nabble > http://camel.465427.n5.nabble.com/Quartz2-Endpoint-Exception-td5780221.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9789) CamelContext.getEndpoint should not start endpoint if Camel is starting up
[ https://issues.apache.org/jira/browse/CAMEL-9789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9789. Resolution: Fixed > CamelContext.getEndpoint should not start endpoint if Camel is starting up > -- > > Key: CAMEL-9789 > URL: https://issues.apache.org/jira/browse/CAMEL-9789 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.18.0 > > > See nabble > http://camel.465427.n5.nabble.com/Quartz2-Endpoint-Exception-td5780221.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9829) camel-cxf namespace parser has hard dependency on jaxrs client
[
https://issues.apache.org/jira/browse/CAMEL-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9829:
---
Issue Type: Improvement (was: Bug)
> camel-cxf namespace parser has hard dependency on jaxrs client
> --
>
> Key: CAMEL-9829
> URL: https://issues.apache.org/jira/browse/CAMEL-9829
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
>Affects Versions: 2.17.0
>Reporter: Niels Ull Harremoes
>Priority: Minor
>
> I am trying to declare an endpoint like this in my spring context:
> {code}
> xmlns:cxf="http://camel.apache.org/schema/cxf";
> id="myEndpoint" address="${myUrl}"/>
> {code}
> I want to use it in a route like this:
> .to("cxf:bean:myEndpoint?dataFormat=PAYLOAD")
> I am not using rs, but the cxf NamespaceHandler has a dependency
> CxfRsClientFactoryBeanDefinitionParser which again has a dependency on
> org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean so I get a
> java.lang.NoClassDefFoundError.
> I found a workaround - not using the cxf namespace and declaring a bean of
> class org.apache.camel.component.cxf.CxfSpringEndpoint.
> But the error was a bit hard to diagnose.
> Could the NamespaceHandler lazy-load the xxxBeanDefinitionParser instances so
> that the class CxfRsClientFactoryBeanDefinitionParser doesn't get loaded if I
> don't have a cxf:rsClient tag?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9829) camel-cxf namespace parser has hard dependency on jaxrs client
[
https://issues.apache.org/jira/browse/CAMEL-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229888#comment-15229888
]
Claus Ibsen commented on CAMEL-9829:
camel-cxf is need to be splitted up into several components. There is a ticket
about that already.
> camel-cxf namespace parser has hard dependency on jaxrs client
> --
>
> Key: CAMEL-9829
> URL: https://issues.apache.org/jira/browse/CAMEL-9829
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
>Affects Versions: 2.17.0
>Reporter: Niels Ull Harremoes
>Priority: Minor
>
> I am trying to declare an endpoint like this in my spring context:
> {code}
> xmlns:cxf="http://camel.apache.org/schema/cxf";
> id="myEndpoint" address="${myUrl}"/>
> {code}
> I want to use it in a route like this:
> .to("cxf:bean:myEndpoint?dataFormat=PAYLOAD")
> I am not using rs, but the cxf NamespaceHandler has a dependency
> CxfRsClientFactoryBeanDefinitionParser which again has a dependency on
> org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean so I get a
> java.lang.NoClassDefFoundError.
> I found a workaround - not using the cxf namespace and declaring a bean of
> class org.apache.camel.component.cxf.CxfSpringEndpoint.
> But the error was a bit hard to diagnose.
> Could the NamespaceHandler lazy-load the xxxBeanDefinitionParser instances so
> that the class CxfRsClientFactoryBeanDefinitionParser doesn't get loaded if I
> don't have a cxf:rsClient tag?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9829) camel-cxf namespace parser has hard dependency on jaxrs client
[
https://issues.apache.org/jira/browse/CAMEL-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9829.
Resolution: Duplicate
Assignee: Claus Ibsen
> camel-cxf namespace parser has hard dependency on jaxrs client
> --
>
> Key: CAMEL-9829
> URL: https://issues.apache.org/jira/browse/CAMEL-9829
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
>Affects Versions: 2.17.0
>Reporter: Niels Ull Harremoes
>Assignee: Claus Ibsen
>Priority: Minor
>
> I am trying to declare an endpoint like this in my spring context:
> {code}
> xmlns:cxf="http://camel.apache.org/schema/cxf";
> id="myEndpoint" address="${myUrl}"/>
> {code}
> I want to use it in a route like this:
> .to("cxf:bean:myEndpoint?dataFormat=PAYLOAD")
> I am not using rs, but the cxf NamespaceHandler has a dependency
> CxfRsClientFactoryBeanDefinitionParser which again has a dependency on
> org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean so I get a
> java.lang.NoClassDefFoundError.
> I found a workaround - not using the cxf namespace and declaring a bean of
> class org.apache.camel.component.cxf.CxfSpringEndpoint.
> But the error was a bit hard to diagnose.
> Could the NamespaceHandler lazy-load the xxxBeanDefinitionParser instances so
> that the class CxfRsClientFactoryBeanDefinitionParser doesn't get loaded if I
> don't have a cxf:rsClient tag?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9825) Exclude CDI generated proxies from context tracker
[ https://issues.apache.org/jira/browse/CAMEL-9825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229905#comment-15229905 ] ASF GitHub Bot commented on CAMEL-9825: --- Github user asfgit closed the pull request at: https://github.com/apache/camel/pull/931 > Exclude CDI generated proxies from context tracker > -- > > Key: CAMEL-9825 > URL: https://issues.apache.org/jira/browse/CAMEL-9825 > Project: Camel > Issue Type: Task > Components: camel-core >Reporter: Thomas Diesler > Fix For: 2.17.1, 2.18.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-9768) HTTP[4] component disableStreamCache issue: java.io.IOException: Attempted read from closed stream.
[
https://issues.apache.org/jira/browse/CAMEL-9768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-9768:
--
Assignee: Claus Ibsen
> HTTP[4] component disableStreamCache issue: java.io.IOException: Attempted
> read from closed stream.
> ---
>
> Key: CAMEL-9768
> URL: https://issues.apache.org/jira/browse/CAMEL-9768
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Affects Versions: 2.17.0
>Reporter: Edward Welch
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> This issue is related to CAMEL-7638 which was recently fixed/released in
> 2.17.0
> I was doing some testing with disableStreamCache=true on a http4 producer and
> am getting "java.io.IOException: Attempted read from closed stream"
> The stack trace shows the error occurring when trying to copy the input
> stream to an output stream inside the DefaultHttpBinding copyStream methods
> (i am using camel as a proxy from a sevlet component (consumer) to an http4
> component (producer)).
> I think though, I see the root cause of this issue. Inside the HttpProducer
> process method.
> {code}
> // lets store the result in the output message.
> HttpResponse httpResponse = null;
> try {
> if (LOG.isDebugEnabled()) {
> LOG.debug("Executing http {} method: {}",
> httpRequest.getMethod(), httpRequest.getURI().toString());
> }
> httpResponse = executeMethod(httpRequest);
> int responseCode = httpResponse.getStatusLine().getStatusCode();
> LOG.debug("Http responseCode: {}", responseCode);
> if (!throwException) {
> // if we do not use failed exception then populate response
> for all response codes
> populateResponse(exchange, httpRequest, httpResponse, in,
> strategy, responseCode);
> } else {
> boolean ok = HttpHelper.isStatusCodeOk(responseCode,
> getEndpoint().getOkStatusCodeRange());
> if (ok) {
> // only populate response for OK response
> populateResponse(exchange, httpRequest, httpResponse, in,
> strategy, responseCode);
> } else {
> // operation failed so populate exception to throw
> throw populateHttpOperationFailedException(exchange,
> httpRequest, httpResponse, responseCode);
> }
> }
> } finally {
> if (httpResponse != null) {
> try {
> EntityUtils.consume(httpResponse.getEntity());
> } catch (IOException e) {
> // nothing we could do
> }
> }
> }
> {code}
> Specifically, that finally block at the end.
> When disableStreamCache=true is set on the Producer, the raw input stream is
> put in the exchange body, which was the change fixed by CAMEL-7638
> However, the finally block is consuming and closing that input stream making
> it unusable later when we try to copy it to the servlet output stream to send
> back to the caller.
> I think the fix for this would be to check the endpoint to see if
> disableStreamCaching is set prior to consuming the entity in the finally
> block, perhaps something like this:
> {code}
> ...
> } finally {
> if (httpResponse != null &&
> !getEndpoint().isDisableStreamCache()) {
> try {
> EntityUtils.consume(httpResponse.getEntity());
> } catch (IOException e) {
> // nothing we could do
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9768) HTTP[4] component disableStreamCache issue: java.io.IOException: Attempted read from closed stream.
[
https://issues.apache.org/jira/browse/CAMEL-9768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229924#comment-15229924
]
ASF GitHub Bot commented on CAMEL-9768:
---
Github user asfgit closed the pull request at:
https://github.com/apache/camel/pull/932
> HTTP[4] component disableStreamCache issue: java.io.IOException: Attempted
> read from closed stream.
> ---
>
> Key: CAMEL-9768
> URL: https://issues.apache.org/jira/browse/CAMEL-9768
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Affects Versions: 2.17.0
>Reporter: Edward Welch
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> This issue is related to CAMEL-7638 which was recently fixed/released in
> 2.17.0
> I was doing some testing with disableStreamCache=true on a http4 producer and
> am getting "java.io.IOException: Attempted read from closed stream"
> The stack trace shows the error occurring when trying to copy the input
> stream to an output stream inside the DefaultHttpBinding copyStream methods
> (i am using camel as a proxy from a sevlet component (consumer) to an http4
> component (producer)).
> I think though, I see the root cause of this issue. Inside the HttpProducer
> process method.
> {code}
> // lets store the result in the output message.
> HttpResponse httpResponse = null;
> try {
> if (LOG.isDebugEnabled()) {
> LOG.debug("Executing http {} method: {}",
> httpRequest.getMethod(), httpRequest.getURI().toString());
> }
> httpResponse = executeMethod(httpRequest);
> int responseCode = httpResponse.getStatusLine().getStatusCode();
> LOG.debug("Http responseCode: {}", responseCode);
> if (!throwException) {
> // if we do not use failed exception then populate response
> for all response codes
> populateResponse(exchange, httpRequest, httpResponse, in,
> strategy, responseCode);
> } else {
> boolean ok = HttpHelper.isStatusCodeOk(responseCode,
> getEndpoint().getOkStatusCodeRange());
> if (ok) {
> // only populate response for OK response
> populateResponse(exchange, httpRequest, httpResponse, in,
> strategy, responseCode);
> } else {
> // operation failed so populate exception to throw
> throw populateHttpOperationFailedException(exchange,
> httpRequest, httpResponse, responseCode);
> }
> }
> } finally {
> if (httpResponse != null) {
> try {
> EntityUtils.consume(httpResponse.getEntity());
> } catch (IOException e) {
> // nothing we could do
> }
> }
> }
> {code}
> Specifically, that finally block at the end.
> When disableStreamCache=true is set on the Producer, the raw input stream is
> put in the exchange body, which was the change fixed by CAMEL-7638
> However, the finally block is consuming and closing that input stream making
> it unusable later when we try to copy it to the servlet output stream to send
> back to the caller.
> I think the fix for this would be to check the endpoint to see if
> disableStreamCaching is set prior to consuming the entity in the finally
> block, perhaps something like this:
> {code}
> ...
> } finally {
> if (httpResponse != null &&
> !getEndpoint().isDisableStreamCache()) {
> try {
> EntityUtils.consume(httpResponse.getEntity());
> } catch (IOException e) {
> // nothing we could do
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9768) HTTP[4] component disableStreamCache issue: java.io.IOException: Attempted read from closed stream.
[
https://issues.apache.org/jira/browse/CAMEL-9768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9768.
Resolution: Fixed
Thanks. I added a so the stream is closed later so we cleanup nicely.
> HTTP[4] component disableStreamCache issue: java.io.IOException: Attempted
> read from closed stream.
> ---
>
> Key: CAMEL-9768
> URL: https://issues.apache.org/jira/browse/CAMEL-9768
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Affects Versions: 2.17.0
>Reporter: Edward Welch
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> This issue is related to CAMEL-7638 which was recently fixed/released in
> 2.17.0
> I was doing some testing with disableStreamCache=true on a http4 producer and
> am getting "java.io.IOException: Attempted read from closed stream"
> The stack trace shows the error occurring when trying to copy the input
> stream to an output stream inside the DefaultHttpBinding copyStream methods
> (i am using camel as a proxy from a sevlet component (consumer) to an http4
> component (producer)).
> I think though, I see the root cause of this issue. Inside the HttpProducer
> process method.
> {code}
> // lets store the result in the output message.
> HttpResponse httpResponse = null;
> try {
> if (LOG.isDebugEnabled()) {
> LOG.debug("Executing http {} method: {}",
> httpRequest.getMethod(), httpRequest.getURI().toString());
> }
> httpResponse = executeMethod(httpRequest);
> int responseCode = httpResponse.getStatusLine().getStatusCode();
> LOG.debug("Http responseCode: {}", responseCode);
> if (!throwException) {
> // if we do not use failed exception then populate response
> for all response codes
> populateResponse(exchange, httpRequest, httpResponse, in,
> strategy, responseCode);
> } else {
> boolean ok = HttpHelper.isStatusCodeOk(responseCode,
> getEndpoint().getOkStatusCodeRange());
> if (ok) {
> // only populate response for OK response
> populateResponse(exchange, httpRequest, httpResponse, in,
> strategy, responseCode);
> } else {
> // operation failed so populate exception to throw
> throw populateHttpOperationFailedException(exchange,
> httpRequest, httpResponse, responseCode);
> }
> }
> } finally {
> if (httpResponse != null) {
> try {
> EntityUtils.consume(httpResponse.getEntity());
> } catch (IOException e) {
> // nothing we could do
> }
> }
> }
> {code}
> Specifically, that finally block at the end.
> When disableStreamCache=true is set on the Producer, the raw input stream is
> put in the exchange body, which was the change fixed by CAMEL-7638
> However, the finally block is consuming and closing that input stream making
> it unusable later when we try to copy it to the servlet output stream to send
> back to the caller.
> I think the fix for this would be to check the endpoint to see if
> disableStreamCaching is set prior to consuming the entity in the finally
> block, perhaps something like this:
> {code}
> ...
> } finally {
> if (httpResponse != null &&
> !getEndpoint().isDisableStreamCache()) {
> try {
> EntityUtils.consume(httpResponse.getEntity());
> } catch (IOException e) {
> // nothing we could do
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9825) Exclude CDI generated proxies from context tracker
[ https://issues.apache.org/jira/browse/CAMEL-9825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9825. Resolution: Fixed Assignee: Claus Ibsen > Exclude CDI generated proxies from context tracker > -- > > Key: CAMEL-9825 > URL: https://issues.apache.org/jira/browse/CAMEL-9825 > Project: Camel > Issue Type: Task > Components: camel-core >Reporter: Thomas Diesler >Assignee: Claus Ibsen > Fix For: 2.17.1, 2.18.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9831) Camel-http4: Make possible to use System Properties for configuration
Andrea Cosentino created CAMEL-9831: --- Summary: Camel-http4: Make possible to use System Properties for configuration Key: CAMEL-9831 URL: https://issues.apache.org/jira/browse/CAMEL-9831 Project: Camel Issue Type: Improvement Components: camel-http4 Reporter: Andrea Cosentino Assignee: Andrea Cosentino Priority: Minor There is case when we need to set for example http.nonProxyHosts property. The only way to set this on HttpClient is to use System Properties, but actually we instead read the proxy Properties from camelContext. We can add an option useSystemProperties, that make possible to use System Properties as fallback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9832) Allow the possibility to skip the mapping of message body/headers in HTTP Message
Andrea Cosentino created CAMEL-9832: --- Summary: Allow the possibility to skip the mapping of message body/headers in HTTP Message Key: CAMEL-9832 URL: https://issues.apache.org/jira/browse/CAMEL-9832 Project: Camel Issue Type: Improvement Components: camel-http-common Reporter: Andrea Cosentino Assignee: Andrea Cosentino Priority: Minor There are situations where we don't need to convert a Message in HTTP headers and body, but simply route the message as is. For example when we are on route like jetty ---> jetty. It can be useful to add an option that skip the mapping to HTTP Message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9833) Add mapHttpMessage option to allow to turn off mapping by default
Claus Ibsen created CAMEL-9833: -- Summary: Add mapHttpMessage option to allow to turn off mapping by default Key: CAMEL-9833 URL: https://issues.apache.org/jira/browse/CAMEL-9833 Project: Camel Issue Type: Improvement Components: camel-jetty Reporter: Claus Ibsen Fix For: 2.18.0 Like the mapMailMessage option in camel-mail, we should have an option to turn off the auto mapping from http request to camel message body / headers. You may want to turn this off if you do proxy routes where you just want to route the request to another endpoint without the need to access the body/headers during routing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9833) Add mapHttpMessage option to allow to turn off mapping by default
[ https://issues.apache.org/jira/browse/CAMEL-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229987#comment-15229987 ] Claus Ibsen commented on CAMEL-9833: We should likely add two options so you can map the headers and not the body, eg if you want to do CBR based on HTTP headers. mapHttpMessageBody=true|false mapHttpMessageHeaders=true|false Then they can be true by default as today. Then in org.apache.camel.http.common.DefaultHttpBinding#readRequest we should not force loading the message body and headers if they are false. > Add mapHttpMessage option to allow to turn off mapping by default > - > > Key: CAMEL-9833 > URL: https://issues.apache.org/jira/browse/CAMEL-9833 > Project: Camel > Issue Type: Improvement > Components: camel-jetty >Reporter: Claus Ibsen > Fix For: 2.18.0 > > > Like the mapMailMessage option in camel-mail, we should have an option to > turn off the auto mapping from http request to camel message body / headers. > You may want to turn this off if you do proxy routes where you just want to > route the request to another endpoint without the need to access the > body/headers during routing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-9833) Add mapHttpMessage option to allow to turn off mapping by default
[ https://issues.apache.org/jira/browse/CAMEL-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reassigned CAMEL-9833: --- Assignee: Andrea Cosentino > Add mapHttpMessage option to allow to turn off mapping by default > - > > Key: CAMEL-9833 > URL: https://issues.apache.org/jira/browse/CAMEL-9833 > Project: Camel > Issue Type: Improvement > Components: camel-jetty >Reporter: Claus Ibsen >Assignee: Andrea Cosentino > Fix For: 2.18.0 > > > Like the mapMailMessage option in camel-mail, we should have an option to > turn off the auto mapping from http request to camel message body / headers. > You may want to turn this off if you do proxy routes where you just want to > route the request to another endpoint without the need to access the > body/headers during routing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9832) Allow the possibility to skip the mapping of message body/headers in HTTP Message
[ https://issues.apache.org/jira/browse/CAMEL-9832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-9832. - Resolution: Duplicate > Allow the possibility to skip the mapping of message body/headers in HTTP > Message > - > > Key: CAMEL-9832 > URL: https://issues.apache.org/jira/browse/CAMEL-9832 > Project: Camel > Issue Type: Improvement > Components: camel-http-common >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > > There are situations where we don't need to convert a Message in HTTP headers > and body, but simply route the message as is. For example when we are on > route like jetty ---> jetty. > It can be useful to add an option that skip the mapping to HTTP Message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9832) Allow the possibility to skip the mapping of message body/headers in HTTP Message
[ https://issues.apache.org/jira/browse/CAMEL-9832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-9832: Component/s: (was: camel-http-common) camel-http4 > Allow the possibility to skip the mapping of message body/headers in HTTP > Message > - > > Key: CAMEL-9832 > URL: https://issues.apache.org/jira/browse/CAMEL-9832 > Project: Camel > Issue Type: Improvement > Components: camel-http4 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > > There are situations where we don't need to convert a Message in HTTP headers > and body, but simply route the message as is. For example when we are on > route like jetty ---> jetty. > It can be useful to add an option that skip the mapping to HTTP Message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9600) camel-fop - Upgrade fop to 2.1
[ https://issues.apache.org/jira/browse/CAMEL-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230001#comment-15230001 ] Sergey Yakimovich commented on CAMEL-9600: -- I can work on this issue. In version 1.1 you could configure FopFactory programmatically, now you can't do that but you can programmatically configure FopFactoryBuilder which creates FopFactory https://xmlgraphics.apache.org/fop/2.1/embedding.html#config-internal. Maybe just forbid to specify both parameters by throwing something like FopConfigException with "More than one configuration. You can configure fop either by config file or by supplying FopFactory but not both." to avoid confusions. > camel-fop - Upgrade fop to 2.1 > -- > > Key: CAMEL-9600 > URL: https://issues.apache.org/jira/browse/CAMEL-9600 > Project: Camel > Issue Type: Improvement > Components: camel-fop >Reporter: Claus Ibsen >Priority: Minor > Fix For: 2.18.0 > > > We should upgrade camel-fop to use fop 2.1. It uses 1.1 today. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9828) Swagger seems to inject empty headers
[
https://issues.apache.org/jira/browse/CAMEL-9828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9828:
---
Fix Version/s: 2.18.0
2.17.1
> Swagger seems to inject empty headers
> -
>
> Key: CAMEL-9828
> URL: https://issues.apache.org/jira/browse/CAMEL-9828
> Project: Camel
> Issue Type: Bug
> Components: camel-swagger
>Affects Versions: 2.17.0
>Reporter: Tim Dudgeon
> Fix For: 2.17.1, 2.18.0
>
>
> See
> http://camel.465427.n5.nabble.com/swagger-injects-empty-headers-in-2-17-0-td5780620.html
> key part copied below.
> I have routes built using REST DSL, and this includes swagger definitions.
> With 2.1.6.2 all was good.
> On switching to 2.17.0 I find that having a swagger query parameter
> definition causes a header property to be defined as an empty string even
> when there is no query parameter defined.
> As an example, the REST DSL snippet looks like this:
> .post("/{notebookid}/e").description("Description ...")
> .bindingMode(RestBindingMode.json).produces("application/json")
> .outType(Foo.class)
> .param().name("notebookid").type(path).description("Notebook
> ID").dataType("long").endParam()
> .param().name("parent").type(query).description("The
> parent").dataType("long").required(false).endParam()
> .route()
> .process((Exchange exch) -> {
> Long parent = exch.getIn().getHeader("parent", Long.class);
> ...
> })
> .endRest()
> "parent" is an optional query param.
> With 2.16.2 there was no "parent" header.
> With 2.17.0 a "parent" header is magically added with the value being the
> empty string, which causes the TypeConversion to Long to blow up.
> If I remove the swagger params then it works OK again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-9828) Swagger seems to inject empty headers
[
https://issues.apache.org/jira/browse/CAMEL-9828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-9828:
--
Assignee: Claus Ibsen
> Swagger seems to inject empty headers
> -
>
> Key: CAMEL-9828
> URL: https://issues.apache.org/jira/browse/CAMEL-9828
> Project: Camel
> Issue Type: Bug
> Components: camel-swagger
>Affects Versions: 2.17.0
>Reporter: Tim Dudgeon
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> See
> http://camel.465427.n5.nabble.com/swagger-injects-empty-headers-in-2-17-0-td5780620.html
> key part copied below.
> I have routes built using REST DSL, and this includes swagger definitions.
> With 2.1.6.2 all was good.
> On switching to 2.17.0 I find that having a swagger query parameter
> definition causes a header property to be defined as an empty string even
> when there is no query parameter defined.
> As an example, the REST DSL snippet looks like this:
> .post("/{notebookid}/e").description("Description ...")
> .bindingMode(RestBindingMode.json).produces("application/json")
> .outType(Foo.class)
> .param().name("notebookid").type(path).description("Notebook
> ID").dataType("long").endParam()
> .param().name("parent").type(query).description("The
> parent").dataType("long").required(false).endParam()
> .route()
> .process((Exchange exch) -> {
> Long parent = exch.getIn().getHeader("parent", Long.class);
> ...
> })
> .endRest()
> "parent" is an optional query param.
> With 2.16.2 there was no "parent" header.
> With 2.17.0 a "parent" header is magically added with the value being the
> empty string, which causes the TypeConversion to Long to blow up.
> If I remove the swagger params then it works OK again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9828) Swagger seems to inject empty headers
[
https://issues.apache.org/jira/browse/CAMEL-9828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9828.
Resolution: Fixed
Thanks for reporting
> Swagger seems to inject empty headers
> -
>
> Key: CAMEL-9828
> URL: https://issues.apache.org/jira/browse/CAMEL-9828
> Project: Camel
> Issue Type: Bug
> Components: camel-swagger
>Affects Versions: 2.17.0
>Reporter: Tim Dudgeon
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> See
> http://camel.465427.n5.nabble.com/swagger-injects-empty-headers-in-2-17-0-td5780620.html
> key part copied below.
> I have routes built using REST DSL, and this includes swagger definitions.
> With 2.1.6.2 all was good.
> On switching to 2.17.0 I find that having a swagger query parameter
> definition causes a header property to be defined as an empty string even
> when there is no query parameter defined.
> As an example, the REST DSL snippet looks like this:
> .post("/{notebookid}/e").description("Description ...")
> .bindingMode(RestBindingMode.json).produces("application/json")
> .outType(Foo.class)
> .param().name("notebookid").type(path).description("Notebook
> ID").dataType("long").endParam()
> .param().name("parent").type(query).description("The
> parent").dataType("long").required(false).endParam()
> .route()
> .process((Exchange exch) -> {
> Long parent = exch.getIn().getHeader("parent", Long.class);
> ...
> })
> .endRest()
> "parent" is an optional query param.
> With 2.16.2 there was no "parent" header.
> With 2.17.0 a "parent" header is magically added with the value being the
> empty string, which causes the TypeConversion to Long to blow up.
> If I remove the swagger params then it works OK again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9831) Camel-http4: Make possible to use System Properties for configuration
[ https://issues.apache.org/jira/browse/CAMEL-9831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-9831. - Resolution: Fixed > Camel-http4: Make possible to use System Properties for configuration > - > > Key: CAMEL-9831 > URL: https://issues.apache.org/jira/browse/CAMEL-9831 > Project: Camel > Issue Type: Improvement > Components: camel-http4 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > > There is case when we need to set for example http.nonProxyHosts property. > The only way to set this on HttpClient is to use System Properties, but > actually we instead read the proxy Properties from camelContext. > We can add an option useSystemProperties, that make possible to use System > Properties as fallback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9831) Camel-http4: Make possible to use System Properties for configuration
[ https://issues.apache.org/jira/browse/CAMEL-9831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-9831: Fix Version/s: 2.18.0 > Camel-http4: Make possible to use System Properties for configuration > - > > Key: CAMEL-9831 > URL: https://issues.apache.org/jira/browse/CAMEL-9831 > Project: Camel > Issue Type: Improvement > Components: camel-http4 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 2.18.0 > > > There is case when we need to set for example http.nonProxyHosts property. > The only way to set this on HttpClient is to use System Properties, but > actually we instead read the proxy Properties from camelContext. > We can add an option useSystemProperties, that make possible to use System > Properties as fallback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9462) HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
[
https://issues.apache.org/jira/browse/CAMEL-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230126#comment-15230126
]
ASF GitHub Bot commented on CAMEL-9462:
---
GitHub user erwelch opened a pull request:
https://github.com/apache/camel/pull/935
CAMEL-9462 HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/erwelch/camel CAMEL-9462
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/935.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #935
commit dfc6ee1098745518ca5db5aefef9f5b0f19b934d
Author: Edward Welch
Date: 2016-04-07T11:48:16Z
Adding a new endpoint property to the HttpCommonEndpoint which allows
preserving the Host header in reverse proxy applications, this class is ued by
the Http, Http4, and Jetty producers.
Updated the HttpProducer (Jetty/HTTP4) to set the Host header when this
flag is enabled. The older HTTP component does not readily let us override the
Host header, this component will not support this parameter
Updated the Integration Test to validate the behavior for both when the new
parameter is set, and unset.
> HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
> --
>
> Key: CAMEL-9462
> URL: https://issues.apache.org/jira/browse/CAMEL-9462
> Project: Camel
> Issue Type: Bug
> Components: camel-http, camel-http4
>Affects Versions: 2.9.5, 2.10.3, 2.11.0
>Reporter: Ian Hu
> Fix For: 2.17.1, 2.18.0
>
>
> I have wrote code below make camel as a load balancer, but camel-http4(and
> the camel-http, etc) deal the http header Host wrongly, it replace the Host
> header with the host name of the backend of balancer, that make the backend
> generate the wrong link.
>
> {code:title=Main.java|borderStyle=solid}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.model.RouteDefinition;
> public class Main {
> public static void main(String[] args) throws Exception {
> DefaultCamelContext context = new DefaultCamelContext();
> RouteDefinition route = new RouteDefinition();
> route.from("jetty:http://0.0.0.0:8080/?matchOnUriPrefix=true";)
> .loadBalance().roundRobin()
>
> .to("http4://127.0.0.1:8081/?bridgeEndpoint=true&throwExceptionOnFailure=false")
>
> .to("http4://127.0.0.1:8082/?bridgeEndpoint=true&throwExceptionOnFailure=false");
> //
> context.addRouteDefinition(route);
> context.start();
> }
> }
> {code}
> I have view the code and found a fix of
> [https://issues.apache.org/jira/browse/CAMEL-5757](See the commit), it's
> commits simply removed the host header
> [https://fisheye6.atlassian.com/browse/camel-git/components/camel-http4/src/main/java/org/apache/camel/component/http4/HttpProducer.java?hb=true#to106].
> and I really do not think it should be dealt like that.
> Some backend will use the Host header to generate link, and when the Host
> header removed and then it be set to the backend's host, the backend got the
> wrong Host, and generate the wrong link.
> I expect the link should be http://localhost:8080/web but it generate
> http://127.0.0.1:8081/web or http://127.0.0.1:8082/web when I view the page
> with the url http://localhost:8080
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9462) HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
[
https://issues.apache.org/jira/browse/CAMEL-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230135#comment-15230135
]
Edward Welch commented on CAMEL-9462:
-
Hi Claus, please take a look at my pull request.
A couple of notes for posterity:
The original suspected culprit was not actually the issue:
{code}
//Remove host header unless instructed not to do so
if(!getEndpoint().isPreserveHostHeader()){
exchange.getIn().getHeaders().remove("host");
}
{code}
I discovered this code was made redundant by CAMEL-6185 so I removed this block
of code from the HTTP4 and Jetty producers
The Host header was still being removed by the changes introduced in
CAMEL-6185, so I added a block of code after the headers are filtered where the
new parameter is checked, if set true, and Host header on the exchange is not
null, then the Host header is added to the outgoing http request.
I updated JettyBridgeHostHeaderIssueTest.java to validate the Host header as it
isreceived by the downstream service for both when the new preserveHostHeader
is true/false and for both the Jetty and HTTP4 producers
> HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
> --
>
> Key: CAMEL-9462
> URL: https://issues.apache.org/jira/browse/CAMEL-9462
> Project: Camel
> Issue Type: Bug
> Components: camel-http, camel-http4
>Affects Versions: 2.9.5, 2.10.3, 2.11.0
>Reporter: Ian Hu
> Fix For: 2.17.1, 2.18.0
>
>
> I have wrote code below make camel as a load balancer, but camel-http4(and
> the camel-http, etc) deal the http header Host wrongly, it replace the Host
> header with the host name of the backend of balancer, that make the backend
> generate the wrong link.
>
> {code:title=Main.java|borderStyle=solid}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.model.RouteDefinition;
> public class Main {
> public static void main(String[] args) throws Exception {
> DefaultCamelContext context = new DefaultCamelContext();
> RouteDefinition route = new RouteDefinition();
> route.from("jetty:http://0.0.0.0:8080/?matchOnUriPrefix=true";)
> .loadBalance().roundRobin()
>
> .to("http4://127.0.0.1:8081/?bridgeEndpoint=true&throwExceptionOnFailure=false")
>
> .to("http4://127.0.0.1:8082/?bridgeEndpoint=true&throwExceptionOnFailure=false");
> //
> context.addRouteDefinition(route);
> context.start();
> }
> }
> {code}
> I have view the code and found a fix of
> [https://issues.apache.org/jira/browse/CAMEL-5757](See the commit), it's
> commits simply removed the host header
> [https://fisheye6.atlassian.com/browse/camel-git/components/camel-http4/src/main/java/org/apache/camel/component/http4/HttpProducer.java?hb=true#to106].
> and I really do not think it should be dealt like that.
> Some backend will use the Host header to generate link, and when the Host
> header removed and then it be set to the backend's host, the backend got the
> wrong Host, and generate the wrong link.
> I expect the link should be http://localhost:8080/web but it generate
> http://127.0.0.1:8081/web or http://127.0.0.1:8082/web when I view the page
> with the url http://localhost:8080
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9834) WatchConsumer does not properly set watchIndex
Luca Burgazzoli created CAMEL-9834: -- Summary: WatchConsumer does not properly set watchIndex Key: CAMEL-9834 URL: https://issues.apache.org/jira/browse/CAMEL-9834 Project: Camel Issue Type: Bug Components: camel-etcd Reporter: Luca Burgazzoli Assignee: Luca Burgazzoli -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (CAMEL-9834) WatchConsumer does not properly set watchIndex
[ https://issues.apache.org/jira/browse/CAMEL-9834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-9834 started by Luca Burgazzoli. -- > WatchConsumer does not properly set watchIndex > -- > > Key: CAMEL-9834 > URL: https://issues.apache.org/jira/browse/CAMEL-9834 > Project: Camel > Issue Type: Bug > Components: camel-etcd >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9462) HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
[
https://issues.apache.org/jira/browse/CAMEL-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9462:
---
Assignee: Andrea Cosentino
> HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
> --
>
> Key: CAMEL-9462
> URL: https://issues.apache.org/jira/browse/CAMEL-9462
> Project: Camel
> Issue Type: Bug
> Components: camel-http, camel-http4
>Affects Versions: 2.9.5, 2.10.3, 2.11.0
>Reporter: Ian Hu
>Assignee: Andrea Cosentino
> Fix For: 2.17.1, 2.18.0
>
>
> I have wrote code below make camel as a load balancer, but camel-http4(and
> the camel-http, etc) deal the http header Host wrongly, it replace the Host
> header with the host name of the backend of balancer, that make the backend
> generate the wrong link.
>
> {code:title=Main.java|borderStyle=solid}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.model.RouteDefinition;
> public class Main {
> public static void main(String[] args) throws Exception {
> DefaultCamelContext context = new DefaultCamelContext();
> RouteDefinition route = new RouteDefinition();
> route.from("jetty:http://0.0.0.0:8080/?matchOnUriPrefix=true";)
> .loadBalance().roundRobin()
>
> .to("http4://127.0.0.1:8081/?bridgeEndpoint=true&throwExceptionOnFailure=false")
>
> .to("http4://127.0.0.1:8082/?bridgeEndpoint=true&throwExceptionOnFailure=false");
> //
> context.addRouteDefinition(route);
> context.start();
> }
> }
> {code}
> I have view the code and found a fix of
> [https://issues.apache.org/jira/browse/CAMEL-5757](See the commit), it's
> commits simply removed the host header
> [https://fisheye6.atlassian.com/browse/camel-git/components/camel-http4/src/main/java/org/apache/camel/component/http4/HttpProducer.java?hb=true#to106].
> and I really do not think it should be dealt like that.
> Some backend will use the Host header to generate link, and when the Host
> header removed and then it be set to the backend's host, the backend got the
> wrong Host, and generate the wrong link.
> I expect the link should be http://localhost:8080/web but it generate
> http://127.0.0.1:8081/web or http://127.0.0.1:8082/web when I view the page
> with the url http://localhost:8080
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9462) HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
[
https://issues.apache.org/jira/browse/CAMEL-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230215#comment-15230215
]
Claus Ibsen commented on CAMEL-9462:
Thanks Edward for the PR. Lovely when it includes unit tests.
> HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
> --
>
> Key: CAMEL-9462
> URL: https://issues.apache.org/jira/browse/CAMEL-9462
> Project: Camel
> Issue Type: Bug
> Components: camel-http, camel-http4
>Affects Versions: 2.9.5, 2.10.3, 2.11.0
>Reporter: Ian Hu
>Assignee: Andrea Cosentino
> Fix For: 2.17.1, 2.18.0
>
>
> I have wrote code below make camel as a load balancer, but camel-http4(and
> the camel-http, etc) deal the http header Host wrongly, it replace the Host
> header with the host name of the backend of balancer, that make the backend
> generate the wrong link.
>
> {code:title=Main.java|borderStyle=solid}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.model.RouteDefinition;
> public class Main {
> public static void main(String[] args) throws Exception {
> DefaultCamelContext context = new DefaultCamelContext();
> RouteDefinition route = new RouteDefinition();
> route.from("jetty:http://0.0.0.0:8080/?matchOnUriPrefix=true";)
> .loadBalance().roundRobin()
>
> .to("http4://127.0.0.1:8081/?bridgeEndpoint=true&throwExceptionOnFailure=false")
>
> .to("http4://127.0.0.1:8082/?bridgeEndpoint=true&throwExceptionOnFailure=false");
> //
> context.addRouteDefinition(route);
> context.start();
> }
> }
> {code}
> I have view the code and found a fix of
> [https://issues.apache.org/jira/browse/CAMEL-5757](See the commit), it's
> commits simply removed the host header
> [https://fisheye6.atlassian.com/browse/camel-git/components/camel-http4/src/main/java/org/apache/camel/component/http4/HttpProducer.java?hb=true#to106].
> and I really do not think it should be dealt like that.
> Some backend will use the Host header to generate link, and when the Host
> header removed and then it be set to the backend's host, the backend got the
> wrong Host, and generate the wrong link.
> I expect the link should be http://localhost:8080/web but it generate
> http://127.0.0.1:8081/web or http://127.0.0.1:8082/web when I view the page
> with the url http://localhost:8080
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9600) camel-fop - Upgrade fop to 2.1
[ https://issues.apache.org/jira/browse/CAMEL-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230216#comment-15230216 ] Claus Ibsen commented on CAMEL-9600: Sergey that sounds like a good idea. Thanks for helping > camel-fop - Upgrade fop to 2.1 > -- > > Key: CAMEL-9600 > URL: https://issues.apache.org/jira/browse/CAMEL-9600 > Project: Camel > Issue Type: Improvement > Components: camel-fop >Reporter: Claus Ibsen >Priority: Minor > Fix For: 2.18.0 > > > We should upgrade camel-fop to use fop 2.1. It uses 1.1 today. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9462) HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
[
https://issues.apache.org/jira/browse/CAMEL-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230214#comment-15230214
]
Claus Ibsen commented on CAMEL-9462:
Andrea, after that other HTTP ticket can you take a look at merging this PR.
> HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
> --
>
> Key: CAMEL-9462
> URL: https://issues.apache.org/jira/browse/CAMEL-9462
> Project: Camel
> Issue Type: Bug
> Components: camel-http, camel-http4
>Affects Versions: 2.9.5, 2.10.3, 2.11.0
>Reporter: Ian Hu
>Assignee: Andrea Cosentino
> Fix For: 2.17.1, 2.18.0
>
>
> I have wrote code below make camel as a load balancer, but camel-http4(and
> the camel-http, etc) deal the http header Host wrongly, it replace the Host
> header with the host name of the backend of balancer, that make the backend
> generate the wrong link.
>
> {code:title=Main.java|borderStyle=solid}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.model.RouteDefinition;
> public class Main {
> public static void main(String[] args) throws Exception {
> DefaultCamelContext context = new DefaultCamelContext();
> RouteDefinition route = new RouteDefinition();
> route.from("jetty:http://0.0.0.0:8080/?matchOnUriPrefix=true";)
> .loadBalance().roundRobin()
>
> .to("http4://127.0.0.1:8081/?bridgeEndpoint=true&throwExceptionOnFailure=false")
>
> .to("http4://127.0.0.1:8082/?bridgeEndpoint=true&throwExceptionOnFailure=false");
> //
> context.addRouteDefinition(route);
> context.start();
> }
> }
> {code}
> I have view the code and found a fix of
> [https://issues.apache.org/jira/browse/CAMEL-5757](See the commit), it's
> commits simply removed the host header
> [https://fisheye6.atlassian.com/browse/camel-git/components/camel-http4/src/main/java/org/apache/camel/component/http4/HttpProducer.java?hb=true#to106].
> and I really do not think it should be dealt like that.
> Some backend will use the Host header to generate link, and when the Host
> header removed and then it be set to the backend's host, the backend got the
> wrong Host, and generate the wrong link.
> I expect the link should be http://localhost:8080/web but it generate
> http://127.0.0.1:8081/web or http://127.0.0.1:8082/web when I view the page
> with the url http://localhost:8080
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9462) HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
[
https://issues.apache.org/jira/browse/CAMEL-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230221#comment-15230221
]
Andrea Cosentino commented on CAMEL-9462:
-
Yes :-) I will take care of the PR :-)
> HTTP 1.1 Host header be dealt wrongly in proxy & load balancer
> --
>
> Key: CAMEL-9462
> URL: https://issues.apache.org/jira/browse/CAMEL-9462
> Project: Camel
> Issue Type: Bug
> Components: camel-http, camel-http4
>Affects Versions: 2.9.5, 2.10.3, 2.11.0
>Reporter: Ian Hu
>Assignee: Andrea Cosentino
> Fix For: 2.17.1, 2.18.0
>
>
> I have wrote code below make camel as a load balancer, but camel-http4(and
> the camel-http, etc) deal the http header Host wrongly, it replace the Host
> header with the host name of the backend of balancer, that make the backend
> generate the wrong link.
>
> {code:title=Main.java|borderStyle=solid}
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.model.RouteDefinition;
> public class Main {
> public static void main(String[] args) throws Exception {
> DefaultCamelContext context = new DefaultCamelContext();
> RouteDefinition route = new RouteDefinition();
> route.from("jetty:http://0.0.0.0:8080/?matchOnUriPrefix=true";)
> .loadBalance().roundRobin()
>
> .to("http4://127.0.0.1:8081/?bridgeEndpoint=true&throwExceptionOnFailure=false")
>
> .to("http4://127.0.0.1:8082/?bridgeEndpoint=true&throwExceptionOnFailure=false");
> //
> context.addRouteDefinition(route);
> context.start();
> }
> }
> {code}
> I have view the code and found a fix of
> [https://issues.apache.org/jira/browse/CAMEL-5757](See the commit), it's
> commits simply removed the host header
> [https://fisheye6.atlassian.com/browse/camel-git/components/camel-http4/src/main/java/org/apache/camel/component/http4/HttpProducer.java?hb=true#to106].
> and I really do not think it should be dealt like that.
> Some backend will use the Host header to generate link, and when the Host
> header removed and then it be set to the backend's host, the backend got the
> wrong Host, and generate the wrong link.
> I expect the link should be http://localhost:8080/web but it generate
> http://127.0.0.1:8081/web or http://127.0.0.1:8082/web when I view the page
> with the url http://localhost:8080
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9835) Enable kafka consumer to subcribe to multiple topics
Jose Luis Pedrosa created CAMEL-9835:
Summary: Enable kafka consumer to subcribe to multiple topics
Key: CAMEL-9835
URL: https://issues.apache.org/jira/browse/CAMEL-9835
Project: Camel
Issue Type: Wish
Components: camel-kafka
Affects Versions: 2.17.0
Environment: Any
Reporter: Jose Luis Pedrosa
Priority: Minor
Fix For: 2.17.1
Kafka supports that one consumer is subcriber to multple topics. In their api
when you start the consumer you MUST provide an Array of topics.
If we look in /java/org/apache/camel/component/kafka/KafkaConsumer.java
Currently this is the piece of code that starts the subscriber:
{code}
LOG.debug("Subscribing {} to topic {}", threadId, topicName);
consumer.subscribe(Arrays.asList(topicName));
{code}
just simply allowing the comma separated topic syntax and replacing one line of
code (and the documentation) it would be working.
{code}
LOG.debug("Subscribing {} to topic {}", threadId, topicName);
consumer.subscribe(Arrays.asList(topicName.split(",")));
{code}
Despite the same could be achieved by adding more consumers (rotues) this
causes a significant amount of load (because of the commits) to kafka, so this
really helps to improve performance.
the topic has been already marked as mandatory, so that should keep the
nullpointer safe.
@UriParam @Metadata(required = "true")
private String topic;
thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-9835) Enable kafka consumer to subcribe to multiple topics
[
https://issues.apache.org/jira/browse/CAMEL-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino reassigned CAMEL-9835:
---
Assignee: Andrea Cosentino
> Enable kafka consumer to subcribe to multiple topics
> -
>
> Key: CAMEL-9835
> URL: https://issues.apache.org/jira/browse/CAMEL-9835
> Project: Camel
> Issue Type: Wish
> Components: camel-kafka
>Affects Versions: 2.17.0
> Environment: Any
>Reporter: Jose Luis Pedrosa
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.17.1
>
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> Kafka supports that one consumer is subcriber to multple topics. In their api
> when you start the consumer you MUST provide an Array of topics.
> If we look in /java/org/apache/camel/component/kafka/KafkaConsumer.java
> Currently this is the piece of code that starts the subscriber:
> {code}
> LOG.debug("Subscribing {} to topic {}", threadId, topicName);
> consumer.subscribe(Arrays.asList(topicName));
> {code}
> just simply allowing the comma separated topic syntax and replacing one line
> of code (and the documentation) it would be working.
> {code}
> LOG.debug("Subscribing {} to topic {}", threadId, topicName);
> consumer.subscribe(Arrays.asList(topicName.split(",")));
> {code}
> Despite the same could be achieved by adding more consumers (rotues) this
> causes a significant amount of load (because of the commits) to kafka, so
> this really helps to improve performance.
> the topic has been already marked as mandatory, so that should keep the
> nullpointer safe.
> @UriParam @Metadata(required = "true")
> private String topic;
> thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9836) Add file id of the gridfs file created in the header of the exchange
Jose Luis Pedrosa created CAMEL-9836:
Summary: Add file id of the gridfs file created in the header of
the exchange
Key: CAMEL-9836
URL: https://issues.apache.org/jira/browse/CAMEL-9836
Project: Camel
Issue Type: Wish
Components: camel-mongodb
Affects Versions: 2.17.0
Environment: Any
Reporter: Jose Luis Pedrosa
Priority: Minor
Currently the camel-mongodb-gridfs component (which is not available in this
Jira) when a file is cretated does not return back the Id (_id) of the file
created, it only returns the filename
{code}
String metaData = exchange.getIn().getHeader(GridFsEndpoint.GRIDFS_METADATA,
String.class);
DBObject dbObject = (DBObject) JSON.parse(metaData);
gfsFile.setMetaData(dbObject);
gfsFile.save();
exchange.getIn().setHeader(Exchange.FILE_NAME_PRODUCED,
gfsFile.getFilename());
{code}
mongodb api has the method getid:
http://api.mongodb.org/java/current/com/mongodb/gridfs/GridFSFile.html#getId--
So i'd like to ask to:
a) create a header field (maybe GridFsEndpoint.GRIDFS_FILE_ID_PRODUCED)
b) Add the header after the creation
{code}
String metaData = exchange.getIn().getHeader(GridFsEndpoint.GRIDFS_METADATA,
String.class);
DBObject dbObject = (DBObject) JSON.parse(metaData);
gfsFile.setMetaData(dbObject);
gfsFile.save();
exchange.getIn().setHeader(Exchange.FILE_NAME_PRODUCED,
gfsFile.getFilename());
exchange.getIn().setHeader(GridFsEndpoint.GRIDFS_FILE_ID_PRODUCED,
gfsFile.getId());
{code}
Of course I can create a PR myself, but I think the administrative work would
be more? Up to you guys.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9837) Camel mail component documentation has BCC and CC options as upper-cased
Tom Cunningham created CAMEL-9837: - Summary: Camel mail component documentation has BCC and CC options as upper-cased Key: CAMEL-9837 URL: https://issues.apache.org/jira/browse/CAMEL-9837 Project: Camel Issue Type: Bug Affects Versions: 2.17.0 Reporter: Tom Cunningham As of 2.17, it appears that "The Mail component now requires to configure to, cc, and bcc using lower case keys, eg to=f...@bar.com, instead of To=f...@bar.com as previously.".The Mail component documentation still refers to these keys in upper case form : http://camel.apache.org/mail.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9837) Camel mail component documentation has BCC and CC options as upper-cased
[ https://issues.apache.org/jira/browse/CAMEL-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230674#comment-15230674 ] David J. M. Karlsen commented on CAMEL-9837: I've fixed it on the wiki: https://cwiki.apache.org/confluence/display/CAMEL/Mail - should appear on the static site in a few hours. The issue can be closed. > Camel mail component documentation has BCC and CC options as upper-cased > > > Key: CAMEL-9837 > URL: https://issues.apache.org/jira/browse/CAMEL-9837 > Project: Camel > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Tom Cunningham > > As of 2.17, it appears that "The Mail component now requires to configure to, > cc, and bcc using lower case keys, eg to=f...@bar.com, instead of > To=f...@bar.com as previously.".The Mail component documentation still > refers to these keys in upper case form : > http://camel.apache.org/mail.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-5980) camel-mail - Better handle null values when extracting attachments
[ https://issues.apache.org/jira/browse/CAMEL-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230807#comment-15230807 ] Rick Johns commented on CAMEL-5980: --- I took a look at this. There are a couple places in MailBinding that can be tweaked to cope with a null file name, but a ParseException is thrown when trying to retrieve the file name parameter list for the ContentDisposition on the message/rfc822 attachment. It looks like we'd just have to catch the exception in MailBinding.extractAttachmentsFromMultipart() and drop the attachment or create a disposition with no parameter list. The tweaks to MailBinding I tried are just to replace a null attachmentFilename in addAttachmentsToMultipart() with an empty string, and to generate a place holder for the null fileName in extractAttachmentsFromMultipart(), because it's used as a map key. What do you think? > camel-mail - Better handle null values when extracting attachments > -- > > Key: CAMEL-5980 > URL: https://issues.apache.org/jira/browse/CAMEL-5980 > Project: Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 2.9.0, 2.10.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > Attachments: EmailExceptionTest.java, EmailTest.java, Exception > Mail.eml, debug_log.txt > > > See nabble > http://camel.465427.n5.nabble.com/MailComponent-s-claim-to-handle-special-mail-multipart-formats-and-attachments-tp5724859.html > We should see if we can fix the Camel code to handle those null data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9838) Add ends with operator to simple language
Jonathan Anstey created CAMEL-9838: -- Summary: Add ends with operator to simple language Key: CAMEL-9838 URL: https://issues.apache.org/jira/browse/CAMEL-9838 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.17.1 We have endsWith available via PredicateBuilder in the Java DSL. Would be nice to have this in simple so it could be used in XML DSL as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9838) Add ends with operator to simple language
[ https://issues.apache.org/jira/browse/CAMEL-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey updated CAMEL-9838: --- Fix Version/s: 2.18.0 > Add ends with operator to simple language > - > > Key: CAMEL-9838 > URL: https://issues.apache.org/jira/browse/CAMEL-9838 > Project: Camel > Issue Type: Improvement >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.17.1, 2.18.0 > > > We have endsWith available via PredicateBuilder in the Java DSL. Would be > nice to have this in simple so it could be used in XML DSL as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9838) Add ends with operator to simple language
[ https://issues.apache.org/jira/browse/CAMEL-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-9838. Resolution: Fixed https://github.com/apache/camel/commit/ff085260d530e7bc5b23c124acdca8094739ee7d > Add ends with operator to simple language > - > > Key: CAMEL-9838 > URL: https://issues.apache.org/jira/browse/CAMEL-9838 > Project: Camel > Issue Type: Improvement >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.17.1 > > > We have endsWith available via PredicateBuilder in the Java DSL. Would be > nice to have this in simple so it could be used in XML DSL as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9802) Camel examples - Make them standalone and import Camel BOM
[ https://issues.apache.org/jira/browse/CAMEL-9802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230970#comment-15230970 ] David Gordon commented on CAMEL-9802: - I like this idea, because I think small, individually deployable examples not only makes the examples easier to experiment with, but it also sort of fits in with the spirit of microservices. I'm willing to help out with this, but I'd like to bounce some thoughts around first before getting too far into refactoring. - Introducing the a BOM component to the individual example POMs eliminates some concerns that are currently handled at the parent (or grandparent) POM level, but just that change alone would not allow us to break away from the hierarchy altogether, right? - I'm interpreting the scope of this issue to be not only introducing the BOM in the example POM, but also any additional refactoring that would eliminate the need for POM inheritance altogether. Am I making the scope too big, or can we generally agree on that interpretation? - For any remaining configurations that are inherited from the parent or grandparent, I think my approach would be to push them down into the individual example POMs, essentially as-is. Am I oversimplifying? - I believe this would end up resulting in a fair amount of repetitive XML across example modules, but given the goals of this enhancement, is that an acceptable thing? > Camel examples - Make them standalone and import Camel BOM > -- > > Key: CAMEL-9802 > URL: https://issues.apache.org/jira/browse/CAMEL-9802 > Project: Camel > Issue Type: Improvement > Components: examples >Reporter: Claus Ibsen > Fix For: Future > > > We should make the Camel examples not use a parent, but use Camel BOM > instead, to make them standalone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-5980) camel-mail - Better handle null values when extracting attachments
[ https://issues.apache.org/jira/browse/CAMEL-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231660#comment-15231660 ] Claus Ibsen commented on CAMEL-5980: Rich yeah that sounds good. You are welcome to work on a patch / PR http://camel.apache.org/contributing > camel-mail - Better handle null values when extracting attachments > -- > > Key: CAMEL-5980 > URL: https://issues.apache.org/jira/browse/CAMEL-5980 > Project: Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 2.9.0, 2.10.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > Attachments: EmailExceptionTest.java, EmailTest.java, Exception > Mail.eml, debug_log.txt > > > See nabble > http://camel.465427.n5.nabble.com/MailComponent-s-claim-to-handle-special-mail-multipart-formats-and-attachments-tp5724859.html > We should see if we can fix the Camel code to handle those null data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9802) Camel examples - Make them standalone and import Camel BOM
[ https://issues.apache.org/jira/browse/CAMEL-9802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231662#comment-15231662 ] Claus Ibsen commented on CAMEL-9802: The example should import the Camel BOM as a dependencyManagement. Something like wildfly-camel does here https://github.com/wildfly-extras/wildfly-camel/blob/master/pom.xml#L169 And then the example should not have a parent, so they are standalone. That should actually be around the same amount of xml - remove parent - add dependency management for Camel BOM > Camel examples - Make them standalone and import Camel BOM > -- > > Key: CAMEL-9802 > URL: https://issues.apache.org/jira/browse/CAMEL-9802 > Project: Camel > Issue Type: Improvement > Components: examples >Reporter: Claus Ibsen > Fix For: Future > > > We should make the Camel examples not use a parent, but use Camel BOM > instead, to make them standalone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9838) Add ends with operator to simple language
[ https://issues.apache.org/jira/browse/CAMEL-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231667#comment-15231667 ] Claus Ibsen commented on CAMEL-9838: Jon can you add the new operation to the operators table at http://camel.apache.org/simple Also I noticed it misses the starts with operator. And maybe some others, so could you double check? > Add ends with operator to simple language > - > > Key: CAMEL-9838 > URL: https://issues.apache.org/jira/browse/CAMEL-9838 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.17.1, 2.18.0 > > > We have endsWith available via PredicateBuilder in the Java DSL. Would be > nice to have this in simple so it could be used in XML DSL as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9838) Add ends with operator to simple language
[ https://issues.apache.org/jira/browse/CAMEL-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9838: --- Component/s: camel-core > Add ends with operator to simple language > - > > Key: CAMEL-9838 > URL: https://issues.apache.org/jira/browse/CAMEL-9838 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.17.1, 2.18.0 > > > We have endsWith available via PredicateBuilder in the Java DSL. Would be > nice to have this in simple so it could be used in XML DSL as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9837) Camel mail component documentation has BCC and CC options as upper-cased
[ https://issues.apache.org/jira/browse/CAMEL-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9837: --- Issue Type: Task (was: Bug) > Camel mail component documentation has BCC and CC options as upper-cased > > > Key: CAMEL-9837 > URL: https://issues.apache.org/jira/browse/CAMEL-9837 > Project: Camel > Issue Type: Task > Components: documentation >Affects Versions: 2.17.0 >Reporter: Tom Cunningham > Fix For: 2.18.0 > > > As of 2.17, it appears that "The Mail component now requires to configure to, > cc, and bcc using lower case keys, eg to=f...@bar.com, instead of > To=f...@bar.com as previously.".The Mail component documentation still > refers to these keys in upper case form : > http://camel.apache.org/mail.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9837) Camel mail component documentation has BCC and CC options as upper-cased
[ https://issues.apache.org/jira/browse/CAMEL-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9837: --- Component/s: documentation > Camel mail component documentation has BCC and CC options as upper-cased > > > Key: CAMEL-9837 > URL: https://issues.apache.org/jira/browse/CAMEL-9837 > Project: Camel > Issue Type: Task > Components: documentation >Affects Versions: 2.17.0 >Reporter: Tom Cunningham >Priority: Trivial > Fix For: 2.18.0 > > > As of 2.17, it appears that "The Mail component now requires to configure to, > cc, and bcc using lower case keys, eg to=f...@bar.com, instead of > To=f...@bar.com as previously.".The Mail component documentation still > refers to these keys in upper case form : > http://camel.apache.org/mail.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9837) Camel mail component documentation has BCC and CC options as upper-cased
[ https://issues.apache.org/jira/browse/CAMEL-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9837: --- Priority: Trivial (was: Major) > Camel mail component documentation has BCC and CC options as upper-cased > > > Key: CAMEL-9837 > URL: https://issues.apache.org/jira/browse/CAMEL-9837 > Project: Camel > Issue Type: Task > Components: documentation >Affects Versions: 2.17.0 >Reporter: Tom Cunningham >Priority: Trivial > Fix For: 2.18.0 > > > As of 2.17, it appears that "The Mail component now requires to configure to, > cc, and bcc using lower case keys, eg to=f...@bar.com, instead of > To=f...@bar.com as previously.".The Mail component documentation still > refers to these keys in upper case form : > http://camel.apache.org/mail.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9837) Camel mail component documentation has BCC and CC options as upper-cased
[ https://issues.apache.org/jira/browse/CAMEL-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9837. Resolution: Fixed Assignee: Claus Ibsen Fix Version/s: 2.18.0 Thanks Tom and David > Camel mail component documentation has BCC and CC options as upper-cased > > > Key: CAMEL-9837 > URL: https://issues.apache.org/jira/browse/CAMEL-9837 > Project: Camel > Issue Type: Task > Components: documentation >Affects Versions: 2.17.0 >Reporter: Tom Cunningham >Assignee: Claus Ibsen >Priority: Trivial > Fix For: 2.18.0 > > > As of 2.17, it appears that "The Mail component now requires to configure to, > cc, and bcc using lower case keys, eg to=f...@bar.com, instead of > To=f...@bar.com as previously.".The Mail component documentation still > refers to these keys in upper case form : > http://camel.apache.org/mail.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9835) Enable kafka consumer to subcribe to multiple topics
[
https://issues.apache.org/jira/browse/CAMEL-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9835:
---
Fix Version/s: 2.18.0
> Enable kafka consumer to subcribe to multiple topics
> -
>
> Key: CAMEL-9835
> URL: https://issues.apache.org/jira/browse/CAMEL-9835
> Project: Camel
> Issue Type: Wish
> Components: camel-kafka
>Affects Versions: 2.17.0
> Environment: Any
>Reporter: Jose Luis Pedrosa
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.17.1, 2.18.0
>
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> Kafka supports that one consumer is subcriber to multple topics. In their api
> when you start the consumer you MUST provide an Array of topics.
> If we look in /java/org/apache/camel/component/kafka/KafkaConsumer.java
> Currently this is the piece of code that starts the subscriber:
> {code}
> LOG.debug("Subscribing {} to topic {}", threadId, topicName);
> consumer.subscribe(Arrays.asList(topicName));
> {code}
> just simply allowing the comma separated topic syntax and replacing one line
> of code (and the documentation) it would be working.
> {code}
> LOG.debug("Subscribing {} to topic {}", threadId, topicName);
> consumer.subscribe(Arrays.asList(topicName.split(",")));
> {code}
> Despite the same could be achieved by adding more consumers (rotues) this
> causes a significant amount of load (because of the commits) to kafka, so
> this really helps to improve performance.
> the topic has been already marked as mandatory, so that should keep the
> nullpointer safe.
> @UriParam @Metadata(required = "true")
> private String topic;
> thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9801) Camel Archetypes - Add Camel BOM as dependency management
[ https://issues.apache.org/jira/browse/CAMEL-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9801. Resolution: Fixed Assignee: Claus Ibsen > Camel Archetypes - Add Camel BOM as dependency management > - > > Key: CAMEL-9801 > URL: https://issues.apache.org/jira/browse/CAMEL-9801 > Project: Camel > Issue Type: Improvement > Components: tooling >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.18.0 > > > We should import the Camel BOM (camel-parent) in the archetypes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
