Loading ...
Sorry, an error occurred while loading the content.
 

.NET and zero length arrays

Expand Messages
  • David Crowley
    I ve noticed a problem with .NET. Suppose I am returning a parameters value which is an array of struct foo defined as something like this: struct bar;
    Message 1 of 4 , Aug 30, 2002
      I've noticed a problem with .NET. Suppose I am returning a "parameters"
      value which is an array of struct "foo" defined as something like this:

      struct bar;
      struct foo
      {
      bar[] mybars;
      };


      If my RPC response packets looks like this (standard stuff removed for
      brevity, SOAP 1.1 RPC encoding, etc.):

      <SOAP:Envelope>
      <SOAP:Body>
      <m:GetInfoResponse>
      <parameters xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="m:foo[2]">
      <item xsi:type="m:foo">
      <mybars xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="m:bar[0]"/>
      </item>
      <item xsi:type="m:foo">
      <mybars xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="m:bar[1]">
      <item xsi:type="bar">...</item>
      </mybars>
      </item>
      </parameters>
      </m:GetInfoResponse>
      </SOAP:Body>
      </SOAP:Envelope>

      I am expecting "parameters" to be an array with two (2) foos, the first
      having zero (0) bars and the second having one (1) bar. .NET seems to
      choke on the first zero length array of bars and apparently stops parsing
      the rest of the "parameters" array. The "parameters" value comes back with
      a *single* foo and no error message to indicate a problem. All other tool
      kits I have tried seem to de-serialize the message properly into an array
      with 2 elements. Now, if I add the attribute xsi:nil="true" to the
      problematic array then .NET seems to parse everything fine. The current
      behavior of just ignoring/skipping the rest of the array is sub-optimal.

      Comments?

      Thanks,
      David
    • Alex DeJarnatt
      Hi David. Yep, this is a bug in our reader implementation. The problem (as you guessed) is the empty array element. If you return it ll
      Message 2 of 4 , Aug 30, 2002
        Hi David. Yep, this is a bug in our reader implementation. The problem
        (as you guessed) is the empty array element. If you return <mybars
        ...></mybars> it'll parse correctly. We're aware of this bug and have
        fixed it in the next release. Sorry for the inconvenience.
        thanks
        alex

        -----Original Message-----
        From: David Crowley [mailto:dcrowley@...]
        Sent: Friday, August 30, 2002 8:45 AM
        To: soapbuilders@yahoogroups.com
        Subject: [soapbuilders] .NET and zero length arrays


        I've noticed a problem with .NET. Suppose I am returning a "parameters"

        value which is an array of struct "foo" defined as something like this:

        struct bar;
        struct foo
        {
        bar[] mybars;
        };


        If my RPC response packets looks like this (standard stuff removed for
        brevity, SOAP 1.1 RPC encoding, etc.):

        <SOAP:Envelope>
        <SOAP:Body>
        <m:GetInfoResponse>
        <parameters xsi:type="SOAP-ENC:Array"
        SOAP-ENC:arrayType="m:foo[2]">
        <item xsi:type="m:foo">
        <mybars xsi:type="SOAP-ENC:Array"
        SOAP-ENC:arrayType="m:bar[0]"/>
        </item>
        <item xsi:type="m:foo">
        <mybars xsi:type="SOAP-ENC:Array"
        SOAP-ENC:arrayType="m:bar[1]">
        <item xsi:type="bar">...</item>
        </mybars>
        </item>
        </parameters>
        </m:GetInfoResponse>
        </SOAP:Body>
        </SOAP:Envelope>

        I am expecting "parameters" to be an array with two (2) foos, the first
        having zero (0) bars and the second having one (1) bar. .NET seems to
        choke on the first zero length array of bars and apparently stops
        parsing
        the rest of the "parameters" array. The "parameters" value comes back
        with
        a *single* foo and no error message to indicate a problem. All other
        tool
        kits I have tried seem to de-serialize the message properly into an
        array
        with 2 elements. Now, if I add the attribute xsi:nil="true" to the
        problematic array then .NET seems to parse everything fine. The current

        behavior of just ignoring/skipping the rest of the array is sub-optimal.

        Comments?

        Thanks,
        David



        -----------------------------------------------------------------
        This group is a forum for builders of SOAP implementations to discuss
        implementation and interoperability issues. Please stay on-topic.

        To unsubscribe from this group, send an email to:
        soapbuilders-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to
        http://docs.yahoo.com/info/terms/
      • ajbutr
        Hello, Is it known in what version this will be fixed? I tried with .Net Framework SP2 (Version:1.0.3705.288) and the current public 1.1 beta, but this bug was
        Message 3 of 4 , Nov 5, 2002
          Hello,
          Is it known in what version this will be fixed? I tried with .Net
          Framework SP2 (Version:1.0.3705.288) and the current public 1.1 beta,
          but this bug was still in both those versions.
          (I assume this fix would go in a .Net Framework redist update?)

          Thanks,
          ArentJan

          --- In soapbuilders@y..., "Alex DeJarnatt" <alexdej@m...> wrote:
          > Hi David. Yep, this is a bug in our reader implementation. The
          problem
          > (as you guessed) is the empty array element. If you return <mybars
          > ...></mybars> it'll parse correctly. We're aware of this bug and
          have
          > fixed it in the next release. Sorry for the inconvenience.
          > thanks
          > alex
          >
          > -----Original Message-----
          > From: David Crowley [mailto:dcrowley@s...]
          > Sent: Friday, August 30, 2002 8:45 AM
          > To: soapbuilders@y...
          > Subject: [soapbuilders] .NET and zero length arrays
          >
          >
          > I've noticed a problem with .NET. Suppose I am returning
          a "parameters"
          >
          > value which is an array of struct "foo" defined as something like
          this:
          >
          > struct bar;
          > struct foo
          > {
          > bar[] mybars;
          > };
          >
          >
          > If my RPC response packets looks like this (standard stuff removed
          for
          > brevity, SOAP 1.1 RPC encoding, etc.):
          >
          > <SOAP:Envelope>
          > <SOAP:Body>
          > <m:GetInfoResponse>
          > <parameters xsi:type="SOAP-ENC:Array"
          > SOAP-ENC:arrayType="m:foo[2]">
          > <item xsi:type="m:foo">
          > <mybars xsi:type="SOAP-ENC:Array"
          > SOAP-ENC:arrayType="m:bar[0]"/>
          > </item>
          > <item xsi:type="m:foo">
          > <mybars xsi:type="SOAP-ENC:Array"
          > SOAP-ENC:arrayType="m:bar[1]">
          > <item xsi:type="bar">...</item>
          > </mybars>
          > </item>
          > </parameters>
          > </m:GetInfoResponse>
          > </SOAP:Body>
          > </SOAP:Envelope>
          >
          > I am expecting "parameters" to be an array with two (2) foos, the
          first
          > having zero (0) bars and the second having one (1) bar. .NET seems
          to
          > choke on the first zero length array of bars and apparently stops
          > parsing
          > the rest of the "parameters" array. The "parameters" value comes
          back
          > with
          > a *single* foo and no error message to indicate a problem. All
          other
          > tool
          > kits I have tried seem to de-serialize the message properly into an
          > array
          > with 2 elements. Now, if I add the attribute xsi:nil="true" to the
          > problematic array then .NET seems to parse everything fine. The
          current
          >
          > behavior of just ignoring/skipping the rest of the array is sub-
          optimal.
          >
          > Comments?
          >
          > Thanks,
          > David
          >
          >
          >
          > -----------------------------------------------------------------
          > This group is a forum for builders of SOAP implementations to
          discuss
          > implementation and interoperability issues. Please stay on-topic.
          >
          > To unsubscribe from this group, send an email to:
          > soapbuilders-unsubscribe@y...
          >
          >
          >
          > Your use of Yahoo! Groups is subject to
          > http://docs.yahoo.com/info/terms/
        • Alex DeJarnatt
          It should be fixed in 1.1 (including the beta). Please double-check your results and let me know if you re still seeing the problem. Thanks alex ... From:
          Message 4 of 4 , Nov 5, 2002
            It should be fixed in 1.1 (including the beta). Please double-check your
            results and let me know if you're still seeing the problem.
            Thanks
            alex

            -----Original Message-----
            From: ajbutr [mailto:ajbu@...]
            Sent: Tuesday, November 05, 2002 6:42 AM
            To: soapbuilders@yahoogroups.com
            Subject: [soapbuilders] Re: .NET and zero length arrays

            Hello,
            Is it known in what version this will be fixed? I tried with .Net
            Framework SP2 (Version:1.0.3705.288) and the current public 1.1 beta,
            but this bug was still in both those versions.
            (I assume this fix would go in a .Net Framework redist update?)

            Thanks,
            ArentJan

            --- In soapbuilders@y..., "Alex DeJarnatt" <alexdej@m...> wrote:
            > Hi David. Yep, this is a bug in our reader implementation. The
            problem
            > (as you guessed) is the empty array element. If you return <mybars
            > ...></mybars> it'll parse correctly. We're aware of this bug and
            have
            > fixed it in the next release. Sorry for the inconvenience.
            > thanks
            > alex
            >
            > -----Original Message-----
            > From: David Crowley [mailto:dcrowley@s...]
            > Sent: Friday, August 30, 2002 8:45 AM
            > To: soapbuilders@y...
            > Subject: [soapbuilders] .NET and zero length arrays
            >
            >
            > I've noticed a problem with .NET. Suppose I am returning
            a "parameters"
            >
            > value which is an array of struct "foo" defined as something like
            this:
            >
            > struct bar;
            > struct foo
            > {
            > bar[] mybars;
            > };
            >
            >
            > If my RPC response packets looks like this (standard stuff removed
            for
            > brevity, SOAP 1.1 RPC encoding, etc.):
            >
            > <SOAP:Envelope>
            > <SOAP:Body>
            > <m:GetInfoResponse>
            > <parameters xsi:type="SOAP-ENC:Array"
            > SOAP-ENC:arrayType="m:foo[2]">
            > <item xsi:type="m:foo">
            > <mybars xsi:type="SOAP-ENC:Array"
            > SOAP-ENC:arrayType="m:bar[0]"/>
            > </item>
            > <item xsi:type="m:foo">
            > <mybars xsi:type="SOAP-ENC:Array"
            > SOAP-ENC:arrayType="m:bar[1]">
            > <item xsi:type="bar">...</item>
            > </mybars>
            > </item>
            > </parameters>
            > </m:GetInfoResponse>
            > </SOAP:Body>
            > </SOAP:Envelope>
            >
            > I am expecting "parameters" to be an array with two (2) foos, the
            first
            > having zero (0) bars and the second having one (1) bar. .NET seems
            to
            > choke on the first zero length array of bars and apparently stops
            > parsing
            > the rest of the "parameters" array. The "parameters" value comes
            back
            > with
            > a *single* foo and no error message to indicate a problem. All
            other
            > tool
            > kits I have tried seem to de-serialize the message properly into an
            > array
            > with 2 elements. Now, if I add the attribute xsi:nil="true" to the
            > problematic array then .NET seems to parse everything fine. The
            current
            >
            > behavior of just ignoring/skipping the rest of the array is sub-
            optimal.
            >
            > Comments?
            >
            > Thanks,
            > David
            >
            >
            >
            > -----------------------------------------------------------------
            > This group is a forum for builders of SOAP implementations to
            discuss
            > implementation and interoperability issues. Please stay on-topic.
            >
            > To unsubscribe from this group, send an email to:
            > soapbuilders-unsubscribe@y...
            >
            >
            >
            > Your use of Yahoo! Groups is subject to
            > http://docs.yahoo.com/info/terms/


            -----------------------------------------------------------------
            This group is a forum for builders of SOAP implementations to discuss
            implementation and interoperability issues. Please stay on-topic.

            To unsubscribe from this group, send an email to:
            soapbuilders-unsubscribe@yahoogroups.com



            Your use of Yahoo! Groups is subject to
            http://docs.yahoo.com/info/terms/
          Your message has been successfully submitted and would be delivered to recipients shortly.