[cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2

Mark Struberg (JIRA) issues at jboss.org
Fri Aug 17 04:01:01 EDT 2018


    [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620412#comment-13620412 ] 

Mark Struberg edited comment on CDI-627 at 8/17/18 4:00 AM:
------------------------------------------------------------

This bug actually blow up in our face in many projects! 
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.

Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.

We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!

So I see absolutely no reason why Weld refuses to fix this broken behaviour!

*Edit*: It works perfectly fine in ALL Weld-1 and Weld-3 versions. And as far as I remember it even worked perfectly fine in earlier Weld-2 versions. It just got broken in younger Weld2 versions.


was (Author: struberg):
This bug actually blow up in our face in many projects! 
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.

Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.

We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!

So I see absolutely no reason why Weld refuses to fix this broken behaviour!

> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
>                 Key: CDI-627
>                 URL: https://issues.jboss.org/browse/CDI-627
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Concepts
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
>   <alternatives>
>     <class>org.acme.MockMailService</class>
>   </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


More information about the cdi-dev mailing list