1.8.0
This minor release introduces the following new features
- The CoAP adapter now supports authentication of client certificates using ECDSA based cipher suites.
- The JDBC-based device registry implementation now supports the automatic creation of the database schema, both for device registration and tenant data. This is especially useful for experimental setups where an embedded database, such as H2 provides, is sufficient. To enable automatic schema creation, activate the create-schema application profile.
- Hono's components now support configuration of supported TLS cipher suites. The cipher suites can be configured separately for both the endpoints exposed by the components as well as the clients used for accessing service endpoints exposed by other components. Please refer to the corresponding admin guides for details regarding the corresponding configuration variables.
- Hono now supports auto-provisioning of gateways. For more information please refer to the Gateway Provisioning concept page and to the Device Registry Management API on how to configure a tenant's trusted CA authority for that.
- A Tenant's trusted CA can now be configured with a new property called auto-provisioning-device-id-template. During auto-provisioning of devices and gateways, the device identifier is generated based on this template and used for the device registration. For more information please refer to the Device Provisioning concept page and to the Device Registry Management API on how to configure a tenant's trusted CA authority for that.
- The Hono CLI supports now Kafka as a messaging system. Please refer to the module's README file for examples of using the CLI to receive events and telemetry data and send commands.
- The example business application supports now Kafka as a messaging system. Please refer to the Developer Guide for details.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
Several improvements have been made regarding the routing of commands using a Kafka broker as the messaging infrastructure. Using Kafka as a replacement of the AMQP 1.0 Messaging Network is still considered experimental. However, we encourage users to start experimenting with Kafka and provide feedback and, in particular, report any bugs. The overall goal is to use Kafka as the default messaging infrastructure in the future.
The Sandbox environment now uses the Quarkus based native images instead of the Spring Boot based images. This has resulted in memory consumption dropping down to a third of the original memory requirement of the Spring Boot based images.