Skip to Content

Changes for page R13 - Double Lane

Last modified by Erik Bakker on 2022/06/16 13:13
From version 9.1
edited by Erik Bakker
on 2022/06/16 12:48
Change comment: There is no comment for this version
To version 12.1
edited by Erik Bakker
on 2022/06/16 12:59
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -60
1 +57
Content
... ... @@ -1,14 +1,21 @@
1 -Small update that fixes three specific issues.
1 +Small update that brings support for connecting to OAuth 2.0 resources servers that do not support having OAuth 2.0 scopes. Also the HTTP component is updated with new REST template possibilities.
2 2  
3 3  Find out more in our [release blog]
4 4  
5 5  
6 -===== Bug Fixes =====
6 +===== New Features =====
7 7  
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.
8 +* With this update, eMagiz runtimes can fulfil the role of an MQTT broker. To do this, put an Artemis server support object in your connector and make sure it accepts MQTT protocol communication over web sockets. Internally, handling these (MQTT) messages is no different from handling "normal" (AMQP) messages.
9 +* Updated Artemis, Qpid, Proton-J and Netty to the latest maintenance releases. These updates mostly contain bugfixes, improvements and performance wins.
11 11  
12 12  ===== Minor Changes =====
13 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]".
13 +* Updated bundle 'com.emagiz.bundles.spring-security-config' from 5.3.4.1 to 5.3.9.1
14 +* Updated bundle 'com.emagiz.bundles.spring-security-core' from 5.3.4.1 to 5.3.9.1
15 +* Updated bundle 'com.emagiz.bundles.spring-security-oauth2-client' from 5.3.4.1 to 5.3.9.1
16 +* Updated bundle 'com.emagiz.bundles.spring-security-oauth2-core' from 5.3.4.1 to 5.3.9.1
17 +* Updated bundle 'com.emagiz.bundles.spring-security-oauth2-jose' from 5.3.4.1 to 5.3.9.1
18 +* Updated bundle 'com.emagiz.bundles.spring-security-oauth2-resource-server' from 5.3.4.1 to 5.3.9.1
19 +* Updated bundle 'com.emagiz.bundles.spring-security-web' from 5.3.4.1 to 5.3.9.1
20 +* Updated bundle 'com.emagiz.components.security' from 7.0.0 to 7.0.1
21 +* Updated bundle 'com.emagiz.components.http' from 7.1.0 to 7.1.1