From werner.keil at gmail.com  Fri Aug 10 12:22:51 2018
From: werner.keil at gmail.com (Werner Keil)
Date: Fri, 10 Aug 2018 18:22:51 +0200
Subject: [cdi-dev] CDI security release around the corner
In-Reply-To: <mailman.1825.1531728661.4671.cdi-dev@lists.jboss.org>
References: <mailman.1825.1531728661.4671.cdi-dev@lists.jboss.org>
Message-ID: <CAAGawe3fY5hz0Mt00d9i5eqb59KzDKAPreZOpbwYfCOvPVaAdw@mail.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
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180810/9b81db51/attachment-0001.html 

From struberg at yahoo.de  Mon Aug 13 15:40:24 2018
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 13 Aug 2018 21:40:24 +0200
Subject: [cdi-dev] CDI security release around the corner
In-Reply-To: <CAAGawe3fY5hz0Mt00d9i5eqb59KzDKAPreZOpbwYfCOvPVaAdw@mail.gmail.com>
References: <mailman.1825.1531728661.4671.cdi-dev@lists.jboss.org>
	<CAAGawe3fY5hz0Mt00d9i5eqb59KzDKAPreZOpbwYfCOvPVaAdw@mail.gmail.com>
Message-ID: <D0E32E16-9E03-4A1A-9E5F-072B31AD227C@yahoo.de>

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.



From issues at jboss.org  Tue Aug 14 10:48:00 2018
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Tue, 14 Aug 2018 10:48:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-733)
 javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
In-Reply-To: <JIRA.12764748.1534258029000@Atlassian.JIRA>
References: <JIRA.12764748.1534258029000@Atlassian.JIRA>
	<JIRA.12764748.1534258029150@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12764748.1534258029000.41543.1534258080124@Atlassian.JIRA>

Romain Manni-Bucau created CDI-733:
--------------------------------------

             Summary: javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
                 Key: CDI-733
                 URL: https://issues.jboss.org/browse/CDI-733
             Project: CDI Specification Issues
          Issue Type: Feature Request
            Reporter: Romain Manni-Bucau
            Priority: Minor


Goal is to enable a bit more meta programming and in particular instantiation of custom parameterized type of events, currently it requires to go through the bean manager whereas the event would be a natural place to resolve an event.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Aug 15 01:28:00 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 15 Aug 2018 01:28:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-733)
 javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
In-Reply-To: <JIRA.12764748.1534258029000@Atlassian.JIRA>
References: <JIRA.12764748.1534258029000@Atlassian.JIRA>
	<JIRA.12764748.1534258029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12764748.1534258029000.44627.1534310880077@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619198#comment-13619198 ] 

Martin Kouba commented on CDI-733:
----------------------------------

It should use both. The problem with {{java.lang.reflect.Type}} param is type safety which cannot be guaranteed. FYI Weld API already allows to use {{Type}} parameter for {{Event<Object>}}: https://github.com/weld/api/blob/3.0.SP4/weld/src/main/java/org/jboss/weld/events/WeldEvent.java#L32-L47

> javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
> ---------------------------------------------------------------------
>
>                 Key: CDI-733
>                 URL: https://issues.jboss.org/browse/CDI-733
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>            Priority: Minor
>
> Goal is to enable a bit more meta programming and in particular instantiation of custom parameterized type of events, currently it requires to go through the bean manager whereas the event would be a natural place to resolve an event.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Aug 15 11:00:00 2018
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 15 Aug 2018 11:00:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-733)
 javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
In-Reply-To: <JIRA.12764748.1534258029000@Atlassian.JIRA>
References: <JIRA.12764748.1534258029000@Atlassian.JIRA>
	<JIRA.12764748.1534258029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12764748.1534258029000.48182.1534345200542@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619511#comment-13619511 ] 

Romain Manni-Bucau commented on CDI-733:
----------------------------------------

Right, on OWB side it is 1mn max to add it so let's add it in the spec?

> javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
> ---------------------------------------------------------------------
>
>                 Key: CDI-733
>                 URL: https://issues.jboss.org/browse/CDI-733
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>            Priority: Minor
>
> Goal is to enable a bit more meta programming and in particular instantiation of custom parameterized type of events, currently it requires to go through the bean manager whereas the event would be a natural place to resolve an event.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Aug 16 04:08:00 2018
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Thu, 16 Aug 2018 04:08:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-733)
 javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
In-Reply-To: <JIRA.12764748.1534258029000@Atlassian.JIRA>
References: <JIRA.12764748.1534258029000@Atlassian.JIRA>
	<JIRA.12764748.1534258029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12764748.1534258029000.51440.1534406880222@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619827#comment-13619827 ] 

Romain Manni-Bucau commented on CDI-733:
----------------------------------------

BTW, just realized the same applies to Instance

> javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
> ---------------------------------------------------------------------
>
>                 Key: CDI-733
>                 URL: https://issues.jboss.org/browse/CDI-733
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>            Priority: Minor
>
> Goal is to enable a bit more meta programming and in particular instantiation of custom parameterized type of events, currently it requires to go through the bean manager whereas the event would be a natural place to resolve an event.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Aug 17 03:59:00 2018
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Fri, 17 Aug 2018 03:59:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for
 beans.xml alternative check introduced in 1.2
In-Reply-To: <JIRA.12649238.1473322251000@Atlassian.JIRA>
References: <JIRA.12649238.1473322251000@Atlassian.JIRA>
	<JIRA.12649238.1473322251000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649238.1473322251000.58244.1534492740483@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620412#comment-13620412 ] 

Mark Struberg commented on CDI-627:
-----------------------------------

This bug actually blow up in our face in many projects! 
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.

Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.

We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!

So I see absolutely no reason why Weld refuses to fix this broken behaviour!

> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
>                 Key: CDI-627
>                 URL: https://issues.jboss.org/browse/CDI-627
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Concepts
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
>   <alternatives>
>     <class>org.acme.MockMailService</class>
>   </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Aug 17 04:01:01 2018
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Fri, 17 Aug 2018 04:01:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for
 beans.xml alternative check introduced in 1.2
In-Reply-To: <JIRA.12649238.1473322251000@Atlassian.JIRA>
References: <JIRA.12649238.1473322251000@Atlassian.JIRA>
	<JIRA.12649238.1473322251000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649238.1473322251000.58270.1534492861303@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620412#comment-13620412 ] 

Mark Struberg edited comment on CDI-627 at 8/17/18 4:00 AM:
------------------------------------------------------------

This bug actually blow up in our face in many projects! 
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.

Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.

We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!

So I see absolutely no reason why Weld refuses to fix this broken behaviour!

*Edit*: It works perfectly fine in ALL Weld-1 and Weld-3 versions. And as far as I remember it even worked perfectly fine in earlier Weld-2 versions. It just got broken in younger Weld2 versions.


was (Author: struberg):
This bug actually blow up in our face in many projects! 
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.

Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.

We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!

So I see absolutely no reason why Weld refuses to fix this broken behaviour!

> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
>                 Key: CDI-627
>                 URL: https://issues.jboss.org/browse/CDI-627
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Concepts
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
>   <alternatives>
>     <class>org.acme.MockMailService</class>
>   </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Aug 17 04:16:01 2018
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Fri, 17 Aug 2018 04:16:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for
 beans.xml alternative check introduced in 1.2
In-Reply-To: <JIRA.12649238.1473322251000@Atlassian.JIRA>
References: <JIRA.12649238.1473322251000@Atlassian.JIRA>
	<JIRA.12649238.1473322251000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649238.1473322251000.58354.1534493761683@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620412#comment-13620412 ] 

Mark Struberg edited comment on CDI-627 at 8/17/18 4:15 AM:
------------------------------------------------------------

This bug actually blow up in our face in many projects! 
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.

Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.

We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!

So I see absolutely no reason why Weld refuses to fix this broken behaviour!

*Edit*: It works perfectly fine in ALL Weld-1 and Weld-3 versions. And as far as I remember it even worked perfectly fine in earlier Weld-2 versions. It just got broken in younger Weld2 versions.
*Edit2*: can we probably move all this discussion to a Weld2 ticket? The CDI spec part is imo fine now.


was (Author: struberg):
This bug actually blow up in our face in many projects! 
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.

Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.

We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!

So I see absolutely no reason why Weld refuses to fix this broken behaviour!

*Edit*: It works perfectly fine in ALL Weld-1 and Weld-3 versions. And as far as I remember it even worked perfectly fine in earlier Weld-2 versions. It just got broken in younger Weld2 versions.

> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
>                 Key: CDI-627
>                 URL: https://issues.jboss.org/browse/CDI-627
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Concepts
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
>   <alternatives>
>     <class>org.acme.MockMailService</class>
>   </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Aug 20 05:46:01 2018
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Mon, 20 Aug 2018 05:46:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for
 beans.xml alternative check introduced in 1.2
In-Reply-To: <JIRA.12649238.1473322251000@Atlassian.JIRA>
References: <JIRA.12649238.1473322251000@Atlassian.JIRA>
	<JIRA.12649238.1473322251000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649238.1473322251000.1894.1534758361477@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13621312#comment-13621312 ] 

Matej Novotny commented on CDI-627:
-----------------------------------

I see no reason to move this discussion anywhere - this ticket is solved and deals with CDI 2.0.
Not that there was any _discussion_ anyway, last comment was 17th Nov 2016 until recently.

bq. The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.

That's a bold statement; I wonder if it is the only such change we would find there.
Anyhow, it is a bit late to discuss what should or should not have been in CDI 1.2 as that is no longer developed.
Now we just have to move onwards and drag the legacy behind us :-)

> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
>                 Key: CDI-627
>                 URL: https://issues.jboss.org/browse/CDI-627
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Concepts
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
>   <alternatives>
>     <class>org.acme.MockMailService</class>
>   </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Aug 20 05:59:00 2018
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Mon, 20 Aug 2018 05:59:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-733)
 javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
In-Reply-To: <JIRA.12764748.1534258029000@Atlassian.JIRA>
References: <JIRA.12764748.1534258029000@Atlassian.JIRA>
	<JIRA.12764748.1534258029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12764748.1534258029000.1956.1534759140312@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13621320#comment-13621320 ] 

Matej Novotny commented on CDI-733:
-----------------------------------

Just for completeness, Weld also has {{Type}} based select on {{Instance}} - https://github.com/weld/api/blob/3.0.SP4/weld/src/main/java/org/jboss/weld/inject/WeldInstance.java#L119-L134

If we want to add this to the spec, please mind the type safety hazard, in Weld we added [this line|https://github.com/weld/api/blob/3.0.SP4/weld/src/main/java/org/jboss/weld/inject/WeldInstance.java#L122] to ensure that things won't blow up (well, at least not as violently). Invoking type-based select on anything else then {{Object}} will possibly result in an error.

> javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
> ---------------------------------------------------------------------
>
>                 Key: CDI-733
>                 URL: https://issues.jboss.org/browse/CDI-733
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>            Priority: Minor
>
> Goal is to enable a bit more meta programming and in particular instantiation of custom parameterized type of events, currently it requires to go through the bean manager whereas the event would be a natural place to resolve an event.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Aug 20 08:21:00 2018
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 20 Aug 2018 08:21:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-733)
 javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
In-Reply-To: <JIRA.12764748.1534258029000@Atlassian.JIRA>
References: <JIRA.12764748.1534258029000@Atlassian.JIRA>
	<JIRA.12764748.1534258029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12764748.1534258029000.3332.1534767660474@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13621447#comment-13621447 ] 

Romain Manni-Bucau commented on CDI-733:
----------------------------------------

There is an alternative: make the Type of TypeVariable provided in the constructor instead of extracting it. This would break the type safety in TypeVariable construction (but when intended) but nowhere else.

> javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
> ---------------------------------------------------------------------
>
>                 Key: CDI-733
>                 URL: https://issues.jboss.org/browse/CDI-733
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>            Priority: Minor
>
> Goal is to enable a bit more meta programming and in particular instantiation of custom parameterized type of events, currently it requires to go through the bean manager whereas the event would be a natural place to resolve an event.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Aug 24 04:48:00 2018
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Fri, 24 Aug 2018 04:48:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-591) Easy way to get an interceptor
	model
In-Reply-To: <JIRA.12611460.1458641930000@Atlassian.JIRA>
References: <JIRA.12611460.1458641930000@Atlassian.JIRA>
	<JIRA.12611460.1458641930000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611460.1458641930000.31706.1535100480784@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13623674#comment-13623674 ] 

Mark Struberg commented on CDI-591:
-----------------------------------

Up!

We had the following report from Arjan and he pointed out that Weld since introduced a non-portable way to do exactly that.
https://issues.apache.org/jira/browse/OWB-1217

So why not finally make it an official part of the API?

Could think about extending the InvocationContext. Not sure how we could do this as part of the Interceptors spec as it doesn't know about AnnotatedTypes at all. We could either subclass it to a CdiInvocationContext. Or define a standard parameter in the Map. E.g. 'jcdi.intercepted.AnnotatedMethod'. It should not only contain the InterceptorBindings but the whole AnnotatedMethod. Often you need other Annotations than just the InterceptorBinding.

> Easy way to get an interceptor model
> ------------------------------------
>
>                 Key: CDI-591
>                 URL: https://issues.jboss.org/browse/CDI-591
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Romain Manni-Bucau
>
> Since CDI 1.1 we can get the intercepted Bean<?> but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior.
> {code}
> @Inject
> @Intercepted
> AnnotatedType<?> type;
> @Inject
> @Intercepted
> AnnotatedMethod<?> method;
> {code}
> would be great
> Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Aug 24 04:50:00 2018
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Fri, 24 Aug 2018 04:50:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-591) Easy way to get an interceptor
	model
In-Reply-To: <JIRA.12611460.1458641930000@Atlassian.JIRA>
References: <JIRA.12611460.1458641930000@Atlassian.JIRA>
	<JIRA.12611460.1458641930000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611460.1458641930000.31739.1535100600313@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13623674#comment-13623674 ] 

Mark Struberg edited comment on CDI-591 at 8/24/18 4:49 AM:
------------------------------------------------------------

Up!

We had the following report from Arjan and he pointed out that Weld since introduced a non-portable way to do exactly that.
https://issues.apache.org/jira/browse/OWB-1217

So why not finally make it an official part of the API?

Could think about extending the InvocationContext. Not sure how we could do this as part of the Interceptors spec as it doesn't know about AnnotatedTypes at all. We could either subclass it to a CdiInvocationContext. Or define a standard parameter in the Map. E.g. 'jcdi.intercepted.Annotated'. It should not only contain the InterceptorBindings but the whole AnnotatedMethod or AnnotatedConstructor. Often you need other Annotations than just the InterceptorBinding.


was (Author: struberg):
Up!

We had the following report from Arjan and he pointed out that Weld since introduced a non-portable way to do exactly that.
https://issues.apache.org/jira/browse/OWB-1217

So why not finally make it an official part of the API?

Could think about extending the InvocationContext. Not sure how we could do this as part of the Interceptors spec as it doesn't know about AnnotatedTypes at all. We could either subclass it to a CdiInvocationContext. Or define a standard parameter in the Map. E.g. 'jcdi.intercepted.AnnotatedMethod'. It should not only contain the InterceptorBindings but the whole AnnotatedMethod. Often you need other Annotations than just the InterceptorBinding.

> Easy way to get an interceptor model
> ------------------------------------
>
>                 Key: CDI-591
>                 URL: https://issues.jboss.org/browse/CDI-591
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Romain Manni-Bucau
>
> Since CDI 1.1 we can get the intercepted Bean<?> but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior.
> {code}
> @Inject
> @Intercepted
> AnnotatedType<?> type;
> @Inject
> @Intercepted
> AnnotatedMethod<?> method;
> {code}
> would be great
> Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From EMIJIANG at uk.ibm.com  Fri Aug 24 17:08:04 2018
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Fri, 24 Aug 2018 22:08:04 +0100
Subject: [cdi-dev] [weld-dev] Question about the spec for
	BeanManager.getBeans
In-Reply-To: <1633794470.6460896.1535123819032.JavaMail.zimbra@redhat.com>
References: <OF17C82206.DF8D7992-ON002582F3.0047FB80-802582F3.004855C9@notes.na.collabserv.com>
	<1633794470.6460896.1535123819032.JavaMail.zimbra@redhat.com>
Message-ID: <OF202BDDBB.C91F8AD9-ON002582F3.00732C4C-802582F3.0074183A@notes.na.collabserv.com>

Matej,

Thanks for your quick reply!
I think the spec is quite clear by saying the candidates of typesafe 
resolutions defined in Performing typesafe resolutions... surely a 
disabled bean cannot be a candidate. it is simply disquailified. 

It did not say eliminate all beans but one though. I think it should be 
eliminate disqualified ones and leave all qualified at least. 

I am sending to cdi-dev for clarification. Antoine, please comment.

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, Liberty Architect for MicroProfile and CDI
 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: emijiang at uk.ibm.com 
Lotus Notes: Emily Jiang/UK/IBM at IBMGB




From:   Matej Novotny <manovotn at redhat.com>
To:     Benjamin Confino <BENJAMIC at uk.ibm.com>
Cc:     weld-dev at lists.jboss.org, Emily Jiang <EMIJIANG at uk.ibm.com>
Date:   24/08/2018 16:17
Subject:        Re: [weld-dev] Question about the spec for 
BeanManager.getBeans



Hi

Looking at spec 11.3.6. Obtaining a Bean by type[1] I can see that the 
paragraph ends with "according to the rules for candidates of typesafe 
resolution defined in Performing typesafe resolution.".
The important word here is *candidates* IMO. 
The way typesafe resolution is defined, both the original bean and the 
alternatives are candidates. According to spec, the original bean is still 
considered enabled[2]
Note that CDI spec doesn't say that @Alternative would completely 
eliminate the original bean, it just takes precedence during resolution 
(as opposed to what specialization does[3]).

Last but not least, one thought - if the getBeans() method was to perform 
a typesafe resolution and eliminate all but one bean - why would it return 
a Set (and not throw unsatisfied/ambiguous exceptions)? :)

Matej
______________________________________________________________________________
[1] 
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_obtain_bean_by_type

[2] 
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#enablement

[3] 
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#specialization



----- Original Message -----
> From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
> To: weld-dev at lists.jboss.org
> Cc: "Emily Jiang" <EMIJIANG at uk.ibm.com>
> Sent: Friday, August 24, 2018 3:10:05 PM
> Subject: [weld-dev] Question about the spec for BeanManager.getBeans
> 
> Hello
> 
> I was made aware of the difference on the return of
> beanManager.getBeans(Object.class) between OWB and Weld
> 
> In OWB, it returns all beans, unless there is an enabled @alternative 
within
> the application. If there is an enabled @alternative getBeans() only 
returns
> beans annotated @alternative.
> 
> However, in Weld, it returns all beans even with an enabled 
@alternative.
> 
> The JavaDoc for BeanMnanager says "according to the rules of typesafe
> resolution" and in the CDI 1.0 spec under typesafe resolution I find one
> mention of alternatives: ?When an ambiguous dependency exists, the 
container
> attempts to resolve the ambiguity. The container eliminates all eligible
> beans that are not alternatives, except for producer methods and fields 
of
> beans that are alternatives.? (This text is also in the CDI 1.2 spec)
> 
> However this would imply that if there are no enabled @Alternatives an
> ambiguous resolution like beanManager.getBeans(Object.class) should 
discard
> everything. In this case, the Weld behaviour is incorrect.
> beanManager.getBeans() should only return the resolved or enabled beans.
> 
> Regards
> Benjamin
> 
> Can someone verify this?
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> 
https://lists.jboss.org/mailman/listinfo/weld-dev





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180824/9e36ca8f/attachment.html 

From mkouba at redhat.com  Mon Aug 27 03:51:39 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 27 Aug 2018 09:51:39 +0200
Subject: [cdi-dev] [weld-dev] Question about the spec for
 BeanManager.getBeans
In-Reply-To: <OF202BDDBB.C91F8AD9-ON002582F3.00732C4C-802582F3.0074183A@notes.na.collabserv.com>
References: <OF17C82206.DF8D7992-ON002582F3.0047FB80-802582F3.004855C9@notes.na.collabserv.com>
	<1633794470.6460896.1535123819032.JavaMail.zimbra@redhat.com>
	<OF202BDDBB.C91F8AD9-ON002582F3.00732C4C-802582F3.0074183A@notes.na.collabserv.com>
Message-ID: <a1f86ffa-0b4c-4f8f-b6e3-f6e5ceb800ca@redhat.com>

Hi all,

BeanManager#getBeans() should not apply ambiguous dependency resolution 
rules - see also CDI-231 [1] and related changes. These rules should 
only be applied by BeanManager#resolve().

BeanManager#getBeans() and BeanManager#resolve() are in fact even more 
complicated because they should honor the inter-module injection rules. 
In other words, it also depends where you request the beans from. And 
this is where Weld and OWB differ a lot.

Martin

[1]
https://issues.jboss.org/browse/CDI-231


Dne 24.8.2018 v 23:08 Emily Jiang napsal(a):
> Matej,
> 
> Thanks for your quick reply!
> I think the spec is quite clear by saying the candidates of typesafe 
> resolutions defined in Performing typesafe resolutions... surely a 
> disabled bean cannot be a candidate. it is simply disquailified.
> 
> It did not say eliminate all beans but one though. I think it should be 
> eliminate disqualified ones and leave all qualified at least.
> 
> I am sending to cdi-dev for clarification. Antoine, please comment.
> 
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, Liberty Architect for MicroProfile and CDI
> 
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone: ?+44 (0)1962 816278 ?Internal: 246278
> 
> Email: emijiang at uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM at IBMGB
> 
> 
> 
> 
> From: Matej Novotny <manovotn at redhat.com>
> To: Benjamin Confino <BENJAMIC at uk.ibm.com>
> Cc: weld-dev at lists.jboss.org, Emily Jiang <EMIJIANG at uk.ibm.com>
> Date: 24/08/2018 16:17
> Subject: Re: [weld-dev] Question about the spec for BeanManager.getBeans
> ------------------------------------------------------------------------
> 
> 
> 
> Hi
> 
> Looking at spec 11.3.6. Obtaining a Bean by type[1] I can see that the 
> paragraph ends with "according to the rules for candidates of typesafe 
> resolution defined in Performing typesafe resolution.".
> The important word here is *candidates* IMO.
> The way typesafe resolution is defined, both the original bean and the 
> alternatives are candidates. According to spec, the original bean is 
> still considered enabled[2]
> Note that CDI spec doesn't say that @Alternative would completely 
> eliminate the original bean, it just takes precedence during resolution 
> (as opposed to what specialization does[3]).
> 
> Last but not least, one thought - if the getBeans() method was to 
> perform a typesafe resolution and eliminate all but one bean - why would 
> it return a Set (and not throw unsatisfied/ambiguous exceptions)? :)
> 
> Matej
> ______________________________________________________________________________
> [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_obtain_bean_by_type
> [2] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#enablement
> [3] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#specialization
> 
> 
> ----- Original Message -----
>  > From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
>  > To: weld-dev at lists.jboss.org
>  > Cc: "Emily Jiang" <EMIJIANG at uk.ibm.com>
>  > Sent: Friday, August 24, 2018 3:10:05 PM
>  > Subject: [weld-dev] Question about the spec for BeanManager.getBeans
>  >
>  > Hello
>  >
>  > I was made aware of the difference on the return of
>  > beanManager.getBeans(Object.class) between OWB and Weld
>  >
>  > In OWB, it returns all beans, unless there is an enabled @alternative 
> within
>  > the application. If there is an enabled @alternative getBeans() only 
> returns
>  > beans annotated @alternative.
>  >
>  > However, in Weld, it returns all beans even with an enabled @alternative.
>  >
>  > The JavaDoc for BeanMnanager says "according to the rules of typesafe
>  > resolution" and in the CDI 1.0 spec under typesafe resolution I find one
>  > mention of alternatives: ?When an ambiguous dependency exists, the 
> container
>  > attempts to resolve the ambiguity. The container eliminates all eligible
>  > beans that are not alternatives, except for producer methods and 
> fields of
>  > beans that are alternatives.? (This text is also in the CDI 1.2 spec)
>  >
>  > However this would imply that if there are no enabled @Alternatives an
>  > ambiguous resolution like beanManager.getBeans(Object.class) should 
> discard
>  > everything. In this case, the Weld behaviour is incorrect.
>  > beanManager.getBeans() should only return the resolved or enabled beans.
>  >
>  > Regards
>  > Benjamin
>  >
>  > Can someone verify this?
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
> PO6 3AU
>  >
>  > _______________________________________________
>  > weld-dev mailing list
>  > weld-dev at lists.jboss.org
>  > https://lists.jboss.org/mailman/listinfo/weld-dev
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> 
> _______________________________________________
> 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 EMIJIANG at uk.ibm.com  Tue Aug 28 14:37:31 2018
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Tue, 28 Aug 2018 19:37:31 +0100
Subject: [cdi-dev] [weld-dev] Question about the spec for
	BeanManager.getBeans
In-Reply-To: <a1f86ffa-0b4c-4f8f-b6e3-f6e5ceb800ca@redhat.com>
References: <OF17C82206.DF8D7992-ON002582F3.0047FB80-802582F3.004855C9@notes.na.collabserv.com>
	<1633794470.6460896.1535123819032.JavaMail.zimbra@redhat.com>
	<OF202BDDBB.C91F8AD9-ON002582F3.00732C4C-802582F3.0074183A@notes.na.collabserv.com>
	<a1f86ffa-0b4c-4f8f-b6e3-f6e5ceb800ca@redhat.com>
Message-ID: <OFD4DC59DC.35F4F54C-ON002582F7.00660682-802582F7.00664FE2@notes.na.collabserv.com>

Thank you Martin! 
I think the ticket you referred is clearer spelt out that all beans are 
included included disabled ones. From what you mentioned here, OWB based 
on Ben's experiment is incorrect by filtering out the disabled beans when 
calling beanmanager.getBeans().

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, Liberty Architect for MicroProfile and CDI
 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: emijiang at uk.ibm.com 
Lotus Notes: Emily Jiang/UK/IBM at IBMGB




From:   Martin Kouba <mkouba at redhat.com>
To:     Emily Jiang <EMIJIANG at uk.ibm.com>, Matej Novotny 
<manovotn at redhat.com>, cdi-dev <cdi-dev at lists.jboss.org>
Cc:     Benjamin Confino <BENJAMIC at uk.ibm.com>, weld-dev at lists.jboss.org
Date:   27/08/2018 08:51
Subject:        Re: [cdi-dev] [weld-dev] Question about the spec for 
BeanManager.getBeans



Hi all,

BeanManager#getBeans() should not apply ambiguous dependency resolution 
rules - see also CDI-231 [1] and related changes. These rules should 
only be applied by BeanManager#resolve().

BeanManager#getBeans() and BeanManager#resolve() are in fact even more 
complicated because they should honor the inter-module injection rules. 
In other words, it also depends where you request the beans from. And 
this is where Weld and OWB differ a lot.

Martin

[1]
https://issues.jboss.org/browse/CDI-231



Dne 24.8.2018 v 23:08 Emily Jiang napsal(a):
> Matej,
> 
> Thanks for your quick reply!
> I think the spec is quite clear by saying the candidates of typesafe 
> resolutions defined in Performing typesafe resolutions... surely a 
> disabled bean cannot be a candidate. it is simply disquailified.
> 
> It did not say eliminate all beans but one though. I think it should be 
> eliminate disqualified ones and leave all qualified at least.
> 
> I am sending to cdi-dev for clarification. Antoine, please comment.
> 
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, Liberty Architect for MicroProfile and CDI
> 
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
> 
> Email: emijiang at uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM at IBMGB
> 
> 
> 
> 
> From: Matej Novotny <manovotn at redhat.com>
> To: Benjamin Confino <BENJAMIC at uk.ibm.com>
> Cc: weld-dev at lists.jboss.org, Emily Jiang <EMIJIANG at uk.ibm.com>
> Date: 24/08/2018 16:17
> Subject: Re: [weld-dev] Question about the spec for BeanManager.getBeans
> ------------------------------------------------------------------------
> 
> 
> 
> Hi
> 
> Looking at spec 11.3.6. Obtaining a Bean by type[1] I can see that the 
> paragraph ends with "according to the rules for candidates of typesafe 
> resolution defined in Performing typesafe resolution.".
> The important word here is *candidates* IMO.
> The way typesafe resolution is defined, both the original bean and the 
> alternatives are candidates. According to spec, the original bean is 
> still considered enabled[2]
> Note that CDI spec doesn't say that @Alternative would completely 
> eliminate the original bean, it just takes precedence during resolution 
> (as opposed to what specialization does[3]).
> 
> Last but not least, one thought - if the getBeans() method was to 
> perform a typesafe resolution and eliminate all but one bean - why would 

> it return a Set (and not throw unsatisfied/ambiguous exceptions)? :)
> 
> Matej
> 
______________________________________________________________________________
> [1] 
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_obtain_bean_by_type

> [2] 
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#enablement

> [3] 
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#specialization

> 
> 
> ----- Original Message -----
>  > From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
>  > To: weld-dev at lists.jboss.org
>  > Cc: "Emily Jiang" <EMIJIANG at uk.ibm.com>
>  > Sent: Friday, August 24, 2018 3:10:05 PM
>  > Subject: [weld-dev] Question about the spec for BeanManager.getBeans
>  >
>  > Hello
>  >
>  > I was made aware of the difference on the return of
>  > beanManager.getBeans(Object.class) between OWB and Weld
>  >
>  > In OWB, it returns all beans, unless there is an enabled @alternative 

> within
>  > the application. If there is an enabled @alternative getBeans() only 
> returns
>  > beans annotated @alternative.
>  >
>  > However, in Weld, it returns all beans even with an enabled 
@alternative.
>  >
>  > The JavaDoc for BeanMnanager says "according to the rules of typesafe
>  > resolution" and in the CDI 1.0 spec under typesafe resolution I find 
one
>  > mention of alternatives: ?When an ambiguous dependency exists, the 
> container
>  > attempts to resolve the ambiguity. The container eliminates all 
eligible
>  > beans that are not alternatives, except for producer methods and 
> fields of
>  > beans that are alternatives.? (This text is also in the CDI 1.2 spec)
>  >
>  > However this would imply that if there are no enabled @Alternatives 
an
>  > ambiguous resolution like beanManager.getBeans(Object.class) should 
> discard
>  > everything. In this case, the Weld behaviour is incorrect.
>  > beanManager.getBeans() should only return the resolved or enabled 
beans.
>  >
>  > Regards
>  > Benjamin
>  >
>  > Can someone verify this?
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
> PO6 3AU
>  >
>  > _______________________________________________
>  > weld-dev mailing list
>  > weld-dev at lists.jboss.org
>  > 
https://lists.jboss.org/mailman/listinfo/weld-dev

> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 

> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> 
> _______________________________________________
> 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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180828/e4de5d8f/attachment.html 

From otaviopolianasantana at gmail.com  Fri Aug 31 11:43:55 2018
From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Fri, 31 Aug 2018 12:43:55 -0300
Subject: [cdi-dev] CDI-SPEC review
Message-ID: <CAPc8kR1pKz0LpuNzjJ2xwxBViRrRaO5WWqGsG+k_fAdjWMuMRQ@mail.gmail.com>

Hello everyone.
Could someone review these PRs?
https://github.com/cdi-spec/cdi-spec.org/pulls

-- 
Ot?vio Gon?alves de Santana


twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180831/28f1791b/attachment.html