Learn more about public URLs and how to install the new licence in the Engine Guide.

Furthermore, we have removed the Demo Licence file demo.lic from the [engineDir]/configuration directory. The Axon.ivy Engine 8.0 is running in demo mode by default without a valid licence file.

Verify libraries

We updated many shared project libraries to a Java 11 compatible version. Be aware that more APIs could have been deprecated by these libraries which could have side effects to projects built upon them.

Many prominent Java libraries released new version for Java 11. Check your projects for custom libraries and verify its compatibility with the latest Java LTS JRE.

Known issues with third-party libraries:

• PowerMock: is known to produce NoClassDefFoundErrors as it accesses JDK classes in a non-standard way. However, you can configure PowerMock to avoid loading the problematic classes by setting the @PowerMockIgnore({"com.sun.myissue.*}) annotation. More

Fix sun and com.sun imports

For years internal Sun API was packed and accessible through the JRE. Now these packages can no longer be imported, which leads to compile and runtime failures.

Many developers imported these classes by accident. Therefore, check your projects for compile errors and fix them to avoid runtime errors for users.

In most cases there is an equivalent replacement class available. E.g.:

• sun.misc.BASE64Encoder: can be replaced by java.util.Base64.getEncoder() which is available since Java 8.

Linux Designers

Openjdk-11-jre's are pre-installed on many recent Linux distributions. Unfortunately as of today, with OpenJDK 11.0.5, these JREs are known to crash when using legacy AWT UIs of the Designer [see Bug #1838740]. For instance, when using the configuration editor to add new environments.

However, AdoptOpenJDK releases seem not to be touched by these issues. Therefore, a switch to these VMs is recommended to use the Designer. Execute the installDependencies.sh script in the root of the Designer to do so.

Maven

A Java 11 JDK is required to execute Maven builds with the latest project-build-plugin. To prevent problems with multiple installed Java versions, the environment variable JAVA_HOME must be set.

Here is a list of the most common problems we encountered or changes we had to make:

• Mobile has been removed. If you used any of the mobile (pm:) widgets you will need to replace them, the Axon.ivy Designer will underline them with a warning. These widgets were used by default in mobile and offline dialogs.
  For example replace:
  • <pm:header> with <div class="container">
  • <pm:content id="content"> with <div class="ui-content">
• facetFontStyle and cellFontStyle don't support setBoldWeight() anymore. You can directly call setBold().
• Select one menu arrow alignment changed. Use !important for relative positioning.
• autoUpdate attribute was removed from outputPanel, fragment, messages and growl. Use p:autoUpdate instead.
• Change appendToBody="true" to appendTo="@(body)" in p:overlayPanel.
• jQuery has been updated from version 1.11 to 3.3. Check your jQuery code if it is still valid.
• Some of the styling has changed. Check your styling if it is still as expected.
• The class org.primefaces.context.RequestContext is now deprecated.

To migrate the Portal application, you need to do the following steps:

1. Migrate the projects you have deployed to the Portal application and that depend on the Portal to the new Portal 8.0.
2. Reconfigure the file directory of the Portal application. This can be done by writing an app-Portal.yaml file to the [[EngineDir]/configuration directory and set the Data.FileDirectory property. See below.
3. Redeploy your projects and the new Portal 8 to the Portal application by using the Engine Cockpit.

Example app_Portal.yaml file:

Data:
    FileDirectory: applications/Portal

Removed Properties from System Database

System-, Application- & Cluster-Properties are now read directly from the yaml configuration files. The properties of your system database are written to your ivy.yaml or ivy.cache.properties file during the database conversion. Only a few internal properties will stay stored in the database. Cluster Properties are not supported any longer. For cluster usage you need to define a separate ivy.yaml file for every node.

Please check the ivy.yaml file if the converted values are valid.

Removed Security System Configuration from System Database

The security system configuration is now read directly from the yaml configuration files. The configuration in your system database is written to your ivy.yaml file during database conversion.

Please check the ivy.yaml file if the converted values are valid.

If you have a serverconfig.xml you should copy it into the new engine along with your other configuration files. The settings in the serverconfig.xml file are automatically converted during the next boot of the engine.

Due to platform-independent configuration setup we no longer consider the following launch configurations:

• bin/Example.ilc
• bin/AxonIvyEngine.conf
• bin/control.conf
• bin/*.conf
• bin/*.ilc

We introduced the platform-independent configuration/jvm.options. You must migrate the settings in your *.ilc and *.conf files to the JVM settings in this file.

Windows In the Example.ilc file you find a documentation which JVM flags are modified by each setting. You need to set these JVM flags now in the jvm.options file accordingly.

Linux All settings in the AxonIvyEngine.conf file can be transparently moved to the jvm.options file.

Migrate to pkcs12

Preferred solution is to use the new pkcs12 key- and trustore located in [engineDir]/configuration.

Export the existing certificates and private keys from keystore.jks / truststore.jks and import them into keystore.p12 / truststore.p12.

You can adapt this command to convert a store from jks format into pkcs12.

keytool -importkeystore -srckeystore truststore.jks -destkeystore truststore.p12 -srcstoretype JKS -deststoretype PKCS12 -deststorepass changeit

---

Enable legacy jks store

If you still want to use the legacy jks based stores you can configure Axon.ivy to accept them.

These configuration changes can be made either in ivy.yaml or by using the Engine Cockpit.

Set store type to jks format for the following keys:

• SSL.Client.KeyStore.Type
• SSL.Client.TrustStore.Type

Furthermore, keys that define a keystore path must be re-located to configuration/keystore.jks or configuration/truststore.jks The following keys must be adjusted:

• SSL.Client.TrustStore.File
• SSL.Client.KeyStore.File
• Connector.HTTPS.KeystoreFile

This change requires us to convert the file paths in the database (table IWA_UploadedFile) during an upgrade. It is possible that not all file paths can be converted automatically. If any conversion fails, the process will log a warning, listing all files that could not be converted (Could NOT convert all file paths. The following files could NOT be converted:). All logged file paths need to be changed manually in the database, and the actual files need to be manually moved into the application file folder.

Already deployed projects keep their expanded directory format.

Read-only projects

The packed projects are read-only projects. If you try to change the contents of such a project at runtime it will fail with a java.nio.file.ReadOnlyFileSystemException.

Get write access

If write access is necessary, for instance because the ivy.cms write API is used, the related project must be made writable. This can be done by deploying the project as an expanded project:

• with the maven project-build-plugin, the configuration parameter deployTargetFileFormat must be set to EXPANDED.
• with the deploy directory, it can be enforced by providing an options.yaml file with the following content

target
  fileFormat : EXPANDED

• with the Engine Cockpit, use the EXPANDED File Format Option in the deployment dialog.

To call a modifying REST service via PUT, POST or DELETE the caller needs to provide a HTTP Header called X-Requested-By with any value e.g. ivy. This is the Jersey provided protection of REST services against cross-site request forgery (CSRF). If the CSRF header is not provided on a modifying REST request the request will fail with an HTTP Status 400 (Bad Request). Custom REST services via GET, HEAD or OPTIONS should therefore be implemented in a way that they don't modify data.

The CSRF protection for REST services can be server-wide disabled by setting the configuration property REST.Servlet.CSRF.Protection to false. However, that is not recommended.

You can achieve that as follows:

1. switch to the Java perspective
2. open the context menu of the source directory that contains test (e.g. src_test)
3. select 'Build Path' > 'Configure Build Path...' in the context menu
4. expand the test source directory within Java Build Path dialog
5. select 'Contains tests sources: ...'
6. hit the 'Toggle' button to change the value to 'yes'

The change value will be reflected within the .classpath of your project.

Enabling XML validation for .xhtml files can potentially cause validation errors during dialog execution, e.g. you can get a javax.faces.view.facelets.TagException when calling your Html Dialog. If you run into XML validation errors, first try to fix them. If this is not possible (e.g. because the problem is caused by a required component you don't have permission to change) you can disable XML validation (and enable resource caching) by setting the context parameter javax.faces.PROJECT_STAGE to Production in the Designer's webapps/ivy/WEB-INF/web.xml file.

They have been used in JSP layouts of older Axon.ivy projects (< 8.0). Copy all used CSS, JS-scripts and images from an old installation into your Axon.ivy projects.

Some ITask and ICase API was deprecated The numbered custom fields on ITask and ICase have been deprecated e.g.:

• ITask.setCustomVarCharField1(String)
• ITask.getCustomVarCharField1()
• ITask.setCustomDecimalField1(Number)
• ...

The same for the business fields on ITask and ICase:

• ICase.setBusinessCreatorUser(String)
• ICase.getBusinessCreatorUser()
• ...

And for the categorization fields on ITask and ICase:

• ICase.setProcessCategory(String, String)
• ICase.getProcessCategoryCode()
• ICase.getProcessCategoryName()
• ...

Additional Properties have been deprecated:

• Interface ch.ivyteam.ivy.workflow.IAdditionalPropertyable implemented by ITask and ICase
• ch.ivyteam.ivy.workflow.IWorkflowContext.findTask(String, String, ...)
• ch.ivyteam.ivy.workflow.IWorkflowContext.findCase(String, String, ...)
• ch.ivyteam.ivy.workflow.query.TaskQuery.create().where().additionalProperty(String)
• ch.ivyteam.ivy.workflow.query.CaseQuery.create().where().additionalProperty(String)

Use the new Custom Fields instead.

To categorize your Tasks and Cases you should still use ICase.setCategoryPath(String) and ITask.setCategoryPath(String).

We deprecated this API because it is customer specific and of no value for generic customers.

The API consists of the following methods, interfaces and enums:

• ch.ivyteam.ivy.workflow.IWorkflowContext.findEventLog(...)
• ch.ivyteam.ivy.workflow.IWorkflowContext.createEventLog(...)
• ch.ivyteam.ivy.workflow.IWorkflowContext.createEventLogPropertyFilter(...)
• ch.ivyteam.ivy.workflow.eventlog.EventLogDescription
• ch.ivyteam.ivy.workflow.eventlog.EventLogProperty
• ch.ivyteam.ivy.workflow.eventlog.EventLogSeverity
• ch.ivyteam.ivy.workflow.eventlog.EventLogStatus
• ch.ivyteam.ivy.workflow.eventlog.IEventLog
• ch.ivyteam.ivy.workflow.eventlog.IEventLogCase
• ch.ivyteam.ivy.workflow.eventlog.IEventLogTask

Migrate POI Projects

If you included Apache POI already in your projects, you must remove them. First remove instances of poi, poi-ooxml, poi-ooxml-schemas and xmlbeans libraries from your project classpath. To do so:

• switch to Java perspective
• detect instances of POI JARs within the Referenced Libraries container.
• remove POI related JARs from classpath via: Context Menu (right click) > Build Path > Remove form Build Path.
• delete these JARs afterwards also from the file system.

If you were using a POI version prior to 4.1.0 you might encounter errors in your projects that must be fixed. We faced the following changes frequently:

• CellStyle Enum has been replaced by HorizontalAlignment or VerticalAlignment Enum.
• HSSFCellStyle Enum has been replaced by FillPatternType Enum.
• facetFontStyle and cellFontStyle don't support setBoldWeight() anymore. You can directly call setBold().

Adjust Engine libs

If you want to use the Excel export in the Portal or PrimeFace's dataExporter, you don't have to manually add the poi libraries anymore.

Verify that your engine setup does not enforce a manual coping of POI libraries to webapps/ivy/WEB-INF/lib.

If you still need them, you can add them manually to the Axon.ivy project. There is one big advantage: You can now use them in the version you need. It concerns the following libraries:

• Lucene: lucene-core-4.5.1.jar, lucene-analyzers-common-4.5.1.jar, lucene-queryparser-4.5.1.jar
• JGroups: jgroups-3.3.4.Final.jar
• Jetty: jetty-continuation-7.4.5.v20110725.jar, jetty-http-7.4.5.v20110725.jar, jetty-io-7.4.5.v20110725.jar, jetty-server-7.4.5.v20110725.jar, jetty-util-7.4.5.v20110725.jar
• Freemarker: freemarker-2.3.23.jar
• Spring Security Crypto: spring-security-crypto-4.2.3.RELEASE.jar
• DB Libraries: ecs-1.4.2.jar, hsqldb-1.8.0.10.jar, jt400-7.3.0.3.jar, jtds-1.3.1.jar, mysql-connector-java-5.1.42.jar, ojdbc8-12.2.0.1.jar, postgresql-42.1.3.jar, mssql-jdbc-6.2.1.jre8.jar
• XML Libraries: jaxen-1.1.6.jar, dom4j-1.6.1.jar
• JSON Libraries: jettison-1.3.8.jar
• Helper Libraries: reflections-0.9.8.jar, annotations-2.0.3.jar; if you have used these two libraries in your projects, you will need to update and re-deploy the projects to avoid NoClassDefFoundErrors at runtime.

Tasks that are not synchronised and are being worked on may throw ViewExpiredExceptions when synchronising with the engine. This only happens the first time and won't have any side effects except that you must re-submit your data for said tasks.

After your device has been successfully synchronised with the engine you can start working on your tasks like always.