January 2015 - cdi-dev - Jboss List Archives

[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 commented on CDI-497: ------------------------------------------ Form what I understand your concern is with [6.7.2. Session context lifecycle|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#session_context] {quote} The session context is destroyed when the {{HTTPSession}} times out, after all {{HttpSessionListener}} s have been called, and at the very end of any request in which {{invalidate()}} was called, after all filters and ServletRequestListener s have been called. {quote} You'd like to see the session scope destroyed when {{invalidate}} is called not at the end of the request as it's specified now? > 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 > > 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.3.11#6341)

9 years, 3 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.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: 2.0 (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.3.11#6341)

9 years, 3 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 updated CDI-493: ------------------------------------- Fix Version/s: 2.0 (discussion) > 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.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-232) Relax requirements for built-in Instance

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-232: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Relax requirements for built-in Instance > ---------------------------------------- > > Key: CDI-232 > URL: https://issues.jboss.org/browse/CDI-232 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.EDR > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > 5.6.2. The built-in Instance > {quote} > The container must provide a built-in bean with: > * Instance<X> and Provider<X> for every legal bean type X in its set of bean types, > * every qualifier type in its set of qualifier types, > {quote} > This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording. > By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-232) Relax requirements for built-in Instance

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-232: ------------------------------------------ Ok got it. I read it in the wrong way. So 5.6.2 should become something like: {quote} The container must provide a built-in bean with: * Instance<?> and Provider<?> in its set of bean types, * scope @Dependent, * no bean name, and * an implementation provided automatically by the container. *For all injection point of type Instance<T> or Provider<T> the container must validate that at least one bean with T in its set of bean types exists. If such a bean doesn't exist, the container automatically detects the problem and treats it as a deployment problem* The built-in implementation must be a passivation capable dependency, as defined in Passivation capable dependencies. {quote} We probably should also mention qualifiers in the validation sentence. > Relax requirements for built-in Instance > ---------------------------------------- > > Key: CDI-232 > URL: https://issues.jboss.org/browse/CDI-232 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.EDR > Reporter: Martin Kouba > Fix For: TBD > > > 5.6.2. The built-in Instance > {quote} > The container must provide a built-in bean with: > * Instance<X> and Provider<X> for every legal bean type X in its set of bean types, > * every qualifier type in its set of qualifier types, > {quote} > This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording. > By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-232) Relax requirements for built-in Instance

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-232: ---------------------------------- It's not about limitiations. As Jozef pointed out it's hardly possible to implement {{Instance}} built-in bean according to requirements. So this is mainly about the correct wording. > Relax requirements for built-in Instance > ---------------------------------------- > > Key: CDI-232 > URL: https://issues.jboss.org/browse/CDI-232 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.EDR > Reporter: Martin Kouba > Fix For: TBD > > > 5.6.2. The built-in Instance > {quote} > The container must provide a built-in bean with: > * Instance<X> and Provider<X> for every legal bean type X in its set of bean types, > * every qualifier type in its set of qualifier types, > {quote} > This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording. > By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-494: ------------------------------------- Fix Version/s: 2.0 (discussion) > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 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 (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 (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.3.11#6341)

9 years, 3 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: 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: 2.0 (discussion) > > > 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.3.11#6341)

9 years, 3 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: ------------------------------------- Component/s: Interceptors > 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 > > 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.3.11#6341)

9 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev January 2015