This document describes the steps needed to upgrade the edoras one application to 1.5.0.S125.
Please stop the edoras one server, perform all upgrade steps described below and then restart the server again at the end.
Cache improvements and refactoring
Level 1 cache for work objects
The new level 1 work object cache is completely transparent and no changes are required.
The new cache applies to plain ID-based lookups (work object ID, external ID or global ID). To reap the performance gains of the L1 cache, review code that loads a specific work object using an ID-query-plus-hints call. See if it can be changed to a plain ID-based lookup, as those will benefit from the L1 cache.
Cache refactoring
While introducing an L1 cache we reviewed and refactoed the existing caches. The following list shows the changes. If you adapt/override one of these files, you will need to merge these changes such that your edoras one remains fully functional:
-
The
edorasOne-usersById
cache has been removed in favor of the new L1 cache. Remove this cache from your configuration and the cache provider. -
We moved all classes from the
com.edorasware.one.cache
package to thecom.edorasware.one.cache.internal
package to better reflect that these are internally used classes. -
There are a lot of changes in the
cache-config.xml
. Please compare it to your version if you have custom caching. These are the changes made:-
We now use only one cache manager (EhCache for single nodes and Redis for cluster configuration) and no more composites.
-
We removed the
transactionAware
flag on the caches as this is not needed. -
We now use custom cache managers which provide statistical data on the caches.
-
As mentioned above we now have statistics aware caches that publish statistics over the following endpoints (log into edoras one as the system administrator and enter the URL’s relative to your edoras one root URL.):
-
For the cache statistics open
rest/api/v1/maintenance/cache
. -
To clean all caches you can call the
rest/api/v1/maintenance/cache/clear
endpoint. -
To clear a specific cache you can call the
rest/api/v1/maintenance/cache/clear/{cacheName}
endpoint with the specified cache name.
Support for XA data sources
The default configuration uses one datasource and one transaction manager for data and schema manipulation with two different aliases.
<bean id="transactionManager" name="schemaTransactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
<bean id="dataSource" name="databaseSchemaManagerDataSource" class="org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy">
<property name="targetDataSource">
<bean class="com.zaxxer.hikari.HikariDataSource" destroy-method="close">
<constructor-arg name="configuration" ref="hikariConfig"/>
</bean>
</property>
</bean>
In the case of database-jndi-xa
profile activation data and schema manipulation datasources and transaction managers are created in the separated bean instances with unique
configuration.
<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
<bean id="schemaTransactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
<property name="dataSource" ref="databaseSchemaManagerDataSource"/>
</bean>
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="${databaseJndiName}"/>
</bean>
<bean id="databaseSchemaManagerDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="${schemaDatabaseJndiName}"/>
</bean>
Elasticsearch index configuration
The indexContent
method in the elasticsearch IndexConfiguration
interface has been changed
and projects that define their own index configurations will have to be updated.
The previous method declaration would pass in content that had already be read by the elasticsearch integration code:
void indexContent(ContentReference contentReference, byte[] content);
This has been changed to allow the index configuration to decide how to read the content, for example to use a stream-based content processing chain:
void indexContent(ContentManager contentManager, ContentReference contentReference);
To read the content for implementations that were implemented using the old behaviour,
the static readContent
method from the ContentUtil
class can be used:
void indexContent(ContentManager contentManager, ContentReference contentReference) {
byte[] content = readContent(this.contentManager, contentReference);
// ... implementation as before
}
Another small change was made to the conditions under which the migrate()
method is called.
Instead of the framework checking whether an index exists with the correct index name before calling
the migrate()
method, it will now be called every time the server is started. This allows the
migration code to act regardless of the current index state (for example to rename an existing
index that is compatible with the index configuration but has the wrong name).
If your migration code relies on the presence of the index then you should add an explicit check for this to your implementation:
@Override
public void migrate() {
if (indexAdapter.isIndexPresent(getIndexName())) {
// ... implementation as before
}
}
Spring configuration changes
Some minor changes have been made to the Spring configuration in this release:
-
the ID for the task scheduler bean has been changed from
scheduler
totaskScheduler
, avoiding a warning and the creation of a duplicate scheduler bean by the Spring framework. -
configs from the
/com/edorasware/cloud/core/config
package are now loaded usingclasspath*:…
instead ofclasspath:…
. This change will normally have no effect as projects should not have their own config files in this package, but if a project adds such a file by mistake then the core configurations will still be loaded and hard-to-debug Spring errors will be avoided. -
the
<context:annotation-config/>
setting is now set by default in the core configuration, making it easier to add Java Spring configurations.
Content manager changes
Some minor changes have been made to the content manager configuration. You will need to provide the transaction manager in the constructor of the content manager. Before you had the following configuration (based on the default. Could differ if you configured other content providers):
<!-- configure the 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="currentTenantService"/>
<constructor-arg ref="currentUserService"/>
</bean>
And now you need to add the <constructor-arg ref="transactionManager"/>
constructor argument:
<!-- configure the 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="currentTenantService"/>
<constructor-arg ref="currentUserService"/>
<constructor-arg ref="transactionManager"/>
</bean>
CSRF header and cookie name customization
Since 1.5.0.S125 it’s possible to set a custom cookie name and header for CSRF.
To do that, modify xsrf.cookie.name
and xsrf.header.name
in one.properties
.
#########################################
# Security configuration #
#########################################
# if security-basic or security-embedded spring profiles are activated xsrf.cookie.name is used to specify cookie where to store xsrf tokens
xsrf.cookie.name=XSRF-TOKEN
# if security-basic or security-embedded spring profiles are activated xsrf.header.name is used to specify header where xsrf token is stored
xsrf.header.name=X-XSRF-TOKEN
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/acme/config/acme-context.xml
-
The cache configuration has been adapted. Include the index configuration by default.
-
src/main/resources/com/edorasware/acme/config/acme-index-config.xml
-
enable index configuration beans when the elasticsearch profile is set
-
pom.xml
-
include the edoras-gear-search dependency by default and fix the incorrect group ID
-
src/main/resources/com/edorasware/bootstrap/config/one.properties
-
xsrf.cookie.name
,xsrf.header.name
properties were added -
src/main/resources/com/edorasware/bootstrap/config/security/security-basic-config.xml
-
xsrfTokenName
attribute added to the filter bean -
src/main/resources/com/edorasware/bootstrap/config/database-config.xml
-
database schema and transaction manager reconfiguration
-
src/main/java/com/edorasware/acme/expression/AcmeService.java
-
AbstractActivityService
superclass interface changes wera applied onAcmeService
-
src/main/resources/com/edorasware/bootstrap/config/content-config.xml
-
transaction manager added to content manager