January 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-491) Clarify what happens when an interceptor doesn't have any @AroundInvoke or lifecycle annotation

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-491?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-491: ------------------------------------------ I agree with [~mkouba]. Currently interceptor spec states in 2.1 {quote} An around-invoke interceptor method, an around-timeout interceptor method, and lifecycle callback interceptor methods for different lifecycle events may be defined on the same interceptor class. An interceptor class may have superclasses. {quote} The interceptor spec doesn't forbid to have an interceptor class without lifecycle callback or {{@AroundInvoke}}. Clarification should be made in it. > Clarify what happens when an interceptor doesn't have any @AroundInvoke or lifecycle annotation > ----------------------------------------------------------------------------------------------- > > Key: CDI-491 > URL: https://issues.jboss.org/browse/CDI-491 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Antonio Goncalves > > At the moment, if you enable an interceptor in {{beans.xml}} and the class is not annotated with {{@Inteceptor}}, WELD throws an exception. But if the interceptor has no {{@AroundInvoke}}, {{@AroundConstrcut}}, {{@PostConstruct}} or {{@PreDestroy}}, then WELD stays silent and the interceptor doesn't work. > The spec should clarify that, at least, one of these four annotation has to be used otherwise it's not considered a valid interceptor. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

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

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-496: ------------------------------------- The problem with the TCK test is that it verifies that the container throws a deployment exception if an intercepted session bean is not proxyable. This is an implication of {quote} A bean type must be proxyable if an injection point resolves to a bean: • that requires a client proxy, or • that has an associated decorator, or • that has a bound interceptor. Otherwise, the container automatically detects the problem, and treats it as a deployment problem {quote} The issue here is whether CDI's DeploymentException should really be thrown for a session bean or whether we should let the EJB container fail in whathever way it prefers (and therefore the aforementioned part of the spec should be changed to affect managed beans only). > 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, 11 months

1
0
0 / 0

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

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-496: ---------------------------------- First of all I'm not sure EJB requirements exactly match CDI requirements (e.g. EJB 3.2 does not forbid non-static final methods, see "4.9.2 Session Bean Class"). Also sentences like: {quote} Interceptor bindings may be used to associate interceptors with any managed bean that is not a decorator. {quote} are just confusing (9.3. Binding an interceptor to a bean). Lastly the wording: bq. ...the managed bean must be a proxyable bean type is not accurate and would deserve a minor revision. However, I would lower the priority of this issue as it's obvious that bindings can be used for session beans. > 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, 11 months

1
0
0 / 0

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

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-496: ---------------------------------------- there are TCKs - sorry dont have the test name anymore - validing EJB impl class for proxying and expects it to fail with a CDI exception where CDI shouldn't see it. > 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, 11 months

1
0
0 / 0

Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ?

by Antonio Goncalves

Hi all, I was playing with @SessionScoped beans... and wondered if @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ? At the moment these annotations belong to the javax.ejb package and are only used in @Stateful EJBs. With CDI scopes, we end up with a few "stateful" scopes (@SessionScoped, but also @ConversationScoped, @ViewScoped...) so why not having the same functionality in CDI ? @PreDestroy and @PostConstruct are already part of JSR 250. So why not having @PostActivate and @PrePassivate as well so they could be used in every bean ? BTW, while I was playing with @SessionScoped beans, I asked Antoine to show me how to remove a bean from the session. It's only a few lines of code, but again, why not having a @Remove annotation that does that (the exact same one of javax.ejb.Remove) ? To summarize, why not taking some of those stateful EJB concerns back to JSR 250 so they could be used anywhere ? Any thoughts ? -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>

9 years, 11 months

6
9
0 / 0

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

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-496: ------------------------------- The second statement (about proxability) does not affect what beans can be intercepted. The reason session beans are not mentioned here is because the EJB specification defines that the bean must be proxiable. I don't really understand this issue. > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-489) NonexistentConversationException thrown at restore view or not?

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-489?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-489: ------------------------------------- Fix Version/s: 2.0 (proposed) > NonexistentConversationException thrown at restore view or not? > --------------------------------------------------------------- > > Key: CDI-489 > URL: https://issues.jboss.org/browse/CDI-489 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.2.Final > Reporter: Vsevolod Golovanov > Fix For: 2.0 (proposed) > > > The 1.0 spec says in 6.7.4: > {quote}If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.NonexistentConversationException from the restore > view phase of the JSF lifecycle. The application may handle this exception using the JSF ExceptionHandler.{quote} > 1.1 and 1.2 just say: > {quote} > If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and > throw an exception of type javax.enterprise.context.NonexistentConversationException. > {quote} > Yet the javadoc of NonexistentConversationException for both 1.1 and 1.2 says: > {quote} > If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type NonexistentConversationException from the restore view phase of the JSF lifecycle. > {quote} > So is it supposed to be thrown from restore view or not? I assume not. Probably javadoc should be amended. > I'm curious about reasoning behind the change. I tried searching for an explanation but didn't find anything. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 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 (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 (discussion) > > > 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, 11 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 (proposed) (was: 2.0 (discussion)) > 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 (proposed) > > > 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, 11 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: ------------------------------- I think that needs including in the spec. > 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, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev January 2015