Twitter Logo Follow us on Twitter
Project Information About this project

RAP 2.0 M3 - New and Noteworthy

Here's a list of the most noteworthy things in the RAP 2.0 M3 milestone build which is available for download since November 16, 2012.

New Web Client Services

Based on the new Client API that has been introduced in M2, some existing API has been transformed into client services.

JavaScriptExecutor service

This service can be used to execute a piece of JavaScript code on the client. It replaces the internal class JSExecutor. Example:

JavaScriptExecutor executor = RWT.getClient().getService( JavaScriptExecutor.class );
executor.execute( "alert( \"Hello World!\" );" );

BrowserHistory service

Allows to use the browser's history for navigating within the application. This replaces the IBrowserHistory interface and RWT.getBrowserHistory(). Example:

BrowserHistory history = RWT.getClient().getService( BrowserHistory.class );
history.createEntry( "main", "Main View" );

ExitConfirmation service

Used to configure the confirmation dialog that can be shown before the user leaves the application. It is no longer possible to do this in a branding. Example:

ExitConfirmation confirmation = RWT.getClient().getService( ExitConfirmation.class );
confirmation.setMessage( "Where do you think you're going?!" );

New Event System

The event system in RWT has been completely re-written. For historical reasons, the implementation was based on typed events like SelectionEvent with untyped events built on top. This “inverted” design caused several problems that are now fixed (see bug 334028).

With the new implementation, the design follows the structure of SWT. Typed and untyped events work exactly like in the original. This also allowed us to provide some missing API: All typed events have a time field that reflects the time an event has occurred. MouseEvent has a field count that allows to distinguish single and double clicks. Custom widgets can now use the protected method Widget #removeListener( int, SWTEventListener ).

Server Push (aka UICallBack) Improvements

The UICallBack is RAP's mechanism to enable “push” UI updates to the client. The implementation of this mechanism has been simplified and made more robust (see bug 382613). As an effect of this change, the client will now be notified of a session timeout when the UICallBack is enabled (bug 388280).

Resource Manager Rework

The resource manager (IResourceManager) is used to register static resources like images or JavaScript files in RAP applications. But it had also been equipped with additional functionality like JavaScript compression, encoding conversion, etc. These additional concerns made the resource manager complicated to use and to maintain. We reduced the interface to the purpose of registering resources and simplified the implementation. In particular, the resource manager

  • does not minify JavaScript anymore. We removed the YUI Compressor from RWT because it turned out to be too resource-intensive. All JavaScript resources used by RWT are minified at build time and we'd recommend that custom component developers also minify their JavaScript files with a tool of their choice. There are many free tools out there, such as YUI Compressor, Google Closure Compiler, or JSMin.
  • does not take the encoding of a resource into account anymore. It now registers the bytes from a given input stream as is. If you used to register text files with a charset other than UTF-8, you should make sure that your client code reads the resources with the correct charset.
  • does not add version hashes to file names anymore. This has been done to avoid caching problems. We think that these issues are not that common anymore than they were in IE6 times. If there is a need to add version hashes to URLs, applications can simply add a URL parameter like "?nocache=4711" when requesting the resource.

Moreover, the resource manager does not close input streams anymore after registering a resource, as it did in 1.5 (bug 347615). Please double check that you're closing your input streams correctly.

Affected API

The ResourceManager API has been reduced to the necessary minimum. If you've used a method that has been removed, the advice above should help you to adapt your code to use one of the remaining methods instead.

The IResource interface is now only used in the extension point org.eclipse.rap.ui.resources and has therefore been moved to the bundle org.eclipse.rap.ui.workbench. The methods getCharset() and getOptions() have been removed because of the changes described above.

For resources that are registered in an ApplicationConfiguration, the method Application.addResource(…) now accepts a ResourceLoader instead of IResource.

Dropped Support for entrypoints by name

Until now, entrypoints could be registered with a name in an entrypoint extension. Those entrypoints had been available at a URL with the default servlet name “rap” and a URL parameter “startup” pointing to this name, such as:

http://hostname/webapp/rap?startup=foo   (OBSOLETE)

Since RAP 1.5, entrypoints can be registered by path. For example, an entrypoint that is registered with the path /foo will be available at:


The old approach had a number of drawbacks. It lead to odd URLs, that follow a convention you had to know. A typo in the entrypoint name resulted in an HTTP 500 instead of a 404. Even if you mapped a custom path to the entrypoint in a branding, the “rap?startup=” URL would still work.

Thus we decided to remove the support for entrypoints by name completely in RAP 2.0. From now on, entrypoints can only be registered by path. The default servlet name “rap” and the parameter “startup” are not supported anymore.


In your entrypoint extensions, use the attibute path to specify the URL path for the entrypoint. The old attribute parameter is not supported anymore. Here's an example plugin.xml snippet:

<extension point="org.eclipse.rap.ui.entrypoint">
  <entrypoint id="example.entrypoint"
      path="/example" />


This change also affects applications that use IApplication as entrypoint. To make an application available at a certain path, add a parameter named path to your extension:

<extension id="" point="org.eclipse.core.runtime.applications">
  <application thread="main" cardinality="singleton-global" visible="true">
    <run class="example.Application">
      <parameter name="path" value="/example" />


Entrypoint mapping

Since entrypoints are now always registered by path, there is no need for an entrypoint-to-path mapping in a branding anymore. Therefore, we removed the attributes servletName, defaultEntrypointId, and the element associatedEntrypoints from the branding extension point. A branding can now be bound to an entrypoint by setting the new attribute brandingId.

<extension point="org.eclipse.rap.ui.entrypoint">
  <entrypoint id="example.entrypoint"
      brandingId="example.branding" />

To bind a branding to an IApplication, add a parameter brandingId to the application extension point.

<extension id="" point="org.eclipse.core.runtime.applications">
  <application thread="main" cardinality="singleton-global" visible="true">
    <run class="example.Application">
      <parameter name="path" value="/mail" />
      <parameter name="brandingId" value="example.branding /">

Exit confirmation

For exit confirmations, the new client service ExitConfirmation should be used as explained above. The attribute exitConfirmationClass is no longer supported by the branding extension point.

Branding API removed from RWT

With these changes, we also removed the branding API from RWT, namely the classes AbstractBranding and Header. We don't expect that anyone was using these classes. In plain RWT applications, entrypoint properties can be used for branding.


This list shows all bugs that have been fixed for this milestone build.

Previous Builds

The above features are just the ones that are new since the last milestone build. Summaries for earlier builds: