Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

SMILE AT LIFERAY DEVCON 2015 – PART 1 : LIFERAY 7 OSGI

As usual day one is for the announcements, mainly on what will be discuss along the devcon. As expected this was part 2 of last year’s devcon: so many undefined parts that there was no choice but to carry on exposing on this refoundation that is Liferay 7.

“Basically all is going to be the same for the final user but nothing will remain on the same place for the developer.”

First impression as a developer is that we need to learn Liferay from the beginning once the 7th version will be used for the first project. Liferay is saying that old plugins will run on the new version except for those cases where the API has been modified, that will have to be adapted to the new version.

OSGI : the critical Liferay 7 change

I’ll start talking about the most important point of the changes coming on Liferay 7, OSGI modularization. Each of the paragraphs below could be extended to a full fledged post just about that point, so here the goal is to make the start point about that aspect on the framework. For sure not all aspects about the OSGI impact are analysed here, as the need to update to Java 8.

Be ready to go back to school and get ready to OSGI your life.

Image1

Why OSGI ?

This is the main guy to blame for the major modifications on Liferay. Modularization is a very hot topic, more profound than big data. For some time modularization has been on the Java plate, and finally it was promised for version 9.

But Liferay wants to keep a fast paced release cycle: with engagement, social media, CXM, UXP coming, modularization seems to be the only hope to survive. The truth is that the project was becoming too complex to be kept as one monolith with all the portlets from Liferay core delivered “velis nolis”.

OSGI is a proven framework for modularization, which promises to deploy only the required modules for the project, managed with a semantic versioning, trying to make sure that you use the very same libs that were used to build the artifact. So no more trusting component-##.##.jar, the real versioning will be based on the signature produced by the code, so one more semicolon will force you to update the version dependency on the project setup.

Versions and dependencies are one problem, which version is the correct one for all the components, each component can have its own dependencies delivered with it. But what it will happen when each portlet will load his own version? Versioning will have to be carefully planned to avoid proliferation of dumb versions or too specific versions used only for a component.

I.1.a Tailored portal & nodes

Modularization will affect Liferay core too, it will be easy to tailor the portal functional payload to specific needs such as a pure document service, removing everything else.

And here are some of the strongest points of the OSGI philosophy:All liferay core portlets will be plugins as any other custom portlet you may develop. The advantage is that Liferay components can be replaced in a transparent way by your custom component that will implement your needs, so if you want to plug any DMS behind Liferay and use only that system for the Documents: just replace Liferay’s Documents portlet by your portlet and that will do all the magic.

Large clusters can have several configurations on each node depending on the task of the node – which will complicate the life of the sysadmin in benefit of the end user. Deployment won’t be no more single configuration for all nodes and one step to production. Sure this is not the most common case but we cannot leave it on the side as it can be very useful in many cases where the bottleneck can have a dedicated Liferay instance with its own configuration and resources to speed up the service – Although Licensing might be an issue and should be discussed on a case by case basis.

Huge flexibility

Finally, one last point is that each module can have its extension points updated with any other OSGI module. These modules can be hot deployed and un-deployed. Beware however to the UI impact for end users if the modification is done live – What happens if an advanced admin deploys a “nice looking” plug-in that overwrites a required plugin?

These accidents must be prevented when configuring the servers, same goes for the specific configurations on a cluster. Liferay does not yet know exactly how to handle locking modifications on the deployed modules, they simply trust OSGI for the moment.

What about migration? As Liferay recommends, do not transform you apps, just carry on using them on the same format as now, plain usual war portlets as up to now. Old wars will be deployed on the very same way as now, new OSGI plugins will be deployed on the “/O” folder, Liferay will take care of the rest.

Developers will have to learn the new paradigm, but the advantages are numerous, and what is more constraint, it will be the only technology for Liferay. 

Expert Smile
Auteur de l’article

José Fernandez

Technical Architect

Avis des internautes

comments powered by Disqus