Eclipse Scout Release Notes

The latest version of this release is: 24.1.6.

You can see the detailed change log on GitHub.

Coming from an older Scout version? Check out the Migration Guide for instructions on how to obtain the new version and upgrade existing applications.

The demo applications for this version can be found on the features/version/24.1.6 branch of our docs repository on GitHub.

If you just want to play around with them without looking at the source code, you can always use the deployed versions:

Scout 24.1 requires at least the following:

Starting with release 24.1 the Scout Jetty server supports HTTP/2 together with the already existing HTTP/1.1. It is enabled for http and https (TLS) access. Please note that Browsers only use HTTP/2 when using https.

When using https also ALPN is supported which can upgrade an HTTP/1.1 request to an HTTP/2 request if the client supports it.

For Scout 24 and newer enabling HTTP/2 for your application is recommended. Please refer to the documentation on how to enable HTTP/2.

It is now possible to push notifications from the backend directly to the UI running in the browser. With JavaScript, you’ll just subscribe for one or more topics and add a handler that should be called when a notification for that topic is published. To publish a notification, just add any Data Object to the notification registry for a topic.

Learn more about the usage and functionality in the chapter UI Notifications.

We are excited to announce the introduction of enhanced accessibility features in Scout. This improves the overall user experience for individuals with diverse abilities, ensuring Scout applications are more inclusive and user-friendly. Scout now includes comprehensive WAI-ARIA support to provide additional information to assistive technologies. ARIA roles, properties, and states have been implemented to convey the purpose and state of most of Scout’s widgets. Very few complex widgets still lack a comprehensive WAI-ARIA support as these widgets require new concepts of interaction to be completely accessible.

To get familiar with Scouts new accessibility features we recommend using aria.ts as a starting point.

For the form-based login box a basic second-factor support was added. To verify the second factor a second credential verifier must be registered via FormBasedAuthConfig#withSecondFactorVerifier.

Please see the migration guide if you plan to enable 2FA.

The former org.eclipse.scout.dev.jetty.JettyServer (now Application) was so far only used for development environments. With this release it has been improved so that it can be used in a productive environment too. This makes the application server (e.g. Tomcat) obsolete and simplifies the setup because development and production work in the same way.

To start the application, just run the main-method of the Scout Application class (org.eclipse.scout.rt.app.Application) which starts an embedded Jetty server. This is (and was) the preferred way to start the application from the IDE as the IDE takes care of building the class path based on the required maven modules. To start the application without an IDE, the Scout archetype creates two maven modules that can be used for this purpose.

Until now, Scout was based on the Java EE Servlet Specification 4.0, many of our third-party libraries also depend on this specification (e.g. Jetty, HttpServlet API, JMS, JAX-WS, JAX-RS etc). With release 24.1 the Scout framework is moving towards Jakarta EE and is now based on the 5.0 specification. This enables the usage of modern Jakarta EE features and containers.

As part of this Jakarta EE version update all module names and packages have been renamed from Javax to Jakarta (due to legal requirements by Oracle as part of the open source donation of Java EE to the Eclipse Foundation). This made it necessary to change all imports from Java to Jakarta. Please see the migration guide on how to do it for your application.

Together with the Jakarta EE update many third-party libraries could now be updated to the latest release.

Scout now contains a REST endpoint that returns CodeTypes. By default, only CodeTypes marked with @ApiExposed are returned (opt-in). Such CodeTypes can then be loaded by the Scout TypeScript code to be reused in the UI. Please refer to the documentation for more details and examples.

When enabling AutoCheckChildNodes for a Tree or TreeBox widget, the behavior of automatic node checking has changed. The new behavior improves the consistence and represents better the real world requirements. For more details, consider reading the corresponding chapter in the migration guide.