[cdi-dev] Possible cycle with ProcessBeanAttributes only for enabled beans

Mark Struberg struberg at yahoo.de
Sat Jan 3 16:39:57 EST 2015

But I CANNOT know if it is enabled before I fire ProcessBeanAttributes! Because this PBA#veto() has a huge impact on which class is enabled or not.

And no, in CDI-1.0 there was only ProcessBean which did imo _not_ have a veto() method. This only got added with ProcessBeanAttributes, right?

I think in practice this will rarely be an issue, but there are cases where it is not really deterministic but depending on the order in which the classes get processed.


> On Friday, 2 January 2015, 8:40, Jozef Hartinger <jharting at redhat.com> wrote:
> > You cannot just fire ProcessBeanAttributes the moment you run across 
> Bravo. You need to figure out whether it is specialized or not first 
> (which means processing Charlie). This is not new at all - this was the 
> case since CDI 1.0 with ProcessBean.
> As for the extension case the moment an extension vetoes BeanAttributes, 
> you should check whether that action makes any previously disabled beans 
> enabled. If so, fire ProcessBeanAttributes for them. Repeat untill all 
> beans are processed.
> On 12/22/2014 06:58 PM, Mark Struberg wrote:
>>  The JavaDoc of ProcessBeanAttributes defines that ProcessBeanAttributes 
> must only get fired for ENABLED beans:
>>  "The container fires an event of this type for each enabled bean, 
> interceptor or decorator deployed in a bean archive before registering the Bean 
> object."
>>  The test
> org.jboss.cdi.tck.tests.extensions.lifecycle.processBeanAttributes.specialization.SpecializationTest
>>  has a nice example
>>  @Specializes class Charly extends
>>     -> @Specializes class Bravo extends
>>       -> class Alpha
>>  Which ProcessBeanAttributes events would you except to get fired?
>>    *) Alpha? No, because it's specialized away (5.1.2. Enabled and 
> disabled beans).
>>    *) Bravo? No, because it's specialized away as well, right?
>>    *) Charly? Yes, because that's the only _enabled_ bean!
>>  So far, so clear. But now comes the tricky part!
>>  This test also has an Extension which observes ProcessBeanAttributes and 
> disables Charly.
>>  This means that finally Bravo is enabled, Charly disabled (is there 
> actually a difference btw disabled and vetoed spec wording wise?)
>>  The problem is now that we only know this AFTER the ProcessBeanAttributes 
> for Charly got fired. And this introduces an ordering issue:
>>  If the BeanAttributes for Bravo gets scanned BEFORE the ones of Charly, 
> then we do not know YET that Charly will get disabled. Thus we fire the 
> ProcessBeanAttributes for Bravo as well. But as we know that should not happen!
>>  Otoh if Charly gets scanned first, then Bravo will not get processed.
>>  Can you follow me?
>>  LieGrue,
>>  strub
>>  _______________________________________________
>>  cdi-dev mailing list
>>  cdi-dev at lists.jboss.org
>>  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.

More information about the cdi-dev mailing list