What will this require on the impl side? To get similar thing working for interceptors (InterceptionFactory), we needed to introduce a whole different proxy factory
Maybe the proposal is not entirely clear. This is not about adding a DecoratorFactory which would add decorators to random beans.
This is about the practice of programmatically adding a Bean<T> instance, where the implementation applies whatever enabled Decorators exist for that type within the CDI runtime. At the moment, when you add a Bean<T> for type X, and there's also a Decorator applicable for type X, then a lookup for X will return the bean with type X from the original Bean<T>, without applying the available and enabled Decorator that exists for X.
The prototype already exists for Weld, in a way. It's the SPI I had to implement for Soteria:
public class WeldBeanDecorator implements BeanDecorator {
@Override
public <T> Bean<T> decorateBean(Bean<T> decorableBean, Class<T> type, BeanManager beanManager) {
return new DecorableWeldBeanWrapper<>(
decorableBean,
type,
BeanManagerProxy.unwrap(beanManager));
}
}
For DecorableWeldBeanWrapper, see
Hope this makes it more clear.
Kind regards,
Arjan Tijms
which was non trivial.
It might be useful to have at least a working prototype in some impl to see the viability of this idea before committing it to the specification; if you'd be willing to try that with Weld, that would be great.
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
