axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: PATCH to RPCHandler
Date Wed, 07 Nov 2001 22:49:53 GMT

There are no types in your response, which means that some sort of metadata
should be used to figure out how to deserialize it.  The SOAP 2.X solution
to this was to "cheat" by registering types that matched the element names,
and then to look for the element QName in the type mapping registry if no
xsi:type attribute was found.  If that's where your patch was trying to go,
it's definitely the wrong approach (it's very brittle, for one thing - what
if two services both use the same element name with different types?).

A much better solution is explicit metadata, such as might be found in a
WSDL document or some other kind of service description.  Axis used to do
this with the ServiceDescription class, but the functionality appears to
have been temporarily disabled during the transition over to the Call
object....

Also, the code you pulled out was NOT in fact unreachable, although it could
have been moved inside the if (type != null) clause.  What if the type is
there, but the type mapping registry couldn't figure out what to do with it?

--Glen

> -----Original Message-----
> From: Mark Roder [mailto:mroder@wamnet.com]
> Sent: Wednesday, November 07, 2001 5:12 PM
> To: 'axis-dev@xml.apache.org'
> Subject: RE: PATCH to RPCHandler
> 
> 
> 
> 
> 
> 
> In my message last week I gave a version of bidbuy that 
> returns a Receipt
> object with no namespaces that trips the same problem.  That 
> might be the
> best way to reproduce it.
> 
> The problem I had was in processing this response:
> 
> HTTP/1.1 200 OK Date: Wed, 07 Nov 2001 21:58:42 GMT Server: 
> Apache/1.3.11
> (Unix) mod_ssl/2.5.0 OpenSSL/0.9.4 Connection: close 
> Content-Type: text/xml
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
> 	<soap:Header>
> 	
> 	</soap:Header>
> 	<soap:Body>
> 		<m:GetLibrariesResponse
> xmlns:m="urn:schemas-wamnet-com:Archive">
> 			<Libraries> 
> 				<Library>
> 					<LibraryName>Beta1
> Library</LibraryName>
> 					<LibraryID>4110401</LibraryID>
> 				</Library>
> 			</Libraries>
> 		</m:GetLibrariesResponse>
> 	</soap:Body>
> </soap:Envelope>
> 
> The code would not be able to find the type using
> context.getTypeByAttributes when a empty string was passed in as the
> namespace.  It might really be a registering types with no 
> namespace that is
> the root problem, but my understanding of the big picture is 
> not there yet.
> 
> I removed the throw of the SAXException because it was 
> unreachable code in
> the old version and in my version.  The dser value was always 
> set before it
> got to the if statement.
> 
> Later
> 
> Mark
> 
> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@macromedia.com]
> Sent: Wednesday, November 07, 2001 3:47 PM
> To: 'axis-dev@xml.apache.org'
> Subject: RE: PATCH to RPCHandler
> 
> 
> 
> Mark, I don't understand this patch - could you explain 
> exactly what the
> issue was?  Seems like a bad idea to remove the ability to 
> fault if we can't
> figure out the type...?
> 
> I must admit to also being a little confused as to why the 
> code which used
> the ServiceDescription to figure out types in here is now 
> gone (Doug?) - I
> need to read up on the current state of the code to see where this is
> happening now.
> 
> > -----Original Message-----
> > From: Mark Roder [mailto:mroder@wamnet.com]
> > Sent: Wednesday, November 07, 2001 2:04 PM
> > To: 'axis-dev@xml.apache.org '
> > Subject: PATCH to RPCHandler
> > 
> > 
> > 
> > This patch will also use a QName to find a deserializer.  I 
> was having
> > problems where my results did not include namespaces or xsi 
> > type information
> > and this was needed.
> > 
> > Later
> > 
> > Mark
> > 
> > 
> 

Mime
View raw message