If you are upgrading to a later release of Stardust from an earlier release, there are a few things you have to take in account. The following sections document the changes required for specific issues.
For general upgrading, refer to the following topics:
Refer to the following section for specific upgrading issues:
For details on how to upgrade a Stardust version, refer to the Installation Guide. For known issues while upgrading, please refer to the Troubleshooting chapter.
To upgrade the audit trail from a previous Stardust version, use the following sysconsole command:
sysconsole upgraderuntime
with the following arguments:
For detailed information on the sysconsole command, refer to chapter The Sysconsole Command of the Operation Guide.
Refer to the release notes of the current Stardust version ( Release Notes 4.0.1 ) for details on runtime upgrades like schema changes that will be performed with this command on earlier versions.
You can perform a model upgrade via the Sysconsole command or from the Eclipse environment.
Please ask your administrator to perform the upgrade or use the sysconsole command option upgrademodel to upgrade to a newer Stardust version:
sysconsole upgrademodel -file <file> -source <source> -target <target>
Whereby:
For more information on using the sysconsole command please refer to the chapter The Sysconsole Command in the Operation Guide.
In case you import a model in Eclipse with an earlier Stardust version than you use, you will be prompted and asked if you want to upgrade to the currently installed version. Click Yes to upgrade the model.
Currently there is no automated facility for upgrading the libraries contained in existing Dynamic Web projects with Stardust facets to the most recent Stardust version. In that case you have to upgrade the Process Manager facets manually as described in detail in the section Upgrading Process Manager Facets of the chapter Creating a Dynamic Web Project in Eclipse .
If you upgrade from versions earlier than 4.0, consider the following issues:
Schema changes have been performed in release 4.0. In order to account for schema changes, performing a runtime upgrade will be necessary to operate against audit trails created with earlier versions. For details on these schema changes, please refer to section Schema Changes of our Release Notes 4.0.
In version 4.0 groupId and artifactId of the Camel Templating artifacts have been changed. Apply these changes to your environment in case you upgrade from a version earlier than 4.0. Replace the groupId and artifactId names in your POM files with the new groupId and artifactId accordingly.
The following table provides an overview on the groupId and artifactId changes for the particular projects:
| Project | Old GroupId | Old ArtifactId | New GroupId | New ArtifactId |
|---|---|---|---|---|
| json-utils | com.infinity.integration | json-utils | org.eclipse.stardust.engine.camel | stardust-json-utils |
| camel-itext-convertor | com.infinity.integration | camel-itext-convertor | org.eclipse.stardust.engine.camel | stardust-camel-itext-convertor |
| camel-templating | com.infinity.integration | camel-templating | org.eclipse.stardust.ui.web | stardust-web-camel-templating |
For example change
<groupId>com.infinity.integration</groupId> <artifactId>camel-itext-convertor</artifactId>
to
<groupId>org.eclipse.stardust.engine.camel</groupId> <artifactId>stardust-camel-itext-convertor</artifactId>
If you use a custom skin in your Portal, which was applied in a version earlier than 4.0, you have to re-select it in the Portal Configuration to apply internal changes for default skin preferences.
Please refer to section Selecting the Portal Skin of chapter Configuring general Portal Components in the End User Handbook for details on how to select custom skins.
With version 4.0, document centric access control evaluation is included in a newly created security Jackrabbit repository. In case access control has been set for files individually, access control is now evaluated separately without folder hierarchy inheritance.
If you like to use this feature, but you are using a
repository created with an earlier version, you need to configure the AccessControlProvider inside a
WorkspaceSecurity tag after the SearchIndex entry for each workspace.
In this case add the following workspace security section to the workspace template creation entry in your
repository.xml security file:
<Workspace name="${wsp.name}">
...
<!-- Search index and the file system it uses -->
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
...
</SearchIndex>
...
<!-- Workspace Security -->
<WorkspaceSecurity>
<!-- Files with ACLs are evaluated separately without Folder hierarchy. -->
<AccessControlProvider class="org.apache.jackrabbit.core.security.authorization.acl.FileACLProvider" />
</WorkspaceSecurity>
Note that for existing repositories the same entry needs to be added in the workspace.xml
file, which resides in the according repository path, to become effective.
Schema changes have been performed in release 3.1.0. In order to account for schema changes, performing a runtime upgrade will be necessary to operate against audit trails created with earlier versions. For details on these schema changes, please refer to section Schema Changes of our Release Notes 3.1.0.
Additionally consider the following issues in case of an upgrade:
If you use an audit trail database that has been created with an
Stardust version earlier than 3.1.0, you have to deselect and select the
database from the server configuration page. Republishing the server updates the
server.xml file with the new resource definition entry for embedded
database usage.
With release 3.1.0, the Stardust JBoss 6 archetype has been renamed from ipp-archetype-jb62-eap-ipp-ear to ipp-archetype-jb6-eap-ipp-ear to support JBoss 6.3 EAP and 6.4 EAP. Please consider this change if you upgrade your Maven project from an Stardust version older than 3.1.0.
A runtime upgrade against audit trails created with earlier versions adds the new predefined process instance link type RELATED to the LINK_TYPE in the audit trail. This runtime upgrade job is optional and only required for usage of new link type RELATED.
Note that this upgrade job is a trivial one and can be applied without any risk!
Exception handling for embedded service factory services changed with version 2.1.0 to return unwrapped exceptions as with regular API calls. Additionally, raised exceptions now properly honor an existing transaction rollback policy. Note that this change might potentially break existing workarounds you have applied in an earlier version.
A runtime upgrade against audit trails created with earlier versions adds the new predefined process instance link type SPAWN to the audit trail. The SPAWN link type describes the case for just creating a new root process instance from an existing one with optionally copying data. This runtime upgrade job is optional if you are not using the spawn functionality.
Note that this upgrade job is a trivial one and can be applied without any risk!
A runtime upgrade for versions earlier than 1.1 adds the following columns to your schema:
In case you are using the JavaScript source file IppProcessPortalClient.js in your external Web application, you need to upgrade it with the new one provided in the ipp-workflow-perspective.jar file of the new Stardust installation.