We ran into this some time ago and, yes, it's hell to figure out what's 
going on.  As you say, the only solution is to avoid using public 
statics in your serialized classes.

The reason this happens is that the Flex 1.5 AMF gateway doesn't 
distinguish between static and nonstatic public fields.  When it 
serializes an object, statics are encoded into the stream anyway, just 
as if they belonged to the instance rather than to the class.  This is 
effectively a bug.  I've been told it is fixed in Flex 2.0.

Then, when the instance gets sent back, the gateway instantiates X() 
(which works), but then attempts to use reflection to set the static 
field to the value of the same property that comes back over the wire. 
This fails (since it's a final field) which indirectly causes the error 
that is reported.

In other words, the code on the server is doing something like this:

    x obj = new x();
    x.TEST_KEY = /* data from over the wire */;


... .  .    .       .            j

 From my original bug report to Macromedia around 6 months ago:

> We've uncovered what seems like a serious bug in AS/Java conversion: public 
> static variables (fields) of a server-side Java class are sent over the wire 
> as if they were normal non-static properties of the client-side AS objects.  
> Conversely, if an AS non-static property is received with the name of a Java 
> static field, the server tries to store the deserialized value on the Java 
> side.
> 
> I'd think only non-static fields of Java objects should be converted. It does 
> not make sense to serialize or deserialize static fields, which are the same 
> for every instance.  The documentation doesn't really mention static fields, 
> but it does say "only public variables" are converted, which would typically 
> not inlude statics.
> 
> One might guess this is innocuous, but it isn't!
> 
> 1) If an object is transferred from server to client and then back to the 
> server again, the server will attempt to copy values back into the static 
> Java fields, which can cause a serious error.  In particular, it causes an 
> exception when the static field is final (as is the case with constants).
> 
> 2) If a Java class is transferred that declares lots of constants or other 
> static fields, then even if (1) doesn't bite you, the result is a ton of 
> useless wire traffic and consumed memory on the AS side.


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/KIlPFB/vlQLAA/TtwFAA/nhFolB/TM
--------------------------------------------------------------------~-> 

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/flexcoders/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to