August 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-50) Ability to veto beans, both unconditionally and based on classes visible

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-50: ------------------------------ I've written an updated proposal for @Vetoed, as discussed at the meeting. Please review https://github.com/jboss/cdi/pull/91 > Ability to veto beans, both unconditionally and based on classes visible > ------------------------------------------------------------------------ > > Key: CDI-50 > URL: https://issues.jboss.org/browse/CDI-50 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PRD > > > This should support both a straight veto, and conditional based on classes available. > Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}). > Mark Struberg proposed using @Optional -- 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, 7 months

1
0
0 / 0

Notes from CDI EG 28/08/2012

by Pete Muir

Joe Bergmark =========== We reviewed the status of the issue Joe had worked on: * Close CDI-235 as a dupe of CDI-219 (done) * CDI-180 & CDI-223 Joe is going to strengthen the text that requires that a request context that is not initialized by a call, should not be ended by that call (Action Joe to send pull request) Pete Muir ======= * CDI-138, allow definition of qualifiers and interceptor bindings using annotated types, to allow @Nonbinding to be added programmatically to member values with a proposal at https://github.com/jboss/cdi/pull/41 - Discussed whether it's better to fire a PAT (or another similar event?) for annotations, allowing them to be modified. Mark to file a new issue for this feature request. We need to collect use cases. - Should be able to apply @Nonbinding at annotation level (https://issues.jboss.org/browse/CDI-253) - Hold on applying this issue until we explore whether should fire an event to modify annotations * CDI-218 Allow use of WEB-INF/classes/META-INF/beans.xml with a proposal at https://github.com/jboss/cdi/pull/74 - Apply (done) * CDI-214, Remove BeanManager from Servlet context, a revert of CDI-73 with a proposal at https://github.com/jboss/cdi/pull/74 -Apply (done) * CDI-177 Better handling of @Named defaults for qualifiers with a proposal at https://github.com/jboss/cdi/pull/77/files - Joe raised an issue that we will break existing CDI apps who have explicitly or implicitly (e.g. via a producer method) the same as a now defaulted qualifier - Mark thinks it's spec'd this way already, but Martin and I think it's not. Needs clarification! - Pete to investigate, but probably have to special case it that the name is only defaulted if not explicitly specified elsewhere or something - hold for now * CDI-187 Interceptors and decorators should be required to be passivation capable, not serializable, with a proposal athttps://github.com/jboss/cdi/pull/78 - Apply (done) * CDI-234 Handle array and annotation valued members on qualifiers, with a proposal at https://github.com/jboss/cdi/pull/79 - Definitely do this, removes a wart - Concern that JDK defined equality of arrays is not ideal in many cases for the way people use arrays on qualifiers - discussed a declarative approach (e.g. @Unordered) - discussed a SPI approach (user can specify a comparator to use) - discussed that we should expose a BeanManager.compare(qualifier1, qualifier2) type method that applys rules (https://issues.jboss.org/browse/CDI-223) - group preferred SPI approach - Pete to draft a proposal for SPI approach * CDI-183 Require CDI.current() to work in Java EE servers with a proposal at https://github.com/jboss/cdi/pull/85 - Update to require it to work only between BBD and BS (Pete) * CDI-184 Add CDI.setCDIProvider() for environments where service providers don't work e.g. OSGi with a proposal at https://github.com/jboss/cdi/pull/86 - Apply (done) * CDI-165 Encourage custom context implementations to fire events when they are initialized and destroyed, with a proposal at https://github.com/jboss/cdi/pull/87 - Apply (done) * CDI-43 Adding filters to extensions to limit when they are called, with a proposal at https://github.com/jboss/cdi/pull/88 - Update proposal to require considering meta-annotations as things the extension is interested in (Pete) and then then apply * CDI-245 & CDI-249 Discussion how extensions work, and what can be injected into them, with a proposal at https://github.com/jboss/cdi/pull/89 - Update proposal with latest discussion on issue, and also add an IllegalStateException if BeanManager.fireEvent() is called with an EventType that is assignable to a container lifecycle event type Mark Struberg =========== * CDI-60, @Veto etc. - Remove @Requires - Discussed that @Disabled might still be useful, to declaratively disable a bean, put still run it's PAT - Mike advocated very strongly in favor of @Vetoed which stops a class from passing through @PAT at all - Write up proposal and seek community feedback (Pete) * CDI-228 - Went through the issue and all agreed that the most important thing is to keep the semantics of all injection types the same by default - Proposed adding a @Throwaway (name tbc!) parameter annotation which indicates to the container that an injected bean has a truncated lifecycle, and is destroyed when the method/constructor invocation ends. This allows non-serializables beans (e.g. factories) to be injected into serializable beans. It also allows a dependent bean graph which must be kept around (to call a @PreDestroy somewhere) to be got rid of early. Mark to write up a proposal.

11 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (CDI-109) Invalid beans should not be injectable into extensions

by John Ament (JIRA)

Invalid beans should not be injectable into extensions ------------------------------------------------------ Key: CDI-109 URL: https://issues.jboss.org/browse/CDI-109 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Currently, you can inject beans that may not be ready yet into the extension's call back methods. As an example, I can inject something application scoped like this in to an extension, but it should really be throwing a definition exception (or similar): public void handleABD(@Observes AfterBeanDiscovery abd, MyApplicationScopedBean masb) { } Pete had noted that really the only safe thing to inject, other than the observed call back, is the bean manager. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

10
18
0 / 0

[JBoss JIRA] (CDI-245) Promote the right way how extensions should communicate with each other during container initialization

by Martin Kouba (JIRA)

Martin Kouba created CDI-245: -------------------------------- Summary: Promote the right way how extensions should communicate with each other during container initialization Key: CDI-245 URL: https://issues.jboss.org/browse/CDI-245 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.1.EDR1, 1.0 Reporter: Martin Kouba This is not clear right now. The spec allows (does not forbid) extensions to fire regular events via {{BeanManager}} and I believe this should be _the right way_. See also CDI-109 discussion. However we should also state that extensions _may not fire container lifecycle events_ as this could lead to unexpected results (and it's pretty broken imho). -- 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, 7 months

3
21
0 / 0

[JBoss JIRA] (CDI-183) Clarify that CDI.current() can be called by anyone and not just CDI extensions

by Emmanuel Bernard (Created) (JIRA)

Clarify that CDI.current() can be called by anyone and not just CDI extensions ------------------------------------------------------------------------------ Key: CDI-183 URL: https://issues.jboss.org/browse/CDI-183 Project: CDI Specification Issues Issue Type: Clarification Reporter: Emmanuel Bernard Fix For: 1.1 (Proposed) http://docs.jboss.org/cdi/spec/1.1.EDR1/html/spi.html#provider EDR1 makes it a bit unclear that this is allowed. -- 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, 7 months

2
2
0 / 0

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-43. -------------------------- Resolution: Done > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1.PRD > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-75) Clarify what happens to a bean which belongs to inactive when it observes an event

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.sys... ] Martin Kouba reopened CDI-75: ----------------------------- We should clarify the spec part as well (not only API javadoc). Also consider review of "10.5. Observer notification" in this context. > Clarify what happens to a bean which belongs to inactive when it observes an event > ---------------------------------------------------------------------------------- > > Key: CDI-75 > URL: https://issues.jboss.org/browse/CDI-75 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: 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, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (CDI-151) Remove from section 6.7 JMS notes

by John Ament (JIRA)

Remove from section 6.7 JMS notes --------------------------------- Key: CDI-151 URL: https://issues.jboss.org/browse/CDI-151 Project: CDI Specification Issues Issue Type: Clarification Reporter: John Ament In section 6.7, a reference is made to JMS Message Listeners. MessageListeners (as bound to the consumers) are not available in JMS in an EE environment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

3
9
0 / 0

LJC comments/questions

by Luigi Bitonti

Hi All, My name is Luigi Bitonti and I am a member of the London Java Community (LJC). We are interested in the CDI 1.1 specification and would like to help by contributing our point of view as developers. We are also keen to help with any tasks you feel like assigning to us. We have read the latest draft specification and put together a first round of comments and questions: All the discussions and development are being tracked on Jira (https://issues.jboss.org/browse/CDI). The whole process seems very transparent and easy to follow which is a very good thing. We view very positively the adoption of JCP 2.8. It looks like there is also a private mailing list the EG uses. Is that in use? What's its purpose? It looks like good work is being done and some interesting new addition have already made it into this new version of the specification, such as: - CDI-86 Support firing general purpose lifecycle events in Java EE environments - CDI-129 Clarify behaviour of @ApplicationScoped in EARs What we would like to see going forward is an "easier and clearer" specification, so the current efforts seem to be going in the right direction. Hopefully more good proposals will be implemented as part of the final version. The lack of clear separation between the SE and EE parts of the specification seems to be an issue that limits adoption. This is also related to the lack of a standard way of bootstrapping the DI container in SE. In this respect we believe the following planned changes will bring improvements: - CDI-160 Split the specification into "Core" and "EE integrations". - CDI-26 Provide a bootstrap API for the CDI container outside of an EE container. Do you think these will make it into CDI 1.1? Other interesting proposals we would like to see implemented are: - CDI-139 Support for unmanaged instances. - CDI-110 Provide support for binding an invocation handler to an interface or abstract class - CDI-30 An API for managing built in contexts I've noticed the first 2 have been voted at the top of the most popular issues. I suppose they are very likely to make it into CDI 1.1. Is that correct? Regarding the following issue, we have a question: - CDI-51 Support static injection Static injection would still not be allowed for final fields, just as for the non-static case, right? Thanks for all your work on the specification. I hope we'll be able to help your efforts going forward. Cheers, Luigi

11 years, 7 months

4
7
0 / 0

[JBoss JIRA] (CDI-77) Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-77?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-77: ------------------------------ This was discussed at yesterdays EG meeting {quote} - Joe raised an issue that we will break existing CDI apps who have explicitly or implicitly (e.g. via a producer method) the same as a now defaulted qualifier - Mark thinks it's spec'd this way already, but Martin and I think it's not. Needs clarification! - Pete to investigate, but probably have to special case it that the name is only defaulted if not explicitly specified elsewhere or something - hold for now {quote} > Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans > ---------------------------------------------------------------------------------------------------- > > Key: CDI-77 > URL: https://issues.jboss.org/browse/CDI-77 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > for example > class Foo { > @Inject Bar bar; > } > class bar { > @Inject Foo foo; > } -- 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, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2012