You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Hemmer, Tim" <Ti...@gallup.com> on 2014/09/28 21:18:39 UTC
Asymmetric binding using soap 1.1 in server environment
Hello,
I am witnessing a problem when running a war in a tomcat server when using Asymmetric binding, but not in my local junit tests. I added the encryption and everything works when running a local test (soap 1.2 is used). Before adding the asymmetric binding the tomcat environment also was working fine. We have always been using soap 1.2 in the evolution of this client. Please note, we are using reliable messaging (create sequence before real request) and the soap handler log will display before the policy interceptors.
Now with the new changes for using encryption in cxf, along with the obvious wsdl change, on the tomcat server we are sending a soap 1.1 request for some strange reason. Nothing really has changed with the jar dependencies so I wonder what could be different besides adding the asymmetric binding. Both the local and tomcat use local wsdls on runtime.
Here is the response error I am receiving when sending the 'message':
Caused by: javax.xml.ws.WebServiceException: Could not send Message.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:148)
at com.sun.proxy.$Proxy106.validate(Unknown Source)
at gallup.org.oms.authentication.AuthenticationDaoDiacapJaxWsImpl.validate(AuthenticationDaoDiacapJaxWsImpl.java:151)
... 52 more
Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '415: Cannot process the message because the content type 'text/xml; charset=UTF-8' was not the expected type 'application/soap+xml; charset=utf-8'.' when communicating with [service link]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1573)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
... 54 more
The wsdl definitely states to use soap 1.2:
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
........
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
The error itself points to a soap version problem and the soap handler log payload agree with the soap having this namespace (1.1 version of soap)
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
Does anyone have a clue where to start looking or any ideas what could be wrong? Is it possible that this is a symptom that the policies and wsdl are not being loaded when creating the client or something to do with the new addition of asymmetric binding only in a real container? Any ideas are appreciated.
Thanks,
Tim
All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
Re: Asymmetric binding using soap 1.1 in server environment
Posted by "Hemmer, Tim" <Ti...@gallup.com>.
Hi Dennis,
I believe I had some read permissions errors that were being silent in the
background as well. Once that was also fixed I actually am now receiving
the same HTTP 415 error, but now the error has switched with the service
saying I should be sending soap version 1.1 (text/xml for content type
instead of the app/soap one). I have contacted the service side to see if
the problem lies on their side since local still works. I will update the
forum with our findings.
Thanks for all your help!
On 9/29/14 2:00 PM, "Hemmer, Tim" <Ti...@gallup.com> wrote:
>Hi Dennis,
>
>I had an internal error when creating the URL (Malformed exception) from
>the wsdl location (file) that I missed in the logs. I have fixed this, but
>I am still getting the same error. So the first error is quite
>serendipitous letting me know when I create the client that the local wsdl
>still must not be loading up since there seems to be a lack of policies on
>runtime (same symptom/error as before).
>
>So far I have tried retrieving a wsdl outside the war (absolute path),
>wsdl (absolute path) inside the war. Next thing I will try is going
>through the classpath when creating the client. Since the local junit
>works this should work in theory.
>
>This is what I mean when I am using a custom wsdl location when creating
>the client (see first argument of Employees). My goal is to keep the xml
>binding live to changes when generating and policies custom/local that
>should not change to be loaded at runtime.
>
>IEmployees employeesDiacapEndpoint = new Employees(url,
>qname).getEmployeesDiacapEndpoint();
>
>Thanks again,
>Tim
>
>On 9/29/14 1:45 PM, "Dennis Sosnoski" <dm...@sosnoski.com> wrote:
>
>>Can you tell us what the error was, Tim? It's always helpful to have
>>information like that in the email chain so people searching on similar
>>symptoms get an idea what to check.
>>
>>Thanks,
>>
>> - Dennis
>>
>>On 09/30/2014 05:06 AM, Hemmer, Tim wrote:
>>> Hi Dennis,
>>>
>>> I believe I found the error on our side with creating the URL during
>>>the creation of the service. Now it makes sense why the policies seemed
>>>to not be in effect and it was only in the deployed version. We
>>>definitely appreciate your effort and time. Thank you sir.
>>>
>>> From: <Hemmer>, Gallup
>>><ti...@gallup.com>>
>>> Date: Sunday, September 28, 2014 7:51 PM
>>> To: "users@cxf.apache.org<ma...@cxf.apache.org>"
>>><us...@cxf.apache.org>>
>>> Subject: RE: Asymmetric binding using soap 1.1 in server environment
>>>
>>> We were always using the latest version.
>>>
>>> We recently switched to the asymmetric binding once we got the
>>>symmetric binding working with the custom wsdl that moved the individual
>>>policies into the general policy. My coworker Pohl talked to the user
>>>group about that discovery.
>>>
>>> Im going to do some checks tomorrow on the local wsdl itself to make
>>>sure it is loaded and literally the same, but I did not see any errors
>>>on the logs.
>>>
>>> Is there a way to set the soap version programmatically assuming that
>>>is the only thing that is wrong?
>>>
>>> Thanks,
>>> Tim
>>>
>>>
>>> -------- Original message --------
>>> From: Dennis Sosnoski <dm...@sosnoski.com>>
>>> Date:09/28/2014 7:44 PM (GMT-06:00)
>>> To: users@cxf.apache.org<ma...@cxf.apache.org>
>>> Cc:
>>> Subject: Re: Asymmetric binding using soap 1.1 in server environment
>>>
>>> Is this something which was working correctly for you with older
>>> releases, or is it the first time you tried the combination?
>>>
>>> - Dennis
>>>
>>> On 09/29/2014 01:22 PM, Hemmer, Tim wrote:
>>>> We are using the latest 3.0.1 from the July release
>>>>
>>>> Thanks,
>>>> Tim
>>>>
>>>>
>>>> -------- Original message --------
>>>> From: Dennis Sosnoski <dm...@sosnoski.com>>
>>>> Date:09/28/2014 4:55 PM (GMT-06:00)
>>>> To: users@cxf.apache.org<ma...@cxf.apache.org>
>>>> Cc:
>>>> Subject: Re: Asymmetric binding using soap 1.1 in server environment
>>>>
>>>> Hi Tim,
>>>>
>>>> Which version of CXF are you using? The combination of WS-Security
>>>>with
>>>> WS-ReliableMessaging went through some major changes for 3.0, so it's
>>>> possible this may have changed some behaviors.
>>>>
>>>> - Dennis
>>>>
>>>> Dennis M. Sosnoski
>>>> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
>>>> CXF and Web Services Security Training
>>>> <http://www.sosnoski.com/training.html>
>>>> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>>>>
>>>> On 09/29/2014 08:18 AM, Hemmer, Tim wrote:
>>>>> Hello,
>>>>>
>>>>> I am witnessing a problem when running a war in a tomcat server when
>>>>>using Asymmetric binding, but not in my local junit tests. I added the
>>>>>encryption and everything works when running a local test (soap 1.2 is
>>>>>used). Before adding the asymmetric binding the tomcat environment
>>>>>also was working fine. We have always been using soap 1.2 in the
>>>>>evolution of this client. Please note, we are using reliable messaging
>>>>>(create sequence before real request) and the soap handler log will
>>>>>display before the policy interceptors.
>>>>>
>>>>> Now with the new changes for using encryption in cxf, along with the
>>>>>obvious wsdl change, on the tomcat server we are sending a soap 1.1
>>>>>request for some strange reason. Nothing really has changed with the
>>>>>jar dependencies so I wonder what could be different besides adding
>>>>>the asymmetric binding. Both the local and tomcat use local wsdls on
>>>>>runtime.
>>>>>
>>>>> Here is the response error I am receiving when sending the 'message':
>>>>>
>>>>> Caused by: javax.xml.ws.WebServiceException: Could not send Message.
>>>>> at
>>>>>org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:148
>>>>>)
>>>>> at com.sun.proxy.$Proxy106.validate(Unknown Source)
>>>>> at
>>>>>gallup.org.oms.authentication.AuthenticationDaoDiacapJaxWsImpl.validat
>>>>>e
>>>>>(AuthenticationDaoDiacapJaxWsImpl.java:151)
>>>>> ... 52 more
>>>>> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response
>>>>>'415: Cannot process the message because the content type 'text/xml;
>>>>>charset=UTF-8' was not the expected type 'application/soap+xml;
>>>>>charset=utf-8'.' when communicating with [service link]
>>>>> at
>>>>>org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRe
>>>>>s
>>>>>ponseInternal(HTTPConduit.java:1573)
>>>>> at
>>>>>org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRe
>>>>>s
>>>>>ponse(HTTPConduit.java:1525)
>>>>> at
>>>>>org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HT
>>>>>T
>>>>>PConduit.java:1330)
>>>>> at
>>>>>org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOut
>>>>>p
>>>>>utStream.java:56)
>>>>> at
>>>>>org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215
>>>>>)
>>>>> at
>>>>>org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56
>>>>>)
>>>>> at
>>>>>org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
>>>>> at
>>>>>org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndin
>>>>>g
>>>>>Interceptor.handleMessage(MessageSenderInterceptor.java:62)
>>>>> at
>>>>>org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>>>>>r
>>>>>Chain.java:307)
>>>>> at
>>>>>org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
>>>>> at
>>>>>org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
>>>>> at
>>>>>org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
>>>>> at
>>>>>org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
>>>>> at
>>>>>org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>>>>> at
>>>>>org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137
>>>>>)
>>>>> ... 54 more
>>>>>
>>>>> The wsdl definitely states to use soap 1.2:
>>>>>
>>>>> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
>>>>> ........
>>>>> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
>>>>>
>>>>> The error itself points to a soap version problem and the soap
>>>>>handler log payload agree with the soap having this namespace (1.1
>>>>>version of soap)
>>>>>
>>>>> <soap:Envelope
>>>>>xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>>>>>
>>>>> Does anyone have a clue where to start looking or any ideas what
>>>>>could be wrong? Is it possible that this is a symptom that the
>>>>>policies and wsdl are not being loaded when creating the client or
>>>>>something to do with the new addition of asymmetric binding only in a
>>>>>real container? Any ideas are appreciated.
>>>>>
>>>>> Thanks,
>>>>> Tim
>>>>> All information in this message is confidential and may be legally
>>>>>privileged. Only intended recipients are authorized to use it.
>>>>>
>>>> All information in this message is confidential and may be legally
>>>>privileged. Only intended recipients are authorized to use it.
>>>>
>>> All information in this message is confidential and may be legally
>>>privileged. Only intended recipients are authorized to use it.
>>>
>>
>
All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
Re: Asymmetric binding using soap 1.1 in server environment
Posted by "Hemmer, Tim" <Ti...@gallup.com>.
Hi Dennis,
I had an internal error when creating the URL (Malformed exception) from
the wsdl location (file) that I missed in the logs. I have fixed this, but
I am still getting the same error. So the first error is quite
serendipitous letting me know when I create the client that the local wsdl
still must not be loading up since there seems to be a lack of policies on
runtime (same symptom/error as before).
So far I have tried retrieving a wsdl outside the war (absolute path),
wsdl (absolute path) inside the war. Next thing I will try is going
through the classpath when creating the client. Since the local junit
works this should work in theory.
This is what I mean when I am using a custom wsdl location when creating
the client (see first argument of Employees). My goal is to keep the xml
binding live to changes when generating and policies custom/local that
should not change to be loaded at runtime.
IEmployees employeesDiacapEndpoint = new Employees(url,
qname).getEmployeesDiacapEndpoint();
Thanks again,
Tim
On 9/29/14 1:45 PM, "Dennis Sosnoski" <dm...@sosnoski.com> wrote:
>Can you tell us what the error was, Tim? It's always helpful to have
>information like that in the email chain so people searching on similar
>symptoms get an idea what to check.
>
>Thanks,
>
> - Dennis
>
>On 09/30/2014 05:06 AM, Hemmer, Tim wrote:
>> Hi Dennis,
>>
>> I believe I found the error on our side with creating the URL during
>>the creation of the service. Now it makes sense why the policies seemed
>>to not be in effect and it was only in the deployed version. We
>>definitely appreciate your effort and time. Thank you sir.
>>
>> From: <Hemmer>, Gallup
>><ti...@gallup.com>>
>> Date: Sunday, September 28, 2014 7:51 PM
>> To: "users@cxf.apache.org<ma...@cxf.apache.org>"
>><us...@cxf.apache.org>>
>> Subject: RE: Asymmetric binding using soap 1.1 in server environment
>>
>> We were always using the latest version.
>>
>> We recently switched to the asymmetric binding once we got the
>>symmetric binding working with the custom wsdl that moved the individual
>>policies into the general policy. My coworker Pohl talked to the user
>>group about that discovery.
>>
>> Im going to do some checks tomorrow on the local wsdl itself to make
>>sure it is loaded and literally the same, but I did not see any errors
>>on the logs.
>>
>> Is there a way to set the soap version programmatically assuming that
>>is the only thing that is wrong?
>>
>> Thanks,
>> Tim
>>
>>
>> -------- Original message --------
>> From: Dennis Sosnoski <dm...@sosnoski.com>>
>> Date:09/28/2014 7:44 PM (GMT-06:00)
>> To: users@cxf.apache.org<ma...@cxf.apache.org>
>> Cc:
>> Subject: Re: Asymmetric binding using soap 1.1 in server environment
>>
>> Is this something which was working correctly for you with older
>> releases, or is it the first time you tried the combination?
>>
>> - Dennis
>>
>> On 09/29/2014 01:22 PM, Hemmer, Tim wrote:
>>> We are using the latest 3.0.1 from the July release
>>>
>>> Thanks,
>>> Tim
>>>
>>>
>>> -------- Original message --------
>>> From: Dennis Sosnoski <dm...@sosnoski.com>>
>>> Date:09/28/2014 4:55 PM (GMT-06:00)
>>> To: users@cxf.apache.org<ma...@cxf.apache.org>
>>> Cc:
>>> Subject: Re: Asymmetric binding using soap 1.1 in server environment
>>>
>>> Hi Tim,
>>>
>>> Which version of CXF are you using? The combination of WS-Security with
>>> WS-ReliableMessaging went through some major changes for 3.0, so it's
>>> possible this may have changed some behaviors.
>>>
>>> - Dennis
>>>
>>> Dennis M. Sosnoski
>>> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
>>> CXF and Web Services Security Training
>>> <http://www.sosnoski.com/training.html>
>>> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>>>
>>> On 09/29/2014 08:18 AM, Hemmer, Tim wrote:
>>>> Hello,
>>>>
>>>> I am witnessing a problem when running a war in a tomcat server when
>>>>using Asymmetric binding, but not in my local junit tests. I added the
>>>>encryption and everything works when running a local test (soap 1.2 is
>>>>used). Before adding the asymmetric binding the tomcat environment
>>>>also was working fine. We have always been using soap 1.2 in the
>>>>evolution of this client. Please note, we are using reliable messaging
>>>>(create sequence before real request) and the soap handler log will
>>>>display before the policy interceptors.
>>>>
>>>> Now with the new changes for using encryption in cxf, along with the
>>>>obvious wsdl change, on the tomcat server we are sending a soap 1.1
>>>>request for some strange reason. Nothing really has changed with the
>>>>jar dependencies so I wonder what could be different besides adding
>>>>the asymmetric binding. Both the local and tomcat use local wsdls on
>>>>runtime.
>>>>
>>>> Here is the response error I am receiving when sending the 'message':
>>>>
>>>> Caused by: javax.xml.ws.WebServiceException: Could not send Message.
>>>> at
>>>>org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:148)
>>>> at com.sun.proxy.$Proxy106.validate(Unknown Source)
>>>> at
>>>>gallup.org.oms.authentication.AuthenticationDaoDiacapJaxWsImpl.validate
>>>>(AuthenticationDaoDiacapJaxWsImpl.java:151)
>>>> ... 52 more
>>>> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response
>>>>'415: Cannot process the message because the content type 'text/xml;
>>>>charset=UTF-8' was not the expected type 'application/soap+xml;
>>>>charset=utf-8'.' when communicating with [service link]
>>>> at
>>>>org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRes
>>>>ponseInternal(HTTPConduit.java:1573)
>>>> at
>>>>org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRes
>>>>ponse(HTTPConduit.java:1525)
>>>> at
>>>>org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTT
>>>>PConduit.java:1330)
>>>> at
>>>>org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutp
>>>>utStream.java:56)
>>>> at
>>>>org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
>>>> at
>>>>org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
>>>> at
>>>>org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
>>>> at
>>>>org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEnding
>>>>Interceptor.handleMessage(MessageSenderInterceptor.java:62)
>>>> at
>>>>org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
>>>>Chain.java:307)
>>>> at
>>>>org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
>>>> at
>>>>org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
>>>> at
>>>>org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
>>>> at
>>>>org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
>>>> at
>>>>org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>>>> at
>>>>org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
>>>> ... 54 more
>>>>
>>>> The wsdl definitely states to use soap 1.2:
>>>>
>>>> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
>>>> ........
>>>> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
>>>>
>>>> The error itself points to a soap version problem and the soap
>>>>handler log payload agree with the soap having this namespace (1.1
>>>>version of soap)
>>>>
>>>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>>>>
>>>> Does anyone have a clue where to start looking or any ideas what
>>>>could be wrong? Is it possible that this is a symptom that the
>>>>policies and wsdl are not being loaded when creating the client or
>>>>something to do with the new addition of asymmetric binding only in a
>>>>real container? Any ideas are appreciated.
>>>>
>>>> Thanks,
>>>> Tim
>>>> All information in this message is confidential and may be legally
>>>>privileged. Only intended recipients are authorized to use it.
>>>>
>>> All information in this message is confidential and may be legally
>>>privileged. Only intended recipients are authorized to use it.
>>>
>> All information in this message is confidential and may be legally
>>privileged. Only intended recipients are authorized to use it.
>>
>
All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
Re: Asymmetric binding using soap 1.1 in server environment
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Can you tell us what the error was, Tim? It's always helpful to have
information like that in the email chain so people searching on similar
symptoms get an idea what to check.
Thanks,
- Dennis
On 09/30/2014 05:06 AM, Hemmer, Tim wrote:
> Hi Dennis,
>
> I believe I found the error on our side with creating the URL during the creation of the service. Now it makes sense why the policies seemed to not be in effect and it was only in the deployed version. We definitely appreciate your effort and time. Thank you sir.
>
> From: <Hemmer>, Gallup <ti...@gallup.com>>
> Date: Sunday, September 28, 2014 7:51 PM
> To: "users@cxf.apache.org<ma...@cxf.apache.org>" <us...@cxf.apache.org>>
> Subject: RE: Asymmetric binding using soap 1.1 in server environment
>
> We were always using the latest version.
>
> We recently switched to the asymmetric binding once we got the symmetric binding working with the custom wsdl that moved the individual policies into the general policy. My coworker Pohl talked to the user group about that discovery.
>
> Im going to do some checks tomorrow on the local wsdl itself to make sure it is loaded and literally the same, but I did not see any errors on the logs.
>
> Is there a way to set the soap version programmatically assuming that is the only thing that is wrong?
>
> Thanks,
> Tim
>
>
> -------- Original message --------
> From: Dennis Sosnoski <dm...@sosnoski.com>>
> Date:09/28/2014 7:44 PM (GMT-06:00)
> To: users@cxf.apache.org<ma...@cxf.apache.org>
> Cc:
> Subject: Re: Asymmetric binding using soap 1.1 in server environment
>
> Is this something which was working correctly for you with older
> releases, or is it the first time you tried the combination?
>
> - Dennis
>
> On 09/29/2014 01:22 PM, Hemmer, Tim wrote:
>> We are using the latest 3.0.1 from the July release
>>
>> Thanks,
>> Tim
>>
>>
>> -------- Original message --------
>> From: Dennis Sosnoski <dm...@sosnoski.com>>
>> Date:09/28/2014 4:55 PM (GMT-06:00)
>> To: users@cxf.apache.org<ma...@cxf.apache.org>
>> Cc:
>> Subject: Re: Asymmetric binding using soap 1.1 in server environment
>>
>> Hi Tim,
>>
>> Which version of CXF are you using? The combination of WS-Security with
>> WS-ReliableMessaging went through some major changes for 3.0, so it's
>> possible this may have changed some behaviors.
>>
>> - Dennis
>>
>> Dennis M. Sosnoski
>> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
>> CXF and Web Services Security Training
>> <http://www.sosnoski.com/training.html>
>> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>>
>> On 09/29/2014 08:18 AM, Hemmer, Tim wrote:
>>> Hello,
>>>
>>> I am witnessing a problem when running a war in a tomcat server when using Asymmetric binding, but not in my local junit tests. I added the encryption and everything works when running a local test (soap 1.2 is used). Before adding the asymmetric binding the tomcat environment also was working fine. We have always been using soap 1.2 in the evolution of this client. Please note, we are using reliable messaging (create sequence before real request) and the soap handler log will display before the policy interceptors.
>>>
>>> Now with the new changes for using encryption in cxf, along with the obvious wsdl change, on the tomcat server we are sending a soap 1.1 request for some strange reason. Nothing really has changed with the jar dependencies so I wonder what could be different besides adding the asymmetric binding. Both the local and tomcat use local wsdls on runtime.
>>>
>>> Here is the response error I am receiving when sending the 'message':
>>>
>>> Caused by: javax.xml.ws.WebServiceException: Could not send Message.
>>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:148)
>>> at com.sun.proxy.$Proxy106.validate(Unknown Source)
>>> at gallup.org.oms.authentication.AuthenticationDaoDiacapJaxWsImpl.validate(AuthenticationDaoDiacapJaxWsImpl.java:151)
>>> ... 52 more
>>> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '415: Cannot process the message because the content type 'text/xml; charset=UTF-8' was not the expected type 'application/soap+xml; charset=utf-8'.' when communicating with [service link]
>>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1573)
>>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525)
>>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
>>> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
>>> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
>>> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
>>> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
>>> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>>> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
>>> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
>>> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
>>> ... 54 more
>>>
>>> The wsdl definitely states to use soap 1.2:
>>>
>>> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
>>> ........
>>> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
>>>
>>> The error itself points to a soap version problem and the soap handler log payload agree with the soap having this namespace (1.1 version of soap)
>>>
>>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>>>
>>> Does anyone have a clue where to start looking or any ideas what could be wrong? Is it possible that this is a symptom that the policies and wsdl are not being loaded when creating the client or something to do with the new addition of asymmetric binding only in a real container? Any ideas are appreciated.
>>>
>>> Thanks,
>>> Tim
>>> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>>>
>> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>>
> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>
Re: Asymmetric binding using soap 1.1 in server environment
Posted by "Hemmer, Tim" <Ti...@gallup.com>.
Hi Dennis,
I believe I found the error on our side with creating the URL during the creation of the service. Now it makes sense why the policies seemed to not be in effect and it was only in the deployed version. We definitely appreciate your effort and time. Thank you sir.
From: <Hemmer>, Gallup <ti...@gallup.com>>
Date: Sunday, September 28, 2014 7:51 PM
To: "users@cxf.apache.org<ma...@cxf.apache.org>" <us...@cxf.apache.org>>
Subject: RE: Asymmetric binding using soap 1.1 in server environment
We were always using the latest version.
We recently switched to the asymmetric binding once we got the symmetric binding working with the custom wsdl that moved the individual policies into the general policy. My coworker Pohl talked to the user group about that discovery.
Im going to do some checks tomorrow on the local wsdl itself to make sure it is loaded and literally the same, but I did not see any errors on the logs.
Is there a way to set the soap version programmatically assuming that is the only thing that is wrong?
Thanks,
Tim
-------- Original message --------
From: Dennis Sosnoski <dm...@sosnoski.com>>
Date:09/28/2014 7:44 PM (GMT-06:00)
To: users@cxf.apache.org<ma...@cxf.apache.org>
Cc:
Subject: Re: Asymmetric binding using soap 1.1 in server environment
Is this something which was working correctly for you with older
releases, or is it the first time you tried the combination?
- Dennis
On 09/29/2014 01:22 PM, Hemmer, Tim wrote:
> We are using the latest 3.0.1 from the July release
>
> Thanks,
> Tim
>
>
> -------- Original message --------
> From: Dennis Sosnoski <dm...@sosnoski.com>>
> Date:09/28/2014 4:55 PM (GMT-06:00)
> To: users@cxf.apache.org<ma...@cxf.apache.org>
> Cc:
> Subject: Re: Asymmetric binding using soap 1.1 in server environment
>
> Hi Tim,
>
> Which version of CXF are you using? The combination of WS-Security with
> WS-ReliableMessaging went through some major changes for 3.0, so it's
> possible this may have changed some behaviors.
>
> - Dennis
>
> Dennis M. Sosnoski
> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
> CXF and Web Services Security Training
> <http://www.sosnoski.com/training.html>
> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>
> On 09/29/2014 08:18 AM, Hemmer, Tim wrote:
>> Hello,
>>
>> I am witnessing a problem when running a war in a tomcat server when using Asymmetric binding, but not in my local junit tests. I added the encryption and everything works when running a local test (soap 1.2 is used). Before adding the asymmetric binding the tomcat environment also was working fine. We have always been using soap 1.2 in the evolution of this client. Please note, we are using reliable messaging (create sequence before real request) and the soap handler log will display before the policy interceptors.
>>
>> Now with the new changes for using encryption in cxf, along with the obvious wsdl change, on the tomcat server we are sending a soap 1.1 request for some strange reason. Nothing really has changed with the jar dependencies so I wonder what could be different besides adding the asymmetric binding. Both the local and tomcat use local wsdls on runtime.
>>
>> Here is the response error I am receiving when sending the 'message':
>>
>> Caused by: javax.xml.ws.WebServiceException: Could not send Message.
>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:148)
>> at com.sun.proxy.$Proxy106.validate(Unknown Source)
>> at gallup.org.oms.authentication.AuthenticationDaoDiacapJaxWsImpl.validate(AuthenticationDaoDiacapJaxWsImpl.java:151)
>> ... 52 more
>> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '415: Cannot process the message because the content type 'text/xml; charset=UTF-8' was not the expected type 'application/soap+xml; charset=utf-8'.' when communicating with [service link]
>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1573)
>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525)
>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
>> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
>> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
>> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
>> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
>> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
>> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
>> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
>> ... 54 more
>>
>> The wsdl definitely states to use soap 1.2:
>>
>> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
>> ........
>> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
>>
>> The error itself points to a soap version problem and the soap handler log payload agree with the soap having this namespace (1.1 version of soap)
>>
>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>>
>> Does anyone have a clue where to start looking or any ideas what could be wrong? Is it possible that this is a symptom that the policies and wsdl are not being loaded when creating the client or something to do with the new addition of asymmetric binding only in a real container? Any ideas are appreciated.
>>
>> Thanks,
>> Tim
>> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>>
> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>
All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
RE: Asymmetric binding using soap 1.1 in server environment
Posted by "Hemmer, Tim" <Ti...@gallup.com>.
We were always using the latest version.
We recently switched to the asymmetric binding once we got the symmetric binding working with the custom wsdl that moved the individual policies into the general policy. My coworker Pohl talked to the user group about that discovery.
Im going to do some checks tomorrow on the local wsdl itself to make sure it is loaded and literally the same, but I did not see any errors on the logs.
Is there a way to set the soap version programmatically assuming that is the only thing that is wrong?
Thanks,
Tim
-------- Original message --------
From: Dennis Sosnoski <dm...@sosnoski.com>
Date:09/28/2014 7:44 PM (GMT-06:00)
To: users@cxf.apache.org
Cc:
Subject: Re: Asymmetric binding using soap 1.1 in server environment
Is this something which was working correctly for you with older
releases, or is it the first time you tried the combination?
- Dennis
On 09/29/2014 01:22 PM, Hemmer, Tim wrote:
> We are using the latest 3.0.1 from the July release
>
> Thanks,
> Tim
>
>
> -------- Original message --------
> From: Dennis Sosnoski <dm...@sosnoski.com>
> Date:09/28/2014 4:55 PM (GMT-06:00)
> To: users@cxf.apache.org
> Cc:
> Subject: Re: Asymmetric binding using soap 1.1 in server environment
>
> Hi Tim,
>
> Which version of CXF are you using? The combination of WS-Security with
> WS-ReliableMessaging went through some major changes for 3.0, so it's
> possible this may have changed some behaviors.
>
> - Dennis
>
> Dennis M. Sosnoski
> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
> CXF and Web Services Security Training
> <http://www.sosnoski.com/training.html>
> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>
> On 09/29/2014 08:18 AM, Hemmer, Tim wrote:
>> Hello,
>>
>> I am witnessing a problem when running a war in a tomcat server when using Asymmetric binding, but not in my local junit tests. I added the encryption and everything works when running a local test (soap 1.2 is used). Before adding the asymmetric binding the tomcat environment also was working fine. We have always been using soap 1.2 in the evolution of this client. Please note, we are using reliable messaging (create sequence before real request) and the soap handler log will display before the policy interceptors.
>>
>> Now with the new changes for using encryption in cxf, along with the obvious wsdl change, on the tomcat server we are sending a soap 1.1 request for some strange reason. Nothing really has changed with the jar dependencies so I wonder what could be different besides adding the asymmetric binding. Both the local and tomcat use local wsdls on runtime.
>>
>> Here is the response error I am receiving when sending the 'message':
>>
>> Caused by: javax.xml.ws.WebServiceException: Could not send Message.
>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:148)
>> at com.sun.proxy.$Proxy106.validate(Unknown Source)
>> at gallup.org.oms.authentication.AuthenticationDaoDiacapJaxWsImpl.validate(AuthenticationDaoDiacapJaxWsImpl.java:151)
>> ... 52 more
>> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '415: Cannot process the message because the content type 'text/xml; charset=UTF-8' was not the expected type 'application/soap+xml; charset=utf-8'.' when communicating with [service link]
>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1573)
>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525)
>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
>> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
>> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
>> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
>> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
>> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
>> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
>> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
>> ... 54 more
>>
>> The wsdl definitely states to use soap 1.2:
>>
>> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
>> ........
>> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
>>
>> The error itself points to a soap version problem and the soap handler log payload agree with the soap having this namespace (1.1 version of soap)
>>
>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>>
>> Does anyone have a clue where to start looking or any ideas what could be wrong? Is it possible that this is a symptom that the policies and wsdl are not being loaded when creating the client or something to do with the new addition of asymmetric binding only in a real container? Any ideas are appreciated.
>>
>> Thanks,
>> Tim
>> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>>
> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>
All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
Re: Asymmetric binding using soap 1.1 in server environment
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Is this something which was working correctly for you with older
releases, or is it the first time you tried the combination?
- Dennis
On 09/29/2014 01:22 PM, Hemmer, Tim wrote:
> We are using the latest 3.0.1 from the July release
>
> Thanks,
> Tim
>
>
> -------- Original message --------
> From: Dennis Sosnoski <dm...@sosnoski.com>
> Date:09/28/2014 4:55 PM (GMT-06:00)
> To: users@cxf.apache.org
> Cc:
> Subject: Re: Asymmetric binding using soap 1.1 in server environment
>
> Hi Tim,
>
> Which version of CXF are you using? The combination of WS-Security with
> WS-ReliableMessaging went through some major changes for 3.0, so it's
> possible this may have changed some behaviors.
>
> - Dennis
>
> Dennis M. Sosnoski
> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
> CXF and Web Services Security Training
> <http://www.sosnoski.com/training.html>
> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>
> On 09/29/2014 08:18 AM, Hemmer, Tim wrote:
>> Hello,
>>
>> I am witnessing a problem when running a war in a tomcat server when using Asymmetric binding, but not in my local junit tests. I added the encryption and everything works when running a local test (soap 1.2 is used). Before adding the asymmetric binding the tomcat environment also was working fine. We have always been using soap 1.2 in the evolution of this client. Please note, we are using reliable messaging (create sequence before real request) and the soap handler log will display before the policy interceptors.
>>
>> Now with the new changes for using encryption in cxf, along with the obvious wsdl change, on the tomcat server we are sending a soap 1.1 request for some strange reason. Nothing really has changed with the jar dependencies so I wonder what could be different besides adding the asymmetric binding. Both the local and tomcat use local wsdls on runtime.
>>
>> Here is the response error I am receiving when sending the 'message':
>>
>> Caused by: javax.xml.ws.WebServiceException: Could not send Message.
>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:148)
>> at com.sun.proxy.$Proxy106.validate(Unknown Source)
>> at gallup.org.oms.authentication.AuthenticationDaoDiacapJaxWsImpl.validate(AuthenticationDaoDiacapJaxWsImpl.java:151)
>> ... 52 more
>> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '415: Cannot process the message because the content type 'text/xml; charset=UTF-8' was not the expected type 'application/soap+xml; charset=utf-8'.' when communicating with [service link]
>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1573)
>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525)
>> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
>> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
>> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
>> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
>> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
>> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
>> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
>> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
>> ... 54 more
>>
>> The wsdl definitely states to use soap 1.2:
>>
>> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
>> ........
>> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
>>
>> The error itself points to a soap version problem and the soap handler log payload agree with the soap having this namespace (1.1 version of soap)
>>
>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>>
>> Does anyone have a clue where to start looking or any ideas what could be wrong? Is it possible that this is a symptom that the policies and wsdl are not being loaded when creating the client or something to do with the new addition of asymmetric binding only in a real container? Any ideas are appreciated.
>>
>> Thanks,
>> Tim
>> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>>
> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>
RE: Asymmetric binding using soap 1.1 in server environment
Posted by "Hemmer, Tim" <Ti...@gallup.com>.
We are using the latest 3.0.1 from the July release
Thanks,
Tim
-------- Original message --------
From: Dennis Sosnoski <dm...@sosnoski.com>
Date:09/28/2014 4:55 PM (GMT-06:00)
To: users@cxf.apache.org
Cc:
Subject: Re: Asymmetric binding using soap 1.1 in server environment
Hi Tim,
Which version of CXF are you using? The combination of WS-Security with
WS-ReliableMessaging went through some major changes for 3.0, so it's
possible this may have changed some behaviors.
- Dennis
Dennis M. Sosnoski
Java Web Services Consulting <http://www.sosnoski.com/consult.html>
CXF and Web Services Security Training
<http://www.sosnoski.com/training.html>
Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
On 09/29/2014 08:18 AM, Hemmer, Tim wrote:
> Hello,
>
> I am witnessing a problem when running a war in a tomcat server when using Asymmetric binding, but not in my local junit tests. I added the encryption and everything works when running a local test (soap 1.2 is used). Before adding the asymmetric binding the tomcat environment also was working fine. We have always been using soap 1.2 in the evolution of this client. Please note, we are using reliable messaging (create sequence before real request) and the soap handler log will display before the policy interceptors.
>
> Now with the new changes for using encryption in cxf, along with the obvious wsdl change, on the tomcat server we are sending a soap 1.1 request for some strange reason. Nothing really has changed with the jar dependencies so I wonder what could be different besides adding the asymmetric binding. Both the local and tomcat use local wsdls on runtime.
>
> Here is the response error I am receiving when sending the 'message':
>
> Caused by: javax.xml.ws.WebServiceException: Could not send Message.
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:148)
> at com.sun.proxy.$Proxy106.validate(Unknown Source)
> at gallup.org.oms.authentication.AuthenticationDaoDiacapJaxWsImpl.validate(AuthenticationDaoDiacapJaxWsImpl.java:151)
> ... 52 more
> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '415: Cannot process the message because the content type 'text/xml; charset=UTF-8' was not the expected type 'application/soap+xml; charset=utf-8'.' when communicating with [service link]
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1573)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
> ... 54 more
>
> The wsdl definitely states to use soap 1.2:
>
> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
> ........
> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
>
> The error itself points to a soap version problem and the soap handler log payload agree with the soap having this namespace (1.1 version of soap)
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>
> Does anyone have a clue where to start looking or any ideas what could be wrong? Is it possible that this is a symptom that the policies and wsdl are not being loaded when creating the client or something to do with the new addition of asymmetric binding only in a real container? Any ideas are appreciated.
>
> Thanks,
> Tim
> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>
All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
Re: Asymmetric binding using soap 1.1 in server environment
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Tim,
Which version of CXF are you using? The combination of WS-Security with
WS-ReliableMessaging went through some major changes for 3.0, so it's
possible this may have changed some behaviors.
- Dennis
Dennis M. Sosnoski
Java Web Services Consulting <http://www.sosnoski.com/consult.html>
CXF and Web Services Security Training
<http://www.sosnoski.com/training.html>
Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
On 09/29/2014 08:18 AM, Hemmer, Tim wrote:
> Hello,
>
> I am witnessing a problem when running a war in a tomcat server when using Asymmetric binding, but not in my local junit tests. I added the encryption and everything works when running a local test (soap 1.2 is used). Before adding the asymmetric binding the tomcat environment also was working fine. We have always been using soap 1.2 in the evolution of this client. Please note, we are using reliable messaging (create sequence before real request) and the soap handler log will display before the policy interceptors.
>
> Now with the new changes for using encryption in cxf, along with the obvious wsdl change, on the tomcat server we are sending a soap 1.1 request for some strange reason. Nothing really has changed with the jar dependencies so I wonder what could be different besides adding the asymmetric binding. Both the local and tomcat use local wsdls on runtime.
>
> Here is the response error I am receiving when sending the 'message':
>
> Caused by: javax.xml.ws.WebServiceException: Could not send Message.
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:148)
> at com.sun.proxy.$Proxy106.validate(Unknown Source)
> at gallup.org.oms.authentication.AuthenticationDaoDiacapJaxWsImpl.validate(AuthenticationDaoDiacapJaxWsImpl.java:151)
> ... 52 more
> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '415: Cannot process the message because the content type 'text/xml; charset=UTF-8' was not the expected type 'application/soap+xml; charset=utf-8'.' when communicating with [service link]
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1573)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
> ... 54 more
>
> The wsdl definitely states to use soap 1.2:
>
> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
> ........
> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
>
> The error itself points to a soap version problem and the soap handler log payload agree with the soap having this namespace (1.1 version of soap)
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>
> Does anyone have a clue where to start looking or any ideas what could be wrong? Is it possible that this is a symptom that the policies and wsdl are not being loaded when creating the client or something to do with the new addition of asymmetric binding only in a real container? Any ideas are appreciated.
>
> Thanks,
> Tim
> All information in this message is confidential and may be legally privileged. Only intended recipients are authorized to use it.
>