Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdi-dev] CDI future - problems and proposal

Hi,

On Wed, Oct 21, 2020 at 8:49 PM Tomas Langer <tomas.langer@xxxxxxxxxx> wrote:
The only problem I see if an extension creates an actual synthetic bean instance (e.g. a class implementing Bean<X>), and registers it in AfterBeanDiscovery using the addBean(Bean) method.
If that is the use case you refer to, then I understand that you may be in trouble when it comes to interceptors (though a lot of cases may be covered by `BeanConfigurator addBean()` method in AfterBeanDiscovery).

Sorry if I hadn't made it clear before, but that is indeed the use case (and only use case) I was referring to.

Specifically for (spec) implementations that build on CDI and provide their own build-in beans that are created and registered using AfterBeanDiscovery, this is a big gap in the current API. As mentioned, Jakarta Security implementation Soteria needed to introduce an SPI for this which needs to be implemented individually by both Weld and OWB, and potentially any future CDI implementation.

As Jakarta Faces moves more to CDI, I'm pretty sure we'll see the same need in implementation Mojarra too.

Essentially, we need portable variants of Weld's

org.jboss.weld.util.Decorators.getOuterDelegate
org.jboss.weld.manager.BeanManagerImpl.getServices().get(CurrentInjectionPoint.class)

Kind regards,
Arjan Tijms




 

Back to the top