Skip to main content
Jump to: navigation, search


Wiki Home

This page shows what you need to know about the new Eclipse Scout 3.8 release shipped with Eclipse Juno.

Release 3.8.0

New Runtime Features

Scout Web UI support based on RAP

Scout Web UI with Rap

Bug 367812

With version 3.8 Scout supports building web applications in addition to the previously supported Swing and SWT desktop technologies. Two scenarios are supported:

  • Migrate existing Scout Desktop applications into the browser with minimal effort.
  • Build new Scout applications that simultaneously run in the browser and as rich applications on the desktop.

This is possible because Eclipse Scout features a clean separation of the application model from the UI Layer (also see this wiki article).

Benefits for the developer: The Scout developer builds the application only once. Everything can be done using existing Scout/Java/Eclipse development know how (no new framework to learn, no HTML, CSS or JavaScript to learn).

Benefits to the end user: The end user of Scout applications experiences an identical look and feel for both the web and the desktop application.

Outlook: The Web UI support is only the next step of the Eclipse Scout "Multi Frontend" strategy. In addition to business application on the desktop and in the web, we are also planning to support mobile devices in the near future.

SVG Field as an additional UI Component

SVG Example with SWT UI

Bug 351223

The new SVG field enhances Eclipse Scout with the ability to display interactive diagrams and graphics that work on both the desktop and the web environment.

Check out the corresponding tutorial.

Busy Handling Improvements

Swing busy
Swing blocking
SWT busy
SWT blocking
RAP busy
RAP blocking

Bug 351223

Parts of the busy handling in the graphical ui layer was refactored in order to have a more responsive and intuitive human-computer interaction.

Busy handling - as all scout parts - is split into the model part in package org.eclipse.scout.rt.client.busy and the GUI part in packages org.eclipse.scout.rt.ui.swing.ext.busy, org.eclipse.scout.rt.ui.swt.busy, org.eclipse.scout.rt.ui.rap.busy, ...

Busy handling in scout is based on eclipse jobs. Whenever a sync ClientJob is running, the scout application is defined as being busy. The IBusyManagerServer supports for registering busy handlers to IClientSessions. Depending on how long jobs last, the IBusyHandler schedules a short running busy indicator or a long running busy indicator. The indicator may be blocking or cancellable or both, depending on the job being run. As a convenience a basic BusyJob can be subclassed do have basic handling.

Default implementaions vary on devices:

Swing shows wait cursor (for short operation) and blocks after that (long operation), showing the used a screen overlay to cancel.

SWT without workbench uses BusyIndicator.showWhile to show busy state. It never shows a blocking state for long operations

SWT Workbench uses BusyIndicator.showWhile to show busy state and to block the workbench on long running operations. The developer may however choose if blocking should block all views or just the views of the affected (scout) application part.

RAP/RWT RAP/RWT in the browser is different from rich client apps. On busy it shows a spinning wheel in the top section of the application, on blocking it decorates the affected views and blocks them.

New NLS (i18n) concept: TextProviderServices

Bug 361816

Before version 3.8 Scout only supported internationalization and localization of applications using the Scout NLS properties files. This restriction has been removed by introducing TextProviderServices. This way the translated text retrieval is also aligned with the icon retrieval which is also managed using IconProviderServices. Using the new TextProviderServices developers can decide to store the translations in a custom container like a database or XML files. Furthermore using TextProviderServices it is very easy to overwrite any translated text in the application (also texts used in Scout itself) using the already well known service ranking.

By default the existing properties files will be supported by a reference implementation of the TextProviderServices.

Label Position Top

Bug 363274

Label Positioning

Scout already provides a mechanism to control the position of the field's label. Until now it has been possible to position the label on the left side of the field (which is the default) or on the field itself. The property to control this behavior is called "LabelPosition" and has been extended for Eclipse Scout 3.8.0 to allow a positioning on top of the field.

Introducing ISession

Bug 377552

In order to read session data like the userId you can use ServerSession.get().getUserId() or ClientSession.get().getUserId(). This works fine if you want to do this inside a server respectively client bundle. Due to the strict dependency rules it is not possible to access these session classes from the shared plugin, because it has no dependency to neither of them. Until now.

Since the server and the client session share a lot of common attributes the ISession interface has been introduced, along with the ISessionService. If you now would like to access the userId from a shared plugin you can use following code:

ISession session = SERVICES.getService(ISessionService.class).getCurrentSession();

But: If you can directly use the ClientSession.get() resp. ServerSession.get() you should still do so to avoid unnecessary osgi service calls.

Enhancement of the Multi Frontend Support

Bug 364449

Session View

As a preparation for the future mobile support coming with 3.9.0, the multi frontend support has been enhanced. It's now possible to get information about the running frontend, on client and server side as well. This is very useful if you need to make some components dependent on a specific frontend, e.g. making fields invisible in the web client but not on the rich client.

The information of the frontend is stored on the session and is called UserAgent. The UserAgent consists of a ui layer and a ui device type. With these two properties you can determine if the GUI of the current session is based on SWT, Swing or Rap and if the device is a desktop, tablet or mobile. To make these checks even more easy some utility functions have been created and are accessible with the UserAgentUtility.

If you are interested in what user agents are really used, the scout session view has been extended to show this information, as you can see in the image.

New SDK Features

Support for Scout Web UI

SDK Support for Rap UI

Bug 362401

The SDK comes with some handy tools to support you in dealing with the new Web UI that comes with Scout 3.8.

Create a RAP Web UI plugin when creating a new Scout Project When creating a new Scout Project you can now choose to also create a RAP web plugin (this feature is only available when using an Eclipse version 3.6 or higher). The SDK then also supports you by creating a RAP target definition. See the "Create a new project" HowTo for more information about the different options.

Add a RAP Web UI plugin to existing Scout Projects If you already have a Scout Project that will be migrated to Scout 3.8 and you want to use the new Web UI in your project, you can add a new Scout RAP Web bundle using the corresponding wizard:

Export web projects as WAR files In previous Scout releases there was the possibility to export a Scout Server plugin using the "Export as WAR file" wizard. This wizard has been replaced by a more powerful version that is also capable to export the RAP Web UI bundle into a WAR file so that you can deploy it easily to an application server. Optionally you now also have the possibility to export the entire application into a single EAR. See the "Deploy to Tomcat" tutorial for more information.

JAX-WS Integration

SDK Support for Jax-WS

Bug 362485

A typical scenario for Eclipse Scout applications in the enterprise environment is to communicate with other applications through web services. With version 3.8 Scout is moving from the previously supported Apache Axis framework to the more modern and active JAX-WS technology.

See this post for a brief introduction to the scope of the JAX-WS integration.

This new feature is supported in the Scout SDK with the following capabilities:

  • Support to create/maintain JAX-WS consumers.
  • Support to create/maintain JAX-WS producers.

Check out the corresponding tutorial to learn more on how to use the new features.

Reorganized Scout Properties View

Bug 366928

SDK Property View

Some objects in the Scout Explorer provide a lot of properties and operations to choose from. In the past the list was without any logical order. E.g. username and password properties did not belong together but were ordered alphabetically in the whole list which made it sometimes harder to find the corresponding fields. Therefore we redesigned the Property View to help the developers to find the right properties and operations more easily.

Group Operations and Properties

Operations and Properties are now grouped in two levels:

  • Separation in methods that are used very often and methods that are used rarely: For some object types certain properties or operations are very common. E.g. for a StringField the maxlength property should always be set. That's why we have defined a section Properties holding the most common ones for each object type and a section Advanced Properties holding all other methods. By default the more important properties are expanded while the advanced sections are collapsed. The same also exists for Operations. If you change the collapsed state, the sections remember your changes as long as your IDE is running.
  • Operations and Properties are grouped into types like Appearance, Layout, Behavior or Data. This helps to jump faster to the desired methods and ensures methods that belong to the same topics are next to each others.

New Layout for the Scout Perspective

SDK Property View

Because the Operations and Properties are now separated (see paragraph above) the Property View does no longer need so much space. This allowed us to reorganize the Scout Perspective. With the new layout developers have more space for the Java Editor where the business logic is implemented. See the Scout Perspective wiki article for a screenshot of the new perspective layout.

The Property View can also adapt to different layouts if you want to customize the Scout Perspective. As more space gets available on the X axis, the Property View re-layouts to make use of the free room:

Help Text for Operations and Properties

Property Documentation

For some Properties or Operations it may not be clear what they do and how/when to use them. To support the developer we improved the help texts that are shown when you hover with the mouse over an Operation or Property.

  • First of all the help texts themselves have been added and improved at various places. It is not complete yet and we will continue to improve this type of help and documentation.
  • Second the hover window showing the help is now capable to follow the links provided in the help.

Feature Technology Checkboxes

Feature Technology Section

Bug 373566

Scout offers various additional functionalities and features that are not all enabled by default after a project has been created. To easier add and remove such features new Technology checkboxes have been added. When selecting the project node in the Scout Explorer, the section on the image "Feature Technology Section" is shown (amongst others) in the Scout Object Properties View.

When the selection of a technology checkbox is changed, a confirmation box is shown to the user. This box lists which resources that would be changed to apply the new selection. The preselected resources can be adapted to the needs of the project. If the dialog is confirmed, the selected resources are modified to add or remove the feature for the chosen resources.

If a technology is added that needs to install some new features from the internet first, a license confirmation dialog is shown upfront. After confirmation the required files are downloaded from the corresponding udpatesites and automatically installed in the local Eclipse instance of the developer.

Management of External Libraries

"New Library Bundle" Wizard

Bug 362895

Scout SDK now allows to easily include and manage external libraries. Developers have the possibility to create own library bundles as

  • independent bundle that can be used by any plugin
  • fragment bundle for a specific host (the library will then only be available to that single host plugin)
  • fragment bundle for system.bundle which then allows every bundle to use the new library

NLS (i18n) Changes

Text Provider Service

Bug 361818 and Bug 354265

The Scout SDK also supports the new TextProviderServices introduced with Scout 3.8 (see here). The support is restricted to the built in support for properties files but can be extended to custom implementations if necessary. The NLS Editor is now capable to also show contents of TextProviderServices. Furthermore the SDK includes support to create new and remove existing TextProviderServices.

NLS Editor

Along with the move to TextProviderServices also other improvements of the NLS SDK have been implemented:

  • The Translation Dialog can now handle multiline texts
  • When creating a new translation, the Translation Dialog offers a generated key based on the text entered
  • The Translation Dialog remembers its last size
  • If creating a new translation out of a wizard: The Translation dialog offers to choose in which TextProviderService the new text should be created
  • Direct edit in the table of the NLS Editor (also supporting multi line)
  • Support to overwrite texts using the Translation Dialog
  • and much more...


The following list shows all bugs which have been fixed for this release. The list also contains all new enhancements.

Release 3.8.1

New Runtime Features

InjectFieldTo Annotation

Bug 381971

A new annotation InjectFieldTo was introduced. It allows adding a field to an existing form without changing it. A field may be added to a container inside the same form or a container in the super classes form fields.

In the following example, the field SalaryField is added to the FirstGroupBox by injection. The order of the fields in FirstGroupBox is determined by the @Order annotation. In this example, SalaryField will appear after NameField:

public class BaseForm {
 public class MainBox extends AbstractGroupBox {
   public class FirstGroupBox extends AbstractGroupBox {
     public class NameField extends AbstractStringField {
public class ExtendedForm extends BaseForm {
 public class SalaryField extends AbstractDoubleField {

The injected fields are currently not displayed in the Scout SDK.

Better support for creating/overriding form data in search and other forms

Bug 381968

This new feature allows to specify how a form creates its form data. This is useful when using search forms that should automatically attach a FormData export to the SearchFilter. Or if a subclass of a SearchForm has an extended FormData and wants to just override that.

Former (frequently used) code inside a form/searchform of the form:

protected void execResetSearchFilter(SearchFilter searchFilter) throws ProcessingException {
  FooSearchFormData data = new FooSearchFormData();

can now be replaced by:

protected AbstractFormData execCreateFormData() throws ProcessingException {
  return new FooSearchFormData();

New extension point to allow customized service initialization

Bug 383083

By default, a service of type org.eclipse.scout.service.AbstractService is initialized with properties in the config.ini file. If the scout application is running inside another RCP application, the config.ini file often cannot be accessed.

Therefore,a new extension point serviceInitializerFactory has been added to to allow the registration of a custom service initializer factory.

The default service initialization behavior stays the same.


The following list shows all bugs which have been fixed for this release. The list also contains all new enhancements.

Release 3.8.2

New Runtime Features

Introducing ClientJobContext / [RAP] Adding support accessing HTTP context properties in Scout model thread

Bug 395576

The ClientJobContext allows to define a context per ClientJob. This context will be passed to every "Sub-ClientJob" (= ClientJob which is started/scheduled by the current running one). The class ClientJobContextThreadLocal is used to access the current client job context, whereon the properties can be get and/or set.

This new feature will be used in Eclipse Scout RAP to add support accessing HTTP context properties (like HTTP request parameters, cookies, header) in Scout model thread. Therefore the AbstractRwtEnvironment contains two new methods (beforeHttpRequest() and afterHttpRequest()) which can be overridden to get notified before and after a HTTP request has been processed by the RAP UI thread.


The following list shows all bugs which have been fixed for this release. The list also contains all new enhancements.

Migration Guidelines

Some features and bugfixes sometimes require a change of the api. If this has been the case for the new release then you'll find behind the link below a guideline how to migrate your scout application to the newest release.

Migration Guidelines for 3.8

Back to the top