It’s been a little while since the initial release of org.openntf.domino, but as we’re gearing up towards M2 release, it’s worth giving an update of all the work that’s been going on under the hood.
M1 provided the core set of Java code that offered a host of possibilities for looping Collections, avoiding recycle, throwing generic exceptions instead of NotesExceptions and providing the MIMEBean. The jar could also be added to jvm/lib/ext for use in Java agents etc and could be added to WebContentWEB-INFlib for use in Java in XPages. These steps alone significantly sped up development. But for M2 we’ve gone further.
We may be good but we’re still human! Some deep bugs on recycling and MIMEBean have been identified and fixed as members of the team have been using the API more intensively. Resurrection of recycled objects is robust across the run context – XPages, agents etc. Code has been added to identify the run context.
Making Integration into XPages Easier
A plugin project – org.openntf.domino.xsp – has been added to enable the jar to any XPages application on the server as well as adding global objects as entry points (opensession and opendatabase). It still requires the plugin and jar, but details of exporting and deploying from the source code are on the wiki.
If you’re working on a clean environment and want to only use the new API, you can set org.openntf.domino.xsp=godmode in the server’s xsp.properties file so we override session and database.
And the API is now fully integrated into SSJS as well. You’ll need to import the update site into Designer and put the plugin in your <notes>/jvm/lib.ext folder. But then, cast variables to the new classes (e.g. var myView:org.openntf.domino.View = …) and you will get typeahead support for standard and new methods.
Architecture of Class Interfaces and Implementations
This isn’t something you have to worry about, but an interesting change for the geeks. As part of M2 we’ve changed the underlying architecture of the API. Previously we had interfaces in the org.openntf.domino package that mixed both standard and new methods. We’ve changed that so the org.openntf.domino package has the standard methods and all new methods are in parallel interfaces in org.openntf.domino.ext. The classes that implement those interfaces are still in the org.openntf.domino.impl package. (You cast to and import the org.openntf.domino classes, but you’re actually using org.openntf.domino.impl classes, the same as happens when you cast to lotus.domino interfaces but actually use lotus.domino.local classes.)
A logger was added to M1 but wasn’t fully operational. Now it is. It allows high-level logging to server console, full stack trace logging to a file in IBM_TECHNICAL_SUPPORT folder and the whole lot also logged to OpenLog.nsf on the relevant server, if it exists. Longer term I’ll be looking at making the path configurable and other elements, which may or may not be feasible (and may even already be possible!).
You may have seen Nathan’s post last month about him adding transaction logging into the API. This is a huge addition. Most databases have code somewhere where the user clicks a button and business processing kicks off that does something like setting fields on the source document, then updating child documents or related documents in another database. What happens if the code fails on updating all those other documents after successfully updating the source document? You might have coded an exception for that but you the only possible cause may be a connectivity blip, so you didn’t bother coding for an extremely rare occurrence. But it hits exactly when you’re at your busiest!
This is where transaction logging comes in. Now start the transaction, change your fields, update your related documents and then call transaction.commit(). In your error handling call transaction.rollback(). And even better, the transaction logging that Nathan has written is clever enough to only save documents that have changed. I know I’ll be using that.
Graph databases are something I haven’t yet fully got my head around. But Nathan has added an implementation for writing to Graph databases from the API.
We’re also working on a demo database. I posted a YouTube video (embedded below) a few weeks ago. (As an aside, what I mention as a bug in the API was actually developer error – I called the wrong method from SSJS!) The version that will ship with M2 will probably just include the data import routine and comparison of code and some of the new DateTime methods, as well as a performance comparator on looping through documents and setting a DateTime field. We’ll be adding to it to provide SSJS and Java bean samples of the full API along with code comparisons of Java to lotus.domino Java code, and also give sample Java agents.
Resting on Our Laurels?
No way. When you see the release notes for M2 you’ll see there are additional bits that are not yet operational. And I will be hugely surprised if that’s the end of the new functionality.