A Simple Plugin System for Web Applications
We need to make multiple web-based projects with a lot of shared functionality. For that, some sort of a plugin system would be a good option (as an alternative to copy-pasting stuff). Some frameworks (like grails) have the option to make web plugins, but most don’t, so something custom-made is to be implemented.
First, let’s define what is the required functionality. The “plugin”:
- should be included simply by importing via maven/ivy
- should register all classes (either automatically, or via a one-line configuration) in a dependency injection container, if one is used
- should be vertical – i.e. contain all files, from javascript, css and templates, through controllers, to service layer classes
- should not require complex configuration that needs to be copy-pasted from project to project
- should allow easy development and debugging without redeployment
The java classes are put into a jar file and added to the lib directory, therefore to the classpath, so that’s the easy part. But we need to get the web resources extracted to the respective locations, where they can be used by the rest of the code. There are three general approaches to that: build-time extraction, runtime extraction and runtime loading from the classpath.
The last approach would require a controller (or servlet) that loads the resources from the classpath (the respective jar), cache them, and serve them. That has a couple of significant drawbacks, one of which is that being in a jar, they can’t be easily replaced during development. Working with classpath resources is also tricky, as you don’t know the names of the files in advance.
The other two approaches are very similar. Grails, for example, uses the build-time extraction – the plugin is a zip file, containing all the needed resources, and they are extracted to the respective locations while the project is built. This is fine, but it would require a little more configuration (maven, in our case), which would also probably have to be copied over from project to project.
So we picked the runtime extraction approach. It happens on startup – when the application is loaded, a startup listener of some sort (a spring components with @PostConstruct in our case) iterates through all jar files in the lib folder, and extracts the files from a specific folder (e.g. “web”). So, the structure of the jar file looks like this:
com
company
pkg
Foo.class
Bar.class
web
plugin-name
css
main.css
js
foo.js
bar.js
images
logo.png
views
foo.jsp
bar.jsp
The end-result is that on after the application is started, you get all the needed web resources accessible from the application, so you can include them in the pages (views) of your main application.
And the code that does the extraction is rather simple (using zip4j for the zip part). This can be a servlet context listener, rather than a spring bean – it doesn’t make any difference.
/**
* Component that locates modules (in the form of jar files) and extracts their web elements, if any, on startup
*
* @author Bozhidar
*/
@Component
public class ModuleExtractor {
private static final Logger logger = LoggerFactory.getLogger(ModuleExtractor.class);
@Inject
private ServletContext ctx;
@SuppressWarnings("unchecked")
@PostConstruct
public void init() {
File lib = new File(ctx.getRealPath("/WEB-INF/lib"));
File[] jars = lib.listFiles();
String targetPath = ctx.getRealPath("/");
String viewPath = "/WEB-INF/views"; //that can be made configurable
for (File jar : jars) {
try {
ZipFile file = new ZipFile(jar);
for (FileHeader header : (List<FileHeader>) file.getFileHeaders()) {
if (header.getFileName().startsWith("web/") && !fileExists(header)) {
// extract views in WEB-INF (inaccessible to the outside world)
// all other files are extracted in the root of the application
if (header.getFileName().contains("/views/")) {
file.extractFile(header, targetPath + viewPath);
} else {
file.extractFile(header, targetPath);
}
}
}
} catch (ZipException ex) {
logger.warn("Error opening jar file and looking for a web-module in: " + jar, ex);
}
}
}
private boolean fileExists(FileHeader header) {
return new File(ctx.getRealPath(header.getFileName())).exists();
}
}
So, in order to make a plugin, you just make a maven project with jar packaging, and add it as dependency to your main project, everything else is taken care of. You might need to register the ModuleExtractor
if classpath scanning for beans is not enabled (or you choose to make it a listener), but that’s it.
Note: this solution doesn’t aim to be a full-featured plugin system that solves all problems. It doesn’t support versioning, submodules, etc. That’s why the title is “simple”. But you can do many things with it, and it’s has a very low complexity.
Note 2: Servlet 3.0 has a native way of doing almost the same thing, but it doesn’t allow dynamically changing the assets. If you don’t need to change them and don’t need save-and-refresh, then it’s probably the better option.
We need to make multiple web-based projects with a lot of shared functionality. For that, some sort of a plugin system would be a good option (as an alternative to copy-pasting stuff). Some frameworks (like grails) have the option to make web plugins, but most don’t, so something custom-made is to be implemented.
First, let’s define what is the required functionality. The “plugin”:
- should be included simply by importing via maven/ivy
- should register all classes (either automatically, or via a one-line configuration) in a dependency injection container, if one is used
- should be vertical – i.e. contain all files, from javascript, css and templates, through controllers, to service layer classes
- should not require complex configuration that needs to be copy-pasted from project to project
- should allow easy development and debugging without redeployment
The java classes are put into a jar file and added to the lib directory, therefore to the classpath, so that’s the easy part. But we need to get the web resources extracted to the respective locations, where they can be used by the rest of the code. There are three general approaches to that: build-time extraction, runtime extraction and runtime loading from the classpath.
The last approach would require a controller (or servlet) that loads the resources from the classpath (the respective jar), cache them, and serve them. That has a couple of significant drawbacks, one of which is that being in a jar, they can’t be easily replaced during development. Working with classpath resources is also tricky, as you don’t know the names of the files in advance.
The other two approaches are very similar. Grails, for example, uses the build-time extraction – the plugin is a zip file, containing all the needed resources, and they are extracted to the respective locations while the project is built. This is fine, but it would require a little more configuration (maven, in our case), which would also probably have to be copied over from project to project.
So we picked the runtime extraction approach. It happens on startup – when the application is loaded, a startup listener of some sort (a spring components with @PostConstruct in our case) iterates through all jar files in the lib folder, and extracts the files from a specific folder (e.g. “web”). So, the structure of the jar file looks like this:
com company pkg Foo.class Bar.class web plugin-name css main.css js foo.js bar.js images logo.png views foo.jsp bar.jsp
The end-result is that on after the application is started, you get all the needed web resources accessible from the application, so you can include them in the pages (views) of your main application.
And the code that does the extraction is rather simple (using zip4j for the zip part). This can be a servlet context listener, rather than a spring bean – it doesn’t make any difference.
/** * Component that locates modules (in the form of jar files) and extracts their web elements, if any, on startup * * @author Bozhidar */ @Component public class ModuleExtractor { private static final Logger logger = LoggerFactory.getLogger(ModuleExtractor.class); @Inject private ServletContext ctx; @SuppressWarnings("unchecked") @PostConstruct public void init() { File lib = new File(ctx.getRealPath("/WEB-INF/lib")); File[] jars = lib.listFiles(); String targetPath = ctx.getRealPath("/"); String viewPath = "/WEB-INF/views"; //that can be made configurable for (File jar : jars) { try { ZipFile file = new ZipFile(jar); for (FileHeader header : (List<FileHeader>) file.getFileHeaders()) { if (header.getFileName().startsWith("web/") && !fileExists(header)) { // extract views in WEB-INF (inaccessible to the outside world) // all other files are extracted in the root of the application if (header.getFileName().contains("/views/")) { file.extractFile(header, targetPath + viewPath); } else { file.extractFile(header, targetPath); } } } } catch (ZipException ex) { logger.warn("Error opening jar file and looking for a web-module in: " + jar, ex); } } } private boolean fileExists(FileHeader header) { return new File(ctx.getRealPath(header.getFileName())).exists(); } }
So, in order to make a plugin, you just make a maven project with jar packaging, and add it as dependency to your main project, everything else is taken care of. You might need to register the ModuleExtractor
if classpath scanning for beans is not enabled (or you choose to make it a listener), but that’s it.
Note: this solution doesn’t aim to be a full-featured plugin system that solves all problems. It doesn’t support versioning, submodules, etc. That’s why the title is “simple”. But you can do many things with it, and it’s has a very low complexity.
Note 2: Servlet 3.0 has a native way of doing almost the same thing, but it doesn’t allow dynamically changing the assets. If you don’t need to change them and don’t need save-and-refresh, then it’s probably the better option.
Have you used Servlet 3.0’s web-fragment JARs? They provide much of the same functionality as you describe, without having to bootstrap them. CDI Beans can be injected and web resources can be deployed. It’s a very nice way to distribute common components (especially in a Maven project).
Isn’t it about web.xml definitions only? Can it extract css/js/jsps?
Servlet 3 containers can directly serve assets in JARs if they are in the META-INF/resources directory.
Also, check out WebJars for a project that cleanly provides what you’re looking for. webjars.org
This approach implies some conventions about the structure of the Maven project of a module. Maven archetypes are very useful in keeping things simple in this kind of situation – http://maven.apache.org/archetype/maven-archetype-plugin/create-from-project-mojo.html
@Mwanji Ezana – yes, I added Note2 about that.