RAP can be combined with various other technologies and deployed in different setups. Your choice of an application setup depends on the technologies you want to use and the server you need to deploy the application on.
OSGi is a module platform for Java that allows you to organize your application in loosely coupled modules, called bundles, that communicate over a service infrastructure. Eclipse is based on OSGi and provides a lot of bundles that you can re-use in your application. RAP is designed to work with any standard-compliant OSGi implementation. It is often used on Equinox, the OSGi reference implementation by Eclipse, but can also run on other OSGi containers like Apache Felix.
If you don't need or don't like to use OSGi in your web application, you can still use RWT as a normal Java library. This setup is usually referred to as RWT standalone.
OSGi-based applications can be deployed in basically two different ways.
When using RWT stand-alone, the RWT servlet is configured directly in the application's web.xml file.
RWT has two different modes of operation, which can be configured in the application configuration. The default one is fully compatible with JEE, lightweight, and supports transparent session failover in clustering environments (clustering currently requires an RWT standalone setup). This is the recommended operation mode in most cases.
As an alternative, the SWT compatibility mode exactly emulates the SWT threading model. To make this possible, a separate UI thread has to be started for every user session. As a consequence, the code running in the UI thread cannot directly access JEE transaction or security contexts.
The SWT compatibility mode is only required for code that uses SWT's few blocking APIs.
The most obvious case are blocking dialogs (i.e. calling
dialog.open() will suspend code
execution until the dialog is closed by the user, and then return a value).
In JEE mode, code execution will continue after opening the dialog, but any operations reacting
to closing the dialog must be done in a callback.
RAP provides an
that can be used for those dialog callbacks.
This mechanism does not exist in SWT.
Another blocking API in SWT are the Browser-widget's execute and evaluate methods. Their return value can also be obtained with callback implementation, but this may be problematic when developing browser-based custom widgets.
If you're building an application based on the Eclipse 3.x workbench, you need a platform that includes the Equinox OSGi implementation and the extension registry. The application and all contributions, such as views or themes, must be registered as extensions. In this setup, the SWT compatibility mode is enforced.
Here is a comparison of 3 typical RAP-setups:
|RAP with OSGi||RAP with Workbench 3.x||RWT Standalone|
|Summary||Lightweight and flexible, recommended for new applications that do not use Eclipse extensions||For applications using the Workbench 3.x||No OSGi, RWT used as a library in a traditional web app|
|OSGi||Compatible with any OSGi implementation including Equinox||Eclipse Equinox required||No OSGi|
|Deployment||As WAR file in servlet container or directly in OSGi container with embedded server. Direct access to JEE contexts possible with JEE compatibility mode.||As WAR file in servlet container or directly in OSGi container with embedded server.||As WAR file in servlet container. Direct access to JEE contexts possible with JEE compatibility mode. Clustering supported.|
|Configuration||Using the Application Configuration API||Using extension points Branding||Using the Application Configuration API RWT servlet and application configured in web.xml.|
|Entry-point||EntryPoint||EntryPoint or IApplication||EntryPoint|
|Operation Modes||SWT or JEE compatibility mode||SWT compatibility mode enforced||SWT or JEE compatibility mode|
|RCP Compatibility||SWT, JFace||SWT, JFace, Workbench||SWT, JFace|
|Launch from IDE||RAP Launcher||RAP Launcher||RWT Launcher|