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