Matej Novotny
Matej Novotny
> Personally, I wouldn't expose the assignability rules directly, as that's too low-level. For the scenario presented here, the annotation comparison is trivial, so it boils down to type assignability....
@Ladicek I don't think this meets the requirements of the scenario @JHahnHRO drafted. > Specific use case that I have in mind: I'd like to add to the CDI container's...
The first one (same as Arc has) is better because you can have several impls of any given context, all of which are for same scope annotation and can have...
Hmm, I see. But I still think it might be easier to just skip that OM part. It is not that low level either since spec has all these rules...
> Would a hypothetical `getContexts(Class
> The problem with a `java.lang.reflect.Type` subtype parameter is that it's not type-safe. I think there was a similar discussion for `javax.enterprise.inject.Instance` in JIRA and the result was a non-portable...
@rmannibucau @Ladicek this issue sounds like something we should consider for https://github.com/jakartaee/cdi/issues/622, WDYT?
@Ladicek do you intent do include this in the next release or is it just planning issue?
> Alternatively, a producer with @Priority could be enabled even if its declaring bean is disabled, but that would likely interfere with ambiguity resolution, specialization, and probably a few other...
I have seen this debated repeatedly with arguments for and against self-interception. There are already conflicting implementations - Weld does not do self-interception (in fact it does quite some hacks...