Technically, the eXo Kernel provides an extensibility mechanism that extends the portal container configurations.
This extensibility mechanism allows more services and resources to be loaded at start-up.
In other words, thanks to the extensibility mechanism, you can extend the portal resources in an almost plug-and-play fashion
- simply by dropping in a .war archive with the resources,
and configuring its position on the portal's classpath in a .jar archive.
Note
With this way, customization of the portal does not involve unpacking and repacking the original portal's
.wararchives. Instead, you can override a portal resource by including it in your extension in the same path as that ofportal.war.In case many extensions include a same resource, they override each other too. So, take care that only the last loaded one will take effect.
See the following diagram for how the portal extensions work:
eXo Platform comes with a pre-configured PortalContainer named "portal".
The configuration of this portal container ties the core and the extended services stack.
The default portal container is started from portal.war and naturally maps to the /portal URL.
The webapp portal.war is the base that can be overridden by other extensions.
The extensibility is achieved via 2 advanced features of the PortalContainer:
A unified ClassLoader: Any classpath resource, such as property files, will be accessible as if it was inside
portal.war.Note
This is valid only for resources but not for Java classes.
A unified ServletContext: Any web resources contained in your
custom-extension.warwill be accessible from /portal/ uri.
When you are extending an existing portal container, the name of the portal in the extension's configuration should be the same as that of the existing portal container. By using this approach, the configuration (and many other aspects) of an existing portal container can be customized, for example, Groovy templates of portlets, porlet skins, CSS and Images, navigations and pages or localizations.