db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dibyendu Majumdar (JIRA)" <j...@apache.org>
Subject [jira] Created: (DERBY-3405) Examine the possibility of implementing Derby modules as OSGI bundles
Date Mon, 11 Feb 2008 23:49:07 GMT
Examine the possibility of implementing Derby modules as OSGI bundles

                 Key: DERBY-3405
                 URL: https://issues.apache.org/jira/browse/DERBY-3405
             Project: Derby
          Issue Type: New Feature
            Reporter: Dibyendu Majumdar

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

  - 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.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message