-
Notifications
You must be signed in to change notification settings - Fork 38k
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
Provide more declarative control over reflection hint registration #29194
Comments
It may not looks like, but this issue is IMO more complex than it looks like, so let's have a deep dive. If we want to start simple, having something like It could be tempting to unify the model and describe as suggested by @wilkinsona
Now, I would like to understand a little bit more the use case described.
My 2 questions related to that use case are:
|
For the types returned by Boot's actuator endpoints we only need reflective access to the getter methods that are used by Jackson to serialise them to json. As such, I expect that This is just one use case of course. My hope was that we could provide a single, easy to use mechanism for registering reflection hints. If we offer both |
For From Spring Native days, one lesson learnt is that binding and reflection based serialization is almost always much more tricky than expected because:
If you prefer something laser focused on exactly what you need like registering with deep control, you can just implement it in a programmatic Now, should we introduce more declarative hint registration capabilities? Potentially, but I am not sure we have enough time and strong and various enough use cases yet to take the right decisions:
So today we have 2 strong use cases with RC1 freeze is tomorrow and RC2 is already packed with challenging issues like the GraalVM 22.3 upgrade so fixing this issue for GA sounds like not possible to me (apology for not having processed this issue earlier but I was on other topics). I am not opposed to introduce something in one of the |
I'd like that we take an hour to brainstorm together about what can be done. IMO it would be a shame to lose the opportunity to do something before 6.0 GA. |
We could maybe support something like:
|
Just my 2 cts (view it as a "think aloud test" protocol of the humble spring boot developer): I'd like to have the Effect of Background Story: Working with Quarkus I am used to just pin an " I expected " It seems to work with |
Please consider auto reachability of |
If I'm not mistaken we already support reflection hints on Flux and Mono types on controllers to some extent.
What do you mean by springdoc api docs generation? Are you referring to this project? If so, this is not supported by the Spring team and if native support has issues with it then you should report that problem directly to the maintainers. |
@bclozel in the below example unless we add
We are having real difficulty adding |
@syedyusufh I'm not sure I understand - why would you need reflection on return types from a Service method? This is only necessary if the returned value needs JSON serialization, for example. We do this automatically for all Controller methods (including parameterized types); you can see it in action in our smoke tests. This is applied automatically by our This issue is about providing refined mechanisms in case it is not easy to detect the types at the method level, or if the required hints are different from what's provided by In your case, maybe you shouldn't have to add all those annotations because:
Could you answer the following?
|
I did two exercises following the below sequential steps, Sequence-A:
Sequence-B:
If I compare the The above missing DTO are all for Regarding the springdoc api-docs, it was just a reference where we use If I could ask in one liner, is there a plan or can it be considered as a feature request to autodetect and register all the DTOs without any custom Thanks |
@syedyusufh as mentioned in my previous comment this is already supported. We do not use the tracing agent and rely on our own AOT process. If you can reproduce an issue where a DTO cannot be serialized from a controller endpoint (even a reactive one), please create a new issue here and provide a minimal sample application that we can run. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This commit introduces a declarative way of registering reflection information for arbitrary types. Types can be specified as a class, a class name, or by annotating the type itself. This existing RegisterReflectionForBinding becomes a specialized version of the new annotation, registering the necessary hints for data binding. Closes spring-projectsgh-29194
We've introduced a After a bit of a back and forth the existing The next piece of the puzzle is to ease the inclusion of non-beans as target of this annotation. See #33132. |
Affects: 6.0.0-M6
For declarative registration of reflection hints, we currently offer
@Reflective
and@RegisterReflectionForBinding
. These two options, particularly when used at the type level, sit at two opposite ends of the spectrum.@Reflective
on a type will register a hint for the type and nothing more.@RegisterReflectionForBinding
on a type will register hints for the type, its constructors, fields, properties, and record components for the whole type hierarchy. Sometimes we want something in between. That means you either write your ownReflectiveProcessor
or you accept that@RegisterReflectionForBinding
will do the job at the cost of some unnecessary hints.A concrete example of the above can be found in some of Spring Boot's actuator endpoints. We have types that need to be serialised to JSON that can't be discovered by
@Reflective
at the method level. This can be because a method returns something quite loosely typed likeMap<String, Object>
orMap<String, Thing>
where there are multiple differentThing
sub-classes. I'd like to be able to annotate the endpoint type with something that registers additional types for a certain kind of reflection:We could take some inspiration from
@RegisterForReflection
in Quarkus.The text was updated successfully, but these errors were encountered: