October 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-488) InjectionPoint SPI should expose whether an injection point is @TransientReference

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-488?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-488: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > InjectionPoint SPI should expose whether an injection point is @TransientReference > ---------------------------------------------------------------------------------- > > Key: CDI-488 > URL: https://issues.jboss.org/browse/CDI-488 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Jozef Hartinger > Fix For: TBD > > > Similarly to InjectionPoint.isDelegate(), the SPI should expose whether an injection points requires a @TransientReference or not. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-492: ------------------------------------------ Had a discussion with [~edburns] at Java One. We agreed on re-discussing this topic for servlet next iteration and probably CDI 2.1. > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: 2.1 (Discussion) > > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_...] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-492: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: TBD) > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: 2.1 (Discussion) > > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_...] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-492: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: TBD > > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_...] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-493) Allow firing of parameterized event types from BeanManager

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand resolved CDI-493. -------------------------------------- Release Notes Text: Solved by CDI-633 Resolution: Duplicate Issue > Allow firing of parameterized event types from BeanManager > ---------------------------------------------------------- > > Key: CDI-493 > URL: https://issues.jboss.org/browse/CDI-493 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.2.Final > Reporter: Sven Linstaedt > Fix For: 2.0 (discussion) > > > Currently we are allowed firing generic events from {{javax.enterprise.event.Event<X>#fire}} as long as it's type parameter X does not contain a TypeVariable. > When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}. > This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager > {code} > BeanManager#fireEvent(Type, Object, Annotation...) > BeanManager#resolveObserverMethods(Type, T, Annotation...) > {code} > which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards. > The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. > Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type. > With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like > {code} > <X> void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType<X> pbt) { > if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) { > // register interceptor type > } else { > // register intercepted type > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-495: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > What happens if an illegal bean type is found in the set of bean types > ---------------------------------------------------------------------- > > Key: CDI-495 > URL: https://issues.jboss.org/browse/CDI-495 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-495: ------------------------------------------ +1 to add a mention of ignoring the type > What happens if an illegal bean type is found in the set of bean types > ---------------------------------------------------------------------- > > Key: CDI-495 > URL: https://issues.jboss.org/browse/CDI-495 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-496) Clarification (or completion) for interceptor binding to session bean

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-496: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Clarification (or completion) for interceptor binding to session bean > --------------------------------------------------------------------- > > Key: CDI-496 > URL: https://issues.jboss.org/browse/CDI-496 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Fix For: TBD > > > It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement: > {quote}Managed beans and EJB session and message-driven beans support interception.{quote} > But at the end of "9.3. Binding an interceptor to a bean" There is only: > {quote} > If a managed bean has a class-level or method-level interceptor binding, the managed bean must > be a proxyable bean type, as defined in Section 3.15, “Unproxyable bean types”. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-497) session scope doesn't follow session lifecycle

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-497: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > session scope doesn't follow session lifecycle > ---------------------------------------------- > > Key: CDI-497 > URL: https://issues.jboss.org/browse/CDI-497 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > Fix For: 2.0 .Final > > > ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case). > Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-498) Revise "6.7.5. The Conversation interface" - dots are not valid in EL name

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-498?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-498: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Revise "6.7.5. The Conversation interface" - dots are not valid in EL name > -------------------------------------------------------------------------- > > Key: CDI-498 > URL: https://issues.jboss.org/browse/CDI-498 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > Seems that following part contradicts the EL spec: > {quote}The container provides a built-in bean with bean type Conversation , scope @RequestScoped , > and qualifier @Default , named javax.enterprise.context.conversation .{quote} > The EL name "javax.enterprise.context.conversation" is not valid. > Discussion available at http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23... > and > http://lists.jboss.org/pipermail/cdi-dev/2015-January/thread.html - topic "where is defined javax.enterprise.context.conversation.id?" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2016