Before going any deeper into the the servlet project, let’s have a look at the imported projects and talk about some OSGi basics.
First you will notice that for every cloned repository three Eclipse projects have been imported:
- A plugin project
- A feature project
- An updatesite project
The plugin project contains the code and all the relevant resources of the servlet. It defines extension points provided or describes which extension points are used by the plugin.
A feature project is basically a list of plugins and other features which can be understood as a logical separate unit. And an updatesite contains all features you need.
Using an UpdateSite is the preferred way to deploy plugins to Domino. It has a „Build All„-Button which builds all plugins from all features in your updatesite project, and creates the JARs to import into an UpdateSite in Domino.
Update Site „Build All“-Button
A plugin is mainly described by two files: the MANIFEST.MF (stored in the /META-INF folder) and a plugin.xml in the root.
plugin.xml & MANIFEST.MF
The MANIFEST.MF contains meta informations about the Plugin, like the name, imports and exports, other required bundles, the Activator class, the Execution environment and many more.
For example the Domino REST servlet plugin requires the concurrent plugin:
Required Bundles: „ch.hasselba.concurrent.plugin“
If the bundle is loaded, but the requirements are not fullyfied, the bundle won’t start.
The plugin.xml is optional for OSGI bundles, but we need this file, because it describes the extension point used by our plugin:
plugin.xml – Extension Point
Our servlet plugin uses the com.ibm.pvc.webcontainer.application extension point to run a JEE application. The parameter contextRoot is the path our servlet listens (which means it will be reachable at http://example.com/ec2017), and the contentLocation parameter is the path to the static files of the plugin and our web.xml.
An Activator class is the class executed when a bundle is started or stopped (or the other possibilities a lifecyle of a bundle can have). It is also a good idea to store the BundleContext in the Activator to communicate with the OSGi environment.
Last but not least, there is a build.properties file: This file is for Eclipse and contains all relevant information to build the bundle. This means that if you add a JAR file the plugin requires, you have to add the JAR to both – the MANIFEST.MF and the build.properties (if the classes of the JAR file are used in the project).
In the Domino REST Servlet project, the spymemcached.jar is used, that’s why it is added to the build path and the manifest:
build.properties – spymemcached JAR
MANTIFEST.MF – spymemcached JAR
You have to keep this in your mind, because if you write some code, it is not enough just to add the required JAR to the build path, it also has to be exported in your bundle / plugin.
In the next post, let’s have a look into web.xml, and then go into the real „High Performance“ solution.