« Back

Liferay Portal & OSGi

Company Blogs September 3, 2011 By Ray Augé Staff

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.

If you are not familliar with OSGi, I recommend visiting the OSGi web site, and in particular reading the Benefits of Using OSGi.

The first publicly available code of this integration is available as an OSGi branch on my fork of the liferay-portal project on github.

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.

Threaded Replies Author Date
Whohoo! Nice! Ray, is this correct URL to see... Tomas Polesovsky September 4, 2011 12:17 AM
As a guy that prepares and sells solutions... Szymon Gołębiewski September 4, 2011 9:02 AM
hey ray, could you make your images viewable... Jelmer Kuperus September 4, 2011 3:09 PM
@Tomáš, yes it is! @Szymon, my primary goal is... Ray Augé September 4, 2011 4:55 PM
Does Liferay+OSGi helps us to deploy Liferay in... Ravindra Kanchikare September 4, 2011 9:58 PM
Not immediately, but eventually it would make... Ray Augé September 4, 2011 11:04 PM
Very nice! Thanks, Ray. Jonas Yuan September 5, 2011 8:38 AM
I just published the liferay-plugins OSGi... Ray Augé September 5, 2011 2:21 PM
Truly interesting, I have to take a look. ... Sampsa Sohlman September 6, 2011 6:19 AM
Ray, how deep do you want to go with the... Tomas Polesovsky September 6, 2011 3:07 PM
Ray, how is this going to reflect on... Jakub Liska September 12, 2011 5:19 AM
At least from my perspective the model does not... Ray Augé September 12, 2011 9:45 AM
[...] The service jar needs to go in the... Anonymous September 13, 2011 5:00 AM
be interesting also ? for Vaadin portlets if UI... Jack Bakker September 13, 2011 7:33 AM
Yup! I don't see any reason why they couldn't.... Ray Augé September 13, 2011 7:49 AM
os-chi-i ? :) Jelmer Kuperus September 26, 2011 1:48 AM
;) (can't wait for comment moderation workflow) Ray Augé September 26, 2011 5:57 AM
[...] Internet coverage in Northern Ontario... Anonymous September 28, 2011 8:16 AM
I cloned... Amarjeet Singh October 4, 2011 3:25 AM
You need to use the OSGi branch on my fork :)... Ray Augé October 4, 2011 7:21 AM
just a clarification, i dont see any equinox... Kamesh Sampath October 23, 2011 1:14 AM
Liferay ships with equinox.jar that will appear... Ray Augé October 23, 2011 8:13 AM
[...] Internet coverage in Northern Ontario... Anonymous October 31, 2011 7:50 AM
I'm so happy to see OSGi integration with... Jevon Wright December 20, 2011 6:54 PM
Thanks for your feedback Jevon! I should have... Ray Augé December 23, 2011 6:25 AM
Hi Ray, Could you give me an updated status of... Cristiano Gavião February 18, 2012 5:36 AM
I'll be updating all this info in the next... Ray Augé February 21, 2012 5:54 AM

Whohoo! Nice!

Ray, is this correct URL to see the modifications? https://github.com/rotty3000/liferay-portal/compare/master...OSGi

Thank you.

-- tom
Posted on 9/4/11 12:17 AM.
As a guy that prepares and sells solutions based on Liferay I want to ask what do we gonna get from "Liferay+OSGi"?
Posted on 9/4/11 9:02 AM.
hey ray, could you make your images viewable for guests. I am getting a permission error now
Posted on 9/4/11 3:09 PM.
@Tomáš, yes it is!

@Szymon, my primary goal is to eliminate the dependency on j2ee/servlet specs and app server behaviors for support of hot deploy plugins. Basically, if Liferay could be a plain war, with no global scope interactions/changes needed, it would be better for everyone. OSGi can give us that and more.

@ jelmer, Sorry, should be fixed now!
Posted on 9/4/11 4:55 PM in reply to jelmer kuperus.
Does Liferay+OSGi helps us to deploy Liferay in Goggle app engine ?
Posted on 9/4/11 9:58 PM in reply to Ray Augé.
Not immediately, but eventually it would make it more feasible to attempt it.

There are a number of restrictions that Liferay would have to overcome, naturally the one I mentioned is one of the toughest, the global classloader dependency for plugins.
But even after than is solved, we still need to address: "an app cannot spawn threads, write data to the local file system or make arbitrary network connections", but besides this, and by far the most difficult task would be the persistence tier, which for Liferay is heavily customized hibernate/SQL. App Engine only provides JDO and JPA, which we don't yet support either of.
Posted on 9/4/11 11:04 PM in reply to Ravindra Kanchikare.
Very nice! Thanks, Ray.
Posted on 9/5/11 8:38 AM in reply to Ray Augé.
I just published the liferay-plugins OSGi branch with a few plugins to test out some of the features, such as http bridge support and example, service wrapper example, spring dm example, and blueprint example.

https://github.com/rotty3000/liferay-plugins/tree/OSGi
Posted on 9/5/11 2:21 PM in reply to Jonas Yuan.
Truly interesting, I have to take a look.

Brian Chan did mention OSGi development direction and reasons behind it year ago at European Symposium and now we see where you are going.

Good work.
Posted on 9/6/11 6:19 AM.
Ray, how deep do you want to go with the extensibility?

Have you thought about loading/overriding/adding Struts+Tiles configs/classes, servlet filters, exposing portlets services ... also from the OSGi context - where it could be redefined by a custom module.

And another idea - querying services/pojos in the OSGi context based on the current context in the portal (companyId/name, groupId/name) ?
Posted on 9/6/11 3:07 PM.
Ray, how is this going to reflect on ServiceBuilder ? In regards to the notion of 2 non-related spring contexts (portlet / portal) that use different classloaders - SpringUtil.loadContext() for loading context from spring.configs locations is ok for testing Portal only, but for testing both Portlet services that implicitly use Portal services ... it is not so trivial. This is actually third time I'm doing that, I did it every time differently, learning from past mistakes...
Posted on 9/12/11 5:19 AM in reply to Tomáš Polešovský.
At least from my perspective the model does not change from the current model one iota in the first generations. I also don't see a reason to change it since the OSGi blueprint spec is virtually a one to one mapping of what we're currently doing, except in standardized way.
Posted on 9/12/11 9:45 AM in reply to Jakub Liska.
[...] The service jar needs to go in the tomcat/lib. All other implementation can stay within the portlet war that you are implementing the services. Also you need to make sure the service jar is not... [...] Read More
Posted on 9/13/11 5:00 AM.
be interesting also ? for Vaadin portlets if UI modules could be added/removed on the fly

http://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20Applicat­ion%20with%20OSGi
Posted on 9/13/11 7:33 AM in reply to .
Yup! I don't see any reason why they couldn't. I'm still working on the request handling delegation model (which will heavily factor in when working with third party libs like this). Right now the behavior is pretty raw but I figure it won't be more than a month or two (working on this only part time at the present) and I'll have that sorted out.
Posted on 9/13/11 7:49 AM in reply to Jack Bakker.
Posted on 9/26/11 1:48 AM in reply to Ray Augé.
;) (can't wait for comment moderation workflow)
Posted on 9/26/11 5:57 AM in reply to jelmer kuperus.
[...] Internet coverage in Northern Ontario Forums, IRC, Blog The beauty of XML and XSLT (in 2004) Bits of Liferay's history since 2004, e.g. the Sourceforge Mailinglist Some Features Ray has been involved... [...] Read More
Posted on 9/28/11 8:16 AM.
I cloned git://github.com/rotty3000/liferay-portal.git locally and after a successful build and starting the server, I still do NOT see the OSGi Admin in the control panel. Is there something else I need to do in order to see this in action?

Thanks!
Posted on 10/4/11 3:25 AM.
You need to use the OSGi branch on my fork emoticon It should be in your clone if you pulled all the branches (which I think is typically the default).

That branch is a little old about 2-3 weeks, but it's still very functional.
Posted on 10/4/11 7:21 AM in reply to Amarjeet Singh.
just a clarification, i dont see any equinox jars or any other OSGi supported framework jars in the web-inf/lib of the Liferay OSGi server that i build from your github repo. is the bnd.jar the one which does the provisioning of bundles ? Can you please explain how bundles are processed and which jars are key for it ? just to understand the core architecture of it.
Posted on 10/23/11 1:14 AM.
Liferay ships with equinox.jar that will appear in the WEB-INF/lib folder. This jar provides both the osgi apis as well as the equinox implementation. You could just as easily change this jar for Felix or Knopflerfish, or any OSGi implementation that supports the Framework API, as well as the BundleStartLevel API.

You will find in portal.properties under the ## OSGi heading properties related to the configuration of the framework.

I would like to stick with pure OSGi APIs in order for it to be possible to maintain this implementation agnostic support. It currently is, and should remain possible to swap out the OSGi implementation for any that support the OSGi 4.3 or higher standard.

Deployment of OSGi bundles is implemented in two ways currently. You can drop bundles into the standard deploy folder and an OSGiAutoDeployListener which will identify bundles and install them (this is in trunk already) OR you can upload them directly via the OSGi Admin portlet if you have my OSGi branch (since this portlet is not in trunk).

On portal startup, Liferay's OSGiServiceUtil class will dynamically locate and load the first Framework implementation it finds in its classpath. When initializing the Framework it will use the properties defined in portal(-ext).properties to setup it's environment. The interaction between the portal and Framework will continue to be controlled completely through this class, such as install/update/remove/start/stop/adjust run levels, etc.

The BND jar is only used for handling of OSGi header parsing in two places a) during build time for the portal core, and b) during auto deploy to check if a plugin is an OSGi bundle.
Posted on 10/23/11 8:13 AM in reply to Kamesh Sampath.
[...] Internet coverage in Northern Ontario Forums, IRC, Blog The beauty of XML and XSLT (in 2004) Bits of Liferay's history since 2004, e.g. the Sourceforge Mailinglist Some Features Ray has been involved... [...] Read More
Posted on 10/31/11 7:50 AM.
I'm so happy to see OSGi integration with Liferay, even in alpha stages. I'd love to see Liferay itself split into separate OSGi bundles but I'd imagine that's years and years away.
Posted on 12/20/11 6:54 PM.
Thanks for your feedback Jevon!

I should have some OSGi related content coming out very soon! I hope you find it interesting and ideally useful.
Posted on 12/23/11 6:25 AM in reply to Jevon Wright.
Hi Ray,
Could you give me an updated status of our branch ? it is stable? it is sync with 6.1 version?
I've been working in a vaadin + osgi + tycho product a couple of months. After reading your article, I think that integrating liferay could be a nice path to follow...
regards,
Cristiano
Posted on 2/18/12 5:36 AM in reply to Ray Augé.
I'll be updating all this info in the next week(s) as we're starting the next dec cycle which contains some OSGi work. I'll keep you all posted.

Thanks.
Posted on 2/21/12 5:54 AM in reply to Cristiano Gavião.