GWT 2.1.1 and DAOs

[Henrik Schmidt]

Hi there,

I'm playing with the new 2.1.1 release. I'm trying to use DAOs instead
of DTOs and testing it through RequestFactoryMagic. I use Guice server
side to inject the DAOs and I've implemented a ServiceLocator to hook
into Guice and get the given instance. This seems to work well.

Here's the problem. I have a domain class called Section which is a
simple JDO persistent class. This class has the required getId and
getVersion method. However, GWT blows up because there is no static
findSection(String id) method. I get the following errors:

SEVERE: There is no findSection method in type
cwp.handin3.server.model.Section that returns
cwp.handin3.server.model.Section
...
SEVERE: The type cwp.handin3.shared.SectionProxy did not pass
RequestFactory validation

I could of course create one but that defeats the purpose of the DAO.
Do I need to extend the Locator interface and hook that into Guice as
well or is there a better way?

/Henrik

[Henrik Schmidt]

I had a look through the code.
com.google.gwt.requestfactory.server.RequestFactoryInterfaceValidator
has a (rather unfortunately named) method called
checkIdAndVersion(ErrorContext logger, Type domainType) in line 1001.
However, this method also checks for a find method. Is this a bug?

In other words, is the find method used internally or can we ignore
it?

/Henrik

[Thomas Broyer]

The findXxx method is required when "de-serializing" instances. If you can't or don't one that static method, then you have to use a Locator.

[Sebastian]

Further investigation has revealed that SimpleRequestProcessor call's
ServiceLayer#isLive() for every non-null domain object to check if
it's still there. Otherwise the write operation is set to "DELETE".
IMO that's terrible: I don't want to do two entity manager/db lookups
for every "find" (even if it's aggressively cached). Using DAOs, I
don't even call remove() on my entities but on the DAO (and I call
removeById() -- I don't have a domain object in these situations!)

So providing a ServiceLayerDecorator with an overridden isLive()
method (returning always true) solves this part. But I still need the
findXxx method because of the check Henrik mentions (even if it's
never called).

I really appreciate the possibility to use DAOs and service locators
in 2.1.1 -- but unfortunately it's still not usable (for me). I don't
want data access methods in my domain models and I don't want
unnecessary db operations! And I don't want to provide a totally
redundant Locator for *every* domain model either...

Is there any way to avoid the check for the findXxx methods?

Sebastian

[Thomas Broyer]

If you really want it, yes: override all the resolveXxx on a ServiceLayerDecorator to totally by-pass the stock ResolverServiceLayer (which calls the RequestFactoryInterfaceValidator).

See also: http://code.google.com/p/google-web-toolkit/issues/detail?id=5761

(method validated with the RequestFactoryMagic and InProcessRequestTransport in a unit-test; and deferred-binding generator does not look like it's making use of the validator)