Introduction
ApacheDS is scheduled to offer OSGi capability around the June 2007 timeframe.
Proposal
We propose to begin moving to OSGi through a series of baby steps:
- Document packages - Start documenting all our packages in all our projects with package-info.java files.
- Resolve obstacles - Track the status of obstacles to moving to OSGi to reduce the risk of making a bad container choice. See the "Obstacles" table, below.
- Add OSGi metadata - Add the maven-bundle-plugin to our pom.xml files, one by one, to generate bundle jars with OSGi metadata.
- Analyze dependencies - Refactor to improve coupling.
- Use container - Switch 'server-main' to use Apache Felix, update installers, etc.
- Future enhancements - TBD, major functionality improvements taking full advantage of OSGi dynamics.
Obstacle |
Status |
|---|---|
Move antlr wrapper from 'jconlon osgi-commons' to Felix. |
|
Move commons-collections wrapper from 'jconlon osgi-commons' to Felix. |
|
Move commons-lang wrapper from 'jconlon osgi-commons' to Felix. |
|
Move jdbm wrapper from 'jconlon osgi-commons' to Felix. |
|
Move jzlib wrapper from 'jconlon osgi-commons' to Felix. |
|
Achieve Felix graduation. |
|
Felix 1.0 release with R4 support. |
|
Non-snapshot Felix bundle plugin released and deployed to Ibiblio. |
|
Bug fix in Maven when using multiple plugins. |
|
Find/build an integration testing framework to easily test services within the target container as part of the maven build process. |
|
Achieve good test coverage, testing the ApacheDS services inside an OSGi container (requires integration testing framework). |
|
Solid documentation in Confluence for OSGi-based architecture for ApacheDS. |
|
Greater team awareness of this OSGi based architecture. |
|
Review OSGi alternatives like xbean. |
|
Time for us all to be involved to make sure something does not go wrong during this move to OSGi. |
|
Finish key enterprise features the server needs first. |
|
Clean-up, doco, and enhancements to the protocols (Kerberos, etc.). |
|
Spring-OSGi release. |
|
Notes
From an OSGi perspective ApacheDS can be viewed as three major organizations of functionality:
- Shared utility functionality - Shared
- Network functionality - Mina
- Main platform functionality - ApacheDS
The three functional organizations of ApacheDS are now being adapted to OSGi through a process of 'structural and service oriented componentization'.
For a review of OSGi best practices see: OSGi Best Practices
Structural Componentization
Structural Componentization is the management or partitioning of software at the modular (archive/jar) level. In OSGi a structural component or bundle refers to a Java archive, that has OSGi metadata annotated in its manifest. In the OSGi runtime container, bundles (metadata annotated jars) offer or export their Java packages for use or import by other bundles running within the container.
Package import and export relationships between bundles, are created as classloader wirings by the OSGi runtime container.
Structural Componentization can also be called 'Package Dependency Management'. Structural Componentization is the initial focus of the OSGi work effort. It will consist of annotating ApacheDS software artifacts with OSGi specific metadata.
OSGi Commons Bundling Projects
Both ADS and Mina depend on third party libraries. For OSGi based Mina and/or ApacheDS bundles to start within an OSGi runtime; all dependent libraries must be packaged as OSGi bundles, be installed, started and have their packages exported to the OSGi runtime so that these packages may be imported by the Mina and ApacheDS bundles.
The OSGi Commons Bundling projects have been initiated to facilitate the creation of Mina and ApacheDS dependent libraries as OSGi bundles. The projects are simple pom based and simply wrap the targeted third party packages in OSGi annotated jars (aka OSGi bundles).
Current OSGi Commons Bundle Projects:
- antlr
- commons-collections
- commons-lang
- jzlib
The maven Plugin
The OSGi Commons Bundling projects utilize the new org.apache.felix maven-bundle-plugin to do the wrapping/annotating of the jars.
Service Componentization
Service Componentization refers to the management of services and their dependencies on other services and on configuration resources.