November 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-283) Remove ProcessModule

by Pete Muir (JIRA)

Pete Muir created CDI-283: ----------------------------- Summary: Remove ProcessModule Key: CDI-283 URL: https://issues.jboss.org/browse/CDI-283 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.1.EDR Reporter: Pete Muir Fix For: 1.1.PRD -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
2
0 / 0

[JBoss JIRA] (CDI-279) Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform

by Hong Zhang (JIRA)

Hong Zhang created CDI-279: ------------------------------ Summary: Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform Key: CDI-279 URL: https://issues.jboss.org/browse/CDI-279 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Hong Zhang Please provide CDI SPI that could be used to directly replace the java.lang.reflect methods when expanding the use of @Stereotype to Java EE 7 platform. Also attaching the relevant sections from Bill's @Stereotype proposal below: ================================================ Stereotypes are implemented by CDI, but (typically) the Java EE deployment processing has no knowledge of CDI when it's looking for Java EE annotations. Integrating with CDI so that stereotypes could be considered during this deployment-time annotation processing would require a new CDI SPI. Many existing implementations would need to be changed to understand how to expand stereotypes. Requiring every technology to do this itself will almost certainly lead to inconsistencies. Since stereotypes are a CDI feature, CDI will provide a simple replacement for the java.lang.reflect methods such as getAnnotations that takes into account stereotypes. Some technologies will not want to have a hard dependency on CDI so we'll need to provide a simple way for them to conditionally invoke these new methods only if CDI is present, falling back to java.lang.reflect if not. This seems straightforward. In this case, the functionality of @Stereotype would not be available to applications that chose to run without CDI. =============================== -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

2
4
0 / 0

[JBoss JIRA] (CDI-265) Specify the @Initialized(ApplicationScoped.class) event payload for an EAR with multiple WARs

by Martin Kouba (JIRA)

Martin Kouba created CDI-265: -------------------------------- Summary: Specify the @Initialized(ApplicationScoped.class) event payload for an EAR with multiple WARs Key: CDI-265 URL: https://issues.jboss.org/browse/CDI-265 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.1.EDR Reporter: Martin Kouba The spec states: {quote} The event payload is: * the ServletContextEvent if the application is a web application deployed to a Servlet container, or * ... {quote} However this will not work for enterprise archives with multiple web modules (which ServletContextEvent would be the payload). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

3
5
0 / 0

[JBoss JIRA] (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger reopened CDI-44: -------------------------------- Reopening as the addition to Section 3.15 (proxyable requirements for interceptors and decorators) is overlapping with sections 8.3 and 9.3 > Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation > ------------------------------------------------------------------------------------------------------------- > > Key: CDI-44 > URL: https://issues.jboss.org/browse/CDI-44 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1.PRD > > > When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not. > When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger updated CDI-44: ------------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PRD) > Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation > ------------------------------------------------------------------------------------------------------------- > > Key: CDI-44 > URL: https://issues.jboss.org/browse/CDI-44 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1 (Proposed) > > > When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not. > When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

prd review

by Mark Struberg

Hi folks! I think there are still a few paragraphs in there which I personally thought we already dropped again I gonna review the spec page by page the next 2 weeks. in 'Foreward' (btw shouldn't that be 'Foreword'?) * "Ability to veto beans declaratively using @Veto and @Requires" I thought we dropped @Requires as it's not really possible to implement that properly? That would require any scanning mechanism to know CDI and it's mechanics. At least this references to a valid paragraph ;) -> should get fixed too. * "Ability to access the BeanManager from the ServletContext" Didn't we drop that as well? I wasnt able to find the definition in the rest of the spec. * "Ability to obtain Extension instances from BeanManager" As above, do we really have this now? Thought we dont need it as its perfectly possible to @Inject Extensions since CDI-1.0 Foreword misses a reference to CDI-18 which is imo the most important change. Just for the start :) LieGrue, strub

11 years, 6 months

2
3
0 / 0

[JBoss JIRA] (CDI-247) It's currently not possible to implement a primitive and wrapping type producer method for the same type

by Mark Struberg (JIRA)

Mark Struberg created CDI-247: --------------------------------- Summary: It's currently not possible to implement a primitive and wrapping type producer method for the same type Key: CDI-247 URL: https://issues.jboss.org/browse/CDI-247 Project: CDI Specification Issues Issue Type: Bug Components: Concepts Affects Versions: 1.1.EDR1, 1.0 Reporter: Mark Struberg Fix For: 1.1 (Proposed) -- 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

11 years, 6 months

5
13
0 / 0

[JBoss JIRA] (CDI-288) IdentifiedAnnotatedType.getID() should be called getId()

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-288: ----------------------------------- Summary: IdentifiedAnnotatedType.getID() should be called getId() Key: CDI-288 URL: https://issues.jboss.org/browse/CDI-288 Project: CDI Specification Issues Issue Type: Bug Components: Portable Extensions Affects Versions: 1.1.PRD Reporter: Jozef Hartinger Assignee: Pete Muir Priority: Trivial Fix For: 1.1 (Proposed) *getID() vs getId()* There is not really a convention we could follow (http://stackoverflow.com/questions/2236807/java-naming-convention-with-ac...). However, there are certain example where the latter option is prefered http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#getId() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

3
3
0 / 0

[JBoss JIRA] (CDI-234) behavior of arrays without @Nonbinding

by Romain Manni-Bucau (JIRA)

Romain Manni-Bucau created CDI-234: -------------------------------------- Summary: behavior of arrays without @Nonbinding Key: CDI-234 URL: https://issues.jboss.org/browse/CDI-234 Project: CDI Specification Issues Issue Type: Clarification Reporter: Romain Manni-Bucau The spec says: "Array-valued or annotation-valued members of a qualifier type should be annotated @Nonbinding in a portable application. If an array-valued or annotation-valued member of a qualifier type is not annotated @Nonbinding, non-portable behavior results." The case of arrays without this annotation should be managed to get a better portability. Two arraysequality is determined through "Arrays" helper (http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/annotation/Annotat...) so i don't think there is any technical issue to consider arrays as a field. -- 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

11 years, 6 months

3
21
0 / 0

[JBoss JIRA] (CDI-87) Declarative control over classes including in bean archive scanning

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-87: ------------------------------ This wasn't accepted as a Java EE wide improvement. > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Weld introduced a XML syntax for this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2012