From john.ament at spartasystems.com  Tue Nov  1 09:43:20 2016
From: john.ament at spartasystems.com (John Ament)
Date: Tue, 1 Nov 2016 13:43:20 +0000
Subject: [cdi-dev] Meeting on?
Message-ID: <CY4PR04MB04861A6359B34AA2F7E0350098A10@CY4PR04MB0486.namprd04.prod.outlook.com>

Hey guys


Is today's meeting on?  Looks like you guys moved your clocks ahead this past weekend, so its an hour later for me.  I can still join, but have to leave at X:45.


John


________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161101/e9715bf2/attachment.html 

From antoine at sabot-durand.net  Tue Nov  1 09:49:28 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 01 Nov 2016 13:49:28 +0000
Subject: [cdi-dev] Meeting on?
In-Reply-To: <CY4PR04MB04861A6359B34AA2F7E0350098A10@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CY4PR04MB04861A6359B34AA2F7E0350098A10@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <CABu-YBSNsgXuyjTrP18anOLcO9Xv4vZ4wgjAKXX0PQW7oEqKwg@mail.gmail.com>

sorry, I won't be able to join today, I'm in Devoxx Morocco. You're right
John, most of europe switched to DST this week end, so meeting will be one
hour later, next week.

Antoine

On Tue, Nov 1, 2016 at 1:44 PM John Ament <john.ament at spartasystems.com>
wrote:

> Hey guys
>
>
> Is today's meeting on?  Looks like you guys moved your clocks ahead this
> past weekend, so its an hour later for me.  I can still join, but have to
> leave at X:45.
>
>
> John
>
>
> ------------------------------
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the
> sender immediately by return e-mail, delete this message, and destroy all
> physical and electronic copies. Thank you.
> _______________________________________________
> 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/20161101/875ee699/attachment-0001.html 

From manovotn at redhat.com  Tue Nov  1 09:53:18 2016
From: manovotn at redhat.com (Matej Novotny)
Date: Tue, 1 Nov 2016 09:53:18 -0400 (EDT)
Subject: [cdi-dev] Meeting on?
In-Reply-To: <CY4PR04MB04861A6359B34AA2F7E0350098A10@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CY4PR04MB04861A6359B34AA2F7E0350098A10@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <2046198085.5843075.1478008398553.JavaMail.zimbra@redhat.com>

Hi there,

AFAIK Antoine is at devoxx Morocco, so no meeting today.

Matej

----- Original Message -----
> From: "John Ament" <john.ament at spartasystems.com>
> To: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Tuesday, November 1, 2016 2:43:20 PM
> Subject: [cdi-dev] Meeting on?
> 
> 
> 
> Hey guys
> 
> 
> 
> 
> Is today's meeting on? Looks like you guys moved your clocks ahead this past
> weekend, so its an hour later for me. I can still join, but have to leave at
> X:45.
> 
> 
> 
> 
> John
> 
> 
> 
> 
> 
> 
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the sender
> immediately by return e-mail, delete this message, and destroy all physical
> and electronic copies. Thank you.
> 
> _______________________________________________
> 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 Nov  1 11:43:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 1 Nov 2016 11:43:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-643) Provide a way to easily configure
 injection point of an InjectionTarget
In-Reply-To: <JIRA.12657855.1477755180000@Atlassian.JIRA>
References: <JIRA.12657855.1477755180000@Atlassian.JIRA>
	<JIRA.12657855.1477755180000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657855.1477755180000.4653.1478014980189@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-643:
------------------------------------------

In my remembering, this problem is for advanced CDI meta-data ({{BeanAttributesconfigurator}}, {{InjectionPointconfigurator}}, etc..). AnnotatedType is not bound to a container lifecycle, it's everywehere and usable at runtime (to create {{InjectionTarget}} for instance).
  

> Provide a way to easily configure injection point of an InjectionTarget
> -----------------------------------------------------------------------
>
>                 Key: CDI-643
>                 URL: https://issues.jboss.org/browse/CDI-643
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Creating an {{InjectionTarget}} requires an AnnotatedType. It is often convenient to create a custom {{AnnotatedType}} to add injection points in it (i.e. add {{@Inject}} on fields or methods).
> We Introduced the {{AnnotatedTypeConfigurator}} helper but didn't provide a way to use it to create an {{InjectionTarget}}.
> I think we should add {{BeanManager.createAnnotatedTypeConfigurator()}} to solve this and perhaps simplify other places where we could use an {{AnnotatedTypeConfigurator}} like in CDI-642



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Nov  1 11:46:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 1 Nov 2016 11:46:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0
In-Reply-To: <JIRA.12655302.1476712726000@Atlassian.JIRA>
References: <JIRA.12655302.1476712726000@Atlassian.JIRA>
	<JIRA.12655302.1476712726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655302.1476712726000.4694.1478015160097@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand reassigned CDI-638:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Introduce a new xsd for CDI 2.0
> -------------------------------
>
>                 Key: CDI-638
>                 URL: https://issues.jboss.org/browse/CDI-638
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> CDI-420 made us to introduce the {{<trim/>}} attribute to {{beans.xml}}, so we need to introduce a new grammar ({{beans_2_0.xsd}})for CDI 2.0.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From EMIJIANG at uk.ibm.com  Tue Nov  1 11:58:57 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Tue, 1 Nov 2016 15:58:57 +0000
Subject: [cdi-dev] Meeting on?
In-Reply-To: <CABu-YBSNsgXuyjTrP18anOLcO9Xv4vZ4wgjAKXX0PQW7oEqKwg@mail.gmail.com>
References: <CY4PR04MB04861A6359B34AA2F7E0350098A10@CY4PR04MB0486.namprd04.prod.outlook.com>
	<CABu-YBSNsgXuyjTrP18anOLcO9Xv4vZ4wgjAKXX0PQW7oEqKwg@mail.gmail.com>
Message-ID: <OFE15BC0A5.A942FF33-ON8025805E.00576E78-8025805E.0057CD16@notes.na.collabserv.com>

Hi Antoine,

Can you bring forward the meeting for an hour as it will be very difficult 
for me to attend the meeting after the clock changes? 

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
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:   Antoine Sabot-Durand <antoine at sabot-durand.net>
To:     John Ament <john.ament at spartasystems.com>, cdi-dev 
<cdi-dev at lists.jboss.org>
Date:   01/11/2016 13:51
Subject:        Re: [cdi-dev] Meeting on?
Sent by:        cdi-dev-bounces at lists.jboss.org



sorry, I won't be able to join today, I'm in Devoxx Morocco. You're right 
John, most of europe switched to DST this week end, so meeting will be one 
hour later, next week.

Antoine

On Tue, Nov 1, 2016 at 1:44 PM John Ament <john.ament at spartasystems.com> 
wrote:
Hey guys

Is today's meeting on?  Looks like you guys moved your clocks ahead this 
past weekend, so its an hour later for me.  I can still join, but have to 
leave at X:45.

John

NOTICE: This e-mail message and any attachments may contain confidential, 
proprietary, and/or privileged information which should be treated 
accordingly. If you are not the intended recipient, please notify the 
sender immediately by return e-mail, delete this message, and destroy all 
physical and electronic copies. Thank you. 
_______________________________________________
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.
_______________________________________________
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.

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/20161101/b9b5e6cd/attachment.html 

From issues at jboss.org  Wed Nov  2 05:34:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 2 Nov 2016 05:34:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0
In-Reply-To: <JIRA.12655302.1476712726000@Atlassian.JIRA>
References: <JIRA.12655302.1476712726000@Atlassian.JIRA>
	<JIRA.12655302.1476712726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655302.1476712726000.902.1478079240329@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CDI-638 started by Antoine Sabot-Durand.
------------------------------------------------
> Introduce a new xsd for CDI 2.0
> -------------------------------
>
>                 Key: CDI-638
>                 URL: https://issues.jboss.org/browse/CDI-638
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> CDI-420 made us to introduce the {{<trim/>}} attribute to {{beans.xml}}, so we need to introduce a new grammar ({{beans_2_0.xsd}})for CDI 2.0.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Nov  3 11:40:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 11:40:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-157) Enabling/Disabling Extensions
In-Reply-To: <JIRA.12446748.1315843013000@Atlassian.JIRA>
References: <JIRA.12446748.1315843013000@Atlassian.JIRA>
	<JIRA.12446748.1315843013000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446748.1315843013000.1188.1478187600538@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-157:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 (discussion))


> Enabling/Disabling Extensions
> -----------------------------
>
>                 Key: CDI-157
>                 URL: https://issues.jboss.org/browse/CDI-157
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>             Fix For: 2.1 (Discussion)
>
>
> Typically an extension class is packaged in a jar, along with a META-INF/services/javax.enterprise.inject.spi.Extension file which enables it. However, this means that an application, or another extension, has no way of disabling extensions.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 11:41:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 11:41:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-224) Support Decoration of no interface
	beans
In-Reply-To: <JIRA.12465476.1335953276000@Atlassian.JIRA>
References: <JIRA.12465476.1335953276000@Atlassian.JIRA>
	<JIRA.12465476.1335953276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465476.1335953276000.1205.1478187660770@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-224:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 (discussion))


> Support Decoration of no interface beans
> ----------------------------------------
>
>                 Key: CDI-224
>                 URL: https://issues.jboss.org/browse/CDI-224
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Decorators
>    Affects Versions: 1.0
>            Reporter: Aslak Knutsen
>            Assignee: Antoine Sabot-Durand
>              Labels: F2F2016
>             Fix For: 2.1 (Discussion)
>
>
> According to CDI 1.0 Spec:
> "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean."
> "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator."
> Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. 
> I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place.
> {code}
> import javax.decorator.Decorator;
> import javax.decorator.Delegate;
> import javax.enterprise.inject.Any;
> import javax.inject.Inject;
> import junit.framework.Assert;
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.jboss.shrinkwrap.impl.BeansXml;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> @RunWith(Arquillian.class)
> public class DecoratesClassTestCase {
> 	@Deployment
> 	public static WebArchive create() {
> 		return ShrinkWrap.create(WebArchive.class)
> 				.addAsWebInfResource(
> 						new BeansXml().decorators(BusinessDecorator.class), "beans.xml");
> 	}
> 	
> 	@Test
> 	public void shouldBeAbleToDecorate(BusinessObject business) throws Exception {
> 		Assert.assertEquals("Decorated Test", business.send("Test"));
> 	}
> 	
> 	@Decorator
> 	public static abstract class BusinessDecorator extends BusinessObject {
> 		@Inject @Delegate @Any
> 		private BusinessObject delegate;
> 		
> 		public String send(String msg) {
> 			return "Decorated " + delegate.send(msg);
> 		}
> 	}
> 	
> 	public static class BusinessObject {
> 		
> 		public String send(String msg) {
> 			return msg;
> 		}
> 	}
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 11:41:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 11:41:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-452) Specify that web scoped (request,
 session, application) beans are injectable in async servlets
In-Reply-To: <JIRA.12549310.1407962641000@Atlassian.JIRA>
References: <JIRA.12549310.1407962641000@Atlassian.JIRA>
	<JIRA.12549310.1407962641000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549310.1407962641000.1235.1478187661427@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-452:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 (discussion))


> Specify that web scoped (request, session, application) beans are injectable in async servlets
> ----------------------------------------------------------------------------------------------
>
>                 Key: CDI-452
>                 URL: https://issues.jboss.org/browse/CDI-452
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts, Java EE integration
>    Affects Versions: 1.0
>            Reporter: Ed Burns
>            Assignee: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> Consider this code based on this blog post: < https://weblogs.java.net/blog/swchan2/archive/2013/06/06/asynchronous-servlet-and-java-ee-concurrency-utilities >.
> {code}
> @WebServlet(urlPatterns="/test2", asyncSupported=true)
> public class TestAsyncMESServlet extends HttpServlet {
>     @Resource
>     private ManagedExecutorService managedExecutorService;
>     @Inject
>     MyRunnableImpl myRunnableImpl;
>     @Override
>     protected void doGet(HttpServletRequest req, HttpServletResponse res)
>             throws ServletException, IOException {
>         final AsyncContext asyncContext = req.startAsync();
>         final PrintWriter writer = res.getWriter();
>         managedExecutorService.submit(myRunnableImpl);
>     }
>     public static class MyRunnableImpl implements Runnable {
>       @Inject
>       Bean bean; // Bean is @RequestScoped
>       @Override
>       public void run() {
> 	  writer.println("Done");
> 	  asyncContext.complete();
>       }
>     }
> }
> {code}
> According to Jozef Hartzinger, this currently does not work, because only @Dependent and @ApplicationScoped beans are propagated to the new thread.  To keep CDI relevant in light of the reactive programming movement and the popularity of node.js, we need to make this work.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 11:42:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 11:42:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-502) Clarify "contains" meaning in
 "Legal bean types" specification.
In-Reply-To: <JIRA.12561865.1422442632000@Atlassian.JIRA>
References: <JIRA.12561865.1422442632000@Atlassian.JIRA>
	<JIRA.12561865.1422442632000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561865.1422442632000.1248.1478187720831@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-502:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 (discussion))


> Clarify "contains" meaning in "Legal bean types" specification.
> ---------------------------------------------------------------
>
>                 Key: CDI-502
>                 URL: https://issues.jboss.org/browse/CDI-502
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans, Inheritance and Specialization
>            Reporter: Tomasz Krakowiak
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.1 (Discussion)
>
>
> CDI 1.1, section 2.2.1. Legal bean types says:
> {quote}
> A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> Does it means direct containment or deep/recursive containment?
> I understand this is clearly illegal:
> {code}
> @Produces
> List<?> produceList(){
> //...
> }
> {code}
> But, are those two bean definitions legal:
> {code}
> @Produces
> List<Optional<?>> produceList(){
> //...
> }
> {code}
> {code}
> // Bean types: MyList, List<Optional<?>>, Object
> // or
> // Bean types: MyList, Object
> @Dependent
> MyList extends List<Optional<?>> {
> //...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 11:42:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 11:42:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-629) Consider standardizing
 AnnotationInstaceProvider from DeltaSpike
In-Reply-To: <JIRA.12649767.1473689261000@Atlassian.JIRA>
References: <JIRA.12649767.1473689261000@Atlassian.JIRA>
	<JIRA.12649767.1473689261000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649767.1473689261000.1256.1478187721000@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-629:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 (discussion))


> Consider standardizing AnnotationInstaceProvider from DeltaSpike
> ----------------------------------------------------------------
>
>                 Key: CDI-629
>                 URL: https://issues.jboss.org/browse/CDI-629
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>             Fix For: 2.1 (Discussion)
>
>
> http://lists.jboss.org/pipermail/cdi-dev/2016-September/008829.html
> Impl. notes:
> * the type safety is not guaranteed in the current version of 
> {{AnnotationInstanceProvider}} (deltaspike)
> * {{AnnotationInstanceProvider}} implements {{Serializable}} but a user is allowed to provide a map instance which is not serializable or contains values which are not serializable
> * the provided map of values should be copied (it can be mutable)
> * we should at least check the provided map of member values against the set of declared methods



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 11:43:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 11:43:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise
 javax.enterprise.util.AnnotationLiteral.cachedHashCode
In-Reply-To: <JIRA.12649776.1473690143000@Atlassian.JIRA>
References: <JIRA.12649776.1473690143000@Atlassian.JIRA>
	<JIRA.12649776.1473690143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649776.1473690143000.1279.1478187780674@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand resolved CDI-630.
--------------------------------------
    Fix Version/s:     (was: 2.0 (discussion))
       Resolution: Won't Fix


> Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode
> -------------------------------------------------------------
>
>                 Key: CDI-630
>                 URL: https://issues.jboss.org/browse/CDI-630
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Priority: Optional
>
> Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should -either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or- simply return zero and don't cache the value at all.
> UPDATE: We may not return a number based on the annotation type because it would break the {{java.lang.annotation.Annotation.hashCode()}} contract.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 11:43:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 11:43:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-631) Improve AnnotationLiteral for
 empty annotations
In-Reply-To: <JIRA.12649867.1473753012000@Atlassian.JIRA>
References: <JIRA.12649867.1473753012000@Atlassian.JIRA>
	<JIRA.12649867.1473753012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649867.1473753012000.1283.1478187780756@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-631:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 (discussion))


> Improve AnnotationLiteral for empty annotations
> -----------------------------------------------
>
>                 Key: CDI-631
>                 URL: https://issues.jboss.org/browse/CDI-631
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Mark Struberg
>             Fix For: 2.1 (Discussion)
>
>
> Annotation hashCode() and equals() operations are fairly expensive as they always invoke getDeclaredMethods() even if there are no such. And getDeclaredMethods involves the SecurityManager + wrapper classes + Exception handling + + + 
> That's horrible expensive.
> In OWB I improved this by introducing an own base class for dynamic annotations which do not have any members:
> https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/EmptyAnnotationLiteral.java
> The method returns a hardcoded String for toString(), returns hardcoded 0 as hashCode and the equals() method invokes the equals on the annotation type.
> We might support this improvements directly in the AnnotationLiteral class or introduce a similar 2nd class especially for empty annotations?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 12:09:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 12:09:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-462) Parts Epic for CDI 2.0
In-Reply-To: <JIRA.12551949.1410517089000@Atlassian.JIRA>
References: <JIRA.12551949.1410517089000@Atlassian.JIRA>
	<JIRA.12551949.1410517089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551949.1410517089000.1522.1478189340233@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand reopened CDI-462:
--------------------------------------


> Parts Epic for CDI 2.0
> ----------------------
>
>                 Key: CDI-462
>                 URL: https://issues.jboss.org/browse/CDI-462
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> this Epic ticket gathers all tickets and work documents about the introudction of parts (modularity) in CDI 2.0
> Draft document is here : https://docs.google.com/document/d/1AEBjQl00CZ9ERfgXSHq9cdxrngwsERjUCEmcdzgMSZ4/edit?usp=sharing 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 12:09:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 12:09:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-462) Parts Epic for CDI 2.0
In-Reply-To: <JIRA.12551949.1410517089000@Atlassian.JIRA>
References: <JIRA.12551949.1410517089000@Atlassian.JIRA>
	<JIRA.12551949.1410517089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551949.1410517089000.1524.1478189340274@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-462:
-------------------------------------
    Fix Version/s: 2.0 .Final
                       (was: 2.0 (discussion))


> Parts Epic for CDI 2.0
> ----------------------
>
>                 Key: CDI-462
>                 URL: https://issues.jboss.org/browse/CDI-462
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> this Epic ticket gathers all tickets and work documents about the introudction of parts (modularity) in CDI 2.0
> Draft document is here : https://docs.google.com/document/d/1AEBjQl00CZ9ERfgXSHq9cdxrngwsERjUCEmcdzgMSZ4/edit?usp=sharing 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 12:09:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 12:09:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-462) Parts Epic for CDI 2.0
In-Reply-To: <JIRA.12551949.1410517089000@Atlassian.JIRA>
References: <JIRA.12551949.1410517089000@Atlassian.JIRA>
	<JIRA.12551949.1410517089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551949.1410517089000.1528.1478189340370@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand resolved CDI-462.
--------------------------------------
    Resolution: Rejected


> Parts Epic for CDI 2.0
> ----------------------
>
>                 Key: CDI-462
>                 URL: https://issues.jboss.org/browse/CDI-462
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> this Epic ticket gathers all tickets and work documents about the introudction of parts (modularity) in CDI 2.0
> Draft document is here : https://docs.google.com/document/d/1AEBjQl00CZ9ERfgXSHq9cdxrngwsERjUCEmcdzgMSZ4/edit?usp=sharing 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 12:10:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 12:10:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-462) Parts Epic for CDI 2.0
In-Reply-To: <JIRA.12551949.1410517089000@Atlassian.JIRA>
References: <JIRA.12551949.1410517089000@Atlassian.JIRA>
	<JIRA.12551949.1410517089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551949.1410517089000.1532.1478189400268@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand closed CDI-462.
------------------------------------


> Parts Epic for CDI 2.0
> ----------------------
>
>                 Key: CDI-462
>                 URL: https://issues.jboss.org/browse/CDI-462
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> this Epic ticket gathers all tickets and work documents about the introudction of parts (modularity) in CDI 2.0
> Draft document is here : https://docs.google.com/document/d/1AEBjQl00CZ9ERfgXSHq9cdxrngwsERjUCEmcdzgMSZ4/edit?usp=sharing 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 12:12:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 12:12:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-461) Configuration Epic for CDI 2.0
In-Reply-To: <JIRA.12551944.1410513887000@Atlassian.JIRA>
References: <JIRA.12551944.1410513887000@Atlassian.JIRA>
	<JIRA.12551944.1410513887000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551944.1410513887000.1540.1478189520153@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand reopened CDI-461:
--------------------------------------


> Configuration Epic for CDI 2.0
> ------------------------------
>
>                 Key: CDI-461
>                 URL: https://issues.jboss.org/browse/CDI-461
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> This Epic ticket gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0.
> Draft document is here : https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 12:12:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 12:12:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-461) Configuration Epic for CDI 2.0
In-Reply-To: <JIRA.12551944.1410513887000@Atlassian.JIRA>
References: <JIRA.12551944.1410513887000@Atlassian.JIRA>
	<JIRA.12551944.1410513887000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551944.1410513887000.1541.1478189520202@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-461:
-------------------------------------
    Fix Version/s: 2.0 .Final
                       (was: 2.0 (discussion))


> Configuration Epic for CDI 2.0
> ------------------------------
>
>                 Key: CDI-461
>                 URL: https://issues.jboss.org/browse/CDI-461
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> This Epic ticket gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0.
> Draft document is here : https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov  3 12:12:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 3 Nov 2016 12:12:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-461) Configuration Epic for CDI 2.0
In-Reply-To: <JIRA.12551944.1410513887000@Atlassian.JIRA>
References: <JIRA.12551944.1410513887000@Atlassian.JIRA>
	<JIRA.12551944.1410513887000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551944.1410513887000.1543.1478189520284@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand closed CDI-461.
------------------------------------
    Resolution: Done


> Configuration Epic for CDI 2.0
> ------------------------------
>
>                 Key: CDI-461
>                 URL: https://issues.jboss.org/browse/CDI-461
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> This Epic ticket gathers all tickets and work document about studying the possible introduction of configuration feature in CDI 2.0.
> Draft document is here : https://docs.google.com/document/d/1378aTRNgCMXRYP9LBYRuGdan0mmQ3rPjjIYLWv2AB9I/edit?usp=sharing



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From antoine at sabot-durand.net  Mon Nov  7 08:51:02 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 07 Nov 2016 13:51:02 +0000
Subject: [cdi-dev] Need a review for PR 323 (new xsd for CDI 2.0)
Message-ID: <CABu-YBS1xzPtymJm8CkbvZwbMM4xOxjeW6r-mP+i8UuJQxEvFg@mail.gmail.com>

Hi all,

PR 323 is blocking 2 other PR, so if some of you have time today to review
the new xsd. Changes a rather small: version and year mainly.
Another PR is dealing with examples in the spec document.

Thx for your help,

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161107/0baaf731/attachment.html 

From john.ament at spartasystems.com  Mon Nov  7 08:56:48 2016
From: john.ament at spartasystems.com (John Ament)
Date: Mon, 7 Nov 2016 13:56:48 +0000
Subject: [cdi-dev] Whats pending for #305?
Message-ID: <CY4PR04MB0486F8245490A4DF62148A1C98A70@CY4PR04MB0486.namprd04.prod.outlook.com>

All,


Anything pending for https://github.com/cdi-spec/cdi/pull/305  to get merged?

[https://avatars3.githubusercontent.com/u/108167?v=3&s=400]<https://github.com/cdi-spec/cdi/pull/305>

CDI-30 Added a context controller specifically for requests and an in... by johnament ? Pull Request #305 ? cdi-spec/cdi<https://github.com/cdi-spec/cdi/pull/305>
github.com
...terceptor binding.



John

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161107/245a70f9/attachment.html 

From antoine at sabot-durand.net  Mon Nov  7 09:44:00 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 07 Nov 2016 14:44:00 +0000
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
Message-ID: <CABu-YBQYrCvOpj4z8n=WE4e2c9-w3vOJBfXDsZEWoWCcbo6WwQ@mail.gmail.com>

Hi all,

In my last review for CDI-580 (https://github.com/cdi-spec/cdi/pull/315), I
removed all reference to proxies in Javadoc and spec doc following various
feedback.
So now the name of the interface is the only one dealing with Proxy, so we
really need to find it a new name.
I listed some proposal in PR 315:
- InstanceEnhancer (short but not very clear)
- BusinessMethodInvocationFactory (more exact from spec pov, but is it
clear from user pov?)
- InterceptionFactory (cleared from user pov and near our initial name)
- InterceptionEnhancer

Feedback and other names are welcome.

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

From rmannibucau at gmail.com  Mon Nov  7 09:52:01 2016
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Mon, 7 Nov 2016 15:52:01 +0100
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <CABu-YBQYrCvOpj4z8n=WE4e2c9-w3vOJBfXDsZEWoWCcbo6WwQ@mail.gmail.com>
References: <CABu-YBQYrCvOpj4z8n=WE4e2c9-w3vOJBfXDsZEWoWCcbo6WwQ@mail.gmail.com>
Message-ID: <CACLE=7NR3hzT5HjaYdi-FJApGgN-3JjHGhzuU+BbQ2KT=cv_nA@mail.gmail.com>

Hello Antoine,

concurrency-utilities use ContextFactory for something pretty close (a
proxying adding spec features over invocations) which is less "cglib-like"
than "Enhancer" so I'd like to keep Factory. In the list InterceptionFactory
looks clear enough. We neevr speak of business method anymore I think so it
would add a difficulty for something very useful to go that deep in the
naming I think.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

> Hi all,
>
> In my last review for CDI-580 (https://github.com/cdi-spec/cdi/pull/315),
> I removed all reference to proxies in Javadoc and spec doc following
> various feedback.
> So now the name of the interface is the only one dealing with Proxy, so we
> really need to find it a new name.
> I listed some proposal in PR 315:
> - InstanceEnhancer (short but not very clear)
> - BusinessMethodInvocationFactory (more exact from spec pov, but is it
> clear from user pov?)
> - InterceptionFactory (cleared from user pov and near our initial name)
> - InterceptionEnhancer
>
> Feedback and other names are welcome.
>
> Antoine
>
> _______________________________________________
> 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/20161107/84ae10c7/attachment-0001.html 

From struberg at yahoo.de  Mon Nov  7 11:58:04 2016
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 7 Nov 2016 16:58:04 +0000 (UTC)
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <CACLE=7NR3hzT5HjaYdi-FJApGgN-3JjHGhzuU+BbQ2KT=cv_nA@mail.gmail.com>
References: <CABu-YBQYrCvOpj4z8n=WE4e2c9-w3vOJBfXDsZEWoWCcbo6WwQ@mail.gmail.com>
	<CACLE=7NR3hzT5HjaYdi-FJApGgN-3JjHGhzuU+BbQ2KT=cv_nA@mail.gmail.com>
Message-ID: <421014798.1728352.1478537884045@mail.yahoo.com>

InterceptionFactory sounds fine for me.


LieGrue,
strub



On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>
>Hello Antoine,
>
>
>concurrency-utilities use ContextFactory for something pretty close (a proxying adding spec features over invocations) which is less "cglib-like" than "Enhancer" so I'd like to keep Factory. In the list InterceptionFactory looks clear enough. We neevr speak of business method anymore I think so it would add a difficulty for something very useful to go that deep in the naming I think.
>
>
>
>Romain Manni-Bucau
>@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>
>2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:
>
>Hi all,
>>
>>
>>In my last review for CDI-580 (https://github.com/cdi-spec/ cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc following various feedback.
>>So now the name of the interface is the only one dealing with Proxy, so we really need to find it a new name.
>>I listed some proposal in PR 315:
>>- InstanceEnhancer (short but not very clear)
>>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it clear from user pov?)
>>- InterceptionFactory (cleared from user pov and near our initial name)
>>- InterceptionEnhancer
>>
>>
>>Feedback and other names are welcome.
>>
>>
>>Antoine
>>______________________________ _________________
>>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.
>>
>
>
>_______________________________________________
>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 antoine at sabot-durand.net  Tue Nov  8 08:24:28 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 08 Nov 2016 13:24:28 +0000
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <421014798.1728352.1478537884045@mail.yahoo.com>
References: <CABu-YBQYrCvOpj4z8n=WE4e2c9-w3vOJBfXDsZEWoWCcbo6WwQ@mail.gmail.com>
	<CACLE=7NR3hzT5HjaYdi-FJApGgN-3JjHGhzuU+BbQ2KT=cv_nA@mail.gmail.com>
	<421014798.1728352.1478537884045@mail.yahoo.com>
Message-ID: <CABu-YBRhd8UYWck4-fibda_Ykoh-n=u_Xfhs48tUcBCOw_TiAw@mail.gmail.com>

+1 for InterceptionFactory as well. I change my PR with this name.

Romain, for the record, mentioning "business method invocation" and
paragraph 7.2 is the only mean to bind this feature to the spec without
mentioning implementation specific stuff like proxies. That's why the
javadoc and text for this new section lack clarity. In other word we lack a
simple name for instances on which "methods invocation" are "business
methods invocation".

Antoine

On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de> wrote:

> InterceptionFactory sounds fine for me.
>
>
> LieGrue,
> strub
>
>
>
> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> rmannibucau at gmail.com> wrote:
> >
> >Hello Antoine,
> >
> >
> >concurrency-utilities use ContextFactory for something pretty close (a
> proxying adding spec features over invocations) which is less "cglib-like"
> than "Enhancer" so I'd like to keep Factory. In the list
> InterceptionFactory looks clear enough. We neevr speak of business method
> anymore I think so it would add a difficulty for something very useful to
> go that deep in the naming I think.
> >
> >
> >
> >Romain Manni-Bucau
> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net
> >:
> >
> >Hi all,
> >>
> >>
> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
> following various feedback.
> >>So now the name of the interface is the only one dealing with Proxy, so
> we really need to find it a new name.
> >>I listed some proposal in PR 315:
> >>- InstanceEnhancer (short but not very clear)
> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
> clear from user pov?)
> >>- InterceptionFactory (cleared from user pov and near our initial name)
> >>- InterceptionEnhancer
> >>
> >>
> >>Feedback and other names are welcome.
> >>
> >>
> >>Antoine
> >>______________________________ _________________
> >>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.
> >>
> >
> >
> >_______________________________________________
> >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/20161108/efa4663c/attachment.html 

From rmannibucau at gmail.com  Tue Nov  8 08:28:27 2016
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 8 Nov 2016 14:28:27 +0100
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <CABu-YBRhd8UYWck4-fibda_Ykoh-n=u_Xfhs48tUcBCOw_TiAw@mail.gmail.com>
References: <CABu-YBQYrCvOpj4z8n=WE4e2c9-w3vOJBfXDsZEWoWCcbo6WwQ@mail.gmail.com>
	<CACLE=7NR3hzT5HjaYdi-FJApGgN-3JjHGhzuU+BbQ2KT=cv_nA@mail.gmail.com>
	<421014798.1728352.1478537884045@mail.yahoo.com>
	<CABu-YBRhd8UYWck4-fibda_Ykoh-n=u_Xfhs48tUcBCOw_TiAw@mail.gmail.com>
Message-ID: <CACLE=7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg@mail.gmail.com>

2016-11-08 14:24 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

> +1 for InterceptionFactory as well. I change my PR with this name.
>
> Romain, for the record, mentioning "business method invocation" and
> paragraph 7.2 is the only mean to bind this feature to the spec without
> mentioning implementation specific stuff like proxies. That's why the
> javadoc and text for this new section lack clarity. In other word we lack a
> simple name for instances on which "methods invocation" are "business
> methods invocation".
>
>
Agree and it fits the spec but since EJB I never heard any developer (not
developping weld or openwebbeans) using this term so for the API it would
be rude IMHO - was the point, nothing more.


> Antoine
>
> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de> wrote:
>
>> InterceptionFactory sounds fine for me.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
>> rmannibucau at gmail.com> wrote:
>> >
>> >Hello Antoine,
>> >
>> >
>> >concurrency-utilities use ContextFactory for something pretty close (a
>> proxying adding spec features over invocations) which is less "cglib-like"
>> than "Enhancer" so I'd like to keep Factory. In the list
>> InterceptionFactory looks clear enough. We neevr speak of business method
>> anymore I think so it would add a difficulty for something very useful to
>> go that deep in the naming I think.
>> >
>> >
>> >
>> >Romain Manni-Bucau
>> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> >
>> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
>> antoine at sabot-durand.net>:
>> >
>> >Hi all,
>> >>
>> >>
>> >>In my last review for CDI-580 (https://github.com/cdi-spec/
>> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
>> following various feedback.
>> >>So now the name of the interface is the only one dealing with Proxy, so
>> we really need to find it a new name.
>> >>I listed some proposal in PR 315:
>> >>- InstanceEnhancer (short but not very clear)
>> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
>> clear from user pov?)
>> >>- InterceptionFactory (cleared from user pov and near our initial name)
>> >>- InterceptionEnhancer
>> >>
>> >>
>> >>Feedback and other names are welcome.
>> >>
>> >>
>> >>Antoine
>> >>______________________________ _________________
>> >>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.
>> >>
>> >
>> >
>> >_______________________________________________
>> >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/20161108/c6e8a845/attachment-0001.html 

From werner.keil at gmail.com  Tue Nov  8 08:30:54 2016
From: werner.keil at gmail.com (Werner Keil)
Date: Tue, 8 Nov 2016 14:30:54 +0100
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
Message-ID: <CAAGawe0GNLRfnXY1rhaoBwzR0_eWFJvQHSrQ4WcAX8_qMLnCRw@mail.gmail.com>

+1 for InterceptionFactory, too.
It sounds simpler.

Werner


On Tue, Nov 8, 2016 at 2:29 PM, <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: Finding a new name for InterceptorProxyFactory (Mark Struberg)
>    2. Re: Finding a new name for InterceptorProxyFactory
>       (Antoine Sabot-Durand)
>    3. Re: Finding a new name for InterceptorProxyFactory
>       (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 7 Nov 2016 16:58:04 +0000 (UTC)
> From: Mark Struberg <struberg at yahoo.de>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Romain Manni-Bucau <rmannibucau at gmail.com>, Antoine Sabot-Durand
>         <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <421014798.1728352.1478537884045 at mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
> InterceptionFactory sounds fine for me.
>
>
> LieGrue,
> strub
>
>
>
> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> rmannibucau at gmail.com> wrote:
> >
> >Hello Antoine,
> >
> >
> >concurrency-utilities use ContextFactory for something pretty close (a
> proxying adding spec features over invocations) which is less "cglib-like"
> than "Enhancer" so I'd like to keep Factory. In the list
> InterceptionFactory looks clear enough. We neevr speak of business method
> anymore I think so it would add a difficulty for something very useful to
> go that deep in the naming I think.
> >
> >
> >
> >Romain Manni-Bucau
> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net
> >:
> >
> >Hi all,
> >>
> >>
> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
> following various feedback.
> >>So now the name of the interface is the only one dealing with Proxy, so
> we really need to find it a new name.
> >>I listed some proposal in PR 315:
> >>- InstanceEnhancer (short but not very clear)
> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
> clear from user pov?)
> >>- InterceptionFactory (cleared from user pov and near our initial name)
> >>- InterceptionEnhancer
> >>
> >>
> >>Feedback and other names are welcome.
> >>
> >>
> >>Antoine
> >>______________________________ _________________
> >>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.
> >>
> >
> >
> >_______________________________________________
> >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.
> >
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 08 Nov 2016 13:24:28 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Mark Struberg <struberg at yahoo.de>,  Romain Manni-Bucau
>         <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CABu-YBRhd8UYWck4-fibda_Ykoh-n=u_Xfhs48tUcBCOw_TiAw at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1 for InterceptionFactory as well. I change my PR with this name.
>
> Romain, for the record, mentioning "business method invocation" and
> paragraph 7.2 is the only mean to bind this feature to the spec without
> mentioning implementation specific stuff like proxies. That's why the
> javadoc and text for this new section lack clarity. In other word we lack a
> simple name for instances on which "methods invocation" are "business
> methods invocation".
>
> Antoine
>
> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de> wrote:
>
> > InterceptionFactory sounds fine for me.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> > rmannibucau at gmail.com> wrote:
> > >
> > >Hello Antoine,
> > >
> > >
> > >concurrency-utilities use ContextFactory for something pretty close (a
> > proxying adding spec features over invocations) which is less
> "cglib-like"
> > than "Enhancer" so I'd like to keep Factory. In the list
> > InterceptionFactory looks clear enough. We neevr speak of business method
> > anymore I think so it would add a difficulty for something very useful to
> > go that deep in the naming I think.
> > >
> > >
> > >
> > >Romain Manni-Bucau
> > >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> > >
> > >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
> antoine at sabot-durand.net
> > >:
> > >
> > >Hi all,
> > >>
> > >>
> > >>In my last review for CDI-580 (https://github.com/cdi-spec/
> > cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
> > following various feedback.
> > >>So now the name of the interface is the only one dealing with Proxy, so
> > we really need to find it a new name.
> > >>I listed some proposal in PR 315:
> > >>- InstanceEnhancer (short but not very clear)
> > >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
> > clear from user pov?)
> > >>- InterceptionFactory (cleared from user pov and near our initial name)
> > >>- InterceptionEnhancer
> > >>
> > >>
> > >>Feedback and other names are welcome.
> > >>
> > >>
> > >>Antoine
> > >>______________________________ _________________
> > >>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.
> > >>
> > >
> > >
> > >_______________________________________________
> > >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/
> 20161108/efa4663c/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Tue, 8 Nov 2016 14:28:27 +0100
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.
> com>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-11-08 14:24 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net
> >:
>
> > +1 for InterceptionFactory as well. I change my PR with this name.
> >
> > Romain, for the record, mentioning "business method invocation" and
> > paragraph 7.2 is the only mean to bind this feature to the spec without
> > mentioning implementation specific stuff like proxies. That's why the
> > javadoc and text for this new section lack clarity. In other word we
> lack a
> > simple name for instances on which "methods invocation" are "business
> > methods invocation".
> >
> >
> Agree and it fits the spec but since EJB I never heard any developer (not
> developping weld or openwebbeans) using this term so for the API it would
> be rude IMHO - was the point, nothing more.
>
>
> > Antoine
> >
> > On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de> wrote:
> >
> >> InterceptionFactory sounds fine for me.
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> >> rmannibucau at gmail.com> wrote:
> >> >
> >> >Hello Antoine,
> >> >
> >> >
> >> >concurrency-utilities use ContextFactory for something pretty close (a
> >> proxying adding spec features over invocations) which is less
> "cglib-like"
> >> than "Enhancer" so I'd like to keep Factory. In the list
> >> InterceptionFactory looks clear enough. We neevr speak of business
> method
> >> anymore I think so it would add a difficulty for something very useful
> to
> >> go that deep in the naming I think.
> >> >
> >> >
> >> >
> >> >Romain Manni-Bucau
> >> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >> >
> >> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
> >> antoine at sabot-durand.net>:
> >> >
> >> >Hi all,
> >> >>
> >> >>
> >> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> >> cdi/pull/315), I removed all reference to proxies in Javadoc and spec
> doc
> >> following various feedback.
> >> >>So now the name of the interface is the only one dealing with Proxy,
> so
> >> we really need to find it a new name.
> >> >>I listed some proposal in PR 315:
> >> >>- InstanceEnhancer (short but not very clear)
> >> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is
> it
> >> clear from user pov?)
> >> >>- InterceptionFactory (cleared from user pov and near our initial
> name)
> >> >>- InterceptionEnhancer
> >> >>
> >> >>
> >> >>Feedback and other names are welcome.
> >> >>
> >> >>
> >> >>Antoine
> >> >>______________________________ _________________
> >> >>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.
> >> >>
> >> >
> >> >
> >> >_______________________________________________
> >> >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/
> 20161108/c6e8a845/attachment.html
>
> ------------------------------
>
> _______________________________________________
> 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 72, Issue 5
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/0d7d3b0e/attachment-0001.html 

From john.ament at spartasystems.com  Tue Nov  8 08:35:51 2016
From: john.ament at spartasystems.com (John Ament)
Date: Tue, 8 Nov 2016 13:35:51 +0000
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <CAAGawe0GNLRfnXY1rhaoBwzR0_eWFJvQHSrQ4WcAX8_qMLnCRw@mail.gmail.com>
References: <CAAGawe0GNLRfnXY1rhaoBwzR0_eWFJvQHSrQ4WcAX8_qMLnCRw@mail.gmail.com>
Message-ID: <CY4PR04MB0486DD2E2DB8705A4ABB995E98A60@CY4PR04MB0486.namprd04.prod.outlook.com>

If the only use case is for inceptors, I agree to InterceptionFactory.


________________________________
From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on behalf of Werner Keil <werner.keil at gmail.com>
Sent: Tuesday, November 8, 2016 8:30 AM
To: cdi-dev
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory

+1 for InterceptionFactory, too.
It sounds simpler.

Werner


On Tue, Nov 8, 2016 at 2:29 PM, <cdi-dev-request at lists.jboss.org<mailto:cdi-dev-request at lists.jboss.org>> wrote:
Send cdi-dev mailing list submissions to
        cdi-dev at lists.jboss.org<mailto: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<mailto:cdi-dev-request at lists.jboss.org>

You can reach the person managing the list at
        cdi-dev-owner at lists.jboss.org<mailto: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: Finding a new name for InterceptorProxyFactory (Mark Struberg)
   2. Re: Finding a new name for InterceptorProxyFactory
      (Antoine Sabot-Durand)
   3. Re: Finding a new name for InterceptorProxyFactory
      (Romain Manni-Bucau)


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

Message: 1
Date: Mon, 7 Nov 2016 16:58:04 +0000 (UTC)
From: Mark Struberg <struberg at yahoo.de<mailto:struberg at yahoo.de>>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Romain Manni-Bucau <rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>>, Antoine Sabot-Durand
        <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>
Cc: cdi-dev <cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>>
Message-ID: <421014798.1728352.1478537884045 at mail.yahoo.com<mailto:421014798.1728352.1478537884045 at mail.yahoo.com>>
Content-Type: text/plain; charset=UTF-8

InterceptionFactory sounds fine for me.


LieGrue,
strub



On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>> wrote:
>
>Hello Antoine,
>
>
>concurrency-utilities use ContextFactory for something pretty close (a proxying adding spec features over invocations) which is less "cglib-like" than "Enhancer" so I'd like to keep Factory. In the list InterceptionFactory looks clear enough. We neevr speak of business method anymore I think so it would add a difficulty for something very useful to go that deep in the naming I think.
>
>
>
>Romain Manni-Bucau
>@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>
>2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>:
>
>Hi all,
>>
>>
>>In my last review for CDI-580 (https://github.com/cdi-spec/ cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc following various feedback.
>>So now the name of the interface is the only one dealing with Proxy, so we really need to find it a new name.
>>I listed some proposal in PR 315:
>>- InstanceEnhancer (short but not very clear)
>>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it clear from user pov?)
>>- InterceptionFactory (cleared from user pov and near our initial name)
>>- InterceptionEnhancer
>>
>>
>>Feedback and other names are welcome.
>>
>>
>>Antoine
>>______________________________ _________________
>>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<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.
>
>


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

Message: 2
Date: Tue, 08 Nov 2016 13:24:28 +0000
From: Antoine Sabot-Durand <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Mark Struberg <struberg at yahoo.de<mailto:struberg at yahoo.de>>,  Romain Manni-Bucau
        <rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>>
Cc: cdi-dev <cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>>
Message-ID:
        <CABu-YBRhd8UYWck4-fibda_Ykoh-n=u_Xfhs48tUcBCOw_TiAw at mail.gmail.com<mailto:u_Xfhs48tUcBCOw_TiAw at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

+1 for InterceptionFactory as well. I change my PR with this name.

Romain, for the record, mentioning "business method invocation" and
paragraph 7.2 is the only mean to bind this feature to the spec without
mentioning implementation specific stuff like proxies. That's why the
javadoc and text for this new section lack clarity. In other word we lack a
simple name for instances on which "methods invocation" are "business
methods invocation".

Antoine

On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de<mailto:struberg at yahoo.de>> wrote:

> InterceptionFactory sounds fine for me.
>
>
> LieGrue,
> strub
>
>
>
> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>> wrote:
> >
> >Hello Antoine,
> >
> >
> >concurrency-utilities use ContextFactory for something pretty close (a
> proxying adding spec features over invocations) which is less "cglib-like"
> than "Enhancer" so I'd like to keep Factory. In the list
> InterceptionFactory looks clear enough. We neevr speak of business method
> anymore I think so it would add a difficulty for something very useful to
> go that deep in the naming I think.
> >
> >
> >
> >Romain Manni-Bucau
> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>
> >:
> >
> >Hi all,
> >>
> >>
> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
> following various feedback.
> >>So now the name of the interface is the only one dealing with Proxy, so
> we really need to find it a new name.
> >>I listed some proposal in PR 315:
> >>- InstanceEnhancer (short but not very clear)
> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
> clear from user pov?)
> >>- InterceptionFactory (cleared from user pov and near our initial name)
> >>- InterceptionEnhancer
> >>
> >>
> >>Feedback and other names are welcome.
> >>
> >>
> >>Antoine
> >>______________________________ _________________
> >>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<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.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/efa4663c/attachment-0001.html

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

Message: 3
Date: Tue, 8 Nov 2016 14:28:27 +0100
From: Romain Manni-Bucau <rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Antoine Sabot-Durand <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>
Cc: cdi-dev <cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>>
Message-ID:
        <CACLE=7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com<mailto:7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

2016-11-08 14:24 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>:

> +1 for InterceptionFactory as well. I change my PR with this name.
>
> Romain, for the record, mentioning "business method invocation" and
> paragraph 7.2 is the only mean to bind this feature to the spec without
> mentioning implementation specific stuff like proxies. That's why the
> javadoc and text for this new section lack clarity. In other word we lack a
> simple name for instances on which "methods invocation" are "business
> methods invocation".
>
>
Agree and it fits the spec but since EJB I never heard any developer (not
developping weld or openwebbeans) using this term so for the API it would
be rude IMHO - was the point, nothing more.


> Antoine
>
> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de<mailto:struberg at yahoo.de>> wrote:
>
>> InterceptionFactory sounds fine for me.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
>> rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>> wrote:
>> >
>> >Hello Antoine,
>> >
>> >
>> >concurrency-utilities use ContextFactory for something pretty close (a
>> proxying adding spec features over invocations) which is less "cglib-like"
>> than "Enhancer" so I'd like to keep Factory. In the list
>> InterceptionFactory looks clear enough. We neevr speak of business method
>> anymore I think so it would add a difficulty for something very useful to
>> go that deep in the naming I think.
>> >
>> >
>> >
>> >Romain Manni-Bucau
>> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> >
>> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
>> antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>:
>> >
>> >Hi all,
>> >>
>> >>
>> >>In my last review for CDI-580 (https://github.com/cdi-spec/
>> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
>> following various feedback.
>> >>So now the name of the interface is the only one dealing with Proxy, so
>> we really need to find it a new name.
>> >>I listed some proposal in PR 315:
>> >>- InstanceEnhancer (short but not very clear)
>> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
>> clear from user pov?)
>> >>- InterceptionFactory (cleared from user pov and near our initial name)
>> >>- InterceptionEnhancer
>> >>
>> >>
>> >>Feedback and other names are welcome.
>> >>
>> >>
>> >>Antoine
>> >>______________________________ _________________
>> >>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<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.
>> >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/c6e8a845/attachment.html

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

_______________________________________________
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.

End of cdi-dev Digest, Vol 72, Issue 5
**************************************

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/83c15651/attachment-0001.html 

From issues at jboss.org  Tue Nov  8 08:41:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 8 Nov 2016 08:41:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-30) An API for managing built in
 request contexts designed for other frameworks
In-Reply-To: <JIRA.12427803.1294750750000@Atlassian.JIRA>
References: <JIRA.12427803.1294750750000@Atlassian.JIRA>
	<JIRA.12427803.1294750750000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12427803.1294750750000.23869.1478612460639@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ament updated CDI-30:
--------------------------
    Summary: An API for managing built in request contexts designed for other frameworks  (was: An API for managing built in contexts designed for other frameworks)


> An API for managing built in request contexts designed for other frameworks
> ---------------------------------------------------------------------------
>
>                 Key: CDI-30
>                 URL: https://issues.jboss.org/browse/CDI-30
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>    Affects Versions: 1.0
>            Reporter: Nicklas Karlsson
>            Assignee: John Ament
>             Fix For: 2.0 .Final
>
>
> In order to allow CDI to play well in the general ecosystem, it needs to have SPIs.  These SPIs need to allow other libraries to do things like register beans (CDI extensions), look up a bean manager, and get managed versions of its classes.
> CDI has no way currently to support a framework starting and stopping built in contexts.  These built in contexts are not really clear in how they are started, other than the container is responsible for starting them.  This means its near impossible for an external library which is not Java EE aware to start these built in contexts.  Being able to reuse these contexts allow developers to build their beans once and reuse them in many use cases.
> These use cases may include:
> 1. Quartz Scheduler/CDI Integration.  A Prototype of this is available in DeltaSpike, where jobs can be managed beans, by overriding the InstanceJobFactory, and can have contexts started via an annotation.  To bring it a step further, Quartz, in order to mirror Java EE capabilities, may want to say that during the execution of a job, an instance of a request context is active.  To do this, the developer should not need to do anything, but instead Quartz may automatically register a job listener that starts and stops the context (see: http://www.quartz-scheduler.org/documentation/quartz-2.2.x/cookbook/JobListeners.html)
> 2. Camel-CDI.  Camel may want to say that during the execution of a route, a request context is active.  
> 3. Netty/CDI (or any arbitrary network based server).  During the reception of a message over TCP, a request is active.  Likewise, for the entire TCP connection a session context is active.
> 4. Sparkjava/CDI.  Assuming that sparkjava isn't running in a servlet container, during the execution of an arbitrary reactive method call, a request context is available for use.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov  8 10:33:01 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 8 Nov 2016 10:33:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an
 interceptor/decorator is enabled using both @Priority and beans.xml
In-Reply-To: <JIRA.12556682.1415175307000@Atlassian.JIRA>
References: <JIRA.12556682.1415175307000@Atlassian.JIRA>
	<JIRA.12556682.1415175307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556682.1415175307000.25369.1478619181200@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CDI-490 started by John Ament.
--------------------------------------
> Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
> ------------------------------------------------------------------------------------------------
>
>                 Key: CDI-490
>                 URL: https://issues.jboss.org/browse/CDI-490
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators, Interceptors
>    Affects Versions: 1.2.Final
>            Reporter: Jozef Hartinger
>            Assignee: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 .Final
>
>
> Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because:
> {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final
> list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote}
> it matches both parts of the statement.
> As for ordering, the following statement defines invocation order:
> {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote}
> Since InterceptorA is enabled by both @Priority and beans.xml, the following applies:
> "Interceptors enabled using @Priority" = \{ InterceptorA \}
> "interceptors enabled using beans.xml" = \{ InterceptorA \}
> We can perform substitution in the statement and we get:
> *\{ InterceptorA \} are called before \{ InterceptorA \}*
> which does not seem right.
> The specification should explicitly address this scenario. There are several options (some of them are better, some are worse):
> 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml
> 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence)
> 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence)
> 4) Forbid an interceptor to be enabled by both @Priority and beans.xml



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Nov  8 11:27:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 8 Nov 2016 11:27:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-312) ProcessModule doesn't reflect the
 @Priority changes in CDI-18
In-Reply-To: <JIRA.12480790.1355151025000@Atlassian.JIRA>
References: <JIRA.12480790.1355151025000@Atlassian.JIRA>
	<JIRA.12480790.1355151025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480790.1355151025000.26072.1478622420153@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba resolved CDI-312.
------------------------------
    Resolution: Out of Date


{{ProcessModule}} was removed.

> ProcessModule doesn't reflect the @Priority changes in CDI-18
> -------------------------------------------------------------
>
>                 Key: CDI-312
>                 URL: https://issues.jboss.org/browse/CDI-312
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Packaging and Deployment, Portable Extensions
>            Reporter: Mark Struberg
>
> ProcessModule has a getAlternatives() method which returns a Set<Class> of all enabled alternatives. This Set is mutable and can get changed via extensions. But which 'priority' should such an added Alternative have? (see CDI-18). And should this only account for the one beans.xml or all? 
> Also what is about 'globally' enabled alternatives? Should they get returned in all modules or just in the module they are enabled in? 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From antoine at sabot-durand.net  Tue Nov  8 12:04:05 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 08 Nov 2016 17:04:05 +0000
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <CY4PR04MB0486DD2E2DB8705A4ABB995E98A60@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CAAGawe0GNLRfnXY1rhaoBwzR0_eWFJvQHSrQ4WcAX8_qMLnCRw@mail.gmail.com>
	<CY4PR04MB0486DD2E2DB8705A4ABB995E98A60@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <CABu-YBRC3kn8TXWc3hjt3VeMrYDwMjyejzsxfRBpDFKYNnyDdA@mail.gmail.com>

On Tue, Nov 8, 2016 at 2:38 PM John Ament <john.ament at spartasystems.com>
wrote:

> If the only use case is for inceptors, I agree to InterceptionFactory.
>
What other use case you are thinking of John?




>
> ------------------------------
> *From:* cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org>
> on behalf of Werner Keil <werner.keil at gmail.com>
> *Sent:* Tuesday, November 8, 2016 8:30 AM
> *To:* cdi-dev
>
> *Subject:* Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> +1 for InterceptionFactory, too.
> It sounds simpler.
>
> Werner
>
>
> On Tue, Nov 8, 2016 at 2:29 PM, <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: Finding a new name for InterceptorProxyFactory (Mark Struberg)
>    2. Re: Finding a new name for InterceptorProxyFactory
>       (Antoine Sabot-Durand)
>    3. Re: Finding a new name for InterceptorProxyFactory
>       (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 7 Nov 2016 16:58:04 +0000 (UTC)
> From: Mark Struberg <struberg at yahoo.de>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Romain Manni-Bucau <rmannibucau at gmail.com>, Antoine Sabot-Durand
>         <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <421014798.1728352.1478537884045 at mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
> InterceptionFactory sounds fine for me.
>
>
> LieGrue,
> strub
>
>
>
> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> rmannibucau at gmail.com> wrote:
> >
> >Hello Antoine,
> >
> >
> >concurrency-utilities use ContextFactory for something pretty close (a
> proxying adding spec features over invocations) which is less "cglib-like"
> than "Enhancer" so I'd like to keep Factory. In the list
> InterceptionFactory looks clear enough. We neevr speak of business method
> anymore I think so it would add a difficulty for something very useful to
> go that deep in the naming I think.
> >
> >
> >
> >Romain Manni-Bucau
> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net
> >:
> >
> >Hi all,
> >>
> >>
> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
> following various feedback.
> >>So now the name of the interface is the only one dealing with Proxy, so
> we really need to find it a new name.
> >>I listed some proposal in PR 315:
> >>- InstanceEnhancer (short but not very clear)
> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
> clear from user pov?)
> >>- InterceptionFactory (cleared from user pov and near our initial name)
> >>- InterceptionEnhancer
> >>
> >>
> >>Feedback and other names are welcome.
> >>
> >>
> >>Antoine
> >>______________________________ _________________
> >>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.
> >>
> >
> >
> >_______________________________________________
> >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.
> >
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 08 Nov 2016 13:24:28 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Mark Struberg <struberg at yahoo.de>,  Romain Manni-Bucau
>         <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CABu-YBRhd8UYWck4-fibda_Ykoh-n=
> u_Xfhs48tUcBCOw_TiAw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1 for InterceptionFactory as well. I change my PR with this name.
>
> Romain, for the record, mentioning "business method invocation" and
> paragraph 7.2 is the only mean to bind this feature to the spec without
> mentioning implementation specific stuff like proxies. That's why the
> javadoc and text for this new section lack clarity. In other word we lack a
> simple name for instances on which "methods invocation" are "business
> methods invocation".
>
> Antoine
>
> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de> wrote:
>
> > InterceptionFactory sounds fine for me.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> > rmannibucau at gmail.com> wrote:
> > >
> > >Hello Antoine,
> > >
> > >
> > >concurrency-utilities use ContextFactory for something pretty close (a
> > proxying adding spec features over invocations) which is less
> "cglib-like"
> > than "Enhancer" so I'd like to keep Factory. In the list
> > InterceptionFactory looks clear enough. We neevr speak of business method
> > anymore I think so it would add a difficulty for something very useful to
> > go that deep in the naming I think.
> > >
> > >
> > >
> > >Romain Manni-Bucau
> > >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> > >
> > >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
> antoine at sabot-durand.net
> > >:
> > >
> > >Hi all,
> > >>
> > >>
> > >>In my last review for CDI-580 (https://github.com/cdi-spec/
> > cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
> > following various feedback.
> > >>So now the name of the interface is the only one dealing with Proxy, so
> > we really need to find it a new name.
> > >>I listed some proposal in PR 315:
> > >>- InstanceEnhancer (short but not very clear)
> > >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
> > clear from user pov?)
> > >>- InterceptionFactory (cleared from user pov and near our initial name)
> > >>- InterceptionEnhancer
> > >>
> > >>
> > >>Feedback and other names are welcome.
> > >>
> > >>
> > >>Antoine
> > >>______________________________ _________________
> > >>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.
> > >>
> > >
> > >
> > >_______________________________________________
> > >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/20161108/efa4663c/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Tue, 8 Nov 2016 14:28:27 +0100
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=
> 7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-11-08 14:24 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net
> >:
>
> > +1 for InterceptionFactory as well. I change my PR with this name.
> >
> > Romain, for the record, mentioning "business method invocation" and
> > paragraph 7.2 is the only mean to bind this feature to the spec without
> > mentioning implementation specific stuff like proxies. That's why the
> > javadoc and text for this new section lack clarity. In other word we
> lack a
> > simple name for instances on which "methods invocation" are "business
> > methods invocation".
> >
> >
> Agree and it fits the spec but since EJB I never heard any developer (not
> developping weld or openwebbeans) using this term so for the API it would
> be rude IMHO - was the point, nothing more.
>
>
> > Antoine
> >
> > On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de> wrote:
> >
> >> InterceptionFactory sounds fine for me.
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> >> rmannibucau at gmail.com> wrote:
> >> >
> >> >Hello Antoine,
> >> >
> >> >
> >> >concurrency-utilities use ContextFactory for something pretty close (a
> >> proxying adding spec features over invocations) which is less
> "cglib-like"
> >> than "Enhancer" so I'd like to keep Factory. In the list
> >> InterceptionFactory looks clear enough. We neevr speak of business
> method
> >> anymore I think so it would add a difficulty for something very useful
> to
> >> go that deep in the naming I think.
> >> >
> >> >
> >> >
> >> >Romain Manni-Bucau
> >> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >> >
> >> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
> >> antoine at sabot-durand.net>:
> >> >
> >> >Hi all,
> >> >>
> >> >>
> >> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> >> cdi/pull/315), I removed all reference to proxies in Javadoc and spec
> doc
> >> following various feedback.
> >> >>So now the name of the interface is the only one dealing with Proxy,
> so
> >> we really need to find it a new name.
> >> >>I listed some proposal in PR 315:
> >> >>- InstanceEnhancer (short but not very clear)
> >> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is
> it
> >> clear from user pov?)
> >> >>- InterceptionFactory (cleared from user pov and near our initial
> name)
> >> >>- InterceptionEnhancer
> >> >>
> >> >>
> >> >>Feedback and other names are welcome.
> >> >>
> >> >>
> >> >>Antoine
> >> >>______________________________ _________________
> >> >>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.
> >> >>
> >> >
> >> >
> >> >_______________________________________________
> >> >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/20161108/c6e8a845/attachment.html
>
> ------------------------------
>
> _______________________________________________
> 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 72, Issue 5
> **************************************
>
>
> ------------------------------
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the
> sender immediately by return e-mail, delete this message, and destroy all
> physical and electronic copies. Thank you.
> _______________________________________________
> 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/20161108/14b2c1e2/attachment-0001.html 

From john.ament at spartasystems.com  Tue Nov  8 12:06:47 2016
From: john.ament at spartasystems.com (John Ament)
Date: Tue, 8 Nov 2016 17:06:47 +0000
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <CABu-YBRC3kn8TXWc3hjt3VeMrYDwMjyejzsxfRBpDFKYNnyDdA@mail.gmail.com>
References: <CAAGawe0GNLRfnXY1rhaoBwzR0_eWFJvQHSrQ4WcAX8_qMLnCRw@mail.gmail.com>
	<CY4PR04MB0486DD2E2DB8705A4ABB995E98A60@CY4PR04MB0486.namprd04.prod.outlook.com>,
	<CABu-YBRC3kn8TXWc3hjt3VeMrYDwMjyejzsxfRBpDFKYNnyDdA@mail.gmail.com>
Message-ID: <CY4PR04MB04864457DF31C373E5F24C8298A60@CY4PR04MB0486.namprd04.prod.outlook.com>

I can't think of any, just want to make sure no one else was.


________________________________
From: Antoine Sabot-Durand <antoine at sabot-durand.net>
Sent: Tuesday, November 8, 2016 12:04 PM
To: John Ament; cdi-dev
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory


On Tue, Nov 8, 2016 at 2:38 PM John Ament <john.ament at spartasystems.com<mailto:john.ament at spartasystems.com>> wrote:

If the only use case is for inceptors, I agree to InterceptionFactory.

What other use case you are thinking of John?




________________________________
From: cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org> <cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Werner Keil <werner.keil at gmail.com<mailto:werner.keil at gmail.com>>
Sent: Tuesday, November 8, 2016 8:30 AM
To: cdi-dev

Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
+1 for InterceptionFactory, too.
It sounds simpler.

Werner


On Tue, Nov 8, 2016 at 2:29 PM, <cdi-dev-request at lists.jboss.org<mailto:cdi-dev-request at lists.jboss.org>> wrote:
Send cdi-dev mailing list submissions to
        cdi-dev at lists.jboss.org<mailto: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<mailto:cdi-dev-request at lists.jboss.org>

You can reach the person managing the list at
        cdi-dev-owner at lists.jboss.org<mailto: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: Finding a new name for InterceptorProxyFactory (Mark Struberg)
   2. Re: Finding a new name for InterceptorProxyFactory
      (Antoine Sabot-Durand)
   3. Re: Finding a new name for InterceptorProxyFactory
      (Romain Manni-Bucau)


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

Message: 1
Date: Mon, 7 Nov 2016 16:58:04 +0000 (UTC)
From: Mark Struberg <struberg at yahoo.de<mailto:struberg at yahoo.de>>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Romain Manni-Bucau <rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>>, Antoine Sabot-Durand
        <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>
Cc: cdi-dev <cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>>
Message-ID: <421014798.1728352.1478537884045 at mail.yahoo.com<mailto:421014798.1728352.1478537884045 at mail.yahoo.com>>
Content-Type: text/plain; charset=UTF-8

InterceptionFactory sounds fine for me.


LieGrue,
strub



On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>> wrote:
>
>Hello Antoine,
>
>
>concurrency-utilities use ContextFactory for something pretty close (a proxying adding spec features over invocations) which is less "cglib-like" than "Enhancer" so I'd like to keep Factory. In the list InterceptionFactory looks clear enough. We neevr speak of business method anymore I think so it would add a difficulty for something very useful to go that deep in the naming I think.
>
>
>
>Romain Manni-Bucau
>@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>
>2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>:
>
>Hi all,
>>
>>
>>In my last review for CDI-580 (https://github.com/cdi-spec/ cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc following various feedback.
>>So now the name of the interface is the only one dealing with Proxy, so we really need to find it a new name.
>>I listed some proposal in PR 315:
>>- InstanceEnhancer (short but not very clear)
>>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it clear from user pov?)
>>- InterceptionFactory (cleared from user pov and near our initial name)
>>- InterceptionEnhancer
>>
>>
>>Feedback and other names are welcome.
>>
>>
>>Antoine
>>______________________________ _________________
>>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<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.
>
>


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

Message: 2
Date: Tue, 08 Nov 2016 13:24:28 +0000
From: Antoine Sabot-Durand <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Mark Struberg <struberg at yahoo.de<mailto:struberg at yahoo.de>>,  Romain Manni-Bucau
        <rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>>
Cc: cdi-dev <cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>>
Message-ID:
        <CABu-YBRhd8UYWck4-fibda_Ykoh-n=u_Xfhs48tUcBCOw_TiAw at mail.gmail.com<mailto:u_Xfhs48tUcBCOw_TiAw at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

+1 for InterceptionFactory as well. I change my PR with this name.

Romain, for the record, mentioning "business method invocation" and
paragraph 7.2 is the only mean to bind this feature to the spec without
mentioning implementation specific stuff like proxies. That's why the
javadoc and text for this new section lack clarity. In other word we lack a
simple name for instances on which "methods invocation" are "business
methods invocation".

Antoine

On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de<mailto:struberg at yahoo.de>> wrote:

> InterceptionFactory sounds fine for me.
>
>
> LieGrue,
> strub
>
>
>
> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>> wrote:
> >
> >Hello Antoine,
> >
> >
> >concurrency-utilities use ContextFactory for something pretty close (a
> proxying adding spec features over invocations) which is less "cglib-like"
> than "Enhancer" so I'd like to keep Factory. In the list
> InterceptionFactory looks clear enough. We neevr speak of business method
> anymore I think so it would add a difficulty for something very useful to
> go that deep in the naming I think.
> >
> >
> >
> >Romain Manni-Bucau
> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>
> >:
> >
> >Hi all,
> >>
> >>
> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
> following various feedback.
> >>So now the name of the interface is the only one dealing with Proxy, so
> we really need to find it a new name.
> >>I listed some proposal in PR 315:
> >>- InstanceEnhancer (short but not very clear)
> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
> clear from user pov?)
> >>- InterceptionFactory (cleared from user pov and near our initial name)
> >>- InterceptionEnhancer
> >>
> >>
> >>Feedback and other names are welcome.
> >>
> >>
> >>Antoine
> >>______________________________ _________________
> >>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<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.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/efa4663c/attachment-0001.html

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

Message: 3
Date: Tue, 8 Nov 2016 14:28:27 +0100
From: Romain Manni-Bucau <rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Antoine Sabot-Durand <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>
Cc: cdi-dev <cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>>
Message-ID:
        <CACLE=7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com<mailto:7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

2016-11-08 14:24 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>:

> +1 for InterceptionFactory as well. I change my PR with this name.
>
> Romain, for the record, mentioning "business method invocation" and
> paragraph 7.2 is the only mean to bind this feature to the spec without
> mentioning implementation specific stuff like proxies. That's why the
> javadoc and text for this new section lack clarity. In other word we lack a
> simple name for instances on which "methods invocation" are "business
> methods invocation".
>
>
Agree and it fits the spec but since EJB I never heard any developer (not
developping weld or openwebbeans) using this term so for the API it would
be rude IMHO - was the point, nothing more.


> Antoine
>
> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de<mailto:struberg at yahoo.de>> wrote:
>
>> InterceptionFactory sounds fine for me.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
>> rmannibucau at gmail.com<mailto:rmannibucau at gmail.com>> wrote:
>> >
>> >Hello Antoine,
>> >
>> >
>> >concurrency-utilities use ContextFactory for something pretty close (a
>> proxying adding spec features over invocations) which is less "cglib-like"
>> than "Enhancer" so I'd like to keep Factory. In the list
>> InterceptionFactory looks clear enough. We neevr speak of business method
>> anymore I think so it would add a difficulty for something very useful to
>> go that deep in the naming I think.
>> >
>> >
>> >
>> >Romain Manni-Bucau
>> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> >
>> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
>> antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>:
>> >
>> >Hi all,
>> >>
>> >>
>> >>In my last review for CDI-580 (https://github.com/cdi-spec/
>> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
>> following various feedback.
>> >>So now the name of the interface is the only one dealing with Proxy, so
>> we really need to find it a new name.
>> >>I listed some proposal in PR 315:
>> >>- InstanceEnhancer (short but not very clear)
>> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
>> clear from user pov?)
>> >>- InterceptionFactory (cleared from user pov and near our initial name)
>> >>- InterceptionEnhancer
>> >>
>> >>
>> >>Feedback and other names are welcome.
>> >>
>> >>
>> >>Antoine
>> >>______________________________ _________________
>> >>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<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.
>> >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/c6e8a845/attachment.html

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

_______________________________________________
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.

End of cdi-dev Digest, Vol 72, Issue 5
**************************************

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
_______________________________________________
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.
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/4c9a19d7/attachment-0001.html 

From issues at jboss.org  Tue Nov  8 12:19:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 8 Nov 2016 12:19:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in
 typesafe resolution mechanism
In-Reply-To: <JIRA.12552145.1410771375000@Atlassian.JIRA>
References: <JIRA.12552145.1410771375000@Atlassian.JIRA>
	<JIRA.12552145.1410771375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552145.1410771375000.26450.1478625540474@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ament reassigned CDI-471:
------------------------------

    Assignee: John Ament


> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
>                 Key: CDI-471
>                 URL: https://issues.jboss.org/browse/CDI-471
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>            Reporter: Antonin Stefanutti
>            Assignee: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 .Final
>
>
> As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism.
> For example, one could write:
> {code}
> @Qualifier
> @Repeatable(ContextNames.class)
> public interface @ContextName {
>     String value;
> }
> public @interface ContextNames {
>     ContextName[] value();
> }
> {code}
> And then:
> {code}
> @ContextName("ctx1")
> class CamelContext1 {
> }
> @ContextName("ctx2")
> class CamelContext2 {
> }
> @Uri("")
> @Produces
> @ContextName("ctx1")
> @ContextName("ctx2")
> static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) {
> }
> {code}
> That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies.
> Support of the annotation container / list for backward compatibility could be provided as well.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Nov  9 03:06:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 9 Nov 2016 03:06:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-644) Link formatting in the
	specification text
In-Reply-To: <JIRA.12660350.1478678726000@Atlassian.JIRA>
References: <JIRA.12660350.1478678726000@Atlassian.JIRA>
	<JIRA.12660350.1478678726013@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660350.1478678726000.29147.1478678760421@Atlassian.JIRA>

Tomas Remes created CDI-644:
-------------------------------

             Summary: Link formatting in the specification text 
                 Key: CDI-644
                 URL: https://issues.jboss.org/browse/CDI-644
             Project: CDI Specification Issues
          Issue Type: Feature Request
            Reporter: Tomas Remes


In the last version of specification there was good use of link formatting in the text. It looks as follows: 
{noformat}
Section 2.4.1, ?Built-in scope types? 
{noformat}
I would like to keep this format (especialy the prefix "Section x.x.x") also in the new version because I think it's more legible.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Nov  9 05:39:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 9 Nov 2016 05:39:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.30979.1478687940866@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CDI-527 started by Antoine Sabot-Durand.
------------------------------------------------
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: F2F2016
>             Fix For: 2.0 .Final
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov 10 09:44:00 2016
From: issues at jboss.org (Antonin Stefanutti (JIRA))
Date: Thu, 10 Nov 2016 09:44:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeating annotations in
	CDI SPI
In-Reply-To: <JIRA.12551806.1410430982000@Atlassian.JIRA>
References: <JIRA.12551806.1410430982000@Atlassian.JIRA>
	<JIRA.12551806.1410430982000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551806.1410430982000.42096.1478789040808@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antonin Stefanutti updated CDI-460:
-----------------------------------
    Description: 
In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations:

{{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}},
{{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}},
{{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}.

Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection.

Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Though, that's important to have that support explicitly stated and specified in CDI.

Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification.

That applies as well for {{EventMetadata.getQualifiers}} in _read-only_.

While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification.

  was:
In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations:

{{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}},
{{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}},
{{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}.

Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection.

Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI.

Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification.

That applies as well for {{EventMetadata.getQualifiers}} in _read-only_.

While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification.



> Support repeating annotations in CDI SPI
> ----------------------------------------
>
>                 Key: CDI-460
>                 URL: https://issues.jboss.org/browse/CDI-460
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Antonin Stefanutti
>
> In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations:
> {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}},
> {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}},
> {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}.
> Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection.
> Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Though, that's important to have that support explicitly stated and specified in CDI.
> Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification.
> That applies as well for {{EventMetadata.getQualifiers}} in _read-only_.
> While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From antonin at stefanutti.fr  Thu Nov 10 13:03:04 2016
From: antonin at stefanutti.fr (Antonin Stefanutti)
Date: Thu, 10 Nov 2016 18:03:04 +0000
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)
Message-ID: <BF5895E1-1E92-4E88-ADEF-C7D290D55585@stefanutti.fr>

Hi,

While CDI-471 (Support repeating qualifiers in typesafe resolution mechanism) targets CDI 2.0, related issue CDI-460 (Support repeating annotations in CDI SPI) doesn?t have any fix version defined. Can it be implied that CDI-460 will be addressed with CDI-471 or is it intentional left undefined? IMHO, it?d be important to have CDI-460 delivered as part of CDI 2.0 as well to bring a consistent support for repeating annotations in CDI.

Thanks,
Antonin 



From john.ament at spartasystems.com  Thu Nov 10 14:22:26 2016
From: john.ament at spartasystems.com (John Ament)
Date: Thu, 10 Nov 2016 19:22:26 +0000
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)
In-Reply-To: <BF5895E1-1E92-4E88-ADEF-C7D290D55585@stefanutti.fr>
References: <BF5895E1-1E92-4E88-ADEF-C7D290D55585@stefanutti.fr>
Message-ID: <CY4PR04MB0486B599838DB6ED5AC65D7398B80@CY4PR04MB0486.namprd04.prod.outlook.com>

Basically the spec text change to support this is "repeating annotations work as qualifiers.  they continue to act as inclusive, meaning those repeated annotations follow the same resolution strategy as any other qualifiers."


Do you agree?


________________________________
From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on behalf of Antonin Stefanutti <antonin at stefanutti.fr>
Sent: Thursday, November 10, 2016 1:03 PM
To: cdi-dev at lists.jboss.org
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)

Hi,

While CDI-471 (Support repeating qualifiers in typesafe resolution mechanism) targets CDI 2.0, related issue CDI-460 (Support repeating annotations in CDI SPI) doesn't have any fix version defined. Can it be implied that CDI-460 will be addressed with CDI-471 or is it intentional left undefined? IMHO, it'd be important to have CDI-460 delivered as part of CDI 2.0 as well to bring a consistent support for repeating annotations in CDI.

Thanks,
Antonin


_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.




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.
Apache License, Version 2.0<http://www.apache.org/licenses/LICENSE-2.0.html>
www.apache.org
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.


________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161110/e1bce522/attachment-0001.html 

From issues at jboss.org  Fri Nov 11 06:47:00 2016
From: issues at jboss.org (Antonin Stefanutti (JIRA))
Date: Fri, 11 Nov 2016 06:47:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeating annotations in
	CDI SPI
In-Reply-To: <JIRA.12551806.1410430982000@Atlassian.JIRA>
References: <JIRA.12551806.1410430982000@Atlassian.JIRA>
	<JIRA.12551806.1410430982000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551806.1410430982000.49113.1478864820243@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antonin Stefanutti updated CDI-460:
-----------------------------------
    Fix Version/s: 2.0 .Final


> Support repeating annotations in CDI SPI
> ----------------------------------------
>
>                 Key: CDI-460
>                 URL: https://issues.jboss.org/browse/CDI-460
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Antonin Stefanutti
>             Fix For: 2.0 .Final
>
>
> In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations:
> {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}},
> {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}},
> {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}.
> Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection.
> Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Though, that's important to have that support explicitly stated and specified in CDI.
> Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification.
> That applies as well for {{EventMetadata.getQualifiers}} in _read-only_.
> While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From antonin at stefanutti.fr  Fri Nov 11 06:48:46 2016
From: antonin at stefanutti.fr (Antonin Stefanutti)
Date: Fri, 11 Nov 2016 11:48:46 +0000
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)
In-Reply-To: <CY4PR04MB0486B599838DB6ED5AC65D7398B80@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <BF5895E1-1E92-4E88-ADEF-C7D290D55585@stefanutti.fr>
	<CY4PR04MB0486B599838DB6ED5AC65D7398B80@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <7C127D14-7DBF-4384-B4EE-0863A4857DD8@stefanutti.fr>

I agree with the spec change, which is the essence of CDI-460. So I guess that this spec change implies percolating it into the CDI SPI as well, so I can infer CDI-471 is part of CDI 2.0.

On 10 Nov 2016, at 20:22, John Ament <john.ament at spartasystems.com<mailto:john.ament at spartasystems.com>> wrote:

Basically the spec text change to support this is "repeating annotations work as qualifiers.  they continue to act as inclusive, meaning those repeated annotations follow the same resolution strategy as any other qualifiers."

Do you agree?


________________________________
From: cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org> <cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Antonin Stefanutti <antonin at stefanutti.fr<mailto:antonin at stefanutti.fr>>
Sent: Thursday, November 10, 2016 1:03 PM
To: cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)

Hi,

While CDI-471 (Support repeating qualifiers in typesafe resolution mechanism) targets CDI 2.0, related issue CDI-460 (Support repeating annotations in CDI SPI) doesn?t have any fix version defined. Can it be implied that CDI-460 will be addressed with CDI-471 or is it intentional left undefined? IMHO, it?d be important to have CDI-460 delivered as part of CDI 2.0 as well to bring a consistent support for repeating annotations in CDI.

Thanks,
Antonin


_______________________________________________
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
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org<http://lists.jboss.org/>
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.




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.
Apache License, Version 2.0<http://www.apache.org/licenses/LICENSE-2.0.html>
www.apache.org<http://www.apache.org/>
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.


________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

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

From john.ament at spartasystems.com  Fri Nov 11 07:40:37 2016
From: john.ament at spartasystems.com (John Ament)
Date: Fri, 11 Nov 2016 12:40:37 +0000
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)
In-Reply-To: <7C127D14-7DBF-4384-B4EE-0863A4857DD8@stefanutti.fr>
References: <BF5895E1-1E92-4E88-ADEF-C7D290D55585@stefanutti.fr>
	<CY4PR04MB0486B599838DB6ED5AC65D7398B80@CY4PR04MB0486.namprd04.prod.outlook.com>,
	<7C127D14-7DBF-4384-B4EE-0863A4857DD8@stefanutti.fr>
Message-ID: <CY4PR04MB0486ABB3196BFCAAC89FAB4098BB0@CY4PR04MB0486.namprd04.prod.outlook.com>

Mind if I mark it as a duplicate then?  I usually prefer to mark the higher numbers, but there's more info in 471.


John


________________________________
From: Antonin Stefanutti <antonin at stefanutti.fr>
Sent: Friday, November 11, 2016 6:48 AM
To: John Ament
Cc: cdi-dev at lists.jboss.org
Subject: Re: Repeating annotations support (CDI-460 and CDI-471)

I agree with the spec change, which is the essence of CDI-460. So I guess that this spec change implies percolating it into the CDI SPI as well, so I can infer CDI-471 is part of CDI 2.0.

On 10 Nov 2016, at 20:22, John Ament <john.ament at spartasystems.com<mailto:john.ament at spartasystems.com>> wrote:

Basically the spec text change to support this is "repeating annotations work as qualifiers.  they continue to act as inclusive, meaning those repeated annotations follow the same resolution strategy as any other qualifiers."

Do you agree?


________________________________
From: cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org> <cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Antonin Stefanutti <antonin at stefanutti.fr<mailto:antonin at stefanutti.fr>>
Sent: Thursday, November 10, 2016 1:03 PM
To: cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)

Hi,

While CDI-471 (Support repeating qualifiers in typesafe resolution mechanism) targets CDI 2.0, related issue CDI-460 (Support repeating annotations in CDI SPI) doesn't have any fix version defined. Can it be implied that CDI-460 will be addressed with CDI-471 or is it intentional left undefined? IMHO, it'd be important to have CDI-460 delivered as part of CDI 2.0 as well to bring a consistent support for repeating annotations in CDI.

Thanks,
Antonin


_______________________________________________
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
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org<http://lists.jboss.org/>
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.




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.
Apache License, Version 2.0<http://www.apache.org/licenses/LICENSE-2.0.html>
www.apache.org<http://www.apache.org/>
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.


________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161111/bff5a374/attachment-0001.html 

From antonin at stefanutti.fr  Fri Nov 11 08:50:09 2016
From: antonin at stefanutti.fr (Antonin Stefanutti)
Date: Fri, 11 Nov 2016 13:50:09 +0000
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)
In-Reply-To: <CY4PR04MB0486ABB3196BFCAAC89FAB4098BB0@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <BF5895E1-1E92-4E88-ADEF-C7D290D55585@stefanutti.fr>
	<CY4PR04MB0486B599838DB6ED5AC65D7398B80@CY4PR04MB0486.namprd04.prod.outlook.com>
	<7C127D14-7DBF-4384-B4EE-0863A4857DD8@stefanutti.fr>
	<CY4PR04MB0486ABB3196BFCAAC89FAB4098BB0@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <C49F9F5C-644D-4E15-B9BB-8DA34D49BA23@stefanutti.fr>


On 11 Nov 2016, at 13:40, John Ament <john.ament at spartasystems.com<mailto:john.ament at spartasystems.com>> wrote:

Mind if I mark it as a duplicate then?  I usually prefer to mark the higher numbers, but there's more info in 471.

Sure, go for it. Then maybe renaming 471 to ?Support repeating qualifiers" short.



________________________________
From: Antonin Stefanutti <antonin at stefanutti.fr<mailto:antonin at stefanutti.fr>>
Sent: Friday, November 11, 2016 6:48 AM
To: John Ament
Cc: cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>
Subject: Re: Repeating annotations support (CDI-460 and CDI-471)

I agree with the spec change, which is the essence of CDI-460. So I guess that this spec change implies percolating it into the CDI SPI as well, so I can infer CDI-471 is part of CDI 2.0.

On 10 Nov 2016, at 20:22, John Ament <john.ament at spartasystems.com<mailto:john.ament at spartasystems.com>> wrote:

Basically the spec text change to support this is "repeating annotations work as qualifiers.  they continue to act as inclusive, meaning those repeated annotations follow the same resolution strategy as any other qualifiers."

Do you agree?


________________________________
From: cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org> <cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Antonin Stefanutti <antonin at stefanutti.fr<mailto:antonin at stefanutti.fr>>
Sent: Thursday, November 10, 2016 1:03 PM
To: cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)

Hi,

While CDI-471 (Support repeating qualifiers in typesafe resolution mechanism) targets CDI 2.0, related issue CDI-460 (Support repeating annotations in CDI SPI) doesn?t have any fix version defined. Can it be implied that CDI-460 will be addressed with CDI-471 or is it intentional left undefined? IMHO, it?d be important to have CDI-460 delivered as part of CDI 2.0 as well to bring a consistent support for repeating annotations in CDI.

Thanks,
Antonin


_______________________________________________
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
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org<http://lists.jboss.org/>
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.




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.
Apache License, Version 2.0<http://www.apache.org/licenses/LICENSE-2.0.html>
www.apache.org<http://www.apache.org/>
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.


________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

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

From issues at jboss.org  Fri Nov 11 08:57:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 11 Nov 2016 08:57:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in
 typesafe resolution mechanism
In-Reply-To: <JIRA.12552145.1410771375000@Atlassian.JIRA>
References: <JIRA.12552145.1410771375000@Atlassian.JIRA>
	<JIRA.12552145.1410771375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552145.1410771375000.50543.1478872620372@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CDI-471 started by John Ament.
--------------------------------------
> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
>                 Key: CDI-471
>                 URL: https://issues.jboss.org/browse/CDI-471
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>            Reporter: Antonin Stefanutti
>            Assignee: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 .Final
>
>
> As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism.
> For example, one could write:
> {code}
> @Qualifier
> @Repeatable(ContextNames.class)
> public interface @ContextName {
>     String value;
> }
> public @interface ContextNames {
>     ContextName[] value();
> }
> {code}
> And then:
> {code}
> @ContextName("ctx1")
> class CamelContext1 {
> }
> @ContextName("ctx2")
> class CamelContext2 {
> }
> @Uri("")
> @Produces
> @ContextName("ctx1")
> @ContextName("ctx2")
> static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) {
> }
> {code}
> That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies.
> Support of the annotation container / list for backward compatibility could be provided as well.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Nov 11 08:57:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 11 Nov 2016 08:57:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers
In-Reply-To: <JIRA.12552145.1410771375000@Atlassian.JIRA>
References: <JIRA.12552145.1410771375000@Atlassian.JIRA>
	<JIRA.12552145.1410771375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552145.1410771375000.50550.1478872620528@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ament updated CDI-471:
---------------------------
    Summary: Support repeating qualifiers  (was: Support repeating qualifiers in typesafe resolution mechanism)


> Support repeating qualifiers
> ----------------------------
>
>                 Key: CDI-471
>                 URL: https://issues.jboss.org/browse/CDI-471
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>            Reporter: Antonin Stefanutti
>            Assignee: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 .Final
>
>
> As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism.
> For example, one could write:
> {code}
> @Qualifier
> @Repeatable(ContextNames.class)
> public interface @ContextName {
>     String value;
> }
> public @interface ContextNames {
>     ContextName[] value();
> }
> {code}
> And then:
> {code}
> @ContextName("ctx1")
> class CamelContext1 {
> }
> @ContextName("ctx2")
> class CamelContext2 {
> }
> @Uri("")
> @Produces
> @ContextName("ctx1")
> @ContextName("ctx2")
> static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) {
> }
> {code}
> That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies.
> Support of the annotation container / list for backward compatibility could be provided as well.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Nov 11 08:58:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 11 Nov 2016 08:58:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-460) Support repeating annotations in
	CDI SPI
In-Reply-To: <JIRA.12551806.1410430982000@Atlassian.JIRA>
References: <JIRA.12551806.1410430982000@Atlassian.JIRA>
	<JIRA.12551806.1410430982000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551806.1410430982000.50568.1478872680903@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ament closed CDI-460.
--------------------------
    Resolution: Done


Closing out - CDI-471 is going to encompass the repeating changes required in the spec.

> Support repeating annotations in CDI SPI
> ----------------------------------------
>
>                 Key: CDI-460
>                 URL: https://issues.jboss.org/browse/CDI-460
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Antonin Stefanutti
>             Fix For: 2.0 .Final
>
>
> In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations:
> {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}},
> {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}},
> {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}.
> Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection.
> Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it seems logical to have repeating annotations supported at the CDI SPI level. Though, that's important to have that support explicitly stated and specified in CDI.
> Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification.
> That applies as well for {{EventMetadata.getQualifiers}} in _read-only_.
> While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From john.ament at spartasystems.com  Fri Nov 11 09:19:25 2016
From: john.ament at spartasystems.com (John Ament)
Date: Fri, 11 Nov 2016 14:19:25 +0000
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)
In-Reply-To: <C49F9F5C-644D-4E15-B9BB-8DA34D49BA23@stefanutti.fr>
References: <BF5895E1-1E92-4E88-ADEF-C7D290D55585@stefanutti.fr>
	<CY4PR04MB0486B599838DB6ED5AC65D7398B80@CY4PR04MB0486.namprd04.prod.outlook.com>
	<7C127D14-7DBF-4384-B4EE-0863A4857DD8@stefanutti.fr>
	<CY4PR04MB0486ABB3196BFCAAC89FAB4098BB0@CY4PR04MB0486.namprd04.prod.outlook.com>,
	<C49F9F5C-644D-4E15-B9BB-8DA34D49BA23@stefanutti.fr>
Message-ID: <CY4PR04MB048689ADC47B6E8DC2B6339998BB0@CY4PR04MB0486.namprd04.prod.outlook.com>

I also want to check, I can't think of a reason why any of the following CDI spec related qualifiers should be repeatable:


- BeforeDestroyed

- Destroyed

- Initialized

- Any

- Decorated

- Default

- Intercepted

- New


I can think of reasons why Named should be repeatable, but that's not managed by the CDI spec.


John


________________________________
From: Antonin Stefanutti <antonin at stefanutti.fr>
Sent: Friday, November 11, 2016 8:50 AM
To: John Ament
Cc: cdi-dev at lists.jboss.org
Subject: Re: Repeating annotations support (CDI-460 and CDI-471)


On 11 Nov 2016, at 13:40, John Ament <john.ament at spartasystems.com<mailto:john.ament at spartasystems.com>> wrote:

Mind if I mark it as a duplicate then?  I usually prefer to mark the higher numbers, but there's more info in 471.

Sure, go for it. Then maybe renaming 471 to "Support repeating qualifiers" short.



________________________________
From: Antonin Stefanutti <antonin at stefanutti.fr<mailto:antonin at stefanutti.fr>>
Sent: Friday, November 11, 2016 6:48 AM
To: John Ament
Cc: cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>
Subject: Re: Repeating annotations support (CDI-460 and CDI-471)

I agree with the spec change, which is the essence of CDI-460. So I guess that this spec change implies percolating it into the CDI SPI as well, so I can infer CDI-471 is part of CDI 2.0.

On 10 Nov 2016, at 20:22, John Ament <john.ament at spartasystems.com<mailto:john.ament at spartasystems.com>> wrote:

Basically the spec text change to support this is "repeating annotations work as qualifiers.  they continue to act as inclusive, meaning those repeated annotations follow the same resolution strategy as any other qualifiers."

Do you agree?


________________________________
From: cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org> <cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Antonin Stefanutti <antonin at stefanutti.fr<mailto:antonin at stefanutti.fr>>
Sent: Thursday, November 10, 2016 1:03 PM
To: cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)

Hi,

While CDI-471 (Support repeating qualifiers in typesafe resolution mechanism) targets CDI 2.0, related issue CDI-460 (Support repeating annotations in CDI SPI) doesn't have any fix version defined. Can it be implied that CDI-460 will be addressed with CDI-471 or is it intentional left undefined? IMHO, it'd be important to have CDI-460 delivered as part of CDI 2.0 as well to bring a consistent support for repeating annotations in CDI.

Thanks,
Antonin


_______________________________________________
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
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org<http://lists.jboss.org/>
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.




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.
Apache License, Version 2.0<http://www.apache.org/licenses/LICENSE-2.0.html>
www.apache.org<http://www.apache.org/>
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.


________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161111/6ba2a321/attachment.html 

From antonin at stefanutti.fr  Fri Nov 11 09:49:59 2016
From: antonin at stefanutti.fr (Antonin Stefanutti)
Date: Fri, 11 Nov 2016 14:49:59 +0000
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)
In-Reply-To: <CY4PR04MB048689ADC47B6E8DC2B6339998BB0@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <BF5895E1-1E92-4E88-ADEF-C7D290D55585@stefanutti.fr>
	<CY4PR04MB0486B599838DB6ED5AC65D7398B80@CY4PR04MB0486.namprd04.prod.outlook.com>
	<7C127D14-7DBF-4384-B4EE-0863A4857DD8@stefanutti.fr>
	<CY4PR04MB0486ABB3196BFCAAC89FAB4098BB0@CY4PR04MB0486.namprd04.prod.outlook.com>
	<C49F9F5C-644D-4E15-B9BB-8DA34D49BA23@stefanutti.fr>
	<CY4PR04MB048689ADC47B6E8DC2B6339998BB0@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <D0BD6F17-6865-47C7-B78C-33F2105C9D26@stefanutti.fr>

Sounds reasonable to me.

On 11 Nov 2016, at 15:19, John Ament <john.ament at spartasystems.com<mailto:john.ament at spartasystems.com>> wrote:

I also want to check, I can't think of a reason why any of the following CDI spec related qualifiers should be repeatable:

- BeforeDestroyed
- Destroyed
- Initialized
- Any
- Decorated
- Default
- Intercepted
- New

I can think of reasons why Named should be repeatable, but that's not managed by the CDI spec.

John


________________________________
From: Antonin Stefanutti <antonin at stefanutti.fr<mailto:antonin at stefanutti.fr>>
Sent: Friday, November 11, 2016 8:50 AM
To: John Ament
Cc: cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>
Subject: Re: Repeating annotations support (CDI-460 and CDI-471)


On 11 Nov 2016, at 13:40, John Ament <john.ament at spartasystems.com<mailto:john.ament at spartasystems.com>> wrote:

Mind if I mark it as a duplicate then?  I usually prefer to mark the higher numbers, but there's more info in 471.

Sure, go for it. Then maybe renaming 471 to ?Support repeating qualifiers" short.



________________________________
From: Antonin Stefanutti <antonin at stefanutti.fr<mailto:antonin at stefanutti.fr>>
Sent: Friday, November 11, 2016 6:48 AM
To: John Ament
Cc: cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>
Subject: Re: Repeating annotations support (CDI-460 and CDI-471)

I agree with the spec change, which is the essence of CDI-460. So I guess that this spec change implies percolating it into the CDI SPI as well, so I can infer CDI-471 is part of CDI 2.0.

On 10 Nov 2016, at 20:22, John Ament <john.ament at spartasystems.com<mailto:john.ament at spartasystems.com>> wrote:

Basically the spec text change to support this is "repeating annotations work as qualifiers.  they continue to act as inclusive, meaning those repeated annotations follow the same resolution strategy as any other qualifiers."

Do you agree?


________________________________
From: cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org> <cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Antonin Stefanutti <antonin at stefanutti.fr<mailto:antonin at stefanutti.fr>>
Sent: Thursday, November 10, 2016 1:03 PM
To: cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>
Subject: [cdi-dev] Repeating annotations support (CDI-460 and CDI-471)

Hi,

While CDI-471 (Support repeating qualifiers in typesafe resolution mechanism) targets CDI 2.0, related issue CDI-460 (Support repeating annotations in CDI SPI) doesn?t have any fix version defined. Can it be implied that CDI-460 will be addressed with CDI-471 or is it intentional left undefined? IMHO, it?d be important to have CDI-460 delivered as part of CDI 2.0 as well to bring a consistent support for repeating annotations in CDI.

Thanks,
Antonin


_______________________________________________
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
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org<http://lists.jboss.org/>
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.




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.
Apache License, Version 2.0<http://www.apache.org/licenses/LICENSE-2.0.html>
www.apache.org<http://www.apache.org/>
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.


________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161111/93c01c07/attachment-0001.html 

From john.ament at spartasystems.com  Fri Nov 11 11:01:24 2016
From: john.ament at spartasystems.com (John Ament)
Date: Fri, 11 Nov 2016 16:01:24 +0000
Subject: [cdi-dev] Any qualms with merging CDI-490?
Message-ID: <CY4PR04MB0486C5A6B930A0BFD0587BA398BB0@CY4PR04MB0486.namprd04.prod.outlook.com>

Just wondering - is everyone good with this change? https://github.com/cdi-spec/cdi/pull/327 If so, can it be merged?

[https://avatars3.githubusercontent.com/u/108167?v=3&s=400]<https://github.com/cdi-spec/cdi/pull/327>

CDI-490 Clarify what happens when an interceptor is enabled twice. by johnament ? Pull Request #327 ? cdi-spec/cdi<https://github.com/cdi-spec/cdi/pull/327>
github.com
Based on F2F feedback, clarifying what happens when its in both places.



________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161111/6970746a/attachment.html 

From issues at jboss.org  Fri Nov 11 15:25:00 2016
From: issues at jboss.org (Laird Nelson (JIRA))
Date: Fri, 11 Nov 2016 15:25:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-645) Links in CDI EDR2 javadoc go to
 Java SE 6; should go to Java SE 8
In-Reply-To: <JIRA.12661060.1478895867000@Atlassian.JIRA>
References: <JIRA.12661060.1478895867000@Atlassian.JIRA>
	<JIRA.12661060.1478895867356@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661060.1478895867000.54558.1478895900015@Atlassian.JIRA>

Laird Nelson created CDI-645:
--------------------------------

             Summary: Links in CDI EDR2 javadoc go to Java SE 6; should go to Java SE 8
                 Key: CDI-645
                 URL: https://issues.jboss.org/browse/CDI-645
             Project: CDI Specification Issues
          Issue Type: Bug
          Components: Javadoc and API
    Affects Versions: 2.0-EDR2
            Reporter: Laird Nelson
            Priority: Trivial


The links in the CDI EDR2 javadocs go to Java SE 6, not Java SE 8.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mjremijan at yahoo.com  Sun Nov 13 23:43:27 2016
From: mjremijan at yahoo.com (Michael Remijan)
Date: Mon, 14 Nov 2016 04:43:27 +0000 (UTC)
Subject: [cdi-dev] Think I found bug with interceptor
References: <871484121.2996663.1479098607794.ref@mail.yahoo.com>
Message-ID: <871484121.2996663.1479098607794@mail.yahoo.com>

Greetings,
I am using:
<dependency>
??? <groupId>org.jboss.weld.se</groupId>
??? <artifactId>weld-se-core</artifactId>
??? <version>3.0.0.Alpha15</version>
</dependency>
and I think I found a bug with the interceptors.? I wanted to ask about it first before I put it in Jira.
Basically, the interceptor I have defined works great if I annotate a method called by the CDI container, which in my case is an method observing for an event.? I have an ExceptionRetryInterceptor class and an ExceptionRetry annotation.? If I annotate an observer method like this:
@ExceptionRetrypublic void send(
??????? @Observes @Priority(SEND_EMAIL_MESSAGE) EmailEvent evnt
??? ) throws MessagingException, IOException {....}

No problem, everything works fine.? I can see the interceptor code being called in my logs.? 

Now here's the problem,? If I use this annotation on just a regular method which I call myself, it DOES NOT work.? So if I refactor the above example so the annotation is NOT on the observer method called by the container, then the doSend() method below does NOT get wrapped by the interceptor:

public void send(
??????? @Observes @Priority(SEND_EMAIL_MESSAGE) EmailEvent evnt
??? ) throws MessagingException, IOException {????? //....????? doSend();}
@ExceptionRetrypublic void doSend() {....}? // this method does not get wrapped by the interceptor

I'm trying to figure out why. My ExceptionRetryInterceptor class has a @Priority set on it and that works fine.? But I've also tried setting <interceptors> in beans.xml but the doSend(){...} method still doesn't get wrapped.
Any thoughts/help?




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

From issues at jboss.org  Mon Nov 14 03:11:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 14 Nov 2016 03:11:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-646) Fix
 AnnotatedTypeConfigurator.add(),
 AnnotatedMethodConfigurator.add() and AnnotatedParameterConfigurator.add()
 javadoc
In-Reply-To: <JIRA.12661188.1479111015000@Atlassian.JIRA>
References: <JIRA.12661188.1479111015000@Atlassian.JIRA>
	<JIRA.12661188.1479111015217@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661188.1479111015000.56652.1479111060157@Atlassian.JIRA>

Martin Kouba created CDI-646:
--------------------------------

             Summary: Fix AnnotatedTypeConfigurator.add(), AnnotatedMethodConfigurator.add() and AnnotatedParameterConfigurator.add() javadoc
                 Key: CDI-646
                 URL: https://issues.jboss.org/browse/CDI-646
             Project: CDI Specification Issues
          Issue Type: Bug
    Affects Versions: 2.0-EDR2
            Reporter: Martin Kouba
             Fix For: 2.0 .Final


It says: {{Add an annotation to the field.}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 14 03:51:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 14 Nov 2016 03:51:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-481) Introduce
 AnnotatedParameter.getJavaParameter()
In-Reply-To: <JIRA.12552665.1411054766000@Atlassian.JIRA>
References: <JIRA.12552665.1411054766000@Atlassian.JIRA>
	<JIRA.12552665.1411054766000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552665.1411054766000.56783.1479113460205@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-481:
-----------------------------
    Fix Version/s: 2.0 .Final


> Introduce AnnotatedParameter.getJavaParameter()
> -----------------------------------------------
>
>                 Key: CDI-481
>                 URL: https://issues.jboss.org/browse/CDI-481
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Portable Extensions
>            Reporter: Jozef Hartinger
>             Fix For: 2.0 .Final
>
>
> Make it possible to obtain the Java Reflection object representing the parameter. This is in line with
> AnnotatedField.getJavaMember()
> AnnotatedMethod.getJavaMember()
> AnnotatedConstructor.getJavaMember()
> Can be implemented as a default method such as:
> {code:JAVA}
> default Parameter getJavaParameter() {
>         Member member = getDeclaringCallable().getJavaMember();
>         if (!(member instanceof Executable)) {
>             throw new IllegalStateException("Parameter does not belong to an executable " + member);
>         }
>         Executable executable = (Executable) member;
>         return executable.getParameters()[getPosition()];
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 14 03:52:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 14 Nov 2016 03:52:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-481) Introduce
 AnnotatedParameter.getJavaParameter()
In-Reply-To: <JIRA.12552665.1411054766000@Atlassian.JIRA>
References: <JIRA.12552665.1411054766000@Atlassian.JIRA>
	<JIRA.12552665.1411054766000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552665.1411054766000.56793.1479113521438@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reassigned CDI-481:
--------------------------------

    Assignee: Martin Kouba


> Introduce AnnotatedParameter.getJavaParameter()
> -----------------------------------------------
>
>                 Key: CDI-481
>                 URL: https://issues.jboss.org/browse/CDI-481
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Portable Extensions
>            Reporter: Jozef Hartinger
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Make it possible to obtain the Java Reflection object representing the parameter. This is in line with
> AnnotatedField.getJavaMember()
> AnnotatedMethod.getJavaMember()
> AnnotatedConstructor.getJavaMember()
> Can be implemented as a default method such as:
> {code:JAVA}
> default Parameter getJavaParameter() {
>         Member member = getDeclaringCallable().getJavaMember();
>         if (!(member instanceof Executable)) {
>             throw new IllegalStateException("Parameter does not belong to an executable " + member);
>         }
>         Executable executable = (Executable) member;
>         return executable.getParameters()[getPosition()];
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From EMIJIANG at uk.ibm.com  Mon Nov 14 05:41:55 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Mon, 14 Nov 2016 10:41:55 +0000
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <CY4PR04MB04864457DF31C373E5F24C8298A60@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CAAGawe0GNLRfnXY1rhaoBwzR0_eWFJvQHSrQ4WcAX8_qMLnCRw@mail.gmail.com>	<CY4PR04MB0486DD2E2DB8705A4ABB995E98A60@CY4PR04MB0486.namprd04.prod.outlook.com>,
	<CABu-YBRC3kn8TXWc3hjt3VeMrYDwMjyejzsxfRBpDFKYNnyDdA@mail.gmail.com>
	<CY4PR04MB04864457DF31C373E5F24C8298A60@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <OF72082902.E6DF4AA5-ON8025806B.003A67DD-8025806B.003AC7B2@notes.na.collabserv.com>

I looked at the methods under *InterceptionFactory*. To me, it sounds 
better to rename it to InterceptorConfigurator as it has .configure() plus 
it configures or wraps the classes.

Thoughts?

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
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:   John Ament <john.ament at spartasystems.com>
To:     Antoine Sabot-Durand <antoine at sabot-durand.net>, cdi-dev 
<cdi-dev at lists.jboss.org>
Date:   08/11/2016 17:17
Subject:        Re: [cdi-dev] Finding a new name for 
InterceptorProxyFactory
Sent by:        cdi-dev-bounces at lists.jboss.org



I can't think of any, just want to make sure no one else was.



From: Antoine Sabot-Durand <antoine at sabot-durand.net>
Sent: Tuesday, November 8, 2016 12:04 PM
To: John Ament; cdi-dev
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory 
 

On Tue, Nov 8, 2016 at 2:38 PM John Ament <john.ament at spartasystems.com> 
wrote:
If the only use case is for inceptors, I agree to InterceptionFactory.
What other use case you are thinking of John?


 


From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on 
behalf of Werner Keil <werner.keil at gmail.com>
Sent: Tuesday, November 8, 2016 8:30 AM
To: cdi-dev

Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
+1 for InterceptionFactory, too.
It sounds simpler.

Werner


On Tue, Nov 8, 2016 at 2:29 PM, <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: Finding a new name for InterceptorProxyFactory (Mark Struberg)
   2. Re: Finding a new name for InterceptorProxyFactory
      (Antoine Sabot-Durand)
   3. Re: Finding a new name for InterceptorProxyFactory
      (Romain Manni-Bucau)


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

Message: 1
Date: Mon, 7 Nov 2016 16:58:04 +0000 (UTC)
From: Mark Struberg <struberg at yahoo.de>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Romain Manni-Bucau <rmannibucau at gmail.com>, Antoine Sabot-Durand
        <antoine at sabot-durand.net>
Cc: cdi-dev <cdi-dev at lists.jboss.org>
Message-ID: <421014798.1728352.1478537884045 at mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8

InterceptionFactory sounds fine for me.


LieGrue,
strub



On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
rmannibucau at gmail.com> wrote:
>
>Hello Antoine,
>
>
>concurrency-utilities use ContextFactory for something pretty close (a 
proxying adding spec features over invocations) which is less "cglib-like" 
than "Enhancer" so I'd like to keep Factory. In the list 
InterceptionFactory looks clear enough. We neevr speak of business method 
anymore I think so it would add a difficulty for something very useful to 
go that deep in the naming I think.
>
>
>
>Romain Manni-Bucau
>@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>
>2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net
>:
>
>Hi all,
>>
>>
>>In my last review for CDI-580 (https://github.com/cdi-spec/ 
cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc 
following various feedback.
>>So now the name of the interface is the only one dealing with Proxy, so 
we really need to find it a new name.
>>I listed some proposal in PR 315:
>>- InstanceEnhancer (short but not very clear)
>>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it 
clear from user pov?)
>>- InterceptionFactory (cleared from user pov and near our initial name)
>>- InterceptionEnhancer
>>
>>
>>Feedback and other names are welcome.
>>
>>
>>Antoine
>>______________________________ _________________
>>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.
>>
>
>
>_______________________________________________
>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.
>
>


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

Message: 2
Date: Tue, 08 Nov 2016 13:24:28 +0000
From: Antoine Sabot-Durand <antoine at sabot-durand.net>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Mark Struberg <struberg at yahoo.de>,  Romain Manni-Bucau
        <rmannibucau at gmail.com>
Cc: cdi-dev <cdi-dev at lists.jboss.org>
Message-ID:
        <CABu-YBRhd8UYWck4-fibda_Ykoh-n=
u_Xfhs48tUcBCOw_TiAw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

+1 for InterceptionFactory as well. I change my PR with this name.

Romain, for the record, mentioning "business method invocation" and
paragraph 7.2 is the only mean to bind this feature to the spec without
mentioning implementation specific stuff like proxies. That's why the
javadoc and text for this new section lack clarity. In other word we lack 
a
simple name for instances on which "methods invocation" are "business
methods invocation".

Antoine

On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de> wrote:

> InterceptionFactory sounds fine for me.
>
>
> LieGrue,
> strub
>
>
>
> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> rmannibucau at gmail.com> wrote:
> >
> >Hello Antoine,
> >
> >
> >concurrency-utilities use ContextFactory for something pretty close (a
> proxying adding spec features over invocations) which is less 
"cglib-like"
> than "Enhancer" so I'd like to keep Factory. In the list
> InterceptionFactory looks clear enough. We neevr speak of business 
method
> anymore I think so it would add a difficulty for something very useful 
to
> go that deep in the naming I think.
> >
> >
> >
> >Romain Manni-Bucau
> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
antoine at sabot-durand.net
> >:
> >
> >Hi all,
> >>
> >>
> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> cdi/pull/315), I removed all reference to proxies in Javadoc and spec 
doc
> following various feedback.
> >>So now the name of the interface is the only one dealing with Proxy, 
so
> we really need to find it a new name.
> >>I listed some proposal in PR 315:
> >>- InstanceEnhancer (short but not very clear)
> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is 
it
> clear from user pov?)
> >>- InterceptionFactory (cleared from user pov and near our initial 
name)
> >>- InterceptionEnhancer
> >>
> >>
> >>Feedback and other names are welcome.
> >>
> >>
> >>Antoine
> >>______________________________ _________________
> >>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.
> >>
> >
> >
> >_______________________________________________
> >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/20161108/efa4663c/attachment-0001.html


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

Message: 3
Date: Tue, 8 Nov 2016 14:28:27 +0100
From: Romain Manni-Bucau <rmannibucau at gmail.com>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Antoine Sabot-Durand <antoine at sabot-durand.net>
Cc: cdi-dev <cdi-dev at lists.jboss.org>
Message-ID:
        <CACLE=
7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2016-11-08 14:24 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net
>:

> +1 for InterceptionFactory as well. I change my PR with this name.
>
> Romain, for the record, mentioning "business method invocation" and
> paragraph 7.2 is the only mean to bind this feature to the spec without
> mentioning implementation specific stuff like proxies. That's why the
> javadoc and text for this new section lack clarity. In other word we 
lack a
> simple name for instances on which "methods invocation" are "business
> methods invocation".
>
>
Agree and it fits the spec but since EJB I never heard any developer (not
developping weld or openwebbeans) using this term so for the API it would
be rude IMHO - was the point, nothing more.


> Antoine
>
> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de> wrote:
>
>> InterceptionFactory sounds fine for me.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
>> rmannibucau at gmail.com> wrote:
>> >
>> >Hello Antoine,
>> >
>> >
>> >concurrency-utilities use ContextFactory for something pretty close (a
>> proxying adding spec features over invocations) which is less 
"cglib-like"
>> than "Enhancer" so I'd like to keep Factory. In the list
>> InterceptionFactory looks clear enough. We neevr speak of business 
method
>> anymore I think so it would add a difficulty for something very useful 
to
>> go that deep in the naming I think.
>> >
>> >
>> >
>> >Romain Manni-Bucau
>> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> >
>> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
>> antoine at sabot-durand.net>:
>> >
>> >Hi all,
>> >>
>> >>
>> >>In my last review for CDI-580 (https://github.com/cdi-spec/
>> cdi/pull/315), I removed all reference to proxies in Javadoc and spec 
doc
>> following various feedback.
>> >>So now the name of the interface is the only one dealing with Proxy, 
so
>> we really need to find it a new name.
>> >>I listed some proposal in PR 315:
>> >>- InstanceEnhancer (short but not very clear)
>> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is 
it
>> clear from user pov?)
>> >>- InterceptionFactory (cleared from user pov and near our initial 
name)
>> >>- InterceptionEnhancer
>> >>
>> >>
>> >>Feedback and other names are welcome.
>> >>
>> >>
>> >>Antoine
>> >>______________________________ _________________
>> >>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.
>> >>
>> >
>> >
>> >_______________________________________________
>> >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/20161108/c6e8a845/attachment.html


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

_______________________________________________
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 72, Issue 5
**************************************

NOTICE: This e-mail message and any attachments may contain confidential, 
proprietary, and/or privileged information which should be treated 
accordingly. If you are not the intended recipient, please notify the 
sender immediately by return e-mail, delete this message, and destroy all 
physical and electronic copies. Thank you. 
_______________________________________________
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.
NOTICE: This e-mail message and any attachments may contain confidential, 
proprietary, and/or privileged information which should be treated 
accordingly. If you are not the intended recipient, please notify the 
sender immediately by return e-mail, delete this message, and destroy all 
physical and electronic copies. Thank you. 
_______________________________________________
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.

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/20161114/e079a6c3/attachment-0001.html 

From EMIJIANG at uk.ibm.com  Mon Nov 14 06:10:25 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Mon, 14 Nov 2016 11:10:25 +0000
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <OF72082902.E6DF4AA5-ON8025806B.003A67DD-8025806B.003AC7B2@notes.na.collabserv.com>
References: <CAAGawe0GNLRfnXY1rhaoBwzR0_eWFJvQHSrQ4WcAX8_qMLnCRw@mail.gmail.com>	<CY4PR04MB0486DD2E2DB8705A4ABB995E98A60@CY4PR04MB0486.namprd04.prod.outlook.com>,
	<CABu-YBRC3kn8TXWc3hjt3VeMrYDwMjyejzsxfRBpDFKYNnyDdA@mail.gmail.com>	<CY4PR04MB04864457DF31C373E5F24C8298A60@CY4PR04MB0486.namprd04.prod.outlook.com>
	<OF72082902.E6DF4AA5-ON8025806B.003A67DD-8025806B.003AC7B2@notes.na.collabserv.com>
Message-ID: <OF4B393E3A.EEEAC09D-ON8025806B.003D4519-8025806B.003D635E@notes.na.collabserv.com>

Small correction: InterceptionConfigurator is what I suggested (not 
InterceptorConfigurator).

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
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:   Emily Jiang/UK/IBM at IBMGB
To:     John Ament <john.ament at spartasystems.com>
Cc:     cdi-dev <cdi-dev at lists.jboss.org>
Date:   14/11/2016 10:43
Subject:        Re: [cdi-dev] Finding a new name for 
InterceptorProxyFactory
Sent by:        cdi-dev-bounces at lists.jboss.org



I looked at the methods under *InterceptionFactory*. To me, it sounds 
better to rename it to InterceptorConfigurator as it has .configure() plus 
it configures or wraps the classes. 

Thoughts? 

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead 
 
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:        John Ament <john.ament at spartasystems.com> 
To:        Antoine Sabot-Durand <antoine at sabot-durand.net>, cdi-dev 
<cdi-dev at lists.jboss.org> 
Date:        08/11/2016 17:17 
Subject:        Re: [cdi-dev] Finding a new name for 
InterceptorProxyFactory 
Sent by:        cdi-dev-bounces at lists.jboss.org 



I can't think of any, just want to make sure no one else was. 



From: Antoine Sabot-Durand <antoine at sabot-durand.net>
Sent: Tuesday, November 8, 2016 12:04 PM
To: John Ament; cdi-dev
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory 
  

On Tue, Nov 8, 2016 at 2:38 PM John Ament <john.ament at spartasystems.com> 
wrote: 
If the only use case is for inceptors, I agree to InterceptionFactory. 
What other use case you are thinking of John? 


  


From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on 
behalf of Werner Keil <werner.keil at gmail.com>
Sent: Tuesday, November 8, 2016 8:30 AM
To: cdi-dev 

Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory 
+1 for InterceptionFactory, too. 
It sounds simpler.

Werner 


On Tue, Nov 8, 2016 at 2:29 PM, <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: Finding a new name for InterceptorProxyFactory (Mark Struberg)
  2. Re: Finding a new name for InterceptorProxyFactory
     (Antoine Sabot-Durand)
  3. Re: Finding a new name for InterceptorProxyFactory
     (Romain Manni-Bucau)


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

Message: 1
Date: Mon, 7 Nov 2016 16:58:04 +0000 (UTC)
From: Mark Struberg <struberg at yahoo.de>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Romain Manni-Bucau <rmannibucau at gmail.com>, Antoine Sabot-Durand
       <antoine at sabot-durand.net>
Cc: cdi-dev <cdi-dev at lists.jboss.org>
Message-ID: <421014798.1728352.1478537884045 at mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8

InterceptionFactory sounds fine for me.


LieGrue,
strub



On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
rmannibucau at gmail.com> wrote:
>
>Hello Antoine,
>
>
>concurrency-utilities use ContextFactory for something pretty close (a 
proxying adding spec features over invocations) which is less "cglib-like" 
than "Enhancer" so I'd like to keep Factory. In the list 
InterceptionFactory looks clear enough. We neevr speak of business method 
anymore I think so it would add a difficulty for something very useful to 
go that deep in the naming I think.
>
>
>
>Romain Manni-Bucau
>@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>
>2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net
>:
>
>Hi all,
>>
>>
>>In my last review for CDI-580 (https://github.com/cdi-spec/ 
cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc 
following various feedback.
>>So now the name of the interface is the only one dealing with Proxy, so 
we really need to find it a new name.
>>I listed some proposal in PR 315:
>>- InstanceEnhancer (short but not very clear)
>>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it 
clear from user pov?)
>>- InterceptionFactory (cleared from user pov and near our initial name)
>>- InterceptionEnhancer
>>
>>
>>Feedback and other names are welcome.
>>
>>
>>Antoine
>>______________________________ _________________
>>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.
>>
>
>
>_______________________________________________
>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.
>
>


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

Message: 2
Date: Tue, 08 Nov 2016 13:24:28 +0000
From: Antoine Sabot-Durand <antoine at sabot-durand.net>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Mark Struberg <struberg at yahoo.de>,  Romain Manni-Bucau
       <rmannibucau at gmail.com>
Cc: cdi-dev <cdi-dev at lists.jboss.org>
Message-ID:
       <CABu-YBRhd8UYWck4-fibda_Ykoh-n=u_Xfhs48tUcBCOw_TiAw at mail.gmail.com
>
Content-Type: text/plain; charset="utf-8"

+1 for InterceptionFactory as well. I change my PR with this name.

Romain, for the record, mentioning "business method invocation" and
paragraph 7.2 is the only mean to bind this feature to the spec without
mentioning implementation specific stuff like proxies. That's why the
javadoc and text for this new section lack clarity. In other word we lack 
a
simple name for instances on which "methods invocation" are "business
methods invocation".

Antoine

On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de> wrote:

> InterceptionFactory sounds fine for me.
>
>
> LieGrue,
> strub
>
>
>
> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
> rmannibucau at gmail.com> wrote:
> >
> >Hello Antoine,
> >
> >
> >concurrency-utilities use ContextFactory for something pretty close (a
> proxying adding spec features over invocations) which is less 
"cglib-like"
> than "Enhancer" so I'd like to keep Factory. In the list
> InterceptionFactory looks clear enough. We neevr speak of business 
method
> anymore I think so it would add a difficulty for something very useful 
to
> go that deep in the naming I think.
> >
> >
> >
> >Romain Manni-Bucau
> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
antoine at sabot-durand.net
> >:
> >
> >Hi all,
> >>
> >>
> >>In my last review for CDI-580 (https://github.com/cdi-spec/
> cdi/pull/315), I removed all reference to proxies in Javadoc and spec 
doc
> following various feedback.
> >>So now the name of the interface is the only one dealing with Proxy, 
so
> we really need to find it a new name.
> >>I listed some proposal in PR 315:
> >>- InstanceEnhancer (short but not very clear)
> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is 
it
> clear from user pov?)
> >>- InterceptionFactory (cleared from user pov and near our initial 
name)
> >>- InterceptionEnhancer
> >>
> >>
> >>Feedback and other names are welcome.
> >>
> >>
> >>Antoine
> >>______________________________ _________________
> >>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.
> >>
> >
> >
> >_______________________________________________
> >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/20161108/efa4663c/attachment-0001.html


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

Message: 3
Date: Tue, 8 Nov 2016 14:28:27 +0100
From: Romain Manni-Bucau <rmannibucau at gmail.com>
Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
To: Antoine Sabot-Durand <antoine at sabot-durand.net>
Cc: cdi-dev <cdi-dev at lists.jboss.org>
Message-ID:
       <CACLE=7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com
>
Content-Type: text/plain; charset="utf-8"

2016-11-08 14:24 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net
>:

> +1 for InterceptionFactory as well. I change my PR with this name.
>
> Romain, for the record, mentioning "business method invocation" and
> paragraph 7.2 is the only mean to bind this feature to the spec without
> mentioning implementation specific stuff like proxies. That's why the
> javadoc and text for this new section lack clarity. In other word we 
lack a
> simple name for instances on which "methods invocation" are "business
> methods invocation".
>
>
Agree and it fits the spec but since EJB I never heard any developer (not
developping weld or openwebbeans) using this term so for the API it would
be rude IMHO - was the point, nothing more.


> Antoine
>
> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <struberg at yahoo.de> wrote:
>
>> InterceptionFactory sounds fine for me.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
>> rmannibucau at gmail.com> wrote:
>> >
>> >Hello Antoine,
>> >
>> >
>> >concurrency-utilities use ContextFactory for something pretty close (a
>> proxying adding spec features over invocations) which is less 
"cglib-like"
>> than "Enhancer" so I'd like to keep Factory. In the list
>> InterceptionFactory looks clear enough. We neevr speak of business 
method
>> anymore I think so it would add a difficulty for something very useful 
to
>> go that deep in the naming I think.
>> >
>> >
>> >
>> >Romain Manni-Bucau
>> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> >
>> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
>> antoine at sabot-durand.net>:
>> >
>> >Hi all,
>> >>
>> >>
>> >>In my last review for CDI-580 (https://github.com/cdi-spec/
>> cdi/pull/315), I removed all reference to proxies in Javadoc and spec 
doc
>> following various feedback.
>> >>So now the name of the interface is the only one dealing with Proxy, 
so
>> we really need to find it a new name.
>> >>I listed some proposal in PR 315:
>> >>- InstanceEnhancer (short but not very clear)
>> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is 
it
>> clear from user pov?)
>> >>- InterceptionFactory (cleared from user pov and near our initial 
name)
>> >>- InterceptionEnhancer
>> >>
>> >>
>> >>Feedback and other names are welcome.
>> >>
>> >>
>> >>Antoine
>> >>______________________________ _________________
>> >>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.
>> >>
>> >
>> >
>> >_______________________________________________
>> >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/20161108/c6e8a845/attachment.html


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

_______________________________________________
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 72, Issue 5
************************************** 

NOTICE: This e-mail message and any attachments may contain confidential, 
proprietary, and/or privileged information which should be treated 
accordingly. If you are not the intended recipient, please notify the 
sender immediately by return e-mail, delete this message, and destroy all 
physical and electronic copies. Thank you. 
_______________________________________________
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. 
NOTICE: This e-mail message and any attachments may contain confidential, 
proprietary, and/or privileged information which should be treated 
accordingly. If you are not the intended recipient, please notify the 
sender immediately by return e-mail, delete this message, and destroy all 
physical and electronic copies. Thank you. 
_______________________________________________
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. 

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.

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/20161114/1d531f23/attachment-0001.html 

From issues at jboss.org  Mon Nov 14 08:50:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 14 Nov 2016 08:50:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-645) Links in CDI EDR2 javadoc go to
 Java SE 6; should go to Java SE 8
In-Reply-To: <JIRA.12661060.1478895867000@Atlassian.JIRA>
References: <JIRA.12661060.1478895867000@Atlassian.JIRA>
	<JIRA.12661060.1478895867000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661060.1478895867000.61283.1479131400658@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes reassigned CDI-645:
-------------------------------

    Assignee: Tomas Remes


> Links in CDI EDR2 javadoc go to Java SE 6; should go to Java SE 8
> -----------------------------------------------------------------
>
>                 Key: CDI-645
>                 URL: https://issues.jboss.org/browse/CDI-645
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 2.0-EDR2
>            Reporter: Laird Nelson
>            Assignee: Tomas Remes
>            Priority: Trivial
>
> The links in the CDI EDR2 javadocs go to Java SE 6, not Java SE 8.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 14 11:09:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Mon, 14 Nov 2016 11:09:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-647) Introduce a parent pom for CDI
In-Reply-To: <JIRA.12661482.1479139692000@Atlassian.JIRA>
References: <JIRA.12661482.1479139692000@Atlassian.JIRA>
	<JIRA.12661482.1479139692681@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661482.1479139692000.64044.1479139740101@Atlassian.JIRA>

John Ament created CDI-647:
------------------------------

             Summary: Introduce a parent pom for CDI
                 Key: CDI-647
                 URL: https://issues.jboss.org/browse/CDI-647
             Project: CDI Specification Issues
          Issue Type: Feature Request
    Affects Versions: 2.0-EDR2
            Reporter: John Ament


Introduce a new parent pom for the CDI API, to avoid the odd relationship between the weld impl and CDI API.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 15 04:28:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 15 Nov 2016 04:28:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-647) Introduce a parent pom for CDI
In-Reply-To: <JIRA.12661482.1479139693000@Atlassian.JIRA>
References: <JIRA.12661482.1479139693000@Atlassian.JIRA>
	<JIRA.12661482.1479139693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661482.1479139693000.70258.1479202080599@Atlassian.JIRA>


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

Martin Kouba commented on CDI-647:
----------------------------------

If really needed, we should not introduce a new POM file but enhance https://github.com/cdi-spec/cdi/blob/master/pom.xml instead.

> Introduce a parent pom for CDI
> ------------------------------
>
>                 Key: CDI-647
>                 URL: https://issues.jboss.org/browse/CDI-647
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 2.0-EDR2
>            Reporter: John Ament
>
> Introduce a new parent pom for the CDI API, to avoid the odd relationship between the weld impl and CDI API.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 15 04:29:01 2016
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Tue, 15 Nov 2016 04:29:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-647) Introduce a parent pom for CDI
In-Reply-To: <JIRA.12661482.1479139693000@Atlassian.JIRA>
References: <JIRA.12661482.1479139693000@Atlassian.JIRA>
	<JIRA.12661482.1479139693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661482.1479139693000.70277.1479202141212@Atlassian.JIRA>


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

Matej Novotny commented on CDI-647:
-----------------------------------

-1 from me. There is no relation to Weld *impl*, but only to a parental POM, which merely declares plugin versions. I cannot really see the harm there.
BTW [~tremes], TCK has the same "problem".

> Introduce a parent pom for CDI
> ------------------------------
>
>                 Key: CDI-647
>                 URL: https://issues.jboss.org/browse/CDI-647
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 2.0-EDR2
>            Reporter: John Ament
>
> Introduce a new parent pom for the CDI API, to avoid the odd relationship between the weld impl and CDI API.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mkouba at redhat.com  Tue Nov 15 05:21:00 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 15 Nov 2016 11:21:00 +0100
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <OF4B393E3A.EEEAC09D-ON8025806B.003D4519-8025806B.003D635E@notes.na.collabserv.com>
References: <CAAGawe0GNLRfnXY1rhaoBwzR0_eWFJvQHSrQ4WcAX8_qMLnCRw@mail.gmail.com>
	<CY4PR04MB0486DD2E2DB8705A4ABB995E98A60@CY4PR04MB0486.namprd04.prod.outlook.com>
	<CABu-YBRC3kn8TXWc3hjt3VeMrYDwMjyejzsxfRBpDFKYNnyDdA@mail.gmail.com>
	<CY4PR04MB04864457DF31C373E5F24C8298A60@CY4PR04MB0486.namprd04.prod.outlook.com>
	<OF72082902.E6DF4AA5-ON8025806B.003A67DD-8025806B.003AC7B2@notes.na.collabserv.com>
	<OF4B393E3A.EEEAC09D-ON8025806B.003D4519-8025806B.003D635E@notes.na.collabserv.com>
Message-ID: <6348202c-b622-38d2-3978-9819c3be4032@redhat.com>

Maybe we could switch back to "wrapper", i.e. something like 
InterceptionWrapperFactory so that it's clear that the final object is 
actually just a wrapper of the original instance that handles interception.

Martin

Dne 14.11.2016 v 12:10 Emily Jiang napsal(a):
> Small correction: *InterceptionConfigurator *is what I suggested (not
> InterceptorConfigurator).
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> 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:        Emily Jiang/UK/IBM at IBMGB
> To:        John Ament <john.ament at spartasystems.com>
> Cc:        cdi-dev <cdi-dev at lists.jboss.org>
> Date:        14/11/2016 10:43
> Subject:        Re: [cdi-dev] Finding a new name for
> InterceptorProxyFactory
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> I looked at the methods under *InterceptionFactory*. To me, it sounds
> better to rename it to *InterceptorConfigurator *as it has .configure()
> plus it configures or wraps the classes.
>
> Thoughts?
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> 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:        John Ament <john.ament at spartasystems.com>
> To:        Antoine Sabot-Durand <antoine at sabot-durand.net>, cdi-dev
> <cdi-dev at lists.jboss.org>
> Date:        08/11/2016 17:17
> Subject:        Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> I can't think of any, just want to make sure no one else was.
>
>
>
> ------------------------------------------------------------------------
> *
> From:* Antoine Sabot-Durand <antoine at sabot-durand.net>*
> Sent:* Tuesday, November 8, 2016 12:04 PM*
> To:* John Ament; cdi-dev*
> Subject:* Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
>
>
> On Tue, Nov 8, 2016 at 2:38 PM John Ament
> <_john.ament at spartasystems.com_ <mailto:john.ament at spartasystems.com>>
> wrote:
> If the only use case is for inceptors, I agree to InterceptionFactory.
>
> What other use case you are thinking of John?
>
>
>
>
> ------------------------------------------------------------------------
> *
> From:* _cdi-dev-bounces at lists.jboss.org_
> <mailto:cdi-dev-bounces at lists.jboss.org><_cdi-dev-bounces at lists.jboss.org_
> <mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Werner Keil
> <_werner.keil at gmail.com_ <mailto:werner.keil at gmail.com>>*
> Sent:* Tuesday, November 8, 2016 8:30 AM*
> To:* cdi-dev*
>
> Subject:* Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> +1 for InterceptionFactory, too.
> It sounds simpler.
>
> Werner
>
>
> On Tue, Nov 8, 2016 at 2:29 PM, <_cdi-dev-request at lists.jboss.org_
> <mailto:cdi-dev-request at lists.jboss.org>> wrote:
> Send cdi-dev mailing list submissions to
>       _cdi-dev at lists.jboss.org_ <mailto: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_
> <mailto:cdi-dev-request at lists.jboss.org>
>
> You can reach the person managing the list at
>       _cdi-dev-owner at lists.jboss.org_ <mailto: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: Finding a new name for InterceptorProxyFactory (Mark Struberg)
>  2. Re: Finding a new name for InterceptorProxyFactory
>     (Antoine Sabot-Durand)
>  3. Re: Finding a new name for InterceptorProxyFactory
>     (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 7 Nov 2016 16:58:04 +0000 (UTC)
> From: Mark Struberg <_struberg at yahoo.de_ <mailto:struberg at yahoo.de>>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Romain Manni-Bucau <_rmannibucau at gmail.com_
> <mailto:rmannibucau at gmail.com>>, Antoine Sabot-Durand
>       <_antoine at sabot-durand.net_ <mailto:antoine at sabot-durand.net>>
> Cc: cdi-dev <_cdi-dev at lists.jboss.org_ <mailto:cdi-dev at lists.jboss.org>>
> Message-ID: <_421014798.1728352.1478537884045 at mail.yahoo.com_
> <mailto:421014798.1728352.1478537884045 at mail.yahoo.com>>
> Content-Type: text/plain; charset=UTF-8
>
> InterceptionFactory sounds fine for me.
>
>
> LieGrue,
> strub
>
>
>
> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau
> <_rmannibucau at gmail.com_ <mailto:rmannibucau at gmail.com>> wrote:
>>
>>Hello Antoine,
>>
>>
>>concurrency-utilities use ContextFactory for something pretty close (a
> proxying adding spec features over invocations) which is less
> "cglib-like" than "Enhancer" so I'd like to keep Factory. In the list
> InterceptionFactory looks clear enough. We neevr speak of business
> method anymore I think so it would add a difficulty for something very
> useful to go that deep in the naming I think.
>>
>>
>>
>>Romain Manni-Bucau
>>@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>>
>>2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand
> <_antoine at sabot-durand.net_ <mailto:antoine at sabot-durand.net>>:
>>
>>Hi all,
>>>
>>>
>>>In my last review for CDI-580
> (_https://github.com/cdi-spec/_cdi/pull/315), I removed all reference to
> proxies in Javadoc and spec doc following various feedback.
>>>So now the name of the interface is the only one dealing with Proxy,
> so we really need to find it a new name.
>>>I listed some proposal in PR 315:
>>>- InstanceEnhancer (short but not very clear)
>>>- BusinessMethodInvocationFactor y (more exact from spec pov, but is
> it clear from user pov?)
>>>- InterceptionFactory (cleared from user pov and near our initial name)
>>>- InterceptionEnhancer
>>>
>>>
>>>Feedback and other names are welcome.
>>>
>>>
>>>Antoine
>>>______________________________ _________________
>>>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_ <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.
>>
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 08 Nov 2016 13:24:28 +0000
> From: Antoine Sabot-Durand <_antoine at sabot-durand.net_
> <mailto:antoine at sabot-durand.net>>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Mark Struberg <_struberg at yahoo.de_ <mailto:struberg at yahoo.de>>,
>  Romain Manni-Bucau
>       <_rmannibucau at gmail.com_ <mailto:rmannibucau at gmail.com>>
> Cc: cdi-dev <_cdi-dev at lists.jboss.org_ <mailto:cdi-dev at lists.jboss.org>>
> Message-ID:
>
> <CABu-YBRhd8UYWck4-fibda_Ykoh-n=_u_Xfhs48tUcBCOw_TiAw at mail.gmail.com_
> <mailto:u_Xfhs48tUcBCOw_TiAw at mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> +1 for InterceptionFactory as well. I change my PR with this name.
>
> Romain, for the record, mentioning "business method invocation" and
> paragraph 7.2 is the only mean to bind this feature to the spec without
> mentioning implementation specific stuff like proxies. That's why the
> javadoc and text for this new section lack clarity. In other word we lack a
> simple name for instances on which "methods invocation" are "business
> methods invocation".
>
> Antoine
>
> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <_struberg at yahoo.de_
> <mailto:struberg at yahoo.de>> wrote:
>
>> InterceptionFactory sounds fine for me.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
>> _rmannibucau at gmail.com_ <mailto:rmannibucau at gmail.com>> wrote:
>> >
>> >Hello Antoine,
>> >
>> >
>> >concurrency-utilities use ContextFactory for something pretty close (a
>> proxying adding spec features over invocations) which is less "cglib-like"
>> than "Enhancer" so I'd like to keep Factory. In the list
>> InterceptionFactory looks clear enough. We neevr speak of business method
>> anymore I think so it would add a difficulty for something very useful to
>> go that deep in the naming I think.
>> >
>> >
>> >
>> >Romain Manni-Bucau
>> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> >
>> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand
> <_antoine at sabot-durand.net_ <mailto:antoine at sabot-durand.net>
>> >:
>> >
>> >Hi all,
>> >>
>> >>
>> >>In my last review for CDI-580 (_https://github.com/cdi-spec/_
>> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
>> following various feedback.
>> >>So now the name of the interface is the only one dealing with Proxy, so
>> we really need to find it a new name.
>> >>I listed some proposal in PR 315:
>> >>- InstanceEnhancer (short but not very clear)
>> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
>> clear from user pov?)
>> >>- InterceptionFactory (cleared from user pov and near our initial name)
>> >>- InterceptionEnhancer
>> >>
>> >>
>> >>Feedback and other names are welcome.
>> >>
>> >>
>> >>Antoine
>> >>______________________________ _________________
>> >>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_ <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.
>> >
>> >
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> _http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/efa4663c/attachment-0001.html_
>
> ------------------------------
>
> Message: 3
> Date: Tue, 8 Nov 2016 14:28:27 +0100
> From: Romain Manni-Bucau <_rmannibucau at gmail.com_
> <mailto:rmannibucau at gmail.com>>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Antoine Sabot-Durand <_antoine at sabot-durand.net_
> <mailto:antoine at sabot-durand.net>>
> Cc: cdi-dev <_cdi-dev at lists.jboss.org_ <mailto:cdi-dev at lists.jboss.org>>
> Message-ID:
>
> <CACLE=_7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com_
> <mailto:7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-11-08 14:24 GMT+01:00 Antoine Sabot-Durand
> <_antoine at sabot-durand.net_ <mailto:antoine at sabot-durand.net>>:
>
>> +1 for InterceptionFactory as well. I change my PR with this name.
>>
>> Romain, for the record, mentioning "business method invocation" and
>> paragraph 7.2 is the only mean to bind this feature to the spec without
>> mentioning implementation specific stuff like proxies. That's why the
>> javadoc and text for this new section lack clarity. In other word we
> lack a
>> simple name for instances on which "methods invocation" are "business
>> methods invocation".
>>
>>
> Agree and it fits the spec but since EJB I never heard any developer (not
> developping weld or openwebbeans) using this term so for the API it would
> be rude IMHO - was the point, nothing more.
>
>
>> Antoine
>>
>> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <_struberg at yahoo.de_
> <mailto:struberg at yahoo.de>> wrote:
>>
>>> InterceptionFactory sounds fine for me.
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
>>> _rmannibucau at gmail.com_ <mailto:rmannibucau at gmail.com>> wrote:
>>> >
>>> >Hello Antoine,
>>> >
>>> >
>>> >concurrency-utilities use ContextFactory for something pretty close (a
>>> proxying adding spec features over invocations) which is less
> "cglib-like"
>>> than "Enhancer" so I'd like to keep Factory. In the list
>>> InterceptionFactory looks clear enough. We neevr speak of business method
>>> anymore I think so it would add a difficulty for something very useful to
>>> go that deep in the naming I think.
>>> >
>>> >
>>> >
>>> >Romain Manni-Bucau
>>> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>>> >
>>> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
>>> _antoine at sabot-durand.net_ <mailto:antoine at sabot-durand.net>>:
>>> >
>>> >Hi all,
>>> >>
>>> >>
>>> >>In my last review for CDI-580 (_https://github.com/cdi-spec/_
>>> cdi/pull/315), I removed all reference to proxies in Javadoc and spec doc
>>> following various feedback.
>>> >>So now the name of the interface is the only one dealing with Proxy, so
>>> we really need to find it a new name.
>>> >>I listed some proposal in PR 315:
>>> >>- InstanceEnhancer (short but not very clear)
>>> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is it
>>> clear from user pov?)
>>> >>- InterceptionFactory (cleared from user pov and near our initial name)
>>> >>- InterceptionEnhancer
>>> >>
>>> >>
>>> >>Feedback and other names are welcome.
>>> >>
>>> >>
>>> >>Antoine
>>> >>______________________________ _________________
>>> >>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_ <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.
>>> >
>>> >
>>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> _http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/c6e8a845/attachment.html_
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 72, Issue 5
> **************************************
>
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.
> _______________________________________________
> 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.
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.
> _______________________________________________
> 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.
>
> 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.
>
> 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
Software Engineer
Red Hat, Czech Republic

From issues at jboss.org  Tue Nov 15 08:50:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 15 Nov 2016 08:50:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-648) Consider adding synthetic
 container lifecycle event observers
In-Reply-To: <JIRA.12661787.1479217743000@Atlassian.JIRA>
References: <JIRA.12661787.1479217743000@Atlassian.JIRA>
	<JIRA.12661787.1479217743262@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661787.1479217743000.73198.1479217800214@Atlassian.JIRA>

Martin Kouba created CDI-648:
--------------------------------

             Summary: Consider adding synthetic container lifecycle event observers
                 Key: CDI-648
                 URL: https://issues.jboss.org/browse/CDI-648
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Java SE Integration
            Reporter: Martin Kouba
             Fix For: 2.1 (Discussion)


See also:
* https://issues.jboss.org/browse/WELD-2102 
* http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 15 11:23:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 15 Nov 2016 11:23:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-181) Provide full changelog in spec
In-Reply-To: <JIRA.12450421.1319627508000@Atlassian.JIRA>
References: <JIRA.12450421.1319627508000@Atlassian.JIRA>
	<JIRA.12450421.1319627508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12450421.1319627508000.76219.1479226981236@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand resolved CDI-181.
--------------------------------------
    Fix Version/s:     (was: 1.1.FD)
       Resolution: Out of Date


> Provide full changelog in spec
> ------------------------------
>
>                 Key: CDI-181
>                 URL: https://issues.jboss.org/browse/CDI-181
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Linda DeMichiel
>            Assignee: Pete Muir
>
> Linda has requested a full changelog.
> Other specs generate this manually.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 15 11:23:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 15 Nov 2016 11:23:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-181) Provide full changelog in spec
In-Reply-To: <JIRA.12450421.1319627508000@Atlassian.JIRA>
References: <JIRA.12450421.1319627508000@Atlassian.JIRA>
	<JIRA.12450421.1319627508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12450421.1319627508000.76222.1479226981292@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand closed CDI-181.
------------------------------------


> Provide full changelog in spec
> ------------------------------
>
>                 Key: CDI-181
>                 URL: https://issues.jboss.org/browse/CDI-181
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Linda DeMichiel
>            Assignee: Pete Muir
>
> Linda has requested a full changelog.
> Other specs generate this manually.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 15 11:32:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 15 Nov 2016 11:32:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-642) Allow defining interceptor binding
 or qualifier via an AnnotatedTypeConfigurator in BeforeBeandiscovery
In-Reply-To: <JIRA.12657852.1477751134000@Atlassian.JIRA>
References: <JIRA.12657852.1477751134000@Atlassian.JIRA>
	<JIRA.12657852.1477751134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657852.1477751134000.76454.1479227520105@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand reassigned CDI-642:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Allow defining interceptor binding or qualifier via an AnnotatedTypeConfigurator in BeforeBeandiscovery 
> --------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-642
>                 URL: https://issues.jboss.org/browse/CDI-642
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 2.0-EDR2
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> We should consider adding a new version of {{BeforeBeanDiscovery.addInterceptorBinding()}} and {{BeforeBeanDiscovery.addQualifier()}} methods returning an {{AnnotatedTypeConfigurator}} to ease addition of of 3rd party annotation as interceptor binding or qualifier. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 15 11:33:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 15 Nov 2016 11:33:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-642) Allow defining interceptor binding
 or qualifier via an AnnotatedTypeConfigurator in BeforeBeandiscovery
In-Reply-To: <JIRA.12657852.1477751134000@Atlassian.JIRA>
References: <JIRA.12657852.1477751134000@Atlassian.JIRA>
	<JIRA.12657852.1477751134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657852.1477751134000.76459.1479227580141@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CDI-642 started by Antoine Sabot-Durand.
------------------------------------------------
> Allow defining interceptor binding or qualifier via an AnnotatedTypeConfigurator in BeforeBeandiscovery 
> --------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-642
>                 URL: https://issues.jboss.org/browse/CDI-642
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 2.0-EDR2
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> We should consider adding a new version of {{BeforeBeanDiscovery.addInterceptorBinding()}} and {{BeforeBeanDiscovery.addQualifier()}} methods returning an {{AnnotatedTypeConfigurator}} to ease addition of of 3rd party annotation as interceptor binding or qualifier. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 15 19:58:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 15 Nov 2016 19:58:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-512) Initialization parameter to
 specify loaded Extensions
In-Reply-To: <JIRA.12564533.1425222305000@Atlassian.JIRA>
References: <JIRA.12564533.1425222305000@Atlassian.JIRA>
	<JIRA.12564533.1425222305000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564533.1425222305000.78974.1479257880028@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ament closed CDI-512.
--------------------------
    Resolution: Rejected


Already in.

> Initialization parameter to specify loaded Extensions
> -----------------------------------------------------
>
>                 Key: CDI-512
>                 URL: https://issues.jboss.org/browse/CDI-512
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java SE Integration
>            Reporter: John Ament
>            Assignee: John Ament
>
> As a tie in for CDI-511, define a initialization parameter that can specify the list of extensions to be enabled.
> The parameter should accept any Collection, however if a duplicate entry is found it is ignored.
> The collection should support either Classes or Strings representing the FQCN of the extension itself, or the extension instance.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From antoine at sabot-durand.net  Wed Nov 16 05:30:04 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 16 Nov 2016 10:30:04 +0000
Subject: [cdi-dev] AnnotatedTypeConfigurator limitation
Message-ID: <CABu-YBQLifnkdyUG6ZxZi2Rc4StY5trvyJ5XGNJHzFsy70KB6g@mail.gmail.com>

Hi Guys,

Following CDI-642 and 643 I started to explore place where annotatedType
can be used and where we don't provide access to AnnotatedTypeConfigurator
[1], I really think we should solve this use case to avoid advanced users
frustration discovering a new feature they can use everywhere (that was my
case when realised that I could use it in BBD for Qualifier or
interceptorBinding addition).

Possible solutions:
1) Add a hook to each of these place to obtain an AnnotatedTypeConfigurator
2) Add BM.createAnnotatypeConfigurator(Class) and
BM.createAnnotatedType(ATC)
3) Add a Builder class that would provide a configure method
4) Transform AnnotatedTypeConfigurator into a Builder and simplify SPI
using AnnotatedTypeConfigurator.

Antoine

 [1] Non exhaustive list :
- BeforeTypeDiscovery for addQualifier and addInterceptorBinding
- UnManaged class
- BeanManager createInjectionTartet and getInjectionTargetFactory or in
InjectionTarget
- BeanManager getProducerFactory where a configured AnnotatedField or
AnnotatedMethod could be useful
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161116/5d85fafc/attachment.html 

From mkouba at redhat.com  Wed Nov 16 06:34:03 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 16 Nov 2016 12:34:03 +0100
Subject: [cdi-dev] AnnotatedTypeConfigurator limitation
In-Reply-To: <CABu-YBQLifnkdyUG6ZxZi2Rc4StY5trvyJ5XGNJHzFsy70KB6g@mail.gmail.com>
References: <CABu-YBQLifnkdyUG6ZxZi2Rc4StY5trvyJ5XGNJHzFsy70KB6g@mail.gmail.com>
Message-ID: <8d24385c-a780-2670-c136-61dad9109ae7@redhat.com>

Well, I thought the EG already agreed that the purpose of the 
configurator API is not to cover all possible use cases, but the most 
common ones. And the list of use cases below seems more like a list of 
corner cases.

Anyway, if the EG decides to support this, I think we could either go 
with 1) or 3) *.

*
BeanManager.getAnnotatedTypeBuilder() that returns a new builder 
wrapping a configurator instance.

Martin

Dne 16.11.2016 v 11:30 Antoine Sabot-Durand napsal(a):
> Hi Guys,
>
> Following CDI-642 and 643 I started to explore place where annotatedType
> can be used and where we don't provide access to
> AnnotatedTypeConfigurator [1], I really think we should solve this use
> case to avoid advanced users frustration discovering a new feature they
> can use everywhere (that was my case when realised that I could use it
> in BBD for Qualifier or interceptorBinding addition).
>
> Possible solutions:
> 1) Add a hook to each of these place to obtain an AnnotatedTypeConfigurator
> 2) Add BM.createAnnotatypeConfigurator(Class) and
> BM.createAnnotatedType(ATC)
> 3) Add a Builder class that would provide a configure method
> 4) Transform AnnotatedTypeConfigurator into a Builder and simplify SPI
> using AnnotatedTypeConfigurator.
>
> Antoine
>
>  [1] Non exhaustive list :
> - BeforeTypeDiscovery for addQualifier and addInterceptorBinding
> - UnManaged class
> - BeanManager createInjectionTartet and getInjectionTargetFactory or in
> InjectionTarget
> - BeanManager getProducerFactory where a configured AnnotatedField or
> AnnotatedMethod could be useful
>
>
> _______________________________________________
> 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
Software Engineer
Red Hat, Czech Republic

From manovotn at redhat.com  Wed Nov 16 06:59:05 2016
From: manovotn at redhat.com (Matej Novotny)
Date: Wed, 16 Nov 2016 06:59:05 -0500 (EST)
Subject: [cdi-dev] AnnotatedTypeConfigurator limitation
In-Reply-To: <8d24385c-a780-2670-c136-61dad9109ae7@redhat.com>
References: <CABu-YBQLifnkdyUG6ZxZi2Rc4StY5trvyJ5XGNJHzFsy70KB6g@mail.gmail.com>
	<8d24385c-a780-2670-c136-61dad9109ae7@redhat.com>
Message-ID: <1978175296.8358686.1479297545207.JavaMail.zimbra@redhat.com>

Here are my 0.02$

As soon as you extract ATC outside and make it available at any time, a question pops up - Why ATC only? Why not all configurators usable at all times?
The above is ofc nonsense and had been discussed before. So, we cannot add all, and therefore doing so for some will make usage inconsistent and confusing.

If you really feel like covering the cases you described[1] and making ATC available there, I would go for 1). We don't yet know what will users do with current API; let us not overextend it.

> Well, I thought the EG already agreed that the purpose of the
> configurator API is not to cover all possible use cases, but the most
> common ones.

Also, +10 on ^

Regards
Matej


----- Original Message -----
> From: "Martin Kouba" <mkouba at redhat.com>
> To: "Antoine Sabot-Durand" <antoine at sabot-durand.net>, "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Wednesday, November 16, 2016 12:34:03 PM
> Subject: Re: [cdi-dev] AnnotatedTypeConfigurator limitation
> 
> Well, I thought the EG already agreed that the purpose of the
> configurator API is not to cover all possible use cases, but the most
> common ones. And the list of use cases below seems more like a list of
> corner cases.
> 
> Anyway, if the EG decides to support this, I think we could either go
> with 1) or 3) *.
> 
> *
> BeanManager.getAnnotatedTypeBuilder() that returns a new builder
> wrapping a configurator instance.
> 
> Martin
> 
> Dne 16.11.2016 v 11:30 Antoine Sabot-Durand napsal(a):
> > Hi Guys,
> >
> > Following CDI-642 and 643 I started to explore place where annotatedType
> > can be used and where we don't provide access to
> > AnnotatedTypeConfigurator [1], I really think we should solve this use
> > case to avoid advanced users frustration discovering a new feature they
> > can use everywhere (that was my case when realised that I could use it
> > in BBD for Qualifier or interceptorBinding addition).
> >
> > Possible solutions:
> > 1) Add a hook to each of these place to obtain an AnnotatedTypeConfigurator
> > 2) Add BM.createAnnotatypeConfigurator(Class) and
> > BM.createAnnotatedType(ATC)
> > 3) Add a Builder class that would provide a configure method
> > 4) Transform AnnotatedTypeConfigurator into a Builder and simplify SPI
> > using AnnotatedTypeConfigurator.
> >
> > Antoine
> >
> >  [1] Non exhaustive list :
> > - BeforeTypeDiscovery for addQualifier and addInterceptorBinding
> > - UnManaged class
> > - BeanManager createInjectionTartet and getInjectionTargetFactory or in
> > InjectionTarget
> > - BeanManager getProducerFactory where a configured AnnotatedField or
> > AnnotatedMethod could be useful
> >
> >
> > _______________________________________________
> > 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
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> 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 antoine at sabot-durand.net  Wed Nov 16 07:51:27 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 16 Nov 2016 12:51:27 +0000
Subject: [cdi-dev] AnnotatedTypeConfigurator limitation
In-Reply-To: <1978175296.8358686.1479297545207.JavaMail.zimbra@redhat.com>
References: <CABu-YBQLifnkdyUG6ZxZi2Rc4StY5trvyJ5XGNJHzFsy70KB6g@mail.gmail.com>
	<8d24385c-a780-2670-c136-61dad9109ae7@redhat.com>
	<1978175296.8358686.1479297545207.JavaMail.zimbra@redhat.com>
Message-ID: <CABu-YBTOhBx6iHQ+DFbVtz+dGdLisGdBSXYraqo0tCwqEw=hKg@mail.gmail.com>

>From the beginning I advocated to have AnnotatedType treated as special
case since it can be used from outside a portable extension (that's the
reason why ATC and not other configurators, Matej).

These are not corner cases since I encountered them on 3rd party framework
integration.

This said, I understand it's rather late to open this topic and with such
cold and negative reception I move it to 2.1.

Antoine

On Wed, Nov 16, 2016 at 12:59 PM Matej Novotny <manovotn at redhat.com> wrote:

> Here are my 0.02$
>
> As soon as you extract ATC outside and make it available at any time, a
> question pops up - Why ATC only? Why not all configurators usable at all
> times?
> The above is ofc nonsense and had been discussed before. So, we cannot add
> all, and therefore doing so for some will make usage inconsistent and
> confusing.
>
> If you really feel like covering the cases you described[1] and making ATC
> available there, I would go for 1). We don't yet know what will users do
> with current API; let us not overextend it.
>
> > Well, I thought the EG already agreed that the purpose of the
> > configurator API is not to cover all possible use cases, but the most
> > common ones.
>
> Also, +10 on ^
>
> Regards
> Matej
>
>
> ----- Original Message -----
> > From: "Martin Kouba" <mkouba at redhat.com>
> > To: "Antoine Sabot-Durand" <antoine at sabot-durand.net>, "cdi-dev" <
> cdi-dev at lists.jboss.org>
> > Sent: Wednesday, November 16, 2016 12:34:03 PM
> > Subject: Re: [cdi-dev] AnnotatedTypeConfigurator limitation
> >
> > Well, I thought the EG already agreed that the purpose of the
> > configurator API is not to cover all possible use cases, but the most
> > common ones. And the list of use cases below seems more like a list of
> > corner cases.
> >
> > Anyway, if the EG decides to support this, I think we could either go
> > with 1) or 3) *.
> >
> > *
> > BeanManager.getAnnotatedTypeBuilder() that returns a new builder
> > wrapping a configurator instance.
> >
> > Martin
> >
> > Dne 16.11.2016 v 11:30 Antoine Sabot-Durand napsal(a):
> > > Hi Guys,
> > >
> > > Following CDI-642 and 643 I started to explore place where
> annotatedType
> > > can be used and where we don't provide access to
> > > AnnotatedTypeConfigurator [1], I really think we should solve this use
> > > case to avoid advanced users frustration discovering a new feature they
> > > can use everywhere (that was my case when realised that I could use it
> > > in BBD for Qualifier or interceptorBinding addition).
> > >
> > > Possible solutions:
> > > 1) Add a hook to each of these place to obtain an
> AnnotatedTypeConfigurator
> > > 2) Add BM.createAnnotatypeConfigurator(Class) and
> > > BM.createAnnotatedType(ATC)
> > > 3) Add a Builder class that would provide a configure method
> > > 4) Transform AnnotatedTypeConfigurator into a Builder and simplify SPI
> > > using AnnotatedTypeConfigurator.
> > >
> > > Antoine
> > >
> > >  [1] Non exhaustive list :
> > > - BeforeTypeDiscovery for addQualifier and addInterceptorBinding
> > > - UnManaged class
> > > - BeanManager createInjectionTartet and getInjectionTargetFactory or in
> > > InjectionTarget
> > > - BeanManager getProducerFactory where a configured AnnotatedField or
> > > AnnotatedMethod could be useful
> > >
> > >
> > > _______________________________________________
> > > 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
> > Software Engineer
> > Red Hat, Czech Republic
> > _______________________________________________
> > 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/20161116/5b684f91/attachment.html 

From manovotn at redhat.com  Wed Nov 16 07:58:35 2016
From: manovotn at redhat.com (Matej Novotny)
Date: Wed, 16 Nov 2016 07:58:35 -0500 (EST)
Subject: [cdi-dev] AnnotatedTypeConfigurator limitation
In-Reply-To: <CABu-YBTOhBx6iHQ+DFbVtz+dGdLisGdBSXYraqo0tCwqEw=hKg@mail.gmail.com>
References: <CABu-YBQLifnkdyUG6ZxZi2Rc4StY5trvyJ5XGNJHzFsy70KB6g@mail.gmail.com>
	<8d24385c-a780-2670-c136-61dad9109ae7@redhat.com>
	<1978175296.8358686.1479297545207.JavaMail.zimbra@redhat.com>
	<CABu-YBTOhBx6iHQ+DFbVtz+dGdLisGdBSXYraqo0tCwqEw=hKg@mail.gmail.com>
Message-ID: <1419799286.8366226.1479301115433.JavaMail.zimbra@redhat.com>

> This said, I understand it's rather late to open this topic and with such
> cold and negative reception I move it to 2.1.

Uh, sorry, seems like I am all too cold and negative this week. Didn't mean that, my apology.
All I meant to say is that we discussed this quite excessively before and came to resolve the way we did.
That being said, applying your 1) solution would perfectly fit into our current layout :-)

Matej

----- Original Message -----
> From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
> To: "Matej Novotny" <manovotn at redhat.com>, "Martin Kouba" <mkouba at redhat.com>
> Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Wednesday, November 16, 2016 1:51:27 PM
> Subject: Re: [cdi-dev] AnnotatedTypeConfigurator limitation
> 
> From the beginning I advocated to have AnnotatedType treated as special
> case since it can be used from outside a portable extension (that's the
> reason why ATC and not other configurators, Matej).
> 
> These are not corner cases since I encountered them on 3rd party framework
> integration.
> 
> This said, I understand it's rather late to open this topic and with such
> cold and negative reception I move it to 2.1.
> 
> Antoine
> 
> On Wed, Nov 16, 2016 at 12:59 PM Matej Novotny <manovotn at redhat.com> wrote:
> 
> > Here are my 0.02$
> >
> > As soon as you extract ATC outside and make it available at any time, a
> > question pops up - Why ATC only? Why not all configurators usable at all
> > times?
> > The above is ofc nonsense and had been discussed before. So, we cannot add
> > all, and therefore doing so for some will make usage inconsistent and
> > confusing.
> >
> > If you really feel like covering the cases you described[1] and making ATC
> > available there, I would go for 1). We don't yet know what will users do
> > with current API; let us not overextend it.
> >
> > > Well, I thought the EG already agreed that the purpose of the
> > > configurator API is not to cover all possible use cases, but the most
> > > common ones.
> >
> > Also, +10 on ^
> >
> > Regards
> > Matej
> >
> >
> > ----- Original Message -----
> > > From: "Martin Kouba" <mkouba at redhat.com>
> > > To: "Antoine Sabot-Durand" <antoine at sabot-durand.net>, "cdi-dev" <
> > cdi-dev at lists.jboss.org>
> > > Sent: Wednesday, November 16, 2016 12:34:03 PM
> > > Subject: Re: [cdi-dev] AnnotatedTypeConfigurator limitation
> > >
> > > Well, I thought the EG already agreed that the purpose of the
> > > configurator API is not to cover all possible use cases, but the most
> > > common ones. And the list of use cases below seems more like a list of
> > > corner cases.
> > >
> > > Anyway, if the EG decides to support this, I think we could either go
> > > with 1) or 3) *.
> > >
> > > *
> > > BeanManager.getAnnotatedTypeBuilder() that returns a new builder
> > > wrapping a configurator instance.
> > >
> > > Martin
> > >
> > > Dne 16.11.2016 v 11:30 Antoine Sabot-Durand napsal(a):
> > > > Hi Guys,
> > > >
> > > > Following CDI-642 and 643 I started to explore place where
> > annotatedType
> > > > can be used and where we don't provide access to
> > > > AnnotatedTypeConfigurator [1], I really think we should solve this use
> > > > case to avoid advanced users frustration discovering a new feature they
> > > > can use everywhere (that was my case when realised that I could use it
> > > > in BBD for Qualifier or interceptorBinding addition).
> > > >
> > > > Possible solutions:
> > > > 1) Add a hook to each of these place to obtain an
> > AnnotatedTypeConfigurator
> > > > 2) Add BM.createAnnotatypeConfigurator(Class) and
> > > > BM.createAnnotatedType(ATC)
> > > > 3) Add a Builder class that would provide a configure method
> > > > 4) Transform AnnotatedTypeConfigurator into a Builder and simplify SPI
> > > > using AnnotatedTypeConfigurator.
> > > >
> > > > Antoine
> > > >
> > > >  [1] Non exhaustive list :
> > > > - BeforeTypeDiscovery for addQualifier and addInterceptorBinding
> > > > - UnManaged class
> > > > - BeanManager createInjectionTartet and getInjectionTargetFactory or in
> > > > InjectionTarget
> > > > - BeanManager getProducerFactory where a configured AnnotatedField or
> > > > AnnotatedMethod could be useful
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > > Software Engineer
> > > Red Hat, Czech Republic
> > > _______________________________________________
> > > 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 EMIJIANG at uk.ibm.com  Wed Nov 16 17:53:17 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Wed, 16 Nov 2016 22:53:17 +0000
Subject: [cdi-dev] Finding a new name for InterceptorProxyFactory
In-Reply-To: <6348202c-b622-38d2-3978-9819c3be4032@redhat.com>
References: <CAAGawe0GNLRfnXY1rhaoBwzR0_eWFJvQHSrQ4WcAX8_qMLnCRw@mail.gmail.com>	<CY4PR04MB0486DD2E2DB8705A4ABB995E98A60@CY4PR04MB0486.namprd04.prod.outlook.com>
	<CABu-YBRC3kn8TXWc3hjt3VeMrYDwMjyejzsxfRBpDFKYNnyDdA@mail.gmail.com>	<CY4PR04MB04864457DF31C373E5F24C8298A60@CY4PR04MB0486.namprd04.prod.outlook.com>
	<OF72082902.E6DF4AA5-ON8025806B.003A67DD-8025806B.003AC7B2@notes.na.collabserv.com>
	<OF4B393E3A.EEEAC09D-ON8025806B.003D4519-8025806B.003D635E@notes.na.collabserv.com>
	<6348202c-b622-38d2-3978-9819c3be4032@redhat.com>
Message-ID: <OF4C12B009.8ECD0A6D-ON8025806D.007C42A1-8025806D.007DBCE1@notes.na.collabserv.com>

InterceptionWrapperFactory sounds better than the InterceptionFactory.

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
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/UK/IBM at IBMGB
Cc:     cdi-dev <cdi-dev at lists.jboss.org>
Date:   15/11/2016 10:22
Subject:        Re: [cdi-dev] Finding a new name for 
InterceptorProxyFactory
Sent by:        cdi-dev-bounces at lists.jboss.org



Maybe we could switch back to "wrapper", i.e. something like 
InterceptionWrapperFactory so that it's clear that the final object is 
actually just a wrapper of the original instance that handles 
interception.

Martin

Dne 14.11.2016 v 12:10 Emily Jiang napsal(a):
> Small correction: *InterceptionConfigurator *is what I suggested (not
> InterceptorConfigurator).
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> 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:        Emily Jiang/UK/IBM at IBMGB
> To:        John Ament <john.ament at spartasystems.com>
> Cc:        cdi-dev <cdi-dev at lists.jboss.org>
> Date:        14/11/2016 10:43
> Subject:        Re: [cdi-dev] Finding a new name for
> InterceptorProxyFactory
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> I looked at the methods under *InterceptionFactory*. To me, it sounds
> better to rename it to *InterceptorConfigurator *as it has .configure()
> plus it configures or wraps the classes.
>
> Thoughts?
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> 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:        John Ament <john.ament at spartasystems.com>
> To:        Antoine Sabot-Durand <antoine at sabot-durand.net>, cdi-dev
> <cdi-dev at lists.jboss.org>
> Date:        08/11/2016 17:17
> Subject:        Re: [cdi-dev] Finding a new name for 
InterceptorProxyFactory
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> I can't think of any, just want to make sure no one else was.
>
>
>
> ------------------------------------------------------------------------
> *
> From:* Antoine Sabot-Durand <antoine at sabot-durand.net>*
> Sent:* Tuesday, November 8, 2016 12:04 PM*
> To:* John Ament; cdi-dev*
> Subject:* Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
>
>
> On Tue, Nov 8, 2016 at 2:38 PM John Ament
> <_john.ament at spartasystems.com_ <mailto:john.ament at spartasystems.com>>
> wrote:
> If the only use case is for inceptors, I agree to InterceptionFactory.
>
> What other use case you are thinking of John?
>
>
>
>
> ------------------------------------------------------------------------
> *
> From:* _cdi-dev-bounces at lists.jboss.org_
> <mailto:cdi-dev-bounces at lists.jboss.org
><_cdi-dev-bounces at lists.jboss.org_
> <mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Werner Keil
> <_werner.keil at gmail.com_ <mailto:werner.keil at gmail.com>>*
> Sent:* Tuesday, November 8, 2016 8:30 AM*
> To:* cdi-dev*
>
> Subject:* Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> +1 for InterceptionFactory, too.
> It sounds simpler.
>
> Werner
>
>
> On Tue, Nov 8, 2016 at 2:29 PM, <_cdi-dev-request at lists.jboss.org_
> <mailto:cdi-dev-request at lists.jboss.org>> wrote:
> Send cdi-dev mailing list submissions to
>       _cdi-dev at lists.jboss.org_ <mailto: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_
> <mailto:cdi-dev-request at lists.jboss.org>
>
> You can reach the person managing the list at
>       _cdi-dev-owner at lists.jboss.org_ <
mailto: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: Finding a new name for InterceptorProxyFactory (Mark Struberg)
>  2. Re: Finding a new name for InterceptorProxyFactory
>     (Antoine Sabot-Durand)
>  3. Re: Finding a new name for InterceptorProxyFactory
>     (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 7 Nov 2016 16:58:04 +0000 (UTC)
> From: Mark Struberg <_struberg at yahoo.de_ <mailto:struberg at yahoo.de>>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Romain Manni-Bucau <_rmannibucau at gmail.com_
> <mailto:rmannibucau at gmail.com>>, Antoine Sabot-Durand
>       <_antoine at sabot-durand.net_ <mailto:antoine at sabot-durand.net>>
> Cc: cdi-dev <_cdi-dev at lists.jboss.org_ <mailto:cdi-dev at lists.jboss.org>>
> Message-ID: <_421014798.1728352.1478537884045 at mail.yahoo.com_
> <mailto:421014798.1728352.1478537884045 at mail.yahoo.com>>
> Content-Type: text/plain; charset=UTF-8
>
> InterceptionFactory sounds fine for me.
>
>
> LieGrue,
> strub
>
>
>
> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau
> <_rmannibucau at gmail.com_ <mailto:rmannibucau at gmail.com>> wrote:
>>
>>Hello Antoine,
>>
>>
>>concurrency-utilities use ContextFactory for something pretty close (a
> proxying adding spec features over invocations) which is less
> "cglib-like" than "Enhancer" so I'd like to keep Factory. In the list
> InterceptionFactory looks clear enough. We neevr speak of business
> method anymore I think so it would add a difficulty for something very
> useful to go that deep in the naming I think.
>>
>>
>>
>>Romain Manni-Bucau
>>@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>>
>>2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand
> <_antoine at sabot-durand.net_ <mailto:antoine at sabot-durand.net>>:
>>
>>Hi all,
>>>
>>>
>>>In my last review for CDI-580
> (_https://github.com/cdi-spec/_cdi/pull/315), I removed all reference to
> proxies in Javadoc and spec doc following various feedback.
>>>So now the name of the interface is the only one dealing with Proxy,
> so we really need to find it a new name.
>>>I listed some proposal in PR 315:
>>>- InstanceEnhancer (short but not very clear)
>>>- BusinessMethodInvocationFactor y (more exact from spec pov, but is
> it clear from user pov?)
>>>- InterceptionFactory (cleared from user pov and near our initial name)
>>>- InterceptionEnhancer
>>>
>>>
>>>Feedback and other names are welcome.
>>>
>>>
>>>Antoine
>>>______________________________ _________________
>>>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_ <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.
>>
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 08 Nov 2016 13:24:28 +0000
> From: Antoine Sabot-Durand <_antoine at sabot-durand.net_
> <mailto:antoine at sabot-durand.net>>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Mark Struberg <_struberg at yahoo.de_ <mailto:struberg at yahoo.de>>,
>  Romain Manni-Bucau
>       <_rmannibucau at gmail.com_ <mailto:rmannibucau at gmail.com>>
> Cc: cdi-dev <_cdi-dev at lists.jboss.org_ <mailto:cdi-dev at lists.jboss.org>>
> Message-ID:
>
> <CABu-YBRhd8UYWck4-fibda_Ykoh-n=_u_Xfhs48tUcBCOw_TiAw at mail.gmail.com_
> <mailto:u_Xfhs48tUcBCOw_TiAw at mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> +1 for InterceptionFactory as well. I change my PR with this name.
>
> Romain, for the record, mentioning "business method invocation" and
> paragraph 7.2 is the only mean to bind this feature to the spec without
> mentioning implementation specific stuff like proxies. That's why the
> javadoc and text for this new section lack clarity. In other word we 
lack a
> simple name for instances on which "methods invocation" are "business
> methods invocation".
>
> Antoine
>
> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <_struberg at yahoo.de_
> <mailto:struberg at yahoo.de>> wrote:
>
>> InterceptionFactory sounds fine for me.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
>> _rmannibucau at gmail.com_ <mailto:rmannibucau at gmail.com>> wrote:
>> >
>> >Hello Antoine,
>> >
>> >
>> >concurrency-utilities use ContextFactory for something pretty close (a
>> proxying adding spec features over invocations) which is less 
"cglib-like"
>> than "Enhancer" so I'd like to keep Factory. In the list
>> InterceptionFactory looks clear enough. We neevr speak of business 
method
>> anymore I think so it would add a difficulty for something very useful 
to
>> go that deep in the naming I think.
>> >
>> >
>> >
>> >Romain Manni-Bucau
>> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> >
>> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand
> <_antoine at sabot-durand.net_ <mailto:antoine at sabot-durand.net>
>> >:
>> >
>> >Hi all,
>> >>
>> >>
>> >>In my last review for CDI-580 (_https://github.com/cdi-spec/_
>> cdi/pull/315), I removed all reference to proxies in Javadoc and spec 
doc
>> following various feedback.
>> >>So now the name of the interface is the only one dealing with Proxy, 
so
>> we really need to find it a new name.
>> >>I listed some proposal in PR 315:
>> >>- InstanceEnhancer (short but not very clear)
>> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is 
it
>> clear from user pov?)
>> >>- InterceptionFactory (cleared from user pov and near our initial 
name)
>> >>- InterceptionEnhancer
>> >>
>> >>
>> >>Feedback and other names are welcome.
>> >>
>> >>
>> >>Antoine
>> >>______________________________ _________________
>> >>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_ <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.
>> >
>> >
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> 
_http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/efa4663c/attachment-0001.html_
>
> ------------------------------
>
> Message: 3
> Date: Tue, 8 Nov 2016 14:28:27 +0100
> From: Romain Manni-Bucau <_rmannibucau at gmail.com_
> <mailto:rmannibucau at gmail.com>>
> Subject: Re: [cdi-dev] Finding a new name for InterceptorProxyFactory
> To: Antoine Sabot-Durand <_antoine at sabot-durand.net_
> <mailto:antoine at sabot-durand.net>>
> Cc: cdi-dev <_cdi-dev at lists.jboss.org_ <mailto:cdi-dev at lists.jboss.org>>
> Message-ID:
>
> <CACLE=_7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com_
> <mailto:7N-q9Uk9F2JuAU9f4T5wb8u26MMJ_LbNNhd1LkeQxvcWg at mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-11-08 14:24 GMT+01:00 Antoine Sabot-Durand
> <_antoine at sabot-durand.net_ <mailto:antoine at sabot-durand.net>>:
>
>> +1 for InterceptionFactory as well. I change my PR with this name.
>>
>> Romain, for the record, mentioning "business method invocation" and
>> paragraph 7.2 is the only mean to bind this feature to the spec without
>> mentioning implementation specific stuff like proxies. That's why the
>> javadoc and text for this new section lack clarity. In other word we
> lack a
>> simple name for instances on which "methods invocation" are "business
>> methods invocation".
>>
>>
> Agree and it fits the spec but since EJB I never heard any developer 
(not
> developping weld or openwebbeans) using this term so for the API it 
would
> be rude IMHO - was the point, nothing more.
>
>
>> Antoine
>>
>> On Mon, Nov 7, 2016 at 5:58 PM Mark Struberg <_struberg at yahoo.de_
> <mailto:struberg at yahoo.de>> wrote:
>>
>>> InterceptionFactory sounds fine for me.
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> On Monday, 7 November 2016, 15:55, Romain Manni-Bucau <
>>> _rmannibucau at gmail.com_ <mailto:rmannibucau at gmail.com>> wrote:
>>> >
>>> >Hello Antoine,
>>> >
>>> >
>>> >concurrency-utilities use ContextFactory for something pretty close 
(a
>>> proxying adding spec features over invocations) which is less
> "cglib-like"
>>> than "Enhancer" so I'd like to keep Factory. In the list
>>> InterceptionFactory looks clear enough. We neevr speak of business 
method
>>> anymore I think so it would add a difficulty for something very useful 
to
>>> go that deep in the naming I think.
>>> >
>>> >
>>> >
>>> >Romain Manni-Bucau
>>> >@rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>>> >
>>> >2016-11-07 15:44 GMT+01:00 Antoine Sabot-Durand <
>>> _antoine at sabot-durand.net_ <mailto:antoine at sabot-durand.net>>:
>>> >
>>> >Hi all,
>>> >>
>>> >>
>>> >>In my last review for CDI-580 (_https://github.com/cdi-spec/_
>>> cdi/pull/315), I removed all reference to proxies in Javadoc and spec 
doc
>>> following various feedback.
>>> >>So now the name of the interface is the only one dealing with Proxy, 
so
>>> we really need to find it a new name.
>>> >>I listed some proposal in PR 315:
>>> >>- InstanceEnhancer (short but not very clear)
>>> >>- BusinessMethodInvocationFactor y (more exact from spec pov, but is 
it
>>> clear from user pov?)
>>> >>- InterceptionFactory (cleared from user pov and near our initial 
name)
>>> >>- InterceptionEnhancer
>>> >>
>>> >>
>>> >>Feedback and other names are welcome.
>>> >>
>>> >>
>>> >>Antoine
>>> >>______________________________ _________________
>>> >>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_ <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.
>>> >
>>> >
>>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> 
_http://lists.jboss.org/pipermail/cdi-dev/attachments/20161108/c6e8a845/attachment.html_
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 72, Issue 5
> **************************************
>
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.
> _______________________________________________
> 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.
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.
> _______________________________________________
> 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.
>
> 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.
>
> 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
Software Engineer
Red Hat, Czech Republic
_______________________________________________
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.



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/20161116/d8b0a751/attachment-0001.html 

From john.ament at spartasystems.com  Wed Nov 16 18:08:13 2016
From: john.ament at spartasystems.com (John Ament)
Date: Wed, 16 Nov 2016 23:08:13 +0000
Subject: [cdi-dev] John offline until ~11/26
Message-ID: <CY4PR04MB0486ECEE09B1F9E41B5B120998BE0@CY4PR04MB0486.namprd04.prod.outlook.com>

Will be offline through the coming US holiday.


John


________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161116/1d894f1b/attachment.html 

From issues at jboss.org  Thu Nov 17 12:29:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Thu, 17 Nov 2016 12:29:00 -0500 (EST)
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.89433.1479403740396@Atlassian.JIRA>


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

Emily Jiang commented on CDI-627:
---------------------------------

As Mark has fixed the issue reported by Tomas, can this PR #309 be merged and then this issue can be fixed by Weld.

> 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.2.3#72005)

From issues at jboss.org  Thu Nov 17 12:30:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Thu, 17 Nov 2016 12:30:00 -0500 (EST)
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.89440.1479403800455@Atlassian.JIRA>


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

Emily Jiang edited comment on CDI-627 at 11/17/16 12:29 PM:
------------------------------------------------------------

As Mark has fixed the issue reported by Tomas, can this PR #309 be merged and then this issue can be fixed by Weld? [~antoinesabot-durand]


was (Author: emilyj):
As Mark has fixed the issue reported by Tomas, can this PR #309 be merged and then this issue can be fixed by Weld.

> 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.2.3#72005)

From issues at jboss.org  Thu Nov 17 12:30:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Thu, 17 Nov 2016 12:30:00 -0500 (EST)
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.89447.1479403800657@Atlassian.JIRA>


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

Emily Jiang edited comment on CDI-627 at 11/17/16 12:29 PM:
------------------------------------------------------------

As Mark has fixed the issue reported by Tomas, can this PR #309 be merged and then this issue can be fixed by Weld, [~antoinesabot-durand]?


was (Author: emilyj):
As Mark has fixed the issue reported by Tomas, can this PR #309 be merged and then this issue can be fixed by Weld? [~antoinesabot-durand]

> 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.2.3#72005)

From issues at jboss.org  Fri Nov 18 05:39:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 18 Nov 2016 05:39:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering
In-Reply-To: <JIRA.12574324.1433846017000@Atlassian.JIRA>
References: <JIRA.12574324.1433846017000@Atlassian.JIRA>
	<JIRA.12574324.1433846017000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574324.1433846017000.114.1479465541169@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-535:
-----------------------------
    Fix Version/s: 2.1 (Discussion)


> cdi instance injection ordering
> -------------------------------
>
>                 Key: CDI-535
>                 URL: https://issues.jboss.org/browse/CDI-535
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>            Reporter: Ochieng Marembo
>            Priority: Optional
>             Fix For: 2.1 (Discussion)
>
>
> We should allow ordering of bean instance injection using the {{Instance<MyBeanInterface>}} when an instance injection is used.
> h3. Use case:
> Developer always define a kind of chain of processor beans, which may need to run in specific order.
> h3. Current scenario:
> Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following:
> #1
> {code:java}
> private Iterable<MyBeanInterface> myBeans;
> @Inject
> void injectBeans(@Any Instance<MyBeanInterface> myBeans) {
>   //the create order does some kind of ordering on the beans.
>    this.myBeans = createOrder(myBeans);
> }
> {code}
> #2
> This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call.
> {code:java}
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> public void doSomething() {
>   Iterable<MyBeanInterface> orderedbeans = createOrder(myBeans.select(someQualifier));
> }
> {code}
> h3. Our Proposal
> We already have {{javax.annotation.Priority}} or any cdi specific annotation which we can add to {{MyBeanInterfaceImpl}} so that on injection of an {{Instance<MyBeanInterface>}}, all possible injection values are sorted based on the {{Priority.value()}} and if no annotation is defined, defaults to {{Priority.value = Integer.MAX_VALUE}}
> {code:java}
> public interface MyBeanInterface {}
> @MyQualifier
> @Priority(0)
> public class MyFirstBean implements MyBeanInterface{
> }
> @MyQualifier
> @Priority(2)
> public class MySecondBean implements MyBeanInterface{
> }
> @ApplicationScoped
> public class MyBeanProcessor {
>   //We expect that this injected instances shall be in order based on the @Priority annotation
>   @Any
>   @Inject
>   private Instance<MyBeanInterface> myBeans;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From antoine at sabot-durand.net  Fri Nov 18 09:30:44 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Fri, 18 Nov 2016 14:30:44 +0000
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword
Message-ID: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>

Hi all,


With Martin, we reword the <trim/> section like:

"If an explicit bean archive contains the `<trim/>` element in its
`beans.xml` file, types that don't have either a bean defining annotation
(as defined in <<bean_defining_annotations>>) or any scope annotation, are
removed from the set of discovered types."

Grammar feedback from native speaker is most welcome.

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161118/3cb6583b/attachment.html 

From john.ament at spartasystems.com  Fri Nov 18 10:50:02 2016
From: john.ament at spartasystems.com (John Ament)
Date: Fri, 18 Nov 2016 15:50:02 +0000
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword
In-Reply-To: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>
References: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>
Message-ID: <CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>

Here's my take..


"If an explicit bean archive contains the `<trim/>` element in its `beans.xml` file, then for a type to be discovered it must have either a scope annotation (normal or pseudo) or a bean defining annotation (as defined in <<bean_defining_annotations>>)"


John


________________________________
From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on behalf of Antoine Sabot-Durand <antoine at sabot-durand.net>
Sent: Friday, November 18, 2016 9:30 AM
To: CDI Java EE Specification
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword

Hi all,


With Martin, we reword the <trim/> section like:

"If an explicit bean archive contains the `<trim/>` element in its `beans.xml` file, types that don't have either a bean defining annotation (as defined in <<bean_defining_annotations>>) or any scope annotation, are removed from the set of discovered types."

Grammar feedback from native speaker is most welcome.

Antoine
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161118/ba8434e8/attachment-0001.html 

From antoine at sabot-durand.net  Fri Nov 18 11:16:22 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Fri, 18 Nov 2016 16:16:22 +0000
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword
In-Reply-To: <CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>
	<CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <CABu-YBStBwTdHhCDD=L2v7s1YUzSGWnvGzhQwfVsZzyEediZgA@mail.gmail.com>

Thanks John!.

On Fri, Nov 18, 2016 at 4:50 PM John Ament <john.ament at spartasystems.com>
wrote:

> Here's my take..
>
>
> "If an explicit bean archive contains the `<trim/>` element in its
> `beans.xml` file, then for a type to be discovered it must have either a
> scope annotation (normal or pseudo) or a bean defining annotation (as
> defined in <<bean_defining_annotations>>)"
>
>
> John
>
>
> ------------------------------
> *From:* cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org>
> on behalf of Antoine Sabot-Durand <antoine at sabot-durand.net>
> *Sent:* Friday, November 18, 2016 9:30 AM
> *To:* CDI Java EE Specification
> *Subject:* [cdi-dev] Need native speaker for CDI-420 (trim) reword
>
> Hi all,
>
>
> With Martin, we reword the <trim/> section like:
>
> "If an explicit bean archive contains the `<trim/>` element in its
> `beans.xml` file, types that don't have either a bean defining annotation
> (as defined in <<bean_defining_annotations>>) or any scope annotation, are
> removed from the set of discovered types."
>
> Grammar feedback from native speaker is most welcome.
>
> Antoine
> ------------------------------
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the
> sender immediately by return e-mail, delete this message, and destroy all
> physical and electronic copies. Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161118/a6857b6b/attachment.html 

From EMIJIANG at uk.ibm.com  Fri Nov 18 12:26:51 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Fri, 18 Nov 2016 17:26:51 +0000
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword
In-Reply-To: <CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>
	<CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <OF799BD487.F7690B23-ON8025806F.005FC6A0-8025806F.005FDC84@notes.na.collabserv.com>

+1 on John:o!

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
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:   John Ament <john.ament at spartasystems.com>
To:     Antoine Sabot-Durand <antoine at sabot-durand.net>, CDI Java EE 
Specification <cdi-dev at lists.jboss.org>
Date:   18/11/2016 15:54
Subject:        Re: [cdi-dev] Need native speaker for CDI-420 (trim) 
reword
Sent by:        cdi-dev-bounces at lists.jboss.org



Here's my take..

"If an explicit bean archive contains the `<trim/>` element in its 
`beans.xml` file, then for a type to be discovered it must have either a 
scope annotation (normal or pseudo) or a bean defining annotation (as 
defined in <<bean_defining_annotations>>)"

John



From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on 
behalf of Antoine Sabot-Durand <antoine at sabot-durand.net>
Sent: Friday, November 18, 2016 9:30 AM
To: CDI Java EE Specification
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword 
 
Hi all, 


With Martin, we reword the <trim/> section like:

"If an explicit bean archive contains the `<trim/>` element in its 
`beans.xml` file, types that don't have either a bean defining annotation 
(as defined in <<bean_defining_annotations>>) or any scope annotation, are 
removed from the set of discovered types."

Grammar feedback from native speaker is most welcome.

Antoine
NOTICE: This e-mail message and any attachments may contain confidential, 
proprietary, and/or privileged information which should be treated 
accordingly. If you are not the intended recipient, please notify the 
sender immediately by return e-mail, delete this message, and destroy all 
physical and electronic copies. Thank you. 
_______________________________________________
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.

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/20161118/5febfca5/attachment.html 

From mkouba at redhat.com  Mon Nov 21 03:15:12 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 21 Nov 2016 09:15:12 +0100
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword
In-Reply-To: <CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>
	<CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <abedfa76-f140-b060-11db-831fd30e14d0@redhat.com>

Hi John,

sounds good but is not entirely correct because those type ARE actually 
discovered (ProcessAnnotatedType is fired etc.) and then removed (if 
necessary) from the set of discovered types before the "Bean discovery" 
phase.

Martin

Dne 18.11.2016 v 16:50 John Ament napsal(a):
> Here's my take..
>
>
> "If an explicit bean archive contains the `<trim/>` element in its
> `beans.xml` file, then for a type to be discovered it must have either a
> scope annotation (normal or pseudo) or a bean defining annotation (as
> defined in <<bean_defining_annotations>>)"
>
>
> John
>
>
>
> ------------------------------------------------------------------------
> *From:* cdi-dev-bounces at lists.jboss.org
> <cdi-dev-bounces at lists.jboss.org> on behalf of Antoine Sabot-Durand
> <antoine at sabot-durand.net>
> *Sent:* Friday, November 18, 2016 9:30 AM
> *To:* CDI Java EE Specification
> *Subject:* [cdi-dev] Need native speaker for CDI-420 (trim) reword
>
> Hi all,
>
>
> With Martin, we reword the <trim/> section like:
>
> "If an explicit bean archive contains the `<trim/>` element in its
> `beans.xml` file, types that don't have either a bean defining
> annotation (as defined in <<bean_defining_annotations>>) or any scope
> annotation, are removed from the set of discovered types."
>
> Grammar feedback from native speaker is most welcome.
>
> Antoine
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.
>
>
> _______________________________________________
> 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
Software Engineer
Red Hat, Czech Republic

From antoine at sabot-durand.net  Mon Nov 21 05:07:52 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 21 Nov 2016 10:07:52 +0000
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword
In-Reply-To: <abedfa76-f140-b060-11db-831fd30e14d0@redhat.com>
References: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>
	<CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
	<abedfa76-f140-b060-11db-831fd30e14d0@redhat.com>
Message-ID: <CABu-YBTmDSGVB5-81zNi9cH=9nPCerqkFA=Rm1jQheWtOqQ72A@mail.gmail.com>

+1 for Martin. I didn't read with enough attention. All Types should be
discovered like in All bean-discovery mode , but only those with bean
defining annotation or scope should be eligible to become beans.

On Mon, Nov 21, 2016 at 9:15 AM Martin Kouba <mkouba at redhat.com> wrote:

> Hi John,
>
> sounds good but is not entirely correct because those type ARE actually
> discovered (ProcessAnnotatedType is fired etc.) and then removed (if
> necessary) from the set of discovered types before the "Bean discovery"
> phase.
>
> Martin
>
> Dne 18.11.2016 v 16:50 John Ament napsal(a):
> > Here's my take..
> >
> >
> > "If an explicit bean archive contains the `<trim/>` element in its
> > `beans.xml` file, then for a type to be discovered it must have either a
> > scope annotation (normal or pseudo) or a bean defining annotation (as
> > defined in <<bean_defining_annotations>>)"
> >
> >
> > John
> >
> >
> >
> > ------------------------------------------------------------------------
> > *From:* cdi-dev-bounces at lists.jboss.org
> > <cdi-dev-bounces at lists.jboss.org> on behalf of Antoine Sabot-Durand
> > <antoine at sabot-durand.net>
> > *Sent:* Friday, November 18, 2016 9:30 AM
> > *To:* CDI Java EE Specification
> > *Subject:* [cdi-dev] Need native speaker for CDI-420 (trim) reword
> >
> > Hi all,
> >
> >
> > With Martin, we reword the <trim/> section like:
> >
> > "If an explicit bean archive contains the `<trim/>` element in its
> > `beans.xml` file, types that don't have either a bean defining
> > annotation (as defined in <<bean_defining_annotations>>) or any scope
> > annotation, are removed from the set of discovered types."
> >
> > Grammar feedback from native speaker is most welcome.
> >
> > Antoine
> > ------------------------------------------------------------------------
> > NOTICE: This e-mail message and any attachments may contain
> > confidential, proprietary, and/or privileged information which should be
> > treated accordingly. If you are not the intended recipient, please
> > notify the sender immediately by return e-mail, delete this message, and
> > destroy all physical and electronic copies. Thank you.
> >
> >
> > _______________________________________________
> > 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
> Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161121/b7dd54cf/attachment-0001.html 

From issues at jboss.org  Mon Nov 21 05:10:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 21 Nov 2016 05:10:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Introduce BeanManager.event()
In-Reply-To: <JIRA.12650965.1474369800000@Atlassian.JIRA>
References: <JIRA.12650965.1474369800000@Atlassian.JIRA>
	<JIRA.12650965.1474369800000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650965.1474369800000.7655.1479723000240@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand reassigned CDI-633:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Introduce BeanManager.event()
> -----------------------------
>
>                 Key: CDI-633
>                 URL: https://issues.jboss.org/browse/CDI-633
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 21 05:10:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 21 Nov 2016 05:10:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Introduce BeanManager.event()
In-Reply-To: <JIRA.12650965.1474369800000@Atlassian.JIRA>
References: <JIRA.12650965.1474369800000@Atlassian.JIRA>
	<JIRA.12650965.1474369800000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650965.1474369800000.7658.1479723000301@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CDI-633 started by Antoine Sabot-Durand.
------------------------------------------------
> Introduce BeanManager.event()
> -----------------------------
>
>                 Key: CDI-633
>                 URL: https://issues.jboss.org/browse/CDI-633
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 21 05:41:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 21 Nov 2016 05:41:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-516) Firing events with dynamic
 parameterized types
In-Reply-To: <JIRA.12565212.1425836471000@Atlassian.JIRA>
References: <JIRA.12565212.1425836471000@Atlassian.JIRA>
	<JIRA.12565212.1425836471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565212.1425836471000.7906.1479724860993@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand reopened CDI-516:
--------------------------------------


Not a duplicate of CDI-633. It's a request to enhance event API by supporting parameterized type resolution at runtime.

> Firing events with dynamic parameterized types
> ----------------------------------------------
>
>                 Key: CDI-516
>                 URL: https://issues.jboss.org/browse/CDI-516
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antonin Stefanutti
>             Fix For: 2.1 (Discussion)
>
>
> For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
> {quote}
> If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
> If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
> {quote}
> If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
> {code}
> @Inject
> Event<Object> event;
> event.select(new TypeLiteral<String>() {});
> {code}
> It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
> Yet, there are use cases where that need is valid, for example:
> {code}
> <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
>     // Represents the runtime type for T
>     Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
>     String uri = endpointUri(type, ip.getQualifiers());
>     if (context.hasEndpoint(uri) == null) {
>         // Work around to pass the dynamic type
>         TypeLiteral<T> literal = new TypeLiteral<T>() {};
>         for (Field field : TypeLiteral.class.getDeclaredFields()) {
>              if (field.getType().equals(Type.class)) {
>                 field.setAccessible(true);
>                 field.set(literal, type);
>                 break;
>             }
>         }
>         // Here we used the dynamic type
>         Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
>         context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
>     }
>     return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
> }
> {code}
> In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
> Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
> {code}
> public void fireEvent(Object event, Type type, Annotation... qualifiers);
> {code}
> That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb98f87b07739aa9ddfc44191/impl/src/main/java/org/apache/camel/cdi/CdiCamelFactory.java#L91] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi].



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 21 05:41:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 21 Nov 2016 05:41:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-516) Firing events with dynamic
 parameterized types
In-Reply-To: <JIRA.12565212.1425836471000@Atlassian.JIRA>
References: <JIRA.12565212.1425836471000@Atlassian.JIRA>
	<JIRA.12565212.1425836471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565212.1425836471000.7912.1479724861213@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-516:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)


> Firing events with dynamic parameterized types
> ----------------------------------------------
>
>                 Key: CDI-516
>                 URL: https://issues.jboss.org/browse/CDI-516
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antonin Stefanutti
>             Fix For: 2.1 (Discussion)
>
>
> For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
> {quote}
> If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
> If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
> {quote}
> If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
> {code}
> @Inject
> Event<Object> event;
> event.select(new TypeLiteral<String>() {});
> {code}
> It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
> Yet, there are use cases where that need is valid, for example:
> {code}
> <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
>     // Represents the runtime type for T
>     Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
>     String uri = endpointUri(type, ip.getQualifiers());
>     if (context.hasEndpoint(uri) == null) {
>         // Work around to pass the dynamic type
>         TypeLiteral<T> literal = new TypeLiteral<T>() {};
>         for (Field field : TypeLiteral.class.getDeclaredFields()) {
>              if (field.getType().equals(Type.class)) {
>                 field.setAccessible(true);
>                 field.set(literal, type);
>                 break;
>             }
>         }
>         // Here we used the dynamic type
>         Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
>         context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
>     }
>     return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
> }
> {code}
> In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
> Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
> {code}
> public void fireEvent(Object event, Type type, Annotation... qualifiers);
> {code}
> That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb98f87b07739aa9ddfc44191/impl/src/main/java/org/apache/camel/cdi/CdiCamelFactory.java#L91] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi].



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 21 05:41:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 21 Nov 2016 05:41:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-516) Firing events with dynamic
 parameterized types
In-Reply-To: <JIRA.12565212.1425836471000@Atlassian.JIRA>
References: <JIRA.12565212.1425836471000@Atlassian.JIRA>
	<JIRA.12565212.1425836471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565212.1425836471000.7918.1479724861349@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-516:
-------------------------------------
    Release Notes Text:   (was: Should be resolved with CDI-633)


> Firing events with dynamic parameterized types
> ----------------------------------------------
>
>                 Key: CDI-516
>                 URL: https://issues.jboss.org/browse/CDI-516
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antonin Stefanutti
>             Fix For: 2.1 (Discussion)
>
>
> For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
> {quote}
> If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
> If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
> {quote}
> If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
> {code}
> @Inject
> Event<Object> event;
> event.select(new TypeLiteral<String>() {});
> {code}
> It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
> Yet, there are use cases where that need is valid, for example:
> {code}
> <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
>     // Represents the runtime type for T
>     Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
>     String uri = endpointUri(type, ip.getQualifiers());
>     if (context.hasEndpoint(uri) == null) {
>         // Work around to pass the dynamic type
>         TypeLiteral<T> literal = new TypeLiteral<T>() {};
>         for (Field field : TypeLiteral.class.getDeclaredFields()) {
>              if (field.getType().equals(Type.class)) {
>                 field.setAccessible(true);
>                 field.set(literal, type);
>                 break;
>             }
>         }
>         // Here we used the dynamic type
>         Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
>         context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
>     }
>     return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
> }
> {code}
> In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
> Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
> {code}
> public void fireEvent(Object event, Type type, Annotation... qualifiers);
> {code}
> That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb98f87b07739aa9ddfc44191/impl/src/main/java/org/apache/camel/cdi/CdiCamelFactory.java#L91] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi].



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 21 05:44:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 21 Nov 2016 05:44:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Introduce BeanManager.event()
In-Reply-To: <JIRA.12650965.1474369800000@Atlassian.JIRA>
References: <JIRA.12650965.1474369800000@Atlassian.JIRA>
	<JIRA.12650965.1474369800000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650965.1474369800000.7954.1479725040111@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-633:
------------------------------------------

[~tzwoenn] I reopened CDI-516 and targeted to be discussed during CDI 2.1.
This ticket is only a mean to get a more standard and typesafe way to fire event from the BeanManager.

> Introduce BeanManager.event()
> -----------------------------
>
>                 Key: CDI-633
>                 URL: https://issues.jboss.org/browse/CDI-633
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 21 06:48:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 21 Nov 2016 06:48:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow
 session lifecycle
In-Reply-To: <JIRA.12560194.1420448865000@Atlassian.JIRA>
References: <JIRA.12560194.1420448865000@Atlassian.JIRA>
	<JIRA.12560194.1420448865000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560194.1420448865000.8616.1479728880274@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-497:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 .Final)


> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
>                 Key: CDI-497
>                 URL: https://issues.jboss.org/browse/CDI-497
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>             Fix For: 2.1 (Discussion)
>
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 21 07:59:00 2016
From: issues at jboss.org (Nico Schlebusch (JIRA))
Date: Mon, 21 Nov 2016 07:59:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-649) Typo in specification document -
	2.0-EDR2
In-Reply-To: <JIRA.12662784.1479733104000@Atlassian.JIRA>
References: <JIRA.12662784.1479733104000@Atlassian.JIRA>
	<JIRA.12662784.1479733104896@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662784.1479733104000.9117.1479733140687@Atlassian.JIRA>

Nico Schlebusch created CDI-649:
-----------------------------------

             Summary: Typo in specification document - 2.0-EDR2
                 Key: CDI-649
                 URL: https://issues.jboss.org/browse/CDI-649
             Project: CDI Specification Issues
          Issue Type: Bug
          Components: Javadoc and API
    Affects Versions: 2.0-EDR2
         Environment: Documentation - https://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html
            Reporter: Nico Schlebusch


The is a typo in the "*Preface*" of the CDI 2 EDR2 spec.

In the "*Mayor Problems*" section, first bullet point:
{noformat}
The spec was split in 3 parts as desibed in Organisation of this document to add the support for Java SE.
{noformat}
The typo is in the word *desibed* which should be *described*:
{noformat}
The spec was split in 3 parts as described in Organisation of this document to add the support for Java SE.
{noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 21 08:13:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 21 Nov 2016 08:13:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-649) Typo in specification document -
	2.0-EDR2
In-Reply-To: <JIRA.12662784.1479733105000@Atlassian.JIRA>
References: <JIRA.12662784.1479733105000@Atlassian.JIRA>
	<JIRA.12662784.1479733105000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662784.1479733105000.9255.1479733980450@Atlassian.JIRA>


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

Tomas Remes commented on CDI-649:
---------------------------------

This has been already fixed https://github.com/cdi-spec/cdi/commit/898a17e62c554b97f2a3552546d334dbaf13fdf8 but thanks anyway:-)

> Typo in specification document - 2.0-EDR2
> -----------------------------------------
>
>                 Key: CDI-649
>                 URL: https://issues.jboss.org/browse/CDI-649
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 2.0-EDR2
>         Environment: Documentation - https://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html
>            Reporter: Nico Schlebusch
>
> The is a typo in the "*Preface*" of the CDI 2 EDR2 spec.
> In the "*Mayor Problems*" section, first bullet point:
> {noformat}
> The spec was split in 3 parts as desibed in Organisation of this document to add the support for Java SE.
> {noformat}
> The typo is in the word *desibed* which should be *described*:
> {noformat}
> The spec was split in 3 parts as described in Organisation of this document to add the support for Java SE.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mkouba at redhat.com  Mon Nov 21 08:25:28 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 21 Nov 2016 14:25:28 +0100
Subject: [cdi-dev] CDI-471 and repeatable annotations
Message-ID: <4f3a4d70-fb55-edd1-1f61-80da5a105eb7@redhat.com>

Dear EG,

during the review of CDI API 2.0.Alpha5 with modified Annotated SPI [1] 
I came across few questionable parts:

1. We should be more clear that the original methods like 
Annotated.getAnnotations() or Annotated.isAnnotationPresent() DO NOT 
support repeatable annotations - this is what Reflection API does to 
remain backward compatible - see also AnnotatedElement javadoc [2]
2. Thus AnnotatedElement.getAnnotation(Class<T>) should not be 
deprecated - for the same reasons as 
AnnotatedElement.getAnnotation(Class<T>) is not
3. We should provide a default implementation of 
Annotated.getAnnotations(Class<T>), otherwise a lot of extensions 
providing their own Annotated implementations would be broken
4. We should consider renaming the method to "getAnnotationsByType()" to 
keep it simple for users used to Reflection API

Thanks,

Martin

[1]
https://github.com/cdi-spec/cdi/pull/330

[2]
https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html

From john.ament at spartasystems.com  Mon Nov 21 08:47:00 2016
From: john.ament at spartasystems.com (John Ament)
Date: Mon, 21 Nov 2016 13:47:00 +0000
Subject: [cdi-dev] CDI-471 and repeatable annotations
In-Reply-To: <4f3a4d70-fb55-edd1-1f61-80da5a105eb7@redhat.com>
References: <4f3a4d70-fb55-edd1-1f61-80da5a105eb7@redhat.com>
Message-ID: <CY4PR04MB04866E231D5DD493845B9E1198B50@CY4PR04MB0486.namprd04.prod.outlook.com>

Martin,


I'll make these changes for #1-#3.  I'm not in favor of #4.  Its not consistent with our existing method.  (I'd prefer consistency of our API over consistency with the Java lang's spec)


I may get to them this evening.


John


________________________________
From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on behalf of Martin Kouba <mkouba at redhat.com>
Sent: Monday, November 21, 2016 8:25 AM
To: cdi-dev
Subject: [cdi-dev] CDI-471 and repeatable annotations

Dear EG,

during the review of CDI API 2.0.Alpha5 with modified Annotated SPI [1]
I came across few questionable parts:

1. We should be more clear that the original methods like
Annotated.getAnnotations() or Annotated.isAnnotationPresent() DO NOT
support repeatable annotations - this is what Reflection API does to
remain backward compatible - see also AnnotatedElement javadoc [2]
2. Thus AnnotatedElement.getAnnotation(Class<T>) should not be
deprecated - for the same reasons as
AnnotatedElement.getAnnotation(Class<T>) is not
3. We should provide a default implementation of
Annotated.getAnnotations(Class<T>), otherwise a lot of extensions
providing their own Annotated implementations would be broken
4. We should consider renaming the method to "getAnnotationsByType()" to
keep it simple for users used to Reflection API

Thanks,

Martin

[1]
https://github.com/cdi-spec/cdi/pull/330
[https://avatars3.githubusercontent.com/u/108167?v=3&s=400]<https://github.com/cdi-spec/cdi/pull/330>

CDI-471 Introduce SPI for retrieving multiple annotations of the same... by johnament ? Pull Request #330 ? cdi-spec/cdi<https://github.com/cdi-spec/cdi/pull/330>
github.com
... type, deprecating the old one. Updated spec docs for qualifiers to reflect repeatability and spec docs for annotated for new method.




[2]
https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html
AnnotatedElement (Java Platform SE 8 ) - Oracle<https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html>
docs.oracle.com
Represents an annotated element of the program currently running in this VM. This interface allows annotations to be read reflectively. All annotations returned by ...



_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.




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.
Apache License, Version 2.0<http://www.apache.org/licenses/LICENSE-2.0.html>
www.apache.org
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.



________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161121/caa7ac22/attachment.html 

From john.ament at spartasystems.com  Mon Nov 21 08:53:33 2016
From: john.ament at spartasystems.com (John Ament)
Date: Mon, 21 Nov 2016 13:53:33 +0000
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword
In-Reply-To: <CABu-YBTmDSGVB5-81zNi9cH=9nPCerqkFA=Rm1jQheWtOqQ72A@mail.gmail.com>
References: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>
	<CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
	<abedfa76-f140-b060-11db-831fd30e14d0@redhat.com>,
	<CABu-YBTmDSGVB5-81zNi9cH=9nPCerqkFA=Rm1jQheWtOqQ72A@mail.gmail.com>
Message-ID: <CY4PR04MB04867029EF5CD3D917E83EDD98B50@CY4PR04MB0486.namprd04.prod.outlook.com>

What you're referring to is a nuance that most users don't follow.  A PAT is fired for essentially every class found.  If this works differently (e.g. for bean-discovery-mode=none) then it may be worth calling this out, but as of now it should be implicit that PAT works differently.


John


________________________________
From: Antoine Sabot-Durand <antoine at sabot-durand.net>
Sent: Monday, November 21, 2016 5:07 AM
To: Martin Kouba; John Ament; CDI Java EE Specification
Subject: Re: [cdi-dev] Need native speaker for CDI-420 (trim) reword

+1 for Martin. I didn't read with enough attention. All Types should be discovered like in All bean-discovery mode , but only those with bean defining annotation or scope should be eligible to become beans.

On Mon, Nov 21, 2016 at 9:15 AM Martin Kouba <mkouba at redhat.com<mailto:mkouba at redhat.com>> wrote:
Hi John,

sounds good but is not entirely correct because those type ARE actually
discovered (ProcessAnnotatedType is fired etc.) and then removed (if
necessary) from the set of discovered types before the "Bean discovery"
phase.

Martin

Dne 18.11.2016 v 16:50 John Ament napsal(a):
> Here's my take..
>
>
> "If an explicit bean archive contains the `<trim/>` element in its
> `beans.xml` file, then for a type to be discovered it must have either a
> scope annotation (normal or pseudo) or a bean defining annotation (as
> defined in <<bean_defining_annotations>>)"
>
>
> John
>
>
>
> ------------------------------------------------------------------------
> *From:* cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org>
> <cdi-dev-bounces at lists.jboss.org<mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Antoine Sabot-Durand
> <antoine at sabot-durand.net<mailto:antoine at sabot-durand.net>>
> *Sent:* Friday, November 18, 2016 9:30 AM
> *To:* CDI Java EE Specification
> *Subject:* [cdi-dev] Need native speaker for CDI-420 (trim) reword
>
> Hi all,
>
>
> With Martin, we reword the <trim/> section like:
>
> "If an explicit bean archive contains the `<trim/>` element in its
> `beans.xml` file, types that don't have either a bean defining
> annotation (as defined in <<bean_defining_annotations>>) or any scope
> annotation, are removed from the set of discovered types."
>
> Grammar feedback from native speaker is most welcome.
>
> Antoine
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.
>
>
> _______________________________________________
> 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.
>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161121/b2d1b2ee/attachment-0001.html 

From mkouba at redhat.com  Mon Nov 21 09:00:46 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 21 Nov 2016 15:00:46 +0100
Subject: [cdi-dev] CDI-471 and repeatable annotations
In-Reply-To: <CY4PR04MB04866E231D5DD493845B9E1198B50@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <4f3a4d70-fb55-edd1-1f61-80da5a105eb7@redhat.com>
	<CY4PR04MB04866E231D5DD493845B9E1198B50@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <4dae4258-ce99-7c7e-a7a8-8e98b6167144@redhat.com>

Hi John,

No problem, #4 was optional ;-)

By the way, this is the default implementation from Weld experimental API:
https://github.com/weld/api/blob/master/weld/src/main/java/org/jboss/weld/experimental/ExperimentalAnnotated.java

It's not perfect. E.g. Class.getMethod() should be used with privileges 
enabled if a SecurityManager is used. But it could be a good base to 
start with.

Thanks,

Martin

Dne 21.11.2016 v 14:47 John Ament napsal(a):
> Martin,
>
>
> I'll make these changes for #1-#3.  I'm not in favor of #4.  Its not
> consistent with our existing method.  (I'd prefer consistency of our API
> over consistency with the Java lang's spec)
>
>
> I may get to them this evening.
>
>
> John
>
>
>
> ------------------------------------------------------------------------
> *From:* cdi-dev-bounces at lists.jboss.org
> <cdi-dev-bounces at lists.jboss.org> on behalf of Martin Kouba
> <mkouba at redhat.com>
> *Sent:* Monday, November 21, 2016 8:25 AM
> *To:* cdi-dev
> *Subject:* [cdi-dev] CDI-471 and repeatable annotations
>
> Dear EG,
>
> during the review of CDI API 2.0.Alpha5 with modified Annotated SPI [1]
> I came across few questionable parts:
>
> 1. We should be more clear that the original methods like
> Annotated.getAnnotations() or Annotated.isAnnotationPresent() DO NOT
> support repeatable annotations - this is what Reflection API does to
> remain backward compatible - see also AnnotatedElement javadoc [2]
> 2. Thus AnnotatedElement.getAnnotation(Class<T>) should not be
> deprecated - for the same reasons as
> AnnotatedElement.getAnnotation(Class<T>) is not
> 3. We should provide a default implementation of
> Annotated.getAnnotations(Class<T>), otherwise a lot of extensions
> providing their own Annotated implementations would be broken
> 4. We should consider renaming the method to "getAnnotationsByType()" to
> keep it simple for users used to Reflection API
>
> Thanks,
>
> Martin
>
> [1]
> https://github.com/cdi-spec/cdi/pull/330
> <https://github.com/cdi-spec/cdi/pull/330>
> 	
> CDI-471 Introduce SPI for retrieving multiple annotations of the same?
> by johnament ? Pull Request #330 ? cdi-spec/cdi
> <https://github.com/cdi-spec/cdi/pull/330>
> github.com
> ? type, deprecating the old one. Updated spec docs for qualifiers to
> reflect repeatability and spec docs for annotated for new method.
>
>
>
>
> [2]
> https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html
>
> AnnotatedElement (Java Platform SE 8 ) - Oracle
> <https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html>
> docs.oracle.com
> Represents an annotated element of the program currently running in this
> VM. This interface allows annotations to be read reflectively. All
> annotations returned by ...
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> cdi-dev Info Page - JBoss Developer
> <https://lists.jboss.org/mailman/listinfo/cdi-dev>
> lists.jboss.org
> List to discuss the development of CDI (the specification) To see the
> collection of prior postings to the list, visit the cdi-dev Archives.
>

From antoine at sabot-durand.net  Mon Nov 21 09:28:00 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 21 Nov 2016 14:28:00 +0000
Subject: [cdi-dev] CDI 2.0 Alpha 5 hit Maven cetral
Message-ID: <CABu-YBTaZHNQDHGFgyQXt2a4r7GACBYcOswAgiiFM=r1+Ub=KA@mail.gmail.com>

Hi all,

A new alpha version of CDI 2.0 API was released on is now available on
Maven Central, to help Weld and TCK team to work on their project.
It's also a convenient way to experiment our new API.

Check:

<dependency>
    <groupId>javax.enterprise</groupId>
    <artifactId>cdi-api</artifactId>
    <version>2.0.Alpha5</version>
</dependency>

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161121/2f30a1cb/attachment.html 

From mkouba at redhat.com  Mon Nov 21 09:31:47 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 21 Nov 2016 15:31:47 +0100
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword
In-Reply-To: <CY4PR04MB04867029EF5CD3D917E83EDD98B50@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>
	<CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
	<abedfa76-f140-b060-11db-831fd30e14d0@redhat.com>
	<CABu-YBTmDSGVB5-81zNi9cH=9nPCerqkFA=Rm1jQheWtOqQ72A@mail.gmail.com>
	<CY4PR04MB04867029EF5CD3D917E83EDD98B50@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <569fd152-1251-2bbe-f75f-5496a9cb29fc@redhat.com>

Well, we're discussing the spec wording which should be clear and 
accurate. What users follow or not is a different thing, and should be 
covered in tutorials, blogposts and docs.

To sum it up:

* type discovery is covered in "12.4.1. Type discovery"
* the "trimming" process happens AFTER type discovery and BEFORE bean 
discovery ("12.4.3. Bean discovery")

Therefore, we cannot say that "for a type to be discovered it must 
have..." because for trimmed archives the type is always discovered and 
then, if it does not meet the conditions, thrown away (no beans are 
created from it).

Martin

Dne 21.11.2016 v 14:53 John Ament napsal(a):
> What you're referring to is a nuance that most users don't follow.  A
> PAT is fired for essentially every class found.  If this works
> differently (e.g. for bean-discovery-mode=none) then it may be worth
> calling this out, but as of now it should be implicit that PAT works
> differently.
>
>
> John
>
>
>
> ------------------------------------------------------------------------
> *From:* Antoine Sabot-Durand <antoine at sabot-durand.net>
> *Sent:* Monday, November 21, 2016 5:07 AM
> *To:* Martin Kouba; John Ament; CDI Java EE Specification
> *Subject:* Re: [cdi-dev] Need native speaker for CDI-420 (trim) reword
>
> +1 for Martin. I didn't read with enough attention. All Types should be
> discovered like in All bean-discovery mode , but only those with bean
> defining annotation or scope should be eligible to become beans.
>
> On Mon, Nov 21, 2016 at 9:15 AM Martin Kouba <mkouba at redhat.com
> <mailto:mkouba at redhat.com>> wrote:
>
>     Hi John,
>
>     sounds good but is not entirely correct because those type ARE actually
>     discovered (ProcessAnnotatedType is fired etc.) and then removed (if
>     necessary) from the set of discovered types before the "Bean discovery"
>     phase.
>
>     Martin
>
>     Dne 18.11.2016 v 16:50 John Ament napsal(a):
>     > Here's my take..
>     >
>     >
>     > "If an explicit bean archive contains the `<trim/>` element in its
>     > `beans.xml` file, then for a type to be discovered it must have
>     either a
>     > scope annotation (normal or pseudo) or a bean defining annotation (as
>     > defined in <<bean_defining_annotations>>)"
>     >
>     >
>     > John
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     > *From:* cdi-dev-bounces at lists.jboss.org
>     <mailto:cdi-dev-bounces at lists.jboss.org>
>     > <cdi-dev-bounces at lists.jboss.org
>     <mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Antoine
>     Sabot-Durand
>     > <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>>
>     > *Sent:* Friday, November 18, 2016 9:30 AM
>     > *To:* CDI Java EE Specification
>     > *Subject:* [cdi-dev] Need native speaker for CDI-420 (trim) reword
>     >
>     > Hi all,
>     >
>     >
>     > With Martin, we reword the <trim/> section like:
>     >
>     > "If an explicit bean archive contains the `<trim/>` element in its
>     > `beans.xml` file, types that don't have either a bean defining
>     > annotation (as defined in <<bean_defining_annotations>>) or any scope
>     > annotation, are removed from the set of discovered types."
>     >
>     > Grammar feedback from native speaker is most welcome.
>     >
>     > Antoine
>     >
>     ------------------------------------------------------------------------
>     > NOTICE: This e-mail message and any attachments may contain
>     > confidential, proprietary, and/or privileged information which
>     should be
>     > treated accordingly. If you are not the intended recipient, please
>     > notify the sender immediately by return e-mail, delete this
>     message, and
>     > destroy all physical and electronic copies. Thank you.
>     >
>     >
>     > _______________________________________________
>     > 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.
>     >
>
>     --
>     Martin Kouba
>     Software Engineer
>     Red Hat, Czech Republic
>
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From issues at jboss.org  Mon Nov 21 09:46:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 21 Nov 2016 09:46:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-612)
 ObserverMethodConfigurator.notifyWith() should probably accept a functional
 interface whose method throws java.lang.Exception
In-Reply-To: <JIRA.12629421.1464951703000@Atlassian.JIRA>
References: <JIRA.12629421.1464951703000@Atlassian.JIRA>
	<JIRA.12629421.1464951703000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629421.1464951703000.10231.1479739560042@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reassigned CDI-612:
--------------------------------

    Assignee: Martin Kouba


> ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-612
>                 URL: https://issues.jboss.org/browse/CDI-612
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0-EDR1
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> The regular observer methods may also throw checked exceptions (wrapped and rethrown as an (unchecked) {{ObserverException}}).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From EMIJIANG at uk.ibm.com  Mon Nov 21 12:05:54 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Mon, 21 Nov 2016 17:05:54 +0000
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword
In-Reply-To: <569fd152-1251-2bbe-f75f-5496a9cb29fc@redhat.com>
References: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>	<CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
	<abedfa76-f140-b060-11db-831fd30e14d0@redhat.com>	<CABu-YBTmDSGVB5-81zNi9cH=9nPCerqkFA=Rm1jQheWtOqQ72A@mail.gmail.com>
	<CY4PR04MB04867029EF5CD3D917E83EDD98B50@CY4PR04MB0486.namprd04.prod.outlook.com>
	<569fd152-1251-2bbe-f75f-5496a9cb29fc@redhat.com>
Message-ID: <OFE514AC72.EB76F5F3-ON00258072.005D5930-80258072.005DED60@notes.na.collabserv.com>

+1 on Martin's suggestion!
How about the following rewording?
 "If an explicit bean archive contains the `<trim/>` element in its 
`beans.xml` file, then for a type to be discovered it must have either a
scope annotation (normal or pseudo) or a bean defining annotation (as 
defined in <<bean_defining_annotations>>)"
=>
 "If an explicit bean archive contains the `<trim/>` element in its 
`beans.xml` file, then for a class to be discovered as a bean it must have 
either a scope annotation (normal or pseudo) or a bean defining annotation 
(as defined in <<bean_defining_annotations>>)"

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
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:     John Ament <john.ament at spartasystems.com>, Antoine Sabot-Durand 
<antoine at sabot-durand.net>, CDI Java EE Specification 
<cdi-dev at lists.jboss.org>
Date:   21/11/2016 14:34
Subject:        Re: [cdi-dev] Need native speaker for CDI-420 (trim) 
reword
Sent by:        cdi-dev-bounces at lists.jboss.org



Well, we're discussing the spec wording which should be clear and 
accurate. What users follow or not is a different thing, and should be 
covered in tutorials, blogposts and docs.

To sum it up:

* type discovery is covered in "12.4.1. Type discovery"
* the "trimming" process happens AFTER type discovery and BEFORE bean 
discovery ("12.4.3. Bean discovery")

Therefore, we cannot say that "for a type to be discovered it must 
have..." because for trimmed archives the type is always discovered and 
then, if it does not meet the conditions, thrown away (no beans are 
created from it).

Martin

Dne 21.11.2016 v 14:53 John Ament napsal(a):
> What you're referring to is a nuance that most users don't follow.  A
> PAT is fired for essentially every class found.  If this works
> differently (e.g. for bean-discovery-mode=none) then it may be worth
> calling this out, but as of now it should be implicit that PAT works
> differently.
>
>
> John
>
>
>
> ------------------------------------------------------------------------
> *From:* Antoine Sabot-Durand <antoine at sabot-durand.net>
> *Sent:* Monday, November 21, 2016 5:07 AM
> *To:* Martin Kouba; John Ament; CDI Java EE Specification
> *Subject:* Re: [cdi-dev] Need native speaker for CDI-420 (trim) reword
>
> +1 for Martin. I didn't read with enough attention. All Types should be
> discovered like in All bean-discovery mode , but only those with bean
> defining annotation or scope should be eligible to become beans.
>
> On Mon, Nov 21, 2016 at 9:15 AM Martin Kouba <mkouba at redhat.com
> <mailto:mkouba at redhat.com>> wrote:
>
>     Hi John,
>
>     sounds good but is not entirely correct because those type ARE 
actually
>     discovered (ProcessAnnotatedType is fired etc.) and then removed (if
>     necessary) from the set of discovered types before the "Bean 
discovery"
>     phase.
>
>     Martin
>
>     Dne 18.11.2016 v 16:50 John Ament napsal(a):
>     > Here's my take..
>     >
>     >
>     > "If an explicit bean archive contains the `<trim/>` element in its
>     > `beans.xml` file, then for a type to be discovered it must have
>     either a
>     > scope annotation (normal or pseudo) or a bean defining annotation 
(as
>     > defined in <<bean_defining_annotations>>)"
>     >
>     >
>     > John
>     >
>     >
>     >
>     >
> ------------------------------------------------------------------------
>     > *From:* cdi-dev-bounces at lists.jboss.org
>     <mailto:cdi-dev-bounces at lists.jboss.org>
>     > <cdi-dev-bounces at lists.jboss.org
>     <mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Antoine
>     Sabot-Durand
>     > <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>>
>     > *Sent:* Friday, November 18, 2016 9:30 AM
>     > *To:* CDI Java EE Specification
>     > *Subject:* [cdi-dev] Need native speaker for CDI-420 (trim) reword
>     >
>     > Hi all,
>     >
>     >
>     > With Martin, we reword the <trim/> section like:
>     >
>     > "If an explicit bean archive contains the `<trim/>` element in its
>     > `beans.xml` file, types that don't have either a bean defining
>     > annotation (as defined in <<bean_defining_annotations>>) or any 
scope
>     > annotation, are removed from the set of discovered types."
>     >
>     > Grammar feedback from native speaker is most welcome.
>     >
>     > Antoine
>     >
> ------------------------------------------------------------------------
>     > NOTICE: This e-mail message and any attachments may contain
>     > confidential, proprietary, and/or privileged information which
>     should be
>     > treated accordingly. If you are not the intended recipient, please
>     > notify the sender immediately by return e-mail, delete this
>     message, and
>     > destroy all physical and electronic copies. Thank you.
>     >
>     >
>     > _______________________________________________
>     > 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.
>     >
>
>     --
>     Martin Kouba
>     Software Engineer
>     Red Hat, Czech Republic
>
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
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.



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/20161121/042c407e/attachment-0001.html 

From john.ament at spartasystems.com  Mon Nov 21 20:51:20 2016
From: john.ament at spartasystems.com (John Ament)
Date: Tue, 22 Nov 2016 01:51:20 +0000
Subject: [cdi-dev] Need native speaker for CDI-420 (trim) reword
In-Reply-To: <OFE514AC72.EB76F5F3-ON00258072.005D5930-80258072.005DED60@notes.na.collabserv.com>
References: <CABu-YBQCq__ZHA3UZ1EJ9VJN50pUUv_iiDHrCOhfqLJirDpqtQ@mail.gmail.com>
	<CY4PR04MB0486CF0041BB5F973EF24B7098B00@CY4PR04MB0486.namprd04.prod.outlook.com>
	<abedfa76-f140-b060-11db-831fd30e14d0@redhat.com>
	<CABu-YBTmDSGVB5-81zNi9cH=9nPCerqkFA=Rm1jQheWtOqQ72A@mail.gmail.com>
	<CY4PR04MB04867029EF5CD3D917E83EDD98B50@CY4PR04MB0486.namprd04.prod.outlook.com>
	<569fd152-1251-2bbe-f75f-5496a9cb29fc@redhat.com>,
	<OFE514AC72.EB76F5F3-ON00258072.005D5930-80258072.005DED60@notes.na.collabserv.com>
Message-ID: <CY4PR04MB04860A03D4DEE28BEF51FF3698B40@CY4PR04MB0486.namprd04.prod.outlook.com>

Makes sense if we want to add "as a bean" to the discovered text as a classifier for its usage.


John


________________________________
From: Emily Jiang <EMIJIANG at uk.ibm.com>
Sent: Monday, November 21, 2016 12:05 PM
To: Martin Kouba
Cc: John Ament; Antoine Sabot-Durand; CDI Java EE Specification
Subject: Re: [cdi-dev] Need native speaker for CDI-420 (trim) reword

+1 on Martin's suggestion!
How about the following rewording?
 "If an explicit bean archive contains the `<trim/>` element in its `beans.xml` file, then for a type to be discovered it must have either a
scope annotation (normal or pseudo) or a bean defining annotation (as defined in <<bean_defining_annotations>>)"
=>
 "If an explicit bean archive contains the `<trim/>` element in its `beans.xml` file, then for a class to be discovered as a bean it must have either a scope annotation (normal or pseudo) or a bean defining annotation (as defined in <<bean_defining_annotations>>)"

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead

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:        John Ament <john.ament at spartasystems.com>, Antoine Sabot-Durand <antoine at sabot-durand.net>, CDI Java EE Specification <cdi-dev at lists.jboss.org>
Date:        21/11/2016 14:34
Subject:        Re: [cdi-dev] Need native speaker for CDI-420 (trim) reword
Sent by:        cdi-dev-bounces at lists.jboss.org
________________________________



Well, we're discussing the spec wording which should be clear and
accurate. What users follow or not is a different thing, and should be
covered in tutorials, blogposts and docs.

To sum it up:

* type discovery is covered in "12.4.1. Type discovery"
* the "trimming" process happens AFTER type discovery and BEFORE bean
discovery ("12.4.3. Bean discovery")

Therefore, we cannot say that "for a type to be discovered it must
have..." because for trimmed archives the type is always discovered and
then, if it does not meet the conditions, thrown away (no beans are
created from it).

Martin

Dne 21.11.2016 v 14:53 John Ament napsal(a):
> What you're referring to is a nuance that most users don't follow.  A
> PAT is fired for essentially every class found.  If this works
> differently (e.g. for bean-discovery-mode=none) then it may be worth
> calling this out, but as of now it should be implicit that PAT works
> differently.
>
>
> John
>
>
>
> ------------------------------------------------------------------------
> *From:* Antoine Sabot-Durand <antoine at sabot-durand.net>
> *Sent:* Monday, November 21, 2016 5:07 AM
> *To:* Martin Kouba; John Ament; CDI Java EE Specification
> *Subject:* Re: [cdi-dev] Need native speaker for CDI-420 (trim) reword
>
> +1 for Martin. I didn't read with enough attention. All Types should be
> discovered like in All bean-discovery mode , but only those with bean
> defining annotation or scope should be eligible to become beans.
>
> On Mon, Nov 21, 2016 at 9:15 AM Martin Kouba <mkouba at redhat.com
> <mailto:mkouba at redhat.com>> wrote:
>
>     Hi John,
>
>     sounds good but is not entirely correct because those type ARE actually
>     discovered (ProcessAnnotatedType is fired etc.) and then removed (if
>     necessary) from the set of discovered types before the "Bean discovery"
>     phase.
>
>     Martin
>
>     Dne 18.11.2016 v 16:50 John Ament napsal(a):
>     > Here's my take..
>     >
>     >
>     > "If an explicit bean archive contains the `<trim/>` element in its
>     > `beans.xml` file, then for a type to be discovered it must have
>     either a
>     > scope annotation (normal or pseudo) or a bean defining annotation (as
>     > defined in <<bean_defining_annotations>>)"
>     >
>     >
>     > John
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     > *From:* cdi-dev-bounces at lists.jboss.org
>     <mailto:cdi-dev-bounces at lists.jboss.org>
>     > <cdi-dev-bounces at lists.jboss.org
>     <mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Antoine
>     Sabot-Durand
>     > <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>>
>     > *Sent:* Friday, November 18, 2016 9:30 AM
>     > *To:* CDI Java EE Specification
>     > *Subject:* [cdi-dev] Need native speaker for CDI-420 (trim) reword
>     >
>     > Hi all,
>     >
>     >
>     > With Martin, we reword the <trim/> section like:
>     >
>     > "If an explicit bean archive contains the `<trim/>` element in its
>     > `beans.xml` file, types that don't have either a bean defining
>     > annotation (as defined in <<bean_defining_annotations>>) or any scope
>     > annotation, are removed from the set of discovered types."
>     >
>     > Grammar feedback from native speaker is most welcome.
>     >
>     > Antoine
>     >
>     ------------------------------------------------------------------------
>     > NOTICE: This e-mail message and any attachments may contain
>     > confidential, proprietary, and/or privileged information which
>     should be
>     > treated accordingly. If you are not the intended recipient, please
>     > notify the sender immediately by return e-mail, delete this
>     message, and
>     > destroy all physical and electronic copies. Thank you.
>     >
>     >
>     > _______________________________________________
>     > 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.
>     >
>
>     --
>     Martin Kouba
>     Software Engineer
>     Red Hat, Czech Republic
>
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
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.



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
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161122/1368c61c/attachment.html 

From john.ament at spartasystems.com  Mon Nov 21 21:26:42 2016
From: john.ament at spartasystems.com (John Ament)
Date: Tue, 22 Nov 2016 02:26:42 +0000
Subject: [cdi-dev] CDI-471 and repeatable annotations
In-Reply-To: <4dae4258-ce99-7c7e-a7a8-8e98b6167144@redhat.com>
References: <4f3a4d70-fb55-edd1-1f61-80da5a105eb7@redhat.com>
	<CY4PR04MB04866E231D5DD493845B9E1198B50@CY4PR04MB0486.namprd04.prod.outlook.com>,
	<4dae4258-ce99-7c7e-a7a8-8e98b6167144@redhat.com>
Message-ID: <CY4PR04MB0486F6B25A66DB6E7B25C7ED98B40@CY4PR04MB0486.namprd04.prod.outlook.com>

I looked at your implementation.  While its not perfect, it does work.  It does have one critical flaw.  You're assuming how the JDK does repeatable annotations.  I did come up with a way that doesn't make this assumption and is less cumbersome.


The problem is that the recommended implementation is a compile-time thing.  So in theory, other JDKs can do it differently.


I've raised a PR.  I figure we'll have some back and forth on it.


John


________________________________
From: Martin Kouba <mkouba at redhat.com>
Sent: Monday, November 21, 2016 9:00 AM
To: John Ament; cdi-dev
Subject: Re: [cdi-dev] CDI-471 and repeatable annotations

Hi John,

No problem, #4 was optional ;-)

By the way, this is the default implementation from Weld experimental API:
https://github.com/weld/api/blob/master/weld/src/main/java/org/jboss/weld/experimental/ExperimentalAnnotated.java


It's not perfect. E.g. Class.getMethod() should be used with privileges
enabled if a SecurityManager is used. But it could be a good base to
start with.

Thanks,

Martin

Dne 21.11.2016 v 14:47 John Ament napsal(a):
> Martin,
>
>
> I'll make these changes for #1-#3.  I'm not in favor of #4.  Its not
> consistent with our existing method.  (I'd prefer consistency of our API
> over consistency with the Java lang's spec)
>
>
> I may get to them this evening.
>
>
> John
>
>
>
> ------------------------------------------------------------------------
> *From:* cdi-dev-bounces at lists.jboss.org
> <cdi-dev-bounces at lists.jboss.org> on behalf of Martin Kouba
> <mkouba at redhat.com>
> *Sent:* Monday, November 21, 2016 8:25 AM
> *To:* cdi-dev
> *Subject:* [cdi-dev] CDI-471 and repeatable annotations
>
> Dear EG,
>
> during the review of CDI API 2.0.Alpha5 with modified Annotated SPI [1]
> I came across few questionable parts:
>
> 1. We should be more clear that the original methods like
> Annotated.getAnnotations() or Annotated.isAnnotationPresent() DO NOT
> support repeatable annotations - this is what Reflection API does to
> remain backward compatible - see also AnnotatedElement javadoc [2]
> 2. Thus AnnotatedElement.getAnnotation(Class<T>) should not be
> deprecated - for the same reasons as
> AnnotatedElement.getAnnotation(Class<T>) is not
> 3. We should provide a default implementation of
> Annotated.getAnnotations(Class<T>), otherwise a lot of extensions
> providing their own Annotated implementations would be broken
> 4. We should consider renaming the method to "getAnnotationsByType()" to
> keep it simple for users used to Reflection API
>
> Thanks,
>
> Martin
>
> [1]
> https://github.com/cdi-spec/cdi/pull/330
[https://avatars3.githubusercontent.com/u/108167?v=3&s=400]<https://github.com/cdi-spec/cdi/pull/330>

CDI-471 Introduce SPI for retrieving multiple annotations of the same? by johnament ? Pull Request #330 ? cdi-spec/cdi<https://github.com/cdi-spec/cdi/pull/330>
github.com
? type, deprecating the old one. Updated spec docs for qualifiers to reflect repeatability and spec docs for annotated for new method.



> <https://github.com/cdi-spec/cdi/pull/330>
[https://avatars3.githubusercontent.com/u/108167?v=3&s=400]<https://github.com/cdi-spec/cdi/pull/330>

CDI-471 Introduce SPI for retrieving multiple annotations of the same? by johnament ? Pull Request #330 ? cdi-spec/cdi<https://github.com/cdi-spec/cdi/pull/330>
github.com
? type, deprecating the old one. Updated spec docs for qualifiers to reflect repeatability and spec docs for annotated for new method.



>
> CDI-471 Introduce SPI for retrieving multiple annotations of the same?
> by johnament ? Pull Request #330 ? cdi-spec/cdi
> <https://github.com/cdi-spec/cdi/pull/330>
[https://avatars3.githubusercontent.com/u/108167?v=3&s=400]<https://github.com/cdi-spec/cdi/pull/330>

CDI-471 Introduce SPI for retrieving multiple annotations of the same? by johnament ? Pull Request #330 ? cdi-spec/cdi<https://github.com/cdi-spec/cdi/pull/330>
github.com
? type, deprecating the old one. Updated spec docs for qualifiers to reflect repeatability and spec docs for annotated for new method.



> github.com
> ? type, deprecating the old one. Updated spec docs for qualifiers to
> reflect repeatability and spec docs for annotated for new method.
>
>
>
>
> [2]
> https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html
AnnotatedElement (Java Platform SE 8 ) - Oracle<https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html>
docs.oracle.com
Represents an annotated element of the program currently running in this VM. This interface allows annotations to be read reflectively. All annotations returned by ...



>
> AnnotatedElement (Java Platform SE 8 ) - Oracle
> <https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html>
AnnotatedElement (Java Platform SE 8 ) - Oracle<https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html>
docs.oracle.com
Represents an annotated element of the program currently running in this VM. This interface allows annotations to be read reflectively. All annotations returned by ...



> docs.oracle.com
> Represents an annotated element of the program currently running in this
> VM. This interface allows annotations to be read reflectively. All
> annotations returned by ...
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.



> cdi-dev Info Page - JBoss Developer
> <https://lists.jboss.org/mailman/listinfo/cdi-dev>
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.



> lists.jboss.org
> List to discuss the development of CDI (the specification) To see the
> collection of prior postings to the list, visit the cdi-dev Archives.
>
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161122/07c4a7a5/attachment-0001.html 

From mkouba at redhat.com  Tue Nov 22 03:39:52 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 22 Nov 2016 09:39:52 +0100
Subject: [cdi-dev] CDI-471 and repeatable annotations
In-Reply-To: <CY4PR04MB0486F6B25A66DB6E7B25C7ED98B40@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <4f3a4d70-fb55-edd1-1f61-80da5a105eb7@redhat.com>
	<CY4PR04MB04866E231D5DD493845B9E1198B50@CY4PR04MB0486.namprd04.prod.outlook.com>
	<4dae4258-ce99-7c7e-a7a8-8e98b6167144@redhat.com>
	<CY4PR04MB0486F6B25A66DB6E7B25C7ED98B40@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <184354d4-01d4-9a78-c5f5-e5029a1d9a29@redhat.com>

Dne 22.11.2016 v 03:26 John Ament napsal(a):
> I looked at your implementation.  While its not perfect, it does work.
>  It does have one critical flaw.  You're assuming how the JDK does
> repeatable annotations.

That's a good point.

> I did come up with a way that doesn't make this
> assumption and is less cumbersome.

I'm afraid your solution will not always work because 
Annotated.getBaseType() does not return the annotated element for 
methods, fields and parameters. Instead, it returns the type of an 
injection point, event parameter, etc.

So we would have to inspect AnnotatedMember.getJavaMember()...

>
>
> The problem is that the recommended implementation is a compile-time
> thing.  So in theory, other JDKs can do it differently.
>
>
> I've raised a PR.  I figure we'll have some back and forth on it.
>
>
> John
>
>
>
> ------------------------------------------------------------------------
> *From:* Martin Kouba <mkouba at redhat.com>
> *Sent:* Monday, November 21, 2016 9:00 AM
> *To:* John Ament; cdi-dev
> *Subject:* Re: [cdi-dev] CDI-471 and repeatable annotations
>
> Hi John,
>
> No problem, #4 was optional ;-)
>
> By the way, this is the default implementation from Weld experimental API:
> https://github.com/weld/api/blob/master/weld/src/main/java/org/jboss/weld/experimental/ExperimentalAnnotated.java
>
>
> It's not perfect. E.g. Class.getMethod() should be used with privileges
> enabled if a SecurityManager is used. But it could be a good base to
> start with.
>
> Thanks,
>
> Martin
>
> Dne 21.11.2016 v 14:47 John Ament napsal(a):
>> Martin,
>>
>>
>> I'll make these changes for #1-#3.  I'm not in favor of #4.  Its not
>> consistent with our existing method.  (I'd prefer consistency of our API
>> over consistency with the Java lang's spec)
>>
>>
>> I may get to them this evening.
>>
>>
>> John
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* cdi-dev-bounces at lists.jboss.org
>> <cdi-dev-bounces at lists.jboss.org> on behalf of Martin Kouba
>> <mkouba at redhat.com>
>> *Sent:* Monday, November 21, 2016 8:25 AM
>> *To:* cdi-dev
>> *Subject:* [cdi-dev] CDI-471 and repeatable annotations
>>
>> Dear EG,
>>
>> during the review of CDI API 2.0.Alpha5 with modified Annotated SPI [1]
>> I came across few questionable parts:
>>
>> 1. We should be more clear that the original methods like
>> Annotated.getAnnotations() or Annotated.isAnnotationPresent() DO NOT
>> support repeatable annotations - this is what Reflection API does to
>> remain backward compatible - see also AnnotatedElement javadoc [2]
>> 2. Thus AnnotatedElement.getAnnotation(Class<T>) should not be
>> deprecated - for the same reasons as
>> AnnotatedElement.getAnnotation(Class<T>) is not
>> 3. We should provide a default implementation of
>> Annotated.getAnnotations(Class<T>), otherwise a lot of extensions
>> providing their own Annotated implementations would be broken
>> 4. We should consider renaming the method to "getAnnotationsByType()" to
>> keep it simple for users used to Reflection API
>>
>> Thanks,
>>
>> Martin
>>
>> [1]
>> https://github.com/cdi-spec/cdi/pull/330
> <https://github.com/cdi-spec/cdi/pull/330>
> 	
> CDI-471 Introduce SPI for retrieving multiple annotations of the same?
> by johnament ? Pull Request #330 ? cdi-spec/cdi
> <https://github.com/cdi-spec/cdi/pull/330>
> github.com
> ? type, deprecating the old one. Updated spec docs for qualifiers to
> reflect repeatability and spec docs for annotated for new method.
>
>

From issues at jboss.org  Tue Nov 22 05:29:02 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 22 Nov 2016 05:29:02 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-639) Clarify purpose of
 InjectionPointConfigurator.bean(Bean<?> bean) method
In-Reply-To: <JIRA.12657071.1477482040000@Atlassian.JIRA>
References: <JIRA.12657071.1477482040000@Atlassian.JIRA>
	<JIRA.12657071.1477482040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657071.1477482040000.15515.1479810542081@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-639:
------------------------------------------

+1 to remove it.
I can find a use case since IPC is used to change configuration of existing IP. Changing the bean of an existing IP doesn't make sense. 

> Clarify purpose of InjectionPointConfigurator.bean(Bean<?> bean) method
> -----------------------------------------------------------------------
>
>                 Key: CDI-639
>                 URL: https://issues.jboss.org/browse/CDI-639
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 2.0-EDR2
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Dear EG,
> I would like to ask for clarification of {{javax.enterprise.inject.spi.builder.InjectionPointConfigurator#bean}} method. I am not really sure what's the benefit of this method and what would be the suitable use case for this method. 
> I think using this method when I have my custom bean doesn't have any significant advantage since I can declare set of injection points in my custom bean impl. 
> Maybe I would remove this method from the {{InjectionPointConfigurator}} interface.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 22 07:57:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 22 Nov 2016 07:57:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-495) What happens if an illegal bean
 type is found in the set of bean types
In-Reply-To: <JIRA.12559968.1419243129000@Atlassian.JIRA>
References: <JIRA.12559968.1419243129000@Atlassian.JIRA>
	<JIRA.12559968.1419243129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559968.1419243129000.16807.1479819420219@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand reassigned CDI-495:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> What happens if an illegal bean type is found in the set of bean types
> ----------------------------------------------------------------------
>
>                 Key: CDI-495
>                 URL: https://issues.jboss.org/browse/CDI-495
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 22 08:04:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 22 Nov 2016 08:04:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-650) Introduce asynchronous event
 notification options
In-Reply-To: <JIRA.12663076.1479819802000@Atlassian.JIRA>
References: <JIRA.12663076.1479819802000@Atlassian.JIRA>
	<JIRA.12663076.1479819802538@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663076.1479819802000.16837.1479819840175@Atlassian.JIRA>

Martin Kouba created CDI-650:
--------------------------------

             Summary: Introduce asynchronous event notification options
                 Key: CDI-650
                 URL: https://issues.jboss.org/browse/CDI-650
             Project: CDI Specification Issues
          Issue Type: Feature Request
            Reporter: Martin Kouba
            Assignee: Martin Kouba
             Fix For: 2.0 .Final


Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout.

Therefore, I suggest to introduce {{NotificationOptions}} interface:
{code:java}
public interface NotificationOptions {
    Executor getExecutor();
    // Implementation-specific options
    Object get(String optionName);
}
{code}
and change the method signature to:
{code:java}
<U extends T> CompletionStage<U>  fireAsync(U event, NotificationOptions options);
{code}

In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. 
{code:java}
Duration getTimeout();
{code}
instead of adding more and more params to {{Event.fireAsync()}}.

We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.:
{code:java}
void fireEvents(Event event, Executor executor) {
    event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor));
}
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 22 08:10:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 22 Nov 2016 08:10:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-649) Typo in specification document -
	2.0-EDR2
In-Reply-To: <JIRA.12662784.1479733105000@Atlassian.JIRA>
References: <JIRA.12662784.1479733105000@Atlassian.JIRA>
	<JIRA.12662784.1479733105000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662784.1479733105000.16888.1479820200320@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand resolved CDI-649.
--------------------------------------
    Resolution: Out of Date


Already corrected in previous typo review.

> Typo in specification document - 2.0-EDR2
> -----------------------------------------
>
>                 Key: CDI-649
>                 URL: https://issues.jboss.org/browse/CDI-649
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 2.0-EDR2
>         Environment: Documentation - https://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html
>            Reporter: Nico Schlebusch
>
> The is a typo in the "*Preface*" of the CDI 2 EDR2 spec.
> In the "*Mayor Problems*" section, first bullet point:
> {noformat}
> The spec was split in 3 parts as desibed in Organisation of this document to add the support for Java SE.
> {noformat}
> The typo is in the word *desibed* which should be *described*:
> {noformat}
> The spec was split in 3 parts as described in Organisation of this document to add the support for Java SE.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 22 08:12:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 22 Nov 2016 08:12:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-650) Introduce asynchronous event
 notification options
In-Reply-To: <JIRA.12663076.1479819803000@Atlassian.JIRA>
References: <JIRA.12663076.1479819803000@Atlassian.JIRA>
	<JIRA.12663076.1479819803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663076.1479819803000.16910.1479820320392@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-650:
------------------------------------------

+1 for the idea.
How user would access to an implementation of this {{NotificationOption}} class?

> Introduce asynchronous event notification options
> -------------------------------------------------
>
>                 Key: CDI-650
>                 URL: https://issues.jboss.org/browse/CDI-650
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout.
> Therefore, I suggest to introduce {{NotificationOptions}} interface:
> {code:java}
> public interface NotificationOptions {
>     Executor getExecutor();
>     // Implementation-specific options
>     Object get(String optionName);
> }
> {code}
> and change the method signature to:
> {code:java}
> <U extends T> CompletionStage<U>  fireAsync(U event, NotificationOptions options);
> {code}
> In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. 
> {code:java}
> Duration getTimeout();
> {code}
> instead of adding more and more params to {{Event.fireAsync()}}.
> We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.:
> {code:java}
> void fireEvents(Event event, Executor executor) {
>     event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 22 08:19:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 22 Nov 2016 08:19:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-495) What happens if an illegal bean
 type is found in the set of bean types
In-Reply-To: <JIRA.12559968.1419243129000@Atlassian.JIRA>
References: <JIRA.12559968.1419243129000@Atlassian.JIRA>
	<JIRA.12559968.1419243129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559968.1419243129000.16978.1479820740257@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CDI-495 started by Antoine Sabot-Durand.
------------------------------------------------
> What happens if an illegal bean type is found in the set of bean types
> ----------------------------------------------------------------------
>
>                 Key: CDI-495
>                 URL: https://issues.jboss.org/browse/CDI-495
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 22 08:26:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 22 Nov 2016 08:26:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-650) Introduce asynchronous event
 notification options
In-Reply-To: <JIRA.12663076.1479819803000@Atlassian.JIRA>
References: <JIRA.12663076.1479819803000@Atlassian.JIRA>
	<JIRA.12663076.1479819803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663076.1479819803000.17066.1479821160097@Atlassian.JIRA>


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

Martin Kouba commented on CDI-650:
----------------------------------

A user could either use convenient static methods - default immutable implementation (see also NotificationOptionsTest in the PR) or a custom implementation (e.g. container-specific).

> Introduce asynchronous event notification options
> -------------------------------------------------
>
>                 Key: CDI-650
>                 URL: https://issues.jboss.org/browse/CDI-650
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout.
> Therefore, I suggest to introduce {{NotificationOptions}} interface:
> {code:java}
> public interface NotificationOptions {
>     Executor getExecutor();
>     // Implementation-specific options
>     Object get(String optionName);
> }
> {code}
> and change the method signature to:
> {code:java}
> <U extends T> CompletionStage<U>  fireAsync(U event, NotificationOptions options);
> {code}
> In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. 
> {code:java}
> Duration getTimeout();
> {code}
> instead of adding more and more params to {{Event.fireAsync()}}.
> We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.:
> {code:java}
> void fireEvents(Event event, Executor executor) {
>     event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Nov 23 02:03:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 23 Nov 2016 02:03:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
In-Reply-To: <JIRA.12531258.1391619072000@Atlassian.JIRA>
References: <JIRA.12531258.1391619072000@Atlassian.JIRA>
	<JIRA.12531258.1391619072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531258.1391619072000.20680.1479884580493@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes reopened CDI-420:
-----------------------------


This has been marked as resolved, but I can't see anything about {{trim}} in beans_2_0.xsd.

> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
>                 Key: CDI-420
>                 URL: https://issues.jboss.org/browse/CDI-420
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Packaging and Deployment
>    Affects Versions: 1.2.Final, 1.1.Final
>            Reporter: Mark Struberg
>              Labels: F2F2016
>             Fix For: 2.0 .Final
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for 
> ? each Java class, interface or enum deployed in an explicit bean archive, and 
> ? each Java class with a bean defining annotation in an implicit bean archive. 
> ? each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. 
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Nov 23 07:51:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 23 Nov 2016 07:51:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-589) Enhance programmatic lookup
In-Reply-To: <JIRA.12611044.1458296055000@Atlassian.JIRA>
References: <JIRA.12611044.1458296055000@Atlassian.JIRA>
	<JIRA.12611044.1458296055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611044.1458296055000.23358.1479905460281@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-589:
-----------------------------
    Fix Version/s: 2.1 (Discussion)


> Enhance programmatic lookup
> ---------------------------
>
>                 Key: CDI-589
>                 URL: https://issues.jboss.org/browse/CDI-589
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>             Fix For: 2.1 (Discussion)
>
>
> The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515).
> The new proposal is to enhance {{Instance}} similarly as Weld API does:
> https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/inject/WeldInstance.java



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Nov 23 08:31:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 23 Nov 2016 08:31:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-651) Add convenient
	Instance.isResolvable()
In-Reply-To: <JIRA.12663320.1479907810000@Atlassian.JIRA>
References: <JIRA.12663320.1479907810000@Atlassian.JIRA>
	<JIRA.12663320.1479907810236@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663320.1479907810000.23683.1479907860354@Atlassian.JIRA>

Martin Kouba created CDI-651:
--------------------------------

             Summary: Add convenient Instance.isResolvable()
                 Key: CDI-651
                 URL: https://issues.jboss.org/browse/CDI-651
             Project: CDI Specification Issues
          Issue Type: Feature Request
            Reporter: Martin Kouba
            Assignee: Martin Kouba
             Fix For: 2.0 .Final


Returns true if satisfied ({{Instance.isUnsatisfied() == false}}) and NOT ambiguous ({{Instance.isAmbiguous() == false}}).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Nov 23 08:49:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 23 Nov 2016 08:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-651) Add convenient
	Instance.isResolvable()
In-Reply-To: <JIRA.12663320.1479907810000@Atlassian.JIRA>
References: <JIRA.12663320.1479907810000@Atlassian.JIRA>
	<JIRA.12663320.1479907810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663320.1479907810000.23956.1479908940512@Atlassian.JIRA>


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

Emily Jiang commented on CDI-651:
---------------------------------

+1

> Add convenient Instance.isResolvable()
> --------------------------------------
>
>                 Key: CDI-651
>                 URL: https://issues.jboss.org/browse/CDI-651
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Returns true if satisfied ({{Instance.isUnsatisfied() == false}}) and NOT ambiguous ({{Instance.isAmbiguous() == false}}).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Nov 23 09:30:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 23 Nov 2016 09:30:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-652) Introduce example of
 InterceptionFactory usage in 11.7. Apply interceptor programmatically
In-Reply-To: <JIRA.12663369.1479911361000@Atlassian.JIRA>
References: <JIRA.12663369.1479911361000@Atlassian.JIRA>
	<JIRA.12663369.1479911361033@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663369.1479911361000.24446.1479911400219@Atlassian.JIRA>

Tomas Remes created CDI-652:
-------------------------------

             Summary: Introduce example of InterceptionFactory usage in 11.7. Apply interceptor programmatically
                 Key: CDI-652
                 URL: https://issues.jboss.org/browse/CDI-652
             Project: CDI Specification Issues
          Issue Type: Feature Request
            Reporter: Tomas Remes


This new feature would deserve some example in related chapter IMO: 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Nov 23 09:30:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 23 Nov 2016 09:30:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-652) Introduce example of
 InterceptionFactory usage in 11.7. Apply interceptor programmatically
In-Reply-To: <JIRA.12663369.1479911361000@Atlassian.JIRA>
References: <JIRA.12663369.1479911361000@Atlassian.JIRA>
	<JIRA.12663369.1479911361000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663369.1479911361000.24448.1479911400331@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes updated CDI-652:
----------------------------
    Fix Version/s: 2.0 .Final


> Introduce example of InterceptionFactory usage in 11.7. Apply interceptor programmatically
> ------------------------------------------------------------------------------------------
>
>                 Key: CDI-652
>                 URL: https://issues.jboss.org/browse/CDI-652
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> This new feature would deserve some example in related chapter IMO: 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Nov 23 10:26:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 23 Nov 2016 10:26:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-650) Introduce asynchronous event
 notification options
In-Reply-To: <JIRA.12663076.1479819803000@Atlassian.JIRA>
References: <JIRA.12663076.1479819803000@Atlassian.JIRA>
	<JIRA.12663076.1479819803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663076.1479819803000.25268.1479914760595@Atlassian.JIRA>


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

Emily Jiang commented on CDI-650:
---------------------------------

On event receiving side, how an user can get hold of this NotificationOption, which is an interface? Will this be part of observation such as EventMetaData? After getting hold of it, what the receiver is supposed to do?

> Introduce asynchronous event notification options
> -------------------------------------------------
>
>                 Key: CDI-650
>                 URL: https://issues.jboss.org/browse/CDI-650
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout.
> Therefore, I suggest to introduce {{NotificationOptions}} interface:
> {code:java}
> public interface NotificationOptions {
>     Executor getExecutor();
>     // Implementation-specific options
>     Object get(String optionName);
> }
> {code}
> and change the method signature to:
> {code:java}
> <U extends T> CompletionStage<U>  fireAsync(U event, NotificationOptions options);
> {code}
> In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. 
> {code:java}
> Duration getTimeout();
> {code}
> instead of adding more and more params to {{Event.fireAsync()}}.
> We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.:
> {code:java}
> void fireEvents(Event event, Executor executor) {
>     event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Nov 23 10:40:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 23 Nov 2016 10:40:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-650) Introduce asynchronous event
 notification options
In-Reply-To: <JIRA.12663076.1479819803000@Atlassian.JIRA>
References: <JIRA.12663076.1479819803000@Atlassian.JIRA>
	<JIRA.12663076.1479819803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663076.1479819803000.25383.1479915600149@Atlassian.JIRA>


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

Martin Kouba commented on CDI-650:
----------------------------------

This info is not intended for observer methods (receiver part). This is merely a hint for the container, i.e. allows the event "emitter" to configure async events delivery. And right now, the only portable option is the {{Executor}} used for observer method execution.

A user can either use the convenient static methods ({{NotificationOptions.ofExecutor()}}, {{NotificationOptions.builder()}}) and the default impl or provide a custom impl.

> Introduce asynchronous event notification options
> -------------------------------------------------
>
>                 Key: CDI-650
>                 URL: https://issues.jboss.org/browse/CDI-650
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout.
> Therefore, I suggest to introduce {{NotificationOptions}} interface:
> {code:java}
> public interface NotificationOptions {
>     Executor getExecutor();
>     // Implementation-specific options
>     Object get(String optionName);
> }
> {code}
> and change the method signature to:
> {code:java}
> <U extends T> CompletionStage<U>  fireAsync(U event, NotificationOptions options);
> {code}
> In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. 
> {code:java}
> Duration getTimeout();
> {code}
> instead of adding more and more params to {{Event.fireAsync()}}.
> We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.:
> {code:java}
> void fireEvents(Event event, Executor executor) {
>     event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Nov 23 17:33:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 23 Nov 2016 17:33:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-650) Introduce asynchronous event
 notification options
In-Reply-To: <JIRA.12663076.1479819803000@Atlassian.JIRA>
References: <JIRA.12663076.1479819803000@Atlassian.JIRA>
	<JIRA.12663076.1479819803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663076.1479819803000.27713.1479940380388@Atlassian.JIRA>


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

Emily Jiang commented on CDI-650:
---------------------------------

With the introduction of NotificationOptions, the emitter can put more info inside to instruct the container. We will have to spec for each individual properties, right? Otherwise, the application is not portable any more, as Weld might react different from OWB on treating the NotificationOptions info. I might totally misunderstand you. 

> Introduce asynchronous event notification options
> -------------------------------------------------
>
>                 Key: CDI-650
>                 URL: https://issues.jboss.org/browse/CDI-650
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout.
> Therefore, I suggest to introduce {{NotificationOptions}} interface:
> {code:java}
> public interface NotificationOptions {
>     Executor getExecutor();
>     // Implementation-specific options
>     Object get(String optionName);
> }
> {code}
> and change the method signature to:
> {code:java}
> <U extends T> CompletionStage<U>  fireAsync(U event, NotificationOptions options);
> {code}
> In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. 
> {code:java}
> Duration getTimeout();
> {code}
> instead of adding more and more params to {{Event.fireAsync()}}.
> We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.:
> {code:java}
> void fireEvents(Event event, Executor executor) {
>     event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov 24 02:08:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 24 Nov 2016 02:08:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-650) Introduce asynchronous event
 notification options
In-Reply-To: <JIRA.12663076.1479819803000@Atlassian.JIRA>
References: <JIRA.12663076.1479819803000@Atlassian.JIRA>
	<JIRA.12663076.1479819803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663076.1479819803000.29119.1479971280428@Atlassian.JIRA>


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

Martin Kouba commented on CDI-650:
----------------------------------

The idea is to define "typesafe portable options" (only {{NotificationOptions.getExecutor()}} for CDI 2.0) and still allow the implementations to support non-portable/non-standardized options (by means of {{NotificationOptions.get()}}).

> Introduce asynchronous event notification options
> -------------------------------------------------
>
>                 Key: CDI-650
>                 URL: https://issues.jboss.org/browse/CDI-650
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout.
> Therefore, I suggest to introduce {{NotificationOptions}} interface:
> {code:java}
> public interface NotificationOptions {
>     Executor getExecutor();
>     // Implementation-specific options
>     Object get(String optionName);
> }
> {code}
> and change the method signature to:
> {code:java}
> <U extends T> CompletionStage<U>  fireAsync(U event, NotificationOptions options);
> {code}
> In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. 
> {code:java}
> Duration getTimeout();
> {code}
> instead of adding more and more params to {{Event.fireAsync()}}.
> We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.:
> {code:java}
> void fireEvents(Event event, Executor executor) {
>     event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From antoine at sabot-durand.net  Thu Nov 24 02:47:26 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 24 Nov 2016 07:47:26 +0000
Subject: [cdi-dev] Coming roadmap for CDI 2.0
Message-ID: <CABu-YBQGVXXX3yoWtfQhHWaYf=wj26gOrmioGq-OBBzWh6jAzQ@mail.gmail.com>

Hi All,


Just to remind you the coming step for CDI 2.0 specification:

- Nov 30th : feature freeze. After this date we'll only work on spec
clarification that have no impact on RI or TCK (unless an error is found in
specified new features). Name of added API may change after a full review
of new features

- Early December: release of CDI 2.0 Beta1 API

- Mid December: release of Weld 3.0.0 Beta1 and TCK beta

- Early January: start of the release process

Official release is still targeted to end of January as planned.

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161124/4941b6dc/attachment-0001.html 

From issues at jboss.org  Thu Nov 24 08:00:04 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 24 Nov 2016 08:00:04 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-653) Introduce
 BeanManager#getInstances() to ease instance resolution in custom SPI
In-Reply-To: <JIRA.12663578.1479992398000@Atlassian.JIRA>
References: <JIRA.12663578.1479992398000@Atlassian.JIRA>
	<JIRA.12663578.1479992398913@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663578.1479992398000.31573.1479992404995@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-653:
----------------------------------------

             Summary: Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
                 Key: CDI-653
                 URL: https://issues.jboss.org/browse/CDI-653
             Project: CDI Specification Issues
          Issue Type: Feature Request
            Reporter: Antoine Sabot-Durand


Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like

{code:java}
Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
Bean<?> bean = beanManager.resolve(beanSet);
MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
{code}

While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.

So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:

{code:java}
beanManager.getInstances().select(MyClass.class).get();
{code}





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov 24 08:26:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 24 Nov 2016 08:26:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-653) Introduce
 BeanManager#getInstances() to ease instance resolution in custom SPI
In-Reply-To: <JIRA.12663578.1479992399000@Atlassian.JIRA>
References: <JIRA.12663578.1479992399000@Atlassian.JIRA>
	<JIRA.12663578.1479992399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663578.1479992399000.31700.1479993960094@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-653:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)


> Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
> ------------------------------------------------------------------------------
>
>                 Key: CDI-653
>                 URL: https://issues.jboss.org/browse/CDI-653
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.1 (Discussion)
>
>
> Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like
> {code:java}
> Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
> Bean<?> bean = beanManager.resolve(beanSet);
> MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
> {code}
> While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.
> So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:
> {code:java}
> beanManager.getInstances().select(MyClass.class).get();
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov 24 08:34:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Thu, 24 Nov 2016 08:34:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-653) Introduce
 BeanManager#getInstances() to ease instance resolution in custom SPI
In-Reply-To: <JIRA.12663578.1479992399000@Atlassian.JIRA>
References: <JIRA.12663578.1479992399000@Atlassian.JIRA>
	<JIRA.12663578.1479992399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663578.1479992399000.31712.1479994440114@Atlassian.JIRA>


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

Emily Jiang commented on CDI-653:
---------------------------------

+1

> Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
> ------------------------------------------------------------------------------
>
>                 Key: CDI-653
>                 URL: https://issues.jboss.org/browse/CDI-653
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.1 (Discussion)
>
>
> Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like
> {code:java}
> Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
> Bean<?> bean = beanManager.resolve(beanSet);
> MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
> {code}
> While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.
> So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:
> {code:java}
> beanManager.getInstances().select(MyClass.class).get();
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov 24 08:40:00 2016
From: issues at jboss.org (Laird Nelson (JIRA))
Date: Thu, 24 Nov 2016 08:40:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-653) Introduce
 BeanManager#getInstances() to ease instance resolution in custom SPI
In-Reply-To: <JIRA.12663578.1479992399000@Atlassian.JIRA>
References: <JIRA.12663578.1479992399000@Atlassian.JIRA>
	<JIRA.12663578.1479992399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663578.1479992399000.31728.1479994800324@Atlassian.JIRA>


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

Laird Nelson commented on CDI-653:
----------------------------------

Possibly ignorant question: doesn't {{CDI.current().select(MyClass.class).get()}} do this already?

> Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
> ------------------------------------------------------------------------------
>
>                 Key: CDI-653
>                 URL: https://issues.jboss.org/browse/CDI-653
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.1 (Discussion)
>
>
> Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like
> {code:java}
> Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
> Bean<?> bean = beanManager.resolve(beanSet);
> MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
> {code}
> While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.
> So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:
> {code:java}
> beanManager.getInstances().select(MyClass.class).get();
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov 24 08:41:00 2016
From: issues at jboss.org (Antonin Stefanutti (JIRA))
Date: Thu, 24 Nov 2016 08:41:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-653) Introduce
 BeanManager#getInstances() to ease instance resolution in custom SPI
In-Reply-To: <JIRA.12663578.1479992399000@Atlassian.JIRA>
References: <JIRA.12663578.1479992399000@Atlassian.JIRA>
	<JIRA.12663578.1479992399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663578.1479992399000.31734.1479994860334@Atlassian.JIRA>


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

Antonin Stefanutti commented on CDI-653:
----------------------------------------

+1

> Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
> ------------------------------------------------------------------------------
>
>                 Key: CDI-653
>                 URL: https://issues.jboss.org/browse/CDI-653
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.1 (Discussion)
>
>
> Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like
> {code:java}
> Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
> Bean<?> bean = beanManager.resolve(beanSet);
> MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
> {code}
> While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.
> So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:
> {code:java}
> beanManager.getInstances().select(MyClass.class).get();
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov 24 08:42:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 24 Nov 2016 08:42:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-653) Introduce
 BeanManager#getInstances() to ease instance resolution in custom SPI
In-Reply-To: <JIRA.12663578.1479992399000@Atlassian.JIRA>
References: <JIRA.12663578.1479992399000@Atlassian.JIRA>
	<JIRA.12663578.1479992399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663578.1479992399000.31741.1479994920250@Atlassian.JIRA>


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

Martin Kouba commented on CDI-653:
----------------------------------

We should also define what happens if a {{@Dependent}} bean is created, e.g. the user is responsible for the destruction, otherwise memory leaks may occur.

> Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
> ------------------------------------------------------------------------------
>
>                 Key: CDI-653
>                 URL: https://issues.jboss.org/browse/CDI-653
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.1 (Discussion)
>
>
> Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like
> {code:java}
> Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
> Bean<?> bean = beanManager.resolve(beanSet);
> MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
> {code}
> While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.
> So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:
> {code:java}
> beanManager.getInstances().select(MyClass.class).get();
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov 24 08:45:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 24 Nov 2016 08:45:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-653) Introduce
 BeanManager#getInstances() to ease instance resolution in custom SPI
In-Reply-To: <JIRA.12663578.1479992399000@Atlassian.JIRA>
References: <JIRA.12663578.1479992399000@Atlassian.JIRA>
	<JIRA.12663578.1479992399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663578.1479992399000.31769.1479995101301@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-653:
------------------------------------------

[~ljnelson] on the paper yes, but {{CDI.current()}} is static that can cause problems in certain use cases. But the idea is to provide the same comfort in a cleaner way.

> Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
> ------------------------------------------------------------------------------
>
>                 Key: CDI-653
>                 URL: https://issues.jboss.org/browse/CDI-653
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.1 (Discussion)
>
>
> Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like
> {code:java}
> Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
> Bean<?> bean = beanManager.resolve(beanSet);
> MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
> {code}
> While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.
> So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:
> {code:java}
> beanManager.getInstances().select(MyClass.class).get();
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov 24 09:07:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 24 Nov 2016 09:07:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-654) Revisit BeanConfigurator
 create/destroy methods
In-Reply-To: <JIRA.12663597.1479996410000@Atlassian.JIRA>
References: <JIRA.12663597.1479996410000@Atlassian.JIRA>
	<JIRA.12663597.1479996410016@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663597.1479996410000.31958.1479996420150@Atlassian.JIRA>

Martin Kouba created CDI-654:
--------------------------------

             Summary: Revisit BeanConfigurator create/destroy methods
                 Key: CDI-654
                 URL: https://issues.jboss.org/browse/CDI-654
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Martin Kouba
            Assignee: Martin Kouba
             Fix For: 2.0 .Final


Right now, there are four methods to create/producer bean instance and two methods to destroy/dispose bean instance:
*  {{createWith(Function<CreationalContext<U>, U> callback)}}
* {{<U extends T> BeanConfigurator<U> produceWith(Supplier<U> callback)}}
* {{<U extends T> BeanConfigurator<U> produceWith(Function<Instance<Object>, U> callback)}}
* {{<U extends T> BeanConfigurator<U> producing(U instance)}}
* {{destroyWith(BiConsumer<T, CreationalContext<T>> callback)}}
* {{disposeWith(Consumer<T> callback)}}

I think we should:
* remove {{producing()}} and {{produceWith(Supplier<U> callback)}} methods
* clarify that {{Instance<Object>}} is used to "simulate" producer method injection points and behaves in the same way
* modify {{disposeWith(Consumer<T> callback)}} to {{disposeWith(BiConsumer<T, Instance<Object>> callback)}} so that it's possible to "simulate" disposer method injection points




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Nov 24 09:09:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 24 Nov 2016 09:09:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-643) Provide a way to easily configure
 injection point of an InjectionTarget
In-Reply-To: <JIRA.12657855.1477755180000@Atlassian.JIRA>
References: <JIRA.12657855.1477755180000@Atlassian.JIRA>
	<JIRA.12657855.1477755180000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657855.1477755180000.31970.1479996540715@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CDI-643 started by Antoine Sabot-Durand.
------------------------------------------------
> Provide a way to easily configure injection point of an InjectionTarget
> -----------------------------------------------------------------------
>
>                 Key: CDI-643
>                 URL: https://issues.jboss.org/browse/CDI-643
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Creating an {{InjectionTarget}} requires an AnnotatedType. It is often convenient to create a custom {{AnnotatedType}} to add injection points in it (i.e. add {{@Inject}} on fields or methods).
> We Introduced the {{AnnotatedTypeConfigurator}} helper but didn't provide a way to use it to create an {{InjectionTarget}}.
> I think we should add {{BeanManager.createAnnotatedTypeConfigurator()}} to solve this and perhaps simplify other places where we could use an {{AnnotatedTypeConfigurator}} like in CDI-642



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Nov 25 10:07:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 25 Nov 2016 10:07:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-439) ProcessBean event section - make a
 reference to AfterBeanDiscovery#addBean()
In-Reply-To: <JIRA.12541124.1400506656000@Atlassian.JIRA>
References: <JIRA.12541124.1400506656000@Atlassian.JIRA>
	<JIRA.12541124.1400506656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541124.1400506656000.36652.1480086420024@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-439:
-----------------------------
    Fix Version/s: 2.0 .Final


> ProcessBean event section - make a reference to AfterBeanDiscovery#addBean()
> ----------------------------------------------------------------------------
>
>                 Key: CDI-439
>                 URL: https://issues.jboss.org/browse/CDI-439
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Priority: Minor
>             Fix For: 2.0 .Final
>
>
> Right now, "11.5.10. ProcessBean event" does not state anything about the fact that {{AfterBeanDiscovery#addBean()}} fires an event of type {{ProcessBean}} (no subtype as the info is not available for custom Bean implementation).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Nov 25 10:08:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 25 Nov 2016 10:08:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-439) ProcessBean event section - make a
 reference to AfterBeanDiscovery#addBean()
In-Reply-To: <JIRA.12541124.1400506656000@Atlassian.JIRA>
References: <JIRA.12541124.1400506656000@Atlassian.JIRA>
	<JIRA.12541124.1400506656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541124.1400506656000.36660.1480086480363@Atlassian.JIRA>


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

Martin Kouba commented on CDI-439:
----------------------------------

Also note that for a custom bean {{javax.enterprise.inject.spi.ProcessBean.getAnnotated()}} may only return null or an empty impl.

> ProcessBean event section - make a reference to AfterBeanDiscovery#addBean()
> ----------------------------------------------------------------------------
>
>                 Key: CDI-439
>                 URL: https://issues.jboss.org/browse/CDI-439
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Priority: Minor
>             Fix For: 2.0 .Final
>
>
> Right now, "11.5.10. ProcessBean event" does not state anything about the fact that {{AfterBeanDiscovery#addBean()}} fires an event of type {{ProcessBean}} (no subtype as the info is not available for custom Bean implementation).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Nov 25 10:21:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 25 Nov 2016 10:21:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-646) Fix
 AnnotatedTypeConfigurator.add(),
 AnnotatedMethodConfigurator.add() and AnnotatedParameterConfigurator.add()
 javadoc
In-Reply-To: <JIRA.12661188.1479111015000@Atlassian.JIRA>
References: <JIRA.12661188.1479111015000@Atlassian.JIRA>
	<JIRA.12661188.1479111015000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661188.1479111015000.36804.1480087260524@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reassigned CDI-646:
--------------------------------

    Assignee: Martin Kouba


> Fix AnnotatedTypeConfigurator.add(), AnnotatedMethodConfigurator.add() and AnnotatedParameterConfigurator.add() javadoc
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-646
>                 URL: https://issues.jboss.org/browse/CDI-646
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 2.0-EDR2
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> It says: {{Add an annotation to the field.}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mkouba at redhat.com  Fri Nov 25 10:54:17 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Fri, 25 Nov 2016 16:54:17 +0100
Subject: [cdi-dev] Clarify AnnotatedTypeConfigurator.remove(Annotation
	annotation)
Message-ID: <d66aae88-c9fb-9ef6-d7f2-c94e7a7652ff@redhat.com>

Hi all,

while working on https://issues.jboss.org/browse/CDI-646 I figured out 
that all "AnnotatedX.remove(Annotation annotation)" methods declare the 
following javadoc:

"Remove annotations with (a) the same type and (b) the same annotation 
member value for each member which is not annotated {@link Nonbinding}. 
The container calls the {@link Object#equals(Object)} method of the 
annotation member value to compare values."

I don't think this is correct. @Nonbinding is only used for interceptors 
bindings and qualifiers whereas the purpose of AnnotatedType SPI is more 
general.

I believe those remove() methods should simply use 
java.lang.annotation.Annotation.equals(Object) to identify annotations 
to remove.

What do you think?

Thanks,

Martin

From issues at jboss.org  Mon Nov 28 04:02:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 28 Nov 2016 04:02:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-655) Allow CDIProvider to specify the
	priority
In-Reply-To: <JIRA.12663935.1480323665000@Atlassian.JIRA>
References: <JIRA.12663935.1480323665000@Atlassian.JIRA>
	<JIRA.12663935.1480323665667@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663935.1480323665000.39304.1480323720088@Atlassian.JIRA>

Martin Kouba created CDI-655:
--------------------------------

             Summary: Allow CDIProvider to specify the priority 
                 Key: CDI-655
                 URL: https://issues.jboss.org/browse/CDI-655
             Project: CDI Specification Issues
          Issue Type: Feature Request
            Reporter: Martin Kouba


Right now, the CDI class takes the first provider whose {{javax.enterprise.inject.spi.CDIProvider.getCDI()}} does not return null. It might be useful to allow the CDIProvider authors to specify a priority (either by @Priority or by Prioritized) and sort the implementations so that providers with higher priority are taken first.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 28 04:06:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 28 Nov 2016 04:06:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-655) Allow CDIProvider to specify the
	priority
In-Reply-To: <JIRA.12663935.1480323666000@Atlassian.JIRA>
References: <JIRA.12663935.1480323666000@Atlassian.JIRA>
	<JIRA.12663935.1480323666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663935.1480323666000.39337.1480323960415@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-655:
-----------------------------
    Description: Right now, the CDI class takes the first provider whose {{javax.enterprise.inject.spi.CDIProvider.getCDI()}} does not return null. It might be useful to allow the CDIProvider authors to specify a priority (either by @Priority or by Prioritized) and sort the discovered providers so that those with higher priority are taken first.  (was: Right now, the CDI class takes the first provider whose {{javax.enterprise.inject.spi.CDIProvider.getCDI()}} does not return null. It might be useful to allow the CDIProvider authors to specify a priority (either by @Priority or by Prioritized) and sort the implementations so that providers with higher priority are taken first.)


> Allow CDIProvider to specify the priority 
> ------------------------------------------
>
>                 Key: CDI-655
>                 URL: https://issues.jboss.org/browse/CDI-655
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>
> Right now, the CDI class takes the first provider whose {{javax.enterprise.inject.spi.CDIProvider.getCDI()}} does not return null. It might be useful to allow the CDIProvider authors to specify a priority (either by @Priority or by Prioritized) and sort the discovered providers so that those with higher priority are taken first.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From antoine at sabot-durand.net  Mon Nov 28 04:39:29 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 28 Nov 2016 09:39:29 +0000
Subject: [cdi-dev] Clarify AnnotatedTypeConfigurator.remove(Annotation
	annotation)
In-Reply-To: <d66aae88-c9fb-9ef6-d7f2-c94e7a7652ff@redhat.com>
References: <d66aae88-c9fb-9ef6-d7f2-c94e7a7652ff@redhat.com>
Message-ID: <CABu-YBRBJs+RJJ407c5P4he2xLWv13eF1waoMbV4ZeRctsQj8Q@mail.gmail.com>

Well, my guess is that the original intent was to provide an easy way to
remove qualifiers or interceptor binding with members from class or method.
It's powerful but probably too overkill.

+1 for your proposal.

Antoine

On Fri, Nov 25, 2016 at 4:56 PM Martin Kouba <mkouba at redhat.com> wrote:

> Hi all,
>
> while working on https://issues.jboss.org/browse/CDI-646 I figured out
> that all "AnnotatedX.remove(Annotation annotation)" methods declare the
> following javadoc:
>
> "Remove annotations with (a) the same type and (b) the same annotation
> member value for each member which is not annotated {@link Nonbinding}.
> The container calls the {@link Object#equals(Object)} method of the
> annotation member value to compare values."
>
> I don't think this is correct. @Nonbinding is only used for interceptors
> bindings and qualifiers whereas the purpose of AnnotatedType SPI is more
> general.
>
> I believe those remove() methods should simply use
> java.lang.annotation.Annotation.equals(Object) to identify annotations
> to remove.
>
> What do you think?
>
> Thanks,
>
> Martin
> _______________________________________________
> 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/20161128/a1a28478/attachment.html 

From builds at travis-ci.org  Mon Nov 28 04:56:37 2016
From: builds at travis-ci.org (Travis CI)
Date: Mon, 28 Nov 2016 09:56:37 +0000
Subject: [cdi-dev] Passed: cdi-spec/cdi#194 (revert-339-CDI-651 - 67885d9)
In-Reply-To: <cdi-spec/cdi+179382358+passed@travis-ci.org>
Message-ID: <583bff58da06d_43fc9cadd5c4c243241@f8967c27-0bbd-4202-974b-033140626b2e.mail>

Build Update for cdi-spec/cdi
-------------------------------------

Build: #194
Status: Passed

Duration: 3 minutes and 11 seconds
Commit: 67885d9 (revert-339-CDI-651)
Author: Antoine Sabot-Durand
Message: Revert "CDI-651 Add convenient Instance.isResolvable()"

View the changeset: https://github.com/cdi-spec/cdi/commit/67885d9fd598

View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/179382358

--

You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161128/2a78d0d0/attachment-0001.html 

From antoine at sabot-durand.net  Mon Nov 28 05:43:16 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 28 Nov 2016 10:43:16 +0000
Subject: [cdi-dev] Defining the order of event thru priority
Message-ID: <CABu-YBTf-uq=KDkPOn2dtYk8aE-O9en1Tq-DRCOBZ7EqTbCBzA@mail.gmail.com>

Hi all,

In a recent discussion with Martin, I realized that the use of @Priotiy is
not consistent in CDI 1.2:

- For Interceptor and decorator the lowest value in @Priority is first (def
in interceptor spec and 8.2.1)
- For Alternatives the Highest value in @Priroty is first (def in 5.2.2)

Since we have these different interpretation of @Priority value in the spec
, we may find more consistent to change the definition of event ordering
with the @Priority annotation.
Right now we have:

"Observers with smaller priority values are called first"

We may find more intuitive to change it to:

"Observers with higher priority values are called first"

It will remove the oxymoron effect of the sentence and align this ordering
on @Alternative way of using @Priorty.

Wdyt?

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161128/20e86cde/attachment.html 

From issues at jboss.org  Mon Nov 28 07:03:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 28 Nov 2016 07:03:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-609) Clarify behaviour of
 ObserverMethodConfigurator<T> read
In-Reply-To: <JIRA.12628283.1464328351000@Atlassian.JIRA>
References: <JIRA.12628283.1464328351000@Atlassian.JIRA>
	<JIRA.12628283.1464328351000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628283.1464328351000.41151.1480334580757@Atlassian.JIRA>


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

Tomas Remes commented on CDI-609:
---------------------------------

I think this could marked as resolved once https://github.com/cdi-spec/cdi/pull/340 is merged.

> Clarify behaviour of ObserverMethodConfigurator<T> read
> -------------------------------------------------------
>
>                 Key: CDI-609
>                 URL: https://issues.jboss.org/browse/CDI-609
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0-EDR2
>            Reporter: Tomas Remes
>
> It's not clear what should happen in case if you are using ObserverMethodConfigurator and attempting to read from a method ({{Method}}, {{AnnotatedMethod}}) which doesn't have any parameter annotated @Observes. E.g something like this in ABD lifecycle event ("observesMelon" doesn't have any @Observes):
> {code}
> Method melonMethod = FruitObserver.class.getMethod("observesMelon", Melon.class);
> abd.addObserverMethod().read(melonMethod)
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 28 07:05:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 28 Nov 2016 07:05:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-604)
 javax.enterprise.inject.spi.builder package should be renamed
In-Reply-To: <JIRA.12628133.1464263170000@Atlassian.JIRA>
References: <JIRA.12628133.1464263170000@Atlassian.JIRA>
	<JIRA.12628133.1464263170000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628133.1464263170000.41184.1480334700201@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes resolved CDI-604.
-----------------------------
    Resolution: Out of Date


> javax.enterprise.inject.spi.builder package should be renamed
> -------------------------------------------------------------
>
>                 Key: CDI-604
>                 URL: https://issues.jboss.org/browse/CDI-604
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 2.0-EDR2
>            Reporter: Tomas Remes
>
> Since there are no builders in this package we should rename this one. So far there were proposals like {{configurators}} and {{configuration}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mkouba at redhat.com  Mon Nov 28 07:07:46 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 28 Nov 2016 13:07:46 +0100
Subject: [cdi-dev] Defining the order of event thru priority
In-Reply-To: <CABu-YBTf-uq=KDkPOn2dtYk8aE-O9en1Tq-DRCOBZ7EqTbCBzA@mail.gmail.com>
References: <CABu-YBTf-uq=KDkPOn2dtYk8aE-O9en1Tq-DRCOBZ7EqTbCBzA@mail.gmail.com>
Message-ID: <a70db538-9e4b-bd0f-0648-745653d838ac@redhat.com>

Dne 28.11.2016 v 11:43 Antoine Sabot-Durand napsal(a):
> Hi all,
>
> In a recent discussion with Martin, I realized that the use of @Priotiy
> is not consistent in CDI 1.2:
>
> - For Interceptor and decorator the lowest value in @Priority is first
> (def in interceptor spec and 8.2.1)
> - For Alternatives the Highest value in @Priroty is first (def in 5.2.2)
>
> Since we have these different interpretation of @Priority value in the
> spec , we may find more consistent to change the definition of event
> ordering with the @Priority annotation.
> Right now we have:
>
> "Observers with smaller priority values are called first"
>
> We may find more intuitive to change it to:
>
> "Observers with higher priority values are called first"

I believe this one makes much more sense...
+1

>
> It will remove the oxymoron effect of the sentence and align this
> ordering on @Alternative way of using @Priorty.
>
> Wdyt?
>
> Antoine
>
>
> _______________________________________________
> 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
Software Engineer
Red Hat, Czech Republic

From issues at jboss.org  Mon Nov 28 07:08:01 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 28 Nov 2016 07:08:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-609) Clarify behaviour of
 ObserverMethodConfigurator<T> read
In-Reply-To: <JIRA.12628283.1464328351000@Atlassian.JIRA>
References: <JIRA.12628283.1464328351000@Atlassian.JIRA>
	<JIRA.12628283.1464328351000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628283.1464328351000.41246.1480334881465@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes updated CDI-609:
----------------------------
    Comment: was deleted

(was: I think this could marked as resolved once https://github.com/cdi-spec/cdi/pull/340 is merged.)


> Clarify behaviour of ObserverMethodConfigurator<T> read
> -------------------------------------------------------
>
>                 Key: CDI-609
>                 URL: https://issues.jboss.org/browse/CDI-609
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0-EDR2
>            Reporter: Tomas Remes
>
> It's not clear what should happen in case if you are using ObserverMethodConfigurator and attempting to read from a method ({{Method}}, {{AnnotatedMethod}}) which doesn't have any parameter annotated @Observes. E.g something like this in ABD lifecycle event ("observesMelon" doesn't have any @Observes):
> {code}
> Method melonMethod = FruitObserver.class.getMethod("observesMelon", Melon.class);
> abd.addObserverMethod().read(melonMethod)
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mkouba at redhat.com  Mon Nov 28 07:10:03 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 28 Nov 2016 13:10:03 +0100
Subject: [cdi-dev] Clarify AnnotatedTypeConfigurator.remove(Annotation
 annotation)
In-Reply-To: <CABu-YBRBJs+RJJ407c5P4he2xLWv13eF1waoMbV4ZeRctsQj8Q@mail.gmail.com>
References: <d66aae88-c9fb-9ef6-d7f2-c94e7a7652ff@redhat.com>
	<CABu-YBRBJs+RJJ407c5P4he2xLWv13eF1waoMbV4ZeRctsQj8Q@mail.gmail.com>
Message-ID: <e6caaca2-1a93-fc97-7b06-2397d3ac97d4@redhat.com>

For the record, I've submitted a proposal to replace remove(Class) and 
remove(Annotation) methods with remove(Predicate) [1].

This not only simplifies the API but also provides an extensible way
of determining the annotations to remove (e.g. using
BeanManager.areQualifiersEquivalent()).

Martin

[1]
https://github.com/cdi-spec/cdi/pull/347

Dne 28.11.2016 v 10:39 Antoine Sabot-Durand napsal(a):
> Well, my guess is that the original intent was to provide an easy way to
> remove qualifiers or interceptor binding with members from class or
> method. It's powerful but probably too overkill.
>
> +1 for your proposal.
>
> Antoine
>
> On Fri, Nov 25, 2016 at 4:56 PM Martin Kouba <mkouba at redhat.com
> <mailto:mkouba at redhat.com>> wrote:
>
>     Hi all,
>
>     while working on https://issues.jboss.org/browse/CDI-646 I figured out
>     that all "AnnotatedX.remove(Annotation annotation)" methods declare the
>     following javadoc:
>
>     "Remove annotations with (a) the same type and (b) the same annotation
>     member value for each member which is not annotated {@link Nonbinding}.
>     The container calls the {@link Object#equals(Object)} method of the
>     annotation member value to compare values."
>
>     I don't think this is correct. @Nonbinding is only used for interceptors
>     bindings and qualifiers whereas the purpose of AnnotatedType SPI is more
>     general.
>
>     I believe those remove() methods should simply use
>     java.lang.annotation.Annotation.equals(Object) to identify annotations
>     to remove.
>
>     What do you think?
>
>     Thanks,
>
>     Martin
>     _______________________________________________
>     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.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From issues at jboss.org  Mon Nov 28 08:10:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 28 Nov 2016 08:10:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.41909.1480338600310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes updated CDI-541:
----------------------------
    Fix Version/s: 2.0 .Final
                       (was: TBD)


> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
>                 Key: CDI-541
>                 URL: https://issues.jboss.org/browse/CDI-541
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>   
>    void observeMessage(@Observes @Priority(2000) Message message){} 
> }
> {code}
> {code}
> public class Second {
>   
>    void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
> }
> {code}
> {code}
> public class Third {
>   
>    void observeMessage(@Observes @Priority(2200) Message message){} 
> }
> {code}
> {code}
> public class Fourth {
>   
>    void observeMessage(@ObservesAsync @Priority(2300) Message message){} 
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Nov 28 08:38:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 28 Nov 2016 08:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.42218.1480340280517@Atlassian.JIRA>


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

Martin Kouba commented on CDI-541:
----------------------------------

Well, the whole idea of observers ordering is against the principle of loose coupling. However, the EG already decided to standardize it. In my opinion, it doesn't really matter whether we sort sync or async observers. Note that the only requirement of {{fireAsync()}} is: return immediately and notify observers asynchronously (we don't define when, where and how). 

We could also state that async observer with priority results in "non-portable behavior" and let the implementations provide experimental support (e.g. by means of [NotificationOptions|https://github.com/cdi-spec/cdi/pull/337]).



> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
>                 Key: CDI-541
>                 URL: https://issues.jboss.org/browse/CDI-541
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>   
>    void observeMessage(@Observes @Priority(2000) Message message){} 
> }
> {code}
> {code}
> public class Second {
>   
>    void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
> }
> {code}
> {code}
> public class Third {
>   
>    void observeMessage(@Observes @Priority(2200) Message message){} 
> }
> {code}
> {code}
> public class Fourth {
>   
>    void observeMessage(@ObservesAsync @Priority(2300) Message message){} 
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 29 04:02:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 29 Nov 2016 04:02:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering
In-Reply-To: <JIRA.12574324.1433846017000@Atlassian.JIRA>
References: <JIRA.12574324.1433846017000@Atlassian.JIRA>
	<JIRA.12574324.1433846017000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574324.1433846017000.47356.1480410120797@Atlassian.JIRA>


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

Martin Kouba commented on CDI-535:
----------------------------------

Note that we should also provide a means of declaring priority for custom beans (e.g. with {{javax.enterprise.inject.spi.Prioritized}}).

> cdi instance injection ordering
> -------------------------------
>
>                 Key: CDI-535
>                 URL: https://issues.jboss.org/browse/CDI-535
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>            Reporter: Ochieng Marembo
>            Priority: Optional
>             Fix For: 2.1 (Discussion)
>
>
> We should allow ordering of bean instance injection using the {{Instance<MyBeanInterface>}} when an instance injection is used.
> h3. Use case:
> Developer always define a kind of chain of processor beans, which may need to run in specific order.
> h3. Current scenario:
> Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following:
> #1
> {code:java}
> private Iterable<MyBeanInterface> myBeans;
> @Inject
> void injectBeans(@Any Instance<MyBeanInterface> myBeans) {
>   //the create order does some kind of ordering on the beans.
>    this.myBeans = createOrder(myBeans);
> }
> {code}
> #2
> This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call.
> {code:java}
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> public void doSomething() {
>   Iterable<MyBeanInterface> orderedbeans = createOrder(myBeans.select(someQualifier));
> }
> {code}
> h3. Our Proposal
> We already have {{javax.annotation.Priority}} or any cdi specific annotation which we can add to {{MyBeanInterfaceImpl}} so that on injection of an {{Instance<MyBeanInterface>}}, all possible injection values are sorted based on the {{Priority.value()}} and if no annotation is defined, defaults to {{Priority.value = Integer.MAX_VALUE}}
> {code:java}
> public interface MyBeanInterface {}
> @MyQualifier
> @Priority(0)
> public class MyFirstBean implements MyBeanInterface{
> }
> @MyQualifier
> @Priority(2)
> public class MySecondBean implements MyBeanInterface{
> }
> @ApplicationScoped
> public class MyBeanProcessor {
>   //We expect that this injected instances shall be in order based on the @Priority annotation
>   @Any
>   @Inject
>   private Instance<MyBeanInterface> myBeans;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From EMIJIANG at uk.ibm.com  Tue Nov 29 04:44:14 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Tue, 29 Nov 2016 09:44:14 +0000
Subject: [cdi-dev] Defining the order of event thru priority
In-Reply-To: <a70db538-9e4b-bd0f-0648-745653d838ac@redhat.com>
References: <CABu-YBTf-uq=KDkPOn2dtYk8aE-O9en1Tq-DRCOBZ7EqTbCBzA@mail.gmail.com>
	<a70db538-9e4b-bd0f-0648-745653d838ac@redhat.com>
Message-ID: <OF70A4CF3B.CA8BE9EC-ON8025807A.003513B3-8025807A.00357EB9@notes.na.collabserv.com>

I think differently. For Alternatives, the Alternative with the highest 
value is picked, while the others are ignored. There is no so much invoked 
sequentially. 

However, for interceptors/decorators/events, they are chained. Therefore, 
I think events should follow the same fashion as interceptors/decorators, 
which is to follow the ascending order.

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
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:     Antoine Sabot-Durand <antoine at sabot-durand.net>, CDI Java EE 
Specification <cdi-dev at lists.jboss.org>
Date:   28/11/2016 12:10
Subject:        Re: [cdi-dev] Defining the order of event thru priority
Sent by:        cdi-dev-bounces at lists.jboss.org



Dne 28.11.2016 v 11:43 Antoine Sabot-Durand napsal(a):
> Hi all,
>
> In a recent discussion with Martin, I realized that the use of @Priotiy
> is not consistent in CDI 1.2:
>
> - For Interceptor and decorator the lowest value in @Priority is first
> (def in interceptor spec and 8.2.1)
> - For Alternatives the Highest value in @Priroty is first (def in 5.2.2)
>
> Since we have these different interpretation of @Priority value in the
> spec , we may find more consistent to change the definition of event
> ordering with the @Priority annotation.
> Right now we have:
>
> "Observers with smaller priority values are called first"
>
> We may find more intuitive to change it to:
>
> "Observers with higher priority values are called first"

I believe this one makes much more sense...
+1

>
> It will remove the oxymoron effect of the sentence and align this
> ordering on @Alternative way of using @Priorty.
>
> Wdyt?
>
> Antoine
>
>
> _______________________________________________
> 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
Software Engineer
Red Hat, Czech Republic
_______________________________________________
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.



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/20161129/bf99a92d/attachment.html 

From mkouba at redhat.com  Tue Nov 29 04:57:53 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 29 Nov 2016 10:57:53 +0100
Subject: [cdi-dev] Defining the order of event thru priority
In-Reply-To: <OF70A4CF3B.CA8BE9EC-ON8025807A.003513B3-8025807A.00357EB9@notes.na.collabserv.com>
References: <CABu-YBTf-uq=KDkPOn2dtYk8aE-O9en1Tq-DRCOBZ7EqTbCBzA@mail.gmail.com>
	<a70db538-9e4b-bd0f-0648-745653d838ac@redhat.com>
	<OF70A4CF3B.CA8BE9EC-ON8025807A.003513B3-8025807A.00357EB9@notes.na.collabserv.com>
Message-ID: <9189e412-feb1-e688-aea4-a0b4b4fe4fce@redhat.com>

Dne 29.11.2016 v 10:44 Emily Jiang napsal(a):
> I think differently. For Alternatives, the Alternative with the highest
> value is picked, while the others are ignored. There is no so much
> invoked sequentially.
>
> However, for interceptors/decorators/events, they are chained.
> Therefore, I think events should follow the same fashion as
> interceptors/decorators, which is to follow the ascending order.

Well, there is a big difference between interceptors/decorators and 
events - interceptors/decorators do intercept the invocation and may add 
some logic before and after.

Given that INT1 has priority 10 and INT2 has priority 5, then the chain 
would be:

INT1_BEFORE -> INT2_BEFORE -> INT2_AFTER -> INT1_AFTER

So it somehow makes sense that the interceptor with HIGHEST priority is 
the last one which is able to AFFECT the invocation result.

For events the chain is simple:

OBSERVER1 -> OBSERVER2 -> OBSERVER3

>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> 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:        Antoine Sabot-Durand <antoine at sabot-durand.net>, CDI Java EE
> Specification <cdi-dev at lists.jboss.org>
> Date:        28/11/2016 12:10
> Subject:        Re: [cdi-dev] Defining the order of event thru priority
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> Dne 28.11.2016 v 11:43 Antoine Sabot-Durand napsal(a):
>> Hi all,
>>
>> In a recent discussion with Martin, I realized that the use of @Priotiy
>> is not consistent in CDI 1.2:
>>
>> - For Interceptor and decorator the lowest value in @Priority is first
>> (def in interceptor spec and 8.2.1)
>> - For Alternatives the Highest value in @Priroty is first (def in 5.2.2)
>>
>> Since we have these different interpretation of @Priority value in the
>> spec , we may find more consistent to change the definition of event
>> ordering with the @Priority annotation.
>> Right now we have:
>>
>> "Observers with smaller priority values are called first"
>>
>> We may find more intuitive to change it to:
>>
>> "Observers with higher priority values are called first"
>
> I believe this one makes much more sense...
> +1
>
>>
>> It will remove the oxymoron effect of the sentence and align this
>> ordering on @Alternative way of using @Priorty.
>>
>> Wdyt?
>>
>> Antoine
>>
>>
>> _______________________________________________
>> 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
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> 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.
>
>
>
> 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

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From sverker at abrahamsson.com  Tue Nov 29 06:18:08 2016
From: sverker at abrahamsson.com (sverker)
Date: Tue, 29 Nov 2016 04:18:08 -0700 (MST)
Subject: [cdi-dev] CDI events in .ear packaged application
Message-ID: <1480418288812-5714171.post@n5.nabble.com>

Hi
I'm trying to solve an issue with CDI usage in Apache Camel where I was
suggested to use CDI Events to configure the context behavior. This works
fine in the testcases packaged as .jar or .war, but when I try to use it in
my application that is packaged as an .ear then it doesn't work. The event
is never received.
 
When I search on this issue it appears to be due to classloader boundary and
that CDI events won't be carried over them. I had a similar problem before
in the application which I solved by using a JMS topic instead but can't do
that now.
 
Anybody knows a way to make CDI events work in an .ear packaged application
deployed on Wildfly 10.1 application server?
 
Link to the ticket for Apache Camel:
https://issues.apache.org/jira/browse/CAMEL-10391




--
View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/CDI-events-in-ear-packaged-application-tp5714171.html
Sent from the CDI Development mailing list mailing list archive at Nabble.com.

From mkouba at redhat.com  Tue Nov 29 06:34:13 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 29 Nov 2016 12:34:13 +0100
Subject: [cdi-dev] CDI events in .ear packaged application
In-Reply-To: <1480418288812-5714171.post@n5.nabble.com>
References: <1480418288812-5714171.post@n5.nabble.com>
Message-ID: <95e51ba8-c8e0-2191-78ac-433c0bc072f2@redhat.com>

Hi Sverker,

the CDI spec does not define any visibility boundaries for events. So an 
observer method should be notified if the declaring bean is enabled and 
the payload type is accessible. I would try to verify these assumptions 
first (e.g. use debug logging [1] or development mode [2]).

Also do you have a sample app/reproducer?

Martin

[1]
http://weld.cdi-spec.org/documentation/#7

[2]
http://weld.cdi-spec.org/news/2016/10/07/tip2-devmode/


Dne 29.11.2016 v 12:18 sverker napsal(a):
> Hi
> I'm trying to solve an issue with CDI usage in Apache Camel where I was
> suggested to use CDI Events to configure the context behavior. This works
> fine in the testcases packaged as .jar or .war, but when I try to use it in
> my application that is packaged as an .ear then it doesn't work. The event
> is never received.
>
> When I search on this issue it appears to be due to classloader boundary and
> that CDI events won't be carried over them. I had a similar problem before
> in the application which I solved by using a JMS topic instead but can't do
> that now.
>
> Anybody knows a way to make CDI events work in an .ear packaged application
> deployed on Wildfly 10.1 application server?
>
> Link to the ticket for Apache Camel:
> https://issues.apache.org/jira/browse/CAMEL-10391
>
>
>
>
> --
> View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/CDI-events-in-ear-packaged-application-tp5714171.html
> Sent from the CDI Development mailing list mailing list archive at Nabble.com.
> _______________________________________________
> 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
Software Engineer
Red Hat, Czech Republic

From issues at jboss.org  Tue Nov 29 07:23:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 29 Nov 2016 07:23:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-595) Clarify if it is possible to
 'manually' use interceptor
In-Reply-To: <JIRA.12612819.1459514952000@Atlassian.JIRA>
References: <JIRA.12612819.1459514952000@Atlassian.JIRA>
	<JIRA.12612819.1459514952000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12612819.1459514952000.49478.1480422180138@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-595:
-----------------------------
    Fix Version/s: 2.1 (Discussion)


> Clarify if it is possible to 'manually' use interceptor
> -------------------------------------------------------
>
>                 Key: CDI-595
>                 URL: https://issues.jboss.org/browse/CDI-595
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Interceptors
>    Affects Versions: 2.0-EDR1
>            Reporter: Matej Novotny
>             Fix For: 2.1 (Discussion)
>
>
> This issue was inspired by Deltapike issue ([DELTASPIKE-1060|https://issues.apache.org/jira/browse/DELTASPIKE-1060] and [DELTASPIKE-1108|https://issues.apache.org/jira/browse/DELTASPIKE-1108]).
> In the DS issue, the interceptor instance is created with {{new CreationalContext}} and injects an {{@Intercepted Bean}}.
> Later on, there is an attempt to manually call {{javax.enterprise.inject.spi.Interceptor.intercept(InterceptionType, T, InvocationContext)}}.
> This (obviously) fails, as the interceptor does not have a context (meaning a link to the bean it is supposed to intercept).
> Quoting the interceptors spec: "The lifecycle of an interceptor instance is the same as that of the target class instance with which it is associated."
> Therefore we might want to clarify whether creating interceptors in this way is valid at all.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From EMIJIANG at uk.ibm.com  Tue Nov 29 08:47:37 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Tue, 29 Nov 2016 13:47:37 +0000
Subject: [cdi-dev] Defining the order of event thru priority
In-Reply-To: <9189e412-feb1-e688-aea4-a0b4b4fe4fce@redhat.com>
References: <CABu-YBTf-uq=KDkPOn2dtYk8aE-O9en1Tq-DRCOBZ7EqTbCBzA@mail.gmail.com>	<a70db538-9e4b-bd0f-0648-745653d838ac@redhat.com>
	<OF70A4CF3B.CA8BE9EC-ON8025807A.003513B3-8025807A.00357EB9@notes.na.collabserv.com>
	<9189e412-feb1-e688-aea4-a0b4b4fe4fce@redhat.com>
Message-ID: <OFE281DC22.5B4D4A07-ON8025807A.004AFFBC-8025807A.004BC72D@notes.na.collabserv.com>

As for the interceptors/decorators intercepting calls, it is completely 
depending on the implementation of interceptors/decorators. The 
interceptors/decorators might intercept the invocation or might just call 
into the next one.

e.g.
Given that INT1 has priority 10 and INT2 has priority 5, then the 
invocation order:
would be:
If you just logging the method invocation you would have INT2 -> 
INT1->real method

>From end user point of view, it is invoking the INT2 and then INT1

Therefore, I still think it makes more sense to notify the observers with 
the lowest priority first. Interesting to know what others think.


Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
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/UK/IBM at IBMGB, Antoine Sabot-Durand 
<antoine at sabot-durand.net>
Cc:     CDI Java EE Specification <cdi-dev at lists.jboss.org>
Date:   29/11/2016 09:59
Subject:        Re: [cdi-dev] Defining the order of event thru priority
Sent by:        cdi-dev-bounces at lists.jboss.org



Dne 29.11.2016 v 10:44 Emily Jiang napsal(a):
> I think differently. For Alternatives, the Alternative with the highest
> value is picked, while the others are ignored. There is no so much
> invoked sequentially.
>
> However, for interceptors/decorators/events, they are chained.
> Therefore, I think events should follow the same fashion as
> interceptors/decorators, which is to follow the ascending order.

Well, there is a big difference between interceptors/decorators and 
events - interceptors/decorators do intercept the invocation and may add 
some logic before and after.

Given that INT1 has priority 10 and INT2 has priority 5, then the chain 
would be:

INT1_BEFORE -> INT2_BEFORE -> INT2_AFTER -> INT1_AFTER

So it somehow makes sense that the interceptor with HIGHEST priority is 
the last one which is able to AFFECT the invocation result.

For events the chain is simple:

OBSERVER1 -> OBSERVER2 -> OBSERVER3

>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> 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:        Antoine Sabot-Durand <antoine at sabot-durand.net>, CDI Java EE
> Specification <cdi-dev at lists.jboss.org>
> Date:        28/11/2016 12:10
> Subject:        Re: [cdi-dev] Defining the order of event thru priority
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> Dne 28.11.2016 v 11:43 Antoine Sabot-Durand napsal(a):
>> Hi all,
>>
>> In a recent discussion with Martin, I realized that the use of @Priotiy
>> is not consistent in CDI 1.2:
>>
>> - For Interceptor and decorator the lowest value in @Priority is first
>> (def in interceptor spec and 8.2.1)
>> - For Alternatives the Highest value in @Priroty is first (def in 
5.2.2)
>>
>> Since we have these different interpretation of @Priority value in the
>> spec , we may find more consistent to change the definition of event
>> ordering with the @Priority annotation.
>> Right now we have:
>>
>> "Observers with smaller priority values are called first"
>>
>> We may find more intuitive to change it to:
>>
>> "Observers with higher priority values are called first"
>
> I believe this one makes much more sense...
> +1
>
>>
>> It will remove the oxymoron effect of the sentence and align this
>> ordering on @Alternative way of using @Priorty.
>>
>> Wdyt?
>>
>> Antoine
>>
>>
>> _______________________________________________
>> 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
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> 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.
>
>
>
> 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

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
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.



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/20161129/bd8eb633/attachment-0001.html 

From issues at jboss.org  Tue Nov 29 09:07:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 29 Nov 2016 09:07:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-655) Allow CDIProvider to specify the
	priority
In-Reply-To: <JIRA.12663935.1480323666000@Atlassian.JIRA>
References: <JIRA.12663935.1480323666000@Atlassian.JIRA>
	<JIRA.12663935.1480323666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663935.1480323666000.50544.1480428420673@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-655:
-----------------------------
    Fix Version/s: 2.0 .Final


> Allow CDIProvider to specify the priority 
> ------------------------------------------
>
>                 Key: CDI-655
>                 URL: https://issues.jboss.org/browse/CDI-655
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Right now, the CDI class takes the first provider whose {{javax.enterprise.inject.spi.CDIProvider.getCDI()}} does not return null. It might be useful to allow the CDIProvider authors to specify a priority (either by @Priority or by Prioritized) and sort the discovered providers so that those with higher priority are taken first.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From sverker at abrahamsson.com  Tue Nov 29 09:28:27 2016
From: sverker at abrahamsson.com (Sverker Abrahamsson)
Date: Tue, 29 Nov 2016 15:28:27 +0100
Subject: [cdi-dev] CDI events in .ear packaged application
In-Reply-To: <95e51ba8-c8e0-2191-78ac-433c0bc072f2@redhat.com>
References: <1480418288812-5714171.post@n5.nabble.com>
	<95e51ba8-c8e0-2191-78ac-433c0bc072f2@redhat.com>
Message-ID: <d34a7e75-14d3-ae41-12f2-ef203339a411@abrahamsson.com>

Thank you, I found the issue.

I was sending the configuration event in method listening to 
AfterDeploymentValidation event, but that is called after 
AfterBeanDiscovery which is where CdiCamelExtension hangs when trying to 
add my RouteBuilders.

When I moved the code for sending out the event to 
CdiCamelExtension.afterBeanDiscovery() then it works like a charm and I 
do receive the event even in my ear packaged application.

/Sverker

Den 2016-11-29 kl. 12:34, skrev Martin Kouba:
> Hi Sverker,
>
> the CDI spec does not define any visibility boundaries for events. So 
> an observer method should be notified if the declaring bean is enabled 
> and the payload type is accessible. I would try to verify these 
> assumptions first (e.g. use debug logging [1] or development mode [2]).
>
> Also do you have a sample app/reproducer?
>
> Martin
>
> [1]
> http://weld.cdi-spec.org/documentation/#7
>
> [2]
> http://weld.cdi-spec.org/news/2016/10/07/tip2-devmode/
>
>
> Dne 29.11.2016 v 12:18 sverker napsal(a):
>> Hi
>> I'm trying to solve an issue with CDI usage in Apache Camel where I was
>> suggested to use CDI Events to configure the context behavior. This 
>> works
>> fine in the testcases packaged as .jar or .war, but when I try to use 
>> it in
>> my application that is packaged as an .ear then it doesn't work. The 
>> event
>> is never received.
>>
>> When I search on this issue it appears to be due to classloader 
>> boundary and
>> that CDI events won't be carried over them. I had a similar problem 
>> before
>> in the application which I solved by using a JMS topic instead but 
>> can't do
>> that now.
>>
>> Anybody knows a way to make CDI events work in an .ear packaged 
>> application
>> deployed on Wildfly 10.1 application server?
>>
>> Link to the ticket for Apache Camel:
>> https://issues.apache.org/jira/browse/CAMEL-10391
>>
>>
>>
>>
>> -- 
>> View this message in context: 
>> http://cdi-development-mailing-list.1064426.n5.nabble.com/CDI-events-in-ear-packaged-application-tp5714171.html
>> Sent from the CDI Development mailing list mailing list archive at 
>> Nabble.com.
>> _______________________________________________
>> 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 antoine at sabot-durand.net  Tue Nov 29 11:38:41 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 29 Nov 2016 16:38:41 +0000
Subject: [cdi-dev] Priority on PR
Message-ID: <CABu-YBR-xJ6+EY2bZMP2Dzej+ZBs==f_7UWfhvuHwHiCwNnKKA@mail.gmail.com>

Hi all,

As you know, tomorrow is our feature freeze, beginning Thursday there
shouldn't be new PR open for CDI 2.0 unless they don't have impact on
implementation and TCK.
Yet we still have a bunch of PR to review and close. Martin has prioritised
them with label. So please try to focus your review and feedback on the
most urgent one to help the RI and TCK team.

Thanks,

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161129/6d078382/attachment.html 

From issues at jboss.org  Tue Nov 29 11:41:09 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 29 Nov 2016 11:41:09 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-653) Introduce
 BeanManager#getInstances() to ease instance resolution in custom SPI
In-Reply-To: <JIRA.12663578.1479992399000@Atlassian.JIRA>
References: <JIRA.12663578.1479992399000@Atlassian.JIRA>
	<JIRA.12663578.1479992399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663578.1479992399000.52345.1480437669713@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-653:
-------------------------------------
    Fix Version/s: 2.0 .Final
                       (was: 2.1 (Discussion))


> Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
> ------------------------------------------------------------------------------
>
>                 Key: CDI-653
>                 URL: https://issues.jboss.org/browse/CDI-653
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like
> {code:java}
> Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
> Bean<?> bean = beanManager.resolve(beanSet);
> MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
> {code}
> While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.
> So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:
> {code:java}
> beanManager.getInstances().select(MyClass.class).get();
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Nov 29 11:55:04 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 29 Nov 2016 11:55:04 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-653) Introduce
 BeanManager#getInstances() to ease instance resolution in custom SPI
In-Reply-To: <JIRA.12663578.1479992399000@Atlassian.JIRA>
References: <JIRA.12663578.1479992399000@Atlassian.JIRA>
	<JIRA.12663578.1479992399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663578.1479992399000.52442.1480438504817@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CDI-653 started by Antoine Sabot-Durand.
------------------------------------------------
> Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
> ------------------------------------------------------------------------------
>
>                 Key: CDI-653
>                 URL: https://issues.jboss.org/browse/CDI-653
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like
> {code:java}
> Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
> Bean<?> bean = beanManager.resolve(beanSet);
> MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
> {code}
> While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.
> So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:
> {code:java}
> beanManager.getInstances().select(MyClass.class).get();
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Nov 30 08:55:05 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 30 Nov 2016 08:55:05 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-498) Revise "6.7.5. The Conversation
 interface" - dots are not valid in EL name
In-Reply-To: <JIRA.12560483.1420708910000@Atlassian.JIRA>
References: <JIRA.12560483.1420708910000@Atlassian.JIRA>
	<JIRA.12560483.1420708910000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560483.1420708910000.60352.1480514105551@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-498:
-----------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 .Final)


> Revise "6.7.5. The Conversation interface" - dots are not valid in EL name
> --------------------------------------------------------------------------
>
>                 Key: CDI-498
>                 URL: https://issues.jboss.org/browse/CDI-498
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.2.Final
>            Reporter: Tomas Remes
>             Fix For: 2.1 (Discussion)
>
>
> Seems that following part contradicts the EL spec:
> {quote}The container provides a built-in bean with bean type Conversation , scope @RequestScoped ,
> and qualifier @Default , named javax.enterprise.context.conversation .{quote}
> The EL name "javax.enterprise.context.conversation" is not valid.
> Discussion available at http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23cdi-dev.2015-01-06.log.html
> and
> http://lists.jboss.org/pipermail/cdi-dev/2015-January/thread.html - topic "where is defined javax.enterprise.context.conversation.id?"



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)