Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of shak.shaik@gmail.com designates
 209.85.212.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F3021DC.7010600@talend.com>
References: 
 <CAL7AqW5o=+MQXE_enc4=8sn_=BVDc5unvhvRFoWncbb_B1Stpw@mail.gmail.com>
	<4F3021DC.7010600@talend.com>
Date: Mon, 6 Feb 2012 14:23:53 -0600
Message-ID: 
 <CAL7AqW7Dpgir5fsZ3PCDw7jJ7z=gnR3-xUc=6jKNKj77bJ-Osw@mail.gmail.com>
Subject: Re: CXF SOAP 1.2 and .net Client
From: Shakeel Shaik <shak.shaik@gmail.com>
To: users@cxf.apache.org
Content-Type: multipart/alternative; boundary=f46d04430664f0dfe804b8517060

--f46d04430664f0dfe804b8517060
Content-Type: text/plain; charset=ISO-8859-1

Hello Glen,

Thanks for your inputs.
I will go through the tutorials and will try to find the issue.

Thanks,
Shak

On Mon, Feb 6, 2012 at 12:54 PM, Glen Mazza <gmazza@talend.com> wrote:

> The SOAP request would need to use POST, because it's the POST payload
> that holds the SOAP request (Examples: http://www.jroller.com/gmazza/**
> entry/metro_wstrust_analysis<http://www.jroller.com/gmazza/entry/metro_wstrust_analysis>).
>  GET is used in REST calls, and it could be your external client has only
> been working with RESTful (and not SOAP) services, which is why other calls
> are working but not your SOAP one.  If that's the case, you can refer your
> client here[2] to show how to quickly get a SOAP client running using
> either Metro or CXF.  Another possibility is that the external client is
> using SOAP 1.1 calls and not SOAP 1.2, this article[3] has some conversion
> info.
>
> The error stack is probably of secondary importance here.  I'd first use
> Wireshark[1] (or another tool) to grab the SOAP request (the incoming XML)
> you're receiving from the client.  Next compare that to a working SOAP
> request, see what's different and then determine whether the problem is
> with your web service provider or the external user's SOAP client not
> supplying a correct request format.  So long as your web service is
> accepting valid SOAP requests, the problem should be with their client and
> not your web service.
>
> Glen
>
> [1] http://www.jroller.com/gmazza/**entry/soap_calls_over_**wireshark<http://www.jroller.com/gmazza/entry/soap_calls_over_wireshark>
> [2] http://www.jroller.com/gmazza/**entry/soap_client_tutorial<http://www.jroller.com/gmazza/entry/soap_client_tutorial>
> [3] http://www.jroller.com/gmazza/**entry/switch_soap11_to_soap12<http://www.jroller.com/gmazza/entry/switch_soap11_to_soap12>
>
>
> On 02/06/2012 01:16 PM, Shakeel Shaik wrote:
>
>> Hello CXF users/developers,
>>
>> I've bunch of CXF java first web services with SOAP.1.2. One of our client
>> is trying to consume the service but ended-up with timeout. our logs shows
>> that the request is coming in form of GET (not SOAP/post). Please find the
>> following  log for more information.
>> Our client says that their framework is pretty standard one and they say
>> that using thier framework, they are callign other services without any
>> issue except the service that I developed using and CXF.
>>
>> Any help will be appreciated and thanks in advance.
>>
>>
>>
>> org.apache.cxf.interceptor.**Fault: No such operation:  (HTTP GET
>> PATH_INFO:
>> /webservice-cxf/SomeService)
>>     at
>> org.apache.cxf.interceptor.**URIMappingInterceptor.**handleMessage(**
>> URIMappingInterceptor.java:88)
>>     at
>> org.apache.cxf.phase.**PhaseInterceptorChain.**doIntercept(**
>> PhaseInterceptorChain.java:**263)
>>     at
>> org.apache.cxf.transport.**ChainInitiationObserver.**onMessage(**
>> ChainInitiationObserver.java:**118)
>>     at
>> org.apache.cxf.transport.http.**AbstractHTTPDestination.**invoke(**
>> AbstractHTTPDestination.java:**208)
>>     at
>> org.apache.cxf.transport.**servlet.ServletController.**invokeDestination(
>> **ServletController.java:223)
>>     at
>> org.apache.cxf.transport.**servlet.ServletController.**
>> invoke(ServletController.java:**205)
>>     at
>> org.apache.cxf.transport.**servlet.CXFNonSpringServlet.**
>> invoke(CXFNonSpringServlet.**java:113)
>>     at
>> org.apache.cxf.transport.**servlet.AbstractHTTPServlet.**handleRequest(**
>> AbstractHTTPServlet.java:184)
>>     at
>> org.apache.cxf.transport.**servlet.AbstractHTTPServlet.**
>> doGet(AbstractHTTPServlet.**java:112)
>>     at javax.servlet.http.**HttpServlet.service(**HttpServlet.java:707)
>>     at
>> org.apache.cxf.transport.**servlet.AbstractHTTPServlet.**
>> service(AbstractHTTPServlet.**java:163)
>>     at
>> weblogic.servlet.internal.**StubSecurityHelper$**
>> ServletServiceAction.run(**StubSecurityHelper.java:227)
>>     at
>> weblogic.servlet.internal.**StubSecurityHelper.**invokeServlet(**
>> StubSecurityHelper.java:125)
>>     at
>> weblogic.servlet.internal.**ServletStubImpl.execute(**
>> ServletStubImpl.java:292)
>>     at
>> weblogic.servlet.internal.**ServletStubImpl.execute(**
>> ServletStubImpl.java:175)
>>     at
>> weblogic.servlet.internal.**WebAppServletContext$**
>> ServletInvocationAction.run(**WebAppServletContext.java:**3498)
>>     at
>> weblogic.security.acl.**internal.AuthenticatedSubject.**
>> doAs(AuthenticatedSubject.**java:321)
>>     at weblogic.security.service.**SecurityManager.runAs(Unknown Source)
>>     at
>> weblogic.servlet.internal.**WebAppServletContext.**securedExecute(**
>> WebAppServletContext.java:**2180)
>>     at
>> weblogic.servlet.internal.**WebAppServletContext.execute(**
>> WebAppServletContext.java:**2086)
>>     at
>> weblogic.servlet.internal.**ServletRequestImpl.run(**
>> ServletRequestImpl.java:1406)
>>     at weblogic.work.ExecuteThread.**execute(ExecuteThread.java:**201)
>>     at weblogic.work.ExecuteThread.**run(ExecuteThread.java:173)
>>
>> Thanks,
>> Shak.
>>
>>
>
> --
> Glen Mazza
> Talend Community Coders - coders.talend.com
> blog: www.jroller.com/gmazza
>
>

--f46d04430664f0dfe804b8517060--