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" <[email protected]> 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 >><[email protected]<mailto:[email protected]>> >> Date: Sunday, September 28, 2014 7:51 PM >> To: "[email protected]<mailto:[email protected]>" >><[email protected]<mailto:[email protected]>> >> 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 <[email protected]<mailto:[email protected]>> >> Date:09/28/2014 7:44 PM (GMT-06:00) >> To: [email protected]<mailto:[email protected]> >> 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 <[email protected]<mailto:[email protected]>> >>> Date:09/28/2014 4:55 PM (GMT-06:00) >>> To: [email protected]<mailto:[email protected]> >>> 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.
