configureProducerMethodSpecialization looks pretty much overcomplicated

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

Re: configureProducerMethodSpecialization looks pretty much overcomplicated

+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 @rmannibu

Beans added via Extensions and Interceptors and Decorators

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

Re: Beans added via Extensions and Interceptors and Decorators

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

Re: Beans added via Extensions and Interceptors and Decorators

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 par