Unfortunately we did not remove statics from the Java Bean serialization rules of RemoteObject in Flex 1.5. It's a known issue and will be fixed going forward. As a work around for now would it be possible to move the static final to another context? Such as a class called StaticConstants?
-----Original Message----- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Ewok Sent: Monday, June 13, 2005 11:49 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Web browser crashing on remote method call Pete- Thanks for your help...I've finally identified the problem (but still not the solution). Although I did have a reference of my siblingPojo back to my MainPojo, commenting out that code did not solve the problem. However, my SiblingObject has an attribute that is part of a class with static variables. So to give you an example, my SiblingPojo has an attribute like this: private Status status = null; When I construct my data objects in the back-end, I set this variable using it's own static data: siblingPojo.setStatus(Status.CONFIRMED); Here's the Java code of the class that the serialization is hanging up on. This is a pretty standard j2ee design pattern. You'll see that I only have a private constructor. This is what ensures that the variable data will be constant throughout the app. If I were to add a public constructor, the class would not compile (since my variable 'type' could technically never get instantiated)...I'm guessing the serialzation is hanging b/c there is no public empty constructor? have you ever come across a situation like this before? Thanks again for your help. public class Status{ private final String type; private Status(String type) { this.type = type; } public String toString() { return type.toString(); } public static final Status UNASSIGNED = new Status("UNA"); public static final Status ASSIGNED = new Status("ASG"); public static final Status ACKNOWLEDGED = new Status("ACK"); } --- In flexcoders@yahoogroups.com, "Peter Farland" <[EMAIL PROTECTED]> wrote: > It sounds like you might be in an infinite loop somewhere on the > client... a common way to get into such a loop is when processing object > graphs with circular references. > > From your MXML code listing below (i.e. it shows direct binding of the > RO result as a data provider) I don't see that you're doing any > recursive processing of the result so I'd propose that you've discovered > a bug with DataGrid when bound to object graphs that have circular > references. > > How, you might ask, would you have a circular reference in an object > graph from a RemoteObject result? Without seeing any of the code for the > object graph I can only guess that somewhere in your sibling instances > you have a pointer to a parent main object (or perhaps some circular > dependency between sibs, whatever). > > When serializing objects over AMF the client and server will attempt to > restore references between complex objects, for example, Just say we > have two objects, A and B where B has a reference back to its parent A: > > A -> B -> A > > RemoteObject will serialize the "A" property of B as a reference to the > instance A, rather than reserialize A again. This allows the client and > server to support circularly referenced object graphs and avoids > infinite recursion on serialization/deserialization. > > To prove that this is indeed happening you can turn on Debug level > logging for the RemoteObject gateway in the > /WEB-INF/flex/gateway.config.xml file, restart the flex server, and then > watch the server console for AMF traffic, you should be able to see the > "by-reference" serializaiton entries in the log. > > Note that RemoteObject is doing the right thing here - it might just be > that DataGrid can't handle the circularity of the object graph. > > Let me know what you find out. > > Pete Yahoo! Groups Links 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/
