I’ve recently been working on the DSpace Services implementation. I’ve no doubt that in our current case, such Service implementations should be initialized by Spring. However, the current DSpace ServiceManager currently utilizes a great deal of Spring Auto-wiring and Dependency Injection to be initialized into existence. For instance within the CachingServiceImpl, we see much of this:
However, just a few lines lower we see.

This infers that once we have the Service manager, we can now acquire just about any service we need to work with in the initialization and runtime activities of the current module, theres much less of a need to inject.

I find this very inspiring. I think this will be the bridge point between DSpace Services and OSGi / SpringDM environments. The predominant concern however, is that the ServiceManager shouldn’t be interrogated until it is properly started, which happens after Spring has finished initializing. So we should restrict ourselves from using it to wire bean properties in place of Spring. In fact, we should avoid retaining references to the services outside the scope of its usage within the class.
My recommendation now for DSpace Services is to go through and start to limit the current usage of DI within Services to the Addon Module Project the Service Resides in. Not that we can’t use it within the context of the DSpace Addon Modules configuration for defining implementation centric DI Configuration. But just that we should define best practices concerning the boundaries that we should expose Service wiring across. Take for instance, the following as still a valid practice:

I think that maybe its better to reserve the power of Spring IoC / DI to the same scope as its applied in SpringDM, utilizing it to act to initialize resources locally within the bundle. I think the real power of this is that when services are truly delivered by something like OSGi Bundles, making sure that our Addon Modules get their services from the ServiceManager at Runtime and not from Spring at instantiation time will assure that much of the code depending on these services will not need to change when DSpace is run in an OSGi environment.