db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dibyendu Majumdar (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3405) Examine the possibility of implementing Derby modules as OSGI bundles
Date Wed, 13 Feb 2008 01:31:08 GMT

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

Dibyendu Majumdar commented on DERBY-3405:


Thank you for the comments.

I think overall my approach will be to:

a) Keep changes that are generic (e.g. tightening module boundaries) separate and independent
of any OSGI related work. Hopefully, this will make it easier for these changes to be absorbed
quickly. I will soon submit a couple of patches that should illustrate the type of changes
I would like.
b) The OSGI related changes are more difficult. I haven't worked out yet how best maintain
compatibility of the Monitor code with OSGI. I am not sure that we can mix the current approach
with OSGI as you suggest, because OSGI has its own class-loading rules. I have been thinking
about creating a Monitor implementation that uses OSGI underneath. This would allow me to
minimize changes to existing code.

My current approach with regards to the OSGI changes is to maintain a separate code base,
where I am importing one module at a time. This is a bottom up approach. I am hoping that
apart from the OSGI specific code, everything else will remain in synch with the Derby mainstream.

So far I have created following OSGI bundles:

org.apache.derby.core.lib   - This contains:
org.apache.derby.core.io.api - This contains

org.apache.derby.core.io.impl - This contains

org.apache.derby.core.bytecode.api - This contains

I was working on the bytecode implementation module, when I stopped and decided to restart.

As you can see, after the first bundle, I started to split the API from the implementation.
I will have to revisit the first bundle, as I would like to split the API from the implementation
for this as well.

You will notice that there is a new package, org.apache.derby.shared.common.reference. This
contains a new interface containing only those constants from SQLState that are needed by
the bundle. I wasn't sure how to approach the reference data issue, hence my recent posts.
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). I do not really
like this, but it is easier for me at present to do this way than to try and split the constants.

I have encountered some issues, which I will list here for your information - please note
that these are my short-hand notes, and may not make sense to you.

org/apache/derby/iapi/error/StandardException.java contains references to org.apache.derby.iapi.reference.SQLState,
org.apache.derby.impl.jdbc.EmbedSQLException, org.apache.derby.impl.jdbc.Util.
SQLState is basically a long list of error codes, but the list goes across layers.
StandardException has knowledge about EmbedSQLException.

org/apache/derby/iapi/services/i18n/MessageService.java contains reference to org.apache.derby.iapi.services.context.ShutdownException
and org.apache.derby.iapi.services.info.JVMInfo.
ShutdownException is better placed in org.apache.derby.iapi.error.

SingleStream.java contains reference to org.apache.derby.iapi.services.monitor.ModuleControl,
org.apache.derby.iapi.services.monitor.Monitor, org.apache.derby.iapi.reference.Property,

org.apache.derby.iapi.services.property mixes general property utilities with database table
based properties.
iapi.reference package contains values that go across layers.

org.apache.derby.impl.io.BaseStorageFactory contains reference to org.apache.derby.iapi.store.raw.data.DataFactory.
Looks like there is a reference to TEMP_SEGMENT_NAME.

org.apache.derby.iapi.services.info.JVMInfo contains a reference to org.apache.derby.iapi.reference.JDBC30Translation.SQL_TYPES_BOOLEAN.
Its purpose should be only to set JVM version. For some reason this is defined as an abstract
Also, the public static final int JAVA_SQL_TYPES_BOOLEAN should probably be defined in one
of the JDBCTransaction classes and not here.

ClassInspector and ClassInfo seem out of place in org.apache.derby.iapi.services.loader -
as both are implementations that have no dependency on the bytecode generation.
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.

I think that above will give you a flavour of where I am heading.
The bundles I have created load up under OSGI.
I haven't found any unit tests that are defined for the packages I have been working with.
Generally speaking, this will get more difficult when I start looking at the test cases.

Anyway, would welcome your thoughts.

> 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