API with central control

[GoogleCodeExporter]

Now that we are about to add multiple modules support, there is one minor
issue that comes up: we no longer have central control over what happens.
This can be annoying, for example I made this utility module, because of
the lack of central control:
http://code.google.com/p/warp-persist/source/browse/trunk/warp-persist/src/com/w
ideplay/warp/persist/PersistenceServiceExtrasModule.java

Integration with Guice Servlet could also prove to be easier, for example
if we automatically want to install the PersistenceFilter into it. You
obviously only want to install it once, so with the lack of central control
you can't really automate this (requiring user action).

Very rough idea:
new PersistenceModule() {
  @Override
  protected void configure() {
    usingHibernate().annotatedWith(Product.class);
    usingJpa().annotatedWith(Customer.class);
    using(whatever().annotatedWith(Blah.class));
  }

  private PersistenceStrategy whatever() {
    ...
  }
}

Note that we could still keep the classic builder API for single module
scenario's.

Absolutely not sure about the idea or the code example, but I thought I'd
mention it. We should think this through before we release 2.0.

Original issue reported on code.google.com by robbie.v...@gmail.com on 14 Jan 2009 at 9:14

[GoogleCodeExporter]

Guice Servlet integration is another use case (see issue #25). Let's look at 
this
after 2.0. To summarize, these are the problems the lack of a central API is 
causing:
- No easy way to get a List<PersistenceService> across modules. Workarounds are 
the
module mentioned above, or Guice 2.0 multibindings.
- No easy way to automatically bind PersistenceFilter only once across modules. 
The
current workaround is to bind it manually.

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

• Removed labels: Milestone-Release2.0