You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Status

Proposal not ready for review

Target Release

4.0

Original Authors

Dave Johnson

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

These issues were raised and responded to during mailing list discussions of this proposal:

  • Issue raised: "I think it is most appropriate that any instance of the Roller interface should be treated
    as immutable. "
  • Response: We use constructor injection so that Roller implementations do not have to expose setters and can remain immutable.

  • Issue raised: "To truly enforce the singleton pattern we should only provide private constructors and the single instance of the class should be created statically and returned via a public static method."
  • Response: Guice can call private constructors, so we full enforce the singleton model.

  • Issue raised: "From my perspective Spring is more mature, well-documented and tested, has a more open contribution model, and is in wider use amongst a broader community. Plus we have at least two committers that are using it in other settings."
  • Responses
    • Guice documentation is excellent and Guice is "simple and easy. It took me no time at all to figure out – no books or extra docs necessary."
    • "Guice now powers Google Adwords. You'd be hard pressed to find a more massively distributed, scalable, etc. Java app out there. So, I'm not particularly worried about Guice maturity and testing."
    • Spring does not accept external committers and has no plans to do so, that's hardly an open contribution model.

  • Issue raised: "I hope we won't be asking users to modify distributed code in order, for example, to add plugins or to swap a rendering model implementation."
  • Response: We won't require that. If you want to extend Roller's back-end you simply provide your own module class that injects the classes you want.

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.

Changes to the Roller implementation and managers

Roller implementation and all manager implementations use constructor injection. The are all declared as singletons.

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.

The Roller version of the database provider uses RollerConfig to configure the database.

Changes to Roller Planet

Roller Planet uses the very same setup as Roller Weblogger. As you'd expect there is a PlanetFactory and a PlanetModule. There's a PlanetDatabaseProvider that uses PlanetConfig to get database properties, 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 called HibernateRollerPlanetPersistenceStrategy.java. And we'll need a PlanetModule that specifies that strategy, which we call RollerPlanetModule.java.

Status

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

Comments

Please comment on the Roller dev list.

  • No labels