[gwt-contrib] RPC extension points

[noon]

Hello,

This thread follows this one (http://groups.google.com/group/Google-
Web-Toolkit-Contributors/msg/582cfe33f17deab3), so please read it
before this one.

To make Google App Engine and GWT work together (in adapter4appengine
project), I had to modify the RPC serialization code.
My first goal was to add *clean extension points*, to allow any third
library developer to tune RPC serialization according to his needs. Of
course, I used it to develop a DataNucleus adapter, and plan to port
Hibernate one as well.

The idea is to allow 2 kinds of extension points :
 - ISerializationFilter, that indicates if a specific field of a
class should be serialized or not. It is called for serialization
signature computation and for each object serialization
 * Typical use : used to remove new fields from enhancement
 - ISerializationTransformer, that can change a object instance
from one type to another one
 * Typical use : used to turn persistent collection back to
regular one

A first step has been implemented in adapter4appengine library. It
only needs change for 4 existing classes (RPC, SerializabilityUtil,
ServerSerializationStreamReader and ServerSerializationStreamWriter).

A next step would be to read filters and transformers from the gwt.xml
file (currently, they are set by code in EngireRemoteServlet class).

I would *really* love to see this code integrated in official GWT
release, since it would be a pain for me to do the same fixes every
time a new GWT release is out (as I still have to do it since GWT 1.4
for Hibernate4GWT/Gilead because issue 1291 is opened without result
since 2 years :-( ).

My 2 cents
Bruno
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: GWT-RPC broken in GAE/J

[noon]

Hi Robert,

For information, Gilead provides the @ServerOnly annotation to prevent
sending sensible fields over the wire.

Regards
Bruno

On 15 avr, 05:39, Robert Hanson iamroberthan...@gmail.com wrote:
 I hope I am not being naive (or reiterating an existing post), but I
 am not concerned with identity, nor concerned with expecting my ORM
 solution to deal with entities created on the client.

 I think all I need is a way to use an entity as a DTO without needing
 a second set of model objects.

 What about something as simple as keeping the existing semantics in
 tact, with the ability to flag properties that are send-able to the
 client (as opposed to using transient to flag the reverse behavior).

 public class Data implements Serializable {
   @GwtDto
   private Long id;
   @GwtDto
   private String partA;
   private String partB;

 }

 In this case the GWT compiler would create a serializer for the client
 that only handled the id and partA properties, and ignore partB.  The
 partB property would simply be null on the client side.

 On the server reflection would be used to only serialize the marked
 properties, ignoring the rest.  Besides ignoring partB it would also
 ignore any fields added by enhancers.

 Besides fixing GWT-RPC with GAE, it also allows me to trim data that I
 don't really need o

 On Tue, Apr 14, 2009 at 2:18 PM, John Tamplin j...@google.com wrote:
  On Tue, Apr 14, 2009 at 1:28 PM, Ray Cromwell cromwell...@gmail.com wrote:

  On Tue, Apr 14, 2009 at 9:03 AM, John Tamplin j...@google.com wrote:
   The only way I see it working would be to add a flag requiring
   preserving
   object identity across RPC, and the protocol would include an object ID
   with
   each object if that flag is set.

  Actually, JDO has a concept called application identity where object
  identity is handled by the application. This typically boils down to
  the PrimaryKey being used as object identity.

  Is there an equivalent for JPA?

   what happens for a persistent object created on the client that the
   server
   has never seen before?

  Calling persist() on it would insert it rather than merge it.

  Well, what I was getting at was more what does the server-side RPC code
  populate the hidden fields with if it gets a new object of that type from
  the client?

  If the hidden fields can be null and the @PrimaryKey field will be used to
  determine if it is a new object or a replacement of an existing one, then it
  seems pretty easy -- the server-side RPC code simply strips out the effect
  of the bytecode rewriting for serialization.  I don't know enough about what
  rewriting happens to know how to detect/reverse it, but it seems like it
  should be doable.

  --
  John A. Tamplin
  Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---