February 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-315) Allow BeanManager methods, such as getBeans in AfterDeploymentValidation observers

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-315?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-315: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Allow BeanManager methods, such as getBeans in AfterDeploymentValidation observers > ---------------------------------------------------------------------------------- > > Key: CDI-315 > URL: https://issues.jboss.org/browse/CDI-315 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Marek Schmidt > Fix For: 1.1.PFD > > > CDI-274 which disallows some BeanManager methods during application initialization is too strict. > Mark's original suggestion for CDI-274 contained a very important part "...before the AfterDeploymentValidation phase". AfterDeploymentValidation observers would be quite useless if we can't use BeanManager.getBeans in them IMHO, and I think there is no reason to disallow BeanManager methods in AfterDeploymentValidation, so we should allow them there... > So maybe something like: > "IllegalStateException if called during application initialization before the AfterDeploymentValidation phase" -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-294) Clarify that a Java EE component definition never results in a managed bean being created

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-294?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-294: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Clarify that a Java EE component definition never results in a managed bean being created > ----------------------------------------------------------------------------------------- > > Key: CDI-294 > URL: https://issues.jboss.org/browse/CDI-294 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Java EE integration > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.PFD > > > Having e.g. a Servlet that matches managed bean requirements, there is nothing in the spec saying that the container should not take the servlet class and make a managed bean out of it. This results in ProcessInjectionTarget being fired twice. Furthermore, it does not actually make any sense to have Java EE component definitions (e.g. Servlets) to act as managed beans. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-129: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Clarify behaviour of @ApplicationScoped in EARs > ----------------------------------------------- > > Key: CDI-129 > URL: https://issues.jboss.org/browse/CDI-129 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Contexts > Affects Versions: 1.0 > Reporter: Mark Struberg > Assignee: Pete Muir > Labels: application-scoped, visibility > Fix For: 1.1.PFD > > > Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file). > There is currently no specified CDI scope for providing a single shared instance for a whole EAR. > We could (ab-)use @Singleton for that, but this is currently not well defined at all. > Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-307) Use @Priority annotation introduced in common annotations for ordering interceptors, decorators and alternatives

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-307?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-307: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Use @Priority annotation introduced in common annotations for ordering interceptors, decorators and alternatives > ---------------------------------------------------------------------------------------------------------------- > > Key: CDI-307 > URL: https://issues.jboss.org/browse/CDI-307 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Pete Muir > Fix For: 1.1.PFD > > > Common annotations is introducing a @Priority annotation for ordering, we should update our spec to use this, possibly replacing the beans.xml approach. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-313) public Set<Annotation> getInterceptorBindingDefinition(Class<? extends Annotation> qualifierType) parameter should be bindingType

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-313?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-313. --------------------------- Assignee: Pete Muir Resolution: Done This is ok in master https://github.com/jboss/cdi/blob/master/api/src/main/java/javax/enterpri... > public Set<Annotation> getInterceptorBindingDefinition(Class<? extends Annotation> qualifierType) parameter should be bindingType > --------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-313 > URL: https://issues.jboss.org/browse/CDI-313 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Mark Struberg > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PFD > > > The spec defines the BeanManager method > public Set<Annotation> getInterceptorBindingDefinition(Class<? extends Annotation> qualifierType); > the parameter name should actually be 'bindingType', isn't? > The JavaDoc seems ok in this regard already. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-313) public Set<Annotation> getInterceptorBindingDefinition(Class<? extends Annotation> qualifierType) parameter should be bindingType

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-313?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-313: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > public Set<Annotation> getInterceptorBindingDefinition(Class<? extends Annotation> qualifierType) parameter should be bindingType > --------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-313 > URL: https://issues.jboss.org/browse/CDI-313 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Mark Struberg > Priority: Minor > Fix For: 1.1.PFD > > > The spec defines the BeanManager method > public Set<Annotation> getInterceptorBindingDefinition(Class<? extends Annotation> qualifierType); > the parameter name should actually be 'bindingType', isn't? > The JavaDoc seems ok in this regard already. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-314) Clarify behaviour if both a stereotype and a bean class is used to select/deselect an alternative bean

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-314?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-314: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Clarify behaviour if both a stereotype and a bean class is used to select/deselect an alternative bean > ------------------------------------------------------------------------------------------------------ > > Key: CDI-314 > URL: https://issues.jboss.org/browse/CDI-314 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.PRD > Reporter: Martin Kouba > Fix For: 1.1.PFD > > > In CDI 1.1 a bean which has {{@Alternative}} stereotype applied may be selected using the bean class. If both a stereotype and a bean class is used to select/deselect an alternative bean, conflicts may occur (in the cotext of CDI-18). E.g.: > {code} > @Stereotype > @Alternative > @Target({ TYPE, METHOD, FIELD }) > @Retention(RUNTIME) > public @interface Mock { > } > @Mock > class Foo { > } > <beans> > <alternatives> > <class priority="1000">org.mycompany.Foo</class> > <stereotype priority="100">org.mycompany.Mock</stereotype> > </alternatives> > </beans> > {code} -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ] Pete Muir reassigned CDI-271: ----------------------------- Assignee: Arne Limburg > Provide a way to inject Event metadata into an observer method > -------------------------------------------------------------- > > Key: CDI-271 > URL: https://issues.jboss.org/browse/CDI-271 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Arne Limburg > Assignee: Arne Limburg > Fix For: 1.1.PFD > > > Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members). > Consider the following example: > {code} > @Inject @MyQualifier > Event<MyObject> event; > public void fireEvent(MyObject object, MyTypeValue type) { > event.select(new MyTypeAnnotationLiteral(type)).fire(object); > } > {code} > Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this: > {code} > public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) { > MyType annotation = ip.getAnnotated().getAnnotation(MyType.class); > MyTypeValue value = annotation.value(); > ... > } > {code} -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-317) review PassivationCapable interface

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-317?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-317: -------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) > review PassivationCapable interface > ----------------------------------- > > Key: CDI-317 > URL: https://issues.jboss.org/browse/CDI-317 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > Fix For: TBD > > > Currently the spec says that only _passivation capable Beans_ must implement the PassivationCapable interface. > But a Bean class could result in both passivation-capable and not-passivation-capable beans. For e.g. a ProducerMethodBean it depends on the scope of the produced instance. For implementing this properly you would need to always need 2 classes for each bean-type. And even worse - often you know only after the all the Bean-building that this very bean is passivation-capable or not. > Thus I suggest to extend the meaning of PassivationCapable#getId() to allow returning *null* if the very bean doesn't support passivation. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-227) BeanManager#resolve() is underspecified for corner cases

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-227?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-227: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > BeanManager#resolve() is underspecified for corner cases > -------------------------------------------------------- > > Key: CDI-227 > URL: https://issues.jboss.org/browse/CDI-227 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java SE Integration, Packaging and Deployment > Affects Versions: 1.0, 1.1.EDR > Reporter: Guy Veraghtert > Assignee: Pete Muir > Labels: patch > Fix For: 1.1.PFD > > > The CDI api's are mainly used to develop (portable) extensions. In practice, we see that those so called _portable_ extensions are not portable at all due to underspecified api's. > For example BeanManager.resolve(set) doesn't specify how to deal with an empty set or null. This leads to incompatible implementations and unportable extensions. See for example https://issues.apache.org/jira/browse/OWB-625 (Unfortunately Websphere 8 includes openwebbeans < 1.1.3, making Seam3 not out-of-the-box usable). Currently most implementations (weld, owb and candi) return null for an empty set. OWB returns null when null is passed, others will throw an exception. > To create extensions that are truly portable, we should specify all corner cases (what about BeanManager.getBean((String)null)?). In theory developers should not depend on undefined behavior, but in practice we all do (Seam3 is full of examples). > Ideally, we should go over the complete public API and specify what should happen with these corner cases: null-values, empty collections, ... > Just adding that an IllegalArgumentException should be thrown in case of null for example would suffice. > These things are very easy to incorporate in the TCK and would contribute a lot to the success of portable extensions -- 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, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2013