September 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-625: ---------------------------------- {{@AfterDestroyed}} is the new {{@Destroyed}} - just to have consistent names. And if you ask for purpose - it's just backward compatibility. We cannot change the behavior of {{@Destroyed}} and we cannot remove the annotation either. [~antoinesabot-durand] Please correct me if I'm wrong. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{(a)Initialized(X.class)}} is fired when a context is initialized and {{(a)Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{(a)Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{(a)Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{(a)Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-625: -------------------------------- I'm -1 to the changes in the PR. I don't see how after destroyed is useful, due to beans being destroyed. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{(a)Initialized(X.class)}} is fired when a context is initialized and {{(a)Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{(a)Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{(a)Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{(a)Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-634?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-634: -------------------------------- Well, my response was "may" since OWB does something completely different. > Clarify contextual reference validity to a bean with a normal scope in Java SE > ------------------------------------------------------------------------------ > > Key: CDI-634 > URL: https://issues.jboss.org/browse/CDI-634 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: > # start CDI container > # get a reference > # stop CDI container > # start CDI container again and try to use the stored reference. > I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. > See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-634?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-634: ---------------------------------- [~meetoblivion] Because I think it's undefined. And by the way it seems you've also agreed this would deserve some clarification - https://issues.jboss.org/browse/WELD-2190?focusedCommentId=13263160&page=.... The exception is just an implementation detail. > Clarify contextual reference validity to a bean with a normal scope in Java SE > ------------------------------------------------------------------------------ > > Key: CDI-634 > URL: https://issues.jboss.org/browse/CDI-634 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: > # start CDI container > # get a reference > # stop CDI container > # start CDI container again and try to use the stored reference. > I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. > See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-634?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-634: -------------------------------- Not sure why you need spec clarification on this. The complaint on WELD-2190 is that "ContextNotActive" is not the right exception to throw. > Clarify contextual reference validity to a bean with a normal scope in Java SE > ------------------------------------------------------------------------------ > > Key: CDI-634 > URL: https://issues.jboss.org/browse/CDI-634 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: > # start CDI container > # get a reference > # stop CDI container > # start CDI container again and try to use the stored reference. > I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. > See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE

by Martin Kouba (JIRA)

Martin Kouba created CDI-634: -------------------------------- Summary: Clarify contextual reference validity to a bean with a normal scope in Java SE Key: CDI-634 URL: https://issues.jboss.org/browse/CDI-634 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: # start CDI container # get a reference # stop CDI container # start CDI container again and try to use the stored reference. I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.sy... ] Guillermo González de Agüero commented on CDI-370: -------------------------------------------------- Just wondering, could CDI-30 be used to solve cases like this? > Expand @RequestScoped and @SessionScoped to account for WebSocket > ----------------------------------------------------------------- > > Key: CDI-370 > URL: https://issues.jboss.org/browse/CDI-370 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Joseph Snyder > Assignee: Antoine Sabot-Durand > > We've been testing injection into a WebSocket endpoint. > @ReqestScoped objects are usable within the @OnOpen callback. This is because this object is executed within a valid request scope. > However if you try to use the injected object from within the @OnMessage callback you get a Weld error: > SEVERE: org.jboss.weld.context.ContextNotActiveException: > WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped > Can the definition of when @RequestScoped is active be expanded to include a WebSocket @OnMessage callback? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

Invitation: CDI Ctx management Hangout @ Tue Sep 27, 2016 18:00 - 19:00 (CEST) (ASD Perso)

by Antoine Sabot-Durand

You have been invited to the following event. Title: CDI Ctx management Hangout Discussing about CDI-30 When: Tue Sep 27, 2016 18:00 – 19:00 Paris Where: Hangout Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine <https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2l...> Calendar: ASD Perso Who: * Antoine Sabot-Durand - organizer * Mark Struberg * mkouba(a)redhat.com * John D. Ament * cdi-dev(a)lists.jboss.org - optional Your attendance is optional. Event details: https://www.google.com/calendar/event?action=VIEW&eid=Xzg5MmphZDluNzRxNGN... Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev(a)lists.jboss.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

7 years, 7 months

1
0
0 / 0

Proposed times for video chat on context management APIs

by John Ament

All, In talking with Antoine this morning, the proposal is going to be to keep next Tuesday's meeting. Instead of hosting on IRC, we'll do a google hangout. We need at least myself, Martin and Mark on the video (Antoine would like to be there as well [😉] ). So does that time work for everyone? If not, do any other times on Tuesday work? John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

7 years, 7 months

4
6
0 / 0

[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-420: -------------------------------- Don't forget to raise a PR with the spec changes. That will be when the real discussion happens. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > • each Java class, interface or enum deployed in an explicit bean archive, and > • each Java class with a bean defining annotation in an implicit bean archive. > • each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- 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 September 2016