On Oct 30, 2012, at 12:05 PM, Gary Gregory <[email protected]> wrote:
> On Tue, Oct 30, 2012 at 11:12 AM, Daniel Kulp <[email protected]> wrote: > >> >> On Oct 29, 2012, at 6:29 PM, Gary Gregory <[email protected]> wrote: >> >>> Am I hearing different approaches here? >>> >>> (1) Don't send SOAPAction. I'm still not sure how to tell >>> JaxWsDynamicClientFactory how to do that. There is no other way than to >>> strip the header from an interceptor. >> >> If the wsdl has it in it, it should be sent. >> >>> (2) Remove SOAP actions from WSDL and JaxWsDynamicClientFactory will not >>> create the header. When I do that XMLSpy complains about the WSDL and at >>> runtime, I get some other misbehavior, like the creds are always >> rejected. >>> I'd just hacked that quickly so I am not sure of the details. >> >> That should work, or at least setting the action to the empty string. >> >>> (3) Send SOAPAction but it must be matched on the server with a CXF >> config >>> file that points to WSDLs? >> >> You should be able to have action attributes on the @WebMethod >> annotations that would allow the use of them for the code first scenarios. >> That said, if the service is represented by a wsdl, you are normally MUCH >> better off to use the actual wsdl on the service side. >> > > I need a clarification: If I give the service it's WSDL, will I still need > to strip the SOAPAction header? Shouldn't it get matched up? If the service has the wsdl with the action defined in it, it should definitely get matched up and the interceptor should not be needed. Dan > > Thank you, > Gary > > >> >> There is a 4th option: >> You could write a simple interceptor that runs early in the in chain on >> the server side that clears the SOAPAction header. >> >> >> >> Dan >> >> >> >>> >>> Thank you for your help, >>> Gary >>> >>> On Mon, Oct 29, 2012 at 5:00 PM, Glen Mazza <[email protected]> wrote: >>> >>>> You can provide the WSDL to use via the wsdlLocation attribute in the >> CXF >>>> configuration file: >>>> http://www.jroller.com/gmazza/**entry/web_service_tutorial#**WFstep6< >> http://www.jroller.com/gmazza/entry/web_service_tutorial#WFstep6> >>>> >>>> Glen >>>> >>>> >>>> On 10/29/2012 04:49 PM, Daniel Kulp wrote: >>>> >>>>> This may be on the service side: >>>>> >>>>> INFO : Creating Service {http://soap.comm.server.** >>>>> appinterface.seagullsw.com/}**LdeWebServiceProviderService< >> http://soap.comm.server.appinterface.seagullsw.com/%7DLdeWebServiceProviderService>from >> class com.seagullsw.appinterface. >>>>> **server.comm.soap.**SoapServletCxf$**LdeWebServiceProvider >>>>> >>>>> >>>>> Looks like the server side isn't using the WSDL and thus may not have >> the >>>>> proper Actions available for it. >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Oct 29, 2012, at 4:01 PM, Gary Gregory <[email protected]> >> wrote: >>>>> >>>>> Hi All: >>>>>> >>>>>> I am updating our app server to 2.7.0 from 2.6.0 and our WSS tests are >>>>>> failing. All the other tests are OK. I'm not sure if this is something >>>>>> we've gotten away with in the past with our pile of custom >> interceptors >>>>>> or >>>>>> if this is an incompatibility. It would be very difficult for me to >>>>>> extract >>>>>> a standalone test based on our code so I am taking a short cut to see >> if >>>>>> this will ring an obvious bell with someone. >>>>>> >>>>>> The test looks like this: >>>>>> >>>>>> @Test >>>>>> public void testWssNamePwd() throws Exception { >>>>>> final URL wsdl = >>>>>> ClassLoader.getSystemResource(**this.getConfigResource() + >>>>>> "/functions/TestBackEndWss.**wsdl"); >>>>>> final Client client = >>>>>> JaxWsDynamicClientFactory.**newInstance().createClient(** >>>>>> wsdl.toExternalForm()); >>>>>> final Map<String, Object> outProps = new HashMap<String, >>>>>> Object>(); >>>>>> outProps.put(**WSHandlerConstants.ACTION, >>>>>> WSHandlerConstants.USERNAME_**TOKEN); >>>>>> outProps.put(**WSHandlerConstants.PASSWORD_**TYPE, >>>>>> WSConstants.PW_TEXT); >>>>>> outProps.put(**WSHandlerConstants.USER, >>>>>> AisTestBackEnd.USER_NAME); >>>>>> outProps.put(**WSHandlerConstants.PW_**CALLBACK_REF, new >>>>>> CallbackHandler() { >>>>>> @Override >>>>>> public void handle(final Callback[] callbacks) { >>>>>> final WSPasswordCallback callback = >> (WSPasswordCallback) >>>>>> callbacks[0]; >>>>>> callback.setPassword(**AisTestBackEnd.PASSWORD); >>>>>> } >>>>>> }); >>>>>> client.getOutInterceptors().**add(new >>>>>> WSS4JOutInterceptor(outProps))**; >>>>>> final String ARG_VALUE = "string arg value"; >>>>>> Object[] results = >>>>>> client.invoke(AisTestBackEnd.**ONESTRINGARGWSS_USERNAMETOKEN_** >>>>>> FUNCTION_NAME, >>>>>> new Object[] { ARG_VALUE }); >>>>>> Assert.assertNotNull(results); >>>>>> Assert.assertNotNull(results[**0]); >>>>>> Assert.assertTrue(((String) results[0]).indexOf(ARG_VALUE) > >> 0); >>>>>> //more asserts... >>>>>> >>>>>> This is the exception I see: >>>>>> >>>>>> 2012-10-29 15:04:40,656 [qtp563831333-20 - /lde/] WARN : Interceptor >> for >>>>>> { >>>>>> http://soap.comm.server.**appinterface.seagullsw.com/}** >>>>>> LdeWebServiceProviderService#{**http://soap.comm.server.** >>>>>> appinterface.seagullsw.com/}**invokehas< >> http://soap.comm.server.appinterface.seagullsw.com/%7DLdeWebServiceProviderService#%7Bhttp://soap.comm.server.appinterface.seagullsw.com/%7Dinvokehas >>> >>>>>> thrown exception, unwinding now >>>>>> org.apache.cxf.interceptor.**Fault: The given SOAPAction >>>>>> test.**oneStringArgWssUsernameToken does not match an operation. >>>>>> at >>>>>> org.apache.cxf.binding.soap.**interceptor.**SoapActionInInterceptor$** >>>>>> SoapActionInAttemptTwoIntercep**tor.handleMessage(** >>>>>> SoapActionInInterceptor.java:**188) >>>>>> at >>>>>> org.apache.cxf.binding.soap.**interceptor.**SoapActionInInterceptor$** >>>>>> SoapActionInAttemptTwoIntercep**tor.handleMessage(** >>>>>> SoapActionInInterceptor.java:**162) >>>>>> at >>>>>> org.apache.cxf.phase.**PhaseInterceptorChain.**doIntercept(** >>>>>> PhaseInterceptorChain.java:**271) >>>>>> at >>>>>> org.apache.cxf.transport.**ChainInitiationObserver.**onMessage(** >>>>>> ChainInitiationObserver.java:**121) >>>>>> at >>>>>> org.apache.cxf.transport.http.**AbstractHTTPDestination.**invoke(** >>>>>> AbstractHTTPDestination.java:**238) >>>>>> at >>>>>> org.apache.cxf.transport.**servlet.ServletController.** >>>>>> invokeDestination(**ServletController.java:222) >>>>>> at >>>>>> org.apache.cxf.transport.**servlet.ServletController.** >>>>>> invoke(ServletController.java:**202) >>>>>> at >>>>>> org.apache.cxf.transport.**servlet.ServletController.** >>>>>> invoke(ServletController.java:**137) >>>>>> at >>>>>> org.apache.cxf.transport.**servlet.CXFNonSpringServlet.** >>>>>> invoke(CXFNonSpringServlet.**java:158) >>>>>> at >>>>>> >> org.apache.cxf.transport.**servlet.AbstractHTTPServlet.**handleRequest(* >>>>>> *AbstractHTTPServlet.java:239) >>>>>> at >>>>>> org.apache.cxf.transport.**servlet.AbstractHTTPServlet.** >>>>>> doPost(AbstractHTTPServlet.**java:159) >>>>>> at javax.servlet.http.**HttpServlet.service(**HttpServlet.java:754) >>>>>> at >>>>>> org.apache.cxf.transport.**servlet.AbstractHTTPServlet.** >>>>>> service(AbstractHTTPServlet.**java:215) >>>>>> at >>>>>> org.eclipse.jetty.servlet.**ServletHolder.handle(** >>>>>> ServletHolder.java:648) >>>>>> at >>>>>> org.eclipse.jetty.servlet.**ServletHandler.doHandle(** >>>>>> ServletHandler.java:455) >>>>>> at >>>>>> org.eclipse.jetty.server.**handler.ContextHandler.** >>>>>> doHandle(ContextHandler.java:**1072) >>>>>> at >>>>>> org.eclipse.jetty.servlet.**ServletHandler.doScope(** >>>>>> ServletHandler.java:382) >>>>>> at >>>>>> org.eclipse.jetty.server.**handler.ContextHandler.** >>>>>> doScope(ContextHandler.java:**1006) >>>>>> at >>>>>> org.eclipse.jetty.server.**handler.ScopedHandler.handle(** >>>>>> ScopedHandler.java:135) >>>>>> at >>>>>> >> org.eclipse.jetty.server.**handler.**ContextHandlerCollection.**handle(* >>>>>> *ContextHandlerCollection.java:**255) >>>>>> at >>>>>> org.eclipse.jetty.server.**handler.HandlerWrapper.handle(** >>>>>> HandlerWrapper.java:116) >>>>>> at org.eclipse.jetty.server.**Server.handle(Server.java:361) >>>>>> at >>>>>> org.eclipse.jetty.server.**AbstractHttpConnection.**handleRequest(** >>>>>> AbstractHttpConnection.java:**485) >>>>>> at >>>>>> org.eclipse.jetty.server.**AbstractHttpConnection.**content(** >>>>>> AbstractHttpConnection.java:**937) >>>>>> at >>>>>> org.eclipse.jetty.server.**AbstractHttpConnection$** >>>>>> RequestHandler.content(**AbstractHttpConnection.java:**998) >>>>>> at org.eclipse.jetty.http.**HttpParser.parseNext(** >>>>>> HttpParser.java:856) >>>>>> at org.eclipse.jetty.http.**HttpParser.parseAvailable(** >>>>>> HttpParser.java:240) >>>>>> at >>>>>> org.eclipse.jetty.server.**AsyncHttpConnection.handle(** >>>>>> AsyncHttpConnection.java:82) >>>>>> at >>>>>> org.eclipse.jetty.io.nio.**SelectChannelEndPoint.handle(** >>>>>> SelectChannelEndPoint.java:**627) >>>>>> at >>>>>> org.eclipse.jetty.io.nio.**SelectChannelEndPoint$1.run(** >>>>>> SelectChannelEndPoint.java:51) >>>>>> at >>>>>> org.eclipse.jetty.util.thread.**QueuedThreadPool.runJob(** >>>>>> QueuedThreadPool.java:608) >>>>>> at >>>>>> org.eclipse.jetty.util.thread.**QueuedThreadPool$3.run(** >>>>>> QueuedThreadPool.java:543) >>>>>> at java.lang.Thread.run(Unknown Source) >>>>>> >>>>>> The debug log which includes CXF, Jetty and our own logging is here: >>>>>> http://pastebin.com/LXb9vjQD >>>>>> >>>>>> The WSDL is here: http://pastebin.com/y12erjaw >>>>>> >>>>>> Thank you in advance for any guidance you can give me in figuring this >>>>>> out. >>>>>> >>>>>> Gary >>>>>> >>>>>> -- >>>>>> E-Mail: [email protected] | [email protected] >>>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http:/**/ >> bit.ly/ECvg0<http://bit.ly/ECvg0> >>>>>> Spring Batch in Action: <http://s.apache.org/HOq>http:**// >> bit.ly/bqpbCK<http://bit.ly/bqpbCK> >>>>>> Blog: http://garygregory.wordpress.**com< >> http://garygregory.wordpress.com> >>>>>> Home: http://garygregory.com/ >>>>>> Tweet! http://twitter.com/GaryGregory >>>>>> >>>>> >>>> >>>> -- >>>> Glen Mazza >>>> Talend Community Coders - coders.talend.com >>>> blog: www.jroller.com/gmazza >>>> >>>> >>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> > > > -- > E-Mail: [email protected] | [email protected] > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
