The PulsarBinder relies on the Spring Pulsar Spring Boot starter.
The starter moved out of the spring-pulsar core repo and into
Spring Boot proper. This commit updates the Pulsar binder to
use the new coordinates for the Spring Boot based starter.
* Additionally, the PulsarProperties were greatly reduced in the
move to Spring Boot. As such, the binder exposes an extended
set of config properties for producer/consumer (the initial
set supported before the property reduction).
If a target middleware (Kafka for ex) topic has more partitions
than what is set on the partition-count producer property, the binder
never updates the original producer partition-count property to the
partition count from the middleware if it is higher than what was given
through the property. Because of this, te PartitionAwareFunctionWrapper
which evaluates and assigns the partition header in Spring Cloud Stream
does not compute the correct partition since the hash operation still
using the original partition-count from the producer binding property.
This commit is addressing this issue.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2796
When building in AOT mode, the BinderChildContextInitializer is unable to get access
to a SpEL expression conversion service in order to properly bind spring.cloud.stream
prefixed properties with values containing SpEL expressions such as headers[partition-key-expression].
However, we don't need to bind at this level of generality (spring.cloud.stream.*) in the
BinderChildContextInitializer since we are only looking for the user defined binders there.
To fix the issue, this commit explicitly binds only the spring.cloud.stream.binders.* properties
and ignores any other binding properties via spring.cloud.stream prefix. Any such conversions
will be done in later phases after the binder contexts are created.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2799
If kafka truststore and keystore locations are not local files, then they
are converted to org.springframework.core.io.Resource resources, then copied
to local file system. This means that, paths can be defined as HTTP resources too.
Currently, the Kafka binder only supports CLASSPATH based resources. It would be
useful if we can support non-CLASSPATH like resources such as HTTP, so that if an
application uses config server for example to store certificates, then those will
be copied from it's HTTP endpoint to the local filesystem as Resources.
Checkstyle, documentation fixes.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2761
There was a regression introduced in Spring Cloud Function where consumers
of type Consumer<Message<?>> receive null values when tombstone records
are given as KafkaNull.
See this issue for more details: https://github.com/spring-cloud/spring-cloud-function/issues/1060
Regression is addressed in Spring Cloud Function and
making the corresponding test changes in Spring Cloud Stream Kafka binder.
- Insted of unconditionally initializing KafkaJaasLoginModuleInitializer,
only create it, if jaas properties are set properly. By creating it always,
we unncessarily expose Java security related class requirements to the binder
apps. For e.g. if the underlying JVM security classes change and require
reflection, that could break AOT apps that don't use a secure Kafka cluster.
Fixing these type of issues by creating KafkaJaasLoginModuleInitializer only if required.
* Added example to identify Kafka error
* removed implementation and added doc links and added bean example
* changed doc link to the official doc
* Added custom message in the down status of the actuator
