axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wessel Alexander <002-...@adv.magwien.gv.at>
Subject RE: Array of Objects in Axis and .NET interop
Date Thu, 11 Nov 2004 15:55:54 GMT
Hi Axisants!

KHS, Thanks for the info. However, I don't see any change whether I configure the operation
as you stated or not. 

Digging for the cause of our problems we have found out: The XML returned is definetely different
depending on wether you call the service via URL (query string) or actually invoke the service
from a (java, in this case) client (I'll show this later)!

Note: All of the following applies to Axis 1.2RC1!

I wrote the following small testcase -- a service called "TestTerminal" providing only one
operation (this is actually from my real code, so excuse me for not "foobar-ifying" it...
;)

package at.gv.wien.advinstaller.v2.server;
public interface TestTerminalInterface
{
    public at.gv.wien.advinstaller.v2.entity.Terminal[] queryByClientCName(String clientCNameWildcard);
}

This interface is implemented by a hand-written (not generated!) at.gv.wien.advinstaller.v2.server.TestTerminalSoapBindingImpl.
at.gv.wien.advinstaller.v2.entity.Terminal is just a simple Bean, derived from another simple
Bean abstract class at.gv.wien.advinstaller.v2.entity.Node.


The WSDD looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="http://xml.apache.org/axis/wsdd/" 
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
            xmlns:aiv2server="urn:server.v2.advinstaller.wien.gv.at"
            xmlns:aiv2entity="urn:entity.v2.advinstaller.wien.gv.at"
            xmlns:aiv2soapbinding="urn:soapbinding.v2.advinstaller.wien.gv.at"
            xmlns:aiv2schema="urn:schema.v2.advinstaller.wien.gv.at">

    <!-- TestTerminal -->
    <service name="advinstaller_v2/TestTerminal" style="wrapped">
      <namespace>urn:schema.v2.advinstaller.wien.gv.at</namespace>

      <parameter name="wsdlTargetNamespace" value="urn:soapbinding.v2.advinstaller.wien.gv.at"/>
      <parameter name="wsdlServiceElement" value="TestTerminalService"/>
      <parameter name="wsdlServicePort" value="TestTerminal"/>
      <parameter name="wsdlPortType" value="TestTerminalInterface"/>

      <parameter name="className"  value="at.gv.wien.advinstaller.v2.server.TestTerminalSoapBindingImpl"/>
      <parameter name="allowedMethods" value="*"/>
      
      <beanMapping qname="aiv2entity:Node" 
	             languageSpecificType="java:at.gv.wien.advinstaller.v2.entity.Node"/>

	<beanMapping qname="aiv2entity:Terminal" 
	             languageSpecificType="java:at.gv.wien.advinstaller.v2.entity.Terminal"/>
    </service>
</deployment>

Those aiv2*-Namespaces refer to packages in my application, with one exception: 

"urn:entity..." holds all the bean classes.
"urn:server..." holds the service interfaces and implementation classes.
"urn:soapbinding..." I define this as the WSDL targetNamespace. There is a java package of
the same name which contains classes generated by Java2WSDL, but I use those only for JUnit
tests but not for anything on the server side. 
"urn:schema..." this namespace is only used in the WSDD. Setting it per service makes all
generated stuff go into that namespace, unless a namespace is given. So this does not refer
to a java package.

Now this is the generated WSDL (as per "http://.../advinstaller_v2/TestTerminal?wsdl"):

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="urn:soapbinding.v2.advinstaller.wien.gv.at" xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="urn:soapbinding.v2.advinstaller.wien.gv.at" xmlns:intf="urn:soapbinding.v2.advinstaller.wien.gv.at"
xmlns:tns1="urn:schema.v2.advinstaller.wien.gv.at" xmlns:tns2="urn:entity.v2.advinstaller.wien.gv.at"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.2RC1
Built on Sep 29, 2004 (08:29:40 EDT)-->
 <wsdl:types>

  <schema elementFormDefault="qualified" targetNamespace="urn:schema.v2.advinstaller.wien.gv.at"
xmlns="http://www.w3.org/2001/XMLSchema">

   <import namespace="urn:entity.v2.advinstaller.wien.gv.at"/>

   <element name="queryByClientCName">
    <complexType>
     <sequence>
      <element name="clientCNameWildcard" type="xsd:string"/>
     </sequence>
    </complexType>
   </element>

   <element name="queryByClientCNameResponse">
    <complexType>
     <sequence>
      <element maxOccurs="unbounded" name="queryByClientCNameReturn" type="tns2:Terminal"/>
     </sequence>
    </complexType>
   </element>

  </schema>

  <schema elementFormDefault="qualified" targetNamespace="urn:entity.v2.advinstaller.wien.gv.at"
xmlns="http://www.w3.org/2001/XMLSchema">

   <complexType abstract="true" name="Node">
    <sequence>
     <element name="name" nillable="true" type="xsd:string"/>
     <element name="id" type="xsd:long"/>
    </sequence>
   </complexType>

   <complexType name="Terminal">
    <complexContent>
     <extension base="tns2:Node">
      <sequence>
       <element name="itsOrganizationId" type="xsd:long"/>
       <element name="serialNr" nillable="true" type="xsd:string"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

  </schema>
 </wsdl:types>

   <wsdl:message name="queryByClientCNameResponse">
      <wsdl:part element="tns1:queryByClientCNameResponse" name="parameters"/>
   </wsdl:message>

   <wsdl:message name="queryByClientCNameRequest">
      <wsdl:part element="tns1:queryByClientCName" name="parameters"/>
   </wsdl:message>

   <wsdl:portType name="TestTerminalInterface">
      <wsdl:operation name="queryByClientCName">
         <wsdl:input message="impl:queryByClientCNameRequest" name="queryByClientCNameRequest"/>
         <wsdl:output message="impl:queryByClientCNameResponse" name="queryByClientCNameResponse"/>
      </wsdl:operation>
   </wsdl:portType>

   <wsdl:binding name="TestTerminalSoapBinding" type="impl:TestTerminalInterface">
      <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
      <wsdl:operation name="queryByClientCName">
         <wsdlsoap:operation soapAction=""/>
         <wsdl:input name="queryByClientCNameRequest">
            <wsdlsoap:body use="literal"/>
         </wsdl:input>
         <wsdl:output name="queryByClientCNameResponse">
            <wsdlsoap:body use="literal"/>
         </wsdl:output>
      </wsdl:operation>
   </wsdl:binding>

   <wsdl:service name="TestTerminalService">
      <wsdl:port binding="impl:TestTerminalSoapBinding" name="TestTerminal">
         <wsdlsoap:address location="http://localhost:8080/axis/services/advinstaller_v2/TestTerminal"/>
      </wsdl:port>
   </wsdl:service>
</wsdl:definitions>

Note that the WSDL creates two schemata: One for the "urn:schemas..." namespace, and another
for the "urn:entity..." namespace. Note also that the "urn:entity:..." namespace is imported
into the "urn:schema..." namespace.

Now my Terminal is defined in the "urn:entity..." namespace, while all the SOAP-related stuff
goes into the "urn:schema..." namespace. So I am quite satisfied with the generated WSDL.
I really wouldn't do it differently had I not generated the WSDL, apart maybe from using different
names for the wrapper elements, maybe.

Now lets see what we get by calling http://localhost:8080/axis/services/advinstaller_v2/TestTerminal?method=queryByClientCName&clientCNameWildcard=*
using either your browser, wget, curl or whatever:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <queryByClientCNameResponse xmlns="">
   <ns1:queryByClientCNameReturn xmlns:ns1="urn:soapbinding.v2.advinstaller.wien.gv.at">
    <ns1:itsOrganizationId>18</ns1:itsOrganizationId>
    <ns1:name>123457 / pc004711.adv.magwien.gv.at</ns1:name>
    <ns1:id>37</ns1:id>
    <ns1:serialNr>123457</ns1:serialNr>
   </ns1:queryByClientCNameReturn>
   <ns2:queryByClientCNameReturn xmlns:ns2="urn:soapbinding.v2.advinstaller.wien.gv.at">
    <ns2:itsOrganizationId>20</ns2:itsOrganizationId>
    <ns2:name>123458 / kav00001.kav.wien.gv.at</ns2:name>
    <ns2:id>39</ns2:id>
    <ns2:serialNr>123458</ns2:serialNr>
   </ns2:queryByClientCNameReturn>
  </queryByClientCNameResponse>
 </soapenv:Body>
</soapenv:Envelope>

Hmm... The queryByClientCNameResponse is in the "" namespace, why? Then, the queryByClientCNameReturn
is in the "urn:soapbinding..." namespace, again why?"

I promised to show that there's a difference when acually called via SOAP over HTTP POST,
so thats what SoapMonitor displays when I invoke an Axis Client on the service:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
  <queryByClientCNameResponse xmlns="urn:schema.v2.advinstaller.wien.gv.at">
    <queryByClientCNameReturn>
      <itsOrganizationId>18</itsOrganizationId>
      <name>123457 / pc004711.adv.magwien.gv.at</name>
      <id>37</id>
      <serialNr>123457</serialNr>
    </queryByClientCNameReturn>
    <queryByClientCNameReturn>
      <itsOrganizationId>20</itsOrganizationId>
      <name>123458 / kav00001.kav.wien.gv.at</name>
      <id>39</id>
      <serialNr>123458</serialNr>
    </queryByClientCNameReturn>
  </queryByClientCNameResponse>
</soapenv:Body>
</soapenv:Envelope>

Hmmm... Strange, isn't it? Why does Axis produce different responses dependent on the way
the servlet is invoked?!

But back to the "real" output. Namespace-wize that's a whole different story here, but still
it is not correct with respect to the generated WSDL. .net builds stubs from the WSDL successfully,
but fails to deserialize any instances of Terminal to place into the array, thus the array
contains but nulls.

Relative to the WSDL I'd expect the following output:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
  <queryByClientCNameResponse xmlns="urn:schema.v2.advinstaller.wien.gv.at">
    <queryByClientCNameReturn xmlns="urn:schema.v2.advinstaller.wien.gv.at" xmlns:aiv2entity="urn:entity.v2.advinstaller.wien.gv.at>
      <aiv2entity:itsOrganizationId>18</aiv2entity:itsOrganizationId>
      <aiv2entity:name>123457 / pc004711.adv.magwien.gv.at</aiv2entity:name>
      <aiv2entity:id>37</aiv2entity:id>
      <aiv2entity:serialNr>123457</aiv2entity:serialNr>
    </queryByClientCNameReturn>

	<!-- ... -->

</soapenv:Body>
</soapenv:Envelope>

If we doctor the output according to the example above, the array get initialized correctly
under .net. So what happened? It appears that Axis fails to set the correct namespace for
those elements in the XML (itsOrganizationId, name, id, serialNr) that are defined in the
imported "urn:entity..." schema. It simply adds the elements, but "slurps" them into the "urn:schema..."
namespace. First, I thought this was okay, but our XML gurus assured me that elements of a
complex type from an imported schema must appear in the namespace of that imported schema.


So, Java2WSDL and the Axis serializers have a different view on my classes and/or WSDD's.
Thats strange, since I tell Axis the namespace it must use for the Terminal Bean in the WSDD:

	<beanMapping qname="aiv2entity:Terminal" 
	             languageSpecificType="java:at.gv.wien.advinstaller.v2.entity.Terminal"/>

If someone knows any bug numbers that refer to the problem(s) I have, please let me know,
so I can track them. I searched for the problem in the database, but found nothing so far,
so I am short of opening a new bug adressing this problem.


Maybe I am going offtopic now, but with the amount of frustration that has built up over the
course of today, I can't help to speak out some thoughts on the status of Axis.

Now, from a far, I already hear those who claim that, oh well, one should not generate WSDL
but generate Java, and this would be the "real problem" I have here... I doubt however that
starting from WSDL would help here, since even then the Axis BeanSerializer/ArraySerializer
would do the wrong thing. I do see that starting with WSDL is good practice in principle,
but thats seldom practicable for large-scale not-so-decoupleable webserivices, IMHO. As soon
as deadlines come closer (or are first set), we tend to start coding away, to get some results
out, instead of scratching our heads over 500 WSDLs for a complicated suite of services.

But we all lack tools to cater such an approach, and I don't see much coming on the horizon
to really make it work this way. What use is a handcrafted WSDL when there's no default serializers
to comply with it? What use is SOAP anyway if one havs to write a custom serializer/deserializer
for each and every class (or WSDL construct) one wants to use?

In that case, I could also send plain XML over any protocol (like HTTP/CGI, or simple Servlets)
with almost the same effort. All in all, I can't help the impression that SOAP is still in
it's childhood and we're very early adopters of an unproven technology on a scale of a large
distributed application... Yea, shure, "Hello SOAP" works, but that's where the "works" ends,
and the problems start. Hey, I am not trying something overly exotic here, or am I? It's just
an array of a stupid POJO/Bean/getter-setter-thingie I want to get over the wire here! Thats
not exactly Sci-Fi, but SOAP makes it seem so... Many things work well enough if you have
the same toolkit on both ends, but in a heterogenous environment SOAP seems to be more a curse
than a cure, unfortunately. And while I hate to say that, in the last half year or so, nobody
was able to show me otherwise.

Just look at the literature available on the topic. Almost all literature is outdated (most
is covering Apache SOAP) an thus plain useless, and the few articles out on the web are far
too inprecise and also often inaccurate and/or obsolete. And if you find usable stuff, it's
on a "Hello World" kind of scale.

Now, to save me from flambait, I'm not criticizing the Axis developers -- not the least, I
am grateful for all their efforts, eventually leading to a superb piece of software like Apache.
I am critcizing descision makers who push us developers into using underdeveloped, underdocumented
and even underspecified platforms one can hardly stand on yet, with projects far too large
to serve as "proof of concept"-experiments...

So long,
Flexx

-----Original Message-----
From: "SERKOM@t-online.de *EXTERN*"@mozart.adv.magwien.gv.at [mailto:"SERKOM@t-online.de *EXTERN*"@mozart.adv.magwien.gv.at]

Sent: Thursday, November 11, 2004 11:14 AM
To: axis-user@ws.apache.org
Subject: Re: Array of Objects in Axis and .NET interop

Hello,

adressing the topic of the empty namespace attribute > (xmlns="")  that Eric mentioned
in his mail, we had the same .NET/Axis interoperability problem. In our case there was no
need for a codechange in Axis but a change in the wsdd-File.

if we had:

  <service name="ElanServices" provider="java:RPC" style="wrapped">
      <parameter name="wsdlTargetNamespace"
value="http://rehadat.de/elan/service"/>
      <parameter name="wsdlServiceElement" value="Service"/>
      <parameter name="wsdlServicePort" value="Elan"/>
      <parameter name="className"
value="de.rehadat.elan.service.ServicesElanImpl"/>
      <parameter name="wsdlPortType" value="Elan"/>
      <operation name="getSmallElan"
 qname="ns:GetSmallElan"
 returnQName="GetSmallElanResult"
 returnType="ns:SmallElan"
 xmlns:ns="http://rehadat.de/elan/service" > ...

the XML contains
...
<GetSmallElanResult xmlns="">
...
The empty namespace attribute problem will force .NET to return nulls in all elements of SmallElan.
if we change the returnQName to

returnQName="ns:GetSmallElanResult"

the XML now contains
...
<GetSmallElanResult>
...
the empty namespace attribute is away and .NET returns the correct values.

maybe this helps.
KHS

-----Urspr√ľngliche Nachricht-----
Von: Wessel Alexander <002-brf@adv.magwien.gv.at>
An: axis-user@ws.apache.org <axis-user@ws.apache.org>
Datum: Donnerstag, 11. November 2004 10:03
Betreff: RE: Array of Objects in Axis and .NET interop


Hi fellow Axisants,

we're also having "Arrays of problems" here, with getting Axis (1.2RC1) Services on Tomcat
and a couple of Axis and .net clients working together.

The Axis clients deserialize Arrays of Beans correctly, while .net clients give us some headaches:

At the moment we have identified two bugs, one we believe is rooted in .net (seemingly the
"item" problem, discussed elsewhere in this list). That one we forwarded to Microsoft via
our Premier Support Channel, but have not yet received anything to fix the problem.

The other "misunderstanding" seems to be caused by Axis, when .net will correctly generate
the underlying Bean type, yet would not fill the array with anything but nulls. It's the "correct
number of nulls", though -- so the array length is as expected, after all, thus indicating
that the *Array* serializer works for his part... Seemingly the deserialization of the beans
themselves fails, resulting in the array to be filled with nulls instead of bean instances.
We have pinpointed our problem to a bug in Axis where namespaces are not correctly set in
the SOAP messages (responses) sent by Axis in document/wrapped style. By doctoring the XML
by hand, we found a "correct" XML instance that would be serialized correctly by .net. Our
XML Gurus tell me that Axis is definitely producing bogus XML here, with respect to the Java2WSDL-generated
WSDL (which we believe is ok). After some "desparate disbelief" on my side, I had to concede
that indeed there is a problem in Axis.

Eric, did you post your patch to the ASF JIRA at http://nagoya.apache.org/jira/secure/Dashboard.jspa?
If so, please let us know the bug number. I guess some of us would like to track and/or vote
for the bug.

Since I don't know what problem the other thread was adressing (the one Tami mentioned in
her opening post of this thread), I don't know wether the fix presented by Eric works for
us. What exactly does this patch fix?

I'll post an in-depth description of our problems tomorrow, if anyone is interested.

So long,
Flexx

-----Original Message-----
From: Patrick Herber *EXTERN* [mailto:patrick@arpage.ch]
Sent: Friday, November 05, 2004 1:25 PM
To: axis-user@ws.apache.org
Subject: RE: Array of Objects in Axis and .NET interop

Hi,

I'm implementing a Web Service (using doc/literal) that returns an Array of objects.
This service should be used by different types of client (also including .NET clients).
Since it didn't work properly under .NET (the result Array was always empty) I applied the
patch described here by Eric (thanks!) and afterwards it worked just fine.
Does somebody see any problem applying this patch?
(If not why is it not yet included in the standard axis distribution?)

Thanks a lot for your advice.

Best regards,
Patrick

Patrick Herber


> -----Original Message-----
> From: Eric Chijioke [mailto:echijioke@erisk.com]
> Sent: Mittwoch, 29. September 2004 16:01
> To: axis-user@ws.apache.org
> Cc: Tami Wright
> Subject: RE: Array of Objects in Axis and .NET interop
>
> BTW, I am using Axis 1.2 beta. That is important. I should note that I 
> also did NOT generate my WSDL using Java2WSDL but rather built my WSDL 
> first and then java classes manually which has resulted in a much 
> leaner code base that would have been produced automatically.
>
> - I know that axis hardcodes the names of the elements of the array as 
> <item>. Axis doesn't seem to interrogate the WSDL to figure out the 
> 'proper' array element names (!?). It was too much for me to try and 
> modify Axis to do that, and using <item> is prefferable to me than the 
> former <XXXReturn> which it defaulted to. My current client is .NET, 
> and as I described below, one can easily configure .NET to expect the 
> array elements to be named <item> using a method attribute.
> As for Axis clients, I don't think Axis cares what the array elements 
> are named when deserializing.
>
> - A Wrapper element around the array elements is the proper schema 
> according to the WS-I profile (WS-I Profile 1.1 section 4.3.3 -
> soapenc:Array)
>
> - There's one more change I made to my Axis code which I realize I 
> left out. It fixed some namespace issues wherein under certain 
> circumstances, Axis would asign an empty namespace attribute
> (xmlns="") to the elements of the serialized array, if they were in 
> the default namespace.
>
>
>
> The change is made to the
> org.apache.axis.encoding.SerializationContextImpl.serializeActual()
> method.
>
> I added these lines:
>  ------------ begin snippet ------------------------------------
>
> if (elemQName.getNamespaceURI() == ""){
>
> elemQName = new QName(this.nsStack.getNamespaceURI(""),
> elemQName.getLocalPart());
>
> }
>
> ------------ end snippet --------------------------------------
>
>
> Before this line:
>  ------------ begin snippet (Line# 1231) ------------------------
>
> ser.serialize(elemQName, attributes, value, this);
>       return;
>
>  ------------ end snippet --------------------------------------
>
>
> Though these changes (above and below in this thread) seem to make 
> sense, I must make the disclaimer that I have not done any systematic 
> testing to make sure that these changes do not break a configuration 
> that I am not using. Per peoples requests, I am just posting my 
> resolution to the Axis' array serialization/deserialization 
> interoperability problems - as is.
>
> - Eric
>
>
>
>
>
>
> -----Original Message-----
> From: mmosttler@bco.com [mailto:mmosttler@bco.com]
> Sent: Monday, September 27, 2004 6:55 PM
> To: axis-user@ws.apache.org
> Subject: RE: Array of Objects in Axis and .NET interop
>
> I tried this same approach but I then received an unknown element 
> exception with the Axis Java client.  In addition I didn't care for 
> the defaulted hardcoding of the "item" name which was causing problems 
> in the .NET client (especially in a situation where the modification 
> of the generated .NET client is not possible).
>
> In addition I found that this change caused a service method that 
> returns an array to not return the correct xml results since it added 
> extra wrapper and used item.
>
> NOTE: I have discovered also that by removing the field type 
> description for the array property from the helper class causes the 
> serializer to output correctly, with the wrapping element.  (although 
> the Axis client is unable to correctly deserialize).
>
> marcus
>
>
>
>
>
>
>
> -----Original Message-----
> From: Eric Chijioke [mailto:echijioke@erisk.com]
> Sent: Monday, September 27, 2004 12:30 PM
> To: axis-user@ws.apache.org
> Cc: Tami Wright
> Subject: RE: Array of Objects in Axis and .NET interop
>
>
> Tami,
>
> Here's what I've done to make it work with .NET:
>
> I've located the following code in the
> org.apache.axis.encoding.ser.ArraySerializer.serialize()
> method And in both places, commented out the if(...) condition in 
> order to place an array wrapper around the elements for arrays 
> specified using the <element minOccurs="0" maxOccurs="unbounded"...> 
> WSDL syntax.
>
>
>  ------------ begin snippet (Line# 322) ------------------------
>
> // if (!maxOccursUsage) {
> //****** commented out *****//
>       serializeAttr = null;  // since we are putting them here
>       context.startElement(name, attributes);
>      elementName = Constants.QNAME_LITERAL_ITEM; // }
> //****** commented out *****//
>
>  ------------ end snippet --------------------------------------
>
>
>  With the corresponding serialization of a closing wrapper later on:
>
>
>  ------------ begin snippet (Line# 363)--------------------------
>
> // if (!maxOccursUsage)
> //****** commented out *****//
>             context.endElement();
>
>  ------------ end snippet ---------------------------------------
>
>
>
> In order to set the appropriate type of array elements, I also changed 
> the following code (a bit of a blind hack, but it works) in the same 
> method
> FROM:
>
>  ------------ begin snippet (Line# 336)--------------------------
>
> context.serialize(elementName, serializeAttr, aValue,
>                                       componentQName, // prefered type 
> QName
>                                       true,   // Send null values
>                                       null);  // Respect default type 
> config
>
>  ------------ end snippet ---------------------------------------
>
> TO:
>
>  ------------ begin snippet -------------------------------------
>
> context.serialize(elementName, serializeAttr, aValue,
>
> msgContext.getTypeMapping().getXMLType(aValue.getClass(),null,
> encoded),
> // prefered type QName
> true,   // Send null values
> null);  // Respect default type config
>
>  ------------ end snippet ---------------------------------------
>
>
> Remember, your .NET client needs to use the 
> System.Xml.Serialization.XmlArrayItemAttribute("item")]
> attribute on your web service methods (in your Reference.cs
> file) in order to consume arrays serialized form axis with elements 
> named <item>.
>
> I hope this helps,
> Eric
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Tami Wright [mailto:ttwright@myfamilyinc.com]
> Sent: Monday, September 27, 2004 12:25 PM
> To: axis-user@ws.apache.org
> Subject: Array of Objects in Axis and .NET interop
>
> Hi,
>
> I wondered what the status was with the message thread originally 
> posted by Eric Chijioke entitled "Axis and .NET interoperability - 
> Arrays". Any interim solution that can be posted until the bug is 
> resolved would be appreciated.
>
> Best Regards,
>
> tami
>

Mime
View raw message