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] Commented: (DERBY-3405) Examine the possibility of implementing Derby modules as OSGI bundles
Date Mon, 25 Feb 2008 00:42:55 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571995#action_12571995

Dibyendu Majumdar commented on DERBY-3405:

> I would not make the assumption that OSGi would replace the monitor, it could be that
there are two ways of packaging Derby, the current way and an OSGi way. If people have the
itch to work on OSGi and others the itch to work on the monitor, then that's fine, problems
only come if the different approaches lead to conflict, then some vote might be needed. As
an further extension one could imagine that others might be interested in making Derby's modules
work in another "third-party" IoC.

One possibility is to retain the Monitor interface for starting/stopping services and modules
(life-cycle management) but delegate the environment specific class loading to OSGi. So we
could have a different Monitor implementation that presents the same API but relies upon OSGi
to resolve modules. 

> 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
>            Assignee: 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
> 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

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

View raw message