January 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Updated: (CDI-28) Abstract methods on decorators

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-28?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-28: ------------------------- Fix Version/s: TBD > Abstract methods on decorators > ------------------------------ > > Key: CDI-28 > URL: https://issues.jboss.org/browse/CDI-28 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > > If a method is abstract: > * if it is a method of a decorated type, it has a generated implementation that calls the delegate > * otherwise, definition error -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-51) Support static injection

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-51?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-51: ------------------------- Fix Version/s: TBD > Support static injection > ------------------------ > > Key: CDI-51 > URL: https://issues.jboss.org/browse/CDI-51 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-47) Add required attribute to <interceptor> tag in beans.xml

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-47?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-47: ------------------------- Fix Version/s: TBD > Add required attribute to <interceptor> tag in beans.xml > --------------------------------------------------------- > > Key: CDI-47 > URL: https://issues.jboss.org/browse/CDI-47 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: TBD > > > Currently the deployment will fail if an interceptor is not present, which means that it is not conventient to use interceptors from optional modules, as the end user will need to open up the jar file and edit the beans.xml file manually. > Adding a required="true|false" attribute to the <interceptor> element in beans.xml would allow an archive to specify that the interceptor is not essential, and if it is not found it should simply be ignored. > For example, currently Seam Security has a hard dependency on Seam Persistence because it uses the Transaction interceptor, and the deployment will fail if Seam Persistence is not present. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-68) Clarify that there is only one instance of a Context object per application deployment for built in contexts

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-68?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-68: ------------------------- Fix Version/s: TBD > Clarify that there is only one instance of a Context object per application deployment for built in contexts > ------------------------------------------------------------------------------------------------------------ > > Key: CDI-68 > URL: https://issues.jboss.org/browse/CDI-68 > Project: CDI Specification Issues > Issue Type: Bug > Components: Contexts > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-17) Change name of the @Observes Reception attribute to "notified"

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-17?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-17: ------------------------- Fix Version/s: TBD (was: 1.1) > Change name of the @Observes Reception attribute to "notified" > -------------------------------------------------------------- > > Key: CDI-17 > URL: https://issues.jboss.org/browse/CDI-17 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Javadoc and API > Affects Versions: 1.0 > Reporter: Dan Allen > Priority: Minor > Fix For: TBD > > > As of the CDI 1.0 specification, the name of the Reception attribute on @Observes is "receive". The patch release of the API (SP1) changes the name to "notifyObserver", so a change is already being considered. Therefore, I'd like to suggest a better name that would read more fluently. That name is "notified". > Let us compare the three cases: > 1. @Observes(receive = IF_EXISTS) > 2. @Observes(notifyObserver = IF_EXISTS) > 3. @Observes(notified = IF_EXISTS) > Of the three, notifyObserver breaks the flow of the sentence the most. On the other hand, notified reads nicely, including with the TransactionPhase attribute included: > @Observes(notified = IF_EXISTS, during = TransactionPhase.AFTER_SUCCESS) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-20: ------------------------- Fix Version/s: TBD > @Observes(propagate = false) - stop event propagation after being handled by an observer > ---------------------------------------------------------------------------------------- > > Key: CDI-20 > URL: https://issues.jboss.org/browse/CDI-20 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Environment: any > Reporter: Walter White > Fix For: TBD > > > I would like to have the ability to stop event propagation after it is handled by any observer only for certain situations. Is it possible to add a property to the annotation indicating whether the propagation should continue after being handled by the observer? Alternatively, would it be more concise to add a qualifier annotation which specifies the propagation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-46) Clarify in the specification that extensions do not require a beans.xml file

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-46?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-46: ------------------------- Fix Version/s: TBD > Clarify in the specification that extensions do not require a beans.xml file > ---------------------------------------------------------------------------- > > Key: CDI-46 > URL: https://issues.jboss.org/browse/CDI-46 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Shane Bryzak > Fix For: TBD > > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-65) Clarify that stateful EJB references are not automatically destroyed by the container (the app must call the @Remove method explicitly)

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-65?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-65: ------------------------- Fix Version/s: TBD > Clarify that stateful EJB references are not automatically destroyed by the container (the app must call the @Remove method explicitly) > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-65 > URL: https://issues.jboss.org/browse/CDI-65 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-102) Support Injection of Servlet Contexts

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-102?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-102: -------------------------- Fix Version/s: TBD > Support Injection of Servlet Contexts > ------------------------------------- > > Key: CDI-102 > URL: https://issues.jboss.org/browse/CDI-102 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-37) Stateless scope

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-37: ------------------------- Fix Version/s: TBD > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: TBD > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev January 2011