Repository navigation
Optimize the PreciseBeanType recipe and add type exclusion functionality #1148
Description
What problem are you trying to solve?
I used the org.openrewrite.java.spring.boot3.PreciseBeanType recipe from Spring Boot 3 in a Spring Boot 4.1.1 project, and it works fine. But I ran into some problems.
This recipe does not support passing in parameters to ignore certain types. Some types naturally do not need to care about the actual type, because they may be produced by factory patterns or builder patterns, or it is not advisable to hard-code an association with the actual type.
For example, Spring Security's org.springframework.security.web.SecurityFilterChain is built by org.springframework.security.config.annotation.web.builders.HttpSecurity, and the actual type is org.springframework.security.web.DefaultSecurityFilterChain, but generally we would not explicitly write this type; using the interface is enough.
Another example is Spring Batch's org.springframework.batch.core.step.Step, which is also produced through a builder, but it produces different types depending on different parameters, such as org.springframework.batch.core.step.item.ChunkOrientedStep or org.springframework.batch.core.step.job.JobStep, and so on. It is not just these two.
Also, Spring Integration's org.springframework.integration.dsl.IntegrationFlow
In this case, should it still return the actual type? Or has the official framework already adapted to this, so using the interface is enough?
Describe the solution you would like
- I hope this recipe can provide an exclusion parameter to exclude certain types, so that these types are not converted to the actual returned type.
- Or, further, in addition to the exclusion parameter proposed in point 1, it could also include by default some other types from Spring frameworks for exclusion.
Other ideas
This optimization recipe only appears in Spring Boot 3. Is it not recommended for higher versions? Or is it placed in the Spring Boot 3 best practices configuration to prevent developers below this version from using it freely?
I feel this recipe should be applicable beyond just the Spring Boot 3 scope.
Activity
Akhil-1527 commentedon Sep 26, 2026
I'd like to work on this.
My plan is to add an optional
excludedTypesoption toPreciseBeanTypethat takes fully qualified type names. If a@Beanmethod's declared return type is in that list, the recipe leaves the method alone, so aSecurityFilterChainbean that returnshttp.build()staysSecurityFilterChaininstead of becomingDefaultSecurityFilterChain. When the option isn't set nothing changes, so the best practices composite keeps working as it does now.The second idea, skipping a few Spring types by default (
SecurityFilterChain,Step,IntegrationFlow), would change what the recipe does today, so I'd leave that out unless you'd like it included. Does this approach sound good?zhujianxintian commentedon Sep 27, 2026
@Akhil-1527
My thoughts are that the
excludedTypesin the first point definitely needs to exist, as that is the most flexible approach, and developers can also add custom types.As for the second point, as a user of the library, I would very much like that, because then the work of maintaining certain types can be handled by the library, and projects using the library will not need to define them repeatedly.
However, the second point also has issues. In the future, some types in the default list may be removed, added, or modified according to version changes. But personally, I feel there should not be too much of a problem. These types generally do not change for a long time, so the maintenance cost is low. Moreover, even if the update is not timely,
excludedTypescan still be used as a supplement.If you are considering compatibility issues, you can actually add a boolean value, defaulting to false, for whether to enable exclusion of certain special Spring types. That way, compatibility can also be achieved.
In my opinion, the first point basically needs to be implemented. Whether the second point is implemented depends on your consideration of whether to take my suggestion (personally, I still hope it can be implemented when the impact is small and the maintenance cost is low).
Akhil-1527 commentedon Sep 27, 2026
Thanks, that makes sense. I opened #1157 with
excludedTypes. I left the default list out for now and mentioned it in the PR, so the maintainers can decide whether they want it in the recipe itself.