Affects Version/s: None
Fix Version/s: None
Component/s: Build tools
At present, Derby as a whole is offered as an OSGI bundle.
Internally, Derby does not use OSGI for managing modules. Modules and services (which are collections of modules) are managed using the Monitor component, which is a custom IoC container, designed specifically for Derby.
Some of the features of the Monitor component, mirror facilities offered by OSGI. The obvious ones are:
a) Loading modules based upon environment. The features offered by the Monitor subsystem were described by Dan like this:
The monitor ... selects the module implementation that is suitable for the given environment by:
- seeing what the current JDK level is and if a module implementation supports it
- seeing what classes a module implementation requires and if they exist
- if the module implements ModuleSupportable and if so asking the module if it can support the current environment.
As an example, modules.properties today contains three JDBC implementations, JSR169, JDBC 3 and JDBC 4, having multiple exist is not an issue, the monitor selects the correct one.
The ability to load bundles based on environment compatibility is one of OSGI features.
b) Resolving module interdependencies.
c) Managing life-cycle of services and modules.
A migration from the Monitor component to an OSGI based packaging is not going to be an easy transition. At this stage, therefore, this is more of an experiment.
The benefits of using OSGI are:
a) It supports dependencies based upon versions of bundles.
b) It will make it easier to add/remove components, specially at run-time. However, the use case for this needs defining.
c) It may open up Derby to other possibilities ...
The disadvantages are:
a) Introduces a dependency on OSGI - whereas Derby at present has its own IoC implementation.
b) Will mean a major change to how Derby is bundled and therefore potentially impact users.