Description of problem: SwitchYard tutorial does not work Approached wsdl in browser: <soap:Envelope><soap:Header/><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>Fault occurred while processing.</faultstring></soap:Fault></soap:Body></soap:Envelope> Version-Release number of selected component (if applicable): * 6.0.0.ER3 How reproducible: Steps to Reproduce: 1. Follow steps at https://docs.jboss.org/author/display/SWITCHYARD/Quick+Start 2. Run on server (FSW 6.0.0.ER3) 3. Approach depoyed wsdl file Actual results: * Server log: http://pastebin.test.redhat.com/167233 (FSW 6.0.0.ER3) Expected results: Additional info: * Reproducable also with SwitchYard 1.0.0.Final
Created attachment 805762 [details] Application according to the tutorial
The same exception is raised when deploying switchyard-quickstart-bean-service packaged with FSW 6.0.0.ER3
This exception occurs only when navigating browser to http://localhost:8080/quickstart-bean/OrderService. Url http://localhost:8080/quickstart-bean/OrderService?wsdl works correctly.
There's nothing in the stack trace related to SY at all - this error is being generated directly from JBoss WS + CXF. For kicks, I deployed a standard JAX-WS @WebService with no SwitchYard bits at all and still get an exception (although it's a different one). The big difference is that the HTTP GET reply is an actual SOAP fault with a helpful error message ("No such operation: / (HTTP GET PATH_INFO: /CreditService/"), which is a bit nicer than the empty reply and NPE that a SY web service returns today. Top of stack pasted below for reference. Assigning to Magesh to see if there is anything we can do differently with how we register web service endpoints with JBoss WS. 13:00:39,016 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (http-/127.0.0.1:8080-1) Interceptor for {http://mortgages/}CreditWebServiceService has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: No such operation: / (HTTP GET PATH_INFO: /CreditService/) at org.apache.cxf.interceptor.URIMappingInterceptor.handleMessage(URIMappingInterceptor.java:93) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:237) at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:95) at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:156) at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
This issue has minimal impact as it only surfaces if someone issues a GET request against the endpoint. This should return a fault to the invoker.