Re: configureProducerMethodSpecialization looks pretty much overcomplicated

[Gerhard Petracek]

+1

regards,
gerhard



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
>
>

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