I have been trying out declarative services
by porting the org.eclipse.core.jobs bundle to use it. The big potential
advantage of using DS is that I can remove or at least isolate all "containerisms"
from my bundle. Ideally the Java code in my bundle is entirely ignorant
of the OSGi core and the declarative services runtime (SCR). This makes
the code reusable, and easy to use either standalone or inside some other
application container (spring, etc).
This works very well for both service
registration and lookup. In my refactored code, the only external
dependencies are on the two optional services used by jobs: DebugOptions
and PackageAdmin. These can be injected at runtime if desired, either by
DS, some other application container, or manually.
The one sticking issue is application
lifecycle. The only way (as far as I can see) that my component can
participate in the startup and shutdown sequence is to implement DS-specific
methods activate(ComponentContext), and deactivate(ComponentContext). Ideally
I would like to define the activate and deactivate method names in my component
definition XML, and not have any exposure to those DS interfaces (which
I don't need in this case). I can participate in startup quite easily
by adding code to my component object's constructor, but I see no solution
for shutdown. Does anyone know of a way I can make my bundle participate
in the shutdown sequence without adding a dependency on either OSGi or
SCR? (for example, to clean up threads I have created, withdraw listeners,
etc). One could of course define another bundle that can tell the jobs
bundle to shutdown at the right time, but it seems like overkill.
For anyone interested in following along
with my experiments with DS in org.eclipse.core.jobs, see: