Over the past several months I've been working on integrating an OSGi framework into Liferay Portal. The reasons for doing so are varied but include solutions to app server/servlet container dependency, library version conflicts, runtime module lifecycle, advanced extensibility, and so on.
The url of the branch is: https://github.com/rotty3000/liferay-portal/tree/OSGi
I'd like to encourage anyone having an interest in this work to clone the branch and send me feature improvements, bug fixes, etc, via git pull request, or even to just send me comments here.
Things I've done to date:
- I'm using Eclipse Equinox 3.7 (but it works with any 4.1 or greater implementation of OSGi with no code changes, I tested Knopflerfish 3.2.0 and it worked very well, I'm sure Felix would work equally well).
- Published all the services and beans of the portal's spring context as services in the framework so they can be used by bundles.
- Developed a management portlet available in the control panel where the portal administor can add/remove/start/stop/update bundles, see all the bundle headers, all the service registrations and all service references of any bundle. (I'd like to eventually add bundle dependency graphing as well).
- Make sure logging works (this can be tricky in OSGi due to libraries not due to OSGi).
- Setup an auto deploy listener that will inspect any jar/war file dropped into the portal deploy folder that are OSGi bundles and automatically install them into the framework (and try to start them).
- Setup a bridge Servlet which is wired into the OSGi HttpService to provide HttpServlet request dispatching for any servlets or jsps registered in the framework. (This feature depends on a bundle I created which I'm going to release in the comming days, in an OSGi branch of my fork of the liferay-plugins repository. The bundle depends on the eclipse equinox http servlet package which is available in the Equinox 3.7 zip.)
- I've successfully tested various code modification scenarios such as replacing a service implementation and replacing a Util implementation, with all the virtues of OSGi bundle lifecycle goodness.
- I've successfully deployed and used the recently released Gemini Blueprint implementation of the OSGi Blueprint specification (which you might call Spring for OSGi). It's a simple matter of deploying the 3 main bundles.
- I've added BND lib to the portal so that it can be used for various OSGi packaging tasks.
Things I'd like to do next:
- Make some changes to the Plugins SDK so that plugins can (optionally) be generated as OSGi bundles.
- Support deploying the various bundle-ized plugins into the framework.
- Support all the spring wiring of ServiceBuilder services found in plugins correctly.
- Setup a portal packaging system so that we can bundle as set of bundles/plugins so there is no need to assemble and install them manually.
- Modify the Liferay repository mechanism so that it supports bundles and implements either auto update or auto detectiong of possible updates for bundles in the repository (and also resolves/downloads dependencies).
Here are a couple of images of the OSGi Admin portlet.
List of bundles:
View of a Bundle:
I'll be presenting this work in a workshop at the upcoming West Coast Symposium in Anaheim on 21-22 of September.
I hope to hear your thoughs on this and maybe to discuss it with you at WCS.