Matej Novotny
Matej Novotny
I see. So ATM we seem to have two methods on `BeanManager`: * `public ELResolver getELResolver();` * `public ExpressionFactory wrapExpressionFactory(ExpressionFactory expressionFactory);` Plus an entry in `module-info` (which, IIUIC, is a...
Ah ok, I thought you were talking about solution on CDI spec level.
We discussed this during CDI meeting with the following notes: * No immediate action is needed in CDI, this is workarounded by Jakarta core profile * In the future, we'd...
This issue is long overdue but still valid for CDI 4.0 - https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#after_deployment_validation Will add it to the tracking issue for next version, see https://github.com/jakartaee/cdi/issues/622
EL API has very little usage in CDI - two methods altogether IIRC. Separating that would be fairly easy. I've also added comment to https://github.com/jakartaee/cdi/issues/640#issuecomment-1351212663
> > This however broke in some version of Weld. > > I'd say that's probably a bug, but I'll let @manovotn comment on that :-) That sounds like a...
There is already several sets of runtime assignability rules in place - at least one for beans and another for events. And with CDI Lite, implementations are likely to have...
For the time being, I'd suggest grabbing resolution rules from an impl that fits your case (runtime/build time) as the feature you are implementing will be only in that space...
> and I could just store them in some field in the Extension and extract them later by injecting the Extension somewhere This is one of the main reasons why...