Hi,
I'm hoping I could ask a few questions about some of the CDI interfaces.
I'm adapting an injection framework I've been developing on and off for
the past years to be compatible with a minimal subset of CDI: The
"Instance" type and the types it refers to (Handle, Bean,
InjectionPoint, BeanAttributes). The framework is tailored to my
personal needs, but is quite extensive, supporting scopes, producers,
assisted injection, optional injection, providers, lists and sets. It
allows for custom annotation strategies and extensions, and I'm seeing
if it can support CDI style injection simply by configuring it
differently. When implementing `Instance` however I noticed quite some
internal structures are exposed (`Handle` exposes `Bean` which then
exposes a whole host of other classes and interfaces).
I have a few questions regarding those interfaces:
1) How does an InjectionPoint handle an implicit dependency on an owner
class (container class)? For example, when you have a non-static
Producer method, it can only be called after its owner class is
instantiated. The Producer's parameters are injection points, but my
framework also lists the owner class as an injection point, representing
the "this" parameter that is implicitely needed for calling a non-static
Producer method. For such an injection point, my implementation returns
`null` for `getMember()` to indicate the injection point represents the
owner class. How is this handled in CDI?
In CDI, a producer method/field has to be declared in a CDI Bean.
And in order to invoke the non-static producer (i.e. create the bean from it), CDI will need to first instantiate the bean that it is declared in (the "owner class").
I don't fully follow the scenario you are trying to describe, are you talking about self injection?
All I can tell is that `getMember()` isn't returning `null` in any case - it should be either Field,Method or Constructor (according to javadoc).
2) The BeanAttributes class has a `getQualifiers` method. Does this
include qualifiers detected in any stereotypes it might be annotated
with? What's the reasoning behind listing stereotypes separately?
Similar question for `getScope` although I'm assuming there that it must
be getting the scope from the stereotype (if present and not overriden).
Yes, it includes those as well. And if I am not mistaken, you'd even see any programmatically added annotations there (i.e. added via extensions).
Think of BeanAttributes as a complete view of bean's metadata.
The reason stereotypes are there is because they are also a kind of metadata related to a bean and because they can carry information about its bindings, qualifiers or scope.
And some of its information cannot be found elsewhere due to inheritance rules - for instance a stereotype can declare a scope such as @RequestScoped but the bean itself then declares @ApplicationScoped.
The resulting scope (stored in BeanAttributes) is @ApplicationScoped and you'd need to introspect the stereotype to learn that there was some other scope.
3) Is `BeanAttributes#getScope` allowed to return `null`? In CDI Beans
always have a scope, even if it is just `Dependent` AFAIK. My own
implementation does not return the annotation, but instead immediately
returns the appropriate `ScopeResolver` which is never `null` even for
unscoped beans -- when not annotated, the annotation would be `null` though.
Every bean has to have a scope, so the answer is no.
Even if there is no explicit annotation, it defaults to @Dependent scope which is so called pseudo-scope but scope nonetheless.
4) `BeanAttributes#getName` seems to allude you can return `null` here
if it has no name, or is it supposed to return an empty string in that case?
Yes, this can be null.
The name is linked to @Named which is a kind of special qualifier in CDI and it represents an EL name of the given bean so based on your implementation you might not care about it at all.
Best regards,
John Hendrikx
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
