November 2012 - cdi-dev - Jboss List Archives

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

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-294: ----------------------------------- Summary: 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 (Proposed) 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

12 years

3
4
0 / 0

[Vote] @ApplicationScoped and visibility

by Pete Muir

CDI EG members, Please vote on the following two issues by indicating whether you prefer either option (a) or (b) to both questions (1) and (2). Please vote asap, voting closes as soon as I have a complete set of votes from the EG or at COB (Eastern) on 30th Nov, whichever happens sooner :-) Question 1, Visibility --------------------------- The CDI 1.0 specification states that only beans whose bean class is accessible (using standard classloader visibility rules) can be injected into another bean. For example, if you have a bean A in WAR, assuming standard Java EE classloader structure, it wouldn't be available for injection in bean B, in an EJB modiule. This generally makes sense, as the type is not visible either. CDI also offers two options to replace bean implementations transparently, without explicitly selecting that implementation (either by type or using a qualifier) - alternatives and specialization. First, let's consider specialization. For example, if bean B, from the example above, is specialized by bean S in the WAR, and bean C in the same EJB module as B injects a type B, then what should be injected (if anything). The CDI 1.0 specification addresses this issue by disabling any bean which has been specialized across the entire application. Therefore, according to CDI 1.0, this would result in an deployment problem (as there would be an unsatisfied injection point). Alternatives are addressed a little differently in CDI 1.0. For example, if bean B has an alternative A packaged in the WAR, then if A is selected in the war only, then if bean C in the same EJB module as B injects a type B, it would be injected with C. However, if A is selected for the EJB module as well, then the deployment should fail as beans.xml of the EJB module references S which it cannot see. Note that we have also added global visibility for alternatives in CDI 1.1, which may need revising based on what is decided here. The EG has debated two options. (a) maintain the status quo, as described by the CDI 1.0 spec (b) take an approach where visibility is isolated according to the calling context. Thus, if a call originates via the WAR, then specialization and enabled alternatives in the WAR are visible to any bean which is called in that stack. Approximately, Weld takes approach (a), and OWB takes approach (b), so which approach is more backwards compatible here is debatable. Question 2, @ApplicationScoped --------------------------------------------- CDI implementations have not consistently shared @ApplicationScoped beans across all modules of an EAR. Weld, and app servers built on Weld (those that we have surveyed include JBoss AS, GlassFish, WebLogic) have shared application scoped beans across the EAR. OWB isolates @ApplicationScoped beans to the calling context of the WAR, however applications servers built on OWB have shared beans across all modules of an EAR (this is certainly true of WebSphere, and I believe it is true of TomEE). The EG has debated two options. (a) require @ApplicationScoped beans to be shared across all modules of an EAR (b) take an approach where @ApplicationScoped beans are isolated to the calling context Whichever approach is taken, the EG is agreed that a scope that addresses the other option should be introduced. So, please indicated which options you favour: Question 1: (a) OR (b) Question 2: (a) OR (b) Thanks, Pete

12 years

8
20
0 / 0

[JBoss JIRA] (CDI-301) Provide XSD for 1.1 version of beans.xml

by Martin Kouba (JIRA)

Martin Kouba created CDI-301: -------------------------------- Summary: Provide XSD for 1.1 version of beans.xml Key: CDI-301 URL: https://issues.jboss.org/browse/CDI-301 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.1.PRD Reporter: Martin Kouba -- 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

12 years

3
3
0 / 0

[JBoss JIRA] (CDI-267) Consider annotating built in scopes with @Scope

by Julien Viet (JIRA)

Julien Viet created CDI-267: ------------------------------- Summary: Consider annotating built in scopes with @Scope Key: CDI-267 URL: https://issues.jboss.org/browse/CDI-267 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Julien Viet The @Inject spec defines the @Singleton annotation that can be used in @Inject impls or CDI . The annotations defined in CDI can only be used in CDI and could not be reused with @Inject impl. It technically (or per the spec) it is possible to annotation the CDI annotations with @Scope (in addition of @NormalScope) then those annotations could be reused in @Inject implemetentation, removing the need for proprietary annotations that do the same (com.google.inject.servlet.RequestScoped for example). -- 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

12 years

3
6
0 / 0

[JBoss JIRA] (CDI-303) Clarify declaring selected alternatives for an application

by Martin Kouba (JIRA)

Martin Kouba created CDI-303: -------------------------------- Summary: Clarify declaring selected alternatives for an application Key: CDI-303 URL: https://issues.jboss.org/browse/CDI-303 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba It's not clear whether an alternative with a default priority but not selected for an application is selected for the bean archive whose beans.xml declares it. The spec states: {quote} An alternative may be given a default priority, but not selected for an application using the <alternatives> element of the beans.xml file of the bean archive. The <alternatives> element contains a list of bean classes and stereotypes, along with a disabled flag and a priority attribute. An alternative is selected for the bean archive if either: ... {quote} Pay attention to the last sentence of the paragraph. -- 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

12 years

2
1
0 / 0

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

by Arne Limburg (JIRA)

Arne Limburg created CDI-271: -------------------------------- Summary: 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 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

12 years

5
12
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 updated CDI-43: ------------------------- Labels: FAQ with-annotations (was: FAQ) > 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 > Labels: FAQ, with-annotations > 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

12 years

1
0
0 / 0

[JBoss JIRA] (CDI-270) Allow @WithAnnotations to be applied to other events

by Pete Muir (JIRA)

Pete Muir created CDI-270: ----------------------------- Summary: Allow @WithAnnotations to be applied to other events Key: CDI-270 URL: https://issues.jboss.org/browse/CDI-270 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.1.EDR Reporter: Pete Muir Fix For: 1.1 (Proposed) -- 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

12 years

1
2
0 / 0

[JBoss JIRA] (CDI-298) @WithAnnotations needs to consider annotations on superclasses

by Pete Muir (JIRA)

Pete Muir created CDI-298: ----------------------------- Summary: @WithAnnotations needs to consider annotations on superclasses Key: CDI-298 URL: https://issues.jboss.org/browse/CDI-298 Project: CDI Specification Issues Issue Type: Bug Reporter: Pete Muir The wording current prohibits this, it's a mistake in the wording. -- 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

12 years

1
4
0 / 0

[JBoss JIRA] (CDI-226) Clarify the @Singleton behaviour

by Daniel Sachse (JIRA)

Daniel Sachse created CDI-226: --------------------------------- Summary: Clarify the @Singleton behaviour Key: CDI-226 URL: https://issues.jboss.org/browse/CDI-226 Project: CDI Specification Issues Issue Type: Clarification Components: Contexts Affects Versions: 1.1.EDR1 Reporter: Daniel Sachse The specification should make a more clear statement about the Scope and Lifecycle of the @Singleton annotation. ATM it is e.g. totally unclear, in which environment a Singleton is guaranteed to be a Singleton(JVM, EAR, WAR,... ). -- 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

12 years

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2012