How The Extlet Works

Logical views

We see the Extlet in two different axes:

1. Development environment, enables developer to be really quick in building and deploying changes of the Liferay core classes, enables architects to design components as loosely coupled physical bundles.
2. Runtime environment, behaves as the EXT, but it’s not the EXT. Enables to run multiple Extlets together. But they shouldn’t interference!

Development Environment

The core idea was to create one artefact, in which you can have all the functionality needed. Thus to have one Extlet, in which you can package portlets and changes of the Liferay’s core together.

The development environment consists of the Extlet maven archetype, which generates structure of the Extlets. Using Maven you can build and package the Extlet’s war file and deploy to the Liferay as any other Liferay SDK’s plugin.

Runtime Environment

Part of the Extlet is the extlet-setup component. This Extlet’s part modifies core classes in the Liferay and enables them to load all -extlet.xml configuration files from the classpath.

That means that you can change configuration files in every Extlet you have. There is no more single liferay-portlet-ext.xml, you can have liferay-portlet-extlet.xml in every Extlet, portal (Extlet’s runtime env.) will merge all these configuration files together with the portal’s liferay-portlet.xml file.

The extlet-setup also provides logic for (re|un)deployment of the Extlets.

Architecture – why it works

There are 2 simple ideas behind it:

1. Extlet’s classes should be loaded before the portal ones. Then the Extlet can overwrite the Liferay core classes with the changed classes.
2. To have fully featured support for Extlets, the runtime environment must merge all configuration files together.

If there is conflict:

1. 2 Extlets override the same portal class – the class is loaded from the Extlet, which is first in the alphabetical order
2. 2 Extlets override the same line (same definition) in the configuration files – wins the last Extlet

Classloading

Extlets use the same mechanism as the old EXT. There is nothing special. The only difference – there are just more jars (from the Extlets), not the only the one (from the EXT).

Explanation:

In the EXT there is ext-impl.jar file. This file is searched by the Tomcat’s WebappClassLoader before portal-impl.jar, because the jars are retrieved from the FileDirContext alphabetically (and the letter e is simply before the p :) For further info see the Tomcat’s WebappLoader.setResources(), FileDirContext.list(File file), WebappClassLoader.addJar(String jar, JarFile jarFile, File file) and WebappClassLoader.findResources(String name) methods.

And this is the only one RULE.

This rule implies the Extlet to contain the jar with extlet- prefixed name.

It also simply implies that you can override every portal class with your implementation, if you put your jar file into the WEB-INF/lib directory, and you jar file name is alphabetically before the portal-impl.jar.

Merging the config files

The all config files are merged using standard way:

1. Load portal’s configuration file
2. Load the old EXT configuration file (files with postfix -ext)
3. Load all configuration files from all extlets on the classpath using Classloader.findResources(String configurationFileName)
   1. that means call the WebappClassLoader.findResources(String name)
   2. that loads resources from the jars in the alphabetical order

---

Next: Source Codes