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

[Jozef Hartinger]

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