On Sunday, January 27, 2013 8:05:00 PM UTC+1, bloo wrote: > > I believe this may be similar to: > http://code.google.com/p/google-web-toolkit/issues/detail?id=7827 but I > can't be certain as I'm using slightly different components. > > I have a WineProxy EntityProxy with a list of VarietalComponentProxy > EntityProxies. The id of the VCP is a VarietalComponentIdProxy (which > proxies a JPA @EmbeddedId instance), but that id's ValueProxy has no > setters or getters (I set and get to the VCP itself client-side, and on the > server-side set up the VCId accordingly). > > When creating a new VCP foro the currently edited WineProxy, I call a > service to query for a list VarietalProxy objects, select one and hold it, > then before persisting the WineProxy, I 'set' the held VarietalProxy into a > newly created VCP which I then add to the WineProxy's VCP list editor > before calling a InstanceRequest.persist().using(WineProxy). > > Several problems arise when I go to edit a WineProxy. > > 1. First, if I have multiple VCs, the RF find() returns the same VC > for the # of items it's supposed to be returning. This is odd. > 2. Second, if I save as-is, the VCP list is fine. But if I add or > remove a VCP to/from the list, any existing VCPs get sent to the server as > nulls, and if I filter them out to avoid NPEs, they're simply removed from > that Wine relation. > > I don't have a problem calling query services to give me EntityProxy > objects to add to another object's ListEditor for any non-composite id > based lists. This one is the only one that's giving me a bunch of issues, > so in light of the issue I linked to above, I think I may be doing > something fundamentally wrong. > > I'm using Guice with Guice-Persist, GP's PersistFilter on every http > request to enable Open-Session-In-View for the app, and JPA + Hibernate for > data access. > > I don't know if this is relevant, but since I'm querying for > VarietalProxy's via a "service" Request and I'm editing and persisting my > proxies via InstanceRequest "services" - each of which are backed by > different servlets: > > All of my InstanceRequest "services" are defined in one RequestFactory, > backed by a subclass of RequestFactoryServlet (at "/instanceRequest") that > uses a ServiceLayerDecorator that I've overridden invoke() with > Guice-Persist's @Transactional so that all of my InstanceRequests are > within a txn. > > All of my Request "services" are defined in another RequestFactory backed > by a separate RequestFactoryServlet (at "/gwtRequest") that uses my own > ServiceLocator to find the Guice bound services, which may or may not have > their service methods demarcated with @Transactional. >
That might be the problem. I can't see any reason you'd want to use 2 distinct RequestFactory interfaces and 2 distinct RequestFactoryServlet instances (particularly as RF uses shared static state, and doesn't preclude calling your InstanceRequest on /gwtRequest, or your other Requests on /instanceRequest. Can't you setup your ServiceLayerDecorator to only use an explicit transaction on non-static methods invoked on, say, a JPA entity object? (one that you know have not been provided by Guice and therefore isn't subject to AOP interception). Or alternatively, though impacting all your client code as well, how about ditching InstanceRequest and moving everything to Request, with separate "service" objects on the server-side? (that can be provided by Guice and thus intercepted by Guice-Persist) -- 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]. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
