Call for Discussion (2 of 2): How like Spring (dependency injection) do we want to be?

15 views
Skip to first unread message

Hardy Pottinger

unread,
May 11, 2017, 11:04:37 AM5/11/17
to DSpace Developers
Hi, on the agenda [1] for the Developers Meeting yesterday (5/10/2017), we had a couple of discussion topics, however, we did not have enough attendees for a proper discussion, so I'm moving them to the developers mail list instead. This is the second message of two.

The question at hand is:

How like Spring do we want DSpace to be?

On May 3, there was a Slack discussion in the #dev channel [2] on whether the DSpace codebase should move more towards the "Spring way" of doing things (e.g. Dependency Injection via beans) or the traditional DSpace patterns (e.g. classloaders with little DI).

Please first review that discussion [2], and then comment here whether you'd like to formalize (i.e. require or highly recommend) the use of dependency injection in DSpace.

--Hardy

Mark H. Wood

unread,
Jun 22, 2017, 10:56:24 AM6/22/17
to DSpace Developers
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
signature.asc

Hardy Pottinger

unread,
Jun 23, 2017, 10:28:41 PM6/23/17
to DSpace Developers
Thanks, Mark, for picking up this discussion. Anybody else want to weigh in? I am about to fly to OR17, but I'll definitely check e-mail while I'm there.

--Hardy

--
You received this message because you are subscribed to the Google Groups "DSpace Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-devel+unsubscribe@googlegroups.com.
To post to this group, send email to dspace...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-devel.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages