Expanders 5.28.0
Efforts to reimagine and improve the way workflows are modeled and implemented within our applications have started a while ago. This release marks the first impact of those efforts on Expanders.
Resources
The expansion resources below provide Expanders 5.28.0.
| Resource | Version |
|---|---|
| Expanders | 5.28.0 |
| nsx-default-stack | 2023.12.0 |
| rest-jaxrs-stack | 3.21.0 |
Changes and improvements
Task perform and delegation
Modeling your application should be as simple as possible. This includes providing developers with sensible defaults. Best practices shouln't be hidden behind an option. For this reason the following options have become deprecated and are now the default behavior:
includePerformEvery task should be able to be performed. The expanded perform method has the advantage that its contract aligns with the TaskElement model.includeDelegationIn the JEE application stack a task is accessed as an EJB. Delegation allows us to implement the task independently of this technology. It will also improve the ability to test this implementation. To opt-out of delegate implementation(s) you can use the newnoDelegationoption.
Additionally, adding the includeRemoteAccess option is no longer recommended. This option exposes a task directly to a Struts api, which doesn't have the best interface and implementation.
Non-dynamic task implementation
Available task implementations must be known at compile-time, which is why we replaced the dynamic lookup using Class.forName(..) with a switch-statement. This explicitly lists all available implementations and allows for better code navigation.
Multiple task implementations for the same task are infrequently used. However, when applicable it should at least be clear what each implementation does. For this reason we chose to retire the <Task>Impl2.java artifact, custom implementations with meaningful names should be used instead.
Additionally, getting rid of the dynamic lookup allows us to use named implementations instead of fully qualified class names as well. You could for example have a task implemented with and without encryption of some data. These implementations can now be named default and secure, which would then resolve to their respective implementation. Since the implementation name is just a string, you can still use fully qualified names as well.
Migration guide
Task implementations
- Check if your application has any (useful)
<Task>Impl2or custom task implementations.- The
Impl2class must be moved fromgentoext. Preferably rename it to something more meaningful.
- The
- For each of these, add a switch case to the
<Task>Bean.javaas illustrated below:// @anchor:prePerform:start
final Calculate implementation;
String implementationName = targetParameter.getContext().find(ProcessingContext.class)
.map(ProcessingContext::getImplementation).orElse("default");
switch (implementationName) {
// anchor:custom-implementations:start
case "my.custom.impl.CalculateInParallel":
implementation = new CalculateInParallel();
break;
case "net.demo.CalculateImpl2":
implementation = new CalculateImpl2();
break;
// anchor:custom-implementations:end
case "net.demo.CalculateImpl":
case "default":
implementation = new CalculateImpl();
break;
default:
logger.error("No Calculate implementation found for " + implementationName);
return TaskResult.error();
}
// @anchor:prePerform:end
Task options
- Make sure
prime-transmutationsis on version2.1.2or above.- Included in
nsx-default-stackversion2023.12.0.
- Included in
- Run the 'Upgrade' transmutation on your applicaton.
- Either in the microradiant or from commandline using:
mvn expanders:transmute-model -Dtransmutation=Upgrade - The 'Upgrade' will remove the
includeRemoteAccessoption from all tasks as it is not needed for most applications. If your UI depends on executing tasks directly (e.g. it callsnsxActions.performTaskfrom webStyles) you can still use this option. We do however recommend not using it and plan on providing a better alternative in the future.
