On Monday I released XPages OpenLog Logger M6 on OpenNTF, the latest enhancement. It is quite some time since the last release in March 2014. A few suggested enhancements had hung around for a while, as well as a bug in the plugin version that meant the database an error was recorded for was not being cleared between error or event logs. That had been fixed in my local repo for a while but not pushed up, so when some additional requests and a bug fix came in, it prompted me to pick it up again.
In the process there were some quite significant changes, both behind the scenes and within the code itself.
I realised the PDF on the Documentation tab on OpenNTF had not been updated from release to release, although updated documentation had been included in each release’s zip file. I’ve addressed that.
Non Ext Lib Still Deprecated
Since M5 I stopped supporting the non Extension Library version of the NSF and so there is no NSF with that code in it in the M6 release. That is for a couple of reasons. High profile security issues over the last year as well as iOS incompatibilities have hopefully highlighted to all developers and IT departments that if you want to deliver web applications, particularly externally facing web applications, web servers must be kept up-to-date in a much more aggressive manner than previously. On this topic, I cannot echo David Leedy’s message last month loudly enough. 8.5.2 should not still be a server version for live XPages applications. If you’re still on Domino 8.5.3, you should start planning your upgrade, if you haven’t yet.
The second reason is the Extension Library itself. I’ve said before that I don’t understand the standpoint of not using the releases of Extension Library from OpenNTF to aid development of custom applications: if support or skill-set is an issue, talk to a business partner like Intec (we’ve done that before and one outcome of that support has recently found its way back into the core Extension Library); if the belief that it’s “unofficial code” is an issue, cease and desist all custom development you do immediately. But Upgrade Pack 1 has been released for years now. It’s official, tested and supported. So there is no excuse for having 8.5.3 base install – it will not be able to adequately showcase Domino and XPages.
One of the more significant changes in M6 is the Java class used as the entry point for logging, OpenLogUtil instead of OpenLogItem. As my knowledge of Java has increased, I’ve realised it’s much better practice to use of a utility class rather than make every method of an instantiatable class like OpenLogItem static. It’s also the approach that has been in place in OpenNTF Domino API for some time.
If you’re only logging from SSJS, there are no changes.
If you’re logging from Java, there is a significant change required but one that should not be onerous. You will need to do a “Find and Replace” in your databases, made much easier since 8.5.0 with the in-built Eclipse Search functionality. Search for OpenLogItem in the database and, at the bottom of the dialog click the Replace… button. This will allow you to change OpenLogItem for OpenLogUtil. Click the Preview> button in the replace dialog and you can configure which entries get replaced. If you’re not using the plugin version, remember to de-select the com.paulwithers.openLog classes. Then click OK.
You may end up with some import errors where the class being imported is wrong. Clicking on the cross will usually allow you to import the right class, thanks to the intelligence of the Java editor. If you have used any other methods that logEvent or logError, you will need to amend the code to get the current OpenLogItem, by using OpenLogUtil.getOpenLogItem(). After that, there is no more to do.
OpenNTF Domino API
Following on from that, it’s worth mentioning OpenNTF Domino API (ODA), because more and more developers have been leveraging its power this year. All of the XPages OpenLog Logger code is already in that project. Instead of OpenLogUtil you need to use XspOpenLogUtil. That’s the only difference.
Over the coming weeks I’ll be adding the changes into that project.
As mentioned, one of the fixes is #27, an incorrect logging of the source database when the plugin was used. This was a rather tricky one to pin down, but is now fixed and has been fixed in ODA since 2.0.0.
A couple of fixes were done for uncaught exceptions, #26 for an invalid id during a partial refresh and #29 for capturing a ParseException. There was also a fix added for logging the correct page from caught exceptions if you jumped into an application at a page that had an error, #22.
It’s been possible to add a display message for some time. This is now passed to the Errors control on the page (#23) and to the message in OpenLog’s views (#24). Thanks to Philippe Ardit for raising those quite some time ago.
A number of additional xsp properties have also been added:
- xsp.openlog.includeQueryString to include the full URL in errors / events (#29). This can be useful in applications that use Dynamic Content Controls, but the down-side is that URLs that include e.g. documentId will log as separate categories in OpenLog database. Thanks Eric McCormick.
- xsp.openlog.suppressErrorControl to suppress the control ID logging from an event (#25). I sometimes find this useful, so it’s an xsp.property. Thanks Philippe Ardit.
- xsp.openlog.templateFilepath to allow an OpenLog NSF to be auto-created based on a template, if it doesn’t exist at the location (#33). This was a request from last week via the XPages Slack chat from Steven Rieger, thanks.
As ever, remember that if you change the Xsp Properties file, the application needs cleaning to pick up the changes.
One final enhancement was to add XPages references to the .gitattributes file so the relevant design elements are tagged as XPages on GitHub.
Over the last few months OpenNTF has been trialling Atlassian tools including Stash and Jira. We’re hopefully getting closer to releasing those in the wild, so XPages OpenLog Logger has been added to Stash as a project and repository. For at least a period of time there will be parallel-running (all it takes is right-clicking in SourceTree and selecting Push To and selecting a different remote repository).
A JIRA project has also been set up for logging issues, and this will replace the GitHub issues list. JIRA (and Stash) is integrated with OpenNTF’s directory, so active OpenNTF users should already have access just by logging in with their OpenNTF credentials. Adding an issue is very straightforward and I’ve always found Atlassian’s help very good. In the future, issue logging may be integrated into the OpenNTF projects themselves – it certainly looks feasible, but everyone on the Board is learning as we go (in addition to the day jobs!).
Now the big announcement. Don’t worry, I’m not going anywhere. But I’m conscious that XPages OpenLog Logger has demonstrated a lot of my learning, from its inception in XPages Help Application which was my first foray into Java, through to accessing xsp.properties settings, through to plugin development and incorporation in OpenNTF Domino API. I’m also conscious that I’m involved in a number of projects, including ODA which is a huge project. And as part of the OpenNTF Board, I’m also conscious that we’re looking to increase the breadth of involvement in projects. So if you’re interested in helping out with XPages OpenLog Logger, as a developer, tester, for documentation, or for support, please get in touch with me.