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