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:

http://hostname/webapp/foo

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.

IEntryPoint

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:

Branding

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.

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.

Bugfixes

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: