Adventures with vert.x, 64Bit and the IBM Notes client

The rising star of web servers currently is node.js, not at least due to the cambrian explosion in available packages with a clever package management system and the fact that " Any application that can be written in JavaScript, will eventually be written in JavaScript" (according to Jeff Atwood).
When talking to IBM Domino or IBM Connections node.js allows for very elegant solutions using the REST APIs. However when talking to a IBM Notes client, it can't do much since an external program needs to be Java or COM, the later on Windows only.
I really like node.js event driven programming model, so I looked around. In result I found vert.x, which does to the JVM, what node.js does to Google's v8 JS runtime. Wikipedia decribes vert.x as " a polyglot event-driven application framework that runs on the Java Virtual Machine ". Vert.x is now an Eclipse project.
While node.js is tied to JavaScript, vert.x is polyglot and supports Java, JavaScript, CoffeeScript, Ruby, Python and Groovy with Scala and others under consideration.
Task one I tried to complete: run a verticle that simply displays the current local Notes user name. Of course exploring new stuff comes with its own set of surprises. As time of writing the stable version of vert.x is 2.1.1 with version 3.0 under heavy development.
Following the discussion, version 3.0 would introduce quite some changes in the API, so I decided to be brave and use the 3.0 development branch to explore.
The fun part: there is not much documentation for 3.x yet, while version 2.x is well covered in various books and the online documentation.
vert.x 3.x is at the edge of new and uses Lamda expressions, so just using Notes' Java 6 runtime was not an option. The Java 8 JRE was due to be installed. Luckily that is rather easy.
The class is rather simple, even after including Notes.jar, getting it to run (more below) not so much:

package com.notessensei.vertx.notes;

import io.vertx.core.Handler;
import io.vertx.core.Vertx;
import io.vertx.core.http.HttpServerOptions;
import io.vertx.core.http.HttpServerRequest;
import io.vertx.core.http.HttpServerResponse;

import java.io.IOException;

import lotus.domino.NotesFactory;
import lotus.domino.NotesThread;
import lotus.domino.Session;

public class Demo {
 public static void main(String[] args) throws IOException {
  new Demo();
  int quit = 0;
  while (quit != 113) { // Wait for a keypress
   System.out.println("Press q<Enter> to stop the verticle");
   quit = System.in.read();
  }
  System.out.println("Veticle terminated");
  System.exit(0);
 }

 private static final int listenport = 8111;

 public Demo() {
  Vertx vertx = Vertx.factory.createVertx();
  HttpServerOptions options = new HttpServerOptions();
  options.setPort(listenport);
  vertx.createHttpServer(options)
    .requestHandler(new Handler<HttpServerRequest>() {
     public void handle(HttpServerRequest req) {
      HttpServerResponse resp = req.response();
      resp.headers().set("Content-Type",
        "text/plain; charset=UTF-8");
      StringBuilder b = new StringBuilder();
      try {
       NotesThread.sinitThread();
       Session s = NotesFactory.createSession();
       b.append(s.getUserName());
       NotesThread.stermThread();
      } catch (Exception e) {
       e.printStackTrace();
       b.append(e.getMessage());
      }
      resp.writeStringAndEnd(b.toString());
     }
    }).listen();
 }
}

Starting the verticle looked promising, but once I pointed my browser to the fun began.
The first error I had to deal with was: SEVERE: java.lang.UnsatisfiedLinkError: no lsxbe in java.library.path That was actually nothing new, to fix these 2 environment parameters needed to be set:
DYLD_LIBRARY_PATH=/opt/ibm/notes and LD_LIBRARY_PATH=/opt/ibm/notes.
This can be done in the run configuration in Eclipse or in the script that later will run the ready program. After adding them I get the next error: SEVERE: java.lang.UnsatisfiedLinkError: /opt/ibm/notes/liblsxbe.so: /opt/ibm/notes/liblsxbe.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) Now I do like elfs, just not the wrong type. The error actually says: the native library is 32 Bit, the JVM is 64, this ain't working. The Notes client on all platforms Checking with Jesse I learned, that there is a switch to tell Java to do 32 Bit: -d32, while NTF asserted using server code you could run pure 64Bit. Trying the -d32, I was greeted with yet another error: Error: This Java instance does not support a 32-bit JVM. Please install the desired version. That only seems to work on Windows. So, downloaded the 32Bit version, expanded into a directory in /opt and created a new JVM configuration in Eclipse pointing to it. And horray! It works. So now I have a local web server that can talk to my local Notes client and I can read data from all the NSF I have access to.
There are a few moving parts. For Java projects I highly recommend using Apache Maven since it can take care of getting all the needed libraries for you. My maven pom.xml file for this project looks like this:

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.notessensei.vertx</groupId>
  <artifactId>com.notessensei.vertx.notes</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <name>IBM Notes 9.0 vert.x 3.0 client</name>
  <description>Local web</description>
  <dependencies>
    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-core</artifactId>
      <version>3.0.0-SNAPSHOT</version>
    </dependency>
  </dependencies>
</project>

The classpath for the project:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
 <classpathentry kind="src" output="target/classes" path="src/main/java">
  <attributes>
   <attribute name="optional" value="true"/>
   <attribute name="maven.pomderived" value="true"/>
  </attributes>
 </classpathentry>
 <classpathentry excluding="**" kind="src" output="target/classes" path="src/main/resources">
  <attributes>
   <attribute name="maven.pomderived" value="true"/>
  </attributes>
 </classpathentry>
 <classpathentry kind="src" output="target/test-classes" path="src/test/java">
  <attributes>
   <attribute name="optional" value="true"/>
   <attribute name="maven.pomderived" value="true"/>
  </attributes>
 </classpathentry>
 <classpathentry excluding="**" kind="src" output="target/test-classes" path="src/test/resources">
  <attributes>
   <attribute name="maven.pomderived" value="true"/>
  </attributes>
 </classpathentry>
 <classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
  <attributes>
   <attribute name="maven.pomderived" value="true"/>
  </attributes>
 </classpathentry>
 <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
 <classpathentry kind="lib" path="/opt/ibm/notes/jvm/lib/ext/Notes.jar"/>
 <classpathentry kind="output" path="target/classes"/>
</classpath>

Next stop: add the OpenNTF Domino API and then have a look what havoc I can wreck with that environment\*


Update: Attributed Jesse for the -d32 switch and Nathan for the 64Bit tests
No Domino servers have been harmed when running this code.