Hi all - I've been working on a patch to improve support for RPC of persistence-enhanced objects that would replace the one I recently submitted as trunk revision 5672. I'd like to give those of you who are interested in the interaction between RPC and persistence a chance to help me validate the design before moving forward.
The idea is to be able to deal with different persistence mechanisms in a way that does not depend too much on the details of their implementations. We assume that the persistence mechanism provides a way for instances to be detached from the object store, serialized, deserialized, and reattached in a well-defined way. Our strategy leverages this capability as follows: 1) User code on the server detaches the object and places it into a state such that serialization is valid 2) GWT detects whether any instance fields are present on the object that were not known to client code 3) GWT performs hybrid serialization: a) GWT uses its regular RPC mechanism for the client-visible fields b) GWT uses Java serialization for any additional server-only instance fields c) GWT encodes the results of step (b) as a String d) GWT prepends the encoded String to the regular RPC data and transmits to the client 4) Client code treats the object in the normal way and does not interact with the data from step (3b) 5) When the object is sent back to the server, the normal RPC mechanism is altered as follows a) the encoded server data is decoded and deserialized into the new object instance b) the client data is populated using setXXX() method invocations rather than by directly setting field values All this is done only for classes that can be send bidirectionally, and which are determined to be (potentially) enhanced. The potential for enhancement is signaled in one of three ways: o The user adds the fully-qualified class name to a 'gwt.enhancedClasses' configuration property o The class is determined to have the JDO @PersistenceCapable annotation with detachable=true o The class is determined to have the JPA @Entity annotation If a class is determined to be potentially enhanced, the list of fields known to the client is added to the '.gwt.rpc' file that contains the RPC whitelist. This list is used by step 2 of the RPC process which compares the set of client- and server-visible fields. Step (5b) is necessary to accommodate mechanisms like that of JDO, where the setter methods are enhanced to provide object state tracking (dirty bits). If we were to set the fields directly, the object detached state would not be updated properly. My hope is that this mechanism would be general enough to support a variety of persistence mechanisms without the need to add a lot of special-case code. I'm looking forward to any comments that you have as to whether this will work with your favorite persistence API, or any other thoughts that you have. Thanks, Dan --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
