Following on from my last blog post, when I came to installing Domino I encountered two issues, both of which I’ve encountered before and both I’d forgotten the resolution and struggled to find it. Making mistakes is unavoidable. Making the same mistake twice, however, is. So I’m resorting to my standard resolution: blog about it. At the very least, it will help me. In all likelihood it will also help others.

The first was during the Domino installation itself. I’m running my local development server on my Windows 10 PC. As I encountered during the beta, I got the message “Lotus Notes/Domino or a Notes/Domino related process is still running”. But I’d made sure they were all stopped before starting the installation. The message also pointed towards UAC, but I remembered at least that that wasn’t the cause. I knew I’d asked the question on Watson Workspace, so searched there, and found I’d also identified the solution:

I also needed to stop the Windows Management Instrumentation services as well. Once done, the installation ran fine.

The second was after the installation ran. I started the Domino server, but hit the same issue I had with the beta: NullPointerException at com.ibm.domino.http.bootstrap.BootstrapOSGIClassLoader.launchOSGIFramework(BootstrapOSGIClassLoader.java:85). The full stack trace screenshot is below:

Searching the internet didn’t give me any useful links. But I knew no one else had mentioned hitting the same error. So I knew it must be something about my setup. What was different? Or unusual?

I realised that, unlike a lot of other people, I don’t tend to have lots of plugins loaded from UpdateSite.nsf databases or in the osgi folder. Instead, I have the source projects installed in Eclipse. Domino loads them dynamically with a OSGi framework configuration. You get to it by accessing Debug Configurations. The screenshot shows the settings below:

You create a new OSGi Framework configuration, set the Framework to “Domino OSGi Framework” and set Default Auto-Start to “false”. Then you select the plugins you want. Deselect all features. Clicking “Debug” then posts that configuration to the Domino server you have setup via XPages SDK, by adding a “pde.launch.ini” in <domino>\data\domino\workspace folder. That file will point to the Eclipse configuration of which plugins to use. Obviously, this is only a good reason if you’re the only one developing on that server – which is yet another reason why I’ve been recommending developers use a local development server for some time.

Restarting HTTP now picks up the plugins selected. If you change a plugin, just restarting HTTP picks up the changes in Eclipse without needing to create an Update Site project. If you add a plugin, you just need to go into the OSGi Framework configuration dialog above and click “Debug” again. If you remove plugins, again you should go to the dialog and click “Debug”. If you want to stop using it, just delete the “pde.launch.ini” file.

Of course the other time it needs to be done is if you upgrade the server. And that’s what I’d forgotten. As soon as I did, the server ran fine.

Lesson learned…and documented!

1 thought on “Development Server Installation Gotchas”

  1. I disable the Windows Instrumentation service since it is configured to respawn. After patching, I re-enable it as a service, and restart the OS. I also have Process Explorer installed on the Windows servers to help spot whether an IBM service or, if a backup agent is installed, the backup agent is running.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.