A bit of background, and some tangents:
Spring is already present. We already make quite some use of DI, but
much of the DSpace code is not prepared to participate. If you've
ever needed to write 'new DSpace().getThis().getThat().getTOther()' or
remember which factory class creates an ItemService then you have seen
what a bother it is to make use of Beans in non-Bean code. How much
neater to just write "@Inject FooService foo" and be handed everything
you need. Some of the newer code is doing this now.
OTOH DI happens at instantiation time. We have a lot of code, and a
lot of habit, built around static initialization of class fields. We
need to learn to think differently when designing a new class, and
there will be some non-routine work required to retrofit existing
classes. Much of the latter can be done bit-by-bit, I think.
We'll need to reconfigure Spring a little. IIRC it is currently told
not to inspect parts of the org.dspace namespace. We'll need to open
that up and then check to make sure that we haven't caused problems
with existing autowire-by-type usages. I don't anticipate big
problems.
Tangent: the ServiceManager. dspace-services provides an elaborate
mechanism for building up a tree of 'ServiceManager's based on
different infrastructures. It's very nicely done. DSpace has never
used it. In practice we have a DSpaceServiceManager which delegates
to one SpringServiceManager that does it all. There was provision for
using Guice, either alternately or together with Spring, but I've
never found anyone who's tried that. Navigating the machinery that
makes it possible to do this always makes my head spin. What
documentation there is, is mainly notes left by someone who was just
trying to figure it all out from staring at code.
The ServiceManager has two jobs. One is to be a service locator,
which is kind of like DI inside-out: you ask it for the configured
implementation of the interface that you want, such as the
ConfigurationService. The other job is to provide listener chains,
similar to the authentication mechanism stack: a signal is sent to an
interface, and various configured implementations each get a chance to
act on it. Both jobs are done by consulting Spring. Both jobs
duplicate what the PluginManager does. (Actually the authentication
method stack is implemented using PluginManager.)
Some things I'd like to see:
o Abolish the service locators. Use DI wherever we need single
configurable implementations. ServiceManager and PluginManager
become much simpler.
o Fold the two listener chain mechanisms together. We can be rid of
the ugly Properties-based configuration of the PluginManager and
have a single simple mechanism configured in Spring, which can
directly express structured configuration data.
o Free the ServiceManager from the DSpaceKernel, which doesn't seem
to be used for much other than to create the ServiceManager tree
and give the rest of DSpace a reference to it. Maybe we could
abolish another mystery interface.
--
Mark H. Wood
Lead Technology Analyst
University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu