First of all, all due credit to Etienne for his amazing blog post, as well as the super simplified library that helped me get service-side Guice setup properly with GWT RequestFactory.
There were a few extra issues that I ran into, that took me some time to figure out. So I present an example of how to put the Locators together for convenient Guice'ing.
Technology assumptions:
- AppEngine Java
- GWT RequestFactory
- JDO entities
- Guice for server-side DI
This post assumes you're already familiar with GWT RequestFactory setup as well as with Guice. It also assumes you'll follow this along-side Etienne's post. Also, I've tested this with GWT 2.5. Additionally, my primary motivation for setting up Guice, was to get a Request-scoped PersistenceManager for JDO, or rather implement the OpenSessionInView pattern.
- Proxy locators and service locators.
The basic GWT RequestFactory guide provided by Google mentions two ways of setting up Proxy and Request interfaces- a simple approach using static methods in your Entity
- use of Locators supporting instance methods in your Dao.
For using Guice and OSIV pattern, you have to follow the follow this 2nd option. And here's why:
Guice will be injecting the request-scoped PersistenceManger for us, like this:
public class MyObj {
private Provider pmp;
@Inject
public MyObj(Provider pmp) {
this.pmp = pmp;
}
}
Now, if you're following the "simple approach", of course, using static methods is not good from a testability point-of-view. But even otherwise, to use a "PersistenceManager" in the entity, you would have to @Inject it. This means that your Entity will no longer have a "default constructor", and you'll have to provide it a PersistenceManager instance wherever you have to instantiate it. It also means you can no longer have a Builder for your entity.Hence, you should follow the second approach, and set up locators and DAO services as mentioned in Etienne's post.
- Setting up Guice-servlet
To make the best out of Guice, you might want to bring down web.xml to its bare minimum. Here is what I would recommend bringing down the web.xml file to:- Guice filter config
This is evident. Without this, your Guice won't get triggered. - welcome-file-list (files for static serving)
This is what gets served if the URL path doesn't match any pattern. - security contraints (E.g. for AppStats)
Now.. where does everything else go? All "servlet", "filter" and "listener" mappings go into a Guice "ServletModule". In case your web.xml specifies specifies <param-value>'s, these can be put into a HashMap and passed to their respective filters(See Initialization parameters).
- Guice filter config
Setting up Request-scoped PersistenceManager
For setting up your PersistenceManager with Guice, I recommend Yaniv Kessler's blog post. As he himself puts it - it's good for prototyping and small projects. As the project grows, however, a better framework like guice-persist is recommended. When I last checked Guice-persist didn't offer direct support for JDO. Lets hope this comes soon.
Finally, if you're not tied down to using JDO, David Chandler's blog posts addresses how to configure GWT RequestFactory with Objectify, where you won't have to worry about OpenSessionInView, and perhaps can avoid Guice for DI on the server-side altogether.
For information on implementing client-side GIN, you may also want to see this post by Stefan Rock.
No comments:
Post a Comment