This document describes the steps needed to upgrade the edoras one application to 1.5.0.S120.1.
Please stop the edoras one server, perform all upgrade steps described below and then restart the server again at the end.
Announcement: Query API behavior change
The current behaviour for executing queries based on predicate combinations is not intuitive, and may return unexpected results. The reason for this is that currently the separate parts of a combined predicate are evaluated separately instead of being combined to check a specific variable. As an example, the following predicate:
Task.VARIABLE.name().eq("var").and(Task.VARIABLE.stringValue().eq("foo")
is currently evaluated as the following pseudo-SQL:
select workObject where ((select where variableName = 'var') and (select where variableValue = 'foo'))
From the original predicate, this would seem to return all work objects that have a single variable with name 'var' and value 'foo'. That is not the case, however. In fact it returns all work objects that have a variable with name 'var' and a separate variable with the value 'foo' (which may or may not have the name 'var').
The change to the query API means that such predicates will be combined into a single variable query:
select workObject where (select where variableName = 'var' and variableValue = 'foo')
The existing com.edorasware.commons.core.query.entity.MultipleNamedValuePredicate
class
can be used to combine predicates that should be applied to separate variables.
Any predicates affected by this change will probably return different results because they were previously returning unexpected matches, but it is also possible that some applications rely on the current 'incorrect' behaviour. For that reason we are announcing this change now so that there is time to review existing predicates before the change is rolled out.
The changes that will be introduced in release 1.5.0.S122 are as follows:
-
combined predicates using normal and() and or() and not explicitly separated using
MultipleNamedValuePredicate
will merged to a single query. -
additional predicates will be provided for some use cases that cannot easily be expressed at the moment (e.g. isNotNull()).
Projects can be affected if they use the query API with combined variable queries (as in the above example), including the use of custom REST endpoints for querying items.
IF your project is affected by the announced change, list the process instance definitions affected and upgrade these when you upgrade to the version containing the announced changes.
Please address cases where you believe it is not possible to upgrade to edorasware support in advance.
Email sending does not iterate through the list of recipients
Starting with 1.5.0.S120.1
, a single email is sent to all recipients in a Send mail task.
The default MailService
implementation does not iterate through all mail recipients, mimicking the behavior of email clients (rather than that of bulk mailers).
The first recipient can be accessed in the mail templates using the existing ${recipient}
expression. Please adapt you process models and definitions accordingly.
To keep the old behavior, you could create a custom MailService
implementation that does iterate.
Expression bean configuration
Previous releases used an expression.bean.whitelist
property to configure Spring beans that can be
accessed using a backend expression (e.g. from a process model). The whitelist has now been removed
and replaced with an annotation (@ExpressionBean
) which can be used to mark beans that should be
accessible from an expression.
Simply annotate any bean classes that you want to enable for expressions:
import com.edorasware.api.expression.ExpressionBean; @ExpressionBean public static class TestBean { public String get() { return "Hello bean"; } }
The expression.bean.whitelist
property is no longer used, and can now be removed. If you have custom
beans that should be accessed from an expression then these should be annotated as shown above.
root & parent expression resolution
In the case when you:
-
use
root
orparent
expressions (e.g. in long running processes), -
set
expression.propagate.unresolved.object.error
property totrue
(which is the default value), -
rely on the null returned value in the case when expressions is not resolved
you have to migrate processes to the new process definition version which must handle exceptions instead of null values.
In the case when migration is not feasible set expression.propagate.unresolved.object.error
to false
.
How to integrate edoras one in your own html
The HTML code needed to integrate edoras one into a DIV in your application has changed. Please refer to the documentation How to integrate edoras one in your own html to get the latest code version.
Bootstrap project
Here you will find a list of files which have changed in the bootstrap project since the last release. This helps you check the difference between your bootstrap project version and the current one:
-
src/main/resources/com/edorasware/bootstrap/config/one.properties
-
added properties
expression.propagate.unresolved.object.error
andexperimental.form.live.preview
, removedexpression.bean.whitelist
-
src/test/resources/test/config/acme-test.properties
-
removed
expression.bean.whitelist
-
src/main/java/com/edorasware/acme/AcmeService.java
-
Added
@ExpressionBean
annotation to enable expression access -
src/main/java/com/edorasware/acme/TaskNameService.java
-
Added
@ExpressionBean
annotation to enable expression access