Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Scout/NewAndNoteworthy/5.0"

(M5)
(Changes in execOwnerValueChange)
(5 intermediate revisions by 3 users not shown)
Line 139: Line 139:
 
In the client scout application, the implementation of ICodeService is CodeServiceClientProxy. This implementation requires a scout server application and is not suitable in a client-only application. In this case, you might want to register SharedCodeService as additional service with a higher priority in your client plug-in:
 
In the client scout application, the implementation of ICodeService is CodeServiceClientProxy. This implementation requires a scout server application and is not suitable in a client-only application. In this case, you might want to register SharedCodeService as additional service with a higher priority in your client plug-in:
 
<source lang="xml">
 
<source lang="xml">
      <service
+
<service
            factory="org.eclipse.scout.rt.client.services.ClientServiceFactory"
+
      factory="org.eclipse.scout.rt.client.services.ClientServiceFactory"
            class="org.eclipse.scout.rt.shared.services.common.code.SharedCodeService"
+
      class="org.eclipse.scout.rt.shared.services.common.code.SharedCodeService"
            session="<your app>.client.ClientSession">
+
      session="{your app}.client.ClientSession">
      </service>
+
</service>
 
</source>
 
</source>
  
Line 163: Line 163:
  
 
Of course you need also to register your own CodeService implementation it in the plugin.xml file.
 
Of course you need also to register your own CodeService implementation it in the plugin.xml file.
 +
 +
=== IAccessControlService implementation for client-only applications ===
 +
With {{Bug|456476}} we have introduced a new IAccessControlService implementation that can be used in a standalone client scenario.
 +
 +
In a default scout application the 2 old implementations of IAccessControlService stay the same:
 +
* <code>org.eclipse.scout.rt.client.services.common.security.AccessControlServiceClientProxy</code>: relies on a remote service (server side)
 +
* <code>org.eclipse.scout.rt.server.services.common.security.AbstractAccessControlService</code>: has a dependency on server stuff (IClusterNotification, IClientNotification...). Typical server application extends this abstract class and overrides execLoadPermissions().
 +
 +
The new implementation is: <code>org.eclipse.scout.rt.shared.services.common.security.AbstractSharedAccessControlService</code> it corresponds to the old <code>AbstractAccessControlService</code> implementation without the server stuff and this implementation is now located in the shared plugin.
 +
 +
The <code>AbstractAccessControlService</code> is now extending the <code>AbstractSharedAccessControlService</code>.
 +
 +
In the client scout application, the implementation of IAccessControlService is AccessControlServiceClientProxy. This implementation requires a scout server application and is not suitable in a client-only application. For standalone client you can now provide your own ClientAccessControlService extending AbstractSharedAccessControlService:
 +
 +
<source lang="java">
 +
public class ClientAccessControlService extends AbstractSharedAccessControlService {
 +
 +
  @Override
 +
  protected Permissions execLoadPermissions() {
 +
    Permissions permissions = new Permissions();
 +
    permissions.add(new SomeReadPermission());
 +
    permissions.add(new SomeUpdatePermission());
 +
    //...
 +
    return permissions;
 +
  }
 +
}
 +
</source>
 +
 +
Do not forget to register your ClientAccessControlService as additional service with a higher priority than AccessControlServiceClientProxy in your client plug-in:
 +
<source lang="xml">
 +
<service
 +
      factory="org.eclipse.scout.rt.client.services.ClientServiceFactory"
 +
      class="{your app}.client.services.common.security.ClientAccessControlService"
 +
      session="{your app}.client.ClientSession">
 +
</service>
 +
</source>
 +
 +
=== Drop Legacy support for RemoteServiceAccessPermission in AccessControlService ===
 +
<code>RemoteServiceAccessPermission</code> was introduced in June 2011, to grant remote access to a service interface from gui to server. Until mars, when missing, this permission was added to the Permissions object in the default AccessControlService implementation. When it was the case, following warning was logged:
 +
  Legacy security hint: missing any RemoteServiceAccessPermissions in AccessController.
 +
  Please verify the class {your AccessControlService} to include such permissions for accessing services using client proxies.
 +
  Adding default rule to allow services of pattern '*.shared.*'
 +
 +
With mars release (also implemented with {{Bug|456476}}), this legacy support was dropped, meaning that you need to ensure by yourself that this permission is present for each log in user who requires it.
 +
 +
The default AccessControlService created with new scout project already contains this permission:
 +
<source lang="java">
 +
import java.security.AllPermission;
 +
import java.security.Permissions;
 +
 +
import org.eclipse.scout.rt.server.services.common.security.AbstractAccessControlService;
 +
import org.eclipse.scout.rt.shared.security.RemoteServiceAccessPermission;
 +
 +
public class AccessControlService extends AbstractAccessControlService {
 +
 +
  @Override
 +
  protected Permissions execLoadPermissions() {
 +
    Permissions permissions = new Permissions();
 +
    permissions.add(new RemoteServiceAccessPermission("*.shared.*", "*"));
 +
    //TODO fill access control service
 +
    permissions.add(new AllPermission());
 +
    return permissions;
 +
  }
 +
 +
}
 +
</source>
 +
 +
If you had this warning with Luna, you need to modify your AccessControlService for mars, otherwise your users wont be able to connect to the server.
 +
 +
=== New Extension API ===
 +
 +
See the new {{ScoutLink|Concepts|Extensibility}} concept page for details.
  
 
== M6  ==
 
== M6  ==
Line 171: Line 243:
 
*Planned Scout Version: 5.0
 
*Planned Scout Version: 5.0
 
*Release Date: May 08 , 2015 (Build Date: May 06)
 
*Release Date: May 08 , 2015 (Build Date: May 06)
 +
 +
 +
=== Changes in execOwnerValueChange ===
 +
{{Bug|462445}}
 +
 +
To avoid nullchecks in execOwnerValueChange we changes the behavior as follows:
 +
 +
execOwnerValueChanged is only called, if the selection matches the owner type: E.g.
 +
 +
MenuType SingleSelection: only called, if the selection is a single selection
 +
MenuType MultiSelection: only called, if the selection is a multi selection
 +
MenuType MultiSelection: only called, if the selection is a multi selection
 +
 +
This behavior be useful in in most cases. If a callback is required on all selections, a custom implementation is needed.
 +
 +
=== RAP Filechooser Components Moved to regular Scout Feature ===
 +
{{Bug|463111}}
 +
 +
RAP Filechooser was moved to the rap feature. Therefore, the scout rap incubation components could also be moved to the scout RT feature.
 +
 +
org.eclipse.scout.rt.ui.rap.incubator.filechooser has been removed.
  
 
== RC1  ==
 
== RC1  ==

Revision as of 04:53, 10 April 2015

The Scout documentation has been moved to https://eclipsescout.github.io/.

This page shows what you need to know about the new Eclipse Scout 5.0 release shipped with Eclipse Mars (Release: Wednesday, June 24, 2015).


M1

  • Planned Scout Version: 4.1
  • Release Date: August 22, 2014 (Build Date: August 20)

[RAP] Multisession Coockiestore Enabled by default

bug 441555 The multisession coockie store for Scout RAP introduced with Scout 4.0 (Scout/NewAndNoteworthy/4.0#Multisession_Cookiestore) is now enabled by default.

M2

  • Planned Scout Version: 4.1
  • Release Date: October 03, 2014 (Build Date: October 01)

SDK: new entity from the Package Explorer

bug 439334. You can now create Scout entity (Codes, Form Fields, Columns, Menus…) directly from the Package Explorer View. You now have these items directly in the context menu.

ScoutSDK New Entity From Package Explorer.png

M3

  • Planned Scout Version: 4.2
  • Release Date: November 14, 2014 (Build Date: November 12)

[JAX-WS] JAX-WS support for Java 1.8

bug 446478 adds support for Java 1.8 by moving Java runtime-depending code into fragments. Products using org.eclipse.scout.jaxws216 must be extended by one of the following fragments:

 Java 1.6, 1.7 -> org.eclipse.scout.jaxws216.jre16.fragment
 Java 1.8      -> org.eclipse.scout.jaxws216.jre18.fragment

Add the following two properties to your config.ini if you are using an OSGi runtime that is not already defining the execution environment for Java 1.8 (prior Luna release):

 org.osgi.framework.executionenvironment=OSGi/Minimum-1.0,OSGi/Minimum-1.1,OSGi/Minimum-1.2,JRE-1.1,J2SE-1.2,J2SE-1.3,J2SE-1.4,J2SE-1.5,JavaSE-1.6,JavaSE-1.7,JavaSE-1.8
 org.osgi.framework.system.capabilities.extra=osgi.ee; osgi.ee="JavaSE";version:List<Version>="1.8"

Servlet 3.1 support

bug 433736 adds basic support for running Scout with a servlet 3.1. New servlet 3.1 features are used yet.

For an existing project add one of the following plugins to your server product file:

 servlet 2.5-3.0 -> org.eclipse.scout.rt.server.servlet25
 servlet 3.1 -> org.eclipse.scout.rt.server.servlet31

Distinguish between left-click and right-click on table row

bug 443490 It is now possible to distinguish between left and right-clicks on table rows with :

AbstractTable.execRowClick(ITableRow, MouseButton)

SDK: new entity from the Java Editor

You can now create Scout entity (Codes, Form Fields, Columns, Menus…) directly from the Java Editor. You just need to open the Proposal Window (CTRL+Space) and look at the end of the list. If you do not want to scroll down, simply press the “Up-Arrow” Key, you will jump there immediately.

ScoutSDK New Entity From Java Proposal.png

M4

  • Planned Scout Version: 4.2
  • Release Date: December 19, 2014 (Build Date: December 17)

Empty Checkboxes

bug 416043 Default behaviour for checkbox changed (AbstractBooleanField and AbstractCheckBox): A boolean field is considered empty if unchecked. Previously it was considered empty, if it did not contain any value.

ServerJobService

bug 448572 It is now possible to customize server jobs. ServerJob creation in Scout is now always done with IServerJobService.createJobFactory.

The server session class could previously be configured in some services (jaxws,clustersync,offlinedispatcher...) or was retrieved by naming convention. These configurations have been consolidated and use now the configuration in org.eclipse.scout.rt.server.ServerJobService#serverSessionClassName. Old properties are still read for legacy support. Please server config.ini to

org.eclipse.scout.rt.server.ServerJobService#serverSessionClassName=<fully qualified ServerSession name>

e.g.

org.eclipse.scout.rt.server.ServerJobService#serverSessionClassName=org.eclipsescout.helloworld.server.ServerSession

Exceptions in Pages

bug 452266 Exceptions in AbstractPage#execPageActivated and AbstractPage#execPageDeactivated are now also handled by IExceptionHandlerService.

MailUtility Cleanup

bug 454416 MailUtility was moved to the subpackage mail. Methods were cleaned and signatures were changed from array ([]) to java.util.List.

Deprecate execLoadTableData() in table pages

bug 444210 execLoadTableData() in The Scout documentation has been moved to https://eclipsescout.github.io/. is now deprecated. The recommended way is to update to The Scout documentation has been moved to https://eclipsescout.github.io/. for your table and to use importPageData(..) in the execLoadData(SearchFilter) method.

If you do not want switch to the TablePageData pattern immediately, a migration path might be to use the new importTableData(Object[][]) method in the execLoadData(SearchFilter) method. Code like this:

@Override
protected Object[][] execLoadTableData(SearchFilter filter) throws ProcessingException {
  PersonSearchFormData searchFormData;
  //initialize searchFormData depending on the filter
  return SERVICES.getService(IStandardOutlineService.class).getPersonTableData(searchFormData);
}

Needs to be updated to something like this:

@Override
protected void execLoadData(SearchFilter filter) throws ProcessingException {
  PersonSearchFormData searchFormData;
  //initialize searchFormData depending on the filter
  importTableData(SERVICES.getService(IStandardOutlineService.class).getPersonTableData(searchFormData));
}

New system property for external configuration file

bug 455222 Scout supports the specification of an external configuration file in the system properties. When loading the configuration Scout is retrieving the value of the system property external.configuration.file. If the value is set Scout will add the specified path to the path list of the external configurations to be loaded.

This allows specifying the path of the config.ini in the pom.xml so that the configuration can be used with Maven Tycho. (This is a workaround for the Tycho Bug bug 356193)

MultiClientSessionCookieStore with better synchronization and fixed potential memory leak

bug 455184 The MultiClientSessionCookieStore introduced in the 4.0 (Luna) release used strong references to client sessions. This resulted in a memory leak unless the sessionStopped(IClientSession) method was called. The new implementation now uses weak references to the client sessions to avoid this.

Additionally, the internal synchronization of the MultiClientSessionCookieStore was improved to be more granular.

M5

  • Planned Scout Version: 5.0
  • Release Date: February 06, 2015 (Build Date: February 04)

Change the default for TableData

With bug 455282 we have changed the default The Scout documentation has been moved to https://eclipsescout.github.io/. from Array based TableData to Bean based TableData.

Without changing anything, if you use AbstractTableField directly in your form, your FormData will be updated from array based to bean based. For the migration, you will have two possibilities:

  • 1. Updating your logic using the formData (in the server probably) to work with the new formData.
  • or 2. Configure your tableFields in your form to use array based table data (In this case the generated FormData will be the same as in luna). The easiest way to do so is to extend from the new class: AbstractArrayTableField instead of AbstractTableField.

For the long term, solution 1 is the preferred one. Array based table-data will disapear on the long term.

The type of the generated TableData is only a question of configuration of the @FormData annotation. You are free to configure your table field templates as you need.

ICodeService implementation for client-only applications

With bug 444213 we have introduced a new ICodeService implementation that can be used in a standalone client scenario.

By default the 2 old implementations of ICodeService stay the same:

  • org.eclipse.scout.rt.client.services.common.code.CodeServiceClientProxy: relies on a remote service (server side)
  • org.eclipse.scout.rt.server.services.common.code.CodeService : has dependencies on server stuff (IClusterNotification, IClientNotification...)

The new implementation is: org.eclipse.scout.rt.shared.services.common.code.SharedCodeService it corresponds to the old CodeService implementation without the server stuff and this implementation is now located in the shared plugin.

The (Server)CodeService is now extending the SharedCodeService.

In the client scout application, the implementation of ICodeService is CodeServiceClientProxy. This implementation requires a scout server application and is not suitable in a client-only application. In this case, you might want to register SharedCodeService as additional service with a higher priority in your client plug-in:

<service
      factory="org.eclipse.scout.rt.client.services.ClientServiceFactory"
      class="org.eclipse.scout.rt.shared.services.common.code.SharedCodeService"
      session="{your app}.client.ClientSession">
</service>

If you need some information contained in your client (like the current partition id), you can create your own implementation (ClientCodeService) extending SharedCodeSerivce:

public class ClientCodeService extends SharedCodeService {
 
  @Override
  protected Long provideCurrentPartitionId() {
    Map<String, Object> sharedVariableMap = ClientSession.get().getSharedVariableMap();
    if (sharedVariableMap.containsKey(ICodeType.PROP_PARTITION_ID)) {
      return (Long) sharedVariableMap.get(ICodeType.PROP_PARTITION_ID);
    }
    return super.provideCurrentPartitionId();
  }
}

Of course you need also to register your own CodeService implementation it in the plugin.xml file.

IAccessControlService implementation for client-only applications

With bug 456476 we have introduced a new IAccessControlService implementation that can be used in a standalone client scenario.

In a default scout application the 2 old implementations of IAccessControlService stay the same:

  • org.eclipse.scout.rt.client.services.common.security.AccessControlServiceClientProxy: relies on a remote service (server side)
  • org.eclipse.scout.rt.server.services.common.security.AbstractAccessControlService: has a dependency on server stuff (IClusterNotification, IClientNotification...). Typical server application extends this abstract class and overrides execLoadPermissions().

The new implementation is: org.eclipse.scout.rt.shared.services.common.security.AbstractSharedAccessControlService it corresponds to the old AbstractAccessControlService implementation without the server stuff and this implementation is now located in the shared plugin.

The AbstractAccessControlService is now extending the AbstractSharedAccessControlService.

In the client scout application, the implementation of IAccessControlService is AccessControlServiceClientProxy. This implementation requires a scout server application and is not suitable in a client-only application. For standalone client you can now provide your own ClientAccessControlService extending AbstractSharedAccessControlService:

public class ClientAccessControlService extends AbstractSharedAccessControlService {
 
  @Override
  protected Permissions execLoadPermissions() {
    Permissions permissions = new Permissions();
    permissions.add(new SomeReadPermission());
    permissions.add(new SomeUpdatePermission());
    //...
    return permissions;
  }
}

Do not forget to register your ClientAccessControlService as additional service with a higher priority than AccessControlServiceClientProxy in your client plug-in:

<service
      factory="org.eclipse.scout.rt.client.services.ClientServiceFactory"
      class="{your app}.client.services.common.security.ClientAccessControlService"
      session="{your app}.client.ClientSession">
</service>

Drop Legacy support for RemoteServiceAccessPermission in AccessControlService

RemoteServiceAccessPermission was introduced in June 2011, to grant remote access to a service interface from gui to server. Until mars, when missing, this permission was added to the Permissions object in the default AccessControlService implementation. When it was the case, following warning was logged:

  Legacy security hint: missing any RemoteServiceAccessPermissions in AccessController. 
  Please verify the class {your AccessControlService} to include such permissions for accessing services using client proxies. 
  Adding default rule to allow services of pattern '*.shared.*'

With mars release (also implemented with bug 456476), this legacy support was dropped, meaning that you need to ensure by yourself that this permission is present for each log in user who requires it.

The default AccessControlService created with new scout project already contains this permission:

import java.security.AllPermission;
import java.security.Permissions;
 
import org.eclipse.scout.rt.server.services.common.security.AbstractAccessControlService;
import org.eclipse.scout.rt.shared.security.RemoteServiceAccessPermission;
 
public class AccessControlService extends AbstractAccessControlService {
 
  @Override
  protected Permissions execLoadPermissions() {
    Permissions permissions = new Permissions();
    permissions.add(new RemoteServiceAccessPermission("*.shared.*", "*"));
    //TODO fill access control service
    permissions.add(new AllPermission());
    return permissions;
  }
 
}

If you had this warning with Luna, you need to modify your AccessControlService for mars, otherwise your users wont be able to connect to the server.

New Extension API

See the new The Scout documentation has been moved to https://eclipsescout.github.io/. concept page for details.

M6

  • Planned Scout Version: 5.0
  • Release Date: March 27, 2015 (Build Date: March 25)

M7

  • Planned Scout Version: 5.0
  • Release Date: May 08 , 2015 (Build Date: May 06)


Changes in execOwnerValueChange

bug 462445

To avoid nullchecks in execOwnerValueChange we changes the behavior as follows:

execOwnerValueChanged is only called, if the selection matches the owner type: E.g.

MenuType SingleSelection: only called, if the selection is a single selection MenuType MultiSelection: only called, if the selection is a multi selection MenuType MultiSelection: only called, if the selection is a multi selection

This behavior be useful in in most cases. If a callback is required on all selections, a custom implementation is needed.

RAP Filechooser Components Moved to regular Scout Feature

bug 463111

RAP Filechooser was moved to the rap feature. Therefore, the scout rap incubation components could also be moved to the scout RT feature.

org.eclipse.scout.rt.ui.rap.incubator.filechooser has been removed.

RC1

  • Planned Scout Version: 5.0
  • Release Date: May 22, 2015 (Build Date: May 20)

RC2

  • Planned Scout Version: 5.0
  • Release Date: May 29, 2015 (Build Date: May 27)

RC3

  • Planned Scout Version: 5.0
  • Release Date: June 05, 2015 (Build Date: June 03)

RC4

  • Planned Scout Version: 5.0
  • Release Date: June 12, 2015 (Build Date: June 10)

Back to the top