I got a chance to look at the code and I do think that this will have
some nice results. For unit testing in particular.

Plugging in my little HibernateEscaping stream will be easier with
this structure. It looks like I'd subclass RemoteServiceServlet and
override processCall() with one that call my own RPC mechanism right?

The only further request I'd have is to make the RPC.java a bit easier
to extend since it's not so much that I want to replace the current
RPC imp as to extend it with my Hibernate filter. All I'd really need
is a public encodeResult(). Or perhaps a specific "filter" extension
point? I think that this a a really common result for anyone using ORM
software. The Hibernate folks are (with reason) absolutely aghast at
saying un-initialized == null, but sending lazy objects into the
presentation tier is a tricky thing to solve if you're allergic to
DTOs. In my personal opinion it's one of the real unsolved problems
with the current state of the art.

http://forum.hibernate.org/viewtopic.php?t=947299&highlight=bomb+lazy

If not I'll just end up duping this class and maintaining myself. I'd
understand if you think that this would be a bit dangerous to allow
people to fiddle with the RPC as they choose, but I think it might be
worth it.

ahh. I see it's a final class. sigh. sounds like I'm not going to win
this one :)  but do think about it for me would you? With clients as
powerful as GWT I just love being able to use my real domain objects
in the client, but there's a real sticking point here.

Thanks again,

-Jeff

On Feb 1, 2:48 pm, "Rob Jellinghaus" <r...@unrealities.com> wrote: