Persisting EntityProxy that contains List<ValueProxy> member, receiving null for member if List unchanged...?

[TimOnGmail]

Hey folks...

I'm having a strange situation.  I have an EntityProxy that contains a member that is a List<ValueProxy> (all subclasses of the proxy types, of course).

Everything is set up fine, everything works, except for ONE case.  It looks like this:

class MyEntityProxy ... {

    public List<MyValueProxy> getMyList();

    public void setMyList(List<MyValueProxy> myList);

}

MyEntityProxy entityProxy;

...

request.retrieveMyProxy().fire(...

...

                    request = newRequest(); 

entityProxy = request.edit(retrievedEntityProxy);

);

...

 

request.saveMyEntityProxy(entityProxy).fire(...

);

If I do this (or if I set myList to a list containing the same values - possibly just values where .equals() is true between the old and new values), when I put a breakpoint on the server side, myList is null.

However, if I modify myList (add a different element(s) to it, remove one of the existing ones), THEN myList is correctly serialized on the server side.

Has anyone seen this before?  I know there are problems with Set<ValueProxy> serialization, but this is the first one I've seen with List<ValueProxy>

- Tim

[TimOnGmail]

Nevermind this question - it turned out it was because the Locator for the surrounding EntityProxy was one class, but the fetch/save methods were a different Locator.  The default find() method for this EntityProxy was not filling in some @Transient fields that the regular fetch() method was, so the comparison happening a persistence time was comparing mismatched EntityProxies.

I don't know why this would cause the deserialized class to contain an empty member, but I suppose that if the find() method on the Locator sees a member as empty, it is assuming that is newer than the changes made on the client side and overriding them - unsure on the mechanics of that.

Anyway, I have fixed my code, and it now works.

- Tim