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" <tim_hem...@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" <d...@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 >>><tim_hem...@gallup.com<mailto:tim_hem...@gallup.com>> >>> Date: Sunday, September 28, 2014 7:51 PM >>> To: "users@cxf.apache.org<mailto:users@cxf.apache.org>" >>><users@cxf.apache.org<mailto:users@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 <d...@sosnoski.com<mailto:d...@sosnoski.com>> >>> Date:09/28/2014 7:44 PM (GMT-06:00) >>> To: users@cxf.apache.org<mailto: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 <d...@sosnoski.com<mailto:d...@sosnoski.com>> >>>> Date:09/28/2014 4:55 PM (GMT-06:00) >>>> To: users@cxf.apache.org<mailto: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.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.
