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 [email protected], "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
<*> 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/
