[cdi-dev] CDI security release around the corner
Mark Struberg
struberg at yahoo.de
Mon Aug 13 15:40:24 EDT 2018
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 <werner.keil at gmail.com>:
>
> 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 <cdi-dev-request at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at lists.jboss.org
>
> 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
> cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at lists.jboss.org
>
> 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 <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] Portable decorable Bean<T> instances
> To: Matej Novotny <manovotn at redhat.com>
> Cc: cdi-dev at lists.jboss.org
> Message-ID:
> <CAE=-AhD9wr1B-pC8BfpY7RA3CwHDKPBd-nsejwZn4__0+mv3yw at mail.gmail.com>
> 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 <manovotn at redhat.com> 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" <arjan.tijms at gmail.com>
> > > To: cdi-dev at lists.jboss.org
> > > 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
> > > 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-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 10 Jul 2018 14:46:23 +0200
> From: Martin Kouba <mkouba at redhat.com>
> Subject: Re: [cdi-dev] Portable decorable Bean<T> instances
> To: arjan tijms <arjan.tijms at gmail.com>, Matej Novotny
> <manovotn at redhat.com>
> Cc: cdi-dev at lists.jboss.org
> Message-ID: <229cfa79-b39b-af5b-bc75-757085270acf at redhat.com>
> 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 <manovotn at redhat.com
> > <mailto:manovotn at redhat.com>> 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" <arjan.tijms at gmail.com
> > <mailto:arjan.tijms at gmail.com>>
> > > To: cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> > > 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
> > > cdi-dev at lists.jboss.org <mailto: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
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 11 Jul 2018 10:10:54 +0200
> From: Antoine Sabot-Durand <asd at redhat.com>
> Subject: [cdi-dev] CDI security release around the corner
> To: CDI Java EE Specification <cdi-dev at lists.jboss.org>
> Message-ID:
> <CAHTnX=cPEQngop0ASYtu8ge6CLDx+38WcK3pi-z_VtYCOAa3eA at mail.gmail.com>
> 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)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for
> RequestScoped must be active during @PreDestroy calls
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12757897.1530531484000.672.1531724460377 at Atlassian.JIRA>
> 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)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for
> RequestScoped must be active during @PreDestroy calls
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12757897.1530531484000.702.1531724700312 at Atlassian.JIRA>
> 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)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-730) The order in which contexts
> are destroyed is undefined.
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12756107.1529484750000.1399.1531728660954 at Atlassian.JIRA>
> 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
> 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.
>
> End of cdi-dev Digest, Vol 89, Issue 2
> **************************************
> _______________________________________________
> 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.
More information about the cdi-dev
mailing list