<div dir="ltr">Antoine/all,<div><br></div><div>It seems, the security release is already out:</div><div><a href="https://search.maven.org/artifact/javax.enterprise/cdi-api/2.0.SP1/jar">https://search.maven.org/artifact/javax.enterprise/cdi-api/2.0.SP1/jar</a></div><div><br></div><div>Was there no structural change to the API so not calling it MR1 as none was filed or voted on according to JCP.org?</div><div><br></div><div>How does CDI plan to evolve? It is currently not under Jakarta EE, so do you plan to file a new JSR for CDI 2.1 (unless it is small enough to be a MR) or 3.0 via the JCP?</div><div><br></div><div>Regards,</div><div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0px;border-collapse:collapse"><font face="arial, helvetica, sans-serif" size="1"><span lang="EN-US">Werner </span></font></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 16, 2018 at 10:11 AM <<a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send cdi-dev mailing list submissions to<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cdi-dev-owner@lists.jboss.org" target="_blank">cdi-dev-owner@lists.jboss.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cdi-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Portable decorable Bean<T> instances (arjan tijms)<br>
2. Re: Portable decorable Bean<T> instances (Martin Kouba)<br>
3. CDI security release around the corner (Antoine Sabot-Durand)<br>
4. [JBoss JIRA] (CDI-732) Clarify that the Context for<br>
RequestScoped must be active during @PreDestroy calls<br>
(Mark Struberg (JIRA))<br>
5. [JBoss JIRA] (CDI-732) Clarify that the Context for<br>
RequestScoped must be active during @PreDestroy calls<br>
(Romain Manni-Bucau (JIRA))<br>
6. [JBoss JIRA] (CDI-730) The order in which contexts are<br>
destroyed is undefined. (Mark Struberg (JIRA))<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 10 Jul 2018 12:45:12 +0100<br>
From: arjan tijms <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>><br>
Subject: Re: [cdi-dev] Portable decorable Bean<T> instances<br>
To: Matej Novotny <<a href="mailto:manovotn@redhat.com" target="_blank">manovotn@redhat.com</a>><br>
Cc: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
Message-ID:<br>
<CAE=-<a href="mailto:AhD9wr1B-pC8BfpY7RA3CwHDKPBd-nsejwZn4__0%2Bmv3yw@mail.gmail.com" target="_blank">AhD9wr1B-pC8BfpY7RA3CwHDKPBd-nsejwZn4__0+mv3yw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
Thanks for the reply. I already feared that to be the answer.<br>
<br>
This would probably be a good enhancement request for CDI 2.1. At the very<br>
least the BeanConfigurator could have a method like<br>
BeanConfigurator#setDecorators<Decorator<?>... decorators. That's seemingly<br>
doable to implement by the CDI implementations.<br>
<br>
Kind regards,<br>
Arjan<br>
<br>
<br>
<br>
<br>
<br>
On Tue, Jul 10, 2018 at 11:04 AM Matej Novotny <<a href="mailto:manovotn@redhat.com" target="_blank">manovotn@redhat.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> yes, there is no portable way.<br>
> It is a similar situation as was with interceptors before<br>
> InterceptionFactory was added.<br>
><br>
> [impl 'details']<br>
> In principle, to implement this, you need to create a "wrapper class"<br>
> around the object which is to be intercepted/decorated.<br>
> If you provide a custom way to create the bean, it is very difficult to<br>
> create this wrapper on-the-fly.<br>
> Even the solution for interceptors has some shortcomings and flaws and<br>
> decorators seem even more complex (less restrictions on how does a<br>
> decorator look like).<br>
><br>
> Matej<br>
><br>
> ----- Original Message -----<br>
> > From: "arjan tijms" <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>><br>
> > To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
> > Sent: Tuesday, July 10, 2018 11:30:54 AM<br>
> > Subject: [cdi-dev] Portable decorable Bean<T> instances<br>
> ><br>
> > Hi,<br>
> ><br>
> > When adding a manually constructed Bean<T> instance using<br>
> > AfterBeanDiscovery.addBean(Bean<?>), or using the<br>
> > AfterBeanDiscovery.addBean() method and the BeanConfigurator, the<br>
> resulting<br>
> > bean can't be decorated.<br>
> ><br>
> > This is because seemingly CDI expects the create() method of Bean<T> to<br>
> > locate the decorators itself and apply them to the instance it returns.<br>
> ><br>
> > Using BeanManager.resolveDecorators one can obtain the Decorator<T><br>
> > instances, but am I right that there's no portable way to actually apply<br>
> > those decorators to the bean instance?<br>
> ><br>
> > Kind regards,<br>
> > Arjan<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > cdi-dev mailing list<br>
> > <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> ><br>
> > Note that for all code provided on this list, the provider licenses the<br>
> code<br>
> > under the Apache License, Version 2<br>
> > (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
> > provided on this list, the provider waives all patent and other<br>
> intellectual<br>
> > property rights inherent in such information.<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20180710/df6ec1f4/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20180710/df6ec1f4/attachment-0001.html</a> <br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 10 Jul 2018 14:46:23 +0200<br>
From: Martin Kouba <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>><br>
Subject: Re: [cdi-dev] Portable decorable Bean<T> instances<br>
To: arjan tijms <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>>, Matej Novotny<br>
<<a href="mailto:manovotn@redhat.com" target="_blank">manovotn@redhat.com</a>><br>
Cc: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
Message-ID: <<a href="mailto:229cfa79-b39b-af5b-bc75-757085270acf@redhat.com" target="_blank">229cfa79-b39b-af5b-bc75-757085270acf@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Dne 10.7.2018 v 13:45 arjan tijms napsal(a):<br>
> Hi,<br>
> <br>
> Thanks for the reply. I already feared that to be the answer.<br>
> <br>
> This would probably be a good enhancement request for CDI 2.1. At the <br>
> very least the BeanConfigurator could have a method like <br>
> BeanConfigurator#setDecorators<Decorator<?>... decorators. That's <br>
> seemingly doable to implement by the CDI implementations.<br>
<br>
Well, it's not that simple. In order to make decorators work the <br>
instance produced by Bean#create(CreationalContext<T>) must be proxied, <br>
decorated types only include interfaces, etc.<br>
<br>
There are few issues related to this topic. I'd suggest to walk through <br>
all those issues, close duplicates and outdated issues and create a new <br>
one with distilled summary...<br>
<br>
> <br>
> Kind regards,<br>
> Arjan<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On Tue, Jul 10, 2018 at 11:04 AM Matej Novotny <<a href="mailto:manovotn@redhat.com" target="_blank">manovotn@redhat.com</a> <br>
> <mailto:<a href="mailto:manovotn@redhat.com" target="_blank">manovotn@redhat.com</a>>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> yes, there is no portable way.<br>
> It is a similar situation as was with interceptors before<br>
> InterceptionFactory was added.<br>
> <br>
> [impl 'details']<br>
> In principle, to implement this, you need to create a "wrapper<br>
> class" around the object which is to be intercepted/decorated.<br>
> If you provide a custom way to create the bean, it is very difficult<br>
> to create this wrapper on-the-fly.<br>
> Even the solution for interceptors has some shortcomings and flaws<br>
> and decorators seem even more complex (less restrictions on how does<br>
> a decorator look like).<br>
> <br>
> Matej<br>
> <br>
> ----- Original Message -----<br>
> > From: "arjan tijms" <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a><br>
> <mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>>><br>
> > To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
> > Sent: Tuesday, July 10, 2018 11:30:54 AM<br>
> > Subject: [cdi-dev] Portable decorable Bean<T> instances<br>
> ><br>
> > Hi,<br>
> ><br>
> > When adding a manually constructed Bean<T> instance using<br>
> > AfterBeanDiscovery.addBean(Bean<?>), or using the<br>
> > AfterBeanDiscovery.addBean() method and the BeanConfigurator, the<br>
> resulting<br>
> > bean can't be decorated.<br>
> ><br>
> > This is because seemingly CDI expects the create() method of<br>
> Bean<T> to<br>
> > locate the decorators itself and apply them to the instance it<br>
> returns.<br>
> ><br>
> > Using BeanManager.resolveDecorators one can obtain the Decorator<T><br>
> > instances, but am I right that there's no portable way to<br>
> actually apply<br>
> > those decorators to the bean instance?<br>
> ><br>
> > Kind regards,<br>
> > Arjan<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > cdi-dev mailing list<br>
> > <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> ><br>
> > Note that for all code provided on this list, the provider<br>
> licenses the code<br>
> > under the Apache License, Version 2<br>
> > (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
> ideas<br>
> > provided on this list, the provider waives all patent and other<br>
> intellectual<br>
> > property rights inherent in such information.<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> <br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
> <br>
<br>
-- <br>
Martin Kouba<br>
Senior Software Engineer<br>
Red Hat, Czech Republic<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 11 Jul 2018 10:10:54 +0200<br>
From: Antoine Sabot-Durand <<a href="mailto:asd@redhat.com" target="_blank">asd@redhat.com</a>><br>
Subject: [cdi-dev] CDI security release around the corner<br>
To: CDI Java EE Specification <<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAHTnX=<a href="mailto:cPEQngop0ASYtu8ge6CLDx%2B38WcK3pi-z_VtYCOAa3eA@mail.gmail.com" target="_blank">cPEQngop0ASYtu8ge6CLDx+38WcK3pi-z_VtYCOAa3eA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi all,<br>
<br>
As stated a few weeks ago we have worked on issues in CDI API regarding<br>
security manager.<br>
<br>
2 PR are currently open [1] [2]. The first one is ready to merge, second<br>
one need some discussion and possible rework.<br>
<br>
If none of you raise concern about these, I plan to merge these PR and<br>
release CDI 2.0.SP1 by the end of next week.<br>
<br>
Thanks for your feedback,<br>
<br>
Antoine<br>
<br>
<br>
[1] <a href="https://github.com/cdi-spec/cdi/pull/390" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/390</a><br>
[2] <a href="https://github.com/cdi-spec/cdi/pull/391" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/391</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20180711/217bf5ab/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20180711/217bf5ab/attachment-0001.html</a> <br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 16 Jul 2018 03:01:00 -0400 (EDT)<br>
From: "Mark Struberg (JIRA)" <<a href="mailto:issues@jboss.org" target="_blank">issues@jboss.org</a>><br>
Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for<br>
RequestScoped must be active during @PreDestroy calls<br>
To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
Message-ID:<br>
<JIRA.12757897.1530531484000.672.1531724460377@Atlassian.JIRA><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
<br>
[ <a href="https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605259#comment-13605259" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605259#comment-13605259</a> ] <br>
<br>
Mark Struberg commented on CDI-732:<br>
-----------------------------------<br>
<br>
> It seems logical to first destroy the "shorter-lived" scopes<br>
<br>
Hmm but Welds destroy order according to CDI-730 is<br>
> At present weld destroys conversation, request, then session context in that order.<br>
conversation is clearly longer than request. Thus this argument makes no sense. <br>
<br>
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. <br>
<br>
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. <br>
<br>
> Clarify that the Context for RequestScoped must be active during @PreDestroy calls<br>
> ----------------------------------------------------------------------------------<br>
><br>
> Key: CDI-732<br>
> URL: <a href="https://issues.jboss.org/browse/CDI-732" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-732</a><br>
> Project: CDI Specification Issues<br>
> Issue Type: Feature Request<br>
> Components: Contexts<br>
> Affects Versions: 2.0 .Final<br>
> Reporter: Mark Struberg<br>
><br>
> We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. <br>
> But it seems we don't force the same for invocations of @PreDestroy methods.<br>
> 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.<br>
<br>
<br>
<br>
--<br>
This message was sent by Atlassian JIRA<br>
(v7.5.0#75005)<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Mon, 16 Jul 2018 03:05:00 -0400 (EDT)<br>
From: "Romain Manni-Bucau (JIRA)" <<a href="mailto:issues@jboss.org" target="_blank">issues@jboss.org</a>><br>
Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for<br>
RequestScoped must be active during @PreDestroy calls<br>
To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
Message-ID:<br>
<JIRA.12757897.1530531484000.702.1531724700312@Atlassian.JIRA><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
<br>
[ <a href="https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605260#comment-13605260" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605260#comment-13605260</a> ] <br>
<br>
Romain Manni-Bucau commented on CDI-732:<br>
----------------------------------------<br>
<br>
[~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).<br>
<br>
> Clarify that the Context for RequestScoped must be active during @PreDestroy calls<br>
> ----------------------------------------------------------------------------------<br>
><br>
> Key: CDI-732<br>
> URL: <a href="https://issues.jboss.org/browse/CDI-732" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-732</a><br>
> Project: CDI Specification Issues<br>
> Issue Type: Feature Request<br>
> Components: Contexts<br>
> Affects Versions: 2.0 .Final<br>
> Reporter: Mark Struberg<br>
><br>
> We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. <br>
> But it seems we don't force the same for invocations of @PreDestroy methods.<br>
> 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.<br>
<br>
<br>
<br>
--<br>
This message was sent by Atlassian JIRA<br>
(v7.5.0#75005)<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Mon, 16 Jul 2018 04:11:00 -0400 (EDT)<br>
From: "Mark Struberg (JIRA)" <<a href="mailto:issues@jboss.org" target="_blank">issues@jboss.org</a>><br>
Subject: [cdi-dev] [JBoss JIRA] (CDI-730) The order in which contexts<br>
are destroyed is undefined.<br>
To: <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
Message-ID:<br>
<JIRA.12756107.1529484750000.1399.1531728660954@Atlassian.JIRA><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
<br>
[ <a href="https://issues.jboss.org/browse/CDI-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605310#comment-13605310" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605310#comment-13605310</a> ] <br>
<br>
Mark Struberg commented on CDI-730:<br>
-----------------------------------<br>
<br>
I understand the argument that the order is really hard to get right.<br>
But I would love if we could clarify the following:<br>
<br>
* When a request ends, first ALL the @BeforeDestroyed events for the following contexts are sent: RequestScope, ConversationScoped (if context ends), SessionScoped (if session ends)<br>
* Only after that the proper @PreDestroy methods are called on all those scopes.<br>
<br>
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 :(<br>
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.<br>
<br>
> The order in which contexts are destroyed is undefined.<br>
> -------------------------------------------------------<br>
><br>
> Key: CDI-730<br>
> URL: <a href="https://issues.jboss.org/browse/CDI-730" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-730</a><br>
> Project: CDI Specification Issues<br>
> Issue Type: Clarification<br>
> Affects Versions: 2.Future, 1.2.Final, 2.0 .Final<br>
> Reporter: Benjamin Confino<br>
> Priority: Minor<br>
><br>
> The order in which contexts are destroyed is not defined in the spec, I believe this should be made explicit.<br>
> At present weld destroys conversation, request, then session context in that order. I think this should become the standard and written into the spec.<br>
> For background there is this email by Martin Kouba: <a href="http://lists.jboss.org/pipermail/weld-dev/2018-June/003694.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/weld-dev/2018-June/003694.html</a><br>
<br>
<br>
<br>
--<br>
This message was sent by Atlassian JIRA<br>
(v7.5.0#75005)<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
End of cdi-dev Digest, Vol 89, Issue 2<br>
**************************************<br>
</blockquote></div></div></div>