Why OSGi and Liferay?

 

I had planned to speak at this years North American Symposium about our ongoing work with OSGi. However, sadly due to several different factors that didn't happen.

It's too bad because as it turns out at least two dozen people asked me:

  • What happened to the OSGi plans?

  • Was it dead?

  • When would it come?

  • Was there a talk on it disguised as something else?

  • some variation thereof


 

Likewise, I was asked:

  • What does OSGi and Liferay together even mean?

  • What is the relation?

  • What is the value?

 

Clearing the air

 

1. The plan

Liferay's OSGi plans are not dead. My current focus, as far as development is concerned, is almost 100% OSGi. A usable form of OSGi integration will arrive in 6.2. There was no talk on OSGi at NAS, so you didn't miss anything.

2. The reasoning (why OSGi?)

Liferay is a large, complex application which implements it's own proprietary plugin mechanisms. While Liferay has managed well enough dealing with those characteristics over it's 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, marketting, etc.

(Disclaimer: I'm not part of support, sales or marketting. However, as a senior architect I see how each of those teams deal with the limitations imposed by those previously mentioned characteristics and how they impact the effectiveness of each team, and at times their level of frustration.)

How can OSGi make such a broad impact? you ask.

The impact doesn't actually come from OSGi at all. The impact comes from the outcomes resulting from designing a system using a modular approach.

"Modularity is the degree to which a system's components may be separated and recombined." - Wikipedia

Further to this general definition, you might consider that regardless of which context is used for obtaining a more specific one, it becomes quickly apparent that "modularity" is a benefit rather than impediment.

However, when we do look at a specific definition in the context of software design we see how it clearly applies and might relate to the aspects above:

"In software design, modularity refers to a logical partitioning of the "software design" that allows complex software to be manageable for the purpose of implementation and maintenance. The logic of partitioning may be based on related functions, implementation considerations, data links, or other criteria.” - Wikipedia

Plainly, a modular system allows that the interal details each module be altered without affecting other modules in the system. Imagine if this were true for Liferay on a wider scale.

  • simpler delivery of hot fixes for bugs and/or security vulnerabilities

  • more frequent delivery of improved or new features

  • less bugs in critical modules due to higher degree of focus

  • potentially smaller deployment footprint due to ability to limit functionality to desired modules

  • greater robustness and resilience due to higher degree of care required in designing for consumption and re-use

 

OSGi is simply the best existing implementation of a Java modularity framework. So many of the less obvious concerns which become inherent needs in modular systems are already implemented in OSGi. There exists a number of very good implementations. They are widely adopted. They are heavily supported. The number of supported libraries grows daily, while even unsupported libraries are easily fixed.

 

In short, the benefits far outweigh the costs. There will surely be difficulties along the way, the largest being the fact that learning to implement in a modular way is often counter to how many of us have worked for so long.

 

I'd be very interested in any feedback that people have about this topic, so please let yourselves be heard.

Blogs
Would appreciate if there's something about benefits of OSGi over the current war file distribution and something about how customization will change over the current hook and ext plugins.
Q: benefits of OSGi over the current war file distribution?
A: actual lifecycle, real dependency management, (too many to list).

Q: how customization will change over the current hook and ext plugins?
A: None will change initially, for sake of backward compatibility. Over time, OSGi will improve the granularity and terseness of plugins. Nothing is written in stone about how this will happen, whatever is allowed in OSGi should work. As Liferay re-engineers portions of it's core to suite a more modular approach, the possibility for using more OSGi-esk design will increase. My personal goal is to eliminate need for EXT completely.
Hi Ray, there is a major classloading issue with ehcache & OSGI environment:
http://jira.terracotta.org/jira/browse/EHC-969
I run into this problem with 6.2 beta3.

Is it possible to add a Liferay OSGI bundle (in this case ehcache) as a dependency for a portlet plugin?
Can you give more specific details about the issue you had in 6.2 beta3? For one, our ehcache is not inside Liferay's osgi container. If it's inside an osgi container, it's the container of the app server.

Do you have a ticket and/or stacktrace, steps to reproduce?
Thank you for your response Ray, may be i amalgamated too quickly this issue with OSGi. I updated my thread with a stacktrace here: https://www.liferay.com/community/forums/-/message_boards/message/28199489
I will investigate deeper but any suggestion would be very appreciated!