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.
I usually sign the update sites local and replicate the signed update site to the server. This is faster and you can work with your notes client while replicating 😉
Very good point, I should have thought to do that!
Hi Paul,
I have the same issue. I’m building my plugin with Maven. After importing it into update site it is not visible. I’ve to use Sign All. By building it via Eclipse I have no problems.
The reason is not clear to me, but it is not a slow connection – the same issue I have on local server.
Maven uses Tycho to build for an OSGi environment. Maybe it doesn’t sign the resulting JAR files in the same way that manually building the Update Site project in Eclipse does. It’s only recently that I’ve been using Maven to build REST servlets, so that could be the “what’s changed” element. It certainly sounds a likely candidate. But it’s good to know it’s nothing to do with a slow connection.