Skip to Content

Changes for page 57

Last modified by Erik Bakker on 2023/01/23 13:58
From version 8.1
edited by Erik Bakker
on 2022/06/16 12:47
Change comment: There is no comment for this version
To version 9.1
edited by Erik Bakker
on 2022/06/16 12:48
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -61
1 +60
Content
... ... @@ -3,18 +3,12 @@
3 3  Find out more in our [release blog]
4 4  
5 5  
6 -===== Minor Changes =====
7 -
8 -* Updated bundle 'com.emagiz.bundles.groovy-all' from 3.0.9.1 to 3.0.9.2
9 -* Removed bundle 'com.sun.mail.javax.mail' because it was not used anymore
10 -* Updated bundle 'com.emagiz.components.security' from 7.1.1 to 7.2.0
11 -* Updated bundle 'com.emagiz.components.http' from 7.2.1 to 7.2.2
12 -* Updated bundle 'com.emagiz.util.codec' from 6.1.0 to 6.1.1
13 -
14 14  ===== Bug Fixes =====
15 15  
16 -* The OAuth 2.0 authorization interceptor in the Rest Template component contained client 'Authentication methods’ that were invalid and caused a flow not to start in build 59. Also the clockskew is now configurable so we can handle the requirements of more oauth2 authentication providers.
17 -* The Amazon S3 authentication interceptor in the Rest Template component had a threading issue where the key would be invalid on heavy usage. The threading has been changed and is now behaving correctly.
18 -* In several flow designer components you can add Groovy scripts. Since build 59 using FastStringUtils (JSON parsing) did not work.
19 -* For Gen3 runtimes we upgraded to Spring Boot 2.6.6 to bring the latest security patches.
8 +* Build number 59 broke the debugger, build number 60 fixes this.
9 +* Fixed Kafka components not being able to use key- or truststores from the "resources" tab.
10 +* Deploying flows containing a 'Jetty server' support object in build number 59 only worked on the latest runtime version: build number 60 fixes the backwards compatibility with older runtimes. Note that it is still strongly recommended to update to the latest version of the runtime (5.0.4) if you haven't done so already, because this contains fixes for the Log4j security vulnerability.
20 20  
12 +===== Minor Changes =====
13 +
14 +* Change of behaviour when incoming HTTP headers are mapped to message headers: Up to build 58 the values of incoming HTTP headers were only mapped to an array when it contained multiple values, otherwise the first (and only) value was automatically extracted and used for the message header. Since build 59 the values are always mapped to an array. While this makes the data type of the header more predictable - it is no longer dependent on the number of values a client was sending - it does mean that your SpEL expressions that were previously expecting single values need to now handle array values. In many cases this can be as simple as extracting the first array value like this: "headers.myHeader[0]".