[
https://issues.jboss.org/browse/CDI-581?page=com.atlassian.jira.plugin.sy...
]
Martin Kouba commented on CDI-581:
----------------------------------
Implementation notes: In Weld, {{ProcessBeanAttributes}} delivery is divided in multiple
phases. Let's assume we have the following classes:
{code:java}
@Specializes
class B extends A {
}
// This bean is specialized
class A {
}
{code}
The processing is roughly as follows:
# Fire PBA for all beans which are not specialized and are enabled in any bean archive
(i.e. not an alternative, or selected alternative) -> fire event for B
# If any bean is vetoed within PBA delivery (e.g. during delivery for B), find alll
specialized beans and repeat the process recursively (i.e. go to 1 for A)
Most likely it does not work 100% but it should work in most cases.
I agree that the wording _"if the class is an enabled bean"_ is not clear and
should be clarified.
possible chicken-egg problem with ProcessBeanAttributes#veto and
specialization
-------------------------------------------------------------------------------
Key: CDI-581
URL:
https://issues.jboss.org/browse/CDI-581
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: 1.2.Final
Reporter: Mark Struberg
Currently section 12 describes that ProcessBeanAttributes only should get fired for
'enabed beans'.
{quote}
12.4.3. Bean discovery
* if the class is an enabled bean, interceptor or decorator, fire an event of type
ProcessBeanAttributes, as defined in ProcessBeanAttributes event,
{quote}
But if you have class B extends A and B is @Specializes then you don't know which PBA
to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA
you implicitly change the list of enabled beans. This gets even more complicated by the
ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the
whole bean.
I think this might be a left-over of the split between Bean and BeanAttributes. The
ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean.
* ProcessBean die _not_ have a veto(), PAT does have it.
* PAT gets fired for all discovered classes, ProcessBean only for enabled ones.
I think the wording 'if the class is an enabled *bean*' is also misleading. We do
_not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read
''if the class is a not vetoed AnnotatedType'?
I'm not sure if there is a way the current wording could get cleanly implemented. I
just stumbled across this because we did _not_ fire a PBA for a class because the
@Specialized bean got vetoed away.
The same chicken-egg problem might apply to
{quote}
11.5.9. ProcessBeanAttributes event
The container must fire an event for each bean, interceptor or decorator deployed in a
bean
archive, before registering the Bean object."
{quote}
Reads "for every bean". But we don't have any beans yet. We can only make
the Bean<T> after the BeanAttributes get returned from PBA. Otherwise changing the
bean attributes would have no effect on the Bean, right?
What could work is roughly:
* fire PAT for all detected classes
* remove vetoed ones
* fire PBA for all AnnotatedTypes
* remove vetoed one
* calculate disabled BeanAttributes (@Specializes rule for classes)
* produce Beans
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)