Hi Tom, Glad to hear that you no longer support the parameters hack!
FYI- I hear that both the .Net and JAX-RPC RIs happily ignore any attributes on the XSDs. Nice. Sanjiva. ----- Original Message ----- From: "Tom Jordahl" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 26, 2002 9:48 PM Subject: Support for wrapped document/literal > Sanjiva wrote: > > I would find that a lot more compelling than just supporting > > MSFT stuff. Axis' support of the "parameters" hack is something > > that really bothers me. > > I will note that we don't support the MS "parameters" hack directly any more. What we do is support "wrapped doc/lit" as (sort of) defined by JAX-RPC. That is we follow these rules > > - If there is a single message part defined using element="" > - If there are no attributes on the element > - If the element QName matches the operation QName > THEN > - Treat each of the elements in the message part as arguments to the stub function (i.e. unwrap the augments from the enclosing element). > > What we *used* to do was recognize a single part with the name "parameters" as wrapped and treat it as above. > > -- > Tom Jordahl > Macromedia Server Development > > > > -----Original Message----- > From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 26, 2002 11:33 AM > To: [EMAIL PROTECTED] > Subject: Re: [Q] Axis support for MS SQL Server SOAP... > > > Before supporting an MSFT schema, why not examine whether > JDBC's ResultSet stuff can be mapped .. its my anti-MSFT > juices flowing thru. > > We actually did that a while ago with Apache SOAP - wrote > a provider that made DB2 stored procedures into Web services. > (I think that provider was internal but it was released as > part of the product.) Effectively all you need to do is map > the JDBC types to XSD and pretty much any stored proc in > any JDBC-compliant database can be made into a Web service > just like that. > > I would fine that a lot more compelling than just supporting > MSFT stuff. Axis' support of the "parameters" hack is something > that really bothers me. > > Sanjiva. > > ----- Original Message ----- > From: "Tom Jordahl" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, September 26, 2002 7:50 PM > Subject: RE: [Q] Axis support for MS SQL Server SOAP... > > > > > > I believe this is the .NET "DataSet" Schema, for which there is a bug - > 8419. > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8419 > > > > Axis does not currently support this. If you are interested > > in providing a patch to support this, that would be great. > > It would certainly help our interop with MS technologies. > > > > -- > > Tom Jordahl > > Macromedia > > > > > > > > -----Original Message----- > > From: Per Kreipke [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 26, 2002 9:44 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [Q] Axis support for MS SQL Server SOAP... > > > > > > Let me rephrase into a question: > > > > Does axis have support for the 'xsd:schema' type? It currently causes an > > unreferenced type exception in WSDL2Java. > > > > > FYI, if you're interested... > > > > > > I am able to call MS SQL Server via SOAP using Axis, after a couple of > > > tweaks and work arounds. > > > > > > The MS SQL Server SOAP handler emits the following segment in its WSDL: > > > > > > ... > > > <xsd:complexType name='SqlRowSet'> > > > <xsd:sequence> > > > <xsl:element ref='xsd:schema'/> > > > <xsd:any/> > > > </xsd:sequence> > > > <xsd:attribute ref='sqltypes:IsNested'/> > > > </xsd:complexType> > > > ... > > > > > > > > > The reference to 'xsd:schema' causes an exception in WSDL2Java for an > > > unreferenced type. > > > > > > If I hand edit the WSDL to change it to 'xsd:string', I can get > > > WSDL2Java to > > > emit the Java I need, even though I have to avoid using that type (e.g. > > > structure my code to not use it). > > > > > > > > > > > > Also, Axis does not handle output parameters from SQL Server SOAP > > > correctly > > > (I can't remember the error, I've had to work around it). I saw today > that > > > there was a fix for output parameters in the last spot. If I can find > the > > > time, I'll see if it fixes things. > > > > > > > > > Per > > > > > >
