from:"Joerg Kessler \(JIRA\)"

[jira] [Commented] (CXF-7748) WS-Addressing for One Way + Signature fails

2018-06-13 Thread Joerg Kessler (JIRA)



[ 
https://issues.apache.org/jira/browse/CXF-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510766#comment-16510766
 ] 

Joerg Kessler commented on CXF-7748:


When creating the test I noticed why it works for you but does not work for me. 
We have a requirement to set the key/certificate aliases dynamically. We are 
using the Camel CXF binding to set those values dynamically in the 
corresponding context. For the response we use 
populateCxfResponseFromExchange(). The point is that those methods of the 
binding that deal with the response are not called if the exchange pattern is 
OneWay and I think this is correct. For Oneway pattern there is no response 
expected. When I set the alias statically at the CXF endpoint it works.

Only MAPAggregatorImpl tries to process a reply for such a OneWay scenario. I 
did not look into the details of rebaseResponse() but to me it seems to be luck 
that this is working up now. But maybe I missed a use case here?

> WS-Addressing for One Way + Signature fails
> ---
>
> Key: CXF-7748
> URL: https://issues.apache.org/jira/browse/CXF-7748
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 3.1.14
>Reporter: Joerg Kessler
>Priority: Major
>
> I am using CXF together in Apache Camel. I want to enable WS-Adressing for 
> the provider including signing these headers by WS-Security if requested . 
> This should especially work for One Way requests. When I set up this scenario 
> (Camel-CXF to Camel-CXF including Signature) I get the error
> org.apache.cxf.interceptor.Fault: No configured signature username detected
> The call stack is
> 2018 06 01 
> 06:57:37#+00#WARN#org.apache.cxf.phase.PhaseInterceptorChain##P1369096596#http-bio-8041-exec-5#na#wda71513f#jkt01ifl#web#w7e2e2211#na#na#na#na#Interceptor
>  for 
> \{http://xi.com/xiveri/source_runtime}JKCXF_TEST_IN\#\{http://xi.com/xiveri/source_runtime}JKCXF_TEST_IN
>  has thrown exception, unwinding noworg.apache.cxf.interceptor.Fault: No 
> configured signature username detected at 
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:232)
>  at 
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:114)
>  at 
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessageInternal(PolicyBasedWSS4JOutInterceptor.java:190)
>  at 
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:109)
>  at 
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:96)
>  at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>  at 
> org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:280)
>  at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:469)
>  at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:142)
>  at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>  at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>  at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
>  at 
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
>  at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:303)
>  at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:222)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:755) at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:278)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  at 
> com.sap.esb.security.cloud.authentication.CloudAuthenticationFilter.doFilter(CloudAuthenticationFilter.java:92)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>  at 
>

[jira] [Commented] (CXF-7748) WS-Addressing for One Way + Signature fails

2018-06-04 Thread Joerg Kessler (JIRA)



[ 
https://issues.apache.org/jira/browse/CXF-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500240#comment-16500240
 ] 

Joerg Kessler commented on CXF-7748:


I just checked: without WS-Signature the problem does not come up.

> WS-Addressing for One Way + Signature fails
> ---
>
> Key: CXF-7748
> URL: https://issues.apache.org/jira/browse/CXF-7748
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 3.1.14
>Reporter: Joerg Kessler
>Priority: Major
>
> I am using CXF together in Apache Camel. I want to enable WS-Adressing for 
> the provider including signing these headers by WS-Security if requested . 
> This should especially work for One Way requests. When I set up this scenario 
> (Camel-CXF to Camel-CXF including Signature) I get the error
> org.apache.cxf.interceptor.Fault: No configured signature username detected
> The call stack is
> 2018 06 01 
> 06:57:37#+00#WARN#org.apache.cxf.phase.PhaseInterceptorChain##P1369096596#http-bio-8041-exec-5#na#wda71513f#jkt01ifl#web#w7e2e2211#na#na#na#na#Interceptor
>  for 
> \{http://xi.com/xiveri/source_runtime}JKCXF_TEST_IN\#\{http://xi.com/xiveri/source_runtime}JKCXF_TEST_IN
>  has thrown exception, unwinding noworg.apache.cxf.interceptor.Fault: No 
> configured signature username detected at 
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:232)
>  at 
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:114)
>  at 
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessageInternal(PolicyBasedWSS4JOutInterceptor.java:190)
>  at 
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:109)
>  at 
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:96)
>  at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>  at 
> org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:280)
>  at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:469)
>  at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:142)
>  at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>  at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>  at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
>  at 
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
>  at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:303)
>  at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:222)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:755) at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:278)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  at 
> com.sap.esb.security.cloud.authentication.CloudAuthenticationFilter.doFilter(CloudAuthenticationFilter.java:92)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  at 
> com.sap.core.communication.server.CertValidatorFilter.doFilter(CertValidatorFilter.java:331)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
>  at 
>

[jira] [Created] (CXF-7748) WS-Addressing for One Way + Signature fails

2018-06-01 Thread Joerg Kessler (JIRA)

Joerg Kessler created CXF-7748:
--

 Summary: WS-Addressing for One Way + Signature fails
 Key: CXF-7748
 URL: https://issues.apache.org/jira/browse/CXF-7748
 Project: CXF
  Issue Type: Bug
  Components: WS-* Components
Affects Versions: 3.1.14
Reporter: Joerg Kessler


I am using CXF together in Apache Camel. I want to enable WS-Adressing for the 
provider including signing these headers by WS-Security if requested . This 
should especially work for One Way requests. When I set up this scenario 
(Camel-CXF to Camel-CXF including Signature) I get the error

org.apache.cxf.interceptor.Fault: No configured signature username detected

The call stack is

2018 06 01 
06:57:37#+00#WARN#org.apache.cxf.phase.PhaseInterceptorChain##P1369096596#http-bio-8041-exec-5#na#wda71513f#jkt01ifl#web#w7e2e2211#na#na#na#na#Interceptor
 for 
\{http://xi.com/xiveri/source_runtime}JKCXF_TEST_IN\#\{http://xi.com/xiveri/source_runtime}JKCXF_TEST_IN
 has thrown exception, unwinding noworg.apache.cxf.interceptor.Fault: No 
configured signature username detected at 
org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:232)
 at 
org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:114)
 at 
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessageInternal(PolicyBasedWSS4JOutInterceptor.java:190)
 at 
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:109)
 at 
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:96)
 at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
 at 
org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:280)
 at 
org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:469)
 at 
org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:142)
 at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
 at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
 at 
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
 at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
 at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
 at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
 at 
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
 at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:303)
 at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:222)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:755) at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:278)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
 at 
com.sap.esb.security.cloud.authentication.CloudAuthenticationFilter.doFilter(CloudAuthenticationFilter.java:92)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
 at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
 at 
com.sap.core.communication.server.CertValidatorFilter.doFilter(CertValidatorFilter.java:331)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
 at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
 at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
 at 
org.eclipse.virgo.web.enterprise.security.valve.OpenEjbSecurityInitializationValve.invoke(OpenEjbSecurityInitializationValve.java:44)
 at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:498)
 at 
com.sap.core.jpaas.security.auth.service.lib.AbstractAuthenticator.invoke(AbstractAuthenticator.java:170)
 at

[jira] [Commented] (CXF-7388) Problem with MTOM in Camel-CXF

2017-05-31 Thread Joerg Kessler (JIRA)


[ 
https://issues.apache.org/jira/browse/CXF-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16030834#comment-16030834
 ] 

Joerg Kessler commented on CXF-7388:


https://issues.apache.org/jira/browse/CAMEL-11370 created

> Problem with MTOM in Camel-CXF
> --
>
> Key: CXF-7388
> URL: https://issues.apache.org/jira/browse/CXF-7388
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.9
>Reporter: Joerg Kessler
> Fix For: 3.2.0
>
> Attachments: cxf.client.test.sync.junit.ext.zip
>
>
> Hi,
> I posted this on the CXF user list without getting a response (except from 
> Aki who supports this);
> We use CXF 3.1.9 together with Camel 2.17.4. We want to enable MTOM on the 
> Camel-CXF producer. To test it I created a simple route using Camel test 
> infrastructure where the producer uses a WSDL with base64 encoded payload 
> parts. But in the log output of CXF I always get a payload like this
> Http-Method: POST
> Content-Type: multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"
> Headers: {Accept=[*/*], 
> breadcrumbId=[ID-WDFN32392889A-65347-1494850621554-0-1], 
> Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[487], 
> content-type=[multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"], 
> Host=[localhost:8770], Pragma=[no-cache], SOAPAction=[""], 
> User-Agent=[Apache-CXF/3.1.9]}
> Payload: --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID: 
>  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>  
> xmlns:typ="http://cxf.apache.org/mime/types;>?U1VDQ0VTUw==
> --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6--
> This is not MTOM. The endpoint configuration is
>  address="http://localhost:8770/cxf/mtom; bus="ClientBus" 
> wsdlURL="wsdl/mtom_xop.wsdl">
> 
> 
> 
>  value="http://cxf.apache.org/mime"/>
> 
> 
> 
> Here I even used a WSDL that is used in the CXF MTOM tests. Then I compared 
> the execution of the relevant interceptors in Camel-CXF and CXF and found one 
> difference:
> In AbstractOutDatabindingInterceptor. writeToOutputStream() it is checked 
> that the data binding is implemented by the class 
> org.apache.cxf.jaxb.JAXBDataBinding. That is correct for CXF but Camel-CXF 
> sets in CxfEndpoint the  binding to 
> org.apache.camel.component.cxf.HybridSourceDataBinding which is derived from 
> JAXBDataBinding but of course is a different class. This seems to prevent the 
> completion of the MTOM conversion. I changed the code locally so that now all 
> subclasses are accepted and now the attachment processing gets really called. 
> But now the next problem apears; HybridSourceDataBinding.createWriter() 
> raises an exception:
> java.lang.UnsupportedOperationException: The type java.io.OutputStream is not 
> supported.
>   at 
> org.apache.camel.component.cxf.HybridSourceDataBinding.createWriter(HybridSourceDataBinding.java:87)
> I guess the method getSupportedWriterFormats of 
> JAXBDataBinding/HybridSourceDataBinding should prevent something like this 
> but in this case it does not work.
> I am also unsure whether the problem is now really in CXF or in Camel-CXF. 
> Therefore please forward it to Camel if the problem is locarted there. 
> Best Regards,
> Jörg



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CXF-7388) Problem with MTOM in Camel-CXF

2017-05-30 Thread Joerg Kessler (JIRA)


[ 
https://issues.apache.org/jira/browse/CXF-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16030672#comment-16030672
 ] 

Joerg Kessler commented on CXF-7388:


Yes,
as mentioned above I also found that by simply trying it out and I know that 
there are MTOM tests for camel-cxf but none of them seem to test whether the 
MTOM conversion was really executed. Do I have to create a new ticket on Camel 
or can this ticket be forwarded to camel?

> Problem with MTOM in Camel-CXF
> --
>
> Key: CXF-7388
> URL: https://issues.apache.org/jira/browse/CXF-7388
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.9
>Reporter: Joerg Kessler
> Fix For: 3.2.0
>
> Attachments: cxf.client.test.sync.junit.ext.zip
>
>
> Hi,
> I posted this on the CXF user list without getting a response (except from 
> Aki who supports this);
> We use CXF 3.1.9 together with Camel 2.17.4. We want to enable MTOM on the 
> Camel-CXF producer. To test it I created a simple route using Camel test 
> infrastructure where the producer uses a WSDL with base64 encoded payload 
> parts. But in the log output of CXF I always get a payload like this
> Http-Method: POST
> Content-Type: multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"
> Headers: {Accept=[*/*], 
> breadcrumbId=[ID-WDFN32392889A-65347-1494850621554-0-1], 
> Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[487], 
> content-type=[multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"], 
> Host=[localhost:8770], Pragma=[no-cache], SOAPAction=[""], 
> User-Agent=[Apache-CXF/3.1.9]}
> Payload: --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID: 
>  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>  
> xmlns:typ="http://cxf.apache.org/mime/types;>?U1VDQ0VTUw==
> --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6--
> This is not MTOM. The endpoint configuration is
>  address="http://localhost:8770/cxf/mtom; bus="ClientBus" 
> wsdlURL="wsdl/mtom_xop.wsdl">
> 
> 
> 
>  value="http://cxf.apache.org/mime"/>
> 
> 
> 
> Here I even used a WSDL that is used in the CXF MTOM tests. Then I compared 
> the execution of the relevant interceptors in Camel-CXF and CXF and found one 
> difference:
> In AbstractOutDatabindingInterceptor. writeToOutputStream() it is checked 
> that the data binding is implemented by the class 
> org.apache.cxf.jaxb.JAXBDataBinding. That is correct for CXF but Camel-CXF 
> sets in CxfEndpoint the  binding to 
> org.apache.camel.component.cxf.HybridSourceDataBinding which is derived from 
> JAXBDataBinding but of course is a different class. This seems to prevent the 
> completion of the MTOM conversion. I changed the code locally so that now all 
> subclasses are accepted and now the attachment processing gets really called. 
> But now the next problem apears; HybridSourceDataBinding.createWriter() 
> raises an exception:
> java.lang.UnsupportedOperationException: The type java.io.OutputStream is not 
> supported.
>   at 
> org.apache.camel.component.cxf.HybridSourceDataBinding.createWriter(HybridSourceDataBinding.java:87)
> I guess the method getSupportedWriterFormats of 
> JAXBDataBinding/HybridSourceDataBinding should prevent something like this 
> but in this case it does not work.
> I am also unsure whether the problem is now really in CXF or in Camel-CXF. 
> Therefore please forward it to Camel if the problem is locarted there. 
> Best Regards,
> Jörg



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CXF-7388) Problem with MTOM in Camel-CXF

2017-05-30 Thread Joerg Kessler (JIRA)


[ 
https://issues.apache.org/jira/browse/CXF-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029340#comment-16029340
 ] 

Joerg Kessler commented on CXF-7388:


No, I did not try that. It seems that the interceptor that tests the number of 
attachments is not called anymore. That is strange. In the log there is still 
no MTOM attachment visble, right? The error occurs because the response does 
not fit to the WSDL I guess the test is still not perfect. I could use a one 
way WSDL where there is no response. The original WSDL I used was built that 
way.

> Problem with MTOM in Camel-CXF
> --
>
> Key: CXF-7388
> URL: https://issues.apache.org/jira/browse/CXF-7388
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.9
>Reporter: Joerg Kessler
> Fix For: 3.2.0
>
> Attachments: cxf.client.test.sync.junit.ext.zip
>
>
> Hi,
> I posted this on the CXF user list without getting a response (except from 
> Aki who supports this);
> We use CXF 3.1.9 together with Camel 2.17.4. We want to enable MTOM on the 
> Camel-CXF producer. To test it I created a simple route using Camel test 
> infrastructure where the producer uses a WSDL with base64 encoded payload 
> parts. But in the log output of CXF I always get a payload like this
> Http-Method: POST
> Content-Type: multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"
> Headers: {Accept=[*/*], 
> breadcrumbId=[ID-WDFN32392889A-65347-1494850621554-0-1], 
> Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[487], 
> content-type=[multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"], 
> Host=[localhost:8770], Pragma=[no-cache], SOAPAction=[""], 
> User-Agent=[Apache-CXF/3.1.9]}
> Payload: --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID: 
>  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>  
> xmlns:typ="http://cxf.apache.org/mime/types;>?U1VDQ0VTUw==
> --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6--
> This is not MTOM. The endpoint configuration is
>  address="http://localhost:8770/cxf/mtom; bus="ClientBus" 
> wsdlURL="wsdl/mtom_xop.wsdl">
> 
> 
> 
>  value="http://cxf.apache.org/mime"/>
> 
> 
> 
> Here I even used a WSDL that is used in the CXF MTOM tests. Then I compared 
> the execution of the relevant interceptors in Camel-CXF and CXF and found one 
> difference:
> In AbstractOutDatabindingInterceptor. writeToOutputStream() it is checked 
> that the data binding is implemented by the class 
> org.apache.cxf.jaxb.JAXBDataBinding. That is correct for CXF but Camel-CXF 
> sets in CxfEndpoint the  binding to 
> org.apache.camel.component.cxf.HybridSourceDataBinding which is derived from 
> JAXBDataBinding but of course is a different class. This seems to prevent the 
> completion of the MTOM conversion. I changed the code locally so that now all 
> subclasses are accepted and now the attachment processing gets really called. 
> But now the next problem apears; HybridSourceDataBinding.createWriter() 
> raises an exception:
> java.lang.UnsupportedOperationException: The type java.io.OutputStream is not 
> supported.
>   at 
> org.apache.camel.component.cxf.HybridSourceDataBinding.createWriter(HybridSourceDataBinding.java:87)
> I guess the method getSupportedWriterFormats of 
> JAXBDataBinding/HybridSourceDataBinding should prevent something like this 
> but in this case it does not work.
> I am also unsure whether the problem is now really in CXF or in Camel-CXF. 
> Therefore please forward it to Camel if the problem is locarted there. 
> Best Regards,
> Jörg



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CXF-7388) Problem with MTOM in Camel-CXF

2017-05-30 Thread Joerg Kessler (JIRA)


[ 
https://issues.apache.org/jira/browse/CXF-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029254#comment-16029254
 ] 

Joerg Kessler commented on CXF-7388:


Hi,
I added the maven project. A SOAP message is sent via Camel direct endpoint to 
a cxf endpoint that uses the same WSDL as in one of the CXF MTOM unit tests and 
where MTOM is enabled. Another Camel route receives the message via CXF 
endpoint where MTOM is not enabled. An interceptor checks here whether an 
attachment was received. CXF payload logging is active so you should see the 
payload above that I pasted to this ticket.

> Problem with MTOM in Camel-CXF
> --
>
> Key: CXF-7388
> URL: https://issues.apache.org/jira/browse/CXF-7388
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.9
>Reporter: Joerg Kessler
> Fix For: 3.2.0
>
> Attachments: cxf.client.test.sync.junit.ext.zip
>
>
> Hi,
> I posted this on the CXF user list without getting a response (except from 
> Aki who supports this);
> We use CXF 3.1.9 together with Camel 2.17.4. We want to enable MTOM on the 
> Camel-CXF producer. To test it I created a simple route using Camel test 
> infrastructure where the producer uses a WSDL with base64 encoded payload 
> parts. But in the log output of CXF I always get a payload like this
> Http-Method: POST
> Content-Type: multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"
> Headers: {Accept=[*/*], 
> breadcrumbId=[ID-WDFN32392889A-65347-1494850621554-0-1], 
> Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[487], 
> content-type=[multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"], 
> Host=[localhost:8770], Pragma=[no-cache], SOAPAction=[""], 
> User-Agent=[Apache-CXF/3.1.9]}
> Payload: --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID: 
>  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>  
> xmlns:typ="http://cxf.apache.org/mime/types;>?U1VDQ0VTUw==
> --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6--
> This is not MTOM. The endpoint configuration is
>  address="http://localhost:8770/cxf/mtom; bus="ClientBus" 
> wsdlURL="wsdl/mtom_xop.wsdl">
> 
> 
> 
>  value="http://cxf.apache.org/mime"/>
> 
> 
> 
> Here I even used a WSDL that is used in the CXF MTOM tests. Then I compared 
> the execution of the relevant interceptors in Camel-CXF and CXF and found one 
> difference:
> In AbstractOutDatabindingInterceptor. writeToOutputStream() it is checked 
> that the data binding is implemented by the class 
> org.apache.cxf.jaxb.JAXBDataBinding. That is correct for CXF but Camel-CXF 
> sets in CxfEndpoint the  binding to 
> org.apache.camel.component.cxf.HybridSourceDataBinding which is derived from 
> JAXBDataBinding but of course is a different class. This seems to prevent the 
> completion of the MTOM conversion. I changed the code locally so that now all 
> subclasses are accepted and now the attachment processing gets really called. 
> But now the next problem apears; HybridSourceDataBinding.createWriter() 
> raises an exception:
> java.lang.UnsupportedOperationException: The type java.io.OutputStream is not 
> supported.
>   at 
> org.apache.camel.component.cxf.HybridSourceDataBinding.createWriter(HybridSourceDataBinding.java:87)
> I guess the method getSupportedWriterFormats of 
> JAXBDataBinding/HybridSourceDataBinding should prevent something like this 
> but in this case it does not work.
> I am also unsure whether the problem is now really in CXF or in Camel-CXF. 
> Therefore please forward it to Camel if the problem is locarted there. 
> Best Regards,
> Jörg



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CXF-7388) Problem with MTOM in Camel-CXF

2017-05-30 Thread Joerg Kessler (JIRA)


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

Joerg Kessler updated CXF-7388:
---
Attachment: cxf.client.test.sync.junit.ext.zip

> Problem with MTOM in Camel-CXF
> --
>
> Key: CXF-7388
> URL: https://issues.apache.org/jira/browse/CXF-7388
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.9
>Reporter: Joerg Kessler
> Fix For: 3.2.0
>
> Attachments: cxf.client.test.sync.junit.ext.zip
>
>
> Hi,
> I posted this on the CXF user list without getting a response (except from 
> Aki who supports this);
> We use CXF 3.1.9 together with Camel 2.17.4. We want to enable MTOM on the 
> Camel-CXF producer. To test it I created a simple route using Camel test 
> infrastructure where the producer uses a WSDL with base64 encoded payload 
> parts. But in the log output of CXF I always get a payload like this
> Http-Method: POST
> Content-Type: multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"
> Headers: {Accept=[*/*], 
> breadcrumbId=[ID-WDFN32392889A-65347-1494850621554-0-1], 
> Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[487], 
> content-type=[multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"], 
> Host=[localhost:8770], Pragma=[no-cache], SOAPAction=[""], 
> User-Agent=[Apache-CXF/3.1.9]}
> Payload: --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID: 
>  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>  
> xmlns:typ="http://cxf.apache.org/mime/types;>?U1VDQ0VTUw==
> --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6--
> This is not MTOM. The endpoint configuration is
>  address="http://localhost:8770/cxf/mtom; bus="ClientBus" 
> wsdlURL="wsdl/mtom_xop.wsdl">
> 
> 
> 
>  value="http://cxf.apache.org/mime"/>
> 
> 
> 
> Here I even used a WSDL that is used in the CXF MTOM tests. Then I compared 
> the execution of the relevant interceptors in Camel-CXF and CXF and found one 
> difference:
> In AbstractOutDatabindingInterceptor. writeToOutputStream() it is checked 
> that the data binding is implemented by the class 
> org.apache.cxf.jaxb.JAXBDataBinding. That is correct for CXF but Camel-CXF 
> sets in CxfEndpoint the  binding to 
> org.apache.camel.component.cxf.HybridSourceDataBinding which is derived from 
> JAXBDataBinding but of course is a different class. This seems to prevent the 
> completion of the MTOM conversion. I changed the code locally so that now all 
> subclasses are accepted and now the attachment processing gets really called. 
> But now the next problem apears; HybridSourceDataBinding.createWriter() 
> raises an exception:
> java.lang.UnsupportedOperationException: The type java.io.OutputStream is not 
> supported.
>   at 
> org.apache.camel.component.cxf.HybridSourceDataBinding.createWriter(HybridSourceDataBinding.java:87)
> I guess the method getSupportedWriterFormats of 
> JAXBDataBinding/HybridSourceDataBinding should prevent something like this 
> but in this case it does not work.
> I am also unsure whether the problem is now really in CXF or in Camel-CXF. 
> Therefore please forward it to Camel if the problem is locarted there. 
> Best Regards,
> Jörg



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CXF-7388) Problem with MTOM in Camel-CXF

2017-05-30 Thread Joerg Kessler (JIRA)


[ 
https://issues.apache.org/jira/browse/CXF-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16028837#comment-16028837
 ] 

Joerg Kessler commented on CXF-7388:


Sorry, then I missed your comment. I was not able to find a similar test case 
in Camel-CXF which surprised me because this is not very dfficult. I could 
provide my unit test (I have to prepare it first). What issue should I open?

> Problem with MTOM in Camel-CXF
> --
>
> Key: CXF-7388
> URL: https://issues.apache.org/jira/browse/CXF-7388
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.9
>Reporter: Joerg Kessler
> Fix For: 3.2.0
>
>
> Hi,
> I posted this on the CXF user list without getting a response (except from 
> Aki who supports this);
> We use CXF 3.1.9 together with Camel 2.17.4. We want to enable MTOM on the 
> Camel-CXF producer. To test it I created a simple route using Camel test 
> infrastructure where the producer uses a WSDL with base64 encoded payload 
> parts. But in the log output of CXF I always get a payload like this
> Http-Method: POST
> Content-Type: multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"
> Headers: {Accept=[*/*], 
> breadcrumbId=[ID-WDFN32392889A-65347-1494850621554-0-1], 
> Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[487], 
> content-type=[multipart/related; type="application/xop+xml"; 
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
> start=""; start-info="text/xml"], 
> Host=[localhost:8770], Pragma=[no-cache], SOAPAction=[""], 
> User-Agent=[Apache-CXF/3.1.9]}
> Payload: --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID: 
>  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>  
> xmlns:typ="http://cxf.apache.org/mime/types;>?U1VDQ0VTUw==
> --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6--
> This is not MTOM. The endpoint configuration is
>  address="http://localhost:8770/cxf/mtom; bus="ClientBus" 
> wsdlURL="wsdl/mtom_xop.wsdl">
> 
> 
> 
>  value="http://cxf.apache.org/mime"/>
> 
> 
> 
> Here I even used a WSDL that is used in the CXF MTOM tests. Then I compared 
> the execution of the relevant interceptors in Camel-CXF and CXF and found one 
> difference:
> In AbstractOutDatabindingInterceptor. writeToOutputStream() it is checked 
> that the data binding is implemented by the class 
> org.apache.cxf.jaxb.JAXBDataBinding. That is correct for CXF but Camel-CXF 
> sets in CxfEndpoint the  binding to 
> org.apache.camel.component.cxf.HybridSourceDataBinding which is derived from 
> JAXBDataBinding but of course is a different class. This seems to prevent the 
> completion of the MTOM conversion. I changed the code locally so that now all 
> subclasses are accepted and now the attachment processing gets really called. 
> But now the next problem apears; HybridSourceDataBinding.createWriter() 
> raises an exception:
> java.lang.UnsupportedOperationException: The type java.io.OutputStream is not 
> supported.
>   at 
> org.apache.camel.component.cxf.HybridSourceDataBinding.createWriter(HybridSourceDataBinding.java:87)
> I guess the method getSupportedWriterFormats of 
> JAXBDataBinding/HybridSourceDataBinding should prevent something like this 
> but in this case it does not work.
> I am also unsure whether the problem is now really in CXF or in Camel-CXF. 
> Therefore please forward it to Camel if the problem is locarted there. 
> Best Regards,
> Jörg



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CXF-7388) Problem with MTOM in Camel-CXF

2017-05-29 Thread Joerg Kessler (JIRA)

Joerg Kessler created CXF-7388:
--

 Summary: Problem with MTOM in Camel-CXF
 Key: CXF-7388
 URL: https://issues.apache.org/jira/browse/CXF-7388
 Project: CXF
  Issue Type: Bug
Reporter: Joerg Kessler


Hi,
I posted this on the CXF user list without getting a response (except from Aki 
who supports this);
We use CXF 3.1.9 together with Camel 2.17.4. We want to enable MTOM on the 
Camel-CXF producer. To test it I created a simple route using Camel test 
infrastructure where the producer uses a WSDL with base64 encoded payload 
parts. But in the log output of CXF I always get a payload like this
Http-Method: POST
Content-Type: multipart/related; type="application/xop+xml"; 
boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
start=""; start-info="text/xml"
Headers: {Accept=[*/*], 
breadcrumbId=[ID-WDFN32392889A-65347-1494850621554-0-1], 
Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[487], 
content-type=[multipart/related; type="application/xop+xml"; 
boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6"; 
start=""; start-info="text/xml"], 
Host=[localhost:8770], Pragma=[no-cache], SOAPAction=[""], 
User-Agent=[Apache-CXF/3.1.9]}
Payload: --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: 

http://schemas.xmlsoap.org/soap/envelope/;>http://cxf.apache.org/mime/types;>?U1VDQ0VTUw==
--uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6--

This is not MTOM. The endpoint configuration is
http://localhost:8770/cxf/mtom; bus="ClientBus" 
wsdlURL="wsdl/mtom_xop.wsdl">



http://cxf.apache.org/mime"/>



Here I even used a WSDL that is used in the CXF MTOM tests. Then I compared the 
execution of the relevant interceptors in Camel-CXF and CXF and found one 
difference:
In AbstractOutDatabindingInterceptor. writeToOutputStream() it is checked that 
the data binding is implemented by the class 
org.apache.cxf.jaxb.JAXBDataBinding. That is correct for CXF but Camel-CXF sets 
in CxfEndpoint the  binding to 
org.apache.camel.component.cxf.HybridSourceDataBinding which is derived from 
JAXBDataBinding but of course is a different class. This seems to prevent the 
completion of the MTOM conversion. I changed the code locally so that now all 
subclasses are accepted and now the attachment processing gets really called. 
But now the next problem apears; HybridSourceDataBinding.createWriter() raises 
an exception:
java.lang.UnsupportedOperationException: The type java.io.OutputStream is not 
supported.
at 
org.apache.camel.component.cxf.HybridSourceDataBinding.createWriter(HybridSourceDataBinding.java:87)
I guess the method getSupportedWriterFormats of 
JAXBDataBinding/HybridSourceDataBinding should prevent something like this but 
in this case it does not work.
I am also unsure whether the problem is now really in CXF or in Camel-CXF. 
Therefore please forward it to Camel if the problem is locarted there. 

Best Regards,

Jörg




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CXF-5325) error when having alternative transport bindings in WSDL

2013-10-09 Thread Joerg Kessler (JIRA)

Joerg Kessler created CXF-5325:
--

 Summary: error when having alternative transport bindings in WSDL
 Key: CXF-5325
 URL: https://issues.apache.org/jira/browse/CXF-5325
 Project: CXF
  Issue Type: Bug
  Components: Configuration
Reporter: Joerg Kessler
 Fix For: 2.7.6
 Attachments: cxf.client.test.sync.client.cert.junit.ext.zip

Hi,
we have received a WSDL from a WS provider that allows Basic Authentication or 
Client Certificate Authentication. When I configure Client Certificate 
Authentication in the conduit for my CXF WS consumer. I receive the following 
error

WARNUNG: Interceptor for 
{http://xi.com/xiveri/source_runtime}ZMTOM_CXF_IN#{http://xi.com/xiveri/source_runtime}CXF_IN
 has thrown exception, unwinding now
org.apache.cxf.ws.policy.PolicyException: Assertion of type 
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}HttpsToken could not 
be asserted: HttpBasicAuthentication is set, but not being used
at 
org.apache.cxf.ws.security.policy.interceptors.HttpsTokenInterceptorProvider$HttpsTokenOutInterceptor.assertHttps(HttpsTokenInterceptorProvider.java:144)
at 
org.apache.cxf.ws.security.policy.interceptors.HttpsTokenInterceptorProvider$HttpsTokenOutInterceptor.handleMessage(HttpsTokenInterceptorProvider.java:87)
at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:541)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:467)
If I just allow Client Certificarte it works. If in the WSDL Client Certificate 
is defined first it works. If I use WSRM the Create Sequence is executed 
without error, the message fails. 
I did some investigations. It seems that the HTTPSToken for Client Certificate 
is correctly evaluated by Neethi/CXF but some how get lost during the WSDL 
parsing. At the end all alternative policies contain a transport binding 
(referencing a transport token) referencing a HTTPSToken that requires Basic 
Authentication. I have attached a maven project that includes a simple junit 
test. It uses the Camel test functionality (CamelSpringTestSupport) to send 
directly a message to a CXF endpoint. mvn install or executing the junit test 
leads automatically to the error described above.

Best Regards,

Jörg



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (CXF-5325) error when having alternative transport bindings in WSDL

2013-10-09 Thread Joerg Kessler (JIRA)


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

Joerg Kessler updated CXF-5325:
---

Attachment: cxf.client.test.sync.client.cert.junit.ext.zip

 error when having alternative transport bindings in WSDL
 

 Key: CXF-5325
 URL: https://issues.apache.org/jira/browse/CXF-5325
 Project: CXF
  Issue Type: Bug
  Components: Configuration
Reporter: Joerg Kessler
 Fix For: 2.7.6

 Attachments: cxf.client.test.sync.client.cert.junit.ext.zip


 Hi,
 we have received a WSDL from a WS provider that allows Basic Authentication 
 or Client Certificate Authentication. When I configure Client Certificate 
 Authentication in the conduit for my CXF WS consumer. I receive the following 
 error
 WARNUNG: Interceptor for 
 {http://xi.com/xiveri/source_runtime}ZMTOM_CXF_IN#{http://xi.com/xiveri/source_runtime}CXF_IN
  has thrown exception, unwinding now
 org.apache.cxf.ws.policy.PolicyException: Assertion of type 
 {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}HttpsToken could 
 not be asserted: HttpBasicAuthentication is set, but not being used
   at 
 org.apache.cxf.ws.security.policy.interceptors.HttpsTokenInterceptorProvider$HttpsTokenOutInterceptor.assertHttps(HttpsTokenInterceptorProvider.java:144)
   at 
 org.apache.cxf.ws.security.policy.interceptors.HttpsTokenInterceptorProvider$HttpsTokenOutInterceptor.handleMessage(HttpsTokenInterceptorProvider.java:87)
   at 
 org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
   at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:541)
   at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:467)
 If I just allow Client Certificarte it works. If in the WSDL Client 
 Certificate is defined first it works. If I use WSRM the Create Sequence is 
 executed without error, the message fails. 
 I did some investigations. It seems that the HTTPSToken for Client 
 Certificate is correctly evaluated by Neethi/CXF but some how get lost during 
 the WSDL parsing. At the end all alternative policies contain a transport 
 binding (referencing a transport token) referencing a HTTPSToken that 
 requires Basic Authentication. I have attached a maven project that includes 
 a simple junit test. It uses the Camel test functionality 
 (CamelSpringTestSupport) to send directly a message to a CXF endpoint. mvn 
 install or executing the junit test leads automatically to the error 
 described above.
 Best Regards,
 Jörg



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (CXF-7748) WS-Addressing for One Way + Signature fails

[jira] [Commented] (CXF-7748) WS-Addressing for One Way + Signature fails

[jira] [Created] (CXF-7748) WS-Addressing for One Way + Signature fails

[jira] [Commented] (CXF-7388) Problem with MTOM in Camel-CXF

[jira] [Commented] (CXF-7388) Problem with MTOM in Camel-CXF

[jira] [Commented] (CXF-7388) Problem with MTOM in Camel-CXF

[jira] [Commented] (CXF-7388) Problem with MTOM in Camel-CXF

[jira] [Updated] (CXF-7388) Problem with MTOM in Camel-CXF

[jira] [Commented] (CXF-7388) Problem with MTOM in Camel-CXF

[jira] [Created] (CXF-7388) Problem with MTOM in Camel-CXF

[jira] [Created] (CXF-5325) error when having alternative transport bindings in WSDL

[jira] [Updated] (CXF-5325) error when having alternative transport bindings in WSDL

12 matches

Site Navigation

Mail list logo

Footer information