Proposal Introduce DI with Guice

Abstract

This is a proposal to use Guice to implement Dependency Injection (DI) in Roller.

Requirements

These requirements are met by this proposal.

• Introduce DI
  • Use DI to setup the Roller instance and managers, i.e. manager classes should no longer be hard-coded into the Roller implementation class, instead they should be injected.
  • Enforce singletons, i.e. singletons should have a private constructor.
  • Use constructor injection to ensure that immutable objects remain immutable.

• Do not change Roller API
  • Do not change the was Roller back-end interfaces are accessed by front-end code
  • i.e. RollerFactory.getRoller() stays in place

• Do not change way Roller is configured
  • Do not introduce any additional configuration files for those installing Roller, i.e. don't change the fact that the only customization file users should ever have to touch is roller-custom.properties.
  • Do not introduce any additional configuration files for developers, i.e. developers should not have to deal with any new XML or property files.
  • Maintain the same level of back-end pluggability, i.e. it should still be possible to switch back-end implemenations by setting a single property in the Roller configuration file.

Issues

• How far should we go with DI in the 4.0 release?

Design

List and describe new manager methods, Struts actions, JSP pages, macros, etc.

Changes to RollerFactory

To select a back-end implementation, you set the property 'guice.backend.module' in the Roller configuration file the the class name of a Guice module that specifies the Roller interfaces. The RollerFactory will instantiate that Guice module and will use it to create and inject the Roller implementation specified by that module. Here's the code for RollerFactory.java.

And here's the code for the Guice module for the Hibernate back-end: RollerModule.java.

Changes to the Roller implementation and managers

Roller implementation and all manager implementations use constructor injection. The are all declared as singletons. For example, here's the code for HibernateRollerImpl.java.

The DatabaseProvider class has been moved into the Core component so that it can be shared by both Weblogger and Planet. It's an abstract class and implementations are expected to provide a constructor that calls it's init method. Here's the code DatabaseProvider.java.

The Roller version of the database provider uses RollerConfig to configure the database, here's the code:
RollerDatabaseProvider.

Changes to Roller Planet

Roller Planet will use the very same setup as Roller Weblogger. As you'd expect there will be a PlanetFactory and a PlanetModule. There will be a PlanetDatabaseProvider that uses PlanetConfig to get database proerties, etc.

Changes to Weblogger's Planet integration

The PlanetFactory uses the Guice back-end specified in the planet.properties file. In Roller we need a special PlanetModule, with a Planet implementation that can read database parameters from the Roller properties file instead of the Planet one.

This is accomplished by a special Planet persistence strategy that uses RollerConfig, HibernateRollerPlanetPersistenceStrategy.java . And we'll need a PlanetModule that specifies that strategy: RollerPlanetModule.java .

Status

Guice DI is implemented in both Weblogger and Planet and for both the Hibernate and JPA implementations and passing XXX% of tests.

Comments

Please comment on the Roller dev list.