Thanks Andreas, let me try that.

Eric

--- On Wed, 7/21/10, Andreas Veithen <[email protected]> wrote:

> From: Andreas Veithen <[email protected]>
> Subject: Re: Question about using byte array
> To: [email protected]
> Date: Wednesday, July 21, 2010, 1:28 PM
> On Wed, Jul 21, 2010 at 19:18, Eric
> Borisow <[email protected]>
> wrote:
> > Hi,
> >
> > I am trying to pass an LDAP cookie in a byte array
> from my web service using Axis2 1.4.1.  In my wsdl, I have
> this entry:
> >
> > <xs:element maxOccurs="unbounded" minOccurs="0"
> name="cookie" nillable="true" type="xs:byte"/>
> 
> That is not a good way to model binary data. A much better
> way is to
> use a single instance of xsd:base64Binary.
> 
> > Using ADB, a setCookie method is generated for me that
> takes a byte array as a parameter.  I pass in the byte
> array directly from the LDAP code.  It all looks good when
> the message is going out.
> >
> > In the output from the call, I see a bunch of
> <cookie> elements in the XML getting returned from the
> service.
> >
> > On the client-side, I am once again using ADB which
> provides a getCookie method to retrieve the byte array.  I
> output the value by using the toString method.
> >
> > The problem is that the byte array on the way out of
> the service is not matching the byte array that is coming
> into the client.  I've compared the individual values that
> are in the array between server and client and it does look
> different.  Most notably, it looks like some empty elements
> appear in the service output that are not there when
> debugged on the server side.  As a result, when I try to
> pass the array back for the next call, it fails.
> >
> > Hopefully, there is a simple answer to this.  Any
> help is appreciated.
> >
> > Thanks,
> > Eric
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to