HSEARCH-5235 WIP: draft of injecting field references #4451
Conversation
| @@ -154,6 +157,8 @@ public void configure(MappingBuildContext buildContext, PojoMappingConfiguration | |||
| new PojoAnnotationTypeMetadataDiscoverer( contributorFactory, alreadyContributedTypes ); | |||
| collector.collectDiscoverer( discoverer ); | |||
| } | |||
|
|
|||
| injectableBinderCollector.processDiscoveredBinders(); | |||
There was a problem hiding this comment.
I've tried a few things and here's where I ended up so far 😃
My thinking is that since we want these new binders as a way to have annotated properties so we can read that info in an AP, it seems that making them "available" through the programmatic mapping probably doesn't make that much sense...
Hence, I thought that we could "detect" used binders when an annotation processor (current Search ones to get info from annotations) use a corresponding binder method ( which matches the case when a user adds a binder. So it'll include those coming from programmatic API too ... but IDK if we should just prohibit that use from the programmatic mapping or simply "fail nicely"). Then, once we "discovered" all annotations, we process the info we collected on binders by creating "something" that later will be able to inject required fields into a binder instance.
Since binder metadata (fields to inject) will not change depending on where the binder is used, we can have an instance per type rather than per occurrence.
Then, the injection of fields happens here right before the bind method is called. We do have that delegating binder, which creates a bit of a problem since we cannot simply get our hands on the actual binder instance. I've worked around that for now by updating the delegating binder.
I've started by trying to reuse our annotation processors and basically building an "index model" for a binder but discarded that idea as it didn't work out that nicely 😄
Thinking more about it, for an annotation processor ... we won't be able to rely on user custom annotations and their processors anyway... so in this patch, I've just put together some simple processing to get the required data to create a field reference just for this injection part... thinking even more about it since we will be limiting the number of processors to a specific subset maaaybe I could make it work (reuse current processors at least partially).
Speaking of custom annotations... that's something that also won't play nice with the static metamodel, I suppose, unless we also do some similar "injection of field references" there, too ....
Does that sound to you like the direction to keep exploring @yrodiere ? or should I revisit the approach 😃 🙈
There was a problem hiding this comment.
Sorry I won't be able to review this before I'm back in January, but here are a few answers...
My thinking is that since we want these new binders as a way to have annotated properties so we can read that info in an AP, it seems that making them "available" through the programmatic mapping probably doesn't make that much sense...
I think it could make sense in some cases. E.g. if parts of your mapping are static (so you'll be able to use a static metamodel) and others are not, and if you need similar binders in both cases: it'd be nice to be able to use the same binder in both places.
Even if that was not true, I think we probably want (eventually) to have a single way to implement binders, just to reduce the maintenance burden on our side...
Hence, I thought that we could "detect" used binders when an annotation processor (current Search ones to get info from annotations) use a corresponding binder method ( which matches the case when a user adds a binder.
I don't understand this, I need to have a look at the code.
Since binder metadata (fields to inject) will not change depending on where the binder is used, we can have an instance per type rather than per occurrence.
I think.we talked about some dynamism involving an expression language, which might change a few things such as analyzers based on where the binder is used ?
We do have that delegating binder, which creates a bit of a problem since we cannot simply get our hands on the actual binder instance. I've worked around that for now by updating the delegating binder.
We could reasonably add a new limitation that binders -- at least those using injected fields -- cannot be CDI beans. That would probably remove the need for delegating binders. Maybe.
Speaking of custom annotations... that's something that also won't play nice with the static metamodel, I suppose, unless we also do some similar "injection of field references" there, too ....
I think the current way to implement custom annotations won't work. But yes we can find a way -- later.
There was a problem hiding this comment.
Oh yeah sure 😃 I only wanted to put those few notes so I don't forget about them 🙈 let's definitely leave this discussion for the new year 😃
I think.we talked about some dynamism involving an expression language, which might change a few things such as analyzers based on where the binder is used ?
Right.. we did. I think in that case the dynamic part will come from the parameters, which we will have at the binding time, so my plan so far, was to pass those to the "injector" (at binding time) and it will do the work. But yes - let's get back to that next year 😃
There was a problem hiding this comment.
And thank you for the answers 😃
marko-bekhta
force-pushed
the
feat/HSEARCH-5235-Custom-annotations-and-binders-compatible-with-javacs-annotation-processor
branch
from
4e062a6 to
a6d1f74
Compare
https://hibernate.atlassian.net/browse/HSEARCH-5235
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.