Earlier this week I had a discussion with Graham Acres about an error with ODA.
Firstly, there are two scenarios around plugin errors, and it's important to know the difference:
- Errors in the "Problems" view in Domino Designer. This is a problem with your Designer client - or the last Designer client the application was built with - not having a working version of ODA or the relevant plugin. The version of ODA is just used to verify you've not used invalid syntax at compile-time. There's no magic that adds this to the NSF and you don't necessarily need the same version that will be used on the server. Obviously, if you try to use methods that are newer, you'll hit problems. But typically those are methods that have been added to the core.
- Errors on the server console at run-time. It's important to understand that the problems at run-time aren't caused by a failed compilation, which you can check by looking at the "Problems" view in Domino Designer. But if the NSF doesn't have compilation errors in the "Problems" view, it's a problem with the version of ODA or plugin in your Update Site database on the server.
Once you've identified where the problem lies, it's a case of troubleshooting.
It's important to know that since 9.0.1 FP9 there have been some changes to Domino that introduced breaking changes to ODA. Typically these were removal of plugins that we were referencing, but not using. So you may need to install a newer version of ODA. Developers / admins may not expect this because, for a long time, you've been able to use a much older version of ODA and it still works. But I'd recommend to check and install the relevant version.
The key to verifying all this is two commands, covered in XPages Extension Library book in Chapter 2. tell http osgi ss org.openntf.domino
and tell http osgi diag org.openntf.domino
. The parameter you're passing at the end is the plugin name or part of it. It's important to understand what the normal response it, so I'd recommend running the console command often so you know what you should be looking for. If in doubt, com.ibmxsp.extlib
is a good plugin to try, the Extension Library which is always installed and running since 9.0.
This is what Graham had first. Note that org.openntf.domino was STARTING, but the XPages-specific extension - org.openntf.domino.xsp - is just showing as INSTALLED. That's because there is a missing dependency for that plugin, which is what tell http diag org.openntf.domino.xsp
would say.
So the 10.0.1 version was installed. And this is what the output was.
Now nothing had the status STARTING, just INSTALLED.
The key is that all plugins need to be signed by a valid ID before they will start. Just running the import in the Update Site database with a valid ID may not be enough. And signing the database design and data in Domino Administrator doesn't do what is needed. You need to use Actions > Sign All Content in the Update Site database. Unless you're running on a remote server, that usually runs quickly, so I tend to do it as a matter of course.
It's quicker if you remove all old plugins first - obviously there are fewer documents to update. And it's worth being aware that the Domino server basically detaches the plugins and loads the detached version into memory while the HTTP task is running. So you can delete all content in the Update Site database without impacting the running server.
Once all content was signed, the correct output appeared and the plugins were ACTIVE.
You also should use Karstens Updatesite project from OpenNTF.
https://www.openntf.org/main.nsf/project.xsp?r=project/Open%20Eclipse%20Update%20Site
It allows to remove a single plugin instead of deleting all plugins at once.
A very good point. I’m happy to just remove the QueryDocumentDelete code, because I know what I need to delete and leave. But Karsten’s extended template is good for those less confident in the inner workings of OSGi plugins.
Thank you so much Paul – spent hours trying to get to the bottom of this: “The application xxxx requires org.openntf.domino.xsp.XspLibrary. This library cannot be found” since our v11 upgrade – it was just a case of the Sign All Content action which I hadn’t come across as a suggestion anywhere else!