[
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:
------------------------------------------
Dan,
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.iapi.error
org.apache.derby.iapi.services.i18n
org.apache.derby.iapi.services.info
org.apache.derby.iapi.services.sanity
org.apache.derby.iapi.services.stream
org.apache.derby.iapi.util
org.apache.derby.impl.services.stream
org.apache.derby.shared.common.error
org.apache.derby.shared.common.i18n
org.apache.derby.shared.common.reference
org.apache.derby.shared.common.sanity
org.apache.derby.core.io.api - This contains
org.apache.derby.io
org.apache.derby.core.io.impl - This contains
org.apache.derby.impl.io
org.apache.derby.core.bytecode.api - This contains
org.apache.derby.iapi.services.compiler
org.apache.derby.iapi.services.loader
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.ModuleSupportable,
org.apache.derby.iapi.services.monitor.Monitor,
org.apache.derby.iapi.reference.Property,
org.apache.derby.iapi.services.property.PropertyUtil.
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 class.
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 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.
