[
https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy...
]
Emily Jiang commented on CDI-627:
---------------------------------
I prefer to clearly list the conditions for the DefintionException. It also matches other
DefinitionException style. However, the following sentence is not well spelt out.
* the class is not annotated with @Alternative AND the class is not a bean class of a
Bean<T> with isAlternative() == true
I would suggest to stay similar to CDI 1.0 but change to the following or something
similar
If there is no class with the specified name, or if the class with the specified name is
not an alternative bean class and no corresponding custom alternative bean class is
defined, the container automatically detects the problem and treats it as a deployment
problem.
By the way, although we are fixing back cdi 1.2 to cdi 1.0, we are potentially introducing
a backward incompatibility with cdi 1.2 spec. Any concerns?
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
Fix For: 2.0 (proposed)
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
(v6.4.11#64026)