db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3405) Examine the possibility of implementing Derby modules as OSGI bundles
Date Tue, 12 Feb 2008 17:39:08 GMT

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