Those who were at my session about ODA (OpenNTF Domino API) with Stephan Wissel at IBM Connect may remember him mentioning that his preferred place for adding plugins was directly on the server, because of some issues he had encountered. After Connect I asked for some clarification, so I could understand the risks, symptoms and so pre-empt any potential issues.
What Stephan and others found out when they dug into it further was that the sequence of loading OSGi plugins, or extension libraries, is:
- Osgi folder (<Domino>\osgi\shared\eclipse\plugins). Note, there is an “rcp” folder under “osgi”, but that is not available to the XPages runtime, which is a shame because it includes some very useful code like Apache commons.
- Workspace folder (<Domino>\data\domino\workspace\applications\eclipse\plugins). There is typically no content in here.
- Update Site database(s). The notes.ini can reference multiple and I often use multiple Update Site databases regularly. The reason for this is it allows me to leave the core functionality of only allowing all content to be deleted, but still allows me to keep related content together.
The impact of this loading order is that if a plugin is loaded from the osgi folder, is not set to lazy load (so initialises immediately rather than when required), and depends on a plugin in an Update Site, it will fail. Typically this will not happen for most developers, but it’s worth bearing in mind and ensuring your plugins are all loaded at the same level.
As has always been the focus of my training on XPages, it’s important to understand what’s happening in order that expectations are not misaligned. If you can understand what’s happening under the hood, you can pre-empt actual behaviours and adapt accordingly. If you don’t (and that’s the same for any technology, not just XPages), outcomes can be unexpected and resolving the problem can only be done by learning what’s happening or luck.