Table of Contents
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
Last time I covered using an extension to the Apache Wink servlet class that is used to manage JAX-RS connections via an OSGi servlet. But the OSGi version does not just provide REST servlet access to the NSF. Instead it is a full Vaadin OSGi application. But, as the introduction to the Book of Vaadin says, the UI logic of a Vaadin application also runs as a servlet, so a similar approach can be used to provide a layer to create the NotesThread and wrap the lotus.domino.Session into an org.openntf.domino.Session.
The ODA_VaadinServlet class uses three key methods, very similar to the servlet created for JAX-RS: init(), destroy() and service(). As with that JAX-RS servlet, init starts the ODAPlatform (if it’s not already started), destroy stops it, and service handles the actual request. This method initialises the Notes thread and configures it to use the DominoDefaultApplicationConfig. This is the key difference to the JAX-RS servlet that was created. For JAX-RS, the servlet just provides the current Domino session (by setting the session factory to a new DasCurrentSessionFactory) or a Domino session based on the server ID (which always exists). Because this is a complete web application, the configuration is more flexible and is based on what Daniele Vistalli created for CrossWorlds.
The DominoDefaultApplicationConfig extends an abstract BaseApplicationConfigurator class (which gives some default functionality but cannot be used itself), and that BaseApplicationConfigurator implements the ApplicationConfiguration interface (which defines certain properties and methods that have to be applied by anything using it, as well as fixing names to be used for configuration in the web.xml). This sounds more complicated than it is, but it ensures consistent naming of web.xml configuration for:
- an “application signer” (similar to what is automatically applied for NSF-based design elements)
- a default development username to run as, which means you don’t need to keep logging in during development
- a session variable in which to store the current username (Vaadin has server-based persistence, like XPages)
- methods to determine / set development mode (and on reflection as I write this, the name of the configuration variable for that should also be defined in the ApplicationConfiguration class, so look for that in the future)
Nested within the DominoDefaultApplicationConfig is another class, XSPBasedNamedSessionFactory. The same class is available within CrossWorlds. It allows the developer to use a Java class to create an org.openntf.domino.Session that can allow full access or not and can be based on the application signer or a named Notes name format. (The Notes name format, as we shall see, does not necessarily need to map to an entry in the Domino server, security can be configured to run based on an OU, which is why the setup of the original Key Dates application requires some additional entries in the ACL.) It also applies all the requires switches that are to applied to the Session.
The configure method of the DominoDefaultApplicationConfig is the one that gets called from the servlet and which creates all the sessions used by the application. This reads the “application signer” as defined in the web.xml and then has a more complex statement to work out the “current user”. If the application has already been accessed by the browser session, it uses that; if it’s in developermode and a development username has been set, it uses that and adds the session variable; otherwise it uses the current logged in user name. Finally it creates sessions for current user and application signer, adding them to the Factory. (Currently, if you access the application as Anonymous, if it’s using Domino’s authentication and you subsequently log in, the current user session is not updated, but again look for an amendment to enable that in the future.)
By amending or extending the DominoDefaultApplicationConfig, the web application developer can handle authentication as required, allowing easy switching of users during development, hooking into the Domino server’s in-built authentication, or using authentication within the application that then manages access to the database layer (e.g. OAuth). This may sound unusual and unnerving at first, but it’s no different to logging into a Domino database and using ODBC or JDBC to access a relational database using authority that’s coded into the application. It’s also no different to accessing an application by logging into Twitter or Facebook. Indeed, it’s the same concept as using SessionAsSigner in XPages – you’re using a log in coded by the application developer to access the database layer as someone other than the authenticated user. All are considered perfectly valid approaches for applications in widespread business use.
In the next part I’ll go into a bit more depth on why Vaadin.