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. 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 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 alternative API 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
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.|
|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|