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: "[EMAIL PROTECTED] *EXTERN*"@mozart.adv.magwien.gv.at [mailto:"[EMAIL
PROTECTED] *EXTERN*"@mozart.adv.magwien.gv.at]
Sent: Thursday, November 11, 2004 11:14 AM
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
An: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]
Sent: Friday, November 05, 2004 1:25 PM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]
> Sent: Mittwoch, 29. September 2004 16:01
> To: [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 27, 2004 6:55 PM
> To: [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]
> Sent: Monday, September 27, 2004 12:30 PM
> To: [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]
> Sent: Monday, September 27, 2004 12:25 PM
> To: [EMAIL PROTECTED]
> 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
>
