Hello, I'm wondering if you were able to find a solution to this particular problem. I am having the same exact situation occur to me. I have been able to reproduce it every time using .NET or ColdFusion web services (not that that matters).
I am currently digging into the SOAPEncoder and SOAPDecoder classes as well looking for a work-around. I've been able to force the the "xsi:type" attribute for the derived classes by using hacks explicitly looking for my extended classes, which is by no means a solution, but even this progress has been stumped by the SOAPDecoder decoding to the base class regardless of the specified type attribute. I have sent an email off to Peter Farland & Svetlin Kalaydjiev of the Adobe Flex team, who I believe work with the RPC library primarily. I still have not received a response yet. I'm looking for some sort of confirmation before I file a bug. This has halted things a bit for me, at least until I can resolve the issue. I'll post anything that I hear from them. FYI, I am also using Flex 3.2 along with the auto-generated web service proxies. And in response to valdhor's question: I can't speak for the OP, but remoting wasn't an option for this project since Flex is not the only consumer of these services, so our only option was use .NET SOAP services. Believe me, I pushed for RemoteObjects to avoid all the issues that come with the encoding and decoding SOAP object to actionscript. For the most part, everything works great with a bit of tweaking, but when I usually hit a wall with this particular library, it's a show stopper. Thanks, Ramsey --- In [email protected], "valdhor" <valdhorli...@...> wrote: > > Is there any reason you are using WebServices rather than RemoteObject? > > If there is, can you let me know the location of the WSDL and I can > see if I can get it to work. > > > --- In [email protected], "eeyalee" <eeyalee@> wrote: > > > > Hi, > > > > I'm using flex 3.2 and trying to create a WebService in order to > > communicate between a backend (which in java) and my flex application. > > > > The WebService defines a sequence and one complex type in it. > > The actual returned class by the WebService isn't the defined complex > > type but an extension of that complex type. > > > > for example: > > let say the web service has two methods getItem() and setItem(Item). > > > > The defined type is a copmlex type 'Item' and the actual used class > > is a Table which is an extension of Item. > > > > > > expected result should be that the decoded class will be from the > > derived class and not from the defined type. (which isn't abstract). > > > > actual result is that the decode class is from the defined complex > > type Item and not the Table type. > > > > > > (note, that the XMLEncoder did manage to encode a Table type and add > > the appropriate xsi:type value.) > > > > I've used the generation wizard in the flex builder and changed that > > the Table class will implement the IXMLScehmaInstance interface and > > that the returned xsiType will be the correct one. > > > > The returned message does contains the correct xsi:type value and the > > recordXSIType attribute of the XMLDecoder is set to true. > > > > > > debuging the executions i've found that the problem seems to be not in > > the SOAPDecoder but in the XMLDecoder. > > when decoding the sequence the decoder decode each element as a > > groupElement and then creates the context as defined in the schema and > > not as received in the decoded message. > > > > in the past week i've been digging through bugs of SOAPDecoder and > > XMLDecoder and also trying to find any other references to this problem. > > > > > > can you help me figure out if this logic should work in flex and how ? > > > > thanx, > > eyal. > > >
