This document describes the steps needed to upgrade the edoras one application to 1.5.0.S106. The upgrade is focused on the removal of automatic transaction proxies and vis configuration changes.
Please stop the edoras one server, perform all upgrade steps described below and then restart the server again at the end.
Removal of automatic transaction proxies
In all previous releases, work object service beans were automatically wrapped by a transaction proxy instance. This proxy intercepts incoming service calls and automatically creates a new transaction if required. If the service call throws an exception the proxy will also mark the transaction for rollback.
This approach has a number of problems:
-
rollback-on-error is not always the desired behaviour. Sometimes an error could be successfully handled without abandoning the entire transaction.
-
the proxies could occasionally lead to unexpected and hard-to-analyse problems in the Spring initialisation process (slow initialization or even endless loops)
-
automatically creating transactions is convenient for some very simple use cases that require only a single service call, but generally multiple calls will be required. Application code should therefore provide a suitable transaction context to encapsulate the overall operation, and if this is done correctly then additional transaction handling in the proxies is redundant.
For this reason the following changes have been made:
-
no transaction proxies are created on work object services by default
-
the low-level work object persistence code now checks that a transaction is active and will produce an assertion error if this is not the case
This change is purely an internal one, and for edoras one users it will have no effect.
For custom application code, the combination of the new transaction assertion and the missing transaction proxies may mean that some operations will fail because the operation is not creating a suitable transaction. Such problems were almost certainly a problem anyway, and are most likely to happen when execution originates in a thread outside of the edoras one application, for example:
-
custom REST endpoints
-
listeners for external events / messages
-
internal application code that is executed in a separate thread (e.g. via an execution service)
-
unit / integration tests
When updating to this release, a review should be made of possible places where this may be a problem and appropriate testing should be carried out to make sure that no transaction assertion errors occur. If a transaction problem is identified, then the boundary of the required transaction should be identified and the appropriate changes made to ensure that a transaction is present. Typically this means identifying the part of the call stack where the transaction should be created and adding relevant transaction handling, e.g.:
-
inject the
PlatformTransactionManager
and use Spring transaction templates to create suitable transactions explicitly -
add Spring
@Transactional
annotations to appropriate classes / methods
If a code path is found where appropriate transactions cannot be added in a timely fashion then
the automatic transaction proxies can be temporarily re-enabled for the whole application by
enabling the |
Changes in vis configuration for fixes done in multi-tab support and other refactorings
These changes are dependent on how you use edoras one: if you use the vanilla edoras-one-hosted
WAR file then you do not need to follow these steps, but if you use edoras one
as a dependency in your project then please read the changes carefully. Maybe not all changes apply to your setup as you did not overwrite the specified edoras one
configuration files. These are the changes you need to do if you overwrite the mentioned file:
-
In the
com/edorasware/vis/config/vis-application-context.xml
:-
to the existing bean declaration with the id
modelerConfiguration
add a new property with nameapplicationEndPoint
and value${application.endpoint:null}
-
in the existing bean declaration with the id
edorasOneWorkspaceService
change the class tocom.edorasware.one.service.internal.DefaultEdorasOneWorkspaceService
-
-
In the
com/edorasware/vis/config/vis-rest-config.xml
:-
to the beans tag add a new schema entry
xmlns:tx
with valuehttp://www.springframework.org/schema/tx
and then appendhttp://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd
to the end of the the existing value ofxsi:schemaLocation
-
add <tx:annotation-driven /> entry right below the existing <mvc:annotation-driven /> entry
-
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:
build.gradle
: license version was upgraded to 1.0.5
pom.xml
: license version was upgraded to 1.0.5
.settings/.jsdtscope
: eclipse project settings were removed
.settings/com.springsource.sts.config.flow.prefs
: eclipse project settings were removed
.settings/edoras-one-bootstrap AllTests.launch
: eclipse project settings were removed
.settings/edoras-one-bootstrap clean cf-push.launch
: eclipse project settings were removed
.settings/edoras-one-bootstrap process-asciidoc.launch
: eclipse project settings were removed
.settings/org.eclipse.core.resources.prefs
: eclipse project settings were removed
.settings/org.eclipse.jdt.core.prefs
: eclipse project settings were removed
.settings/org.eclipse.m2e.core.prefs
: eclipse project settings were removed
.settings/org.eclipse.wst.common.component
: eclipse project settings were removed
.settings/org.eclipse.wst.common.project.facet.core.xml
: eclipse project settings were removed
.settings/org.eclipse.wst.jsdt.ui.superType.container
: eclipse project settings were removed
.settings/org.eclipse.wst.jsdt.ui.superType.name
: eclipse project settings were removed
.settings/org.eclipse.wst.validation.prefs
: eclipse project settings were removed
.classpath
: eclipse project settings were removed
.project
: eclipse project settings were removed