Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Critical
-
Resolution: Cannot Reproduce Bug
-
Affects Version/s: 1.1.1.Final
-
Fix Version/s: None
-
Component/s: Resolution
-
Labels:None
Description
example (broken):
bean-archive #1:
- BeanA
- BeanA1 (@Alternative)
- beans.xml (activates BeanA1 as alternative)
bean-archive #2:
- BeanA2 (@Typed())
- beans.xml (empty)
BeanA1 doesn't get used (without an error or a warning BeanA is used instead - even though BeanA1 is activated as alternative in the same bean-archive)
example (working):
bean-archive #1:
- BeanA
- BeanA1 (@Alternative)
- beans.xml (activates BeanA1 as alternative)
jar #2 (no bean-archive):
- BeanA2 (@Typed())
BeanA1 gets activated as alternative (as expected) because jar #2 isn't a bean-archive (that's the difference compared to the broken example).
that prevents >e.g.< portable extensions from providing extension-points to work around the broken @Alternative spec. section.
Gliffy Diagrams
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Re-open if still an issue with AS7.
Ales Justin
added a comment - Re-open if still an issue with AS7. It's still broken (tested with AS7.1)
Gerhard Petracek
added a comment - It's still broken (tested with AS7.1) this file contains the described example.
Gerhard Petracek
added a comment - this file contains the described example. I've tested this on 7.1 and found that BeanA2 plays no role here. Whether the second bean archive is included in WEB-INF/lib or not, it is always BeanA that gets injected into Page. And this appears to be the correct behavior according to section 5.1 of the spec:
An alternative is not available for injection, lookup or EL resolution to classes or JSP/JSF pages in a module unless the module is a bean archive and the alternative is explicitly selected in that bean archive.
Since the alternative is only selected in the first bean archive, and Page is located in the war (and not inside the first bean archive), the injected bean should in fact be BeanA. If you were to move Page into the first bean archive, only then would BeanA1 be injected into Page, since BeanA1 is selected as an alternative only in the first bean archive.
Can someone confirm this?
Marko Lukša
added a comment - I've tested this on 7.1 and found that BeanA2 plays no role here. Whether the second bean archive is included in WEB-INF/lib or not, it is always BeanA that gets injected into Page . And this appears to be the correct behavior according to section 5.1 of the spec:
An alternative is not available for injection, lookup or EL resolution to classes or JSP/JSF pages in a module unless the module is a bean archive and the alternative is explicitly selected in that bean archive .
Since the alternative is only selected in the first bean archive, and Page is located in the war (and not inside the first bean archive), the injected bean should in fact be BeanA . If you were to move Page into the first bean archive, only then would BeanA1 be injected into Page , since BeanA1 is selected as an alternative only in the first bean archive.
Can someone confirm this? that's right - with as7.1 the effect is different. removing module 2 doesn't lead to a different behaviour (like before).
however, BeanA1 is in the same bean archive and it's configured as alternative.
the current behaviour is the 2nd interpretation of this part of the spec. and the 3rd+ behaviour i've seen with weld.
since the whole topic is also related to CDI-18 and the current behaviour is better than everything i've seen in weld before, i'm ok with closing this ticket and keep the behaviour as it is.
Gerhard Petracek
added a comment - that's right - with as7.1 the effect is different. removing module 2 doesn't lead to a different behaviour (like before).
however, BeanA1 is in the same bean archive and it's configured as alternative.
the current behaviour is the 2nd interpretation of this part of the spec. and the 3rd+ behaviour i've seen with weld.
since the whole topic is also related to CDI-18 and the current behaviour is better than everything i've seen in weld before, i'm ok with closing this ticket and keep the behaviour as it is. 
Could you attach this as an example, I'm struggling to understand the pseudo version...