-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add MediaMessage annotation support. #2058
base: main
Are you sure you want to change the base?
Conversation
Supports the ability to define the content type of Message from the client side for resolving.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks interesting, but @MediaMessage
doesn't seem to be correct. Perhaps something like @ResolvableType
?
Also, this needs test coverage.
spring-kafka/src/main/java/org/springframework/kafka/support/resolver/MediaMessageResolver.java
Outdated
Show resolved
Hide resolved
Done, for the name part, maybe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks; it needs some docs; probably in this section https://github.com/spring-projects/spring-kafka/blob/main/spring-kafka-docs/src/main/asciidoc/kafka.adoc#kafkalistener-annotation
Also, maybe a "how to use" here https://docs.spring.io/spring-kafka/docs/current/reference/html/#tips-n-tricks
...ka/src/test/java/org/springframework/kafka/support/resolver/ResolvableTypeResolverTests.java
Outdated
Show resolved
Hide resolved
spring-kafka/src/main/java/org/springframework/kafka/annotation/ResolvableType.java
Outdated
Show resolved
Hide resolved
@artembilan Any thoughts on the annotation name? |
...ka/src/test/java/org/springframework/kafka/support/resolver/ResolvableTypeResolverTests.java
Outdated
Show resolved
Hide resolved
...ka/src/test/java/org/springframework/kafka/support/resolver/ResolvableTypeResolverTests.java
Show resolved
Hide resolved
...ka/src/test/java/org/springframework/kafka/support/resolver/ResolvableTypeResolverTests.java
Show resolved
Hide resolved
@Documented | ||
@Retention(RetentionPolicy.RUNTIME) | ||
@Target({ElementType.PARAMETER}) | ||
public @interface ResolvableType { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is already a org.springframework.core.ResolvableType
.
So, this one is going to confuse.
Plus it doesn't look like we really resolve a type, but talk more about a content-type
.
I'm not fully sure that I follow with the goal of this feature, but probably better to have it as an @ExpectedContentType
since there are many ContentType
classes around 😸 .
I would say this is similar to consumes
on the @RequestMapping
, but you really have here a fallback to the expected if no one provided in the record.
Anyway I'd like to understand better what is going on.
Looks like you want to have a common composite converter and choose an appropriate one according the content-type
header or fallback.
How about have an attribute on the @KafkaListener
instead? Kinda fallbackContentType
?
Populate it to the message (if needed) and still rely on that composite ability to choose an expected converter.
Just thinking aloud...
Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, Artem, for your perspective; I agree coercing the content type in the listener adapter via a @KafkaListener
property would be better than polluting the method signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, Artem, for your perspective; I agree coercing the content type in the listener adapter via a
@KafkaListener
property would be better than polluting the method signature.
In spring, annotation on parameters is very common, I think it can not treat as polluting the method signature, for example @RequestBody
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but we already have enough param annotations to pollute enough.
And your idea makes me think that this kind of fallbackContentType
should go to the existing @Payload
annotation which we rely in Spring Kafka as well.
But again: your current goal could be achieved with an explicit converter for the particular @KakfaListener
. The rest I believe is already covered by the composition if contentType
header is present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hah, @Payload
annotation is in org.springframework.messaging
package but not this project, I treat the @MediaMessage
as an enhanced annotation for spring-kafka
.
I know it was covered if contentType
header is present, but sometimes, you can not control the producers for which message they will send.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks; it needs some docs; probably in this section https://github.com/spring-projects/spring-kafka/blob/main/spring-kafka-docs/src/main/asciidoc/kafka.adoc#kafkalistener-annotation
Also, maybe a "how to use" here https://docs.spring.io/spring-kafka/docs/current/reference/html/#tips-n-tricks
I will fulfill the docs after you make your decision.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, Artem, for your perspective; I agree coercing the content type in the listener adapter via a
@KafkaListener
property would be better than polluting the method signature.
Would you need me also to implement this idea?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, and why we should implement such a feature only in Spring for Apache Kafka?
Why other projects cannot benefit from the feature? For example Spring AMQP, Spring Cloud AWS. Spring Integration at all, at last. And so on. The same @MessageMapping
for WebScokets and RSockets.
That's why I'm talking about that @Payload
as a general place for such a fallback option.
But again: I believe even fallback option can be implemented right now with just a composition with desired converter in the end of chain.
I even think something like this is resent in Spring Cloud Stream with its JSON converter as a fallback.
I really against new annotations because end-user needs to know what to look for. With just a new attribute on the well-known @KafkaListener
he/she gets a clue what is possible.
However independently of the end-user hook for the method, they still need to support an infrastructure for converter composition and so on.
I guess we need to think more what and how could be done and where.
Right now I'm not fully convinced in a new annotation, but I'm opened for arguments anyway.
Thanks for understanding
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I agree that the other projects have the rights to benefit from this.
they still need to support an infrastructure for converter composition and so on.
I do want to add this in default configuration, but maybe we should consider how to implement this first, then consider should or not should to add this support feature as a default.
I will wait for your decision, feel free to comment your ideas.
Supports the ability to define the content type of Message from the client side for resolving.
Usage example: