-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Improve message body handlers #11002
Conversation
test-suite/src/test/java/io/micronaut/docs/server/consumes/ConsumesControllerSpec.java
Outdated
Show resolved
Hide resolved
http-netty/src/test/groovy/io/micronaut/http/netty/body/CustomBodyReaderSpec.groovy
Outdated
Show resolved
Hide resolved
http/src/main/java/io/micronaut/http/body/DynamicMessageBodyWriter.java
Outdated
Show resolved
Hide resolved
http-client/src/main/java/io/micronaut/http/client/netty/DefaultHttpClient.java
Outdated
Show resolved
Hide resolved
http-client/src/main/java/io/micronaut/http/client/netty/DefaultHttpClient.java
Outdated
Show resolved
Hide resolved
http-client/src/main/java/io/micronaut/http/client/netty/FullNettyClientHttpResponse.java
Show resolved
Hide resolved
http-netty/src/main/java/io/micronaut/http/netty/body/NettyByteBufMessageBodyHandler.java
Outdated
Show resolved
Hide resolved
http-netty/src/main/java/io/micronaut/http/netty/body/NettyTextPlainHandler.java
Outdated
Show resolved
Hide resolved
* @return This headers | ||
* @since 4.6 | ||
*/ | ||
default MutableHeaders setIfMissing(CharSequence header, CharSequence value) { |
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 calls add
so should be named addIfMissing
. Add nullability annotations to the arguments and null check the header
argument
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.
That an alternative to the method above called set
which will remove the previous value
http/src/main/java/io/micronaut/http/body/AbstractMessageBodyHandlerRegistry.java
Outdated
Show resolved
Hide resolved
*/ | ||
@Requires(bean = ByteBufferFactory.class) | ||
@Singleton | ||
@BootstrapContextCompatible |
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.
can we reduce the number of bean definitions with a registrar type pattern?
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.
Don't think so
http/src/main/java/io/micronaut/http/body/MessageBodyHandlerRegistry.java
Outdated
Show resolved
Hide resolved
MediaType.APPLICATION_JSON_PATCH, | ||
MediaType.APPLICATION_JSON_MERGE_PATCH, | ||
MediaType.APPLICATION_JSON_SCHEMA | ||
}) |
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.
should this be configurable?
MediaType.APPLICATION_JSON_PATCH, | ||
MediaType.APPLICATION_JSON_MERGE_PATCH, | ||
MediaType.APPLICATION_JSON_SCHEMA | ||
}) |
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.
should this be configurable?
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.
Maybe, but for now it's not, I just create this annotation to reduce repeated code
…tPlainHandler.java Co-authored-by: Jonas Konrad <jonas.konrad@oracle.com>
…BodyReaderSpec.groovy Co-authored-by: Jonas Konrad <jonas.konrad@oracle.com>
@JsonMessageHandler.ProducesJson | ||
@JsonMessageHandler.ConsumesJson | ||
@Internal | ||
public final class NettyRawJsonStringWriter implements MessageBodyWriter<CharSequence>, MessageBodyReader<String>, NettyBodyWriter<CharSequence>, ChunkedMessageBodyReader<String> { |
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.
why do we need separate writers per content type for this now? old behavior was that for these "raw types", the body would always be written the same way, regardless of content type
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.
Not sure 100% how did it work before.
Without this the object type JSON writer will pick it up and convert it into the JSON.
This writer is more correct because we actually want to convert strings as a plain text instead of wrapping it.
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.
Hm, you removed RawMessageHandlerRegistry, but didn't replace the lookup logic. I only see it in the ContextlessMessageBodyHandlerRegistry.
The old logic is very simple: If the type has a RawMessageHandler, that handler is used no matter what. This is the behavior from 3.x and it is the behavior we need to keep.
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.
Raw handlers were internal. Why would you disallow custom handlers?
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.
The problem is if you want to handle the type in a different way. I don't think it's a problem if a user defines a custom handler, he chooses to change the behaviour.
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.
why can't we just have the old behavior?
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.
Bacase that is esentially broken for writers that don't use textual formats like protocol buffers.
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.
that's how it's always been. If you want to change it, do so in 5.0.
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.
So actually it was working like that anyway, there is no need for an extra string json handler. Removed unneeded handlers and added tests.
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!
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.
see above comment on raw handlers
Quality Gate failedFailed conditions See analysis details on SonarCloud Catch issues before they fail your Quality Gate with our IDE extension SonarLint |
String
handler of a different media typeType*
reader/writer that include an argument.@Bean(typed=
)