On 17. 10. 24 18:29, Laird Nelson wrote:
On Thu, Oct 17, 2024 at 9:11 AM Martin Kouba <mkouba(a)redhat.com
<mailto:mkouba@redhat.com>> wrote:
On 17. 10. 24 17:13, Laird Nelson wrote:
> Why, then, does the InjectionTarget interface have a
> getInjectionPoints() method?
So that it's possible to access the metadata about all injection points
of a specific InjectionTarget.
Why, in this case, then, would Weld care at all, since I'm responsible
for injection? Why would it need to read this metadata that describes
things that it is not going to work on? (I still don't understand why
getInjectionPoints() exists on a producer if the producer is wholly
responsible for injection.)
It's not only for Weld but for other extensions too. There can be
multiple ProcessInjectionTarget consumers. It could be useful to know
what injection points are currently registered. But like I said these
APIs are IMO powerful but also quite dangerous, and to some degree also
"incomplete".
In theory, an arbitrary injection point does not have to provide a
valid
member.
Could you explain more? Do you mean that
https://jakarta.ee/specifications/cdi/4.0/apidocs/jakarta.cdi/jakarta/ent...
<
https://jakarta.ee/specifications/cdi/4.0/apidocs/jakarta.cdi/jakarta/ent...
could return null or a no-op or something else without violating the contract? Where can I
read more about that?
An extension can return any field/method/constructor. The spec does not
state what happens if you return an invalid member from
InjectionPoint.getMember().
The spec does not even state that InjectionPoint.getMember() must be
used when performing injection.
But again, the spec wording is clear - it's up to the InjectionTarget
implementation.
Thanks; I see that now. I wish I fully understood why. To put it in
concrete terms, if org.jboss.weld.util.Beans had an
injectInjectionPoints() method alongside its
injectFieldsAndInitializers() method Weld could work with custom
injection targets out of the box.
Fortunately Weld provides the InjectionServices plugin which has all the
information needed to permit this kind of enhancement, I think. Thanks
for your time.
The more I'm thinking about this use case the more I think it does not
make sense to reflect the output of getInjectionPoints() from the
replacing IT in the original/previous IT. Imagine that there's another
extension that replaced the InjectionTarget before your extension does.
Then the IT you're delegating to does not need to be the original Weld
implementation at all.
L
--
Martin Kouba
Principal Software Engineer
Red Hat, Czech Republic