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(a)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.

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. LieGrue, strub > On Friday, 2 January 2015, 8:40, Jozef Hartinger <jharting(a)redhat.com&gt; 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(a)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. >