20.2.0: Better flow id handling for Snapshots

Feature: (#116) Better flow id handling for Snapshots
The current versions of tracer-spring-boot-starter do not setup tracing instrumentation for spring boots management endpoints (at least if they are mapped to a different port). Due to this, snapshots triggered via the management endpoints had no flow ids and a warning was logged for each event before sending.

We now create a new trace iff there is none yet in those cases, so that snapshot events will always have a flow id.

20.1.0: Batch event submission

This version is for Spring Boot 2.

Feature: (#48) When publishing many events (of the same event type) in a short time, they will now be submitted to Nakadi in batches instead of individually. This should improve performance and save bandwidth.

As a programmer, nothing is needed to enable this feature (other than updating the library version).

Currently, we are using a quite simplistic approach of batching (from all events to be sent during one run of the sending scheduler, just collect events until we either exceed the batch size limit of 50 MB or get one of a different type, then submit them, continue with the remaining events). This might change in the future depending on production experience in our systems.

Bugfix: We also changed a dependency version of Jackson, which had some vulnerabilities (none that could be exploited in our case, we think).

4.3.0: Batch event submission

This version is for Spring Boot 1.5.

Feature: (#48) When publishing many events (of the same event type) in a short time, they will now be submitted to Nakadi in batches instead of individually. This should improve performance and save bandwidth.

As a programmer, nothing is needed to enable this feature (other than updating the library version).

Currently, we are using a quite simplistic approach of batching (from all events to be sent during one run of the sending scheduler, just collect events until we either exceed the batch size limit of 50 MB or get one of a different type, then submit them, continue with the remaining events). This might change in the future depending on production experience in our systems.

Bugfix: We also changed a dependency version of Jackson, which had some vulnerabilities (none that could be exploited in our case, we think).

20.0.1: Bugfixes and usability improvements

Bugfix: problems with the initialization order in integration tests, leading to duplicate beans when using the MockNakadiPublishingClient

Usability improvement: It is not needed anymore to annotate your Spring configuration with @EnableNakadiProducer. Just including the jar in your classpath of your spring-boot application is enough. The Annotation has been deprecated and will be removed with the next major release. You may remove it from your applications now.

Bugfix: Submission to Nakadi did not work if the application's Spring configuration was not annotated with @EnableScheduling.

Usability improvement: It is not neccessary to configure nakadi-producer.access-token-uri anymore in Zalando's K8s environment. Please note that you will still need it for local testing.

Usability improvement: If you configure spring.flyway.* but you don't configure all the available keys, the library will now fall back to the equivalent spring.datasource.* configuration. So if you configured something like spring.flyway.url=${spring.datasource.url}, this can now be removed.

20.0.0: Spring Boot 2 Support

We now support Spring Boot 2. We will continue to release Spring Boot 1 based versions, too. Their release numbers will be <= 19.x.x (most recent one at the time of this release is 4.2.0).

Migrating from 4.x to 20.0.0

• versions >= 20.x will only work with Spring Boot 2

• the Actuator endpoint will be mapped to a different path in Spring Boot 2. Please check our docs and the Spring Boot docs to find the exact path (typically /actuator/snapshot-event-creation) (Note: No underscores but dashes). Authentication of management endpoints has also been changed a lot by Spring Boot 2, so you may have a look at their docs for this, too.

• The filter specifier can now be given either as a request parameter or as request body. If you specify it as a request body, the format has changed: {"filter":"myFilter"}

• The Actuator endpoint will now return HTTP status 204 instead of 200.

• You now have to explicitly expose our Actuator endpoints:

  management.endpoints.web.exposure.include=snapshot-event-creation,your-other-endpoints,...

• If you used the NakadiProducerFlywayCallback annotation before, you'll now have to implement an interface with the same name (instead of implementing FlywayCallback) . It's basically just a copy of Flyway's FlywayCallback interface, so there shouldn't be too much to change here.

• The SnapshotEventProvider interface, which was deprecated in 4.1.0, is now gone. Use SnapshotEventGenerator instead.

4.2.0 – Reuse Fahrschein bean if it exists

This release implements #75. This allows to reuse an existing NakadiClient bean (from the Fahrschein library), so you don't need to configure the URLs for Nakadi or the access token retrieval twice. If you don't have a NakadiClient bean, nothing changes.

Upgrading from any 4.* version is straightforward (just update the version number), for upgrades from earlier versions read the previous Release-notes. (Also see version 4.1.2 for a possible issue with a duplicated bean name.)

There might be a problem if you have more than one bean of type NakadiClient – in that case Spring doesn't know which one to inject. You can mark one of them as @Primary to resolve this.

After upgrading, if you have a NakadiClient bean, you can remove all the nakadi-producer specific configurations (nakadi-producer.nakadi-base-uri, nakadi-producer.access-token-uri, and nakadi-producer.access-token-scopes), as they are not used anymore.

4.1.3 – Nakadi scope configuration not needed anymore

This release fixes #78, it is not needed anymore to specify any scopes for the Nakadi access tokens anymore.
Nakadi (at least in Zalando's installation) is not requiring scopes for event submission for over a year anymore, which makes this configuration superfluous. It is now not required anymore, defaulting to just the pseudo-scope uid which is available in every token. If you happen to use a Nakadi installation which still requires scopes, it still works like before.

Upgrading from any 4.* version is straightforward, just update the version number (but see the version notes for 4.1.2 for a possible issue with a duplicated bean). Optionally, you can remove the nakadi-producer.access-token-scopes: uid line in your configuration files.

For upgrades from earlier releases, see the previous release-notes.

4.1.2 – better name for the Nakadi client bean

This release has just #73, which renames the nakadiClient bean to nakadiProducerPublishingClient. This way it is less likely to conflict with other beans of the same name, which might happen if you are using e.g. Fahrschein also directly in your application for reading events.

Upgrading from 4.* versions should be painless (just increase the version number), unless your application happened to already have another bean with the new name nakadiProducerPublishingClient. (In that case you'll have to change the name of that other bean.)
For upgrades from earlier releases, please read the previous release notes.

4.1.1: Bugfix to prevent duplicate event submission

This bugfix release fixes #67, which could – for large amounts of events in the eventlog – send some of the events twice.

Upgrading from the previous version 4.* versions is painless (just increase the version number), for older versions read the previous release notes.

4.1.0: Improved snapshot event generation

Issues #42 and #43: Interface SnapshotEventProvider is deprecated, replaced by SnapshotEventGenerator. You can have multiple of those (one for each event type), which is useful if your application consists of several independent components with their separate events. Its main method also accepts a filtering parameter, which is filled from the Actuator event creation REST endpoint's body parameter – this supports e.g. creating snapshots for just recently modified objects.

How to migrate from 4.0.x

No changes are needed, the old SnapshotEventProvider interface is deprecated, but still supported (without filtering). It might be removed in a future major version (and will be mentioned again then). Replacing it by multiple SnapshotEvenGenerator beans should be straightforward.