[jira] [Created] (CAMEL-13593) avoid “expected resource not found” warnings when using camel-mail in OSGi

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-13593:


 Summary: avoid “expected resource not found” warnings when using 
camel-mail in OSGi
 Key: CAMEL-13593
 URL: https://issues.apache.org/jira/browse/CAMEL-13593
 Project: Camel
  Issue Type: Improvement
Reporter: Freeman Fang


In javax.mail API(1.6), it(javax.mail.Session) will use authenticator's 
classloader to load two default files
{code}
META-INF/javamail.default.address.map
META-INF/javamail.default.providers
{code}

Since camel-mail provider a DefaultAuthenticator, which means javax mail api 
will try to use camel-mail bundle classloader in OSGi to load above default 
files. Those files aren't available for camel-mail bundle classloader, so we 
see warning message as
{code}
 2019-04-25 12:42:09,806 | WARN | 23 - scheduler://foo | j.mail | 21 - 
com.sun.mail.javax.mail - 1.6.1 | expected resource not found: 
/META-INF/javamail.default.providers
2019-04-25 12:42:09,807 | WARN | 23 - scheduler://foo | j.mail | 21 - 
com.sun.mail.javax.mail - 1.6.1| expected resource not found: 
/META-INF/javamail.default.address.map
{code}

This warning message isn't harmful but annoying. The javax.mail.Session will 
always add default stuff by code if can't find the default configuration file
{code}
   if (providers.size() == 0) {
logger.config("failed to load any providers, using defaults");
// failed to load any providers, initialize with our defaults
addProvider(new Provider(Provider.Type.STORE,
"imap", "com.sun.mail.imap.IMAPStore",
"Oracle", Version.version));
addProvider(new Provider(Provider.Type.STORE,
"imaps", "com.sun.mail.imap.IMAPSSLStore",
"Oracle", Version.version));
addProvider(new Provider(Provider.Type.STORE,
"pop3", "com.sun.mail.pop3.POP3Store",
"Oracle", Version.version));
addProvider(new Provider(Provider.Type.STORE,
"pop3s", "com.sun.mail.pop3.POP3SSLStore",
"Oracle", Version.version));
addProvider(new Provider(Provider.Type.TRANSPORT,
"smtp", "com.sun.mail.smtp.SMTPTransport",
"Oracle", Version.version));
addProvider(new Provider(Provider.Type.TRANSPORT,
"smtps", "com.sun.mail.smtp.SMTPSSLTransport",
"Oracle", Version.version));
}
   if (addressMap.isEmpty()) {
logger.config("failed to load address map, using defaults");
addressMap.put("rfc822", "smtp");
}
{code}

It's better we can avoid such WARN message when using camel-mail in OSGi



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

[jira] [Resolved] (CAMEL-13376) camel-cxf - failure processor for custom exception handling cannot get the original message

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-13376.
--
   Resolution: Fixed
Fix Version/s: 2.25.0
   2.24.1
   2.22.5
   2.23.3
   3.0.0

> camel-cxf - failure processor for custom exception handling cannot get the 
> original message
> ---
>
> Key: CAMEL-13376
> URL: https://issues.apache.org/jira/browse/CAMEL-13376
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.21.0
> Environment: Redhat Fuse 7.0 (on EAP)
> reproduced with current "camel-example-cxf-proxy" example
>Reporter: Jochen Riedlinger
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.0.0, 2.23.3, 2.22.5, 2.24.1, 2.25.0
>
>
> I configured custom exception handling for a CXF consumer where I want to use 
> my own processor.
>  
>  Lile this:
>  
>  onException(Exception.class)
>             .handled(false)
>             .useOriginalMessage()
>             .process(failureResponseProcessor);
>  
>  or:
>  
>  
>     java.lang.Exception
>     false
>     
> 
> If allowStreaming is enabled on the CXF consumer endpoint, my 
> FailureResponseProcessor cannot get the original body (the body part of 
> CachedCxfPayload seems to be empty).
> If I set allowStreaming to false, the processor works as expected.
> I did a branch on my fork to create this reproducer:
> https://github.com/jochenr/camel/tree/Reproducer-CXF-CustomExceptionHandling-in-StreamingMode/examples/camel-example-cxf-proxy
> If you toggle the setting of allowStreaming between true and false, you see 
> the different output to the console, right after the string
> "This was the original BODY that caused the fault:"



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

[jira] [Commented] (CAMEL-13376) camel-cxf - failure processor for custom exception handling cannot get the original message

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-13376:
--

We need to set the body back to original CxfPayload with cached stream source so
CxfPayload is re-readable

> camel-cxf - failure processor for custom exception handling cannot get the 
> original message
> ---
>
> Key: CAMEL-13376
> URL: https://issues.apache.org/jira/browse/CAMEL-13376
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.21.0
> Environment: Redhat Fuse 7.0 (on EAP)
> reproduced with current "camel-example-cxf-proxy" example
>Reporter: Jochen Riedlinger
>Assignee: Freeman Fang
>Priority: Minor
>
> I configured custom exception handling for a CXF consumer where I want to use 
> my own processor.
>  
>  Lile this:
>  
>  onException(Exception.class)
>             .handled(false)
>             .useOriginalMessage()
>             .process(failureResponseProcessor);
>  
>  or:
>  
>  
>     java.lang.Exception
>     false
>     
> 
> If allowStreaming is enabled on the CXF consumer endpoint, my 
> FailureResponseProcessor cannot get the original body (the body part of 
> CachedCxfPayload seems to be empty).
> If I set allowStreaming to false, the processor works as expected.
> I did a branch on my fork to create this reproducer:
> https://github.com/jochenr/camel/tree/Reproducer-CXF-CustomExceptionHandling-in-StreamingMode/examples/camel-example-cxf-proxy
> If you toggle the setting of allowStreaming between true and false, you see 
> the different output to the console, right after the string
> "This was the original BODY that caused the fault:"



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

[jira] [Assigned] (CAMEL-13376) camel-cxf - failure processor for custom exception handling cannot get the original message

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-13376:


Assignee: Freeman Fang  (was: Tadayoshi Sato)

> camel-cxf - failure processor for custom exception handling cannot get the 
> original message
> ---
>
> Key: CAMEL-13376
> URL: https://issues.apache.org/jira/browse/CAMEL-13376
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.21.0
> Environment: Redhat Fuse 7.0 (on EAP)
> reproduced with current "camel-example-cxf-proxy" example
>Reporter: Jochen Riedlinger
>Assignee: Freeman Fang
>Priority: Minor
>
> I configured custom exception handling for a CXF consumer where I want to use 
> my own processor.
>  
>  Lile this:
>  
>  onException(Exception.class)
>             .handled(false)
>             .useOriginalMessage()
>             .process(failureResponseProcessor);
>  
>  or:
>  
>  
>     java.lang.Exception
>     false
>     
> 
> If allowStreaming is enabled on the CXF consumer endpoint, my 
> FailureResponseProcessor cannot get the original body (the body part of 
> CachedCxfPayload seems to be empty).
> If I set allowStreaming to false, the processor works as expected.
> I did a branch on my fork to create this reproducer:
> https://github.com/jochenr/camel/tree/Reproducer-CXF-CustomExceptionHandling-in-StreamingMode/examples/camel-example-cxf-proxy
> If you toggle the setting of allowStreaming between true and false, you see 
> the different output to the console, right after the string
> "This was the original BODY that caused the fault:"



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

[jira] [Resolved] (CAMEL-13576) avoid adding cxf message context map into camel exchange

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-13576.
--
   Resolution: Fixed
Fix Version/s: 2.25.0
   2.24.1
   2.22.5
   2.23.3
   3.0.0

> avoid adding cxf message context map into camel exchange
> 
>
> Key: CAMEL-13576
> URL: https://issues.apache.org/jira/browse/CAMEL-13576
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.0.0, 2.23.3, 2.22.5, 2.24.1, 2.25.0
>
>
> which can easily cause ConcurrentModificationException under high load



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

[jira] [Assigned] (CAMEL-13576) avoid adding cxf message context map into camel exchange

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-13576:


Assignee: Freeman Fang

> avoid adding cxf message context map into camel exchange
> 
>
> Key: CAMEL-13576
> URL: https://issues.apache.org/jira/browse/CAMEL-13576
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> which can easily cause ConcurrentModificationException under high load



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

[jira] [Created] (CAMEL-13576) avoid adding cxf message context map into camel exchange

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-13576:


 Summary: avoid adding cxf message context map into camel exchange
 Key: CAMEL-13576
 URL: https://issues.apache.org/jira/browse/CAMEL-13576
 Project: Camel
  Issue Type: Bug
Reporter: Freeman Fang


which can easily cause ConcurrentModificationException under high load



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

[jira] [Resolved] (CAMEL-13357) Regression - Namespaces defined on the SOAP envelope get lost in PAYLOAD mode

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-13357.
--
   Resolution: Fixed
Fix Version/s: 2.22.4
   2.23.2
   3.0.0

> Regression - Namespaces defined on the SOAP envelope get lost in PAYLOAD mode
> -
>
> Key: CAMEL-13357
> URL: https://issues.apache.org/jira/browse/CAMEL-13357
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Reporter: Jochen Riedlinger
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.0.0, 2.23.2, 2.22.4
>
> Attachments: ReproducerException.log
>
>
> If a request message is send to a CXF consumer or a response is returned to 
> the CXF provider that contains namespace definions at the SOAP envelope and 
> the Camel-CXF endpoint is configured in PAYLOAD mode the namespace definition 
> gets lost unless streaming is disabled.
> If the resulting CxfPayload is then converted e.g. to String that String will 
> contain invalid XML (because some namespace definition is missing).
> For non-streaming mode (system property 
> org.apache.camel.component.cxf.streaming is set to false) there are special 
> precautions met to set these envelope namespaces on the first DOM element of 
> the payload but this coding is missing for StAX.
> The messages in question look like that:
> http://schemas.xmlsoap.org/soap/envelope/"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>   
> http://camel.apache.org/cxf/namespace";>
>   Return Value
> 
>   
> 
> If the CxfPayload is converted to String it will lack the definition for the 
> xsi namespace prefix (and further XML parsing will fail).



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

[jira] [Assigned] (CAMEL-13357) Regression - Namespaces defined on the SOAP envelope get lost in PAYLOAD mode

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-13357:


Assignee: Freeman Fang

> Regression - Namespaces defined on the SOAP envelope get lost in PAYLOAD mode
> -
>
> Key: CAMEL-13357
> URL: https://issues.apache.org/jira/browse/CAMEL-13357
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Reporter: Jochen Riedlinger
>Assignee: Freeman Fang
>Priority: Major
> Attachments: ReproducerException.log
>
>
> If a request message is send to a CXF consumer or a response is returned to 
> the CXF provider that contains namespace definions at the SOAP envelope and 
> the Camel-CXF endpoint is configured in PAYLOAD mode the namespace definition 
> gets lost unless streaming is disabled.
> If the resulting CxfPayload is then converted e.g. to String that String will 
> contain invalid XML (because some namespace definition is missing).
> For non-streaming mode (system property 
> org.apache.camel.component.cxf.streaming is set to false) there are special 
> precautions met to set these envelope namespaces on the first DOM element of 
> the payload but this coding is missing for StAX.
> The messages in question look like that:
> http://schemas.xmlsoap.org/soap/envelope/"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>   
> http://camel.apache.org/cxf/namespace";>
>   Return Value
> 
>   
> 
> If the CxfPayload is converted to String it will lack the definition for the 
> xsi namespace prefix (and further XML parsing will fail).



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

[jira] [Resolved] (CAMEL-12914) camel-rest-swagger - Unit test fails after jetty upgrade

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12914.
--
   Resolution: Fixed
Fix Version/s: (was: 2.22.3)
   (was: 2.21.4)

> camel-rest-swagger - Unit test fails after jetty upgrade
> 
>
> Key: CAMEL-12914
> URL: https://issues.apache.org/jira/browse/CAMEL-12914
> Project: Camel
>  Issue Type: Test
>Reporter: Claus Ibsen
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.23.0
>
>
> After the recent jetty upgrade to 9.4.12 then unit tests fails in 
> camel-rest-swagger due to what looks like a chiper suite no longer available 
> and all the https tests fails.



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

[jira] [Commented] (CAMEL-12914) camel-rest-swagger - Unit test fails after jetty upgrade

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12914:
--

fixed on master and camel 2.22, 2.21 don't have such HTTPS test

> camel-rest-swagger - Unit test fails after jetty upgrade
> 
>
> Key: CAMEL-12914
> URL: https://issues.apache.org/jira/browse/CAMEL-12914
> Project: Camel
>  Issue Type: Test
>Reporter: Claus Ibsen
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.23.0
>
>
> After the recent jetty upgrade to 9.4.12 then unit tests fails in 
> camel-rest-swagger due to what looks like a chiper suite no longer available 
> and all the https tests fails.



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

[jira] [Comment Edited] (CAMEL-12914) camel-rest-swagger - Unit test fails after jetty upgrade

[Freeman Fang (JIRA)]

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

Freeman Fang edited comment on CAMEL-12914 at 11/6/18 10:41 AM:


should be caused by this change
https://github.com/eclipse/jetty.project/issues/2807
the weak/insecure cipher TLS_RSA* was removed


was (Author: ffang):
should be caused by this change
https://github.com/eclipse/jetty.project/issues/2807

> camel-rest-swagger - Unit test fails after jetty upgrade
> 
>
> Key: CAMEL-12914
> URL: https://issues.apache.org/jira/browse/CAMEL-12914
> Project: Camel
>  Issue Type: Test
>Reporter: Claus Ibsen
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.4, 2.22.3, 2.23.0
>
>
> After the recent jetty upgrade to 9.4.12 then unit tests fails in 
> camel-rest-swagger due to what looks like a chiper suite no longer available 
> and all the https tests fails.



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

[jira] [Commented] (CAMEL-12914) camel-rest-swagger - Unit test fails after jetty upgrade

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12914:
--

should be caused by this change
https://github.com/eclipse/jetty.project/issues/2807

> camel-rest-swagger - Unit test fails after jetty upgrade
> 
>
> Key: CAMEL-12914
> URL: https://issues.apache.org/jira/browse/CAMEL-12914
> Project: Camel
>  Issue Type: Test
>Reporter: Claus Ibsen
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.4, 2.22.3, 2.23.0
>
>
> After the recent jetty upgrade to 9.4.12 then unit tests fails in 
> camel-rest-swagger due to what looks like a chiper suite no longer available 
> and all the https tests fails.



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

[jira] [Assigned] (CAMEL-12914) camel-rest-swagger - Unit test fails after jetty upgrade

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12914:


Assignee: Freeman Fang

> camel-rest-swagger - Unit test fails after jetty upgrade
> 
>
> Key: CAMEL-12914
> URL: https://issues.apache.org/jira/browse/CAMEL-12914
> Project: Camel
>  Issue Type: Test
>Reporter: Claus Ibsen
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.4, 2.22.3, 2.23.0
>
>
> After the recent jetty upgrade to 9.4.12 then unit tests fails in 
> camel-rest-swagger due to what looks like a chiper suite no longer available 
> and all the https tests fails.



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

[jira] [Resolved] (CAMEL-12911) gzip Content-Encoding problems after upgrading to Jetty 9.4.12

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12911.
--
   Resolution: Fixed
Fix Version/s: 2.23.0
   2.22.3
   2.21.4

> gzip Content-Encoding problems after upgrading to Jetty 9.4.12
> --
>
> Key: CAMEL-12911
> URL: https://issues.apache.org/jira/browse/CAMEL-12911
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http, camel-jetty
>Affects Versions: 2.22.1
>Reporter: Grzegorz Grzybek
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.4, 2.22.3, 2.23.0
>
>
> After upgrading to Jetty {{9.4.12.v20180830}}, some tests stopped working:
> * 
> org.apache.camel.component.jetty.JettyContentTypeTest.testContentTypeWithGZipEncoding(org.apache.camel.component.jetty.JettyContentTypeTest)
> * 
> org.apache.camel.component.jetty.JettyImageFileTest.testImageContentWithGZip(org.apache.camel.component.jetty.JettyImageFileTest)
> * 
> org.apache.camel.component.jetty.HttpGZipEncodingTest.testGzipProducerWithGzipData(org.apache.camel.component.jetty.HttpGZipEncodingTest)
> * 
> org.apache.camel.component.jetty.HttpGZipEncodingTest.testGzipProxy(org.apache.camel.component.jetty.HttpGZipEncodingTest)
> * 
> org.apache.camel.component.jetty.HttpGZipEncodingTest.testHttpProducerWithGzip(org.apache.camel.component.jetty.HttpGZipEncodingTest)
> I did some analysis on jetty side and the reason is [exactly this 
> commit|https://github.com/eclipse/jetty.project/commit/cf3681ef568be2fea41e89b2937112a7474c5c07]
>  for Jetty issue [1688|https://github.com/eclipse/jetty.project/issues/1688] 
> where this was added to 
> {{jetty-server/src/main/java/org/eclipse/jetty/server/Request.java}}:
> {code:xml}
> private void extractContentParameters()
> {
> // Content cannot be encoded
> if (_metaData!=null && 
> getHttpFields().contains(HttpHeader.CONTENT_ENCODING))
> throw new 
> BadMessageException(HttpStatus.NOT_IMPLEMENTED_501,"Unsupported 
> Content-Encoding");
> ...
> {code}
> With Jetty 9.4.11, it's Camel that does gzip encoding (when creating http 
> entity for httpclient 3) and decoding (when reading http body in 
> {{org.apache.camel.http.common.DefaultHttpBinding#readRequest()}}).
> However, with 9.4.12, after 
> {{org.apache.camel.http.common.DefaultHttpBinding#readRequest()}} has read 
> the body, it calls 
> {{org.apache.camel.http.common.DefaultHttpBinding#readHeaders()}} which also 
> extracts parameters.
> Because parameters may be POSTed using {{application/x-www-form-urlencoded}} 
> content type, Jetty really needs GZIP Handler.
> So far tests worked, because we didn't use 
> {{application/x-www-form-urlencoded}} content type.
> I'm not sure how to solve, but maybe, 
> {{org.apache.camel.http.common.DefaultHttpBinding#readRequest()}} should 
> remove {{Content-Encoding: gzip}} header after reading body? IMO, gzip 
> decoding should be done at "server side" and jetty is the server - so either 
> it decodes gzip content (using configured 
> {{org.eclipse.jetty.server.handler.gzip.GzipHandler}}) or it should not be 
> aware of encoded body (thus camel should pass wrapped request with 
> {{Content-Encoding}} header filtered.



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

[jira] [Assigned] (CAMEL-12911) gzip Content-Encoding problems after upgrading to Jetty 9.4.12

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12911:


Assignee: Freeman Fang  (was: Andrea Cosentino)

> gzip Content-Encoding problems after upgrading to Jetty 9.4.12
> --
>
> Key: CAMEL-12911
> URL: https://issues.apache.org/jira/browse/CAMEL-12911
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http, camel-jetty
>Affects Versions: 2.22.1
>Reporter: Grzegorz Grzybek
>Assignee: Freeman Fang
>Priority: Major
>
> After upgrading to Jetty {{9.4.12.v20180830}}, some tests stopped working:
> * 
> org.apache.camel.component.jetty.JettyContentTypeTest.testContentTypeWithGZipEncoding(org.apache.camel.component.jetty.JettyContentTypeTest)
> * 
> org.apache.camel.component.jetty.JettyImageFileTest.testImageContentWithGZip(org.apache.camel.component.jetty.JettyImageFileTest)
> * 
> org.apache.camel.component.jetty.HttpGZipEncodingTest.testGzipProducerWithGzipData(org.apache.camel.component.jetty.HttpGZipEncodingTest)
> * 
> org.apache.camel.component.jetty.HttpGZipEncodingTest.testGzipProxy(org.apache.camel.component.jetty.HttpGZipEncodingTest)
> * 
> org.apache.camel.component.jetty.HttpGZipEncodingTest.testHttpProducerWithGzip(org.apache.camel.component.jetty.HttpGZipEncodingTest)
> I did some analysis on jetty side and the reason is [exactly this 
> commit|https://github.com/eclipse/jetty.project/commit/cf3681ef568be2fea41e89b2937112a7474c5c07]
>  for Jetty issue [1688|https://github.com/eclipse/jetty.project/issues/1688] 
> where this was added to 
> {{jetty-server/src/main/java/org/eclipse/jetty/server/Request.java}}:
> {code:xml}
> private void extractContentParameters()
> {
> // Content cannot be encoded
> if (_metaData!=null && 
> getHttpFields().contains(HttpHeader.CONTENT_ENCODING))
> throw new 
> BadMessageException(HttpStatus.NOT_IMPLEMENTED_501,"Unsupported 
> Content-Encoding");
> ...
> {code}
> With Jetty 9.4.11, it's Camel that does gzip encoding (when creating http 
> entity for httpclient 3) and decoding (when reading http body in 
> {{org.apache.camel.http.common.DefaultHttpBinding#readRequest()}}).
> However, with 9.4.12, after 
> {{org.apache.camel.http.common.DefaultHttpBinding#readRequest()}} has read 
> the body, it calls 
> {{org.apache.camel.http.common.DefaultHttpBinding#readHeaders()}} which also 
> extracts parameters.
> Because parameters may be POSTed using {{application/x-www-form-urlencoded}} 
> content type, Jetty really needs GZIP Handler.
> So far tests worked, because we didn't use 
> {{application/x-www-form-urlencoded}} content type.
> I'm not sure how to solve, but maybe, 
> {{org.apache.camel.http.common.DefaultHttpBinding#readRequest()}} should 
> remove {{Content-Encoding: gzip}} header after reading body? IMO, gzip 
> decoding should be done at "server side" and jetty is the server - so either 
> it decodes gzip content (using configured 
> {{org.eclipse.jetty.server.handler.gzip.GzipHandler}}) or it should not be 
> aware of encoded body (thus camel should pass wrapped request with 
> {{Content-Encoding}} header filtered.



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

[jira] [Resolved] (CAMEL-12870) make cxf consumer endpoints suspendable

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12870.
--
Resolution: Fixed

> make cxf consumer endpoints suspendable
> ---
>
> Key: CAMEL-12870
> URL: https://issues.apache.org/jira/browse/CAMEL-12870
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf, camel-cxfrs
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.3, 2.22.2, 2.23.0
>
>
> Currently both CxfConsumer and CxfRsConsumer are SuspendableService, however 
> they don't implements Suspendable interface, which means in 
> DefaultShutdownStrategy, when catching kill signal, those consumer endpoints 
> will be shutdown immediately. So even though inflight and pending exchanges 
> are completed, they have no change to return to client since CXF Consumer 
> endpoints already shutdown. 
> We should make cxf consumer endpoints suspendable to support graceful shutdown



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

[jira] [Assigned] (CAMEL-12870) make cxf consumer endpoints suspendable

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12870:


Assignee: Freeman Fang

> make cxf consumer endpoints suspendable
> ---
>
> Key: CAMEL-12870
> URL: https://issues.apache.org/jira/browse/CAMEL-12870
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf, camel-cxfrs
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.3, 2.22.2, 2.23.0
>
>
> Currently both CxfConsumer and CxfRsConsumer are SuspendableService, however 
> they don't implements Suspendable interface, which means in 
> DefaultShutdownStrategy, when catching kill signal, those consumer endpoints 
> will be shutdown immediately. So even though inflight and pending exchanges 
> are completed, they have no change to return to client since CXF Consumer 
> endpoints already shutdown. 
> We should make cxf consumer endpoints suspendable to support graceful shutdown



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

[jira] [Updated] (CAMEL-12870) make cxf consumer endpoints suspendable

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12870:
-
Fix Version/s: 2.23.0
   2.22.2
   2.21.3

> make cxf consumer endpoints suspendable
> ---
>
> Key: CAMEL-12870
> URL: https://issues.apache.org/jira/browse/CAMEL-12870
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf, camel-cxfrs
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.3, 2.22.2, 2.23.0
>
>
> Currently both CxfConsumer and CxfRsConsumer are SuspendableService, however 
> they don't implements Suspendable interface, which means in 
> DefaultShutdownStrategy, when catching kill signal, those consumer endpoints 
> will be shutdown immediately. So even though inflight and pending exchanges 
> are completed, they have no change to return to client since CXF Consumer 
> endpoints already shutdown. 
> We should make cxf consumer endpoints suspendable to support graceful shutdown



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

[jira] [Created] (CAMEL-12870) make cxf consumer endpoints suspendable

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12870:


 Summary: make cxf consumer endpoints suspendable
 Key: CAMEL-12870
 URL: https://issues.apache.org/jira/browse/CAMEL-12870
 Project: Camel
  Issue Type: Bug
  Components: camel-cxf, camel-cxfrs
Reporter: Freeman Fang


Currently both CxfConsumer and CxfRsConsumer are SuspendableService, however 
they don't implements Suspendable interface, which means in 
DefaultShutdownStrategy, when catching kill signal, those consumer endpoints 
will be shutdown immediately. So even though inflight and pending exchanges are 
completed, they have no change to return to client since CXF Consumer endpoints 
already shutdown. 

We should make cxf consumer endpoints suspendable to support graceful shutdown



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

[jira] [Resolved] (CAMEL-12843) CamelContext Start command shouldn't start a Suspended context

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12843.
--
Resolution: Fixed

> CamelContext Start command shouldn't start a Suspended context
> --
>
> Key: CAMEL-12843
> URL: https://issues.apache.org/jira/browse/CAMEL-12843
> Project: Camel
>  Issue Type: Bug
>  Components: karaf
>Affects Versions: 2.21.0, 2.22.0
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 2.21.3, 2.22.2, 2.23.0
>
> Attachments: CAMEL-12843.patch
>
>
> We found this problem in Karaf camel command, but think it should also exist 
> in other camel command usecases.
> In Karaf
> {code:java}
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Started   0  0  0   
> 1.366 seconds  
> karaf@root()> camel:context-suspend camel-1
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Suspended 0  0  0   
> 7.554 seconds  
> karaf@root()> camel:context-start camel-1 
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime
>  -----  ---    --   
> --
>  camel-1Started   0  0  0   2 
> minutes
> {code}
> So after start a suspended context, there is still one in context-list. But 
> in JMX tree there are two camel-1 context. This mismatch should be addressed. 
> Either improve ContextList command or if it's a suspended context, throw a 
> RuntimeException and let users resume it other than starting it.



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

[jira] [Commented] (CAMEL-12843) CamelContext Start command shouldn't start a Suspended context

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12843:
--

Thanks [~davsclaus]!

Will revise accordingly.

> CamelContext Start command shouldn't start a Suspended context
> --
>
> Key: CAMEL-12843
> URL: https://issues.apache.org/jira/browse/CAMEL-12843
> Project: Camel
>  Issue Type: Bug
>  Components: karaf
>Affects Versions: 2.21.0, 2.22.0
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 2.21.3, 2.22.2, 2.23.0
>
> Attachments: CAMEL-12843.patch
>
>
> We found this problem in Karaf camel command, but think it should also exist 
> in other camel command usecases.
> In Karaf
> {code:java}
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Started   0  0  0   
> 1.366 seconds  
> karaf@root()> camel:context-suspend camel-1
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Suspended 0  0  0   
> 7.554 seconds  
> karaf@root()> camel:context-start camel-1 
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime
>  -----  ---    --   
> --
>  camel-1Started   0  0  0   2 
> minutes
> {code}
> So after start a suspended context, there is still one in context-list. But 
> in JMX tree there are two camel-1 context. This mismatch should be addressed. 
> Either improve ContextList command or if it's a suspended context, throw a 
> RuntimeException and let users resume it other than starting it.



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

[jira] [Assigned] (CAMEL-12843) CamelContext Start command shouldn't start a Suspended context

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12843:


Assignee: Freeman Fang

> CamelContext Start command shouldn't start a Suspended context
> --
>
> Key: CAMEL-12843
> URL: https://issues.apache.org/jira/browse/CAMEL-12843
> Project: Camel
>  Issue Type: Bug
>  Components: karaf
>Affects Versions: 2.21.0, 2.22.0
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 2.21.3, 2.22.2, 2.23.0
>
> Attachments: CAMEL-12843.patch
>
>
> We found this problem in Karaf camel command, but think it should also exist 
> in other camel command usecases.
> In Karaf
> {code:java}
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Started   0  0  0   
> 1.366 seconds  
> karaf@root()> camel:context-suspend camel-1
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Suspended 0  0  0   
> 7.554 seconds  
> karaf@root()> camel:context-start camel-1 
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime
>  -----  ---    --   
> --
>  camel-1Started   0  0  0   2 
> minutes
> {code}
> So after start a suspended context, there is still one in context-list. But 
> in JMX tree there are two camel-1 context. This mismatch should be addressed. 
> Either improve ContextList command or if it's a suspended context, throw a 
> RuntimeException and let users resume it other than starting it.



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

[jira] [Commented] (CAMEL-12843) CamelContext Start command shouldn't start a Suspended context

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12843:
--

Attached a proposal fix.
[~davsclaus], is this change OK, would it affect other cases outside Karaf? Or 
instead of the RuntimeException, shall we just resume a suspended camelcontext 
when even users use  start command? 

Thanks!

> CamelContext Start command shouldn't start a Suspended context
> --
>
> Key: CAMEL-12843
> URL: https://issues.apache.org/jira/browse/CAMEL-12843
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Priority: Major
> Attachments: CAMEL-12843.patch
>
>
> We found this problem in Karaf camel command, but think it should also exist 
> in other camel command usecases.
> In Karaf
> {code}
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Started   0  0  0   
> 1.366 seconds  
> karaf@root()> camel:context-suspend camel-1
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Suspended 0  0  0   
> 7.554 seconds  
> karaf@root()> camel:context-start camel-1 
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime
>  -----  ---    --   
> --
>  camel-1Started   0  0  0   2 
> minutes
> {code}
> So after start a suspended context, there is still one in context-list. But 
> in JMX tree there are two camel-1 context. This mismatch should be addressed. 
> Either improve ContextList command or if it's a suspended context, throw a 
> RuntimeException and let users resume it other than starting it.



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

[jira] [Updated] (CAMEL-12843) CamelContext Start command shouldn't start a Suspended context

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12843:
-
Attachment: CAMEL-12843.patch

> CamelContext Start command shouldn't start a Suspended context
> --
>
> Key: CAMEL-12843
> URL: https://issues.apache.org/jira/browse/CAMEL-12843
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Priority: Major
> Attachments: CAMEL-12843.patch
>
>
> We found this problem in Karaf camel command, but think it should also exist 
> in other camel command usecases.
> In Karaf
> {code}
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Started   0  0  0   
> 1.366 seconds  
> karaf@root()> camel:context-suspend camel-1
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Suspended 0  0  0   
> 7.554 seconds  
> karaf@root()> camel:context-start camel-1 
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime
>  -----  ---    --   
> --
>  camel-1Started   0  0  0   2 
> minutes
> {code}
> So after start a suspended context, there is still one in context-list. But 
> in JMX tree there are two camel-1 context. This mismatch should be addressed. 
> Either improve ContextList command or if it's a suspended context, throw a 
> RuntimeException and let users resume it other than starting it.



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

[jira] [Updated] (CAMEL-12843) CamelContext Start command shouldn't start a Suspended context

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12843:
-
Description: 
We found this problem in Karaf camel command, but think it should also exist in 
other camel command usecases.

In Karaf
{code}
karaf@root()> camel:context-list
 ContextStatus  Total #   Failed # Inflight #   
Uptime 
 -----  ---    --   
-- 
 camel-1Started   0  0  0   
1.366 seconds  
karaf@root()> camel:context-suspend camel-1
karaf@root()> camel:context-list
 ContextStatus  Total #   Failed # Inflight #   
Uptime 
 -----  ---    --   
-- 
 camel-1Suspended 0  0  0   
7.554 seconds  
karaf@root()> camel:context-start camel-1 
karaf@root()> camel:context-list
 ContextStatus  Total #   Failed # Inflight #   
Uptime
 -----  ---    --   
--
 camel-1Started   0  0  0   2 
minutes
{code}
So after start a suspended context, there is still one in context-list. But in 
JMX tree there are two camel-1 context. This mismatch should be addressed. 
Either improve ContextList command or if it's a suspended context, throw a 
RuntimeException and let users resume it other than starting it.

  was:
We found this problem in Karaf camel command, but think it should also exist in 
other camel command usecases.

In Karaf
{code}
karaf@root()> camel:context-list
 ContextStatus  Total #   Failed # Inflight #   
Uptime 
 -----  ---    --   
-- 
 camel-1Started   0  0  0   
1.366 seconds  
karaf@root()> camel:context-suspend camel-1
karaf@root()> camel:context-list
 ContextStatus  Total #   Failed # Inflight #   
Uptime 
 -----  ---    --   
-- 
 camel-1Suspended 0  0  0   
7.554 seconds  
karaf@root()> camel:context-st
camel:context-start(Start a 
Camel context)
camel:context-stop (Stop a Camel context. It becomes unavailable and can not be 
started again)
karaf@root()> camel:context-start camel-1 
karaf@root()> camel:context-list
 ContextStatus  Total #   Failed # Inflight #   
Uptime
 -----  ---    --   
--
 camel-1Started   0  0  0   2 
minutes
{code}
So after start a suspended context, there is still one in context-list. But in 
JMX tree there are two camel-1 context. This mismatch should be addressed. 
Either improve ContextList command or if it's a suspended context, throw a 
RuntimeException and let users resume it other than starting it.


> CamelContext Start command shouldn't start a Suspended context
> --
>
> Key: CAMEL-12843
> URL: https://issues.apache.org/jira/browse/CAMEL-12843
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Priority: Major
>
> We found this problem in Karaf camel command, but think it should also exist 
> in other camel command usecases.
> In Karaf
> {code}
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Started   0  0  0   
> 1.366 seconds  
> karaf@root()> camel:context-suspend camel-1
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime 
>  -----  ---    --   
> -- 
>  camel-1Suspended 0  0  0   
> 7.554 seconds  
> karaf@root()> camel:context-start camel-1 
> karaf@root()> camel:context-list
>  ContextStatus  Total #   Failed # Inflight #   
> Uptime
>  -----  ---    --   
> --
>  camel-1Started   0  0  0   2 
> minutes
> {code}
> So after start a suspended context, there is still one in context-list. But 
> in JMX 

[jira] [Created] (CAMEL-12843) CamelContext Start command shouldn't start a Suspended context

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12843:


 Summary: CamelContext Start command shouldn't start a Suspended 
context
 Key: CAMEL-12843
 URL: https://issues.apache.org/jira/browse/CAMEL-12843
 Project: Camel
  Issue Type: Bug
Reporter: Freeman Fang


We found this problem in Karaf camel command, but think it should also exist in 
other camel command usecases.

In Karaf
{code}
karaf@root()> camel:context-list
 ContextStatus  Total #   Failed # Inflight #   
Uptime 
 -----  ---    --   
-- 
 camel-1Started   0  0  0   
1.366 seconds  
karaf@root()> camel:context-suspend camel-1
karaf@root()> camel:context-list
 ContextStatus  Total #   Failed # Inflight #   
Uptime 
 -----  ---    --   
-- 
 camel-1Suspended 0  0  0   
7.554 seconds  
karaf@root()> camel:context-st
camel:context-start(Start a 
Camel context)
camel:context-stop (Stop a Camel context. It becomes unavailable and can not be 
started again)
karaf@root()> camel:context-start camel-1 
karaf@root()> camel:context-list
 ContextStatus  Total #   Failed # Inflight #   
Uptime
 -----  ---    --   
--
 camel-1Started   0  0  0   2 
minutes
{code}
So after start a suspended context, there is still one in context-list. But in 
JMX tree there are two camel-1 context. This mismatch should be addressed. 
Either improve ContextList command or if it's a suspended context, throw a 
RuntimeException and let users resume it other than starting it.



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

[jira] [Resolved] (CAMEL-12679) ensure camel-xmlsecurity can try key directly to decrypt message

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12679.
--
   Resolution: Fixed
Fix Version/s: 2.23.0

> ensure camel-xmlsecurity can try key directly to decrypt message
> 
>
> Key: CAMEL-12679
> URL: https://issues.apache.org/jira/browse/CAMEL-12679
> Project: Camel
>  Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.23.0
>
>
> If there is no EncryptedKey can be used,try the key directly to decrypt 
> message as fallback
> As both message
> {code}
> http://www.w3.org/2001/04/xmlenc#"; 
> Type="http://www.w3.org/2001/04/xmlenc#Element";> Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> xmlns:ds="http://www.w3.org/2000/09/xmldsig#";> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";> Algorithm="http://www.w3.org/2001/04/xmlenc#kw-tripledes"/>/5nDlLI7jrETNrNG/5Nsw3qB9dSnZVwyj5OZZsUvZaHb/8oIayoMeg==yP17O2otQdraY+W42w8i8U/pQQac1g84vWaGWqbS1tgCduFfjhnIz2ZqbFJ6n7Ow1cIeF5HyAoHRGaoDd4gbVw==
> {code}
> {code}
> 
>Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc";>
> 168
>   
>   
> mykey
>   
>   
> 
> yP17O2otQdraY+W42w8i8U/pQQac1g84vWaGWqbS1tgCduFfjhnIz2ZqbFJ6n7Ow1cIeF5HyAoHRGaoDd4gbVw==
>   
> 
> {code}
> are valid per the spec.
> Currently camel-xmlsecurity can handle the first case but not the second
> {code}



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

[jira] [Assigned] (CAMEL-12679) ensure camel-xmlsecurity can try key directly to decrypt message

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12679:


Assignee: Freeman Fang

> ensure camel-xmlsecurity can try key directly to decrypt message
> 
>
> Key: CAMEL-12679
> URL: https://issues.apache.org/jira/browse/CAMEL-12679
> Project: Camel
>  Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> If there is no EncryptedKey can be used,try the key directly to decrypt 
> message as fallback
> As both message
> {code}
> http://www.w3.org/2001/04/xmlenc#"; 
> Type="http://www.w3.org/2001/04/xmlenc#Element";> Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> xmlns:ds="http://www.w3.org/2000/09/xmldsig#";> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";> Algorithm="http://www.w3.org/2001/04/xmlenc#kw-tripledes"/>/5nDlLI7jrETNrNG/5Nsw3qB9dSnZVwyj5OZZsUvZaHb/8oIayoMeg==yP17O2otQdraY+W42w8i8U/pQQac1g84vWaGWqbS1tgCduFfjhnIz2ZqbFJ6n7Ow1cIeF5HyAoHRGaoDd4gbVw==
> {code}
> {code}
> 
>Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc";>
> 168
>   
>   
> mykey
>   
>   
> 
> yP17O2otQdraY+W42w8i8U/pQQac1g84vWaGWqbS1tgCduFfjhnIz2ZqbFJ6n7Ow1cIeF5HyAoHRGaoDd4gbVw==
>   
> 
> {code}
> are valid per the spec.
> Currently camel-xmlsecurity can handle the first case but not the second
> {code}



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

[jira] [Created] (CAMEL-12679) ensure camel-xmlsecurity can try key directly to decrypt message

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12679:


 Summary: ensure camel-xmlsecurity can try key directly to decrypt 
message
 Key: CAMEL-12679
 URL: https://issues.apache.org/jira/browse/CAMEL-12679
 Project: Camel
  Issue Type: Improvement
Reporter: Freeman Fang


If there is no EncryptedKey can be used,try the key directly to decrypt message 
as fallback
As both message
{code}
http://www.w3.org/2001/04/xmlenc#"; 
Type="http://www.w3.org/2001/04/xmlenc#Element";>http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>http://www.w3.org/2000/09/xmldsig#";>http://www.w3.org/2001/04/xmlenc#";>http://www.w3.org/2001/04/xmlenc#kw-tripledes"/>/5nDlLI7jrETNrNG/5Nsw3qB9dSnZVwyj5OZZsUvZaHb/8oIayoMeg==yP17O2otQdraY+W42w8i8U/pQQac1g84vWaGWqbS1tgCduFfjhnIz2ZqbFJ6n7Ow1cIeF5HyAoHRGaoDd4gbVw==
{code}
{code}

  http://www.w3.org/2001/04/xmlenc#tripledes-cbc";>
168
  
  
mykey
  
  

yP17O2otQdraY+W42w8i8U/pQQac1g84vWaGWqbS1tgCduFfjhnIz2ZqbFJ6n7Ow1cIeF5HyAoHRGaoDd4gbVw==
  

{code}
are valid per the spec.
Currently camel-xmlsecurity can handle the first case but not the second
{code}



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

[jira] [Resolved] (CAMEL-12673) enable to configure passPhrase of XMLSecurityDataFormat as byte[]

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12673.
--
   Resolution: Fixed
Fix Version/s: 2.23.0

> enable to configure passPhrase of XMLSecurityDataFormat as byte[]
> -
>
> Key: CAMEL-12673
> URL: https://issues.apache.org/jira/browse/CAMEL-12673
> Project: Camel
>  Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.23.0
>
>
> since passPhrase may not be the visiable string, it could be byte[] instead. 
> We should enable to specify  passPhrase as byte[]



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

[jira] [Assigned] (CAMEL-12673) enable to configure passPhrase of XMLSecurityDataFormat as byte[]

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12673:


Assignee: Freeman Fang

> enable to configure passPhrase of XMLSecurityDataFormat as byte[]
> -
>
> Key: CAMEL-12673
> URL: https://issues.apache.org/jira/browse/CAMEL-12673
> Project: Camel
>  Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> since passPhrase may not be the visiable string, it could be byte[] instead. 
> We should enable to specify  passPhrase as byte[]



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

[jira] [Created] (CAMEL-12673) enable to configure passPhrase of XMLSecurityDataFormat as byte[]

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12673:


 Summary: enable to configure passPhrase of XMLSecurityDataFormat 
as byte[]
 Key: CAMEL-12673
 URL: https://issues.apache.org/jira/browse/CAMEL-12673
 Project: Camel
  Issue Type: Improvement
Reporter: Freeman Fang


since passPhrase may not be the visiable string, it could be byte[] instead. We 
should enable to specify  passPhrase as byte[]



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

[jira] [Resolved] (CAMEL-12637) XmlConverter can't transform StAXSource when external xalan lib available

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12637.
--
   Resolution: Fixed
Fix Version/s: 2.23.0
   2.22.1
   2.21.2

> XmlConverter can't transform StAXSource when external xalan lib available
> -
>
> Key: CAMEL-12637
> URL: https://issues.apache.org/jira/browse/CAMEL-12637
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.2, 2.22.1, 2.23.0
>
>
> since external xalan impl doesn't support StAXSource, we should convert 
> StAXSource to SAXSource firstly when external xalan is used
> Otherwise we will see exception like
> {code}
> javax.xml.transform.TransformerException: Can't transform a Source of type 
> javax.xml.transform.stax.StAXSource
> {code}



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

[jira] [Updated] (CAMEL-12637) XmlConverter can't transform StAXSource when external xalan lib available

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12637:
-
Description: 
since external xalan impl doesn't support StAXSource, we should convert 
StAXSource to SAXSource firstly when external xalan is used

Otherwise we will see exception like

{code}

javax.xml.transform.TransformerException: Can't transform a Source of type 
javax.xml.transform.stax.StAXSource

{code}

  was:
since external xalan impl doesn't support StAXSource, we should convert 
StAXSource to SAXSource firstly when external xalan is used

Otherwise we will see exception like

{code}

{color:#00}javax.xml.transform.TransformerException: Can't transform a 
Source of type javax.xml.transform.stax.StAXSource{color}

{color:#00}{code}{color}


> XmlConverter can't transform StAXSource when external xalan lib available
> -
>
> Key: CAMEL-12637
> URL: https://issues.apache.org/jira/browse/CAMEL-12637
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> since external xalan impl doesn't support StAXSource, we should convert 
> StAXSource to SAXSource firstly when external xalan is used
> Otherwise we will see exception like
> {code}
> javax.xml.transform.TransformerException: Can't transform a Source of type 
> javax.xml.transform.stax.StAXSource
> {code}



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

[jira] [Assigned] (CAMEL-12637) XmlConverter can't transform StAXSource when external xalan lib available

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12637:


Assignee: Freeman Fang

> XmlConverter can't transform StAXSource when external xalan lib available
> -
>
> Key: CAMEL-12637
> URL: https://issues.apache.org/jira/browse/CAMEL-12637
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> since external xalan impl doesn't support StAXSource, we should convert 
> StAXSource to SAXSource firstly when external xalan is used
> Otherwise we will see exception like
> {code}
> {color:#00}javax.xml.transform.TransformerException: Can't transform a 
> Source of type javax.xml.transform.stax.StAXSource{color}
> {color:#00}{code}{color}



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

[jira] [Created] (CAMEL-12637) XmlConverter can't transform StAXSource when external xalan lib available

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12637:


 Summary: XmlConverter can't transform StAXSource when external 
xalan lib available
 Key: CAMEL-12637
 URL: https://issues.apache.org/jira/browse/CAMEL-12637
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Reporter: Freeman Fang


since external xalan impl doesn't support StAXSource, we should convert 
StAXSource to SAXSource firstly when external xalan is used

Otherwise we will see exception like

{code}

{color:#00}javax.xml.transform.TransformerException: Can't transform a 
Source of type javax.xml.transform.stax.StAXSource{color}

{color:#00}{code}{color}



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

[jira] [Updated] (CAMEL-12621) Rest DSL with Jetty9|netty4-http components returns 404 instead of 405, when http method is not supported

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12621:
-
Summary: Rest DSL with Jetty9|netty4-http components returns 404 instead of 
405, when http method is not supported  (was: Rest DSL with Jetty9 components 
returns 404 instead of 405, when http method is not supported)

> Rest DSL with Jetty9|netty4-http components returns 404 instead of 405, when 
> http method is not supported
> -
>
> Key: CAMEL-12621
> URL: https://issues.apache.org/jira/browse/CAMEL-12621
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.2, 2.22.1, 2.23.0
>
>
> For example when a GET request is expected but client send a POST, currently 
> it returns 404, however, it should return 405 instead, as resource actually 
> exists and just the HTTP method mismatch



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

[jira] [Resolved] (CAMEL-12621) Rest DSL with Jetty9 components returns 404 instead of 405, when http method is not supported

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12621.
--
   Resolution: Fixed
Fix Version/s: 2.23.0
   2.22.1
   2.21.2

> Rest DSL with Jetty9 components returns 404 instead of 405, when http method 
> is not supported
> -
>
> Key: CAMEL-12621
> URL: https://issues.apache.org/jira/browse/CAMEL-12621
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.2, 2.22.1, 2.23.0
>
>
> For example when a GET request is expected but client send a POST, currently 
> it returns 404, however, it should return 405 instead, as resource actually 
> exists and just the HTTP method mismatch



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

[jira] [Assigned] (CAMEL-12621) Rest DSL with Jetty9 components returns 404 instead of 405, when http method is not supported

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12621:


Assignee: Freeman Fang

> Rest DSL with Jetty9 components returns 404 instead of 405, when http method 
> is not supported
> -
>
> Key: CAMEL-12621
> URL: https://issues.apache.org/jira/browse/CAMEL-12621
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> For example when a GET request is expected but client send a POST, currently 
> it returns 404, however, it should return 405 instead, as resource actually 
> exists and just the HTTP method mismatch



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

[jira] [Created] (CAMEL-12621) Rest DSL with Jetty9 components returns 404 instead of 405, when http method is not supported

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12621:


 Summary: Rest DSL with Jetty9 components returns 404 instead of 
405, when http method is not supported
 Key: CAMEL-12621
 URL: https://issues.apache.org/jira/browse/CAMEL-12621
 Project: Camel
  Issue Type: Bug
Reporter: Freeman Fang


For example when a GET request is expected but client send a POST, currently it 
returns 404, however, it should return 405 instead, as resource actually exists 
and just the HTTP method mismatch



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

[jira] [Resolved] (CAMEL-12465) Don't carry soapAction forward if operationName is specified explicitly for the CxfProducer

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12465.
--
   Resolution: Fixed
Fix Version/s: 2.22.0
   2.21.1

> Don't carry soapAction forward if operationName is specified explicitly for 
> the CxfProducer
> ---
>
> Key: CAMEL-12465
> URL: https://issues.apache.org/jira/browse/CAMEL-12465
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.1, 2.22.0
>
>
> So that the outgoing soap message get chance to calculate soapAction from the 
> operationName



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

[jira] [Assigned] (CAMEL-12465) Don't carry soapAction forward if operationName is specified explicitly for the CxfProducer

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12465:


Assignee: Freeman Fang

> Don't carry soapAction forward if operationName is specified explicitly for 
> the CxfProducer
> ---
>
> Key: CAMEL-12465
> URL: https://issues.apache.org/jira/browse/CAMEL-12465
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> So that the outgoing soap message get chance to calculate soapAction from the 
> operationName



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

[jira] [Created] (CAMEL-12465) Don't carry soapAction forward if operationName is specified explicitly for the CxfProducer

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12465:


 Summary: Don't carry soapAction forward if operationName is 
specified explicitly for the CxfProducer
 Key: CAMEL-12465
 URL: https://issues.apache.org/jira/browse/CAMEL-12465
 Project: Camel
  Issue Type: Bug
  Components: camel-cxf
Reporter: Freeman Fang


So that the outgoing soap message get chance to calculate soapAction from the 
operationName



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

[jira] [Resolved] (CAMEL-12399) CxfRsProducer doesn't configure CxfRsEndpointConfigurer while using the Proxy API

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12399.
--
   Resolution: Fixed
Fix Version/s: 2.22.0
   2.21.1

> CxfRsProducer doesn't configure CxfRsEndpointConfigurer while using the Proxy 
> API
> -
>
> Key: CAMEL-12399
> URL: https://issues.apache.org/jira/browse/CAMEL-12399
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxfrs
>Affects Versions: 2.21.0
>Reporter: Mike Schippers
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.1, 2.22.0
>
>
> The CxfRsProducer doesn't configure a CxfRsEndpointConfigurer on the client 
> while using the Proxy API. When using the HTTP API this is working fine.
> So when i create an endpoint like this:
>  
> {code:java}
> CxfRsEndpoint endpoint = new CxfRsEndpoint(); 
> endpoint.setCxfRsEndpointConfigurer(new MyCxfRsEndpointConfigurer());
> {code}
>  
> {code:java}
> public static class MyCxfRsEndpointConfigurer implements 
> CxfRsEndpointConfigurer {
> @Override
> public void configure(AbstractJAXRSFactoryBean factoryBean) {
> }
> @Override
> public void configureClient(Client client) {
> client.header("foo", "bar");
> }
> @Override
> public void configureServer(Server server) {
> }
> }
> {code}
> In case i use the HTTP API the header "foo" is sent but not when i use the 
> Proxy API.



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

[jira] [Commented] (CAMEL-12399) CxfRsProducer doesn't configure CxfRsEndpointConfigurer while using the Proxy API

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12399:
--

patch applied on behalf of Mike Schippers  with thanks!

> CxfRsProducer doesn't configure CxfRsEndpointConfigurer while using the Proxy 
> API
> -
>
> Key: CAMEL-12399
> URL: https://issues.apache.org/jira/browse/CAMEL-12399
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxfrs
>Affects Versions: 2.21.0
>Reporter: Mike Schippers
>Assignee: Freeman Fang
>Priority: Major
>
> The CxfRsProducer doesn't configure a CxfRsEndpointConfigurer on the client 
> while using the Proxy API. When using the HTTP API this is working fine.
> So when i create an endpoint like this:
>  
> {code:java}
> CxfRsEndpoint endpoint = new CxfRsEndpoint(); 
> endpoint.setCxfRsEndpointConfigurer(new MyCxfRsEndpointConfigurer());
> {code}
>  
> {code:java}
> public static class MyCxfRsEndpointConfigurer implements 
> CxfRsEndpointConfigurer {
> @Override
> public void configure(AbstractJAXRSFactoryBean factoryBean) {
> }
> @Override
> public void configureClient(Client client) {
> client.header("foo", "bar");
> }
> @Override
> public void configureServer(Server server) {
> }
> }
> {code}
> In case i use the HTTP API the header "foo" is sent but not when i use the 
> Proxy API.



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

[jira] [Resolved] (CAMEL-12408) camel-cxf feature should not be tied to cxf-http-jetty feature

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12408.
--
Resolution: Fixed

> camel-cxf feature should not be tied to cxf-http-jetty feature
> --
>
> Key: CAMEL-12408
> URL: https://issues.apache.org/jira/browse/CAMEL-12408
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cxf, osgi
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.22.0
>
>
> should use cxf-http-provider instead, so that can use any http transport from 
> CXF (like jetty or undertow) in the underlying OSGi container



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

[jira] [Updated] (CAMEL-12408) camel-cxf feature should not be tied to cxf-http-jetty feature

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12408:
-
Description: should use cxf-http-provider instead, so that can use any http 
transport from CXF (like jetty or undertow) in the underlying OSGi container  
(was: should use cxf-http-provider instead, so that can use any http OSGI 
service implementation(like jetty or undertow) from the underlying OSGi 
container)

> camel-cxf feature should not be tied to cxf-http-jetty feature
> --
>
> Key: CAMEL-12408
> URL: https://issues.apache.org/jira/browse/CAMEL-12408
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cxf, osgi
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.22.0
>
>
> should use cxf-http-provider instead, so that can use any http transport from 
> CXF (like jetty or undertow) in the underlying OSGi container



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

[jira] [Updated] (CAMEL-12408) camel-cxf feature should not be tied to cxf-http-jetty feature

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12408:
-
Component/s: osgi
 camel-cxf

> camel-cxf feature should not be tied to cxf-http-jetty feature
> --
>
> Key: CAMEL-12408
> URL: https://issues.apache.org/jira/browse/CAMEL-12408
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cxf, osgi
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> should use cxf-http-provider instead, so that can use any http OSGI service 
> implementation(like jetty or undertow) from the underlying OSGi container



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

[jira] [Updated] (CAMEL-12408) camel-cxf feature should not be tied to cxf-http-jetty feature

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12408:
-
Fix Version/s: 2.22.0

> camel-cxf feature should not be tied to cxf-http-jetty feature
> --
>
> Key: CAMEL-12408
> URL: https://issues.apache.org/jira/browse/CAMEL-12408
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cxf, osgi
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.22.0
>
>
> should use cxf-http-provider instead, so that can use any http OSGI service 
> implementation(like jetty or undertow) from the underlying OSGi container



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

[jira] [Assigned] (CAMEL-12399) CxfRsProducer doesn't configure CxfRsEndpointConfigurer while using the Proxy API

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12399:


Assignee: Freeman Fang

> CxfRsProducer doesn't configure CxfRsEndpointConfigurer while using the Proxy 
> API
> -
>
> Key: CAMEL-12399
> URL: https://issues.apache.org/jira/browse/CAMEL-12399
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxfrs
>Affects Versions: 2.21.0
>Reporter: Mike Schippers
>Assignee: Freeman Fang
>Priority: Major
>
> The CxfRsProducer doesn't configure a CxfRsEndpointConfigurer on the client 
> while using the Proxy API. When using the HTTP API this is working fine.
> So when i create an endpoint like this:
>  
> {code:java}
> CxfRsEndpoint endpoint = new CxfRsEndpoint(); 
> endpoint.setCxfRsEndpointConfigurer(new MyCxfRsEndpointConfigurer());
> {code}
>  
> {code:java}
> public static class MyCxfRsEndpointConfigurer implements 
> CxfRsEndpointConfigurer {
> @Override
> public void configure(AbstractJAXRSFactoryBean factoryBean) {
> }
> @Override
> public void configureClient(Client client) {
> client.header("foo", "bar");
> }
> @Override
> public void configureServer(Server server) {
> }
> }
> {code}
> In case i use the HTTP API the header "foo" is sent but not when i use the 
> Proxy API.



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

[jira] [Created] (CAMEL-12408) camel-cxf feature should not be tied to cxf-http-jetty feature

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12408:


 Summary: camel-cxf feature should not be tied to cxf-http-jetty 
feature
 Key: CAMEL-12408
 URL: https://issues.apache.org/jira/browse/CAMEL-12408
 Project: Camel
  Issue Type: Improvement
Reporter: Freeman Fang


should use cxf-http-provider instead, so that can use any http OSGI service 
implementation(like jetty or undertow) from the underlying OSGi container



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

[jira] [Assigned] (CAMEL-12408) camel-cxf feature should not be tied to cxf-http-jetty feature

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12408:


Assignee: Freeman Fang

> camel-cxf feature should not be tied to cxf-http-jetty feature
> --
>
> Key: CAMEL-12408
> URL: https://issues.apache.org/jira/browse/CAMEL-12408
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cxf, osgi
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> should use cxf-http-provider instead, so that can use any http OSGI service 
> implementation(like jetty or undertow) from the underlying OSGi container



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

[jira] [Updated] (CAMEL-12405) upgrade to CXF 3.2.4

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12405:
-
Component/s: camel-cxfrs
 camel-cxf

> upgrade to CXF 3.2.4
> 
>
> Key: CAMEL-12405
> URL: https://issues.apache.org/jira/browse/CAMEL-12405
> Project: Camel
>  Issue Type: Task
>  Components: camel-cxf, camel-cxfrs
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.22.0
>
>




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

[jira] [Resolved] (CAMEL-12405) upgrade to CXF 3.2.4

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12405.
--
   Resolution: Fixed
Fix Version/s: 2.22.0

> upgrade to CXF 3.2.4
> 
>
> Key: CAMEL-12405
> URL: https://issues.apache.org/jira/browse/CAMEL-12405
> Project: Camel
>  Issue Type: Task
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.22.0
>
>




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

[jira] [Created] (CAMEL-12405) upgrade to CXF 3.2.4

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12405:


 Summary: upgrade to CXF 3.2.4
 Key: CAMEL-12405
 URL: https://issues.apache.org/jira/browse/CAMEL-12405
 Project: Camel
  Issue Type: Task
Reporter: Freeman Fang






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

[jira] [Assigned] (CAMEL-12405) upgrade to CXF 3.2.4

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12405:


Assignee: Freeman Fang

> upgrade to CXF 3.2.4
> 
>
> Key: CAMEL-12405
> URL: https://issues.apache.org/jira/browse/CAMEL-12405
> Project: Camel
>  Issue Type: Task
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>




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

[jira] [Resolved] (CAMEL-12345) LinkedIn component throws IllegalArgumentException on API requests

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12345.
--
Resolution: Fixed

> LinkedIn component throws IllegalArgumentException on API requests
> --
>
> Key: CAMEL-12345
> URL: https://issues.apache.org/jira/browse/CAMEL-12345
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.21.0
>Reporter: James Netherton
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.1, 2.22.0
>
>
> Almost all of the camel-linkedin integration tests are failing on master and 
> for the 2.21.0 tag. The error is pretty much the same for all of them. For 
> example SearchResourceIntegrationTest.testSearchCompanies:
>  
> {code:java}
> Caused by: org.apache.camel.RuntimeCamelException: Error invoking 
> searchCompanies with {keywords=linkedin, fields=}: Value for fields is not 
> specified
> at 
> org.apache.camel.util.component.ApiMethodHelper.invokeMethod(ApiMethodHelper.java:514)
> at 
> org.apache.camel.util.component.AbstractApiProducer.doInvokeMethod(AbstractApiProducer.java:120)
> at 
> org.apache.camel.component.linkedin.LinkedInProducer.doInvokeMethod(LinkedInProducer.java:43)
> at 
> org.apache.camel.util.component.AbstractApiProducer$1.run(AbstractApiProducer.java:86)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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:748)
> Caused by: java.lang.IllegalArgumentException: Value for fields is not 
> specified
> at 
> org.apache.cxf.jaxrs.client.AbstractClient.convertParamValue(AbstractClient.java:824)
> at 
> org.apache.cxf.jaxrs.client.ClientProxyImpl.getPathParamValues(ClientProxyImpl.java:452)
> at 
> org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:179)
> at com.sun.proxy.$Proxy54.searchCompanies(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.camel.util.component.ApiMethodHelper.invokeMethod(ApiMethodHelper.java:506)
> ... 10 more{code}
>  
> I tried setting the CamelLinkedIn.fields header, but this leads to further 
> errors. The CXF 3.2.2 upgrade may be the culprit here. The tests run fine on 
> Camel 2.20.x with CXF 3.2.1.



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

[jira] [Commented] (CAMEL-12345) LinkedIn component throws IllegalArgumentException on API requests

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12345:
--

CXF-7584 restrict the proxies (by default) from accidentally supplying empty 
path template values, but seems camel-linkedIn component still need the ability 
to input empty path. Fortunately CXF-7584 also introduce a property 
"allow.empty.path.template.value" from which we can switch off this check, so 
that keep the CXF jaxrs proxy client behavior as is.

> LinkedIn component throws IllegalArgumentException on API requests
> --
>
> Key: CAMEL-12345
> URL: https://issues.apache.org/jira/browse/CAMEL-12345
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.21.0
>Reporter: James Netherton
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.1, 2.22.0
>
>
> Almost all of the camel-linkedin integration tests are failing on master and 
> for the 2.21.0 tag. The error is pretty much the same for all of them. For 
> example SearchResourceIntegrationTest.testSearchCompanies:
>  
> {code:java}
> Caused by: org.apache.camel.RuntimeCamelException: Error invoking 
> searchCompanies with {keywords=linkedin, fields=}: Value for fields is not 
> specified
> at 
> org.apache.camel.util.component.ApiMethodHelper.invokeMethod(ApiMethodHelper.java:514)
> at 
> org.apache.camel.util.component.AbstractApiProducer.doInvokeMethod(AbstractApiProducer.java:120)
> at 
> org.apache.camel.component.linkedin.LinkedInProducer.doInvokeMethod(LinkedInProducer.java:43)
> at 
> org.apache.camel.util.component.AbstractApiProducer$1.run(AbstractApiProducer.java:86)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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:748)
> Caused by: java.lang.IllegalArgumentException: Value for fields is not 
> specified
> at 
> org.apache.cxf.jaxrs.client.AbstractClient.convertParamValue(AbstractClient.java:824)
> at 
> org.apache.cxf.jaxrs.client.ClientProxyImpl.getPathParamValues(ClientProxyImpl.java:452)
> at 
> org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:179)
> at com.sun.proxy.$Proxy54.searchCompanies(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.camel.util.component.ApiMethodHelper.invokeMethod(ApiMethodHelper.java:506)
> ... 10 more{code}
>  
> I tried setting the CamelLinkedIn.fields header, but this leads to further 
> errors. The CXF 3.2.2 upgrade may be the culprit here. The tests run fine on 
> Camel 2.20.x with CXF 3.2.1.



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

[jira] [Assigned] (CAMEL-12345) LinkedIn component throws IllegalArgumentException on API requests

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12345:


Assignee: Freeman Fang

> LinkedIn component throws IllegalArgumentException on API requests
> --
>
> Key: CAMEL-12345
> URL: https://issues.apache.org/jira/browse/CAMEL-12345
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.21.0
>Reporter: James Netherton
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.1, 2.22.0
>
>
> Almost all of the camel-linkedin integration tests are failing on master and 
> for the 2.21.0 tag. The error is pretty much the same for all of them. For 
> example SearchResourceIntegrationTest.testSearchCompanies:
>  
> {code:java}
> Caused by: org.apache.camel.RuntimeCamelException: Error invoking 
> searchCompanies with {keywords=linkedin, fields=}: Value for fields is not 
> specified
> at 
> org.apache.camel.util.component.ApiMethodHelper.invokeMethod(ApiMethodHelper.java:514)
> at 
> org.apache.camel.util.component.AbstractApiProducer.doInvokeMethod(AbstractApiProducer.java:120)
> at 
> org.apache.camel.component.linkedin.LinkedInProducer.doInvokeMethod(LinkedInProducer.java:43)
> at 
> org.apache.camel.util.component.AbstractApiProducer$1.run(AbstractApiProducer.java:86)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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:748)
> Caused by: java.lang.IllegalArgumentException: Value for fields is not 
> specified
> at 
> org.apache.cxf.jaxrs.client.AbstractClient.convertParamValue(AbstractClient.java:824)
> at 
> org.apache.cxf.jaxrs.client.ClientProxyImpl.getPathParamValues(ClientProxyImpl.java:452)
> at 
> org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:179)
> at com.sun.proxy.$Proxy54.searchCompanies(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.camel.util.component.ApiMethodHelper.invokeMethod(ApiMethodHelper.java:506)
> ... 10 more{code}
>  
> I tried setting the CamelLinkedIn.fields header, but this leads to further 
> errors. The CXF 3.2.2 upgrade may be the culprit here. The tests run fine on 
> Camel 2.20.x with CXF 3.2.1.



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

[jira] [Resolved] (CAMEL-12381) upgrade to CXF 3.2.3

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12381.
--
Resolution: Fixed

> upgrade to CXF 3.2.3
> 
>
> Key: CAMEL-12381
> URL: https://issues.apache.org/jira/browse/CAMEL-12381
> Project: Camel
>  Issue Type: Task
>  Components: camel-cxf
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.22.0
>
>




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

[jira] [Commented] (CAMEL-12345) LinkedIn component throws IllegalArgumentException on API requests

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12345:
--

should be caused by this change

CXF-7584

> LinkedIn component throws IllegalArgumentException on API requests
> --
>
> Key: CAMEL-12345
> URL: https://issues.apache.org/jira/browse/CAMEL-12345
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.21.0
>Reporter: James Netherton
>Priority: Major
> Fix For: 2.21.1, 2.22.0
>
>
> Almost all of the camel-linkedin integration tests are failing on master and 
> for the 2.21.0 tag. The error is pretty much the same for all of them. For 
> example SearchResourceIntegrationTest.testSearchCompanies:
>  
> {code:java}
> Caused by: org.apache.camel.RuntimeCamelException: Error invoking 
> searchCompanies with {keywords=linkedin, fields=}: Value for fields is not 
> specified
> at 
> org.apache.camel.util.component.ApiMethodHelper.invokeMethod(ApiMethodHelper.java:514)
> at 
> org.apache.camel.util.component.AbstractApiProducer.doInvokeMethod(AbstractApiProducer.java:120)
> at 
> org.apache.camel.component.linkedin.LinkedInProducer.doInvokeMethod(LinkedInProducer.java:43)
> at 
> org.apache.camel.util.component.AbstractApiProducer$1.run(AbstractApiProducer.java:86)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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:748)
> Caused by: java.lang.IllegalArgumentException: Value for fields is not 
> specified
> at 
> org.apache.cxf.jaxrs.client.AbstractClient.convertParamValue(AbstractClient.java:824)
> at 
> org.apache.cxf.jaxrs.client.ClientProxyImpl.getPathParamValues(ClientProxyImpl.java:452)
> at 
> org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:179)
> at com.sun.proxy.$Proxy54.searchCompanies(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.camel.util.component.ApiMethodHelper.invokeMethod(ApiMethodHelper.java:506)
> ... 10 more{code}
>  
> I tried setting the CamelLinkedIn.fields header, but this leads to further 
> errors. The CXF 3.2.2 upgrade may be the culprit here. The tests run fine on 
> Camel 2.20.x with CXF 3.2.1.



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

[jira] [Resolved] (CAMEL-12104) Unintuitive default cxf timeout behavior

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12104.
--
Resolution: Fixed

> Unintuitive default cxf timeout behavior
> 
>
> Key: CAMEL-12104
> URL: https://issues.apache.org/jira/browse/CAMEL-12104
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf, camel-cxfrs
>Reporter: Adam Campbell
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.22.0
>
> Attachments: Screen Shot 2018-02-28 at 15.20.31.png
>
>
> There is very strange behavior in Camel cxf and cxfrs timeouts which could 
> lead to sensitive data being released.
> Below is a code sample which illustrates the unexpected behavior. I think any 
> developer would expect the test API to return "Valid Response" or some kind 
> exception, but in fact it returns "SENSITIVE DATA" due to the default 
> continuationTimeout of 30 seconds.
> This issue seems to have been introduced by 
> https://issues.apache.org/jira/browse/CAMEL-7401
> {code:java}
> public void configure() {
> from("cxf:///test?dataFormat=MESSAGE")
> .setBody(constant("SENSITIVE DATA"))
> 
> .to("cxf://http://localhost:8003/slowApi?serviceClass=com.example.ExampleService&dataFormat=MESSAGE";)
> .transform(constant("Valid Response"));
> from("cxf:///slowApi?dataFormat=MESSAGE")
> .process(new Processor(){
> @Override
> public void process(final Exchange exchange) throws Exception 
> {
> Thread.sleep(45000);
> }
> });
> }
> {code}



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

[jira] [Assigned] (CAMEL-12381) upgrade to CXF 3.2.3

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12381:


Assignee: Freeman Fang

> upgrade to CXF 3.2.3
> 
>
> Key: CAMEL-12381
> URL: https://issues.apache.org/jira/browse/CAMEL-12381
> Project: Camel
>  Issue Type: Task
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>




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

[jira] [Created] (CAMEL-12381) upgrade to CXF 3.2.3

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12381:


 Summary: upgrade to CXF 3.2.3
 Key: CAMEL-12381
 URL: https://issues.apache.org/jira/browse/CAMEL-12381
 Project: Camel
  Issue Type: Task
Reporter: Freeman Fang






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

[jira] [Resolved] (CAMEL-12364) ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 request correctly

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12364.
--
Resolution: Fixed

> ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 
> request  correctly
> 
>
> Key: CAMEL-12364
> URL: https://issues.apache.org/jira/browse/CAMEL-12364
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.20.3, 2.21.1, 2.22.0
>
>
> The expected behavior for a SOAP 1.2 enabled camel-cxf consumer endpoint 
> should be that
> when the request is SOAP1.2, response SOAP 1.2 message, when the request is 
> SOAP 1.1, response SOAP 1.1 message. 
> The CXF ReadHeadersInterceptor can check the actual request soap version, we 
> should keep this soap version when create CXF response from the Camel 
> Exchange.



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

[jira] [Updated] (CAMEL-12364) ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 request correctly

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12364:
-
Fix Version/s: 2.22.0
   2.21.1
   2.20.3

> ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 
> request  correctly
> 
>
> Key: CAMEL-12364
> URL: https://issues.apache.org/jira/browse/CAMEL-12364
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.20.3, 2.21.1, 2.22.0
>
>
> The expected behavior for a SOAP 1.2 enabled camel-cxf consumer endpoint 
> should be that
> when the request is SOAP1.2, response SOAP 1.2 message, when the request is 
> SOAP 1.1, response SOAP 1.1 message. 
> The CXF ReadHeadersInterceptor can check the actual request soap version, we 
> should keep this soap version when create CXF response from the Camel 
> Exchange.



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

[jira] [Commented] (CAMEL-12345) LinkedIn component throws IllegalArgumentException on API requests

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12345:
--

Is there a  LinkedIn Developer account  I can use to reproduce this?

Thanks!

> LinkedIn component throws IllegalArgumentException on API requests
> --
>
> Key: CAMEL-12345
> URL: https://issues.apache.org/jira/browse/CAMEL-12345
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.21.0
>Reporter: James Netherton
>Priority: Major
> Fix For: 2.21.1, 2.22.0
>
>
> Almost all of the camel-linkedin integration tests are failing on master and 
> for the 2.21.0 tag. The error is pretty much the same for all of them. For 
> example SearchResourceIntegrationTest.testSearchCompanies:
>  
> {code:java}
> Caused by: org.apache.camel.RuntimeCamelException: Error invoking 
> searchCompanies with {keywords=linkedin, fields=}: Value for fields is not 
> specified
> at 
> org.apache.camel.util.component.ApiMethodHelper.invokeMethod(ApiMethodHelper.java:514)
> at 
> org.apache.camel.util.component.AbstractApiProducer.doInvokeMethod(AbstractApiProducer.java:120)
> at 
> org.apache.camel.component.linkedin.LinkedInProducer.doInvokeMethod(LinkedInProducer.java:43)
> at 
> org.apache.camel.util.component.AbstractApiProducer$1.run(AbstractApiProducer.java:86)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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:748)
> Caused by: java.lang.IllegalArgumentException: Value for fields is not 
> specified
> at 
> org.apache.cxf.jaxrs.client.AbstractClient.convertParamValue(AbstractClient.java:824)
> at 
> org.apache.cxf.jaxrs.client.ClientProxyImpl.getPathParamValues(ClientProxyImpl.java:452)
> at 
> org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:179)
> at com.sun.proxy.$Proxy54.searchCompanies(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.camel.util.component.ApiMethodHelper.invokeMethod(ApiMethodHelper.java:506)
> ... 10 more{code}
>  
> I tried setting the CamelLinkedIn.fields header, but this leads to further 
> errors. The CXF 3.2.2 upgrade may be the culprit here. The tests run fine on 
> Camel 2.20.x with CXF 3.2.1.



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

[jira] [Updated] (CAMEL-12364) ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 request correctly

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12364:
-
Description: 
The expected behavior for a SOAP 1.2 enabled camel-cxf consumer endpoint should 
be that
when the request is SOAP1.2, response SOAP 1.2 message, when the request is 
SOAP 1.1, response SOAP 1.1 message. 
The CXF ReadHeadersInterceptor can check the actual request soap version, we 
should keep this soap version when create CXF response from the Camel Exchange.

  was:
The expected behavior for a SOAP 1.2 enabled camel-cxf consumer endpoint should 
be that
when the request is SOAP1.2, response SOAP 1.2 message, when the request is 
SOAP 1.1, response SOAP 1.1 message. 
The CXF ReadHeadersInterceptor can check the actual request soap version, we 
should copy this message when create CXF response from the Camel Exchange.


> ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 
> request  correctly
> 
>
> Key: CAMEL-12364
> URL: https://issues.apache.org/jira/browse/CAMEL-12364
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> The expected behavior for a SOAP 1.2 enabled camel-cxf consumer endpoint 
> should be that
> when the request is SOAP1.2, response SOAP 1.2 message, when the request is 
> SOAP 1.1, response SOAP 1.1 message. 
> The CXF ReadHeadersInterceptor can check the actual request soap version, we 
> should keep this soap version when create CXF response from the Camel 
> Exchange.



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

[jira] [Updated] (CAMEL-12364) ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 request correctly

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12364:
-
Environment: (was: The expected behavior for a SOAP 1.2 enabled 
camel-cxf consumer endpoint should be that
when the request is SOAP1.2, response SOAP 1.2 message, when the request is 
SOAP 1.1, response SOAP 1.1 message. 
The CXF ReadHeadersInterceptor can check the actual request soap version, we 
should copy this message when create CXF response from the Camel Exchange.)
Description: 
The expected behavior for a SOAP 1.2 enabled camel-cxf consumer endpoint should 
be that
when the request is SOAP1.2, response SOAP 1.2 message, when the request is 
SOAP 1.1, response SOAP 1.1 message. 
The CXF ReadHeadersInterceptor can check the actual request soap version, we 
should copy this message when create CXF response from the Camel Exchange.

> ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 
> request  correctly
> 
>
> Key: CAMEL-12364
> URL: https://issues.apache.org/jira/browse/CAMEL-12364
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> The expected behavior for a SOAP 1.2 enabled camel-cxf consumer endpoint 
> should be that
> when the request is SOAP1.2, response SOAP 1.2 message, when the request is 
> SOAP 1.1, response SOAP 1.1 message. 
> The CXF ReadHeadersInterceptor can check the actual request soap version, we 
> should copy this message when create CXF response from the Camel Exchange.



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

[jira] [Created] (CAMEL-12364) ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 request correctly

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12364:


 Summary: ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can 
handle SOAP 1.1 request  correctly
 Key: CAMEL-12364
 URL: https://issues.apache.org/jira/browse/CAMEL-12364
 Project: Camel
  Issue Type: Bug
  Components: camel-cxf
 Environment: The expected behavior for a SOAP 1.2 enabled camel-cxf 
consumer endpoint should be that
when the request is SOAP1.2, response SOAP 1.2 message, when the request is 
SOAP 1.1, response SOAP 1.1 message. 
The CXF ReadHeadersInterceptor can check the actual request soap version, we 
should copy this message when create CXF response from the Camel Exchange.
Reporter: Freeman Fang






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

[jira] [Assigned] (CAMEL-12364) ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 request correctly

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12364:


Assignee: Freeman Fang

> ensure a SOAP 1.2 enabled camel-cxf consumer endpoint can handle SOAP 1.1 
> request  correctly
> 
>
> Key: CAMEL-12364
> URL: https://issues.apache.org/jira/browse/CAMEL-12364
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
> Environment: The expected behavior for a SOAP 1.2 enabled camel-cxf 
> consumer endpoint should be that
> when the request is SOAP1.2, response SOAP 1.2 message, when the request is 
> SOAP 1.1, response SOAP 1.1 message. 
> The CXF ReadHeadersInterceptor can check the actual request soap version, we 
> should copy this message when create CXF response from the Camel Exchange.
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>




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

[jira] [Resolved] (CAMEL-12326) Improve CamelCxfClientImpl a bit ensure it can handle camel side usecase

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-12326.
--
   Resolution: Fixed
Fix Version/s: 2.21.0

> Improve CamelCxfClientImpl a bit ensure it can handle camel side usecase
> 
>
> Key: CAMEL-12326
> URL: https://issues.apache.org/jira/browse/CAMEL-12326
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cxf
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.0
>
>
> when use camel-cxf as bridge which isn't in POJO mode, the camel-cxf 
> producer(CamelCxfClientImpl) needn't check if there is any content in the 
> return list. 



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

[jira] [Assigned] (CAMEL-12326) Improve CamelCxfClientImpl a bit ensure it can handle camel side usecase

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12326:


Assignee: Freeman Fang

> Improve CamelCxfClientImpl a bit ensure it can handle camel side usecase
> 
>
> Key: CAMEL-12326
> URL: https://issues.apache.org/jira/browse/CAMEL-12326
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cxf
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> when use camel-cxf as bridge which isn't in POJO mode, the camel-cxf 
> producer(CamelCxfClientImpl) needn't check if there is any content in the 
> return list. 



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

[jira] [Created] (CAMEL-12326) Improve CamelCxfClientImpl a bit ensure it can handle camel side usecase

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12326:


 Summary: Improve CamelCxfClientImpl a bit ensure it can handle 
camel side usecase
 Key: CAMEL-12326
 URL: https://issues.apache.org/jira/browse/CAMEL-12326
 Project: Camel
  Issue Type: Improvement
  Components: camel-cxf
Reporter: Freeman Fang


when use camel-cxf as bridge which isn't in POJO mode, the camel-cxf 
producer(CamelCxfClientImpl) needn't check if there is any content in the 
return list. 



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

[jira] [Commented] (CAMEL-12104) Unintuitive default cxf timeout behavior

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12104:
--

I think we can extend cxf Continuation interface a bit to add an isTimeout 
method so that we know the timeout happen and can handle this situation 
accordingly outside CXF

> Unintuitive default cxf timeout behavior
> 
>
> Key: CAMEL-12104
> URL: https://issues.apache.org/jira/browse/CAMEL-12104
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf, camel-cxfrs
>Reporter: Adam Campbell
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.0
>
> Attachments: Screen Shot 2018-02-28 at 15.20.31.png
>
>
> There is very strange behavior in Camel cxf and cxfrs timeouts which could 
> lead to sensitive data being released.
> Below is a code sample which illustrates the unexpected behavior. I think any 
> developer would expect the test API to return "Valid Response" or some kind 
> exception, but in fact it returns "SENSITIVE DATA" due to the default 
> continuationTimeout of 30 seconds.
> This issue seems to have been introduced by 
> https://issues.apache.org/jira/browse/CAMEL-7401
> {code:java}
> public void configure() {
> from("cxf:///test?dataFormat=MESSAGE")
> .setBody(constant("SENSITIVE DATA"))
> 
> .to("cxf://http://localhost:8003/slowApi?serviceClass=com.example.ExampleService&dataFormat=MESSAGE";)
> .transform(constant("Valid Response"));
> from("cxf:///slowApi?dataFormat=MESSAGE")
> .process(new Processor(){
> @Override
> public void process(final Exchange exchange) throws Exception 
> {
> Thread.sleep(45000);
> }
> });
> }
> {code}



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

[jira] [Assigned] (CAMEL-12104) Unintuitive default cxf timeout behavior

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12104:


Assignee: Freeman Fang

> Unintuitive default cxf timeout behavior
> 
>
> Key: CAMEL-12104
> URL: https://issues.apache.org/jira/browse/CAMEL-12104
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf, camel-cxfrs
>Reporter: Adam Campbell
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 2.21.0
>
> Attachments: Screen Shot 2018-02-28 at 15.20.31.png
>
>
> There is very strange behavior in Camel cxf and cxfrs timeouts which could 
> lead to sensitive data being released.
> Below is a code sample which illustrates the unexpected behavior. I think any 
> developer would expect the test API to return "Valid Response" or some kind 
> exception, but in fact it returns "SENSITIVE DATA" due to the default 
> continuationTimeout of 30 seconds.
> This issue seems to have been introduced by 
> https://issues.apache.org/jira/browse/CAMEL-7401
> {code:java}
> public void configure() {
> from("cxf:///test?dataFormat=MESSAGE")
> .setBody(constant("SENSITIVE DATA"))
> 
> .to("cxf://http://localhost:8003/slowApi?serviceClass=com.example.ExampleService&dataFormat=MESSAGE";)
> .transform(constant("Valid Response"));
> from("cxf:///slowApi?dataFormat=MESSAGE")
> .process(new Processor(){
> @Override
> public void process(final Exchange exchange) throws Exception 
> {
> Thread.sleep(45000);
> }
> });
> }
> {code}



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

[jira] [Commented] (CAMEL-12026) ensure camel bundle with spring configuration works in OSGi with aries-blueprint-spring bridge

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12026:
--

Great, thanks!

> ensure camel bundle with spring configuration works in OSGi with 
> aries-blueprint-spring bridge
> --
>
> Key: CAMEL-12026
> URL: https://issues.apache.org/jira/browse/CAMEL-12026
> Project: Camel
>  Issue Type: Task
>Reporter: Freeman Fang
>Assignee: Guillaume Nodet
>Priority: Major
> Attachments: say-more-spring.tar
>
>
> the spring-dm won't work with spring 4.x, and there's a new blueprint-spring 
> introduced in Aries to make the spring configured bundle still work with 
> spring 4.x
> We need add back CamelContextFactoryBean.java and OsgiSpringCamelContext.java 
> which was removed with camel-spring-dm module, as they are "OSGi context 
> aware" and ensure we use OsgiComponentResolver, OsgiDataFormatResolver etc 
> with the bundle in OSGi.
> We need remove spring-dm dependency from those classes.



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

[jira] [Commented] (CAMEL-12026) ensure camel bundle with spring configuration works in OSGi with aries-blueprint-spring bridge

[Freeman Fang (JIRA)]

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

Freeman Fang commented on CAMEL-12026:
--

Hi [~gnt],

Thanks for looking into this issue.

Please see the reproducer(say-more-spring.tar) I just attached, extract and 
build it.
Then with a clean Apache Karaf 4.1.3 kit, run commands from karaf console
{code}
repo-add camel 2.20.2
feature:install aries-blueprint-spring camel-spring camel-netty-http 
camel-jackson
bundle:install -s mvn:com.mycompany/say-more-spring/1.0.0-SNAPSHOT
{code}

wait a few seconds in the karaf.log we can see the exception like
{code}
Caused by: java.lang.IllegalArgumentException: Data format 'json-jackson' could 
not be created. Ensure that the data format is valid and the associated Camel 
component is present on the classpath
at 
org.apache.camel.model.DataFormatDefinition.getDataFormat(DataFormatDefinition.java:118)
 ~[?:?]
at 
org.apache.camel.model.DataFormatDefinition.getDataFormat(DataFormatDefinition.java:91)
 ~[?:?]
at 
org.apache.camel.model.UnmarshalDefinition.createProcessor(UnmarshalDefinition.java:189)
 ~[?:?]
at 
org.apache.camel.model.ProcessorDefinition.makeProcessorImpl(ProcessorDefinition.java:549)
 ~[?:?]
at 
org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:510)
 ~[?:?]
at 
org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:226)
 ~[?:?]
at 
org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1295) 
~[?:?]
at 
org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:204) 
~[?:?]
at 
org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:1148)
 ~[?:?]
at 
org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:3727)
 ~[?:?]
at 
org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3441)
 ~[?:?]
at 
org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:208)
 ~[?:?]
at 
org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:3249) 
~[?:?]
at 
org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:3245) 
~[?:?]
at 
org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:3268)
 ~[?:?]
at 
org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:3245)
 ~[?:?]
at 
org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) ~[?:?]
at 
org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:3168) 
~[?:?]
at 
org.apache.camel.spring.SpringCamelContext.start(SpringCamelContext.java:133) 
~[?:?]
... 26 more

{code}

IMO this is caused by the camel-spring has no OSGi support so that we cannot 
use OsgiComponentResolver, OsgiDataFormatResolver  which are "OSGi aware". 

Btw, my previous suggested fix is [1](this was reverted although it works, and 
we may need to use a separate module since it introduce OSGi dependency to 
camel-spring), which just add some crucial classes back from the removed 
camel-spring-dm module.

If we rewrite the reproducer with blueprint, then everything works great. we 
can send a request
{code}
curl -X POST -d "{ \"name\": \"Jack\" }" -H "Content-Type: application/json" 
http://localhost:1/say/greeter
{code}
and get expected response
{code}
{"response":"SUCCESS","errors":["warn1","warn2"]}
{code}

Freeman

[1]https://github.com/apache/camel/commit/ba21445a2548946871ddd3ee2007c4659dbed223

> ensure camel bundle with spring configuration works in OSGi with 
> aries-blueprint-spring bridge
> --
>
> Key: CAMEL-12026
> URL: https://issues.apache.org/jira/browse/CAMEL-12026
> Project: Camel
>  Issue Type: Task
>Reporter: Freeman Fang
>Assignee: Guillaume Nodet
>Priority: Major
> Attachments: say-more-spring.tar
>
>
> the spring-dm won't work with spring 4.x, and there's a new blueprint-spring 
> introduced in Aries to make the spring configured bundle still work with 
> spring 4.x
> We need add back CamelContextFactoryBean.java and OsgiSpringCamelContext.java 
> which was removed with camel-spring-dm module, as they are "OSGi context 
> aware" and ensure we use OsgiComponentResolver, OsgiDataFormatResolver etc 
> with the bundle in OSGi.
> We need remove spring-dm dependency from those classes.



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

[jira] [Updated] (CAMEL-12026) ensure camel bundle with spring configuration works in OSGi with aries-blueprint-spring bridge

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12026:
-
Attachment: say-more-spring.tar

> ensure camel bundle with spring configuration works in OSGi with 
> aries-blueprint-spring bridge
> --
>
> Key: CAMEL-12026
> URL: https://issues.apache.org/jira/browse/CAMEL-12026
> Project: Camel
>  Issue Type: Task
>Reporter: Freeman Fang
>Assignee: Guillaume Nodet
>Priority: Major
> Attachments: say-more-spring.tar
>
>
> the spring-dm won't work with spring 4.x, and there's a new blueprint-spring 
> introduced in Aries to make the spring configured bundle still work with 
> spring 4.x
> We need add back CamelContextFactoryBean.java and OsgiSpringCamelContext.java 
> which was removed with camel-spring-dm module, as they are "OSGi context 
> aware" and ensure we use OsgiComponentResolver, OsgiDataFormatResolver etc 
> with the bundle in OSGi.
> We need remove spring-dm dependency from those classes.



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

[jira] [Updated] (CAMEL-12026) ensure camel bundle with spring configuration works in OSGi with aries-blueprint-spring bridge

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-12026:
-
Description: 
the spring-dm won't work with spring 4.x, and there's a new blueprint-spring 
introduced in Aries to make the spring configured bundle still work with spring 
4.x

We need add back CamelContextFactoryBean.java and OsgiSpringCamelContext.java 
which was removed with camel-spring-dm module, as they are "OSGi context aware" 
and ensure we use OsgiComponentResolver, OsgiDataFormatResolver etc with the 
bundle in OSGi.

We need remove spring-dm dependency from those classes.

  was:
the spring-dm won't work with spring 4.x, and there's a new blueprint-spring 
introduced in Aries to make the spring configured bundle still work with spring 
4.x

We need add back CamelContextFactoryBean.java and OsgiSpringCamelContext.java 
which was removed with camel-spring-dm module, as they are "OSGi context aware" 
and ensure we use OsgiComponentResolver, OsgiDataFormatResolver etc with the 
bundle in OSGi


> ensure camel bundle with spring configuration works in OSGi with 
> aries-blueprint-spring bridge
> --
>
> Key: CAMEL-12026
> URL: https://issues.apache.org/jira/browse/CAMEL-12026
> Project: Camel
>  Issue Type: Task
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
> the spring-dm won't work with spring 4.x, and there's a new blueprint-spring 
> introduced in Aries to make the spring configured bundle still work with 
> spring 4.x
> We need add back CamelContextFactoryBean.java and OsgiSpringCamelContext.java 
> which was removed with camel-spring-dm module, as they are "OSGi context 
> aware" and ensure we use OsgiComponentResolver, OsgiDataFormatResolver etc 
> with the bundle in OSGi.
> We need remove spring-dm dependency from those classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CAMEL-12026) ensure camel bundle with spring configuration works in OSGi with aries-blueprint-spring bridge

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-12026:


Assignee: Freeman Fang

> ensure camel bundle with spring configuration works in OSGi with 
> aries-blueprint-spring bridge
> --
>
> Key: CAMEL-12026
> URL: https://issues.apache.org/jira/browse/CAMEL-12026
> Project: Camel
>  Issue Type: Task
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
> the spring-dm won't work with spring 4.x, and there's a new blueprint-spring 
> introduced in Aries to make the spring configured bundle still work with 
> spring 4.x
> We need add back CamelContextFactoryBean.java and OsgiSpringCamelContext.java 
> which was removed with camel-spring-dm module, as they are "OSGi context 
> aware" and ensure we use OsgiComponentResolver, OsgiDataFormatResolver etc 
> with the bundle in OSGi



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-12026) ensure camel bundle with spring configuration works in OSGi with aries-blueprint-spring bridge

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-12026:


 Summary: ensure camel bundle with spring configuration works in 
OSGi with aries-blueprint-spring bridge
 Key: CAMEL-12026
 URL: https://issues.apache.org/jira/browse/CAMEL-12026
 Project: Camel
  Issue Type: Task
Reporter: Freeman Fang


the spring-dm won't work with spring 4.x, and there's a new blueprint-spring 
introduced in Aries to make the spring configured bundle still work with spring 
4.x

We need add back CamelContextFactoryBean.java and OsgiSpringCamelContext.java 
which was removed with camel-spring-dm module, as they are "OSGi context aware" 
and ensure we use OsgiComponentResolver, OsgiDataFormatResolver etc with the 
bundle in OSGi



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11720) GoogleDriveProducer should be able to honor the http.proxyPort and http.proxyHost properties from the CamelContext

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-11720.
--
   Resolution: Fixed
Fix Version/s: 2.19.3
   2.20.0
   2.18.5

> GoogleDriveProducer should be able to honor the http.proxyPort and 
> http.proxyHost properties from the CamelContext
> --
>
> Key: CAMEL-11720
> URL: https://issues.apache.org/jira/browse/CAMEL-11720
> Project: Camel
>  Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 2.18.5, 2.20.0, 2.19.3
>
>
> it would be easier to use camel-google-drive for whom need the proxy



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11720) GoogleDriveProducer should be able to honor the http.proxyPort and http.proxyHost properties from the CamelContext

[Freeman Fang (JIRA)]

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

Freeman Fang updated CAMEL-11720:
-
Summary: GoogleDriveProducer should be able to honor the http.proxyPort and 
http.proxyHost properties from the CamelContext  (was: GoogleDriveProducer 
should be able to honor the https.proxyPort and https.proxyHost properties from 
the CamelContext)

> GoogleDriveProducer should be able to honor the http.proxyPort and 
> http.proxyHost properties from the CamelContext
> --
>
> Key: CAMEL-11720
> URL: https://issues.apache.org/jira/browse/CAMEL-11720
> Project: Camel
>  Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
> it would be easier to use camel-google-drive for whom need the proxy



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CAMEL-11720) GoogleDriveProducer should be able to honor the https.proxyPort and https.proxyHost properties from the CamelContext

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-11720:


Assignee: Freeman Fang

> GoogleDriveProducer should be able to honor the https.proxyPort and 
> https.proxyHost properties from the CamelContext
> 
>
> Key: CAMEL-11720
> URL: https://issues.apache.org/jira/browse/CAMEL-11720
> Project: Camel
>  Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
> it would be easier to use camel-google-drive for whom need the proxy



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-11720) GoogleDriveProducer should be able to honor the https.proxyPort and https.proxyHost properties from the CamelContext

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-11720:


 Summary: GoogleDriveProducer should be able to honor the 
https.proxyPort and https.proxyHost properties from the CamelContext
 Key: CAMEL-11720
 URL: https://issues.apache.org/jira/browse/CAMEL-11720
 Project: Camel
  Issue Type: Improvement
Reporter: Freeman Fang


it would be easier to use camel-google-drive for whom need the proxy



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11719) add a string to ChildReference converter for camel-google-drive

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-11719.
--
   Resolution: Fixed
Fix Version/s: 2.19.3
   2.20.0
   2.18.5

> add a string to ChildReference converter for camel-google-drive
> ---
>
> Key: CAMEL-11719
> URL: https://issues.apache.org/jira/browse/CAMEL-11719
> Project: Camel
>  Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 2.18.5, 2.20.0, 2.19.3
>
>
> so that can read childId from the message body and convert it to a 
> ChildReference instance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-11719) add a string to ChildReference converter for camel-google-drive

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-11719:


 Summary: add a string to ChildReference converter for 
camel-google-drive
 Key: CAMEL-11719
 URL: https://issues.apache.org/jira/browse/CAMEL-11719
 Project: Camel
  Issue Type: Improvement
Reporter: Freeman Fang


so that can read childId from the message body and convert it to a 
ChildReference instance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CAMEL-11719) add a string to ChildReference converter for camel-google-drive

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-11719:


Assignee: Freeman Fang

> add a string to ChildReference converter for camel-google-drive
> ---
>
> Key: CAMEL-11719
> URL: https://issues.apache.org/jira/browse/CAMEL-11719
> Project: Camel
>  Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
> so that can read childId from the message body and convert it to a 
> ChildReference instance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11688) ensure transport endpoint configuration will be take into account when create JettyRestHttpBinding from REST DSL

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-11688.
--
   Resolution: Fixed
Fix Version/s: 2.19.3
   2.20.0
   2.18.5

> ensure transport endpoint configuration will be take into account when create 
> JettyRestHttpBinding from REST DSL
> 
>
> Key: CAMEL-11688
> URL: https://issues.apache.org/jira/browse/CAMEL-11688
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jetty
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 2.18.5, 2.20.0, 2.19.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CAMEL-11688) ensure transport endpoint configuration will be take into account when create JettyRestHttpBinding from REST DSL

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-11688:


Assignee: Freeman Fang

> ensure transport endpoint configuration will be take into account when create 
> JettyRestHttpBinding from REST DSL
> 
>
> Key: CAMEL-11688
> URL: https://issues.apache.org/jira/browse/CAMEL-11688
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jetty
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-11688) ensure transport endpoint configuration will be take into account when create JettyRestHttpBinding from REST DSL

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-11688:


 Summary: ensure transport endpoint configuration will be take into 
account when create JettyRestHttpBinding from REST DSL
 Key: CAMEL-11688
 URL: https://issues.apache.org/jira/browse/CAMEL-11688
 Project: Camel
  Issue Type: Bug
  Components: camel-jetty
Reporter: Freeman Fang






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11564) avoid ClassCastException when the gzip is enabled for the cxf endpoint with camel destination

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-11564.
--
   Resolution: Fixed
Fix Version/s: 2.20.0
   2.19.2
   2.18.5

> avoid ClassCastException when the gzip is enabled for the cxf endpoint with 
> camel destination
> -
>
> Key: CAMEL-11564
> URL: https://issues.apache.org/jira/browse/CAMEL-11564
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 2.18.5, 2.19.2, 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CAMEL-11564) avoid ClassCastException when the gzip is enabled for the cxf endpoint with camel destination

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-11564:


Assignee: Freeman Fang

> avoid ClassCastException when the gzip is enabled for the cxf endpoint with 
> camel destination
> -
>
> Key: CAMEL-11564
> URL: https://issues.apache.org/jira/browse/CAMEL-11564
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-11564) avoid ClassCastException when the gzip is enabled for the cxf endpoint with camel destination

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-11564:


 Summary: avoid ClassCastException when the gzip is enabled for the 
cxf endpoint with camel destination
 Key: CAMEL-11564
 URL: https://issues.apache.org/jira/browse/CAMEL-11564
 Project: Camel
  Issue Type: Bug
Reporter: Freeman Fang






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-10176) camel-cxf RawMessageContentRedirectInterceptor should be able to handle the case that OutputStream is null for an outgoing message

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-10176.
--
   Resolution: Fixed
Fix Version/s: 2.18.0
   2.17.3
   2.16.4

> camel-cxf RawMessageContentRedirectInterceptor should be able to handle the 
> case that OutputStream is null for an outgoing message
> --
>
> Key: CAMEL-10176
> URL: https://issues.apache.org/jira/browse/CAMEL-10176
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 2.16.4, 2.17.3, 2.18.0
>
>
> when use jms transport in camel-cxf endpoint, the outgoing message will use a 
> Writer but not the OutputStream to send out message when the jms message is 
> using text payload, currently RawMessageContentRedirectInterceptor not handle 
> this case  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-10176) camel-cxf RawMessageContentRedirectInterceptor should be able to handle the case that OutputStream is null for an outgoing message

[Freeman Fang (JIRA)]

Freeman Fang created CAMEL-10176:


 Summary: camel-cxf RawMessageContentRedirectInterceptor should be 
able to handle the case that OutputStream is null for an outgoing message
 Key: CAMEL-10176
 URL: https://issues.apache.org/jira/browse/CAMEL-10176
 Project: Camel
  Issue Type: Bug
Reporter: Freeman Fang


when use jms transport in camel-cxf endpoint, the outgoing message will use a 
Writer but not the OutputStream to send out message when the jms message is 
using text payload, currently RawMessageContentRedirectInterceptor not handle 
this case  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CAMEL-10176) camel-cxf RawMessageContentRedirectInterceptor should be able to handle the case that OutputStream is null for an outgoing message

[Freeman Fang (JIRA)]

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

Freeman Fang reassigned CAMEL-10176:


Assignee: Freeman Fang

> camel-cxf RawMessageContentRedirectInterceptor should be able to handle the 
> case that OutputStream is null for an outgoing message
> --
>
> Key: CAMEL-10176
> URL: https://issues.apache.org/jira/browse/CAMEL-10176
> Project: Camel
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
> when use jms transport in camel-cxf endpoint, the outgoing message will use a 
> Writer but not the OutputStream to send out message when the jms message is 
> using text payload, currently RawMessageContentRedirectInterceptor not handle 
> this case  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CAMEL-10058) when cxf producer use MESSAGE DataFormat, it shouldn't also configure as messageType=text

[Freeman Fang (JIRA)]

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

Freeman Fang resolved CAMEL-10058.
--
   Resolution: Fixed
Fix Version/s: 2.18.0
   2.17.2
   2.16.4

> when cxf producer use MESSAGE DataFormat, it shouldn't also configure as 
> messageType=text 
> --
>
> Key: CAMEL-10058
> URL: https://issues.apache.org/jira/browse/CAMEL-10058
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cxf
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 2.16.4, 2.17.2, 2.18.0
>
>
> As MESSAGE datafFormat means send the underlying stream as is,  but 
> messageType=text   won't send the message as stream, should throw an 
> exception to make this incorrect configuration more visible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)