THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
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.
- Don't change Roller API
- Don't change the Roller back-end interfaces (i.e. Roller and the managers) or the way in which they are accessed in 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 config.
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.
DI in Roller back-end
To select a backend implementation
Planet integration
Planet also implemented with Guice DI.
Roller Planet
Roller planet will use the very same setup as Roller. As you'd expect there will be a PlanetFactory and a PlanetModule. There will be a PlanetDatabaseProvider that uses PlanetConfig to get database prpoerties, etc.
Status
Guice DI is implemented in both Weblogger and Planet and passing XXX% of tests.
Comments
Please comment on the Roller dev list.