[JBoss JIRA] Created: (CDI-112) Clarify how alternatives are enabled
by Shane Bryzak (JIRA)
Clarify how alternatives are enabled
------------------------------------
Key: CDI-112
URL: https://issues.jboss.org/browse/CDI-112
Project: CDI Specification Issues
Issue Type: Clarification
Components: Beans
Affects Versions: 1.0
Reporter: Shane Bryzak
The spec is open to interpretation about how alternatives are enabled. One popular interpretation is that alternatives must be enabled within the same bean archive that contains the alternative bean. However, it might be worth considering the merit of enabling an alternative from a deployment archive that contains the bean archive.
For example, suppose we have the following deployment archive:
foo.war
/WEB-INF
beans.xml
/lib
bar.jar
/META-INF
beans.xml
/com
/acme
AlternativeBean.class
It may be worth allowing AlternativeBean.class (a class annotated with @Alternative) to be enabled by listing it in the <alternatives> section of foo.war/WEB-INF/beans.xml.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (CDI-244) Allow public static fields on managed beans which declare any other scope than dependent
by Martin Kouba (JIRA)
Martin Kouba created CDI-244:
--------------------------------
Summary: Allow public static fields on managed beans which declare any other scope than dependent
Key: CDI-244
URL: https://issues.jboss.org/browse/CDI-244
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Martin Kouba
See 3.1. Managed beans:
{quote}
If a managed bean has a public field, it must have scope @Dependent. If a managed bean with a public field declares any scope other than @Dependent, the container automatically detects the problem and treats it as a definition error.
{quote}
I see no reason why to disallow public _static_ fields on normal scoped beans. To treat public _non-static_ fields as a definition error due to proxy generation is reasonable. However public static fields are usually referenced by the class name and refering to static fields with an object reference (proxy in this case) is discouraged. Moreover, protected and package-private fields which might also cause confusion around proxies are allowed.
BTW Weld allows public static fields on normal scoped beans at the moment.
Maybe the spec wording could be:
{quote}
3.1. Managed beans
If a managed bean has a _non-static_ public field, it must have scope @Dependent. If a managed bean with a _non-static_ public field declares any scope other than @Dependent, the container automatically detects the problem and treats it as a definition error.
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (CDI-202) Clarify when BeanManager.createBeanAttributes(AnnotatedMember) returns an alternative
by Jozef Hartinger (Created) (JIRA)
Clarify when BeanManager.createBeanAttributes(AnnotatedMember) returns an alternative
-------------------------------------------------------------------------------------
Key: CDI-202
URL: https://issues.jboss.org/browse/CDI-202
Project: CDI Specification Issues
Issue Type: Clarification
Components: Beans
Affects Versions: 1.1.EDR1
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
Currently, a producer field/method is an alternative if it is annotated with @Alternative or an alternative stereotype or the class declaring the field/method is annotated this way. However, when the BeanManager.createBeanAttributes(AnnotatedMember) method is called, the container has no access to the bean that declares the member. Therefore, the specification should clarify whether the container
* should examine the AnnotatedType for @Alternative or alternative stereotypes
* should try to infer the declaring bean (probably not possible since multiple beans may exist, each of them possibly modified in the ProcessBeanAttributes phase, etc.)
* should make an assumption (e.g. the bean that declares the returned BeanAttributes is always assumed not to be an alternative)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (CDI-212) Clarify BeanManager.createBean()
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-212:
-----------------------------------
Summary: Clarify BeanManager.createBean()
Key: CDI-212
URL: https://issues.jboss.org/browse/CDI-212
Project: CDI Specification Issues
Issue Type: Clarification
Components: Portable Extensions
Affects Versions: 1.1.EDR1
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
It is unclear from the specification whether the BeanManager.createBean() method should ever return an implementation of the Decorator or Interceptor interface.
Method parameters of the createBean() method provide all the necessary information for constructing a Decorator implementation. Therefore, IMHO the method should return a container-provided Decorator implementation if the set of stereotypes returned by BeanAttributes.getStereotypes contains javax.decorator.Decorator.
On the other hand, Interceptors do not fit this model because the AnnotatedType of the bean class is not available to the method and using the reflection API to scan the bean class directly would not be consistent with the rest of the specification.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months