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.
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
Added ODM Metadata Inheritance fixes #340 #591
base: main
Are you sure you want to change the base?
Added ODM Metadata Inheritance fixes #340 #591
Changes from all commits
b009d28
bb67501
d29c1b2
2b3048b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
While I agree that we want to resolve inheritance and meta-annotation concerns, I don't think we want to merge multiple
Entry
annotations. The reason is that eachEntry
can come with abase
and it's not clear which should be picked.Instead, it may be valuable to look at Spring Security's
AuthorizationAnnotationUtil#findUniqueAnnotation
for some inspiration on how to resolve the@Entry
annotation while still erroring if the result is ambiguous.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.
There is a use case where say you have a inetOrgPerson class which inherits from a organizationalPerson class which inherits from a person class. If you want to reference inetOrgPersons in one query, but person in another they could have different Entry annotation values. By enumerating through all annotations from the top of the class tree and overriding with subclasses it still allows this behavior.
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 understand the use case for filters, but the
base
value remains ambiguous. Whichbase
should you pick? More importantly, how do you reconcile the fact that you pick abase
from one@Entry
but all the filters from all@Entry
annotations?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 for the long absence. I would argue that the default should be to take the lowest class in the class inheritance tree (closest to the instantiated class type) with the ability for the class writer to disambiguate by defining the base on the subclass.
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 agree with this, and I think it should apply consistently for all of
Entry
's properties. Instead of picking the lowestbase
and merging allobjectClasses
in the type hierarchy, the code should pick the lowestEntry
and use itsbase
andobjectClasses
.This should also apply for
objectClasses
. Otherwise, it is tricky for the subclass to overrideobjectClasses
in the superclasses.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 don't want to get hung up on this feature, and it merits further discussion. Could we create a separate ticket to discuss how
objectClasses
inheritance should work? I'm happy to add to that ticket my thoughts and we can continue the conversation over there.For this ticket, can you please leave inheritance as follows:
@Entry
annotation or meta-annotation@Entry
annotations are consideredThe reason for keeping 3 is that it's clear from the ticket that not collecting all reachable fields is the thing that is primarily surprising to folks.
I'm also happy to update the PR with a polish that does the above if you aren't available. If I don't hear from you within a month or so, I'll proceed as I've described so that it can land in time for the 3.3.0 release.
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 not clear to me the purpose of this change to use
doWithFields
. Is this change necessary to address ODM inheritance?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.
If I recall correctly, clazz.getDeclaredFields(); will only return fields declaired directly in the class and not any inherited fields. the "doWithFields" method will recurse through the type inheritance tree to get all fields annotateed with spring ldap annotations.
https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredFields--