With the move to RAP 3.0, we clean up deprecated APIs and introduce replacements for API that is no longer supported.
All API that had already been deprecated back in RAP 2.0 has now been removed. The replacements listed below existed in RAP 2.0 already. For a detailed explanation of these changes, see the RAP 2.0 Migration Guide.
Graphics
removed without substitutionIApplicationStore
replaced by ApplicationContext
IControlThemeAdapter
replaced by ControlThemeAdapter
IEntryPoint
/ IEntryPointFactory
replaced by EntryPoint
/ EntryPointFactory
IResourceManager
replaced by ResourceManager
IServiceHandler
replaced by ServiceHandler
IServiceManager
replaced by ServiceManager
IServiceStore
removed without substitutionISessionStore
replaced by UISession
ISettingStore
/ ISettingStoreFactory
replaced by SettingStore
/ SettingStoreFactory
SessionSingletonBase
replaced by SingletonUtil
UICallBack
replaced by ServerPushSession
The package org.eclipse.rap.rwt.lifecycle has been removed. This package contained API related to lifecycle phases and lifecycle adapters (LCAs), concepts which we consider internals of the framework. These internals are subject to change and should not be accessed by application code. Mostly custom widgets that predate RAP 2.0 and custom PhaseListeners will be affected.
Custom widgets used lifecycle adapters (LCAs) to communicate with their remote counterparts.
In RAP 2.0, the Remote API has been introduced as a replacement for LCAs
(see the package org.eclipse.rap.rwt.remote, especially RemoteObject
).
Custom widgets should use this new API now.
The following classes have been removed without a replacement:
WidgetLifeCycleAdapter
AbstractWidgetLCA
WidgetLCAUtil
and ControlLCAUtil
IWidgetAdapter
and WidgetAdapter
Most of the methods in this helper class were related to LCAs. Two methods that are still
relevant have been moved to a new, trimmed down version of WidgetUtil
in the
package org.eclipse.rap.rwt.widgets
:
WidgetUtil.getId( Widget )
WidgetUtil.registerDataKeys( String... keys )
The request processing of the RAP server is split into different Phases. As an application developer, you don't have to care about those phases anymore. The phase model is going to change in future versions of RAP.
If you've used Fixture.fakePhase( PhaseId.PROCESS_ACTION );
in your unit tests,
you can use the new public JUnit rule instead (see below).
Phase listeners are a means of executing custom code during the processing of a request. Since this interface exposes internals of the framework (such asPhaseId so called lifecycle phases), it has been removed in this release. We did not provide a replacement so far, as we couldn't find a reasonable use case anymore. If you still need this hook, you can continue to use the PhaseListener from the internal package in RAP 3.0. However, please let us know so we can discuss alternatives before phase listeners are removed completely.
PhaseEvent
PhaseId
PhaseListener
ProcessActionRunner
ILifeCycle
RWT.getLifeCycle()
Application.addPhaseListener( PhaseListener )
With the support for themeable border edges, we had to replace the method
getBorderWidth(Control)
in ControlThemeAdapter
with getBorder(Control)
.
This class is only relevant for custom widget developers.
In the interface org.eclipse.rap.rwt.application.Application
,
we've fixed a typo in the method name addThemableWidget()
.
This method has been renamed to addThemeableWidget()
.
If you used the internal rap test fixture in your unit tests, there's now a public replacement
in the bundle org.eclipse.rap.rwt.testfixture.
Instead of calling Fixture.setUp()
and Fixture.tearDown()
,
you now only need to include the following line in your test cases.
This will simulate a new test context for every test method.
There's also no need to fake the PROCESS_ACTION phase anymore.
@Rule
public TestContext context = new TestContext();
The class Fixture
and all its companions have been moved to the internal package
org.eclipse.rap.rwt.testfixture.internal.
The bundles had once been created to execute PDE tests with RAP. As we haven't seem much interest in this approach, these projects are not actively maintained anymore. They still depend on JUnit 3. That's why we don't include them in RAP 3.0 anymore.