January 2015 - cdi-dev - Jboss List Archives

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

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-497: ------------------------------- I think it would be reasonable to review this, but as with everything we should be careful about backwards compatibility. > 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-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: ------------------------------------------ {{Instance}}, {{Provider}} (raw types) and {{Object}}. > 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 Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-232: ------------------------------- So now what doe getBeanTypes return? > 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: ------------------------------------------ So we could reword the paragraph like this {quote} The container must provide a built-in bean: * eligible for all injection point of type Instance<T> and Provider<T>, for any T type and having any set of qualifiers, * with scope @Dependent, * with no bean name, and * an implementation provided automatically by the container. The built-in implementation must be a passivation capable dependency, as defined in Passivation capable dependencies. {quote} > 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 Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-232: ------------------------------------- {quote}Do you mean that the current behaviour allow me to put a non valid bean type (inject Instance<Foo> where no beans exist with Foo type) ?{quote} Yes. We should not really change the behavior. Even if we were allowed to do so, this is still a valid usecase. You can have a code such as: {code} @Inject Instance<Foo> instance if (!instance.isUnsatisfied()) { // use foo instance.get(); } else { // use something other than foo } {code} > 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: ------------------------------------------ yes [~jharting], that's why I was starting to propose a new way to define the behaviour. Saying that the container doesn't provide all the Instance for all bean type but only check that the Instance you injected is related to a valid bean type. Do you mean that the current behaviour allow me to put a non valid bean type (inject Instance<Foo> where no beans exist with Foo type) ? > 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

where is defined javax.enterprise.context.conversation.id?

by Romain Manni-Bucau

Hi guys didnt find in CDI and JSF PDFs where is defined "javax.enterprise.context.conversation.id". Seems it should be available in ELs. Do you have any pointer please? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau

9 years, 3 months

7
20
0 / 0

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

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-232: ------------------------------------- No, the behavior is correct. It's the way the behavior is defined that is problematic. The expected behavior is that no matter what legal type X and qualifiers you choose, you'll always get instance injected for Instance<X> and given qualifiers. The way this is specified is by saying that the built-in bean has {quote} • 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} Combined with how CDI resolution rules work this gets the job done (since the built-in bean has all the types and qualifiers, it will always be resolved). In theory this approach is correct. However, it is difficult to materialize since it uses infinite sets (e.g. Bean<Instance>.getTypes() should strictly speaking return and infinite set of all possible bean types) which is inconvenient at best > 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

generalized bean binding mechanism

by Sven Linstaedt

Hi, while reading the discussions about upcoming cdi 2.0 features, I recognized that more and more features (interceptors, CDI-110 <https://issues.jboss.org/browse/CDI-110>) are based on some defined "binding" mechanism. I am asking myself whether the currently bean binding mechanism is going to be generalized and published as part of some API (e.g. lifecycle events) in the near future? Doing so would 1. benefit extension providers have a solid and standardized base for their binding based extensions 2. allow application developers to modify the binding during application startup e.g. by interacting with the thrown lifecycle events. br, Sven

9 years, 3 months

1
0
0 / 0

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

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-497: ---------------------------------------- Yes Antoine. {code} /** * Invalidates this session then unbinds any objects bound * to it. * * @throws IllegalStateException if this method is called on an * already invalidated session */ void invalidate(); {code} This unbind bound objects so basically the scope doesn't have any sense later, id is also changed and session is often recycled (pooling implementation are quite common), it can just introduce inconsistencies IMO - ie make the same session used in 2 requests which are not linked at all, create leaks if the app relies on session id etc... > 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev January 2015