Let me clarify:
1) Determine what beans are enabled / disabled based on the deployment
information (ignore ProcessBeanAttributes.veto() for now) - this is the
same as what is done for ProcessBean in CDI 1.0
2) For each of these enabled beans fire ProcessBeanAttributes
3) If a veto action makes any previously disabled bean enabled, fire
ProcessBeanAttributes for it once this round of PBA firing finishes
4) Repeat 2-4 until all beans are processed
On 01/03/2015 10:39 PM, Mark Struberg wrote:
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
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(a)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
>> The test
>> 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?
>> cdi-dev mailing list
>> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2
). For all other ideas provided
> on this list, the provider waives all patent and other intellectual property
> rights inherent in such information.