The focus on this release upgrades is the new content manager and the required migration of the content from the previous default file-based storage to the new database-based storage. The change in behaviour of Create Case and Document service tasks requires additional action to take. For the detailed information see chapters below.
Please stop the edoras one server, backup the database, the content and the old WAR file. Then do all the upgrades described in the next paragraphs and then start the server again. This way you ensure that all upgrades are executed properly and that you do not get an inconsistent state when starting it in the middle of the upgrades.
Content manager upgrade
In this release we deprecated the old content provider in favor of the new content manager. To successfully migrate the data from the previous versions to the current one follow these steps:
Before the migration
Create backup of your database, the content and content meta files directories (set in the fileBasedContentProvider.contentDir
, contentProvider.tempDir
system
properties) The table edw_gear_content
(if exists) should be empty before the upgrade as the upgrade will add the non-nullable content scope
field.
Make sure that you’ll have enough space for the migration. The deletion of the content in the previous content provider does not happen until the end of the process, so you’ll need twice the space as you need now for your files. The migration stores the content in the database as Binary Large Objects (BLOBs), so check out the BLOB space of your database.
Rename your current contentProvider
bean to deprecatedContentProvider
(the id is referenced form upgrade patch and can not be changed) and add the contentManager
bean configuration to your content-config.xml
. The databaseContentProvider
bean is created by default by edoras gear. Here a content-config.xml
example for the
database based content provider:
<bean id="contentManager" class="com.edorasware.commons.core.content.internal.DefaultConfigurableContentManager">
<constructor-arg>
<list>
<ref bean="databaseContentProvider"/>
</list>
</constructor-arg>
<constructor-arg>
<ref bean="currentTenantService"/>
</constructor-arg>
</bean>
<bean id="deprecatedContentProvider" class="com.edorasware.cloud.core.content.internal.FileBasedContentProvider">
<constructor-arg value="${fileBasedContentProvider.contentDir}"/>
<constructor-arg value="${contentProvider.tempDir}"/>
<constructor-arg value="2"/>
</bean>
In the case you need to use the file system based content provider use the following configuration:
<bean id="contentManager" class="com.edorasware.commons.core.content.internal.DefaultConfigurableContentManager">
<constructor-arg>
<list>
<ref bean="filesystemContentProvider"/>
</list>
</constructor-arg>
<constructor-arg>
<ref bean="currentTenantService"/>
</constructor-arg>
</bean>
<bean id="filesystemContentProvider" class="com.edorasware.commons.core.content.internal.filesystem.FilesystemContentProvider">
<constructor-arg name="rootFolder" value="${edoras-one.home}/filesystemContentProvider"/>
</bean>
<bean id="deprecatedContentProvider" class="com.edorasware.cloud.core.content.internal.FileBasedContentProvider">
<constructor-arg value="${fileBasedContentProvider.contentDir}"/>
<constructor-arg value="${contentProvider.tempDir}"/>
<constructor-arg value="2"/>
</bean>
After these changes please check that if you use the old content provider in your Java classes that you upgrade to the new API and then start the server.
After the migration
-
All content and the content-meta-files folders are deleted. Review the contents of the ${edoras-one.home} folder to check if the operation succeeded. Migration will not fail if those folders cannot be deleted. An error message will be logged in that case.
-
Check the log for errors and warnings. In the case when there were inconsistencies between references in the database and files you have to fix them manually.
-
The
patchUnusedContentAction
system property can be removed from one.properties file. -
The
deprecatedContentProvider
content provider declaration inside thecontent-config.xml
andcontentProvider.tempDir
and thefileBasedContentProvider.contentDir
properties can be removed after migration.
Rollback instructions
-
Take note of all the migration errors. The migration process logs the ids of the work objects that presented problems.
-
Restore the backup of the database
-
Restore the content and the content meta files folders to their original paths.
-
Start edoras one in your current version an fix all the errors or simply make sure that you can ignore them. After fixing the migration errors, you’ll be able to retry the migration process.
In the case when you implemented your own content provider implementation the migration depends on your proprietary content provider implementation. Please estimate enough time for the code migration because a lot of classes were deprecated and you need to use the new content manager.
Please ensure that you plan enough time for the migration to be done as all content will be copied to the new content provider and all work objects need to be scanned for attachment components. So the migration can take some time.
Configuration changes for exporting and importing translations
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
:-
add a new bean declaration with the id
visAppTranslationService
and the classcom.edorasware.vis.translation.service.VisAppTranslationService
.
-
Miscellaneous
Create Case and Document service tasks behavior change upgrade
Create Case and Document service tasks do not store document id variable value in the string format since 1.5.0.S98. Instead of string value typed CaseId
or DocumentId
variable value is used. In all places where you relay on string id variable value use caseId.getValue()
or documentId.getValue()
method.
Bootstrap project
Here you will find a list of files which have changed since the last release. This helps you check the difference between your bootstrap project version and the current one:
src/main/webapp/custom.css
: this file should be used for custom CSS extensions as it will be automatically loaded by the Front-End if the
index.html or corresponding template is not modified or overwritten.
src/main/webapp/custom.js
: this file should be used for custom JS extensions as it will be automatically loaded by the Front-End if the
index.html or corresponding template is not modified or overwritten.