[jira] [Commented] (CAMEL-12751) http producer - Ignore content length header

2018-08-28 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/CAMEL-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595848#comment-16595848
 ] 

ASF GitHub Bot commented on CAMEL-12751:


GitHub user bobpaulin opened a pull request:

https://github.com/apache/camel/pull/2496

CAMEL-12751 - Added Content-Length Test for incorrect length.

Simple test simulating an incorrect content-length coming into the 
HttpProducer.  This could potentially occur following the marshalling a pretty 
printed HTTP body.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bobpaulin/camel CAMEL-12751

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/2496.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 #2496


commit e883c3495b3ac858017debdaea0091e8541108a3
Author: Bob Paulin 
Date:   2018-08-29T02:13:13Z

CAMEL-12751 - Added Content-Length Test for incorrect length.




> http producer - Ignore content length header
> 
>
> Key: CAMEL-12751
> URL: https://issues.apache.org/jira/browse/CAMEL-12751
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-http, camel-http4
>Reporter: Claus Ibsen
>Priority: Major
>
> When doing eg REST -> HTTP etc then the REST consumer may populate the 
> message with Content-Length header, which gets propagated to the http 
> producer. We should by default ignore those existing headers and calculate 
> the length in the producer based on the message body, eg if string, byte[] 
> etc which AFAIR does today.
> See nabble
> http://camel.465427.n5.nabble.com/Content-Length-Header-being-used-previous-HTTP-Response-td5813376.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12751) http producer - Ignore content length header

2018-08-28 Thread Bob Paulin (JIRA)


[ 
https://issues.apache.org/jira/browse/CAMEL-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595849#comment-16595849
 ] 

Bob Paulin commented on CAMEL-12751:


This logic also exists in 
org.apache.camel.component.http4.HttpEntityConverter.asHttpEntity(InputStream 
in, Exchange exchange)

In my workaround code I remove the Content-Length header before it hits this 
point.  It appears to not send a Content-Length header in this case.  I know 
HTTP 1.1 can work without the Content-Length header but I think this would be 
an issue with HTTP 1.0. 

 

I've added a test to simulate the behavior I'm seeing in 
https://github.com/apache/camel/pull/2496

 

 

> http producer - Ignore content length header
> 
>
> Key: CAMEL-12751
> URL: https://issues.apache.org/jira/browse/CAMEL-12751
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-http, camel-http4
>Reporter: Claus Ibsen
>Priority: Major
>
> When doing eg REST -> HTTP etc then the REST consumer may populate the 
> message with Content-Length header, which gets propagated to the http 
> producer. We should by default ignore those existing headers and calculate 
> the length in the producer based on the message body, eg if string, byte[] 
> etc which AFAIR does today.
> See nabble
> http://camel.465427.n5.nabble.com/Content-Length-Header-being-used-previous-HTTP-Response-td5813376.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12751) http producer - Ignore content length header

2018-08-28 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/CAMEL-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595847#comment-16595847
 ] 

ASF GitHub Bot commented on CAMEL-12751:


bobpaulin opened a new pull request #2496: CAMEL-12751 - Added Content-Length 
Test for incorrect length.
URL: https://github.com/apache/camel/pull/2496
 
 
   Simple test simulating an incorrect content-length coming into the 
HttpProducer.  This could potentially occur following the marshalling a pretty 
printed HTTP body.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> http producer - Ignore content length header
> 
>
> Key: CAMEL-12751
> URL: https://issues.apache.org/jira/browse/CAMEL-12751
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-http, camel-http4
>Reporter: Claus Ibsen
>Priority: Major
>
> When doing eg REST -> HTTP etc then the REST consumer may populate the 
> message with Content-Length header, which gets propagated to the http 
> producer. We should by default ignore those existing headers and calculate 
> the length in the producer based on the message body, eg if string, byte[] 
> etc which AFAIR does today.
> See nabble
> http://camel.465427.n5.nabble.com/Content-Length-Header-being-used-previous-HTTP-Response-td5813376.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12751) http producer - Ignore content length header

2018-08-28 Thread Bob Paulin (JIRA)


[ 
https://issues.apache.org/jira/browse/CAMEL-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595626#comment-16595626
 ] 

Bob Paulin commented on CAMEL-12751:


Similar code exists in 
org.apache.camel.component.jetty.JettyHttpProducer.processInternal 
(Depricated).   

 

 

> http producer - Ignore content length header
> 
>
> Key: CAMEL-12751
> URL: https://issues.apache.org/jira/browse/CAMEL-12751
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-http, camel-http4
>Reporter: Claus Ibsen
>Priority: Major
>
> When doing eg REST -> HTTP etc then the REST consumer may populate the 
> message with Content-Length header, which gets propagated to the http 
> producer. We should by default ignore those existing headers and calculate 
> the length in the producer based on the message body, eg if string, byte[] 
> etc which AFAIR does today.
> See nabble
> http://camel.465427.n5.nabble.com/Content-Length-Header-being-used-previous-HTTP-Response-td5813376.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12751) http producer - Ignore content length header

2018-08-28 Thread Bob Paulin (JIRA)


[ 
https://issues.apache.org/jira/browse/CAMEL-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595611#comment-16595611
 ] 

Bob Paulin commented on CAMEL-12751:


Based on the description if the goal is to simply make the Producer ignore the 
content-length header by default we might look at 
org.apache.camel.component.http4.HttpProducer.createRequestEntity.  I've 
included 2 proposals in comments
{code:java}
// fallback as input stream
    if (answer == null) {
    // force the body as an input stream since this is the 
fallback
    InputStream is = in.getMandatoryBody(InputStream.class);
    String length = in.getHeader(Exchange.CONTENT_LENGTH, 
String.class);
    InputStreamEntity entity = null;


//Proposal 1: Remove this conditional and always 
compute length
//Proposal 2: Keep conditional and add a second flag 
called allowContentLengthOverride that defaults to false.

    if (ObjectHelper.isEmpty(length)) {
    entity = new InputStreamEntity(is, -1);
    } else {
    entity = new InputStreamEntity(is, 
Long.parseLong(length));
    }
    if (contentType != null) {
    entity.setContentType(contentType.toString());
    }
    answer = entity;
    }{code}
Agree that ignoring this header as the default gives expected behavior in most 
cases.

> http producer - Ignore content length header
> 
>
> Key: CAMEL-12751
> URL: https://issues.apache.org/jira/browse/CAMEL-12751
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-http, camel-http4
>Reporter: Claus Ibsen
>Priority: Major
>
> When doing eg REST -> HTTP etc then the REST consumer may populate the 
> message with Content-Length header, which gets propagated to the http 
> producer. We should by default ignore those existing headers and calculate 
> the length in the producer based on the message body, eg if string, byte[] 
> etc which AFAIR does today.
> See nabble
> http://camel.465427.n5.nabble.com/Content-Length-Header-being-used-previous-HTTP-Response-td5813376.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12605) Enhance the AS2 Component to send and receive encrypted AS2 messages

2018-08-28 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/CAMEL-12605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595206#comment-16595206
 ] 

ASF GitHub Bot commented on CAMEL-12605:


GitHub user punkhorn opened a pull request:

https://github.com/apache/camel/pull/2495

[CAMEL-12605] Integrated encryption logic into component.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/punkhorn/camel-upstream master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/2495.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 #2495


commit 5e55c4137bce2b109c544ce1182f915cf074adee
Author: William Collins 
Date:   2018-08-28T15:59:25Z

[CAMEL-12605] Integrated encryption logic into component.




> Enhance the AS2 Component to send and receive encrypted AS2 messages
> 
>
> Key: CAMEL-12605
> URL: https://issues.apache.org/jira/browse/CAMEL-12605
> Project: Camel
>  Issue Type: Improvement
>Affects Versions: 2.23.0
>Reporter: William Collins
>Assignee: William Collins
>Priority: Major
>
> Enhance the AS2 Component to support encrypted AS2 messages per RFC4130



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12605) Enhance the AS2 Component to send and receive encrypted AS2 messages

2018-08-28 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/CAMEL-12605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595205#comment-16595205
 ] 

ASF GitHub Bot commented on CAMEL-12605:


punkhorn opened a new pull request #2495: [CAMEL-12605] Integrated encryption 
logic into component.
URL: https://github.com/apache/camel/pull/2495
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enhance the AS2 Component to send and receive encrypted AS2 messages
> 
>
> Key: CAMEL-12605
> URL: https://issues.apache.org/jira/browse/CAMEL-12605
> Project: Camel
>  Issue Type: Improvement
>Affects Versions: 2.23.0
>Reporter: William Collins
>Assignee: William Collins
>Priority: Major
>
> Enhance the AS2 Component to support encrypted AS2 messages per RFC4130



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-12760) deprecate camel-xmlrpc

2018-08-28 Thread Claus Ibsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-12760.
-
Resolution: Fixed
  Assignee: Claus Ibsen

> deprecate camel-xmlrpc
> --
>
> Key: CAMEL-12760
> URL: https://issues.apache.org/jira/browse/CAMEL-12760
> Project: Camel
>  Issue Type: Task
>  Components: camel-xmlrpc
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.23.0
>
>
> This project is no longer active maintained and last release was from 2010



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (CAMEL-12760) deprecate camel-xmlrpc

2018-08-28 Thread Claus Ibsen (JIRA)
Claus Ibsen created CAMEL-12760:
---

 Summary: deprecate camel-xmlrpc
 Key: CAMEL-12760
 URL: https://issues.apache.org/jira/browse/CAMEL-12760
 Project: Camel
  Issue Type: Task
  Components: camel-xmlrpc
Reporter: Claus Ibsen
 Fix For: 2.23.0


This project is no longer active maintained and last release was from 2010



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (CAMEL-12759) Misleading documentation for Netty components

2018-08-28 Thread Adam Campbell (JIRA)
Adam Campbell created CAMEL-12759:
-

 Summary: Misleading documentation for Netty components
 Key: CAMEL-12759
 URL: https://issues.apache.org/jira/browse/CAMEL-12759
 Project: Camel
  Issue Type: Task
  Components: camel-netty, camel-netty-http, camel-netty4, 
camel-netty4-http
Reporter: Adam Campbell


The documentation currently references "localhost" as the listening address in 
many places. For example:
netty4-http:http://localhost:8080[?options]
Typically the localhost address is only used for the loopback adapter and is 
not accessible externally.

See 
[https://stackoverflow.com/questions/20778771/what-is-the-difference-between-0-0-0-0-127-0-0-1-and-localhost]

Standardizing on "0.0.0.0" in the documentation could prevent a lot of 
confusion for developers who might not be aware of this nuance. It seems like 
localhost is not the correct configuration for the majority of use cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CAMEL-12758) SOAP request causing null namespace URI in SimpleNsStreamWriter camel-cxf/woodstox

2018-08-28 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/CAMEL-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jürgen Fritz updated CAMEL-12758:
-
Description: 
Getting NullPointer at 
com.ctc.wstx.sw.SimpleNsStreamWriter.writeNamespace(+SimpleNsStreamWriter.java:134)+
 because parameter nsURI is null. (full stack trace below)

First call of this method prefix=”soapenv”, nsURI=null

Second call: prefix=”soap”, 
nsURI=="[http://schemas.xmlsoap.org/soap/envelope/]; (I changed the value of 
nsURI in the debugger in the first call to arrive here)

In general: if I change the nsURI in the debugger to the correct value or to an 
empty string,

the request goes through without any error.

Same SOAP request using SOAPUI 5.4 was working with the same application using 
an older version of camel-cxf (2.12.4) under Java 1.7

My SOAP request:

http://schemas.xmlsoap.org/soap/envelope/]; 
xmlns:tss="[http://axpo.ch/emis/v1/TimeseriesService];>
   
    MySourceSystem
    
    
       
     IN1806141130169762894
     NA
     
     
     1234
     MW
     PT15M
     
     
     
     
     
     
       
    


Error stack trace:


com.ctc.wstx.sw.SimpleNsStreamWriter.writeNamespace(+SimpleNsStreamWriter.java:134+
10:27:09,294 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default 
task-118) Application 
\{http://axpo.ch/emis/v1/TimeseriesService}TimeseriesService#\{http://axpo.ch/emis/v1/TimeseriesService}send
 has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Error 
during type conversion from type: 
org.apache.camel.converter.jaxp.XMLStreamReaderInputStream to the required 
type: javax.xml.stream.XMLStreamReader with value 
[org.apache.camel.converter.jaxp.XMLStreamReaderInputStream@9c55922|mailto:org.apache.camel.converter.jaxp.XMLStreamReaderInputStream@9c55922]
 due +java.lang.NullPointerException+
   at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.checkFailure(+CxfConsumer.java:344+)
 [camel-cxf-2.22.0.jar:2.22.0]
   at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.setResponseBack(+CxfConsumer.java:318+)
 [camel-cxf-2.22.0.jar:2.22.0]
   at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(+CxfConsumer.java:244+)
 [camel-cxf-2.22.0.jar:2.22.0]
   at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(+CxfConsumer.java:162+)
 [camel-cxf-2.22.0.jar:2.22.0]
   at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(+ServiceInvokerInterceptor.java:59+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
java.util.concurrent.Executors$RunnableAdapter.call(+Executors.java:511+) 
[rt.jar:1.8.0_144]
  at java.util.concurrent.FutureTask.run(+FutureTask.java:266+) 
[rt.jar:1.8.0_144]
   at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(+ServiceInvokerInterceptor.java:126+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.workqueue.SynchronousExecutor.execute(+SynchronousExecutor.java:37+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(+ServiceInvokerInterceptor.java:131+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(+PhaseInterceptorChain.java:308+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(+ChainInitiationObserver.java:121+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(+AbstractHTTPDestination.java:267+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(+ServletController.java:234+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.ServletController.invoke(+ServletController.java:208+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.ServletController.invoke(+ServletController.java:160+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(+CXFNonSpringServlet.java:216+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(+AbstractHTTPServlet.java:301+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(+AbstractHTTPServlet.java:220+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at javax.servlet.http.HttpServlet.service(+HttpServlet.java:707+) 
[jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
  at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(+AbstractHTTPServlet.java:276+)
 

[jira] [Created] (CAMEL-12758) SOAP request causing null namespace URI in SimpleNsStreamWriter camel-cxf/woodstox

2018-08-28 Thread JIRA
Jürgen Fritz created CAMEL-12758:


 Summary: SOAP request causing null namespace URI in 
SimpleNsStreamWriter camel-cxf/woodstox
 Key: CAMEL-12758
 URL: https://issues.apache.org/jira/browse/CAMEL-12758
 Project: Camel
  Issue Type: Bug
  Components: camel-cxf
Affects Versions: 2.22.0
Reporter: Jürgen Fritz


Getting NullPointer at 
com.ctc.wstx.sw.SimpleNsStreamWriter.writeNamespace(+SimpleNsStreamWriter.java:134)+
 because parameter nsURI is null. (full stack trace below)

First call of this method prefix=”soapenv”, nsURI=null

Second call: prefix=”soap”, 
nsURI=="[http://schemas.xmlsoap.org/soap/envelope/]; (I changed the value of 
nsURI in the debugger in the first call to arrive here)

In general: if I change the nsURI in the debugger to the correct value or to an 
empty string,

the request goes through without any error.

Same SOAP request using SOAPUI 5.4 was working with the same application using 
an older version of camel-cxf under Java 1.7

woodstox-core-5.0.3

camel-cxf 2.22.0

My SOAP request:

http://schemas.xmlsoap.org/soap/envelope/]; 
xmlns:tss="[http://axpo.ch/emis/v1/TimeseriesService];>
   
    MySourceSystem
    
    
       
     IN1806141130169762894
     NA
     
     
     1234
     MW
     PT15M
     
     
     
     
     
     
       
    


Error stack trace:


com.ctc.wstx.sw.SimpleNsStreamWriter.writeNamespace(+SimpleNsStreamWriter.java:134+
10:27:09,294 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default 
task-118) Application 
\{http://axpo.ch/emis/v1/TimeseriesService}TimeseriesService#\{http://axpo.ch/emis/v1/TimeseriesService}send
 has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Error 
during type conversion from type: 
org.apache.camel.converter.jaxp.XMLStreamReaderInputStream to the required 
type: javax.xml.stream.XMLStreamReader with value 
[org.apache.camel.converter.jaxp.XMLStreamReaderInputStream@9c55922|mailto:org.apache.camel.converter.jaxp.XMLStreamReaderInputStream@9c55922]
 due +java.lang.NullPointerException+
   at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.checkFailure(+CxfConsumer.java:344+)
 [camel-cxf-2.22.0.jar:2.22.0]
   at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.setResponseBack(+CxfConsumer.java:318+)
 [camel-cxf-2.22.0.jar:2.22.0]
   at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(+CxfConsumer.java:244+)
 [camel-cxf-2.22.0.jar:2.22.0]
   at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(+CxfConsumer.java:162+)
 [camel-cxf-2.22.0.jar:2.22.0]
   at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(+ServiceInvokerInterceptor.java:59+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
java.util.concurrent.Executors$RunnableAdapter.call(+Executors.java:511+) 
[rt.jar:1.8.0_144]
  at java.util.concurrent.FutureTask.run(+FutureTask.java:266+) 
[rt.jar:1.8.0_144]
   at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(+ServiceInvokerInterceptor.java:126+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.workqueue.SynchronousExecutor.execute(+SynchronousExecutor.java:37+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(+ServiceInvokerInterceptor.java:131+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(+PhaseInterceptorChain.java:308+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(+ChainInitiationObserver.java:121+)
 [cxf-core-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(+AbstractHTTPDestination.java:267+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(+ServletController.java:234+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.ServletController.invoke(+ServletController.java:208+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.ServletController.invoke(+ServletController.java:160+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(+CXFNonSpringServlet.java:216+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(+AbstractHTTPServlet.java:301+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(+AbstractHTTPServlet.java:220+)
 [cxf-rt-transports-http-3.2.5.jar:3.2.5]
   at 

[jira] [Resolved] (CAMEL-12757) add camel-jclouds-starter

2018-08-28 Thread Claus Ibsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-12757.
-
Resolution: Fixed

> add camel-jclouds-starter
> -
>
> Key: CAMEL-12757
> URL: https://issues.apache.org/jira/browse/CAMEL-12757
> Project: Camel
>  Issue Type: Task
>  Components: camel-spring-boot-starters
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.23.0
>
>
> With SB 1 it was a conflict with a gson library. But now with SB2 we can add 
> a jclouds starter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (CAMEL-12757) add camel-jclouds-starter

2018-08-28 Thread Claus Ibsen (JIRA)
Claus Ibsen created CAMEL-12757:
---

 Summary: add camel-jclouds-starter
 Key: CAMEL-12757
 URL: https://issues.apache.org/jira/browse/CAMEL-12757
 Project: Camel
  Issue Type: Task
  Components: camel-spring-boot-starters
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 2.23.0


With SB 1 it was a conflict with a gson library. But now with SB2 we can add a 
jclouds starter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (CAMEL-12756) `@ConditionalOnProperty` target property with no metadata

2018-08-28 Thread Stephane Nicoll (JIRA)
Stephane Nicoll created CAMEL-12756:
---

 Summary: `@ConditionalOnProperty` target property with no metadata
 Key: CAMEL-12756
 URL: https://issues.apache.org/jira/browse/CAMEL-12756
 Project: Camel
  Issue Type: Improvement
  Components: camel-spring-boot
Affects Versions: 2.22.0
Reporter: Stephane Nicoll


 Several auto-configurations use a condition on a property that has no 
metadata. As a result, trying to use it to customize the auto-configuration 
lead to a warning in an IDE.

The report detected the following:
 
{noformat}
org.apache.camel.model.rest.springboot.RestConfigurationDefinitionAutoConfiguration
 [camel.rest.enabled]
org.apache.camel.spring.boot.TypeConversionConfiguration 
[camel.springboot.typeConversion]
{noformat}

For the latter, the property in {{@ConditionalOnProperty}} must use the 
canonical format (i.e. must be {{camel.springboot.type-conversion}})



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-12109) camel-zipkin - Generate tracing identifiers on exchange begin if they do not exist

2018-08-28 Thread Claus Ibsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-12109.
-
   Resolution: Fixed
Fix Version/s: 2.23.0

Thanks for the PR

> camel-zipkin - Generate tracing identifiers on exchange begin if they do not 
> exist
> --
>
> Key: CAMEL-12109
> URL: https://issues.apache.org/jira/browse/CAMEL-12109
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-zipkin
>Reporter: Chris Snyder
>Assignee: Ramu
>Priority: Minor
> Fix For: 2.23.0
>
>
> The current Zipkin instrumentation generates tracing IDs during client 
> requests (in com.github.kristofa.brave.ClientTracer.startNewSpan()). However, 
> it does not do so for server requests (see 
> [ZipkinTracer.ZipkinRoutePolicy.onExchangeBegin()|https://github.com/apache/camel/blob/c6c02ff92a536e78f7ed1b9dd550d6531e852cee/components/camel-zipkin/src/main/java/org/apache/camel/zipkin/ZipkinTracer.java#L753]).
>  This means that if the client does not supply its own tracing headers, 
> nothing will be traced until a client request is made from within Camel.
> This can be demonstrated using the camel-example-zipkin modules by removing 
> the Zipkin instrumentation from the client module. When this is done, the 
> service1 module will not report any spans.
> The [Zipkin documentation|https://zipkin.io/pages/instrumenting.html] 
> indicates that tracing information should be generated when none is present: 
> "When an incoming request has no trace information attached, we generate a 
> random trace ID and span ID."



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12109) camel-zipkin - Generate tracing identifiers on exchange begin if they do not exist

2018-08-28 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/CAMEL-12109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594782#comment-16594782
 ] 

ASF GitHub Bot commented on CAMEL-12109:


Github user davsclaus closed the pull request at:

https://github.com/apache/camel/pull/2494


> camel-zipkin - Generate tracing identifiers on exchange begin if they do not 
> exist
> --
>
> Key: CAMEL-12109
> URL: https://issues.apache.org/jira/browse/CAMEL-12109
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-zipkin
>Reporter: Chris Snyder
>Assignee: Ramu
>Priority: Minor
>
> The current Zipkin instrumentation generates tracing IDs during client 
> requests (in com.github.kristofa.brave.ClientTracer.startNewSpan()). However, 
> it does not do so for server requests (see 
> [ZipkinTracer.ZipkinRoutePolicy.onExchangeBegin()|https://github.com/apache/camel/blob/c6c02ff92a536e78f7ed1b9dd550d6531e852cee/components/camel-zipkin/src/main/java/org/apache/camel/zipkin/ZipkinTracer.java#L753]).
>  This means that if the client does not supply its own tracing headers, 
> nothing will be traced until a client request is made from within Camel.
> This can be demonstrated using the camel-example-zipkin modules by removing 
> the Zipkin instrumentation from the client module. When this is done, the 
> service1 module will not report any spans.
> The [Zipkin documentation|https://zipkin.io/pages/instrumenting.html] 
> indicates that tracing information should be generated when none is present: 
> "When an incoming request has no trace information attached, we generate a 
> random trace ID and span ID."



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (CAMEL-12755) Upgrade Infinispan

2018-08-28 Thread Andrea Cosentino (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino reassigned CAMEL-12755:


Assignee: Claus Ibsen  (was: Andrea Cosentino)

> Upgrade Infinispan
> --
>
> Key: CAMEL-12755
> URL: https://issues.apache.org/jira/browse/CAMEL-12755
> Project: Camel
>  Issue Type: Task
>  Components: camel-infinispan
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.23.0
>
>
> We should upgrade to a newer version, 9.3.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-12755) Upgrade Infinispan

2018-08-28 Thread Andrea Cosentino (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino resolved CAMEL-12755.
--
Resolution: Fixed

> Upgrade Infinispan
> --
>
> Key: CAMEL-12755
> URL: https://issues.apache.org/jira/browse/CAMEL-12755
> Project: Camel
>  Issue Type: Task
>  Components: camel-infinispan
>Reporter: Claus Ibsen
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 2.23.0
>
>
> We should upgrade to a newer version, 9.3.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (CAMEL-12755) Upgrade Infinispan

2018-08-28 Thread Andrea Cosentino (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino reassigned CAMEL-12755:


Assignee: Andrea Cosentino

> Upgrade Infinispan
> --
>
> Key: CAMEL-12755
> URL: https://issues.apache.org/jira/browse/CAMEL-12755
> Project: Camel
>  Issue Type: Task
>  Components: camel-infinispan
>Reporter: Claus Ibsen
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 2.23.0
>
>
> We should upgrade to a newer version, 9.3.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (CAMEL-12755) Upgrade Infinispan

2018-08-28 Thread Claus Ibsen (JIRA)
Claus Ibsen created CAMEL-12755:
---

 Summary: Upgrade Infinispan
 Key: CAMEL-12755
 URL: https://issues.apache.org/jira/browse/CAMEL-12755
 Project: Camel
  Issue Type: Task
  Components: camel-infinispan
Reporter: Claus Ibsen
 Fix For: 2.23.0


We should upgrade to a newer version, 9.3.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-12754) Upgrade Apache Ignite

2018-08-28 Thread Claus Ibsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-12754.
-
Resolution: Fixed

> Upgrade Apache Ignite
> -
>
> Key: CAMEL-12754
> URL: https://issues.apache.org/jira/browse/CAMEL-12754
> Project: Camel
>  Issue Type: Task
>  Components: camel-ignite
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.21.3, 2.22.1, 2.23.0
>
>
> We should upgrade ignite as it has some good fixes needed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (CAMEL-12754) Upgrade Apache Ignite

2018-08-28 Thread Claus Ibsen (JIRA)
Claus Ibsen created CAMEL-12754:
---

 Summary: Upgrade Apache Ignite
 Key: CAMEL-12754
 URL: https://issues.apache.org/jira/browse/CAMEL-12754
 Project: Camel
  Issue Type: Task
  Components: camel-ignite
Reporter: Claus Ibsen
Assignee: Claus Ibsen
 Fix For: 2.21.3, 2.22.1, 2.23.0


We should upgrade ignite as it has some good fixes needed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-12486) Placeholders are not resolved in Simple language while using resource: prefix

2018-08-28 Thread Claus Ibsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-12486.
-
Resolution: Fixed

Thanks for reporting and the unit test

> Placeholders are not resolved in Simple language while using resource: prefix
> -
>
> Key: CAMEL-12486
> URL: https://issues.apache.org/jira/browse/CAMEL-12486
> Project: Camel
>  Issue Type: Wish
>  Components: camel-core
>Reporter: Jan Bednar
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.23.0
>
> Attachments: 
> Allow_dynamic_resource_loading_in_simple_language_failing_test.patch
>
>
> This behavior was found in question 
> https://stackoverflow.com/questions/50063874/load-camels-body-dynamically-depending-on-header
> This is because expression with prefix *resource* is resolved in 
> LanguageSupport#loadResource before property placeholders are resolved. This 
> is reasonable, as placeholders are resolved in expression loaded from file. 
> But it prevents from dynamic resource loading.
> It would be nice to allow property resolution in resource in this way
> {code:java}
> .transform().simple("resource:classpath:${header.myFileName}"){code}
> I would expect this behavior:
>  # Resolve placeholders in expression (now missing)
>  # Load String from resource as new expression (exists)
>  # Resolve placeholders in new expression (exists)
> I have tried to create patch for *SimpleLanguage*, but I failed. Attaching 
> patch to *SimpleResourceTest* with expected behavior based on master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CAMEL-12486) Placeholders are not resolved in Simple language while using resource: prefix

2018-08-28 Thread Claus Ibsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-12486:

Fix Version/s: 2.23.0

> Placeholders are not resolved in Simple language while using resource: prefix
> -
>
> Key: CAMEL-12486
> URL: https://issues.apache.org/jira/browse/CAMEL-12486
> Project: Camel
>  Issue Type: Wish
>  Components: camel-core
>Reporter: Jan Bednar
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.23.0
>
> Attachments: 
> Allow_dynamic_resource_loading_in_simple_language_failing_test.patch
>
>
> This behavior was found in question 
> https://stackoverflow.com/questions/50063874/load-camels-body-dynamically-depending-on-header
> This is because expression with prefix *resource* is resolved in 
> LanguageSupport#loadResource before property placeholders are resolved. This 
> is reasonable, as placeholders are resolved in expression loaded from file. 
> But it prevents from dynamic resource loading.
> It would be nice to allow property resolution in resource in this way
> {code:java}
> .transform().simple("resource:classpath:${header.myFileName}"){code}
> I would expect this behavior:
>  # Resolve placeholders in expression (now missing)
>  # Load String from resource as new expression (exists)
>  # Resolve placeholders in new expression (exists)
> I have tried to create patch for *SimpleLanguage*, but I failed. Attaching 
> patch to *SimpleResourceTest* with expected behavior based on master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (CAMEL-12486) Placeholders are not resolved in Simple language while using resource: prefix

2018-08-28 Thread Claus Ibsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned CAMEL-12486:
---

Assignee: Claus Ibsen

> Placeholders are not resolved in Simple language while using resource: prefix
> -
>
> Key: CAMEL-12486
> URL: https://issues.apache.org/jira/browse/CAMEL-12486
> Project: Camel
>  Issue Type: Wish
>  Components: camel-core
>Reporter: Jan Bednar
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.23.0
>
> Attachments: 
> Allow_dynamic_resource_loading_in_simple_language_failing_test.patch
>
>
> This behavior was found in question 
> https://stackoverflow.com/questions/50063874/load-camels-body-dynamically-depending-on-header
> This is because expression with prefix *resource* is resolved in 
> LanguageSupport#loadResource before property placeholders are resolved. This 
> is reasonable, as placeholders are resolved in expression loaded from file. 
> But it prevents from dynamic resource loading.
> It would be nice to allow property resolution in resource in this way
> {code:java}
> .transform().simple("resource:classpath:${header.myFileName}"){code}
> I would expect this behavior:
>  # Resolve placeholders in expression (now missing)
>  # Load String from resource as new expression (exists)
>  # Resolve placeholders in new expression (exists)
> I have tried to create patch for *SimpleLanguage*, but I failed. Attaching 
> patch to *SimpleResourceTest* with expected behavior based on master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-12546) rest-dsl - Allow to configure rest configuration via spring boot auto configuration

2018-08-28 Thread Claus Ibsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/CAMEL-12546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-12546.
-
Resolution: Fixed
  Assignee: Claus Ibsen

You can do this today, for example in this example
https://github.com/apache/camel/blob/47447cbaecb716b9184eb07c137f87e80538f6cc/examples/camel-example-spring-boot-rest-swagger/src/main/resources/application.properties

> rest-dsl - Allow to configure rest configuration via spring boot auto 
> configuration
> ---
>
> Key: CAMEL-12546
> URL: https://issues.apache.org/jira/browse/CAMEL-12546
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-spring-boot, rest
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.23.0
>
>
> There are some global configurations you can configure on restConfiguration. 
> We should make it possible to configure these via spring boot auto 
> configuration, eg application.properties etc.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12619) camel-swagger-java - Add support for 3.0 spec

2018-08-28 Thread Claus Ibsen (JIRA)


[ 
https://issues.apache.org/jira/browse/CAMEL-12619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594621#comment-16594621
 ] 

Claus Ibsen commented on CAMEL-12619:
-

Blog about whats new in 3.0 spec
https://swagger.io/blog/news/whats-new-in-openapi-3-0/

> camel-swagger-java - Add support for 3.0 spec
> -
>
> Key: CAMEL-12619
> URL: https://issues.apache.org/jira/browse/CAMEL-12619
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-swagger
>Reporter: Claus Ibsen
>Priority: Major
>
> Not sure if we can make swagger v3 generate v2 spec files, so we can be 100% 
> backwards compatible. But v3 openapi 3.0 spec is a different maven GAV so its 
> maybe not an easy upgrade.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)