-
Notifications
You must be signed in to change notification settings - Fork 40.8k
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
Configure JpaBaseConfiguration with custom ManagedClassNameFilter #39813
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unintuitive.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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'sWebMvcConfigurer
. 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
.