Re: CDI security release around the corner

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: CDI security release around the corner

Werner Keil-2
Antoine/all,

It seems, the security release is already out:

Was there no structural change to the API so not calling it MR1 as none was filed or voted on according to JCP.org?

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?

Regards,

Werner 


On Mon, Jul 16, 2018 at 10:11 AM <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Portable decorable Bean<T> instances (arjan tijms)
   2. Re: Portable decorable Bean<T> instances (Martin Kouba)
   3. CDI security release around the corner (Antoine Sabot-Durand)
   4. [JBoss JIRA] (CDI-732) Clarify that the Context for
      RequestScoped must be active during @PreDestroy calls
      (Mark Struberg (JIRA))
   5. [JBoss JIRA] (CDI-732) Clarify that the Context for
      RequestScoped must be active during @PreDestroy calls
      (Romain Manni-Bucau (JIRA))
   6. [JBoss JIRA] (CDI-730) The order in which contexts are
      destroyed is undefined. (Mark Struberg (JIRA))


----------------------------------------------------------------------

Message: 1
Date: Tue, 10 Jul 2018 12:45:12 +0100
From: arjan tijms <[hidden email]>
Subject: Re: [cdi-dev] Portable decorable Bean<T> instances
To: Matej Novotny <[hidden email]>
Cc: [hidden email]
Message-ID:
        <CAE=-[hidden email]>
Content-Type: text/plain; charset="utf-8"

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<Decorator<?>... 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 <[hidden email]> 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" <[hidden email]>
> > To: [hidden email]
> > Sent: Tuesday, July 10, 2018 11:30:54 AM
> > Subject: [cdi-dev] Portable decorable Bean<T> instances
> >
> > Hi,
> >
> > When adding a manually constructed Bean<T> 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<T> to
> > locate the decorators itself and apply them to the instance it returns.
> >
> > Using BeanManager.resolveDecorators one can obtain the Decorator<T>
> > 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
> > [hidden email]
> > 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-0001.html

------------------------------

Message: 2
Date: Tue, 10 Jul 2018 14:46:23 +0200
From: Martin Kouba <[hidden email]>
Subject: Re: [cdi-dev] Portable decorable Bean<T> instances
To: arjan tijms <[hidden email]>, Matej Novotny
        <[hidden email]>
Cc: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

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<Decorator<?>... 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<T>) 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 <[hidden email]
> <mailto:[hidden email]>> 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" <[hidden email]
>     <mailto:[hidden email]>>
>      > To: [hidden email] <mailto:[hidden email]>
>      > Sent: Tuesday, July 10, 2018 11:30:54 AM
>      > Subject: [cdi-dev] Portable decorable Bean<T> instances
>      >
>      > Hi,
>      >
>      > When adding a manually constructed Bean<T> 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<T> to
>      > locate the decorators itself and apply them to the instance it
>     returns.
>      >
>      > Using BeanManager.resolveDecorators one can obtain the Decorator<T>
>      > 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
>      > [hidden email] <mailto:[hidden email]>
>      > 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
> [hidden email]
> 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


------------------------------

Message: 3
Date: Wed, 11 Jul 2018 10:10:54 +0200
From: Antoine Sabot-Durand <[hidden email]>
Subject: [cdi-dev] CDI security release around the corner
To: CDI Java EE Specification <[hidden email]>
Message-ID:
        <CAHTnX=[hidden email]>
Content-Type: text/plain; charset="utf-8"

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-0001.html

------------------------------

Message: 4
Date: Mon, 16 Jul 2018 03:01:00 -0400 (EDT)
From: "Mark Struberg (JIRA)" <[hidden email]>
Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for
        RequestScoped must be active during @PreDestroy calls
To: [hidden email]
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset=UTF-8


    [ 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)


------------------------------

Message: 5
Date: Mon, 16 Jul 2018 03:05:00 -0400 (EDT)
From: "Romain Manni-Bucau (JIRA)" <[hidden email]>
Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for
        RequestScoped must be active during @PreDestroy calls
To: [hidden email]
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset=UTF-8


    [ 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)


------------------------------

Message: 6
Date: Mon, 16 Jul 2018 04:11:00 -0400 (EDT)
From: "Mark Struberg (JIRA)" <[hidden email]>
Subject: [cdi-dev] [JBoss JIRA] (CDI-730) The order in which contexts
        are destroyed is undefined.
To: [hidden email]
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset=UTF-8


    [ 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)


------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
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.

End of cdi-dev Digest, Vol 89, Issue 2
**************************************

_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: CDI security release around the corner

Mark Struberg
Right, no API signature got changed etc.
The only change was doing some parts in a doPrivileged block.
It's really just a security bugfix release.

It's imo perfectly fine since the API is usually provided by the container and user projects only have it as <scope>provided</scope> in their projects.
So it's really mostly important for container vendors.

LieGrue,
strub


> Am 10.08.2018 um 18:22 schrieb Werner Keil <[hidden email]>:
>
> Antoine/all,
>
> It seems, the security release is already out:
> https://search.maven.org/artifact/javax.enterprise/cdi-api/2.0.SP1/jar
>
> Was there no structural change to the API so not calling it MR1 as none was filed or voted on according to JCP.org?
>
> 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?
>
> Regards,
> Werner
>
> On Mon, Jul 16, 2018 at 10:11 AM <[hidden email]> wrote:
> Send cdi-dev mailing list submissions to
>         [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         [hidden email]
>
> You can reach the person managing the list at
>         [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Portable decorable Bean<T> instances (arjan tijms)
>    2. Re: Portable decorable Bean<T> instances (Martin Kouba)
>    3. CDI security release around the corner (Antoine Sabot-Durand)
>    4. [JBoss JIRA] (CDI-732) Clarify that the Context for
>       RequestScoped must be active during @PreDestroy calls
>       (Mark Struberg (JIRA))
>    5. [JBoss JIRA] (CDI-732) Clarify that the Context for
>       RequestScoped must be active during @PreDestroy calls
>       (Romain Manni-Bucau (JIRA))
>    6. [JBoss JIRA] (CDI-730) The order in which contexts are
>       destroyed is undefined. (Mark Struberg (JIRA))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 10 Jul 2018 12:45:12 +0100
> From: arjan tijms <[hidden email]>
> Subject: Re: [cdi-dev] Portable decorable Bean<T> instances
> To: Matej Novotny <[hidden email]>
> Cc: [hidden email]
> Message-ID:
>         <CAE=-[hidden email]>
> Content-Type: text/plain; charset="utf-8"
>
> 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<Decorator<?>... 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 <[hidden email]> 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" <[hidden email]>
> > > To: [hidden email]
> > > Sent: Tuesday, July 10, 2018 11:30:54 AM
> > > Subject: [cdi-dev] Portable decorable Bean<T> instances
> > >
> > > Hi,
> > >
> > > When adding a manually constructed Bean<T> 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<T> to
> > > locate the decorators itself and apply them to the instance it returns.
> > >
> > > Using BeanManager.resolveDecorators one can obtain the Decorator<T>
> > > 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
> > > [hidden email]
> > > 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-0001.html 
>
> ------------------------------
>
> Message: 2
> Date: Tue, 10 Jul 2018 14:46:23 +0200
> From: Martin Kouba <[hidden email]>
> Subject: Re: [cdi-dev] Portable decorable Bean<T> instances
> To: arjan tijms <[hidden email]>, Matej Novotny
>         <[hidden email]>
> Cc: [hidden email]
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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<Decorator<?>... 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<T>) 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 <[hidden email]
> > <mailto:[hidden email]>> 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" <[hidden email]
> >     <mailto:[hidden email]>>
> >      > To: [hidden email] <mailto:[hidden email]>
> >      > Sent: Tuesday, July 10, 2018 11:30:54 AM
> >      > Subject: [cdi-dev] Portable decorable Bean<T> instances
> >      >
> >      > Hi,
> >      >
> >      > When adding a manually constructed Bean<T> 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<T> to
> >      > locate the decorators itself and apply them to the instance it
> >     returns.
> >      >
> >      > Using BeanManager.resolveDecorators one can obtain the Decorator<T>
> >      > 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
> >      > [hidden email] <mailto:[hidden email]>
> >      > 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
> > [hidden email]
> > 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
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 11 Jul 2018 10:10:54 +0200
> From: Antoine Sabot-Durand <[hidden email]>
> Subject: [cdi-dev] CDI security release around the corner
> To: CDI Java EE Specification <[hidden email]>
> Message-ID:
>         <CAHTnX=[hidden email]>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.html 
>
> ------------------------------
>
> Message: 4
> Date: Mon, 16 Jul 2018 03:01:00 -0400 (EDT)
> From: "Mark Struberg (JIRA)" <[hidden email]>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for
>         RequestScoped must be active during @PreDestroy calls
> To: [hidden email]
> Message-ID:
>         <[hidden email]>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [ 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)
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 16 Jul 2018 03:05:00 -0400 (EDT)
> From: "Romain Manni-Bucau (JIRA)" <[hidden email]>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for
>         RequestScoped must be active during @PreDestroy calls
> To: [hidden email]
> Message-ID:
>         <[hidden email]>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [ 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)
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 16 Jul 2018 04:11:00 -0400 (EDT)
> From: "Mark Struberg (JIRA)" <[hidden email]>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-730) The order in which contexts
>         are destroyed is undefined.
> To: [hidden email]
> Message-ID:
>         <[hidden email]>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [ 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)
>
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> 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.
>
> End of cdi-dev Digest, Vol 89, Issue 2
> **************************************
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> 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
[hidden email]
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.