Integrate better with Guice Servlet

[GoogleCodeExporter]

If Guice Servlet ships with support for external configuration / multiple 
modules, we should consider integrating with it. We would be able to get 
rid of the only static state we have left (in PersistenceFilter). Maybe add 
a ManagedPersistenceFilter or something. Could be done after 2.0, the 
current design is flexible enough to allow this.

Original issue reported on code.google.com by robbie.v...@gmail.com on 30 Dec 2008 at 12:47

[GoogleCodeExporter]

How will this work?

Im adding multiple modules support for Guice 2.0.

Original comment by dha...@gmail.com on 4 Jan 2009 at 5:19

[GoogleCodeExporter]

Well that depends on how it'll work :)

The idea is to make it easy for people to use Warp Persist with their Guice 
Servlet
configuration, without having to edit the web.xml. I think this should then 
also be
the preferred way of doing things.

Original comment by robbie.v...@gmail.com on 14 Jan 2009 at 8:54

[GoogleCodeExporter]

It shouldn't be any different than:

filter("/*").through(PersistenceFilter.class);

I guess we could roll this up into the PersistenceService API if unit of work 
is REQUEST.

Original comment by dha...@gmail.com on 14 Jan 2009 at 9:30

[GoogleCodeExporter]

This is interesting. Guice Servlet supports multiple modules, so Warp Persist's 
multiple module support will not 
break the feature.

Some things we should think about:
- We probably can't assume Guice Servlet is in the classpath. We should 
probably create our own ServletModule 
and Class.forName it when users want to include the Guice Servlet module.
- The resulting persistence module(s) will have to be installed before all 
other web modules
- It is unclear to me how we could integrate this in the PersistenceService API

Original comment by robbie.v...@gmail.com on 14 Feb 2009 at 2:37

• Changed state: New
• Added labels: Milestone-Release2.0

[GoogleCodeExporter]

I'm not following this closely, but it is a Bad Thing if your modules need to 
be ordered. 

The standard recipes for coping with this sort of problem:
 - define equals and hashCode in your module so it can be installed multiple times
 - Use requestInjection to analyze what's bound at injector-creation time.

Original comment by limpbizkit on 14 Feb 2009 at 7:54

[GoogleCodeExporter]

You're absolutely right, but the ordering problem exists because of Guice 
Servlet 
(and the servlet spec)

Let's say you have a module that does:
filter("/*").through(FilterThatUsesPersistence.class);

and then we do:
filter("/*").through(PersistenceFilter.class);

The ServletModule#configureServlets() javadoc says:
"The order in which these modules are installed determines the dispatch order 
of 
filters and the precedence order of servlets."

So if users then install their custom module before the Warp Persist module, 
the 
PersistenceFilter will not execute before the filter that needs a Hibernate 
Session 
or whatever; so things will blow up.

Original comment by robbie.v...@gmail.com on 14 Feb 2009 at 8:13

[GoogleCodeExporter]

You should probably discuss this explicitly in the PersistenceFilter Javadoc 
and user
manual. The explanation you gave is pretty good.

Original comment by gili.tza...@gmail.com on 14 Feb 2009 at 8:30

[GoogleCodeExporter]

Maybe we can add a UnitOfWork.GUICE_SERVLET_REQUEST.

Original comment by robbie.v...@gmail.com on 7 Mar 2009 at 12:25

[GoogleCodeExporter]

Yea, it's a problem, our choices are:

- force users to know about ordering in module installs()
- make users install PersistenceFilter manually.
- add some kind of preference mechanism (like salience in drools or 
load-on-startup in servlets)

I'm not so happy with the last option =(

Original comment by dha...@gmail.com on 7 Mar 2009 at 3:05

[GoogleCodeExporter]

If users install it manually they still have the ordering problem. So indeed, 
this is
a Guice Servlet problem. Because of the ordering constraint, it could actually 
be
clearer to have a concept in between Guice Servlet and the actual Guice module. 
Example:

// Acts like a linked list of ConfigurationSection
GuiceServletPipeline pipeline = new GuiceServletPipeline();

// Add sections to it
pipeline.add(new ConfigurationSection() {
  public void configureServlets(GuiceServletPipeline pipeline) {
     // filter, serve are on "pipeline"
  }
});

// WP's module could implement ConfigurationSection
PersistenceModule persistence = 
PersistenceService.usingHibernate().buildModule();
pipeline.add(persistence);

// Installs the web scopes, and optionally any sections that have been added
// Warp Persists module can be added in any order
Guice.createInjector(pipeline.build(), persistence);

The downside is that this severely complicates the common scenario, in which 
you only
have one ServletModule. But I guess it would be easy to add some static 
factories for
that:
Module servletModule = GuiceServletPipline.moduleOf(new ConfigurationSection() {
  public void configureServlets(GuiceServletPipeline pipeline) {
     // filter, serve are on "pipeline"
  }
});

or make a Module that implements ConfigurationSection:

Module m = new ConfigurationSectionModule() {
  public void configureServlets(GuiceServletPipeline pipeline) {
     // filter, serve are on "pipeline"
  }
};

Obviously I'm just making up some names here, I'm sure we can find better ones. 
But
you get the idea.

Original comment by robbie.v...@gmail.com on 7 Mar 2009 at 4:32

[GoogleCodeExporter]

Let's tackle this after 2.0 (possibly using UnitOfWork.GUICE_SERVLET_REQUEST). 
For now people can install it manually.

Original comment by robbie.v...@gmail.com on 18 Apr 2009 at 2:17

• Removed labels: Milestone-Release2.0