AS3 array to Java array Flash Remoting bug

I just stumbled across a very odd bug while using Flash remoting to pass AS3 data objects to Java. For each AS3 data object I have a corresponding Java data object, the two are carbon copies of each other and are mapped together on the AS3 side using the [RemoteClass(alias="com.dgrigg.vo.MyDataObject")] tag. If the AS3 object contains a public Array or ArrayCollection that has not been instantiated Flash remoting dies when trying to pass the object down to Java. Not entirely sure why but lesson learned, always instantiate Arrays and ArrayCollections in a data object before sending it down the wire.

If anyone knows why this happens I'd love to hear.

2 Comments:

  1. Aran Rhee

    Derrick.

    My understanding would be that until you instanciate the Array / Array collection, then it doesn't actually exist as far as remoting is concerned.

    I think whether remoting dies or not is down to the individual rules on thye conversion with whatever remoting gateway you are using (BalzeDS, original Macromedia Java remoting .jar, OpenAMF etc).

    When I did some tests recently with BalzeDS, any properties which weren't defined on either side ( say the Java VO had a name property and Flash didn't) were just ignored, and the VO shipped just didn't include the missing property.

    Aran

  2. Derrick

    Hey Aran,
    I am using BlazeDS. Non declared properties on either side that are basic data types (ie int, string, boolean) get passed back and forth both ways and properly ignored if not declared on the receiving end, however the arrays and array collections seem to go against that rule.

    I think you're right that it likely comes down the gateway being used, I haven't seen similar behaviour using WebOrb (not that I purposely tested for that though).

    Doing some Googling I came across this:

    An ActionScript array can index entries in two ways. A strict array is one in which all indexes are numbers. An associative array is one in which at least one index is based on a string. It is important to know which type of array you are sending to the server, because it changes the data type of parameters that are used to invoke a method on a Java object. A dense array is one in which all numeric indexes are consecutive, with no gap, starting from 0 (zero). A sparse array is one in which there are gaps between the numeric indexes; the array is treated like an object and the numeric indexes become properties that are deserialized into a java.util.Map object to avoid sending many null entries.

    Maybe part of the issue is that the serializer can not determine which type of array (strict or dense) a null array is and it gets hung.

    Derrick


Leave a comment

Name: (required)

Email: (required)

URL:

Captcha test: (required)
Comments: (required)