Re: [cdi-dev] Add methods to BeanConfigurator for applying decorators

[arjan tijms <arjan.tijms@xxxxxxxxx>]

p.s.

This particular request fits right in the CDI.Next topic that states:

"Base specification for other specification

There seems to be an agreement in the Jakarta EE community, that CDI should be a base specification for other specifications,

[...]

There are several areas that are not covered by the CDI specification, yet needed for downstream, 

[...]

To avoid confusion where each downstream specification defines handling of such features on its own, this should be covered in CDI and re-used.

"

On Mon, Nov 23, 2020 at 6:03 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

On Mon, Nov 23, 2020 at 5:39 PM Matej Novotny <manovotn@xxxxxxxxxx> wrote:

Furthermore, I vaguely remember this being a topic in a F2F prior to CDI 2.0. We decided to allow for programmatic interception in certain way (InterceptionFactory), but we deliberately *did not* add it for decorators.

The difference being that this is not for instances returned by producers, but for a Bean<T> that's registered with the runtime by an extension.

Build-in beans have to be decorable but there's no available API in CDI to do so. Meaning, a CDI implementation like Weld can make the build-in bean for say Principal easily decorable, but a Jakarta Security implementation like Soteria can't do the same thing without supporting every current and future CDI implementation separately.

See: https://github.com/eclipse-ee4j/soteria/issues/225

And: https://github.com/eclipse-ee4j/soteria/blob/master/spi/bean-decorator/weld/src/main/java/org/glassfish/soteria/spi/bean/decorator/weld/DecorableWeldBeanWrapper.java

The lack of such API hinders other Jakarta EE specifications like Jakarta Security and Jakarta Faces.

Kind regards,

Arjan Tijms