Page History

...

• 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.

• Don't Do not change Roller API
  • Don't Do not change the was Roller back-end interfaces (i.e. Roller and the managers) or the way in which they are accessed in 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 configconfiguration file.

Issues

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

...

DI in Roller back-end

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

RollerFactory

HibernateRollerImpl

RollerDatabaseProvider

HibernatePersistenceStrategy

DatabaseProvider

Planet integration

.java.

Roller implementation and all manager implementations use constructor injection. 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:
RollerDatabaseProviderPlanet also implemented with Guice DI.

Roller Planet

Roller planet 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 prpoerties, etcproerties, etc.

Roller 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 passing XXX% of tests.

...