Migration guide v3.1.0

Deleting functional methods using a TableFormatterConfig argument

ValidationWriterFactory::create with a TableFormatterConfig argument

The recently added (in powsybl 2.5.0) ValidationWriterFactory::create method which takes a TableFormatterConfig argument has been removed. The deprecated overload of ValidationWriterFactory::create which does not take a TableFormatterConfig argument has been undeprecated and should be reused instead.

Deleting constructors using a TableFormatterConfig argument

After the changes in powsybl configuration, most constructors using a TableFormatterConfig argument have been deleted. You should now use the constructors without TableFormatterConfig and configure table-formatter-config using the implementation of PlatformConfigProvider.

Move AFS-based classes into new modules

Add following module in dependencies if using ActionScript.

<dependency>
  <groupId>com.powsybl</groupId>
  <artifactId>powsybl-action-dsl-afs</artifactId>
  <version>3.1.0</version>
</dependency>

Add following module in dependencies if using ContingencyStore.

<dependency>
  <groupId>com.powsybl</groupId>
  <artifactId>powsybl-contingency-afs</artifactId>
  <version>3.1.0</version>
</dependency>

And the old module powsybl-scripting is replaced by powsybl-scripting-afs and powsybl-scripting-extension.

Change path separator and reading order in powsybl_config_dirs (itools.conf)

In the itools.conf file, several paths can be written in the powsybl_config_dirs parameter, indicating the different paths that can contains configuration files or the logback-itools.xml file. The separator between paths used to be : and is now the File.pathSeparator which depends on your OS: it is : for Unix systems and ; for Windows systems.

Furthermore, the path used in priority to retrieve the logback-itools.xml file is the first written path (furthest into the left) to be consistent with the reading of configuration files.

Groovy version upgrade

Groovy is upgraded to the latest stable: groovy 2.5.8. The following groovy modules are no longer included:

• groovy-ant
• groovy-bsf
• groovy-groovydoc
• groovy-jmx
• groovy-jsr223
• groovy-servlet
• groovy-sql
• groovy-test
• groovy-testng (note that the groovy modules were included before, but their transitive dependencies were not. As a consequence, most of them would not work at runtime)

Evolution of AFS nodes storage within MapDB

The way AFS elements are serialized/deserialized within MapDB has evolved in order to anticipate further modifications of the AFS model. This modification does not maintain compatibility with previous versions of powsybl. Therefore, AFS data stored within MapDB using a previous version of powsybl will no longer be readable with V3.1.0.

Afs EventBus

Afs EventBus is a new notifications system that was added to manage Afs Events (Storage Events & Business Events). Each AppStorage Implementation should have an eventBus to which it sends all its events. The event Bus Interface give us the possibility to add any message broker (kafka, rabbitMQ ...) we want, to be used as an eventBus for our application. (note that ListenableAppSTorage and ForwardingAppStorage are no longer used, we keep them for now to maintain a backward compatibility, use AppStorage instead and use AppSTorage.getEventBus().addListener(AppStorageListener l) to add listeners )

Computation exceptions evolutions

First, the API does not allow multiple causes anymore. They were not correctly handled, in particular in messages and stack trace, not documented, and not used in the framework. It was finally not a good design. Use cases are not obvious : even when there are multiple command executions, usually only one exception is raised.

In the case where the feature was still used, it's possible to :

• have a specific processing to first "merge" the exceptions. The new possibility to add a specific message to the exception may help to give some information in the created computation exception.
• use the addSuppressedException method of the computation exception, in order to keep information about those exceptions and have them reported in the stack trace.

Second, the constructor for wrapping another computation exception and an additional cause has also been removed, since the use case was not clear and the behaviour was not documented. If really needed, an equivalent result can be reached by using the usual builder :

ComputationException wrapper = new ComputationException(computationException, other);

may be replaced by the use of the usual builder:

ComputationExceptionBuilder builder = new ComputationExceptionBuilder(other);
computationException.getOutLogs().forEach((name, log) -> builder.addOutLog(name, log));
...
ComputationException wrapper = builder.build();