[
https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572286#action_12572286
]
Dibyendu Majumdar commented on DERBY-3405:
------------------------------------------
No problem, will submit an ICLA. Noticed that it can be either sent by post
and? or? faxed. So please expect it in a few days.
> 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 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
