2:40 p.m.
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(a)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(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)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(a)gmail.com>
> Subject: Re: [cdi-dev] Portable decorable Bean<T> instances
> To: Matej Novotny <manovotn(a)redhat.com>
> Cc: cdi-dev(a)lists.jboss.org
> Message-ID:
> <CAE=-AhD9wr1B-pC8BfpY7RA3CwHDKPBd-nsejwZn4__0+mv3yw(a)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(a)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(a)gmail.com>
> > > To: cdi-dev(a)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(a)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.
> >
>