Configure JpaBaseConfiguration with custom ManagedClassNameFilter #39813
Conversation
spring-projects-issues
added
the
status: waiting-for-triage
| String[] packagesToScan = getPackagesToScan(beanFactory); | ||
| return new PersistenceManagedTypesScanner(resourceLoader).scan(packagesToScan); | ||
| return new PersistenceManagedTypesScanner(resourceLoader, managedClassNameFilter.getIfAvailable()) |
There was a problem hiding this comment.
I wonder if we should support multiple filters and create a composite. For consistency with exposing actuator endpoints, exclude would take precedence over include. In other words, a class name would have to be matched by every filter for it to be included.
There was a problem hiding this comment.
a class name would have to be matched by every filter for it to be included.
It's unintuitive.
There was a problem hiding this comment.
It's hard to continue a discussion as you haven't described why you think that it's unintuitive. As I said above, this is how the actuator endpoints behave and that seems to be serving us well. I think the consistency would be a good thing.
There was a problem hiding this comment.
My apologize, as typical spring framework user, I’m expecting one bean available for injection, If multiple beans need to be composed, application should write a primary composite implementation they can take over the control, not hardcoded AND or OR.
l said unintuitive because I don’t know If actuator endpoints doing that way if you don’t mention it.
There was a problem hiding this comment.
Thanks, @quaff. So it's more the support for multiple beans that you find unintuitive rather than how the composite created from those multiple beans would behave.
There are other places where multiple beans are supported, such as Boot's various …Customizer callbacks and things like Framework's WebMvcConfigurer. I guess we could stick with support for a single filter for now and add support for automatically composing them in the future if there's demand for it. It side-steps the need to decide if it'll be AND vs OR which is certainly a benefit.
There was a problem hiding this comment.
@snicoll do you have an opinion here? Do you think there's likely to be a need for multiple filters that we compose automatically or will most users' needs be served by supporting only one. I think I'm now leaning towards only handling one in the auto-configuration.
There was a problem hiding this comment.
Sorry, I read that and meant to reply and I forgot about it. I honestly don't know but I'd prefer that the decision is in a central place. If users need to have multiple filters for whatever reason, I'd prefer them to do the gathering rather than us.
There was a problem hiding this comment.
Sounds like we should stick with a single bean for now. Perhaps some helper factory methods can be added ManagedClassNameFilter if composing filters turns out to be a common need? E.g. ManagedClassNameFilter.allOf(f1,f2,f3).
philwebb
added
type: enhancement
Update `JpaBaseConfiguration` to configure a `ManagedClassNameFilter` if one is available. See gh-39813
This commit documents the support of ManagedClassNameFilter that was added in spring-projectsgh-39813.
This commit documents the support of ManagedClassNameFilter that was added in spring-projectsgh-39813.
This commit documents the support of ManagedClassNameFilter that was added in spring-projectsgh-39813. See spring-projectsgh-40617
Fix GH-29193