You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dibyendu Majumdar (JIRA)" <ji...@apache.org> on 2008/02/12 00:49:07 UTC
[jira] Created: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
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
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.
[jira] Commented: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Assigned: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Dibyendu Majumdar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dibyendu Majumdar reassigned DERBY-3405:
----------------------------------------
Assignee: Dibyendu Majumdar
> 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.
[jira] Assigned: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden reassigned DERBY-3405:
-------------------------------------
Assignee: (was: Dibyendu Majumdar)
> 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
> Components: Build tools
> Reporter: 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.
[jira] Commented: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572289#action_12572289 ]
Daniel John Debrunner commented on DERBY-3405:
----------------------------------------------
You can e-mail a scanned copy of ICLA in, see:
http://www.apache.org/licenses/#clas
> 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.
[jira] Commented: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Dibyendu Majumdar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572308#action_12572308 ]
Dibyendu Majumdar commented on DERBY-3405:
------------------------------------------
Okay, done.
> 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.
[jira] Commented: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-3405:
----------------------------------
Component/s: Build tools
> 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
> Components: Build tools
> 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.
[jira] Commented: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572109#action_12572109 ]
Daniel John Debrunner commented on DERBY-3405:
----------------------------------------------
Dibyendu, please note that for any significant contribution you will require an ICLA on file at the ASF. I couldn't see any record of you already having submitted an ICLA.
http://wiki.apache.org/db-derby/DerbyDev has a contributor check list you may want to read.
> 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.
[jira] Commented: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Dibyendu Majumdar (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Dibyendu Majumdar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571993#action_12571993 ]
Dibyendu Majumdar commented on DERBY-3405:
------------------------------------------
> Why is a bundle needed. These classes are only needed at compile time, not a runtime. Does OSGi require a bundle even for compiling?
I think that it is possible to have a plain old library (jar) and include this in a bundle.
But, so far putting reference package in its own bundle seems to be working okay.
> 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.
[jira] Commented: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Dibyendu Majumdar (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-3405) Examine the possibility of
implementing Derby modules as OSGI bundles
Posted by "Dibyendu Majumdar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572286#action_12572286 ]
Dibyendu Majumdar commented on DERBY-3405:
------------------------------------------
No problem, will submit an ICLA. Noticed that it can be either sent by post and? or? faxed. So please expect it in a few days.
> 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.