April 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Created: (CDI-122) Create a standard way to bootstrap a CDI container outside of a Java EE environment for unit testing and other JSRs that need CDI features

by Richard Hightower (JIRA)

Create a standard way to bootstrap a CDI container outside of a Java EE environment for unit testing and other JSRs that need CDI features ------------------------------------------------------------------------------------------------------------------------------------------ Key: CDI-122 URL: https://issues.jboss.org/browse/CDI-122 Project: CDI Specification Issues Issue Type: Feature Request Components: Packaging and Deployment Affects Versions: 1.1 (Proposed) Environment: Java SE Reporter: Richard Hightower Fix For: 1.1 (Proposed) There should be a standard, minimalistic way to bootstrap a CDI container outside of Java EE. This is useful for unit testing extensions, and for other JSRs that need to do annotation processing, injection and interception. Instead of those other JSRs defining their own mechanism for annotation processing, injection and interception they can just use CDI. Also Java EE has clients (for JMS, RMI, Services). The same features on the serverside (injection, interceptions, proxying) are equally useful on the client side. There should also be some clear walls between what is included in Java SE CDI and Java EE CDI. Java SE CDI being a subset and core of Java EE CDI. This modularity should be better defined in the specification. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
3
0 / 0

[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)

by Dan Allen (JIRA)

[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Dan Allen commented on CDI-4: ----------------------------- I don't really think it's counter intuitive. A special circumstance, sure. But not counter intuitive. In a stateful system, there are times when one observer is going to need to affect the state of the system in such a way that it needs to come before other observers of the same event. We have this in Servlet, we have this in JSF and I think we need to have it in CDI too. One concrete use case is an observer that responds to the Servlet Initialized Event (assuming we had such an integration) to prepare the request and initialize other context variables so that all other observers of the same event can use these prepared resources. The inverse is needed on destroy. > Need a way to provide ordering for Event observers (@Observes) > -------------------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Fix For: TBD > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
2
0 / 0

[JBoss JIRA] Commented: (CDI-7) Section 10.2, bullet 3, first paragraph contradicts the rest of the section

by Richard Hightower (JIRA)

[ https://issues.jboss.org/browse/CDI-7?page=com.atlassian.jira.plugin.syst... ] Richard Hightower commented on CDI-7: ------------------------------------- a) more qualifiers = more qualified listener > Section 10.2, bullet 3, first paragraph contradicts the rest of the section > --------------------------------------------------------------------------- > > Key: CDI-7 > URL: https://issues.jboss.org/browse/CDI-7 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 1.0 > Reporter: Pete Muir > Priority: Blocker > Fix For: 1.1 (Proposed) > > > "The observer method has all the event qualifiers." > This contradicts the examples (section 10.2.3) and the use of @Any, all of which indicate that less specific observer methods are also invoked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-18) Global enablement of interceptors, decorators and alternatives

by Richard Hightower (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Richard Hightower commented on CDI-18: -------------------------------------- there is some prior art on this in web-fragments.xml and web.xml defined as part of Servlets. It should at least be considered. They may have some good ideas that we can reuse for these types of things. > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.1 (Proposed) > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml). > Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder! > This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml. > Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-30) An API for managing built in contexts

by Richard Hightower (JIRA)

[ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.sys... ] Richard Hightower commented on CDI-30: -------------------------------------- you might want to link to a wiki or a github gist or use the format commands of Jira which are {{{ }}}. I can't read your code. > An API for managing built in contexts > ------------------------------------- > > Key: CDI-30 > URL: https://issues.jboss.org/browse/CDI-30 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Fix For: 1.1 (Proposed) > > > Add management API for built in contexts allowing them to be reused as needed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-92) Allow injection of Bean object for a bean

by Richard Hightower (JIRA)

[ https://issues.jboss.org/browse/CDI-92?page=com.atlassian.jira.plugin.sys... ] Richard Hightower commented on CDI-92: -------------------------------------- It is hard to even consider this without some further explanation. Can you clarify? I went to the link. This needs more discussion. > Allow injection of Bean object for a bean > ----------------------------------------- > > Key: CDI-92 > URL: https://issues.jboss.org/browse/CDI-92 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-7) Section 10.2, bullet 3, first paragraph contradicts the rest of the section

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-7?page=com.atlassian.jira.plugin.syst... ] Mark Struberg commented on CDI-7: --------------------------------- Like to clarify before I get it wrong: If I have a void doDings(@Observes @QualA @QualB @QualC MyEvent ev) {...} Question now is if this method should get invoked if the fired MyEvent has a) ALL the given qualifiers b) ONE of the given qualifiers choose one :) > Section 10.2, bullet 3, first paragraph contradicts the rest of the section > --------------------------------------------------------------------------- > > Key: CDI-7 > URL: https://issues.jboss.org/browse/CDI-7 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 1.0 > Reporter: Pete Muir > Priority: Blocker > Fix For: 1.1 (Proposed) > > > "The observer method has all the event qualifiers." > This contradicts the examples (section 10.2.3) and the use of @Any, all of which indicate that less specific observer methods are also invoked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
1
0 / 0

[JBoss JIRA] Commented: (CDI-10) Add ability to access a bean instance from a proxy

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-10: ---------------------------------- Think this is not really needed. If an Extension hacker really needs such a hardcore hack, then he might as well take the direct route: {code} @Inject BeanManager bm; .. Context ctx = bm.getContext(SessionScoped.class); Bean bean = bm.resolve(bm.getBeans(type, qualifiers); Object instance = ctx.get(bean); {code} So I see no need for such a hack via the proxy... > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: TBD > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-9) Interceptors are not applied to custom bean types

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-9?page=com.atlassian.jira.plugin.syst... ] Mark Struberg commented on CDI-9: --------------------------------- see CDI-8, imo the spec is pretty clear about it (section 8) > Interceptors are not applied to custom bean types > ------------------------------------------------- > > Key: CDI-9 > URL: https://issues.jboss.org/browse/CDI-9 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors, Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: TBD > > > Beans added through the SPI do not have interceptors applied. > Even though bean does not have a getInterceptorBindings() method, interceptors applied to stereotypes should still work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-8) Decorators are not applied to custom beans

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-8?page=com.atlassian.jira.plugin.syst... ] Mark Struberg commented on CDI-8: --------------------------------- Marius, I think you already gave the answer. 8. Decorators Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean. A decorator instance is a dependent object of the object it decorates. If the bean added via AfterBeanDiscovery is no interceptor, decorator or EJB session bean, than the Decorators should just work. Guess this is a Weld issue and not a spec issue (btw, there's a good chance that this doesn't work with OWB neither ;) > Decorators are not applied to custom beans > ------------------------------------------ > > Key: CDI-8 > URL: https://issues.jboss.org/browse/CDI-8 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators, Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: TBD > > > Beans added with AfterBeanDiscovery.addBean() do not have decorators applied -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev April 2011