Since version 8.5.2, Domino Developers have an amazing tool that I feel has been underused due to the massive mindset shift of developing Domino Apps to developing Java Apps. The Domino Server now has the capability of consuming OSGi Libraries. These libraries can provide any amount of Java Code and provide it to all the apps on your server or domain via replication. Part of the complexity has to do with the way these libraries created and deployed. They aren’t NSFs, they are a different type of project that can be used to deploy many of the pieces of JSF functionality that I mentioned in my previous post. Many of the OSGi libraries created for XPages contain XSP Libraries or “Extension Libraries”, a somewhat confusing name since we tend to call IBM’s extension to the core set of functionality in XPages “The Extension Library”. These XSP Libraries are really just wrappers for some of the core JSF functionality to allow the developer to add it into a specific NSF via an entry in the XSP.properties file or globally to every app in a server.
Now that we have an idea of what an XSP Library is, let’s think about some ways we can use it. We have a perfect example of how the XSP Library works in “The Extension Library” from IBM. This Library contains all kinds of functionality for all the apps that specify it in their xsp.properties file. It has Datasources, Components, Renderers, Managed Beans. Another example of this kind of library is the bootstrap4Xpages library, it provides themes and custom renderers for already existing components.
All of these example are specific to NSFs where they are specified in the xsp.properties file, however XSP Libraries can be declared “Global” in which case the library is provided automatically to all the NSFs on the server in question. One interesting example of this would be to provide functionality onto every page of an app, maybe a menu, or a new option every ViewPanel. This could be done with change to the server, never touching any specific app.
XSP Libraries provide us awesome power to change things globally and re-use the code we write and make us more efficient as developers.
So, How do I write one, Actually the XSP Library is fairly simple, it only 1 class that you have to implement and 4 methods.
getPluginID returns the id of the OSGi plugin
getLibraryID returns the id of the Library, (This is what you see as an option in the XSP Properties.
getXspConfigFiles returns a String array of files in the plugin that specify any designer preferences. This can return null if you are not specifying any.
getFacesConfigFiles returns a String array of files in the plugin that specify any faces-config files that will specify or override any functionality in the NSF. This can return null as well.
Below is an example of one that you can find here:
Another small thing you have to do inside your OSGi plugin when declaring an XSP Library is specify the extension point in the plugin.xml
Its really simple xml that just specifies the type of extension and what class specifies it. The below example actually specifies two different types of extensions, the first <extension> tag specifies the XSP Library.
That’s really it, 2 files and you have an xsp library, the problem is an xsp library without anything in it is pretty useless, however as we go about this series we will add things into it that will make the library very powerful. One thing to note is that this post was about XSP libraries and not so much about OSGi plugins, There have been quite a bit written about these, very recently John Cooper wrote a post over at his blog that describes this process in good detail.