Portable decorable Bean<T> instances

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Portable decorable Bean<T> instances

arjan tijms
Hi,

When adding a manually constructed Bean<T> instance using AfterBeanDiscovery.addBean(Bean<?>), or using the AfterBeanDiscovery.addBean() method and the BeanConfigurator, the resulting bean can't be decorated.

This is because seemingly CDI expects the create() method of Bean<T> to locate the decorators itself and apply them to the instance it returns.

Using BeanManager.resolveDecorators one can obtain the Decorator<T> instances, but am I right that there's no portable way to actually apply those decorators to the bean instance?

Kind regards,
Arjan



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Portable decorable Bean<T> instances

Matej Novotny
Hi,

yes, there is no portable way.
It is a similar situation as was with interceptors before InterceptionFactory was added.

[impl 'details']
In principle, to implement this, you need to create a "wrapper class" around the object which is to be intercepted/decorated.
If you provide a custom way to create the bean, it is very difficult to create this wrapper on-the-fly.
Even the solution for interceptors has some shortcomings and flaws and decorators seem even more complex (less restrictions on how does a decorator look like).

Matej

----- Original Message -----

> From: "arjan tijms" <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, July 10, 2018 11:30:54 AM
> Subject: [cdi-dev] Portable decorable Bean<T> instances
>
> Hi,
>
> When adding a manually constructed Bean<T> instance using
> AfterBeanDiscovery.addBean(Bean<?>), or using the
> AfterBeanDiscovery.addBean() method and the BeanConfigurator, the resulting
> bean can't be decorated.
>
> This is because seemingly CDI expects the create() method of Bean<T> to
> locate the decorators itself and apply them to the instance it returns.
>
> Using BeanManager.resolveDecorators one can obtain the Decorator<T>
> instances, but am I right that there's no portable way to actually apply
> those decorators to the bean instance?
>
> Kind regards,
> Arjan
>
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Portable decorable Bean<T> instances

arjan tijms
Hi,

Thanks for the reply. I already feared that to be the answer.

This would probably be a good enhancement request for CDI 2.1. At the very least the BeanConfigurator could have a method like BeanConfigurator#setDecorators<Decorator<?>... decorators. That's seemingly doable to implement by the CDI implementations.

Kind regards,
Arjan





On Tue, Jul 10, 2018 at 11:04 AM Matej Novotny <[hidden email]> wrote:
Hi,

yes, there is no portable way.
It is a similar situation as was with interceptors before InterceptionFactory was added.

[impl 'details']
In principle, to implement this, you need to create a "wrapper class" around the object which is to be intercepted/decorated.
If you provide a custom way to create the bean, it is very difficult to create this wrapper on-the-fly.
Even the solution for interceptors has some shortcomings and flaws and decorators seem even more complex (less restrictions on how does a decorator look like).

Matej

----- Original Message -----
> From: "arjan tijms" <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, July 10, 2018 11:30:54 AM
> Subject: [cdi-dev] Portable decorable Bean<T> instances
>
> Hi,
>
> When adding a manually constructed Bean<T> instance using
> AfterBeanDiscovery.addBean(Bean<?>), or using the
> AfterBeanDiscovery.addBean() method and the BeanConfigurator, the resulting
> bean can't be decorated.
>
> This is because seemingly CDI expects the create() method of Bean<T> to
> locate the decorators itself and apply them to the instance it returns.
>
> Using BeanManager.resolveDecorators one can obtain the Decorator<T>
> instances, but am I right that there's no portable way to actually apply
> those decorators to the bean instance?
>
> Kind regards,
> Arjan
>
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Portable decorable Bean<T> instances

Martin Kouba
Dne 10.7.2018 v 13:45 arjan tijms napsal(a):
> Hi,
>
> Thanks for the reply. I already feared that to be the answer.
>
> This would probably be a good enhancement request for CDI 2.1. At the
> very least the BeanConfigurator could have a method like
> BeanConfigurator#setDecorators<Decorator<?>... decorators. That's
> seemingly doable to implement by the CDI implementations.

Well, it's not that simple. In order to make decorators work the
instance produced by Bean#create(CreationalContext<T>) must be proxied,
decorated types only include interfaces, etc.

There are few issues related to this topic. I'd suggest to walk through
all those issues, close duplicates and outdated issues and create a new
one with distilled summary...

>
> Kind regards,
> Arjan
>
>
>
>
>
> On Tue, Jul 10, 2018 at 11:04 AM Matej Novotny <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     yes, there is no portable way.
>     It is a similar situation as was with interceptors before
>     InterceptionFactory was added.
>
>     [impl 'details']
>     In principle, to implement this, you need to create a "wrapper
>     class" around the object which is to be intercepted/decorated.
>     If you provide a custom way to create the bean, it is very difficult
>     to create this wrapper on-the-fly.
>     Even the solution for interceptors has some shortcomings and flaws
>     and decorators seem even more complex (less restrictions on how does
>     a decorator look like).
>
>     Matej
>
>     ----- Original Message -----
>      > From: "arjan tijms" <[hidden email]
>     <mailto:[hidden email]>>
>      > To: [hidden email] <mailto:[hidden email]>
>      > Sent: Tuesday, July 10, 2018 11:30:54 AM
>      > Subject: [cdi-dev] Portable decorable Bean<T> instances
>      >
>      > Hi,
>      >
>      > When adding a manually constructed Bean<T> instance using
>      > AfterBeanDiscovery.addBean(Bean<?>), or using the
>      > AfterBeanDiscovery.addBean() method and the BeanConfigurator, the
>     resulting
>      > bean can't be decorated.
>      >
>      > This is because seemingly CDI expects the create() method of
>     Bean<T> to
>      > locate the decorators itself and apply them to the instance it
>     returns.
>      >
>      > Using BeanManager.resolveDecorators one can obtain the Decorator<T>
>      > instances, but am I right that there's no portable way to
>     actually apply
>      > those decorators to the bean instance?
>      >
>      > Kind regards,
>      > Arjan
>      >
>      >
>      >
>      > _______________________________________________
>      > cdi-dev mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/cdi-dev
>      >
>      > Note that for all code provided on this list, the provider
>     licenses the code
>      > under the Apache License, Version 2
>      > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas
>      > provided on this list, the provider waives all patent and other
>     intellectual
>      > property rights inherent in such information.
>
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.