Category Archives: OSGi

  • -

OSGi Adoption and Liferay

Category : Development , Liferay , OSGi

Where Do We Start ?

The goal of this article is to provide a perspective of how relevant the adoption of OSGi in Liferay is to a business executive. Is it really worth the effort to learn OSGi? There are many ways to develop an application. The are numerous frameworks in various languages such as Java, JavaScript, Ruby, PHP, Python etc. If you are a firm that does not deal with Java technologies, OSGi is not for you. If you have a Liferay implementation or are considering one, continue reading.

A Little Bit of History

OSGi has been around since 1999. Liferay has invested more than 5 years in the OSGi technology. The last two years probably were the most intense of all when Liferay started migrating most of the core portlets and services. Until recently most of the Liferay developer community could have easily ignored OSGi and continued to develop plugins the old way. The recommended approach going forward is to use the OSGi bundle, though a legacy deployment may still be supported.

Why OSGi in Liferay?

This is what Ray Augé had to say over the years. Ray has been leading this effort and is the key player behind this implementation.

“Liferay is a large, complex application which implements its own proprietary plugin mechanisms. While Liferay has managed well enough dealing with those characteristics over its history, it’s reached a point on several fronts where these are becoming a burden which seem to bleed into every aspect of Liferay: development, support, sales, marketing, etc.” – Ray Augé October 11, 2012

“Liferay is a complex beast with an intricate network of features, so many features in fact that they occasionally have such indistinct lines such as finding the where one feature ends and another begins can be difficult…The number of benefits is almost too great to list. However, one of the greatest advantages can’t be discussed enough: Modularity.” – Ray Augé Feb 4, 2013

The primary reason Liferay adopted OSGi is to easily manage Liferay as a platform. It is to make things easier for core Liferay developers. The key benefit is the modularity of the OSGi platform. OSGi allows the end user to easily add/remove/enhance services and offerings dynamically. The hardware industry has been following a very modular approach that allows us to add and remove components easily. There is a software piece to it as well which recognizes those dynamic components. Not all software is developed in such a way. Also it should not be the responsibility of the software but rather the platform which should enable such modularity. A capable platform ensures that we don’t have to reinvent the wheel on every piece of code. This is one of the promises of the OSGi platform. If you can tell what your piece of code does and someone can tell what their piece of code needs, the platform can match that up for you while you are still up and running. The OSGi platform does offer various other benefits that you can read up on.

How Relevant is OSGi in Current Architecture?

If you are a business that is using Liferay or looking to use Liferay, it is important that the team invest the time to learn the basic concepts of OSGi. OSGi has a very dedicated group of members who have given all that they have to keep it more relevant. It is very likely that Liferay will continue to use OSGi for at least another 5 years (estimate based on what it took to adopt the OSGi technology). So the time spent on learning OSGi while using Liferay is not a waste.

OSGi provides the concept of µservices within a single JVM. Liferay primarily relies on this feature. In order to stay relevant with the modern cloud architecture and distributed services, there are various OSGi initiatives such as Amdatu that embraces cloud computing.

You could entirely develop a full fledged application using OSGi. Just like you would with Spring Boot and Angular JS or any other JavaScript, PHP, Ruby, or Python frameworks. We could put it this way. Instead of saying, “How relevant is OSGi?,” we can say that OSGi is trying to be relevant by making use of all the new technologies. One thing that the community may lack is the funding and hype similar to the some of the platforms.

Is OSGi the Only Way to Build Modular Applications?

OSGi is probably the only best way to build modular and dynamic application using Java within a single Java Virtual Machine (JVM). The key thing to note here is the single JVM. The way software architecture is evolving indicates that the applications are built in a more tolerant way so that you could remove a server and add it back in a matter a few seconds to a minute or two.

The concept of changing class or implementation within a JVM is not relevant if you are already a shop that knows how to build and deploy your application to an elastic cloud. At that level you are elastically scaling virtual machines in a more tolerant way.

Spring Boot along with PaaS providers such as Pivotal Cloud Foundry and Heroku are an alternative for those developing using Java. OSGi Enroute is trying to provide similar capabilities where you can bundle up your app as a jar file and run it anywhere. Along with the pipelines offered by some of the PaaS providers, nowadays it is as simple as committing the code and the rest is taken care for you.

If you are familiar with some of the javascript frameworks, they do a whole lot of things without having to worry about the class loading issues. In fact, Liferay themselves are working on a similar PaaS called WeDeploy. As of now WeDeploy is in Alpha. Liferay’s interest in providing such as platform clearly indicates the effort to stay relevant and diversify the risks.

It all depends on what you are looking for. If you are a platform or a tool builder, it makes a lot of sense to use frameworks like OSGi. If you are a already running tolerant applications in the cloud, the modularity offered by OSGi is something that definitely does not concern you.

A look at OSGi Adoption

Eclipse IDE is one of the most successful adopters of OSGi that a Java developer comes in contact with on a regular basis. Spring tried to support OSGi but later dropped Spring DM due to the complexity. Glassfish abopted OSGi but later the project was discontinued by Oracle. Liferay has taken the major step of adoption and successfully launched the major version. There is still a lot of work to do within Liferay, but Liferay does provide good support for those developing against it. OSGi has moved further on with OSGi enroute and various cloud computing offerings. Liferay’s primary focus in OSGi adoption is the capabilities within a single JVM. In my opinion, by doing so Liferay has committed itself and has become a major player in OSGi for web applications. A continued success and user adoption within the Liferay community could very well provide the oxygen that OSGi needs in the web application platform.

Liferay has done the toughest part of OSGi adoption in its platform. For the end users Liferay provides various utilities to interact easily with the OSGi service trackers etc. It is sufficient to just understand the basics of OSGi to develop plugins for the Liferay platform. Developers could deep dive into OSGi as needed while working with Liferay. This is in a way similar to how developers using Liferay interact with services without having to master Spring or Hibernate.

Bndtools and various others OSGi frameworks such Apache Felix , Amdatu etc., help it make easy for the developers. There is still a lot of activity primarily supported by the OSGi Alliance members which keeps the community strong even after 17 years.


There are many ways to develop rich applications. If you are a shop that has invested in Liferay, then getting up to speed with OSGi will make your job easier. If you are not a shop that is invested in Liferay or Java, you could live without ever knowing what OSGi is. The one thing that OSGi lacks is the hype and support from the extended Java community. As Liferay is trying to be more than a portal, as a business you need to think beyond any programming language or a platform and evaluate what is best for you. Technology changes so fast. Instead of adopting technology for the sake of it, you need to adopt it to solve your and your customers’ need.