Migration from LSPS 2.7 to LSPS 3.0

Topics related to migration of applications to newer releases of LSPS.
Radovan Cervenka
 
Posts: 48
Joined: Mon Feb 27, 2012 2:47 pm

Migration from LSPS 2.7 to LSPS 3.0

Thu Nov 05, 2015 2:48 pm

To migrate application from LSPS 2.7 to LSPS 3.0, the following changes should be taken into account:

  • Database
    To migrate to 3.0 database, run the migration script in lsps-runtime/db-migration/migrate.bat or lsps-runtime/db-migration/migrate.sh with the required parameters. See this documentation for details.

    In addition, the migration tool should be launched with the parameter initialVersion with value 2.7.0.010. For example:
    Code: Select all
    migrate databaseUrl:jdbc:h2:tcp://localhost/h2/h2;MVCC=TRUE;LOCK_TIMEOUT=60000 user:lsps password:lsps initialVersion:2.7.0.010

  • Synchronous submit of Todo without serialization
    The signature of methods com.whitestein.lsps.human.task.UserTask.processReply(TaskContext, Object) and com.whitestein.lsps.human.task.BaseTodoTask.processReply(TaskContext, Object) has changed. In LSPS 2.7 it was processReply(TaskContext, Serializable). If your custom LSPS Java application overrides these methods, adapt the signature in your Java code.

  • Ban use of iterators outside tables
    If a variable is used as a Table, Repeater, or TreeTable iterator, it can no longer be used outside of its scope, that is, its parent Table, Repeater, or TreeTable component. Also, nested Tables (Repeaters, TreeTables) can no longer use the same variable as their iterator. Make sure your form components use different iterator variables.

  • Change assignments for gateways - Server
    The appropriate model change is done automatically. No manual change in model is needed.

  • Listener executes closures in different contexts
    Change in the GUI behavior; no migration available (used rarely).

  • "Lazy" instantiation of Vaadin components
    Under certain circumstances, closures defined in listeners were executed in a wrong context since they attempted to execute in uninitialized context. No migration steps are available; make sure to test your application forms thoroughly.

  • Added reserved keyword to expression language
    The following keywords were added to the Expression Language: protected, this, super, final, abstract, return. If the model uses such identifiers in names of variables, parameters, functions etc., escape the usage. For example, if there is a variable this, escape it in expressions as 'this'.

  • Optional function parameters
    The signature of method com.whitestein.lsps.lang.operation.Operation.execute(Interpreter, Expression, List<Expression>, boolean, InterpreterStackTrace) has changed. In LSPS 2.7 it was com.whitestein.lsps.lang.operation.Operation.execute(Interpreter, Expression, List<Expression>, InterpreterStackTrace). If the custom LSPS Java application provides an implementation of Operation interface (it is not expected), the Java code has to be fixed.

  • Remove DelegatingOperation
    The helper class com.whitestein.lsps.lang.operation.DelegatingOperation has been removed without any substitute. If the custom Java application uses this class (it is not expected), the Java code has to be fixed.


Return to Migration

Who is online

Users browsing this forum: No registered users and 1 guest