[cdi-dev] Possible cycle with ProcessBeanAttributes only for enabled beans
jharting at redhat.com
Mon Jan 5 03:28:23 EST 2015
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.
>> 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
>>> 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
>>> cdi-dev at lists.jboss.org
>>> 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