Skip to main content

44 posts tagged with "migration-guide"

View All Tags

Expanders 9

· 3 min read
Frédéric Hannes
Frédéric Hannes
R&D Engineer

Version 9 of Expanders introduces support for Jakarta EE as part of an effort to support this across our entire ecosystem. This also marks the completion of the first phase of this migration, where the entire JEE base application stack is supported for both Java EE and Jakarta EE, including process automation.

Breaking change for Struts2

With this release of Expanders, we support both Struts2 6.x and 7.x to match the different versions of JEE. Since Struts2 completely removed support for the fileUpload interceptor in version 7, we've now also removed it from our application stack. The reasoning behind this decision is that this interceptor was responsible for CVE-2024-53677, which has a score of 9.5 on the CVSS 4 scale. The alternative implementation using the actionFileUpload interceptor has been implemented across all of our expanders for several months now, but custom upload actions will also have to be refactored to switch to the new system. Regrettably, the impact of this change will not be visible at compile time, so care must be taking when upgrading to version 9 of Expanders.

Migration

The migration is fairly straight-forward and is described in this migration guide from Struts2: https://struts.apache.org/core-developers/action-file-upload-interceptor

An action that handles uploads should be modified by implementing the UploadedFilesAware interface. With this interface comes a method withUploadedFiles() that should be implemented. To retain backwards compatibility with existing implementations, it is possible to set the values of existing fields in the class from this method, which were previously set dynamically by the old interceptor using reflection.

Migration example

Below you will find a small sample of how we applied this migration to the AssetUploader class.

Before
public class AssetUploader extends ActionSupport {

private File uploadData; // the actual file
private String uploadDataContentType; // the content type of the file
private String uploadDataFileName; // the uploaded file name
After
public class AssetUploader extends ActionSupport implements UploadedFilesAware {

private File uploadData; // the actual file
private String uploadDataContentType; // the content type of the file
private String uploadDataFileName; // the uploaded file name

@Override
public void withUploadedFiles(List<UploadedFile> uploadedFiles) {
if (!uploadedFiles.isEmpty()) {
final UploadedFile uploadedFile = uploadedFiles.get(0);
this.uploadData = new File(uploadedFile.getAbsolutePath());
this.uploadDataContentType = uploadedFile.getContentType();
this.uploadDataFileName = uploadedFile.getOriginalName();
}
}

Angular Expanders 6.1.0

· One min read
Jan Hardy
Jan Hardy
R&D Engineer

Changes and improvements

Ln0x support

Previously only Ln02 link fields were supported, this has been extended to the full range of Ln0x that is implemented by the chosen control layer (std-api or svc-api). This behaviour is locked behind a profile for backwards compatibility reasons:

  • Std API Ln0x
  • Std API yarn Ln0x
  • Svc API Ln0x
  • Svc API yarn Ln0x

New number field component

A new number field component has been introduced that handles text input in the fields more gracefully. The component also implements some fraction digits validators, adding more functionality. The component is powered by an I18N number formatter that handles fraction separators and number bounds correctly. Default this is set to the locale en-GB. For Dutch formatting use nl-BE in the app.config.ts.

Angular Expanders 6.0.0

· 5 min read
Jan Hardy
Jan Hardy
R&D Engineer

Changes and improvements

Upgrade to Angular 19 and Angular Material 19

For this release we updated all the code to Angular 19, in order to stay up to date with the releases and best practices.

Separation of QuerySearch

QuerySearch is now an addon, instead of the default filtering implementation. Everything related to filtering in the code has been moved to separate expansionResources, namely angular-querysearch-expanders, angular-svcapi-querysearch-expanders and angular-stdapi-querysearch-expanders. When these expansionResources are not added the application will still function, however the filtering capabilities will not be present. From now on you can also add filtering implementations, e.g. finders, or provide a custom one.

Yarn support

We provide a solution to substitute npm with yarn if wanted. This drastically improves dependencies install times. Substitute the Std API profile with Std API yarn (or Svc) in your expansionSettings.xml.

Harvest expanders

The angular-expanders now depend on the harvest-expanders:1.0.0, this is an example of one of the first expansionResources that contains reusable expanders. These expanders and expansion steps define the gen/ext less harvesting.

New design implementation

This version contains the new designs made for the list and details page.

Angular Expanders 5.6.0

· 2 min read
Jan Hardy
Jan Hardy
R&D Engineer

Migration guide

Program folder refactor

In order to accommodate multiple AngularApp instances, a folder structure similar to Application has been adopted. This means that in the angular folder you should relocate the ext, harvest and model folder present to a subpath /angularApps/{angularAppName}. You should not move the featureModules folder.

before
angular
├── ext
├── harvest
├── model
. └── space-app.xml
after
angular
├── angularApps
. ├── space-app
. ├── ext
├── harvest
├── model
. └── space-app.xml

Changed allowed value of option angular.isLinkFilterField

The expanders were refactored to correctly find the required DataConnector in the available dataConnectors of the AngularApp. A new find algorithm has been put in place to do this, this algorithm does not rely on the DataRef anymore. This is why the value of the option has been changed to only the name of the DataConnector.

before
featureModuleName::dataConnectorName
after
dataConnectorName

Branding

Login component

Due to popular request the generated login component can be fully customised when using the option angular.hasCustomBranding. This will now give you custom anchors in the login.component.html and login.component.scss files, instead of only the option to change the images.

Title tag in index.html

When using the option angular.hasCustomBranding, custom anchors will appear to set the title tag of your index.html. This is used in the browser tabs, when no other title is set via the angular router. When not filled in, it will put the url in the browser tab. Before the title was always angularAppName.

Docker TomEE base image 3.0.0

· 4 min read
Frédéric Hannes
Frédéric Hannes
R&D Engineer

Version 3 of the nsx-tomee-base Docker image is now available. This version introduces (experimental) support for rootless containers, as well as some minor breaking changes.

Rootless

New images have been added that can be used to run rootless containers. They add a new tomee user, which is used to execute the TomEE application server instead of the root user. Not running containers with a root user reduces security risks for the host system. All existing images are available as rootless as well under labels with the suffix -rootless appended to it.

Data volume

The image now pre-defines a volume at the /data path for applications to write files to. The volume is pre-defined so it will be created even if it is not explicitly defined in the deployment of the container, so any files stored there will always be put into a persistent volume.

Scripts moved

Previously all fixed scripts were stored in the /tmp folder. Though this is not ideal, we kept this for consistency and backwards compatibility. With this major version we've now moved those scripts to a new location in /scripts. There are still symlinks to the existing scripts in case they were called.

Process Automation 1.7.0

· 3 min read
Jorren Hendriks
Jorren Hendriks
R&D Engineer

A brand-new release of the process-automation component is now available! There have been quite a few changes, mostly targeting stability, compatability and bug fixes. Some of the default configuration has changed, which may impact applications using a custom configuration. Read the migration guide below to verify if this applies to you!

Changes and improvements

  • (Stability) {DataElement}Cruds will now return an error when trying to modify an element into an interim state outside a Task.
  • (Stability) Added error and recovery policies, allowing applications to configure how to deal with internal errors.
  • (Stability) Fixed some issues which would occur when transactions went into timeout.
  • (Compatability) Added support for applications using the ejb.interfaces.localOnly option.
  • (Compatability) Replace usage of TransactionManager with TransactionSynchronizationRegistry. This should be available in more JavaEE runtimes.
  • (Traceability) Added new monitoring anchors, to allow for more insight into applications running in production (more on this soon).
  • (Performance) ApplicationPersistent queue will now fetch the queue much sooner if the last fetch received the requested number of tasks.

Angular Expanders 5.0.0

· 4 min read
Jan Hardy
Jan Hardy
R&D Engineer

Changes and improvements

This major release marks the beginning of data access (control layer) separation in the angular stack. This has been accomplished by expanding DataAccess interfaces and InjectionTokens. This token can be implemented by a separate expansion resource specific to a certain control layer implementation, e.g. rest-expanders, json:API, ...

For the moment two data access implementation resources exist:

  • angular-svcapi-stack (rest-expanders)
  • angular-stdapi-stack (jaxrs struts replacement)

REST Expanders 4.26.0

· 4 min read
Frédéric Hannes
Frédéric Hannes
R&D Engineer

REST Expanders are now capable of generating fully featured interactions with file resources. Several other fixes and improvements were also implemented. This post will cover many of the improvements introduced from version 4.22.0 to 4.26.0. The latter of which we consider to provide a complete and stable implementation of the file support.

Resources

The expansion resource below provide rest-expanders 4.26.0.

ResourceVersion
rest-jaxrs-stack4.30.0

Changes and improvements

File support

Version 4.26.0 of rest-expanders features the finished implementation for file support. This includes the linking of file resources to regular REST resources, endpoints to upload files and endpoints to download files.

Files are always represented as fields of a REST resource. It is possible to add the option svcapi.endpoint.upload to generate an upload endpoint in function of a field and svcapi.endpoint.download to generate a download endpoint.

An upload endpoint will return a header containing a unique identifier for the file that can passed to the resource endpoints to link it to a new or existing resource.

Example

In this resource a file link is represented by the birthCertificate. As there's a download endpoint for the field, the resource also returns a resourceUri with a link to the download endpoint for that specific file resource.

{
"name": "Snickers",
"uuid": "f9020d14-b1ab-4de3-99a2-f0a2e5a8c71d",
"birthCertificate": {
"resourceUri": "http://localhost:8080/restexample/v1/cats/f9020d14-b1ab-4de3-99a2-f0a2e5a8c71d/download/birthCertificate",
"identifier": "d8227d40-4e8b-4b7f-baf4-52bb8a051e26",
"fileName": "snickers-haz-cheeseburger.jpeg"
},
"breed": {
"resourceUri": "http://localhost:8080/restexample/v1/catbreeds/Maine%20Coon",
"name": "Maine Coon"
}
}

Asset support

A new expansion resource rest-assets-expanders was introduced which provides a default implementation for file links when they are represented by linkfields to assets:Asset. This includes an implementation for the upload and download endpoints. The rest-assets-expanders resource is now also part of the rest-jaxrs-stack resource.

Client aborts

To round out support for files, the REST expanders now handle aborts for file uploads and downloads from the client. The API now returns nothing when these events occur rather than an error. A message will be logged on the server.

Strict finders

There was a long-standing issue in the backend implementation for the API where in a few places finders are used that do not use strict equality to match resource identifiers. This has now been resolved by adding support instead for the same finders, but using strict equality operators. A strict not-equal operator was also introduced for this purpose.

Though the old finders using Eq and Ne operators instead of Se and Sne operators are still supported, the strict operators are now considered default and the non-strict ones only as fallback if they are the only available.

CORS support

The support for CORS handling in the CorsFilterProvider class has been improved to now include the Access-Control-Expose-Headers, in order to whitelist headers returned by the server for use in scripts. New anchors exposed-headers are available to add additional headers if needed.

Better ValueType support

While rest-expanders already provided support for ValueTypes, the AddDefaultRestApi transmutation still provisioned the model using the deprecated ValueFieldTypes. This has now been updated to correctly provision the model with ValueTypes instead.

QuerySearch Expanders 3

· One min read
Frédéric Hannes
Frédéric Hannes
R&D Engineer

Version 3 of querysearch is in itself not a major functional upgrade, but it is the first version with its model infrastructure depending directly on its ontology model rather than the old elements-based metamodel. This means that it is expanded using the ontology expanders.

Builders

The querysearch-builders module no longer exists. If it is used in an expanders project, remove the dependency. The builders are now part of the querysearch-core module.