Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: users@cxf.apache.org
Subject: Re: Found element ... but could not find matching RPC/Literal part
Date: Fri, 23 Jan 2009 13:32:03 -0500
User-Agent: KMail/1.9.9
Cc: Milan Satala <milan.satala@gmail.com>
References: <21624834.post@talk.nabble.com>
In-Reply-To: <21624834.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200901231332.03818.dkulp@apache.org>


There really are two options:

1) Download the wsdl and edit it to match what the service really produces.   
In this case, all the part names of "parameters" need to be mapped into the 
appropriate name.   ("createLearningActivityReturn")    Then use this wsdl 
instead of the "live" wsdl.

2) Write an interceptor that would run just before the RPCInInterceptor that 
takes the XmlStreamReader and wrappers it with a new XmlStreamReader that 
would map the QNames to the expected names.   


Dan


On Friday 23 January 2009 8:56:50 am Milan Satala wrote:
> org.apache.cxf.interceptor.Fault: Found element
> createLearningActivityReturn but could not find matching RPC/Literal part
>
> I get the exception when invoking this webservice:
> http://prolixdev7.prolix-dev.de/xosoap/services/prolix/pms/PMSServiceImpl?s
>=wsdl The webservice is called properly but it seems that CXF fails to
> process the response message.
> After searching through the mailing list I discovered that this exception
> is probably caused by the webservice framework on the server side
> (AOLServer 4.5) not following WSI-Basic Profile standard.
>
> Since the webservice framework can not be changed I was wondering if it was
> possible to make CXF less strict about the response. I found the following
> message by a developer "dkulp" on this mailing list:
>
> "At one point (don't remember when) I did update the RPCInInterceptor to
> only compare local names and ignore the namespace to workaround issues
> with non WS-I BP compliant services.  The messages CXF generates are
> always WS-I BP compliant, but it should be able to process the
> non-compliant messages as well.     I THINK that made it into 2.0.2, but
> it might not have made it so would be in 2.0.3.   Can you check the
> 2.0.3 SNAPSHOT version and see if that works?"
>
> However I'm using CXF 2.1 and still get the exception.
> I know this isn't CXFs fault but is there a way to make it compatibile with
> the other framework?
>
> Here's the response I get when calling the webservice using xmlspy:
> <SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
> 	<SOAP-ENV:Body>
> 		<m:createLearningActivityResponse xmlns:m="Some-URI">
> 			<createLearningActivityReturn>
> 				<header>
> 					<timestamp>2008-01-01T08:08:08.0Z</timestamp>
> 					<processId>1</processId>
> 					<userToken>rehjb6n06ghhkmpp5hgsonfo4d</userToken>
> 					<receiver>String</receiver>
> 					<sender>Performance Monitor System</sender>
> 					<messageId>1</messageId>
> 				</header>
> 				<body>
> 					<message>The learning activity is already added to the system LID:
> String</message>
> 					<returnCode>0</returnCode>
> 				</body>
> 			</createLearningActivityReturn>
> 		</m:createLearningActivityResponse>
> 	</SOAP-ENV:Body>
> </SOAP-ENV:Envelope>


-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog