Note: The JIRA issue for this work is FCREPO-648
Problem Statement
Fedora's original Server and Module classes were designed in 2002, and provided a common way for major functional components ("modules") of the repository to be plugged in, configured, initialized, and stopped. Problems with the existing framework include:
- It's homegrown. Better, more widely-understood frameworks have come along.
- Unit testing is unnecessarily complicated. The base Module class depends on a Server instance being available in order to function, and the Server base class is not easily mocked.
Requirements
Use standard, well-known frameworks/libraries to:
- Resolve inter-module dependencies via dependency injection
- Provide hooks to initialize/de-initialize modules when the webapp container starts and stops
- Allow re-configuration and plugging in of alternative modules without re-compiling
Non-requirements
This work will NOT attempt to:
- Provide a way to dynamically re-configure modules without restarting
- Provide the ability to run modules in their own classloader space
These capabilities may be added in the future, possibly with the help of OSGi.
Framework Choice
Popular frameworks that support the dependency injection pattern include Spring, PicoContainer, and Guice.
How do they compare? Several articles have been written comparing Spring and Guice, as well as all three. As many have pointed out, Spring and Guice are more than DI frameworks. For our purposes, we should consider the attributes of each that are most relevant to the problem at hand:
|
Spring
|
PicoContainer
|
Guice
|
Supports start/stop lifecycle hooks for components
|
Yes (interface or xml-configured)
|
Yes (interface or annotation)
|
No
|
Supports autowiring
|
Yes
|
Yes
|
Yes
|
Supports in-code wiring and configuration
|
Yes (JavaConfig)
|
Yes
|
Yes
|
Supports external wiring (outside of code)
|
Yes (xml)
|
No
|
Not directly (but it's possible)
|
Supports external config (outside of code)
|
Yes (xml and/or properties)
|
No
|
Yes (Names.bindProperties)
|
OSGi-Friendly
|
Yes (Spring-DM)
|
Unknown |
Yes (Guice-Peaberry)
|
JSR-330 Support
|
Yes, 3.0+
|
In Progress
|
In Progress
|
Jar Footprint (non-OSGi)
|
750kb
|
300kb
|
650kb
|
Implementation Strategy/Principles
- Prefer constructor injection to setter injection
- Minimize coupling of code with DI framework
- Minimize changes to existing Fedora functionality
Implementation Plan
Phase I - Prepare
Modify existing modules to accept injected dependencies and config values
- Decouple module interface impl from Module abstract class where needed
- Push param validation responsibility down to each impl (not in Module)
- Use constructor injection if possible. For those with circular dependencies that can't be refactored easily, provide setters.
- Where existing modules look at configuration of other modules, get the configuration value from a getter in the interface, not the configuration.
- Where existing modules look at global fcfg values, make those available via bean-style class, GlobalConfig.
- Where existing modules look at datastore fcfg values, inject the connectionpool or config values directly.
Phase II - Swap
- Decide on DI framework
- Convert fcfg to DI configuration and update installer to populate it instead
- Trigger initialization of module singletons via DI framework in context initialization
- Use injected module dependencies wherever possible, avoiding use of Module and Server at runtime
Phase III - Cleanup
- Get rid of Module, Server, and subclasses
- Get rid of everything else that parses/looks at fcfg
Identify and remove unused modules and classes with module dependencies.
on above page).