This content has been marked as final. Show 3 replies
Conversion from Java class type to the AS class type happens on the client side and is done by the Flash player. I never faced problem with the conversion before. Please check if the mapping is propert, try cleaning the project. Also try registering the class alias in the code using the registerClassAlias function. Please find more details on this function at the URL below.
It will be great if you can share the PentePlayer, StrategyPlayer Java and ActionScript source files, so that we can see if we something is missing. You can also mail those classes.
Hope this helps.
Many thanks to you for your reply and thoughts towards resolving this issue.
My friend who I suggested I post to the forums resolved my problem this morning; apparently the Java class, "StrategyPlayer" was not being compiled into the .swf file. He writes:
Conversion problem solved. StrategyPlayer was not getting compiled into the swf. Took me a while to work this out but has been good for learning a bit more about how blazeds works. You were right, all java objects are serialized into an AMF binary stream without checking for the presence of their equivalent actionscript objects. There is no table of relations between actionscript objects and java objects. This is quite normal when you think about it as the server side java code has no awareness of the clientside swf and even if it did it would have to be able to read the compiled swf classes to get the information about their remote mappings. You probably already found this but the serialization of java objects to the AMF binary stream happens in flex.messaging.io.amf.Amf3Output.java, more specifically in the method writePropertyProxy (line 525). So all java objects are serialized and sent to the client. I imagine that when they arrive in the client flashplayer deserializes them as actionscript objects. It's flashplayer therefore that has the table of remote mappings, and for each object it deserializes it must look for a remote mapping and if it doesn't find one instantiate it as a generic flex object. In the case of StrategyPlayer since it was not getting compiled into the swf flashplayer had no way of mapping or instantiating it, hence our problem. I don't know if there are ways to get flashplayer to log its deserialization so that we can detect these types of problems. I'll look into it. Why, you may ask, was StrategyPlayer not getting compiled into the swf? This is the bit that i don't like very much. The flex compiler starts at the main application class (in our case src/main/flex/main.mxml) and compiles its dependencies recursively. OK, all fine, in RegistrationWindow.mxml you had imported StrategyPlayer so it should therefore get compiled into the swf? But this is the odd bit, importing the file is not enough, for the compiler to consider the class a dependency it has to be "used" in the class. This seems like strange behavior to me but i suppose that its a measure taken to optimize the size of the compiled swf's and remove unnecessary imports? So if you don't really need a class in your code but you do need the remote mapping how can you force the compiler to consider that you are "using" the class. Well the cleanest way i have found is simply to write the class name somewhere in some method. I have done this is in the updatePlayers method of PenteGameController but you can move it elsewhere if you prefer.
The behavior my friend describes looks like it exposes a bug in Flash player, with regards to how Java and AS conversion is handled in the case of inheritance. Flash/Flex should recognize our serialized object "StrategyPlayer" as a member of the "GamePlayer" family. One would expect all subclasses that are not explicitly referenced in the application to be instantiated as the next member of that family of types that the client is aware of, not just instantiated as raw "ASObjects". It seems that Flex should either include all subclasses of Java types that map to ActionScript classes, or some inheritance information that applies to the type should be included in the serialization stream so as to handle objects on the inheritance tree that are not referenced in concrete, local classes.
We are thinking of posting a bug on the issue, as it's a bit thorny. Love to hear what other Flex developers think!
I'm not sure that its easy to fix. Let me think...
1) Blaze serializes java objects into AMF without knowing who is going to consume them
2) Flashplayer deserializes objects in AMF into actionscript objects according to the remote aliases defined in the swf.
So for what you are asking for to work the AMF specification would have to contain information about type hierarchies and flash player would have to use this information to search for the first parent type of an object when serializing it.
The AMF specification is public and can be found here http://download.macromedia.com/pub/labs/amf/amf3_spec_121207.pdf
As far as i can see there is no information on type hierarchies included in this spec. The spec would have to be changed and the flashplayer code (which i think is closed source) would have to be modified.
I imagine that the idea behind AMF is that it should be a compact format that only carries the minimum information that the client needs so as to optimize bandwidth etc.
I'm not sure whether this functionality would conflict with that philosophy but I suppose we could still file a feature request.
Does anyone know where would be the right place to do this?