Skip to content
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

Merged
merged 12 commits into from
Jul 23, 2024
Merged

Improve message body handlers #11002

merged 12 commits into from
Jul 23, 2024

Conversation

dstepanov
Copy link
Contributor

  • Previous raw handlers didn't allow to define a custom String handler of a different media type
  • Raw handlers replaced by Type* reader/writer that include an argument.
  • Extracted raw handlers to a separate writer / reader bean (no need to hide them with @Bean(typed=)
  • Improved how dynamic body writer works, it will be always included from the registry for object types
  • Introduced a separate writer/reader for a String and a JSON type. That is simply threads it a plain type.
  • Small corrections

core/src/main/java/io/micronaut/core/type/Argument.java Outdated Show resolved Hide resolved
* @return This headers
* @since 4.6
*/
default MutableHeaders setIfMissing(CharSequence header, CharSequence value) {
Copy link
Contributor

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

Copy link
Contributor Author

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

*/
@Requires(bean = ByteBufferFactory.class)
@Singleton
@BootstrapContextCompatible
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think so

MediaType.APPLICATION_JSON_PATCH,
MediaType.APPLICATION_JSON_MERGE_PATCH,
MediaType.APPLICATION_JSON_SCHEMA
})
Copy link
Contributor

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
})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be configurable?

Copy link
Contributor Author

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

@JsonMessageHandler.ProducesJson
@JsonMessageHandler.ConsumesJson
@Internal
public final class NettyRawJsonStringWriter implements MessageBodyWriter<CharSequence>, MessageBodyReader<String>, NettyBodyWriter<CharSequence>, ChunkedMessageBodyReader<String> {
Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

@dstepanov dstepanov Jul 23, 2024

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

Copy link
Member

@yawkat yawkat left a 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

Copy link

sonarcloud bot commented Jul 22, 2024

Quality Gate Failed Quality Gate failed

Failed conditions
2 New Bugs (required ≤ 0)
1 New Blocker Issues (required ≤ 0)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

@graemerocher graemerocher merged commit f4a7f9d into 4.6.x Jul 23, 2024
12 of 16 checks passed
@graemerocher graemerocher deleted the rawhan branch July 23, 2024 12:32
@graemerocher graemerocher added the type: improvement A minor improvement to an existing feature label Jul 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: improvement A minor improvement to an existing feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants