From XPages to Web App Part Seventeen: CrossWorlds

Table of Contents
Introduction
Part One – The Application
Part Two – XPages Advanced 1
Part Three: XPages Advanced Database Separation
Part Four: XPages Advanced Document Wrapper
Part Five: XPages Advanced MVC Controller
Part Six: Use of OpenNTF Domino API
Part Seven: OSGi Application Development Introduction
Part Eight: OSGi JAX-RS REST Access with ODA
Part Nine: OsgiWorlds
Part Ten: Vaadin
Part Eleven: OsgiWorlds Document Wrapper
Part Twelve: Key Date Page
Part Thirteen: Application Structure
Part Fourteen: Calendar View
Part Fifteen: Key Dates Filterable View
Part Sixteen: OSGi JAX-RS REST Access with ODA Revisited
Part Seventeen: CrossWorlds
Glossary

It’s been a while, but the final part of this series will cover CrossWorlds. I pushed up the CrossWorlds project to OpenNTF and completed the documentation at the beginning of May. But first it’s right to position CrossWorlds.

Positioning CrossWorlds

I’m a big fan of CrossWorlds and have used it for a number of applications related to sessions I’ve delivered at user groups and IBM Connect. It allows me to use Vaadin, a framework which I’ve enjoyed learning for my personal development, and develop a web application that runs on my free development Websphere Liberty server.

But it’s never been intended for me as a replacement for XPages, just a complement.

Vaadin is a nice framework with committed support and evangelism from Vaadin themselves, regular releases, best practice webinars and great documentation. But as appealing as it is, it’s still not as rapid for development as XPages. The look and feel is great, but not significantly different from what’s available with Bootstrap.

For personal development, Websphere Liberty server is an interesting option, because the licensing was developed more recently and as a result it is free for development and testing, and even free for limited production use. I’ve been an advocate for some time of a revision of the Domino server licensing, to ensure at least free development use, to bring it more in line with other web servers, even IBM’s own. Websphere Liberty is very easy to set up and administer via an Eclipse plugin that is kept up-to-date. I’ve barely scratched the surface of the configuration, but it certainly looks very powerful. I’ve also not used scheduled processes on Liberty, but again that is possible as a replacement for Domino agents.

But although Websphere Liberty is free for limited production use, it’s not going to replace the XPages runtime.

Why? For the same reason XPages on Bluemix hasn’t taken off: it’s a hard sell to expect customers to pay for a separate web server, when they already have one in their existing Domino server. Yes, Liberty is free for limited production use, but it still needs to be put on a server, it still needs administration etc, and that costs. So I don’t see Websphere Liberty as a replacement for customers’ Domino HTTP servers. And bear in mind that the XPages Bluemix runtime offers virtually nothing over the on premises Domino XPages runtime, whereas Websphere Liberty offers easy Maven integration, modern web applications and Java 8 now.

Java 8 becomes very important with Vaadin, because the latest release of Vaadin – Vaadin 8 – only support Java 8. So bear in mind if you want to dive into Vaadin on Domino, you’re restricted to releases earlier than Vaadin 8. (Currently there’s no confirmed release for Java 8 for use in OSGi applications on Domino.)

Setting Up CrossWorlds

I won’t reproduce the steps for setting up CrossWorlds, it’s on the wiki. There are a number of manual steps, primarily because no one other than IBM are permitted to circulate the Domino-related jar files that CrossWorlds relies on to avoid more standard access. Also, before ICON UK I tried compiling CrossWorlds with the latest OpenNTF Domino API jars. I had some problems getting the jars working with the 3.0.1 naming, but changing the filenames to have “_2.0.1.jar” instead of “_3.0.1.jar” worked fine.

Depending on other focuses over the near future and number of people interested, I may look to make the relevant changes to get the 3.0.1 naming working.

The CrossWorlds Key Dates Application

As I mentioned with the OsgiWorlds version, I did the development primarily on CrossWorlds and then copied the relevant classes etc across to the OsgiWorlds plugin application. That’s because it’s much easier to complete things like setting up the Vaadin application via Maven, building the widgetset, previewing the application etc.

The application itself had very few differences. You’ll see the application is a Maven web application, so there are some incidental differences. But there are few differences in the Java src/main/java package. The org.openntf.osgiworlds package is not required – that just simulates a lot of the functionality CrossWorlds itself offers. There is also a uk.co.intec.keyDatesApp.widgetset package that compiles the widgetset code. It’s possible to avoid that now in CrossWorlds, by telling Maven to use the widgetset via cdn, a recent development from Vaadin’s 7.7.0 codestream.

The other difference is telling the application that it needs to use CrossWorlds. That can be done in different ways, and I’ve used different options more recently. But in this application it’s done via the pom.xml via:

When built, that adds org.openntf.xworlds.dominodeps and org.openntf.xworlds.oda to the classpath. It also routes any calls to the web server via the CrossWorlds filter and weblistener.

So the differences are minimal, but the flexibility great.