You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spring CloudEventMessageConverter content-type header name uses the Spring Messaging contentType header name which differs fom the cloud events spec content-type which is used by Kafka serializer for instance.
This leads to a message from a project using structured mode and kafka serializer (sdk-kafka) to not be deserialized by another project using (sdk-spring).
The current code is as follows on sdk-spring:
if (message.containsKey(MessageHeaders.CONTENT_TYPE)) {
returnString.valueOf(message.get(MessageHeaders.CONTENT_TYPE));
}
if (message.containsKey(CloudEventsHeaders.CONTENT_TYPE)) {
returnString.valueOf(message.get(CloudEventsHeaders.CONTENT_TYPE));
}
Unfortunately the CloudEventsHeaders.CONTENT_TYPE is CE_PREFIX + "datacontenttype" which is not exactly the same property we are looking here.
I would be happy to create a merge request where a another fallback is introduced to have the spec header name (content-type) which would enable the sdk-spring to deserialize messages.
This would add the support while still keeping it compatible with different versions and services.
Ideally, also the spring-sdk serializer should be checked and changed, but i would rather have this small mr fixed and dive on the serializer in a different issue.
The text was updated successfully, but these errors were encountered:
Spring CloudEventMessageConverter content-type header name uses the Spring Messaging
contentType
header name which differs fom the cloud events speccontent-type
which is used by Kafka serializer for instance.This leads to a message from a project using structured mode and kafka serializer (sdk-kafka) to not be deserialized by another project using (sdk-spring).
The current code is as follows on sdk-spring:
Unfortunately the
CloudEventsHeaders.CONTENT_TYPE
isCE_PREFIX + "datacontenttype"
which is not exactly the same property we are looking here.I would be happy to create a merge request where a another fallback is introduced to have the spec header name (content-type) which would enable the
sdk-spring
to deserialize messages.This would add the support while still keeping it compatible with different versions and services.
Ideally, also the spring-sdk serializer should be checked and changed, but i would rather have this small mr fixed and dive on the serializer in a different issue.
The text was updated successfully, but these errors were encountered: