From issues at jboss.org Mon Jul 2 07:39:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 2 Jul 2018 07:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: Mark Struberg created CDI-732: --------------------------------- Summary: Clarify that the Context for RequestScoped must be active during @PreDestroy calls Key: CDI-732 URL: https://issues.jboss.org/browse/CDI-732 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Affects Versions: 2.0 .Final Reporter: Mark Struberg We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. But it seems we don't force the same for invocations of @PreDestroy methods. That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 2 10:01:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 2 Jul 2018 10:01:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599531#comment-13599531 ] Matej Novotny commented on CDI-732: ----------------------------------- This can be tricky because we do not know in what order should we destroy those "HTTP-related" scopes(e.g. session, request and conversation). Spec doesn't mention it and according to what you write I presume implementations differ already. Based on this premise it may not make sense to have it active, at least not in all cases - for instance if you were to destroy request scoped beans before session scope ones, you would need to recreate those req. beans just to have them available in {{@PreDestroy}} of session scope bean. > Clarify that the Context for RequestScoped must be active during @PreDestroy calls > ---------------------------------------------------------------------------------- > > Key: CDI-732 > URL: https://issues.jboss.org/browse/CDI-732 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. > But it seems we don't force the same for invocations of @PreDestroy methods. > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 2 17:47:00 2018 From: issues at jboss.org (Benjamin Confino (JIRA)) Date: Mon, 2 Jul 2018 17:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599787#comment-13599787 ] Benjamin Confino commented on CDI-732: -------------------------------------- Unless I am mistaken there is a rule that a session scope should remain active until all the associated requests are finished. The spec says a session context is destroyed "and at the very end of any request in which invalidate() was called" - keywords "very end", but I think even if it didn't call invalidate() sessions always last until the very end of their associated requests. This to me suggests RequestScoped beans will be destroyed first, and thus it makes sense that they're not available during the PreDestroy of a SessionScope bean. However from my perspective it doesn't matter which is destroyed first, so long as the spec is updated to define the order. > Clarify that the Context for RequestScoped must be active during @PreDestroy calls > ---------------------------------------------------------------------------------- > > Key: CDI-732 > URL: https://issues.jboss.org/browse/CDI-732 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. > But it seems we don't force the same for invocations of @PreDestroy methods. > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 2 17:48:00 2018 From: issues at jboss.org (Benjamin Confino (JIRA)) Date: Mon, 2 Jul 2018 17:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-730) The order in which contexts are destroyed is undefined. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599788#comment-13599788 ] Benjamin Confino commented on CDI-730: -------------------------------------- CDI-732 is a duplicate of this issue. > The order in which contexts are destroyed is undefined. > ------------------------------------------------------- > > Key: CDI-730 > URL: https://issues.jboss.org/browse/CDI-730 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.Future, 1.2.Final, 2.0 .Final > Reporter: Benjamin Confino > Priority: Minor > > The order in which contexts are destroyed is not defined in the spec, I believe this should be made explicit. > At present weld destroys conversation, request, then session context in that order. I think this should become the standard and written into the spec. > For background there is this email by Martin Kouba: http://lists.jboss.org/pipermail/weld-dev/2018-June/003694.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 3 02:36:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 3 Jul 2018 02:36:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599842#comment-13599842 ] Matej Novotny commented on CDI-732: ----------------------------------- I am afraid "very end" is still somewhat vague, but I do agree that it makes more sense to first destroy request scoped, then session scoped beans. > Clarify that the Context for RequestScoped must be active during @PreDestroy calls > ---------------------------------------------------------------------------------- > > Key: CDI-732 > URL: https://issues.jboss.org/browse/CDI-732 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. > But it seems we don't force the same for invocations of @PreDestroy methods. > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 3 02:50:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 3 Jul 2018 02:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599849#comment-13599849 ] Romain Manni-Bucau commented on CDI-732: ---------------------------------------- Isnt it the opposite actually? A session only makes sense if there is a request so last request must stay longer than its session (except invalidate case but this one is clear). Also specifications made request scope available almost everywhere so it would create an exception to not align it on the servlet behavior. > Clarify that the Context for RequestScoped must be active during @PreDestroy calls > ---------------------------------------------------------------------------------- > > Key: CDI-732 > URL: https://issues.jboss.org/browse/CDI-732 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. > But it seems we don't force the same for invocations of @PreDestroy methods. > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 3 03:19:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 3 Jul 2018 03:19:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599861#comment-13599861 ] Matej Novotny commented on CDI-732: ----------------------------------- bq. A session only makes sense if there is a request... One or more requests exist/live within a session. It seems logical to first destroy the "shorter-lived" scopes such as request and conversation and only after that the "encompassing" session. bq. Also specifications made request scope available almost everywhere... True but in many cases it is artificial in a sense that new beans are created for just that occasion and then tossed away. That could be done even here, but the usefulness is arguable - I would expect to either have that bean existing with a given state (in case of invalidation) or to not have it at all. > Clarify that the Context for RequestScoped must be active during @PreDestroy calls > ---------------------------------------------------------------------------------- > > Key: CDI-732 > URL: https://issues.jboss.org/browse/CDI-732 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. > But it seems we don't force the same for invocations of @PreDestroy methods. > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From arjan.tijms at gmail.com Tue Jul 10 05:30:54 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 10 Jul 2018 10:30:54 +0100 Subject: [cdi-dev] Portable decorable Bean instances Message-ID: Hi, When adding a manually constructed Bean instance using AfterBeanDiscovery.addBean(Bean), or using the AfterBeanDiscovery.addBean() method and the BeanConfigurator, the resulting bean can't be decorated. This is because seemingly CDI expects the create() method of Bean to locate the decorators itself and apply them to the instance it returns. Using BeanManager.resolveDecorators one can obtain the Decorator instances, but am I right that there's no portable way to actually apply those decorators to the bean instance? Kind regards, Arjan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180710/c640395b/attachment.html From manovotn at redhat.com Tue Jul 10 06:04:43 2018 From: manovotn at redhat.com (Matej Novotny) Date: Tue, 10 Jul 2018 06:04:43 -0400 (EDT) Subject: [cdi-dev] Portable decorable Bean instances In-Reply-To: References: Message-ID: <1603625784.49044010.1531217083535.JavaMail.zimbra@redhat.com> Hi, yes, there is no portable way. It is a similar situation as was with interceptors before InterceptionFactory was added. [impl 'details'] In principle, to implement this, you need to create a "wrapper class" around the object which is to be intercepted/decorated. If you provide a custom way to create the bean, it is very difficult to create this wrapper on-the-fly. Even the solution for interceptors has some shortcomings and flaws and decorators seem even more complex (less restrictions on how does a decorator look like). Matej ----- Original Message ----- > From: "arjan tijms" > To: cdi-dev at lists.jboss.org > Sent: Tuesday, July 10, 2018 11:30:54 AM > Subject: [cdi-dev] Portable decorable Bean instances > > Hi, > > When adding a manually constructed Bean instance using > AfterBeanDiscovery.addBean(Bean), or using the > AfterBeanDiscovery.addBean() method and the BeanConfigurator, the resulting > bean can't be decorated. > > This is because seemingly CDI expects the create() method of Bean to > locate the decorators itself and apply them to the instance it returns. > > Using BeanManager.resolveDecorators one can obtain the Decorator > instances, but am I right that there's no portable way to actually apply > those decorators to the bean instance? > > Kind regards, > Arjan > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. From arjan.tijms at gmail.com Tue Jul 10 07:45:12 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 10 Jul 2018 12:45:12 +0100 Subject: [cdi-dev] Portable decorable Bean instances In-Reply-To: <1603625784.49044010.1531217083535.JavaMail.zimbra@redhat.com> References: <1603625784.49044010.1531217083535.JavaMail.zimbra@redhat.com> Message-ID: Hi, Thanks for the reply. I already feared that to be the answer. This would probably be a good enhancement request for CDI 2.1. At the very least the BeanConfigurator could have a method like BeanConfigurator#setDecorators... decorators. That's seemingly doable to implement by the CDI implementations. Kind regards, Arjan On Tue, Jul 10, 2018 at 11:04 AM Matej Novotny wrote: > Hi, > > yes, there is no portable way. > It is a similar situation as was with interceptors before > InterceptionFactory was added. > > [impl 'details'] > In principle, to implement this, you need to create a "wrapper class" > around the object which is to be intercepted/decorated. > If you provide a custom way to create the bean, it is very difficult to > create this wrapper on-the-fly. > Even the solution for interceptors has some shortcomings and flaws and > decorators seem even more complex (less restrictions on how does a > decorator look like). > > Matej > > ----- Original Message ----- > > From: "arjan tijms" > > To: cdi-dev at lists.jboss.org > > Sent: Tuesday, July 10, 2018 11:30:54 AM > > Subject: [cdi-dev] Portable decorable Bean instances > > > > Hi, > > > > When adding a manually constructed Bean instance using > > AfterBeanDiscovery.addBean(Bean), or using the > > AfterBeanDiscovery.addBean() method and the BeanConfigurator, the > resulting > > bean can't be decorated. > > > > This is because seemingly CDI expects the create() method of Bean to > > locate the decorators itself and apply them to the instance it returns. > > > > Using BeanManager.resolveDecorators one can obtain the Decorator > > instances, but am I right that there's no portable way to actually apply > > those decorators to the bean instance? > > > > Kind regards, > > Arjan > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code > > under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > intellectual > > property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180710/df6ec1f4/attachment.html From mkouba at redhat.com Tue Jul 10 08:46:23 2018 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 10 Jul 2018 14:46:23 +0200 Subject: [cdi-dev] Portable decorable Bean instances In-Reply-To: References: <1603625784.49044010.1531217083535.JavaMail.zimbra@redhat.com> Message-ID: <229cfa79-b39b-af5b-bc75-757085270acf@redhat.com> Dne 10.7.2018 v 13:45 arjan tijms napsal(a): > Hi, > > Thanks for the reply. I already feared that to be the answer. > > This would probably be a good enhancement request for CDI 2.1. At the > very least the BeanConfigurator could have a method like > BeanConfigurator#setDecorators... decorators. That's > seemingly doable to implement by the CDI implementations. Well, it's not that simple. In order to make decorators work the instance produced by Bean#create(CreationalContext) must be proxied, decorated types only include interfaces, etc. There are few issues related to this topic. I'd suggest to walk through all those issues, close duplicates and outdated issues and create a new one with distilled summary... > > Kind regards, > Arjan > > > > > > On Tue, Jul 10, 2018 at 11:04 AM Matej Novotny > wrote: > > Hi, > > yes, there is no portable way. > It is a similar situation as was with interceptors before > InterceptionFactory was added. > > [impl 'details'] > In principle, to implement this, you need to create a "wrapper > class" around the object which is to be intercepted/decorated. > If you provide a custom way to create the bean, it is very difficult > to create this wrapper on-the-fly. > Even the solution for interceptors has some shortcomings and flaws > and decorators seem even more complex (less restrictions on how does > a decorator look like). > > Matej > > ----- Original Message ----- > > From: "arjan tijms" > > > To: cdi-dev at lists.jboss.org > > Sent: Tuesday, July 10, 2018 11:30:54 AM > > Subject: [cdi-dev] Portable decorable Bean instances > > > > Hi, > > > > When adding a manually constructed Bean instance using > > AfterBeanDiscovery.addBean(Bean), or using the > > AfterBeanDiscovery.addBean() method and the BeanConfigurator, the > resulting > > bean can't be decorated. > > > > This is because seemingly CDI expects the create() method of > Bean to > > locate the decorators itself and apply them to the instance it > returns. > > > > Using BeanManager.resolveDecorators one can obtain the Decorator > > instances, but am I right that there's no portable way to > actually apply > > those decorators to the bean instance? > > > > Kind regards, > > Arjan > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider > licenses the code > > under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas > > provided on this list, the provider waives all patent and other > intellectual > > property rights inherent in such information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From asd at redhat.com Wed Jul 11 04:10:54 2018 From: asd at redhat.com (Antoine Sabot-Durand) Date: Wed, 11 Jul 2018 10:10:54 +0200 Subject: [cdi-dev] CDI security release around the corner Message-ID: Hi all, As stated a few weeks ago we have worked on issues in CDI API regarding security manager. 2 PR are currently open [1] [2]. The first one is ready to merge, second one need some discussion and possible rework. If none of you raise concern about these, I plan to merge these PR and release CDI 2.0.SP1 by the end of next week. Thanks for your feedback, Antoine [1] https://github.com/cdi-spec/cdi/pull/390 [2] https://github.com/cdi-spec/cdi/pull/391 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180711/217bf5ab/attachment.html From issues at jboss.org Mon Jul 16 03:01:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 16 Jul 2018 03:01:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605259#comment-13605259 ] Mark Struberg commented on CDI-732: ----------------------------------- > It seems logical to first destroy the "shorter-lived" scopes Hmm but Welds destroy order according to CDI-730 is > At present weld destroys conversation, request, then session context in that order. conversation is clearly longer than request. Thus this argument makes no sense. Another point to think about: in CDI the RequestScoped Context is also used as kind of 'ThreadScoped'. For example it is also active in an Asynchronous EJB method, in JBatch threads, etc. So even if the Session gets destroyed outside of a HTTP Request (e.g. via timeout), then we could start a RequestContext, perform the @PreDestroy method and stop if afterwards. > Clarify that the Context for RequestScoped must be active during @PreDestroy calls > ---------------------------------------------------------------------------------- > > Key: CDI-732 > URL: https://issues.jboss.org/browse/CDI-732 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. > But it seems we don't force the same for invocations of @PreDestroy methods. > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 03:05:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 16 Jul 2018 03:05:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605260#comment-13605260 ] Romain Manni-Bucau commented on CDI-732: ---------------------------------------- [~struberg] this doesn't solve the problem correctly IMHO. request = thread scope is an abuse of users but not what is the scope normally. A lot of usages are about request = ... request :). If you think about an audit implementation by request you breaks it if the request scope is not the last one destroyed so I think session should be destroyed before the request in any case. Having 2 instances in the same real servlet request would be very misleading and pretty much unusable at all stages (perf, understanding, impl). > Clarify that the Context for RequestScoped must be active during @PreDestroy calls > ---------------------------------------------------------------------------------- > > Key: CDI-732 > URL: https://issues.jboss.org/browse/CDI-732 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. > But it seems we don't force the same for invocations of @PreDestroy methods. > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 04:11:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 16 Jul 2018 04:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-730) The order in which contexts are destroyed is undefined. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605310#comment-13605310 ] Mark Struberg commented on CDI-730: ----------------------------------- I understand the argument that the order is really hard to get right. But I would love if we could clarify the following: * When a request ends, first ALL the @BeforeDestroyed events for the following contexts are sent: RequestScope, ConversationScoped (if context ends), SessionScoped (if session ends) * Only after that the proper @PreDestroy methods are called on all those scopes. PS: the deferral of the session destroy to the end of the request is a left over of the (failed) Seam2 compatibility mode. It should have never be done that way and really causes tons of problems :( In OWB there is even a way to turn this off and make it follow the standard Servlets Sesion lifecycle because it caused so many problems. > The order in which contexts are destroyed is undefined. > ------------------------------------------------------- > > Key: CDI-730 > URL: https://issues.jboss.org/browse/CDI-730 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.Future, 1.2.Final, 2.0 .Final > Reporter: Benjamin Confino > Priority: Minor > > The order in which contexts are destroyed is not defined in the spec, I believe this should be made explicit. > At present weld destroys conversation, request, then session context in that order. I think this should become the standard and written into the spec. > For background there is this email by Martin Kouba: http://lists.jboss.org/pipermail/weld-dev/2018-June/003694.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 04:18:01 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 16 Jul 2018 04:18:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605323#comment-13605323 ] Mark Struberg commented on CDI-732: ----------------------------------- The problem is that lots of code relies on the RequestScoped context. E.g. if you use a @RequestScoped Principal. Or a @RequestScoped EntityManager. In the first case you might get a default user and yes, this might be hard to understand for the user. I would also prefer to end the Session before the Request Context. > Clarify that the Context for RequestScoped must be active during @PreDestroy calls > ---------------------------------------------------------------------------------- > > Key: CDI-732 > URL: https://issues.jboss.org/browse/CDI-732 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. > But it seems we don't force the same for invocations of @PreDestroy methods. > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 17 17:16:00 2018 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Tue, 17 Jul 2018 17:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607132#comment-13607132 ] Emily Jiang commented on CDI-587: --------------------------------- I vote for this issue. I also would like to see the contexts for SessionScoped, ConversationScoped are also propagated. I came up with the similar design as Romain. The default should be 'false' for context propagation so that the existing apps remain unaffected. > Propose a way to propagate an existing context > ---------------------------------------------- > > Key: CDI-587 > URL: https://issues.jboss.org/browse/CDI-587 > Project: CDI Specification Issues > Issue Type: Epic > Components: Contexts > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. > An example is starting an AsyncContext in a servlet. > One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. > Note however this issue is not only bound to servlets even if it is the easiest example. > The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Life-Cycle-td5712701.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jul 18 09:37:00 2018 From: issues at jboss.org (Gordon Hutchison (JIRA)) Date: Wed, 18 Jul 2018 09:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607569#comment-13607569 ] Gordon Hutchison commented on CDI-587: -------------------------------------- The issue of the lifecyle of the RequestScope is touched on in the discussion thread. For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts. However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements - downstream of this, which of the 10 incoming contexts should be propogated? One could envisage: 1 - provide an API - enabling the Publisher(/Operator) to select the downstream context as a function of the contexts associated with the onNext items passed in, 2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request, 3 - or a null context (exception if scoped bean injected) or... 3 - one could specify it was the context that was active when the 'last' of each ten stream elements was processed etc. What, for example, would be the correct RequestScope downstream of CombineLatest operator if each operand stream had a valid RequestScope? How would the CombineLatest operator function 'help' the system provide the correct RequestScope downstream? https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-depth-CombineLatest A similar situation could be set up using CompletionStage:runAfterBothAsync etc. > Propose a way to propagate an existing context > ---------------------------------------------- > > Key: CDI-587 > URL: https://issues.jboss.org/browse/CDI-587 > Project: CDI Specification Issues > Issue Type: Epic > Components: Contexts > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. > An example is starting an AsyncContext in a servlet. > One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. > Note however this issue is not only bound to servlets even if it is the easiest example. > The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Life-Cycle-td5712701.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jul 18 09:38:02 2018 From: issues at jboss.org (Gordon Hutchison (JIRA)) Date: Wed, 18 Jul 2018 09:38:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607569#comment-13607569 ] Gordon Hutchison edited comment on CDI-587 at 7/18/18 9:37 AM: --------------------------------------------------------------- The issue of the lifecyle of the RequestScope is touched on in the discussion thread. For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts. However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements - downstream of this, which of the 10 incoming contexts should be propogated? One could envisage: 1 - provide an API - enabling the Publisher(/Operator) to select the downstream context as a function of the contexts associated with the onNext items passed in, 2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request, 3 - or a null context (exception if scoped bean injected) or... 3 - one could specify it was the context that was active when the 'last' of each ten stream elements was processed etc. What, for example, would be the correct RequestScope downstream of CombineLatest operator if each operand stream had a valid RequestScope? How would the CombineLatest operator function 'help' the system provide the correct RequestScope downstream? https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-depth-CombineLatest A similar situation could be set up using CompletionStage:runAfterBothAsync etc. was (Author: hutchig): The issue of the lifecyle of the RequestScope is touched on in the discussion thread. For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts. However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements - downstream of this, which of the 10 incoming contexts should be propogated? One could envisage: 1 - provide an API - enabling the Publisher(/Operator) to select the downstream context as a function of the contexts associated with the onNext items passed in, 2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request, 3 - or a null context (exception if scoped bean injected) or... 3 - one could specify it was the context that was active when the 'last' of each ten stream elements was processed etc. What, for example, would be the correct RequestScope downstream of CombineLatest operator if each operand stream had a valid RequestScope? How would the CombineLatest operator function 'help' the system provide the correct RequestScope downstream? https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-depth-CombineLatest A similar situation could be set up using CompletionStage:runAfterBothAsync etc. > Propose a way to propagate an existing context > ---------------------------------------------- > > Key: CDI-587 > URL: https://issues.jboss.org/browse/CDI-587 > Project: CDI Specification Issues > Issue Type: Epic > Components: Contexts > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. > An example is starting an AsyncContext in a servlet. > One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. > Note however this issue is not only bound to servlets even if it is the easiest example. > The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Life-Cycle-td5712701.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jul 18 09:41:01 2018 From: issues at jboss.org (Gordon Hutchison (JIRA)) Date: Wed, 18 Jul 2018 09:41:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607569#comment-13607569 ] Gordon Hutchison edited comment on CDI-587 at 7/18/18 9:40 AM: --------------------------------------------------------------- The issue of the lifecyle of the RequestScope is touched on in the discussion thread. For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts. However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements - downstream of this, which of the 10 incoming contexts should be propogated? One could envisage: 1 - provide an API - enabling the Publisher(/Operator) to select the downstream context as a function of the contexts associated with the onNext items passed in, 2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request, 3 - or a null context (exception if scoped bean injected) or... 4 - one could specify it was the context that was active when the 'last' of each ten stream elements was processed etc. What, for example, would be the correct RequestScope downstream of CombineLatest operator if each operand stream had a valid RequestScope? How would the CombineLatest operator function 'help' the system provide the correct RequestScope downstream? https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-depth-CombineLatest A similar situation could be set up using CompletionStage:runAfterBothAsync etc. was (Author: hutchig): The issue of the lifecyle of the RequestScope is touched on in the discussion thread. For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts. However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements - downstream of this, which of the 10 incoming contexts should be propogated? One could envisage: 1 - provide an API - enabling the Publisher(/Operator) to select the downstream context as a function of the contexts associated with the onNext items passed in, 2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request, 3 - or a null context (exception if scoped bean injected) or... 3 - one could specify it was the context that was active when the 'last' of each ten stream elements was processed etc. What, for example, would be the correct RequestScope downstream of CombineLatest operator if each operand stream had a valid RequestScope? How would the CombineLatest operator function 'help' the system provide the correct RequestScope downstream? https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-depth-CombineLatest A similar situation could be set up using CompletionStage:runAfterBothAsync etc. > Propose a way to propagate an existing context > ---------------------------------------------- > > Key: CDI-587 > URL: https://issues.jboss.org/browse/CDI-587 > Project: CDI Specification Issues > Issue Type: Epic > Components: Contexts > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. > An example is starting an AsyncContext in a servlet. > One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. > Note however this issue is not only bound to servlets even if it is the easiest example. > The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Life-Cycle-td5712701.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jul 18 09:43:00 2018 From: issues at jboss.org (Gordon Hutchison (JIRA)) Date: Wed, 18 Jul 2018 09:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607569#comment-13607569 ] Gordon Hutchison edited comment on CDI-587 at 7/18/18 9:42 AM: --------------------------------------------------------------- The issue of the lifecyle of the RequestScope is touched on in the discussion thread. For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts. However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements - downstream of this, which of the 10 incoming contexts should be propogated? One could envisage: 1 - provide an API - enabling the Publisher(/Operator) to select the downstream context as a function of the contexts associated with the onNext items passed in, 2 - a new context (enabling @RequestScoped beans to be used but not shared with a 'real' request, 3 - or a null context (exception if scoped bean injected) or... 4 - one could specify it was the context that was active when the 'last' of each ten stream elements was processed etc. What, for example, would be the correct RequestScope downstream of CombineLatest operator if each operand stream had a valid RequestScope? How would the CombineLatest operator function 'help' the system provide the correct RequestScope downstream? https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-depth-CombineLatest A similar situation could be set up using CompletionStage:runAfterBothAsync etc. was (Author: hutchig): The issue of the lifecyle of the RequestScope is touched on in the discussion thread. For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts. However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements - downstream of this, which of the 10 incoming contexts should be propogated? One could envisage: 1 - provide an API - enabling the Publisher(/Operator) to select the downstream context as a function of the contexts associated with the onNext items passed in, 2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request, 3 - or a null context (exception if scoped bean injected) or... 4 - one could specify it was the context that was active when the 'last' of each ten stream elements was processed etc. What, for example, would be the correct RequestScope downstream of CombineLatest operator if each operand stream had a valid RequestScope? How would the CombineLatest operator function 'help' the system provide the correct RequestScope downstream? https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-depth-CombineLatest A similar situation could be set up using CompletionStage:runAfterBothAsync etc. > Propose a way to propagate an existing context > ---------------------------------------------- > > Key: CDI-587 > URL: https://issues.jboss.org/browse/CDI-587 > Project: CDI Specification Issues > Issue Type: Epic > Components: Contexts > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. > An example is starting an AsyncContext in a servlet. > One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. > Note however this issue is not only bound to servlets even if it is the easiest example. > The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Life-Cycle-td5712701.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jul 18 09:44:01 2018 From: issues at jboss.org (Gordon Hutchison (JIRA)) Date: Wed, 18 Jul 2018 09:44:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607569#comment-13607569 ] Gordon Hutchison edited comment on CDI-587 at 7/18/18 9:43 AM: --------------------------------------------------------------- The issue of the lifecyle of the RequestScope is touched on in the discussion thread. For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts. However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements - downstream of this, which of the 10 incoming contexts should be propogated? One could envisage: 1 - provide an API - enabling the Publisher(/Operator) to select the downstream context as a function of the contexts associated with the onNext items passed in, 2 - a new context (enabling @RequestScoped beans to be used but not shared with a 'real' request, 3 - or a null context (exception if scoped bean injected) or... 4 - one could specify it was the context that was active when the 'last' of each ten stream elements was processed i.e. when the Publisher calls onNext on the Subscribers etc. What, for example, would be the correct RequestScope downstream of CombineLatest operator if each operand stream had a valid RequestScope? How would the CombineLatest operator function 'help' the system provide the correct RequestScope downstream? https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-depth-CombineLatest A similar situation could be set up using CompletionStage:runAfterBothAsync etc. was (Author: hutchig): The issue of the lifecyle of the RequestScope is touched on in the discussion thread. For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts. However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements - downstream of this, which of the 10 incoming contexts should be propogated? One could envisage: 1 - provide an API - enabling the Publisher(/Operator) to select the downstream context as a function of the contexts associated with the onNext items passed in, 2 - a new context (enabling @RequestScoped beans to be used but not shared with a 'real' request, 3 - or a null context (exception if scoped bean injected) or... 4 - one could specify it was the context that was active when the 'last' of each ten stream elements was processed etc. What, for example, would be the correct RequestScope downstream of CombineLatest operator if each operand stream had a valid RequestScope? How would the CombineLatest operator function 'help' the system provide the correct RequestScope downstream? https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-depth-CombineLatest A similar situation could be set up using CompletionStage:runAfterBothAsync etc. > Propose a way to propagate an existing context > ---------------------------------------------- > > Key: CDI-587 > URL: https://issues.jboss.org/browse/CDI-587 > Project: CDI Specification Issues > Issue Type: Epic > Components: Contexts > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. > An example is starting an AsyncContext in a servlet. > One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. > Note however this issue is not only bound to servlets even if it is the easiest example. > The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Life-Cycle-td5712701.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jul 18 09:44:01 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 18 Jul 2018 09:44:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607583#comment-13607583 ] Romain Manni-Bucau commented on CDI-587: ---------------------------------------- Since CDI 2 we could have a simple solution reusing RequestContextController and adding a method to be able to manipulate the context: {code} RequestContextController scope = controller.handler(); // do something // start a new thread or eq () -> { scope.activate(); try { /*...*/} finally { scope.deactivate(); } // }; It would: 1. let to the caller the thread safety responsability 2. use some kind of reference counting to not destroy the scope too early (before all deactivate are called) > Propose a way to propagate an existing context > ---------------------------------------------- > > Key: CDI-587 > URL: https://issues.jboss.org/browse/CDI-587 > Project: CDI Specification Issues > Issue Type: Epic > Components: Contexts > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. > An example is starting an AsyncContext in a servlet. > One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. > Note however this issue is not only bound to servlets even if it is the easiest example. > The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Life-Cycle-td5712701.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jul 18 09:44:01 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 18 Jul 2018 09:44:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607583#comment-13607583 ] Romain Manni-Bucau edited comment on CDI-587 at 7/18/18 9:43 AM: ----------------------------------------------------------------- Since CDI 2 we could have a simple solution reusing RequestContextController and adding a method to be able to manipulate the context: {code} RequestContextController scope = controller.handler(); // do something // start a new thread or eq () -> { scope.activate(); try { /*...*/} finally { scope.deactivate(); } // }; {code} It would: 1. let to the caller the thread safety responsability 2. use some kind of reference counting to not destroy the scope too early (before all deactivate are called) was (Author: rmannibucau): Since CDI 2 we could have a simple solution reusing RequestContextController and adding a method to be able to manipulate the context: {code} RequestContextController scope = controller.handler(); // do something // start a new thread or eq () -> { scope.activate(); try { /*...*/} finally { scope.deactivate(); } // }; It would: 1. let to the caller the thread safety responsability 2. use some kind of reference counting to not destroy the scope too early (before all deactivate are called) > Propose a way to propagate an existing context > ---------------------------------------------- > > Key: CDI-587 > URL: https://issues.jboss.org/browse/CDI-587 > Project: CDI Specification Issues > Issue Type: Epic > Components: Contexts > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. > An example is starting an AsyncContext in a servlet. > One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. > Note however this issue is not only bound to servlets even if it is the easiest example. > The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Life-Cycle-td5712701.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 23 02:33:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 23 Jul 2018 02:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13608915#comment-13608915 ] Matej Novotny commented on CDI-732: ----------------------------------- bq. conversation is clearly longer than request. Thus this argument makes no sense. Clearly not so much when it is transient, so it makes sense. The lifespan of a conversation can differ and there is no "perfect fit" for it. > Clarify that the Context for RequestScoped must be active during @PreDestroy calls > ---------------------------------------------------------------------------------- > > Key: CDI-732 > URL: https://issues.jboss.org/browse/CDI-732 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. > But it seems we don't force the same for invocations of @PreDestroy methods. > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From builds at travis-ci.org Mon Jul 23 04:43:25 2018 From: builds at travis-ci.org (Travis CI) Date: Mon, 23 Jul 2018 08:43:25 +0000 Subject: [cdi-dev] Passed: cdi-spec/cdi#382 (2.0.SP1 - 676366d) In-Reply-To: Message-ID: <5b55952d91f6f_43fc866a6f0a44694e@4fb31980-5aa4-42fb-b68f-b9c3d39b3296.mail> Build Update for cdi-spec/cdi ------------------------------------- Build: #382 Status: Passed Duration: 4 mins and 16 secs Commit: 676366d (2.0.SP1) Author: Antoine Sabot-Durand Message: Prepare for 2.0.SP1 release View the changeset: https://github.com/cdi-spec/cdi/commit/676366d034be View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/407042532?utm_source=email&utm_medium=notification -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications This email was sent to cdi-dev at lists.jboss.org (mailto:cdi-dev at lists.jboss.org) unsubscribe from this list (http://clicks.travis-ci.com/track/unsub.php?u=14313403&id=270ce5f7762849eb87505b988026b5ae.Hgmt0p37KclGv1nK8caMhISWHjk%3D&r=https%3A%2F%2Fmandrillapp.com%2Funsub%3Fmd_email%3Dcdi-dev%2540lists.jboss.org) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180723/23b01e8c/attachment-0001.html From issues at jboss.org Mon Jul 23 05:29:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 23 Jul 2018 05:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609050#comment-13609050 ] Romain Manni-Bucau commented on CDI-732: ---------------------------------------- [~manovotn] at the end it is exactly the same. You can see session scope or conversation scope as being dependent on the request so it must be destroyed before when they are destroyed during a request. > Clarify that the Context for RequestScoped must be active during @PreDestroy calls > ---------------------------------------------------------------------------------- > > Key: CDI-732 > URL: https://issues.jboss.org/browse/CDI-732 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. > But it seems we don't force the same for invocations of @PreDestroy methods. > That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request. -- This message was sent by Atlassian JIRA (v7.5.0#75005)