[jira] Commented: (DERBY-3405) Examine the possibility of implementing Derby modules as OSGI bundles

["Daniel John Debrunner (JIRA)" <ji...@apache.org>]

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

Daniel John Debrunner commented on DERBY-3405:
----------------------------------------------

I agree it's good to consider other IoC implementations as it has these benefits:
  - widens the pool of people who understand the IoC
  - brings (hopefully) a better defined life-cycle model, given any other IoC was designed up front as an IoC rather than Derby's Monitor's organic growth
  - allows the Derby community to focus on database work

Some thoughts:

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

 - As you say this is no easy task, I would strongly encourage incremental development, trying to get a patch reviewed that changes all 50-70 modules will be near impossible.  Some approach that demonstrated/enabled use of an osgi framework (e.g. felix) and one or two modules while continuing to have a functioning Derby would be good, followed by more modules being brought under OSGi control. Apart from being easier to review this also has the benefit of allowing others to get involved once the initial patch is in, e.g. by converting different areas to run under OSGi. I'm not sure what's the actual best way to start here: bottom up, e.g. logging, or top down (e.g. jdbc/network server) , that will probably only become clear with experimentation.

 - I would also encourage open development, feel free to post a patch that gives an idea of what is going on, or is a hacked up version so others can see where you might be heading. Not all patches need to be ready for commit.
 

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