Recently I’ve been working on an extensive OSGi REST service plugin, based on ODA Starter Servlet. Local development is using a pde launch configuration to load my plugins directly from Eclipse. Even with ODA Starter Servlet being maven-enabled, which means building the update site takes moments, running directly from Eclipse is much more preferable. The key step is, when a new plugin is added to Eclipse, to go to Debug Configurations…, go to the OSGi Framework configuration and reload it by clicking the Debug button. This tells the server about the new plugin, so it gets loaded. Then, whenever a change is made, a swift restart of HTTP reloads it. Personally, I don’t have a problem with doing that, but if you do then look at running JRebel against Domino, as covered by Cameron Gregor.
But this was not the root of my problems. Everything was fine until I tried installing it in the Update Site database on the relevant server. Over a slow network, it took some time. But no matter what I did, the plugin wasn’t being picked up.
tell http osgi diag and
tell http osgi ss commands didn’t work. Thankfully Jesse Gallagher was able to recommend the solution, using the “Sign All Content” action. I thought this wouldn’t be needed, because I was in LocalDomainAdmins group on the server. But it appears it was. Maybe it was because of slow network speed to the server, I don’t know. It’s strange I hadn’t come across it before. But now it’s my standard step for servers I encounter the problem on.
Incidentally, the “Sign All Content” can also take a while on the remote servers. I’m not 100% sure what it’s doing behind the scenes, possibly detaching the jar file to the server, doing something with it and re-uploading it. I’ve disabled the QueryDocumentDelete code, but only because I have a deep understanding of what Notes documents get added and the version mappings that are key. In other scenarios I’ve used multiple Update Site databases, allowing the “Delete All Content” action to be used to clear the database down.