Status: Ready for QA
Affects Version/s: None
Fix Version/s: 6.2.0 CE B2
Similar Issues:Show 5 results
LPS-39286 Ensure marketplace-portlet doesn't undeploy required plugins LPS-41935 Change the required plugins auto deployment to use ScheduledExecutorService LPS-40655 Hot Deployment mechanism should be robust enough for enterprise level plugin deployment LPS-36261 Block plugin deployment when a fix pack requirements are not met LPS-13771 Ensure AbsoluteRedirectsFilter is still the first filter when EXT plugins are deployed
Core portlets are great because they are bundled into the core and are thus always available. They are essentially the java.lang.* of portlets.
Plugins are great because they are loosely coupled from the core, have their own development cycle, and can be installed or uninstalled on demand. But the drawback of plugins is that you cannot guarantee that they are always available.
The use case for this is similar to "required" app on your smart phone. There are about a dozen or so apps on your smart phone (Maps, Stocks, etc.) that are still loosely coupled from the phone's operating system, have their own development teams, can even be updated separately from the operating system, but are guaranteed to exist on your smart phone because they cannot be ripped out.
We now have that ability in Liferay.
At deploy time, when we make the portal WAR, we first scan portal-impl/src/com/liferay/portal/deploy/dependencies/plugins1, plugins2... to plugins9.
We scan those 9 directories, and write a wars.txt file in each directory based on the list of WAR files in those directories. We do this at deploy time because class loader scanning for files at runtime is not guaranteed in Java. This also means the required plugins are checked in like libraries in the portal source repository. I chose to do it this way instead of having the portal source repository build the latest plugins on demand because that would create a circular dependency for some application servers (e.g. Glassfish, WebSphere) that require an unexploded portal WAR. Plugins would require a fully built portal, but now a fully built portal WAR would require those plugins. It's also just cleaner and simpler if the portal does not depend on the plugins SDK for development.
On startup, the portal will read the wars.txt files for those 9 levels and copy the plugin files that are packaged inside the main portal WAR into the auto deploy directory. They are deployed in the order of the levels. So level 1 is deployed first and level 9 is deployed last.
In our current use case, only the "marketplace-portlet" is at level 1, and we have no other required plugins at the other levels. But if we did, we would put them in levels 2 and beyond.
If a required plugin is not installed, the portal will automatically install it. If a required plugin is manually removed, the portal will reinstall it. Deployment of additional plugins is disabled until all required plugins are registered.