For Gilead, you don't need to inherit from their classes. Have your model objects implement ILightEntity. It's basically a wrapper around a simple hashmap to store the proxy information. Your service can use the GileadRPCHelper directly. Take a look at the implementation of PersistentRemoteService. Our projects are structured this way and it works great.
One gotcha with Gilead. It seems to play well with either a servlet container or JBOSS. We are using it with GlassFish and it took some tweaking to get everything running. On Aug 4, 10:33 am, javier <[email protected]> wrote: > Hello folks: > > I've posted this question to the Hibernate user's forum, but in the > absence of replies, I am posting it here as well, in the hopes that > some of you may shed some light. Please accept my apologies if this > is the second time you see this post. > > I'm about to engage in an enterprise project whose front-end is to be > built with GWT. I've had some Hibernate experience from past projects > and really like the ORM mechanism used by Hibernate for marshalling/ > unmarshalling from a database. Now, as some of you know, domain > entities need to be transferred over the wire for GWT's consumption: > entities that have been instrumented with persistence information will > fail at the client side, as GWT cannot handle these objects. > > So I've done some research and I've come across two common solutions > to this problem: > > 1) Using a framework called Gilead; > 2) Replicating the domain model hierarchy with a second class > hierarchy used exclusively for data transfer (aka Data Transfer > Objects representing the persistent domain objects). > > None of these solutions are good in my current situation: > > 1) Gilead intrudes into the design of an application by forcing the > entities to inherit from “LightEntity” and forcing > RemoteServiceServlet descendants to extend “PersistentRemoteService”. > Our design cannot allow this, as both of these type of objects already > inherit from a different hierarchy. > 2) Our domain model is composed of 30 classes, some of which have > quite a few getters/setters. Replicating this domain model sounds like > trip to "maintenance nightmare" street, not to mention the amount of > extra code that we'll need to map things back-and-forth. > > So even though I know (from experience) that Hibernate will make me a > lot more productive accessing the database than the alternative (ie > hand-coding with JDBC), all this productivity goes down the drain if I > now have to deal with recreating the objects in order to properly talk > to the client layer. > > So now my question is, can I get away with the following: > > 1) make every single persistent entity to always load everything > eagerly by default (ie lazy=”false”) and make lazy loading the > exception to the rule (ie when fetching lists of things); > 2) use a stateless Session-per-request approach, so that every time I > need something from the db a brand new persistence context is > initialized. > > I understand that I'll be giving up caching and hence, taking a > performance hit, what I'd like to know is, how bad is this hit? is > this an acceptable compromise in my case? Is this approach still > better than going back to manual JDBC days? > > Please advise if this is a horrible approach and if there is something > I should know before I put a rope around my neck. > > Thanks in advance for any ideas, comments or suggestions. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
