Re: Beans added via Extensions and Interceptors and Decorators

[Arne Limburg]

Hi Romain, David,

I remember that discussion in the EG and that outcome, too. The conclusion
was, that 3rd party beans have to define their own interceptor decorator
stack and create it in Bean#create

Cheers,
Arne


Am 20.12.17 06:49 schrieb "Romain Manni-Bucau" unter
:

>Hi David
>
>IIRC 3rd party beans - including @Produces - dont support producers (in
>the
>spec) since there are fully let to the user. This is why deltaspike has
>this partialbean interceptor support.
>
>
>
>Le 20 déc. 2017 04:01, "David Blevins"  a écrit :
>
>Looks as though we don't support Interceptors or Decorators for beans
>added
>via extension that are not subclasses of AbstractOwbBean.
>
>ThirdpartyBeanImpl returns an inner class impl of Producer from
>getProducer.  Since it doesn't extend AbstractProducer it doesn't have the
>defineInterceptorStack method and we skip it at the time where we would
>resolve those.
>
>Is there a reason we don't have the inner class in ThirdpartyBeanImpl
>extend AbstractProducer?
>
>
>--
>David Blevins
>http://twitter.com/dblevins
>http://www.tomitribe.com

Re: Beans added via Extensions and Interceptors and Decorators

[Romain Manni-Bucau]

Hi David

IIRC 3rd party beans - including @Produces - dont support producers (in the
spec) since there are fully let to the user. This is why deltaspike has
this partialbean interceptor support.



Le 20 déc. 2017 04:01, "David Blevins"  a écrit :

Looks as though we don't support Interceptors or Decorators for beans added
via extension that are not subclasses of AbstractOwbBean.

ThirdpartyBeanImpl returns an inner class impl of Producer from
getProducer.  Since it doesn't extend AbstractProducer it doesn't have the
defineInterceptorStack method and we skip it at the time where we would
resolve those.

Is there a reason we don't have the inner class in ThirdpartyBeanImpl
extend AbstractProducer?


--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

Beans added via Extensions and Interceptors and Decorators

[David Blevins]

Looks as though we don't support Interceptors or Decorators for beans added via 
extension that are not subclasses of AbstractOwbBean.

ThirdpartyBeanImpl returns an inner class impl of Producer from getProducer.  
Since it doesn't extend AbstractProducer it doesn't have the 
defineInterceptorStack method and we skip it at the time where we would resolve 
those.

Is there a reason we don't have the inner class in ThirdpartyBeanImpl extend 
AbstractProducer?


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

Re: configureProducerMethodSpecialization looks pretty much overcomplicated

[Romain Manni-Bucau]

+1, it was broken anyway as mentionned on IRC yesterday

Thought about that sorting by descendant (ascendant depending how you see
it) for specialized beans only which should reduce the cost a lot and be
deterministic so a big +1, thank you so much to drive this Mark!


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn 

2017-12-19 9:01 GMT+01:00 Mark Struberg :

> Hi folks!
>
> Currently refactoring the WebBeansUtil#configureProducerMethodSpecial
> izations.
>
> This method is not easy to follow and could be seriously simplified.
>
> I already moved all the condition checks to a common place, unifying the
> checks from ProducerMethodBuilder and the ondes in WebBeansUtil.
>
> The next step is to simplify the condition checks itself.
> It looks that the original approach have been a red/black tree like
> algorithm to avoid n^2.
> But by always creating a fresh sorted list of all producer method beans
> inside this loop, we got the issue anyway.
>
> My current try is to sort all the beans just once and then disable all the
> producer methods who got overwritten.
> This means that the sorting has to be reversed, with the subclasses first,
> then the parent classes later.
>
> It's quite some change, but it gladly only affects specialized producer
> methods.
> Still we should critically review the refactoring.
>
> txs and LieGrue,
> strub
>
>

configureProducerMethodSpecialization looks pretty much overcomplicated

[Mark Struberg]

Hi folks!

Currently refactoring the WebBeansUtil#configureProducerMethodSpecializations.

This method is not easy to follow and could be seriously simplified. 

I already moved all the condition checks to a common place, unifying the checks 
from ProducerMethodBuilder and the ondes in WebBeansUtil.

The next step is to simplify the condition checks itself.
It looks that the original approach have been a red/black tree like algorithm 
to avoid n^2. 
But by always creating a fresh sorted list of all producer method beans inside 
this loop, we got the issue anyway.

My current try is to sort all the beans just once and then disable all the 
producer methods who got overwritten.
This means that the sorting has to be reversed, with the subclasses first, then 
the parent classes later. 

It's quite some change, but it gladly only affects specialized producer methods.
Still we should critically review the refactoring.

txs and LieGrue,
strub