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 Thu, 14 Feb 2008 17:39:10 GMT

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

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

> I now think that maybe it is better at least in the short term to create a common reference
data bundle that contains all the reference data (including StoredFormatIds).

Why is a bundle needed. These classes are only needed at compile time, not a runtime. Does
OSGi require a bundle even for compiling?

> org.apache.derby.iapi.services.info.JVMInfo contains a reference to org.apache.derby.iapi.reference.JDBC30Translation.SQL_TYPES_BOOLEAN.

That should be replaced with java.sql.Types.BOOLEAN. Both JDBC20Translation and JDBC30Translation
can be removed since Derby's lowest support is JDBC 3/JSR 169 which define all the constants
required.

> GeneratedByteCode and GeneratedClass contain reference to Context - but it would be better
if they had no knowledge of context. Perhaps context should be just an object.

Note sure what this really means, Context is a concept that goes across Derby's code, thus
it should be valid for code to use Context where required. Replacing a specific type with
Object just to avoid importing another module's api class seems to be a bad direction. If
the module implementation depends on another module then it should be free to use its api
classes.


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


Mime
View raw message