From issues at jboss.org Mon Jan 2 02:46:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 2 Jan 2017 02:46:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-674) Non-deterministic behavior of CDI.current() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13342125#comment-13342125 ] Tomas Remes commented on CDI-674: --------------------------------- I think this is not a bug in Beta1 - https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/CDI.java#L75 but the git tag is still missing... > Non-deterministic behavior of CDI.current() > ------------------------------------------- > > Key: CDI-674 > URL: https://issues.jboss.org/browse/CDI-674 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0.Beta1 > Reporter: John Ament > > The behavior of CDI.current() is not deterministic. It uses {{findAny()}}. It should use {{findFirst()}} > {{.findAny().orElseThrow(() -> new IllegalStateException("Unable to access CDI"));}} > This also seems to go against what the javadocs say > bq. otherwise the first provider which can access the container is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From mkouba at redhat.com Mon Jan 2 03:34:14 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 2 Jan 2017 09:34:14 +0100 Subject: [cdi-dev] Clarification of Any qualifier In-Reply-To: References: Message-ID: <2bffc2d0-849b-d2e2-b06f-c16e525929d5@redhat.com> Hi John, I believe the spec (2.3.1. Built-in qualifier types) only deals with built-in kinds of beans here. In other words, an author of a custom implementation of Bean is responsible for providing the complete set of qualifiers (i.e. adding @Any). Weld also does not add @Any to a custom bean automatically. The difference is in CDI.current() qualifiers, see also https://issues.jboss.org/browse/CDI-671?focusedCommentId=13339043&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13339043. Martin Dne 28.12.2016 v 15:53 John Ament napsal(a): > Hi, > > > So an issue came up with OWB and programmatic look up. > > > In OWB, when you use CDI.current() the instance you get back includes an > any qualifier. I do a programmatic look up of a custom bean that is > registered with just a single qualifier - @Database. OWB looks up an > instance that has qualifiers Any and Database, but cannot find any > because my bean doesn't declare it. > > > My interpretation > of http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#builtin_qualifiers is that > the container (OWB) should be adding @Any to my custom bean even if I > don't specify it. Is that the proper interpretation? Or am I required > to add @Any to my bean? > > > 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Mon Jan 2 04:13:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 2 Jan 2017 04:13:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-674) Non-deterministic behavior of CDI.current() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13342153#comment-13342153 ] Matej Novotny commented on CDI-674: ----------------------------------- Few more details - this was changed/fixed as a part of CDI-655 in [this PR|https://github.com/cdi-spec/cdi/pull/352]. > Non-deterministic behavior of CDI.current() > ------------------------------------------- > > Key: CDI-674 > URL: https://issues.jboss.org/browse/CDI-674 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0.Beta1 > Reporter: John Ament > > The behavior of CDI.current() is not deterministic. It uses {{findAny()}}. It should use {{findFirst()}} > {{.findAny().orElseThrow(() -> new IllegalStateException("Unable to access CDI"));}} > This also seems to go against what the javadocs say > bq. otherwise the first provider which can access the container is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From mkouba at redhat.com Mon Jan 2 04:15:03 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 2 Jan 2017 10:15:03 +0100 Subject: [cdi-dev] Regression issue with CDI.current In-Reply-To: References: Message-ID: <2f0a4b10-2fd2-065c-8d2f-e5c69a0c8f25@redhat.com> Hi John, could you provide more details (CDI impl, packaging, etc.)? Ideally a link to a hammock test or something like that? I think this should work. Martin Dne 22.12.2016 v 22:23 John Ament napsal(a): > It seems that CDI.current is failing in places where it used to succeed. > > > The scenarios seem to all be the same - JAR files that don't contain a > beans.xml when used in SE mode can no longer invoke CDI.current. In the > past they could. > > > Caused by: java.lang.IllegalStateException: Unable to access CDI > at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$1(CDI.java:75) > at java.util.Optional.orElseThrow(Optional.java:290) > at javax.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:75) > at javax.enterprise.inject.spi.CDI.current(CDI.java:51) > at > ws.ament.hammock.rest.resteasy.Cdi11InjectorFactory.lookupBeanManager(Cdi11InjectorFactory.java:32) > > > I'll raise an issue, but not sure since this was something not specified > previously. > > > 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Tue Jan 3 03:07:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 3 Jan 2017 03:07:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-677) Specify the default scope for BeanConfigurator In-Reply-To: References: Message-ID: Martin Kouba created CDI-677: -------------------------------- Summary: Specify the default scope for BeanConfigurator Key: CDI-677 URL: https://issues.jboss.org/browse/CDI-677 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Fix For: 2.0 .Final Right now, this is undefined. However, it might me useful to specify that the scope is defaulted if not set by {{BeanConfigurator.scope(Class)}}. The default scope could be either {{@Dependent}} or determined by the rules from "2.4.4. Default scope" (i.e. including default scopes from stereotypes). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 06:53:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 3 Jan 2017 06:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-677) Specify the default scope for beans created from BeanConfigurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-677: --------------------------- Summary: Specify the default scope for beans created from BeanConfigurator (was: Specify the default scope for BeanConfigurator) > Specify the default scope for beans created from BeanConfigurator > ----------------------------------------------------------------- > > Key: CDI-677 > URL: https://issues.jboss.org/browse/CDI-677 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > Right now, this is undefined. However, it might me useful to specify that the scope is defaulted if not set by {{BeanConfigurator.scope(Class)}}. The default scope could be either {{@Dependent}} or determined by the rules from "2.4.4. Default scope" (i.e. including default scopes from stereotypes). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Tue Jan 3 07:02:08 2017 From: john.ament at spartasystems.com (John Ament) Date: Tue, 3 Jan 2017 12:02:08 +0000 Subject: [cdi-dev] Meeting on today? Message-ID: All, Is today's meeting on? 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/20170103/331917fb/attachment.html From john.ament at spartasystems.com Tue Jan 3 07:04:14 2017 From: john.ament at spartasystems.com (John Ament) Date: Tue, 3 Jan 2017 12:04:14 +0000 Subject: [cdi-dev] Regression issue with CDI.current In-Reply-To: <2f0a4b10-2fd2-065c-8d2f-e5c69a0c8f25@redhat.com> References: , <2f0a4b10-2fd2-065c-8d2f-e5c69a0c8f25@redhat.com> Message-ID: It actually looked to be a bad classpath. So nevermind. ________________________________ From: Martin Kouba Sent: Monday, January 2, 2017 4:15 AM To: John Ament; cdi-dev Subject: Re: [cdi-dev] Regression issue with CDI.current Hi John, could you provide more details (CDI impl, packaging, etc.)? Ideally a link to a hammock test or something like that? I think this should work. Martin Dne 22.12.2016 v 22:23 John Ament napsal(a): > It seems that CDI.current is failing in places where it used to succeed. > > > The scenarios seem to all be the same - JAR files that don't contain a > beans.xml when used in SE mode can no longer invoke CDI.current. In the > past they could. > > > Caused by: java.lang.IllegalStateException: Unable to access CDI > at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$1(CDI.java:75) > at java.util.Optional.orElseThrow(Optional.java:290) > at javax.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:75) > at javax.enterprise.inject.spi.CDI.current(CDI.java:51) > at > ws.ament.hammock.rest.resteasy.Cdi11InjectorFactory.lookupBeanManager(Cdi11InjectorFactory.java:32) > > > I'll raise an issue, but not sure since this was something not specified > previously. > > > 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 cdi-dev Info Page - JBoss Developer 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 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. > -- 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/20170103/a289aab6/attachment-0001.html From antoine at sabot-durand.net Tue Jan 3 07:04:11 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 03 Jan 2017 12:04:11 +0000 Subject: [cdi-dev] Meeting on today? In-Reply-To: References: Message-ID: Hi John, Yes there will be a meeting today. Antoine Le mar. 3 janv. 2017 ? 13:02, John Ament a ?crit : > All, > > > Is today's meeting on? > > > 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/20170103/a53f53c1/attachment.html From issues at jboss.org Tue Jan 3 07:07:01 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 3 Jan 2017 07:07:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-674) Non-deterministic behavior of CDI.current() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament closed CDI-674. -------------------------- Resolution: Duplicate Issue Already fixed, tag was out of date. > Non-deterministic behavior of CDI.current() > ------------------------------------------- > > Key: CDI-674 > URL: https://issues.jboss.org/browse/CDI-674 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0.Beta1 > Reporter: John Ament > > The behavior of CDI.current() is not deterministic. It uses {{findAny()}}. It should use {{findFirst()}} > {{.findAny().orElseThrow(() -> new IllegalStateException("Unable to access CDI"));}} > This also seems to go against what the javadocs say > bq. otherwise the first provider which can access the container is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 08:49:01 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Jan 2017 08:49:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-672) Purpose of BeanAttributesConfigurator read methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-672: ---------------------------------------- Assignee: Antoine Sabot-Durand > Purpose of BeanAttributesConfigurator read methods > --------------------------------------------------- > > Key: CDI-672 > URL: https://issues.jboss.org/browse/CDI-672 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0.Beta1 > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 08:49:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Jan 2017 08:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance are missing info about their qualifier In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-671: ---------------------------------------- Assignee: Antoine Sabot-Durand > SPI element related to Instance are missing info about their qualifier > ---------------------------------------------------------------------- > > Key: CDI-671 > URL: https://issues.jboss.org/browse/CDI-671 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 2.0.Beta1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Following elements are related to {{Instance}} interface: > * {{CDI}} class implements {{Instance}} > * {{SeContainer}} extends {{Instance}} > * {{BeanManager.createInstance()}} returns and {{Instance}} object > If these {{Instance}} usage are all {{Instance}} there's no information regarding their qualifier. > We should state in Javadoc and spec that these Instance behaves like an injected instance with {{@Inject @Any Instance}} to allow access to all beans instance in the container. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 08:50:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Jan 2017 08:50:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-673) Revisit manipulation with InjectionPoint(s) in ProducerConfigurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-673: ---------------------------------------- Assignee: Antoine Sabot-Durand > Revisit manipulation with InjectionPoint(s) in ProducerConfigurator > ------------------------------------------------------------------- > > Key: CDI-673 > URL: https://issues.jboss.org/browse/CDI-673 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0.Beta1 > Reporter: Matej Novotny > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Currently, {{ProducerConfigurator}} allows to add or replace injection points. > Firstly, {{addInjectionPoints}} - if you think about this, it does not really make sense. You already have producer method defined, it has some body and uses its parameter within that method body. So if you add any IP, the method would not make use of it anyway. > Secondly, replacing IP with {{injectionPoints}} - now this seems useful, but in fact it won't work. As it stands, replacing them in Weld only affects validation phase, not the injection itself. This means that if you have following producer: > {code} > @Produces public Foo produceIt (@Default Bar) { //do stuff} > {code} > and meant to replace the parameter with, say, {{@MyCustom Bar}}, you would in the end still end up with {{@Default Bar}}. > The problem here is that [spec|http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#injectiontarget] states the following: > bq. Implementations of Producer and InjectionTarget must ensure that the set of injection points returned by getInjectionPoints() are injected by produce() or inject(). > However, spec says nothing about what should happen when you change implementation's set on IPs later. > Note: I think we bumped into similar issue with {{BeanConfigurator}} (or some other configurator as well). I will try to dig up that discussion. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 08:52:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Jan 2017 08:52:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-677) Specify the default scope for beans created from BeanConfigurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-677: ---------------------------------------- Assignee: Antoine Sabot-Durand > Specify the default scope for beans created from BeanConfigurator > ----------------------------------------------------------------- > > Key: CDI-677 > URL: https://issues.jboss.org/browse/CDI-677 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Right now, this is undefined. However, it might me useful to specify that the scope is defaulted if not set by {{BeanConfigurator.scope(Class)}}. The default scope could be either {{@Dependent}} or determined by the rules from "2.4.4. Default scope" (i.e. including default scopes from stereotypes). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 08:53:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Jan 2017 08:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-676) Clarify missing class behavior In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-676: ------------------------------------- Fix Version/s: 2.1 (Discussion) > Clarify missing class behavior > ------------------------------ > > Key: CDI-676 > URL: https://issues.jboss.org/browse/CDI-676 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > The spec needs to clarify missing class behavior. Say that I have an extension that is purposely dependent on a class being present (or not present). In Weld, that extension will be ignored due to classloader error. OWB on the other hand throws a TypeNotPresentException. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 08:55:02 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Jan 2017 08:55:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-669) Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-669: ------------------------------------- Fix Version/s: 2.0 .Final > Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance > --------------------------------------------------------------------------------- > > Key: CDI-669 > URL: https://issues.jboss.org/browse/CDI-669 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > {{11.7. Apply interceptor programmatically}} states for method createInterceptedInstance(): > | The method can be only called once, subsequent calls will throw an exception. > Which exception? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 08:55:03 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Jan 2017 08:55:03 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-668) Most Example with @Priority provide non fully qualified contant name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-668: ------------------------------------- Fix Version/s: 2.0 .Final > Most Example with @Priority provide non fully qualified contant name > -------------------------------------------------------------------- > > Key: CDI-668 > URL: https://issues.jboss.org/browse/CDI-668 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0.Beta1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Example in spec show {{@Priority}} are assuming static import of {{javax.interceptor.Interceptor.Priority.APPLICATION}} > We should change them to show full qualified path or add static import to examples for readability sake. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 08:55:04 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Jan 2017 08:55:04 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-668) Most Example with @Priority provide non fully qualified contant name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-668: ---------------------------------------- Assignee: Antoine Sabot-Durand > Most Example with @Priority provide non fully qualified contant name > -------------------------------------------------------------------- > > Key: CDI-668 > URL: https://issues.jboss.org/browse/CDI-668 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0.Beta1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Example in spec show {{@Priority}} are assuming static import of {{javax.interceptor.Interceptor.Priority.APPLICATION}} > We should change them to show full qualified path or add static import to examples for readability sake. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 09:33:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 3 Jan 2017 09:33:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-672) Purpose of BeanAttributesConfigurator read methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny reassigned CDI-672: --------------------------------- Assignee: Matej Novotny (was: Antoine Sabot-Durand) > Purpose of BeanAttributesConfigurator read methods > --------------------------------------------------- > > Key: CDI-672 > URL: https://issues.jboss.org/browse/CDI-672 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0.Beta1 > Reporter: Tomas Remes > Assignee: Matej Novotny > Fix For: 2.0 .Final > > > I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 3 09:33:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 3 Jan 2017 09:33:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-672) Purpose of BeanAttributesConfigurator read methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated CDI-672: ------------------------------ Git Pull Request: https://github.com/cdi-spec/cdi/pull/369 > Purpose of BeanAttributesConfigurator read methods > --------------------------------------------------- > > Key: CDI-672 > URL: https://issues.jboss.org/browse/CDI-672 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0.Beta1 > Reporter: Tomas Remes > Assignee: Matej Novotny > Fix For: 2.0 .Final > > > I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From ljnelson at gmail.com Thu Jan 5 16:56:07 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Thu, 05 Jan 2017 21:56:07 +0000 Subject: [cdi-dev] Thread safety of SeContainer and SeContainerInitializer In-Reply-To: <4e728b5c-2979-edd3-6fe2-d01c68fa2014@redhat.com> References: <4e728b5c-2979-edd3-6fe2-d01c68fa2014@redhat.com> Message-ID: (Resurrecting this thread. Happy New Year!) Another (related) case I had a question about. Suppose I have the standard SeContainer "block" like this: try (final SeContainer container = initializer.initialize()) { // stuff goes here } Inside that block, may I start threads and have them do things with the container variable? It sounds like strictly speaking no, I may not?i.e. that the specification, since it says nothing one way or the other about threading, therefore implies that only one thread may, say, iterate over the container (either using its iterator() or stream() methods). On the other hand, I see no restriction in the specification on the creation of threads from, say, a managed bean, which means it is always possible that at any point an Instance object may be used by many threads. Or, further, since events may be fired asynchronously, then it would *seem* to follow that iteration over an Instance must be thread safe. Should the specification include language related to concurrency in these matters and others? Best, Laird On Thu, Dec 8, 2016 at 1:37 AM Martin Kouba wrote: > I agree with John, it's not guaranteed. However, the original intention > (based on Weld SE impl) was: > > * SeContainerInitializer is not thread-safe and should not be shared > between threads > * it should be safe to call SeContainer.close() from any thread > > Martin > > Dne 7.12.2016 v 22:01 John Ament napsal(a): > > I would say that this is not guaranteed. > > > > > > > > ------------------------------------------------------------------------ > > *From:* cdi-dev-bounces at lists.jboss.org > > on behalf of Laird Nelson > > > > *Sent:* Wednesday, December 7, 2016 3:56 PM > > *To:* cdi-dev at lists.jboss.org > > *Subject:* [cdi-dev] Thread safety of SeContainer and > > SeContainerInitializer > > > > Are SeContainer and SeContainerInitializer safe for concurrent use by > > multiple threads? The string "concurren" shows up only four times in > > the 2.0 specification but not in this context. > > > > I'm most interested in whether it is guaranteed that one thread may call > > SeContainer::initialize and another may call SeContainer::close. > > > > I'm assuming that this is /not/ guaranteed. > > > > Best, > > Laird > > ------------------------------------------------------------------------ > > 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/20170105/d8f03ac1/attachment.html From issues at jboss.org Fri Jan 6 01:49:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 6 Jan 2017 01:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-644) Link formatting in the specification text In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated CDI-644: ---------------------------- Fix Version/s: 2.0 .Final What about this one? Personally I would like to see it in 2.0.Final but it's likely minor. > 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 > Fix For: 2.0 .Final > > > 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 mkouba at redhat.com Fri Jan 6 02:39:07 2017 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 6 Jan 2017 08:39:07 +0100 Subject: [cdi-dev] Thread safety of SeContainer and SeContainerInitializer In-Reply-To: References: <4e728b5c-2979-edd3-6fe2-d01c68fa2014@redhat.com> Message-ID: Dne 5.1.2017 v 22:56 Laird Nelson napsal(a): > (Resurrecting this thread. Happy New Year!) > > Another (related) case I had a question about. > > Suppose I have the standard SeContainer "block" like this: > > try (final SeContainer container = initializer.initialize()) { > // stuff goes here > } > > Inside that block, may I start threads and have them do things with the > container variable? It sounds like strictly speaking no, I may not?i.e. > that the specification, since it says nothing one way or the other about > threading, therefore implies that only one thread may, say, iterate over > the container (either using its iterator() or stream() methods). I believe you can. It should be safe to use an initialized container instance from multiple threads. The spec does not explicitly mention this but it can't cover every possibility ;-) > > On the other hand, I see no restriction in the specification on the > creation of threads from, say, a managed bean, which means it is always > possible that at any point an Instance object may be used by many > threads. You can create a new thread from within a managed bean. BUT there are few snags you should be aware of. I.e. in Java EE you should not create your own threads and if you do, only dependent and application context will work as usual. See also http://weld.cdi-spec.org/documentation/#0 > Or, further, since events may be fired asynchronously, then it > would /seem/ to follow that iteration over an Instance must be thread safe. > > Should the specification include language related to concurrency in > these matters and others? I think that would require a great deal of effort. But feel free to create a spec issue for CDI 2.1+. > > Best, > Laird > > On Thu, Dec 8, 2016 at 1:37 AM Martin Kouba > wrote: > > I agree with John, it's not guaranteed. However, the original intention > (based on Weld SE impl) was: > > * SeContainerInitializer is not thread-safe and should not be shared > between threads > * it should be safe to call SeContainer.close() from any thread > > Martin > > Dne 7.12.2016 v 22:01 John Ament napsal(a): > > I would say that this is not guaranteed. > > > > > > > > > ------------------------------------------------------------------------ > > *From:* cdi-dev-bounces at lists.jboss.org > > > > on behalf of Laird Nelson > > > > > *Sent:* Wednesday, December 7, 2016 3:56 PM > > *To:* cdi-dev at lists.jboss.org > > *Subject:* [cdi-dev] Thread safety of SeContainer and > > SeContainerInitializer > > > > Are SeContainer and SeContainerInitializer safe for concurrent use by > > multiple threads? The string "concurren" shows up only four times in > > the 2.0 specification but not in this context. > > > > I'm most interested in whether it is guaranteed that one thread > may call > > SeContainer::initialize and another may call SeContainer::close. > > > > I'm assuming that this is /not/ guaranteed. > > > > Best, > > Laird > > > ------------------------------------------------------------------------ > > 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 ljnelson at gmail.com Fri Jan 6 02:50:00 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Fri, 06 Jan 2017 07:50:00 +0000 Subject: [cdi-dev] Thread safety of SeContainer and SeContainerInitializer In-Reply-To: References: <4e728b5c-2979-edd3-6fe2-d01c68fa2014@redhat.com> Message-ID: On Thu, Jan 5, 2017 at 11:39 PM Martin Kouba wrote: > Dne 5.1.2017 v 22:56 Laird Nelson napsal(a): > > Suppose I have the standard SeContainer "block" like this: > > > > try (final SeContainer container = initializer.initialize()) { > > // stuff goes here > > } > > > > Inside that block, may I start threads and have them do things with the > > container variable? > I believe you can. It should be safe to use an initialized container > instance from multiple threads. The spec does not explicitly mention > this but it can't cover every possibility ;-) > Sure; that's fair. I guess?maybe there's a blanket statement that could be added to the specification? Something that indicates that *unless otherwise indicated*, core CDI objects (not sure offhand what these are, but things like BeanManager, CDI, Instance, Context, etc.) used in a Java SE context are safe for concurrent use by multiple threads. To state the obvious, I'm not a fan of "try it; see if it works", since I don't know what any given implementation is going to do. > You can create a new thread from within a managed bean. BUT there are > few snags you should be aware of. I.e. in Java EE you should not create > your own threads Sure; of course not. > and if you do, only dependent and application context > will work as usual. > Right. > See also http://weld.cdi-spec.org/documentation/#0 > Thanks. > > Should the specification include language related to concurrency in > > these matters and others? > > I think that would require a great deal of effort. But feel free to > create a spec issue for CDI 2.1+. > OK. A blanket statement or two, so that exceptional cases can then be documented on a case-by-case basis would seem to be the way to go here. I'll file a spec issue. Thanks for your time. Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170106/14baf70e/attachment.html From issues at jboss.org Fri Jan 6 02:51:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 6 Jan 2017 02:51:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-644) Link formatting in the specification text In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated CDI-644: ---------------------------- Description: In previous versions (1.x) of specification links to chapters within spec were formatted as follows: {noformat} Section 2.4.1, ?Built-in scope types? {noformat} I would like to preserve this formatting (especialy the prefix "Section x.x.x") also in the new specification version because I think it's more legible. was: 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. > 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 > Fix For: 2.0 .Final > > > In previous versions (1.x) of specification links to chapters within spec were formatted as follows: > {noformat} > Section 2.4.1, ?Built-in scope types? > {noformat} > I would like to preserve this formatting (especialy the prefix "Section x.x.x") also in the new specification version because I think it's more legible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jan 6 02:56:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 6 Jan 2017 02:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-644) Link formatting in the specification text In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13344058#comment-13344058 ] Tomas Remes commented on CDI-644: --------------------------------- Ok it seems HTML is the same. I thought PDF - http://docs.jboss.org/cdi/spec/1.2/cdi-spec-1.2.pdf > 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 > Fix For: 2.0 .Final > > > In previous versions (1.x) of specification links to chapters within spec were formatted as follows: > {noformat} > Section 2.4.1, ?Built-in scope types? > {noformat} > I would like to preserve this formatting (especialy the prefix "Section x.x.x") also in the new specification version because I think it's more legible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jan 6 08:55:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 6 Jan 2017 08:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-678) Consider expanding @WithAnnotations utilization In-Reply-To: References: Message-ID: Tomas Remes created CDI-678: ------------------------------- Summary: Consider expanding @WithAnnotations utilization Key: CDI-678 URL: https://issues.jboss.org/browse/CDI-678 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Tomas Remes Priority: Minor Currently usage of {{@WithAnnotations}} is available only with {{ProcessAnnotatedType}} event. Maybe it could be helpful to expand this option also for other lifecycle events. For example I came across this extension https://github.com/wildfly-swarm/wildfly-swarm/blob/master/core/container/src/main/java/org/wildfly/swarm/container/runtime/cdi/configurable/ConfigurableExtension.java It basically observes all {{ProcessInjectionTarget}} events and tries to find {{@Configurable}} annotation in the related {{AnnotatedType}} (which is available in this case). Allowing to use {{@WithAnnotations}} in this case would solve this problem more gracefully I believe. It's likely minor enhancement but maybe it could be useful also in another cases. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jan 6 08:55:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 6 Jan 2017 08:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-678) Consider expanding @WithAnnotations utilization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated CDI-678: ---------------------------- Fix Version/s: 2.1 (Discussion) > Consider expanding @WithAnnotations utilization > ----------------------------------------------- > > Key: CDI-678 > URL: https://issues.jboss.org/browse/CDI-678 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Tomas Remes > Priority: Minor > Fix For: 2.1 (Discussion) > > > Currently usage of {{@WithAnnotations}} is available only with {{ProcessAnnotatedType}} event. Maybe it could be helpful to expand this option also for other lifecycle events. > For example I came across this extension https://github.com/wildfly-swarm/wildfly-swarm/blob/master/core/container/src/main/java/org/wildfly/swarm/container/runtime/cdi/configurable/ConfigurableExtension.java > It basically observes all {{ProcessInjectionTarget}} events and tries to find {{@Configurable}} annotation in the related {{AnnotatedType}} (which is available in this case). Allowing to use {{@WithAnnotations}} in this case would solve this problem more gracefully I believe. > It's likely minor enhancement but maybe it could be useful also in another cases. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From java at sebastian-daschner.de Sat Jan 7 07:42:43 2017 From: java at sebastian-daschner.de (Sebastian Daschner) Date: Sat, 7 Jan 2017 13:42:43 +0100 Subject: [cdi-dev] InvocationScoped | RequestScoped thread context Message-ID: Hi experts, Regarding scopes, specificly @RequestScoped: We found in enterprise projects that there is a need for a request / invocation scope that is active during an invocation of a business method (HTTP, JMS, EJB, timer, whatever), regardless how many threads are involved. Naively, one could presume that @RequestScoped would deal that, but since it's strictly single threaded and not accessible from asyncronously started threads (ManagedExecuterService and so forth) that doesn't help much. This scope would e.g. enable correlation IDs that are needed in all threads started from one original invocation. Name is up to better suggestions :-) I guess it's not possible to change the behavior of @RequestScoped and to make it available in asyncronously started threads? Have there been considerations for adding such a scope or similar in the past? Cheers, Sebastian From rmannibucau at gmail.com Sat Jan 7 10:13:41 2017 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sat, 7 Jan 2017 16:13:41 +0100 Subject: [cdi-dev] InvocationScoped | RequestScoped thread context In-Reply-To: References: Message-ID: Hi Sebastian Think we spoke of it and request scope is single threaded but should propagate following servlet spec. That said i agree cdi misses a manually controlled and inheritable scope. Implemented it 4-5 times last 2 years. Le 7 janv. 2017 13:45, "Sebastian Daschner" a ?crit : > Hi experts, > > Regarding scopes, specificly @RequestScoped: We found in enterprise > projects that there is a need for a request / invocation scope that is > active during an invocation of a business method (HTTP, JMS, EJB, timer, > whatever), regardless how many threads are involved. Naively, one could > presume that @RequestScoped would deal that, but since it's strictly > single threaded and not accessible from asyncronously started threads > (ManagedExecuterService and so forth) that doesn't help much. > > This scope would e.g. enable correlation IDs that are needed in all > threads started from one original invocation. Name is up to better > suggestions :-) > > I guess it's not possible to change the behavior of @RequestScoped and > to make it available in asyncronously started threads? Have there been > considerations for adding such a scope or similar in the past? > > Cheers, > Sebastian > > _______________________________________________ > 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/20170107/4fab8db4/attachment-0001.html From manovotn at redhat.com Mon Jan 9 01:43:05 2017 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 9 Jan 2017 01:43:05 -0500 (EST) Subject: [cdi-dev] InvocationScoped | RequestScoped thread context In-Reply-To: References: Message-ID: <1900149257.8741850.1483944185211.JavaMail.zimbra@redhat.com> Hi Manual context activation had been implemented in CDI 2.0 for RequestScope[1] as a part of CDI-30[2]. I know that's probably not what you are after, just saying that it's headed that way. As for context propagation, there is an issue too (CDI-618[3] I think). I recall there was quite a discussion about it and possibly even more issues raised (like CDI-587) but no real action taken as this turns out to be very complex case to cover with "general" implementation. BTW due to backward compatibility, RequestScoped cannot be changed for sure. Matej __________________________________________________________________________- [1] http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#activating_request_context [2] https://issues.jboss.org/browse/CDI-30 [3]https://issues.jboss.org/browse/CDI-618 ----- Original Message ----- > From: "Romain Manni-Bucau" > To: "Sebastian Daschner" > Cc: "cdi-dev" > Sent: Saturday, January 7, 2017 4:13:41 PM > Subject: Re: [cdi-dev] InvocationScoped | RequestScoped thread context > > Hi Sebastian > > Think we spoke of it and request scope is single threaded but should > propagate following servlet spec. That said i agree cdi misses a manually > controlled and inheritable scope. Implemented it 4-5 times last 2 years. > > > Le 7 janv. 2017 13:45, "Sebastian Daschner" < java at sebastian-daschner.de > a > ?crit : > > > Hi experts, > > Regarding scopes, specificly @RequestScoped: We found in enterprise > projects that there is a need for a request / invocation scope that is > active during an invocation of a business method (HTTP, JMS, EJB, timer, > whatever), regardless how many threads are involved. Naively, one could > presume that @RequestScoped would deal that, but since it's strictly > single threaded and not accessible from asyncronously started threads > (ManagedExecuterService and so forth) that doesn't help much. > > This scope would e.g. enable correlation IDs that are needed in all > threads started from one original invocation. Name is up to better > suggestions :-) > > I guess it's not possible to change the behavior of @RequestScoped and > to make it available in asyncronously started threads? Have there been > considerations for adding such a scope or similar in the past? > > Cheers, > Sebastian > > _______________________________________________ > 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 issues at jboss.org Mon Jan 9 05:50:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 9 Jan 2017 05:50:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-679) ProducerConfigurator should provide the possibility to simulate parameter injection In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-679: ---------------------------------------- Summary: ProducerConfigurator should provide the possibility to simulate parameter injection Key: CDI-679 URL: https://issues.jboss.org/browse/CDI-679 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Antoine Sabot-Durand As BeanConfigurator, ProducerConfigurator should provide {{ BeanConfigurator produceWith(Function, U> callback);}} to simulate parameter injection in producer method. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jan 9 05:58:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 9 Jan 2017 05:58:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-679) ProducerConfigurator should provide the possibility to simulate parameter injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13344635#comment-13344635 ] Martin Kouba commented on CDI-679: ---------------------------------- I would say this is a low priority issue (Minor/Optional). Also for {{BeanConfigurator}} it makes more sense to simulate a producer method. > ProducerConfigurator should provide the possibility to simulate parameter injection > ------------------------------------------------------------------------------------ > > Key: CDI-679 > URL: https://issues.jboss.org/browse/CDI-679 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > > As BeanConfigurator, ProducerConfigurator should provide {{ BeanConfigurator produceWith(Function, U> callback);}} to simulate parameter injection in producer method. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jan 9 06:01:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 9 Jan 2017 06:01:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-673) Revisit manipulation with InjectionPoint(s) in ProducerConfigurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-673 started by Antoine Sabot-Durand. ------------------------------------------------ > Revisit manipulation with InjectionPoint(s) in ProducerConfigurator > ------------------------------------------------------------------- > > Key: CDI-673 > URL: https://issues.jboss.org/browse/CDI-673 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0.Beta1 > Reporter: Matej Novotny > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Currently, {{ProducerConfigurator}} allows to add or replace injection points. > Firstly, {{addInjectionPoints}} - if you think about this, it does not really make sense. You already have producer method defined, it has some body and uses its parameter within that method body. So if you add any IP, the method would not make use of it anyway. > Secondly, replacing IP with {{injectionPoints}} - now this seems useful, but in fact it won't work. As it stands, replacing them in Weld only affects validation phase, not the injection itself. This means that if you have following producer: > {code} > @Produces public Foo produceIt (@Default Bar) { //do stuff} > {code} > and meant to replace the parameter with, say, {{@MyCustom Bar}}, you would in the end still end up with {{@Default Bar}}. > The problem here is that [spec|http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#injectiontarget] states the following: > bq. Implementations of Producer and InjectionTarget must ensure that the set of injection points returned by getInjectionPoints() are injected by produce() or inject(). > However, spec says nothing about what should happen when you change implementation's set on IPs later. > Note: I think we bumped into similar issue with {{BeanConfigurator}} (or some other configurator as well). I will try to dig up that discussion. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jan 9 06:08:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 9 Jan 2017 06:08:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-673) Revisit manipulation with InjectionPoint(s) in ProducerConfigurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13344641#comment-13344641 ] Antoine Sabot-Durand commented on CDI-673: ------------------------------------------ I agree. If a user needs to resolve an injection from here, providing fix for CDI-679 or using {{BeanManger#createInstance()}} seems a better approach. > Revisit manipulation with InjectionPoint(s) in ProducerConfigurator > ------------------------------------------------------------------- > > Key: CDI-673 > URL: https://issues.jboss.org/browse/CDI-673 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0.Beta1 > Reporter: Matej Novotny > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Currently, {{ProducerConfigurator}} allows to add or replace injection points. > Firstly, {{addInjectionPoints}} - if you think about this, it does not really make sense. You already have producer method defined, it has some body and uses its parameter within that method body. So if you add any IP, the method would not make use of it anyway. > Secondly, replacing IP with {{injectionPoints}} - now this seems useful, but in fact it won't work. As it stands, replacing them in Weld only affects validation phase, not the injection itself. This means that if you have following producer: > {code} > @Produces public Foo produceIt (@Default Bar) { //do stuff} > {code} > and meant to replace the parameter with, say, {{@MyCustom Bar}}, you would in the end still end up with {{@Default Bar}}. > The problem here is that [spec|http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#injectiontarget] states the following: > bq. Implementations of Producer and InjectionTarget must ensure that the set of injection points returned by getInjectionPoints() are injected by produce() or inject(). > However, spec says nothing about what should happen when you change implementation's set on IPs later. > Note: I think we bumped into similar issue with {{BeanConfigurator}} (or some other configurator as well). I will try to dig up that discussion. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jan 9 06:12:01 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 9 Jan 2017 06:12:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance are missing info about their qualifier In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-671 started by Antoine Sabot-Durand. ------------------------------------------------ > SPI element related to Instance are missing info about their qualifier > ---------------------------------------------------------------------- > > Key: CDI-671 > URL: https://issues.jboss.org/browse/CDI-671 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 2.0.Beta1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Following elements are related to {{Instance}} interface: > * {{CDI}} class implements {{Instance}} > * {{SeContainer}} extends {{Instance}} > * {{BeanManager.createInstance()}} returns and {{Instance}} object > If these {{Instance}} usage are all {{Instance}} there's no information regarding their qualifier. > We should state in Javadoc and spec that these Instance behaves like an injected instance with {{@Inject @Any Instance}} to allow access to all beans instance in the container. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jan 9 06:14:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 9 Jan 2017 06:14:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance are missing info about their qualifier In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13344651#comment-13344651 ] Antoine Sabot-Durand commented on CDI-671: ------------------------------------------ EG agreed to standardize Weld Behaviour described by [~mkouba] > SPI element related to Instance are missing info about their qualifier > ---------------------------------------------------------------------- > > Key: CDI-671 > URL: https://issues.jboss.org/browse/CDI-671 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 2.0.Beta1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Following elements are related to {{Instance}} interface: > * {{CDI}} class implements {{Instance}} > * {{SeContainer}} extends {{Instance}} > * {{BeanManager.createInstance()}} returns and {{Instance}} object > If these {{Instance}} usage are all {{Instance}} there's no information regarding their qualifier. > We should state in Javadoc and spec that these Instance behaves like an injected instance with {{@Inject @Any Instance}} to allow access to all beans instance in the container. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jan 9 11:15:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 9 Jan 2017 11:15:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-677) Specify the default scope for beans created from BeanConfigurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-677 started by Antoine Sabot-Durand. ------------------------------------------------ > Specify the default scope for beans created from BeanConfigurator > ----------------------------------------------------------------- > > Key: CDI-677 > URL: https://issues.jboss.org/browse/CDI-677 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Right now, this is undefined. However, it might me useful to specify that the scope is defaulted if not set by {{BeanConfigurator.scope(Class)}}. The default scope could be either {{@Dependent}} or determined by the rules from "2.4.4. Default scope" (i.e. including default scopes from stereotypes). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 10 04:33:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 10 Jan 2017 04:33:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-668) Most Example with @Priority provide non fully qualified contant name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-668 started by Antoine Sabot-Durand. ------------------------------------------------ > Most Example with @Priority provide non fully qualified contant name > -------------------------------------------------------------------- > > Key: CDI-668 > URL: https://issues.jboss.org/browse/CDI-668 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0.Beta1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Example in spec show {{@Priority}} are assuming static import of {{javax.interceptor.Interceptor.Priority.APPLICATION}} > We should change them to show full qualified path or add static import to examples for readability sake. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 10 04:55:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 10 Jan 2017 04:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-670) Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-670 started by Antoine Sabot-Durand. ------------------------------------------------ > Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning > ------------------------------------------------------------------------ > > Key: CDI-670 > URL: https://issues.jboss.org/browse/CDI-670 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Priority: Critical > Fix For: 2.0 .Final > > > It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap): > {code:java} > @Inject > Foo myFoo; > @Produces > @RequestScoped // -> Requires a client proxy > public Foo produce(InterceptionFactory interceptionFactory) { > // Suppose Foo has a final method > return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new Foo()); > } > {code} > The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method). > I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 10 07:33:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 10 Jan 2017 07:33:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-644) Link formatting in the specification text In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13345344#comment-13345344 ] Antoine Sabot-Durand commented on CDI-644: ------------------------------------------ I'm investigating this, but not sure to provide a solution before 2.0 spec doc release. > 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 > Fix For: 2.0 .Final > > > In previous versions (1.x) of specification links to chapters within spec were formatted as follows: > {noformat} > Section 2.4.1, ?Built-in scope types? > {noformat} > I would like to preserve this formatting (especialy the prefix "Section x.x.x") also in the new specification version because I think it's more legible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 10 07:33:01 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 10 Jan 2017 07:33:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-644) Link formatting in the specification text In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-644: ---------------------------------------- Assignee: Antoine Sabot-Durand > 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 > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > In previous versions (1.x) of specification links to chapters within spec were formatted as follows: > {noformat} > Section 2.4.1, ?Built-in scope types? > {noformat} > I would like to preserve this formatting (especialy the prefix "Section x.x.x") also in the new specification version because I think it's more legible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 10 08:26:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 10 Jan 2017 08:26:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-644) Link formatting in the specification text In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13345369#comment-13345369 ] Antoine Sabot-Durand commented on CDI-644: ------------------------------------------ No simple solution at that moment. It's being discussed here : https://github.com/asciidoctor/asciidoctor/issues/858 Scenarios are * Switch back to docbook generation. Seems not very hard on the paper but side effects may be overkill * Write an asciidoctor post processor to add these section number. I'm not sure yet if it can be wrritten in Java or Ruby and given the priority, I'm not sure it worth it. I propose to postpone this to 2.1 > 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 > Assignee: Antoine Sabot-Durand > Fix For: 2.1 (Discussion) > > > In previous versions (1.x) of specification links to chapters within spec were formatted as follows: > {noformat} > Section 2.4.1, ?Built-in scope types? > {noformat} > I would like to preserve this formatting (especialy the prefix "Section x.x.x") also in the new specification version because I think it's more legible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 10 08:26:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 10 Jan 2017 08:26:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-644) Link formatting in the specification text In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-644: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 .Final) > 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 > Assignee: Antoine Sabot-Durand > Fix For: 2.1 (Discussion) > > > In previous versions (1.x) of specification links to chapters within spec were formatted as follows: > {noformat} > Section 2.4.1, ?Built-in scope types? > {noformat} > I would like to preserve this formatting (especialy the prefix "Section x.x.x") also in the new specification version because I think it's more legible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jan 10 09:40:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 10 Jan 2017 09:40:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-680) SPI configurators - missing statement about deployment problem In-Reply-To: References: Message-ID: Tomas Remes created CDI-680: ------------------------------- Summary: SPI configurators - missing statement about deployment problem Key: CDI-680 URL: https://issues.jboss.org/browse/CDI-680 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 2.0.Beta1 Reporter: Tomas Remes In {{11.5.3. AfterBeanDiscovery event}} spec states: {quote} The second version of the method, returns a new ObserverMethodConfigurator as defined in ObserverMethodConfigurator interface to easily configure the ObserverMethod which will be added at the end of observer invocation. If the container is unable to process the configurator it automatically detects the problem and treats it as a deployment problem. {quote} I think we should add the second sentence also for other configurators (not only for {{ObserverMethodConfigurator}}) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Tue Jan 10 12:03:33 2017 From: john.ament at spartasystems.com (John Ament) Date: Tue, 10 Jan 2017 17:03:33 +0000 Subject: [cdi-dev] Meeting on? Message-ID: Hi, Few of us are on IRC. Are we having the meeting today? 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/20170110/672f98db/attachment.html From antoine at sabot-durand.net Tue Jan 10 12:18:21 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 10 Jan 2017 17:18:21 +0000 Subject: [cdi-dev] Meeting on? In-Reply-To: References: Message-ID: Sorry guys I am still stuck in traffic to get my daughter. So no meeting today. Antoine Le mar. 10 janv. 2017 ? 18:04, John Ament a ?crit : > Hi, > > > Few of us are on IRC. Are we having the meeting today? > > > 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/20170110/23fc8bad/attachment-0001.html From issues at jboss.org Wed Jan 11 10:49:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 11 Jan 2017 10:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-681) Spec doesn't talk about BeanConfigurator.read method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated CDI-681: ---------------------------- Fix Version/s: 2.0 .Final > Spec doesn't talk about BeanConfigurator.read method > ---------------------------------------------------- > > Key: CDI-681 > URL: https://issues.jboss.org/browse/CDI-681 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Priority: Blocker > Fix For: 2.0 .Final > > > Spec doesn't mention this method which could be confusing e.g with following (recently added) rule: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method, the Default Scope rules apply. > {quote} > When you use this {{read}} method then it makes sense to copy scope from original AnnotatedType (current Weld behaviour) so I would reword this e.g to: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method or BeanConfigurator is not initialized with one of its read methods, the Default Scope rules apply. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jan 11 10:49:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 11 Jan 2017 10:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-681) Spec doesn't talk about BeanConfigurator.read method In-Reply-To: References: Message-ID: Tomas Remes created CDI-681: ------------------------------- Summary: Spec doesn't talk about BeanConfigurator.read method Key: CDI-681 URL: https://issues.jboss.org/browse/CDI-681 Project: CDI Specification Issues Issue Type: Bug Reporter: Tomas Remes Priority: Blocker Spec doesn't mention this method which could be confusing e.g with following (recently added) rule: {quote} If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method, the Default Scope rules apply. {quote} When you use this {{read}} method then it makes sense to copy scope from original AnnotatedType (current Weld behaviour) so I would reword this e.g to: {quote} If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method or BeanConfigurator is not initialized with one of its read methods, the Default Scope rules apply. {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jan 12 01:29:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 12 Jan 2017 01:29:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-681) Spec doesn't talk about BeanConfigurator.read method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13346879#comment-13346879 ] Martin Kouba commented on CDI-681: ---------------------------------- We can also omit the "via the BeanConfigurator.scope() method" part, e.g. bq. If a BeanConfigurator has no scope specified, the ... > Spec doesn't talk about BeanConfigurator.read method > ---------------------------------------------------- > > Key: CDI-681 > URL: https://issues.jboss.org/browse/CDI-681 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Priority: Blocker > Fix For: 2.0 .Final > > > Spec doesn't mention this method which could be confusing e.g with following (recently added) rule: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method, the Default Scope rules apply. > {quote} > When you use this {{read}} method then it makes sense to copy scope from original AnnotatedType (current Weld behaviour) so I would reword this e.g to: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method or BeanConfigurator is not initialized with one of its read methods, the Default Scope rules apply. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jan 12 01:30:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 12 Jan 2017 01:30:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-681) Spec doesn't talk about BeanConfigurator.read method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13346879#comment-13346879 ] Martin Kouba edited comment on CDI-681 at 1/12/17 1:29 AM: ----------------------------------------------------------- We could also omit the _"via the BeanConfigurator.scope() method"_ part, e.g. bq. If a BeanConfigurator has no scope specified, the ... was (Author: mkouba): We can also omit the "via the BeanConfigurator.scope() method" part, e.g. bq. If a BeanConfigurator has no scope specified, the ... > Spec doesn't talk about BeanConfigurator.read method > ---------------------------------------------------- > > Key: CDI-681 > URL: https://issues.jboss.org/browse/CDI-681 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Priority: Blocker > Fix For: 2.0 .Final > > > Spec doesn't mention this method which could be confusing e.g with following (recently added) rule: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method, the Default Scope rules apply. > {quote} > When you use this {{read}} method then it makes sense to copy scope from original AnnotatedType (current Weld behaviour) so I would reword this e.g to: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method or BeanConfigurator is not initialized with one of its read methods, the Default Scope rules apply. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jan 12 02:34:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 12 Jan 2017 02:34:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-681) Spec doesn't talk about BeanConfigurator.read method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13346886#comment-13346886 ] Matej Novotny commented on CDI-681: ----------------------------------- Also, the spec doesn't say anything about what happens when you: * First add a stereotype which defines a scope (like {{@Model}}) * Then you set the scope via `scope(..)` method > Spec doesn't talk about BeanConfigurator.read method > ---------------------------------------------------- > > Key: CDI-681 > URL: https://issues.jboss.org/browse/CDI-681 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Priority: Blocker > Fix For: 2.0 .Final > > > Spec doesn't mention this method which could be confusing e.g with following (recently added) rule: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method, the Default Scope rules apply. > {quote} > When you use this {{read}} method then it makes sense to copy scope from original AnnotatedType (current Weld behaviour) so I would reword this e.g to: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method or BeanConfigurator is not initialized with one of its read methods, the Default Scope rules apply. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jan 12 02:44:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 12 Jan 2017 02:44:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-681) Spec doesn't talk about BeanConfigurator.read method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13346889#comment-13346889 ] Martin Kouba commented on CDI-681: ---------------------------------- A scope set manually should have precedence - see also 2.4.4. Default scope. > Spec doesn't talk about BeanConfigurator.read method > ---------------------------------------------------- > > Key: CDI-681 > URL: https://issues.jboss.org/browse/CDI-681 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Priority: Blocker > Fix For: 2.0 .Final > > > Spec doesn't mention this method which could be confusing e.g with following (recently added) rule: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method, the Default Scope rules apply. > {quote} > When you use this {{read}} method then it makes sense to copy scope from original AnnotatedType (current Weld behaviour) so I would reword this e.g to: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method or BeanConfigurator is not initialized with one of its read methods, the Default Scope rules apply. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jan 12 02:53:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 12 Jan 2017 02:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-681) Spec doesn't talk about BeanConfigurator.read method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13346886#comment-13346886 ] Matej Novotny edited comment on CDI-681 at 1/12/17 2:52 AM: ------------------------------------------------------------ -Also, the spec doesn't say anything about what happens when you:- * -First add a stereotype which defines a scope (like {{@Model}})- * -Then you set the scope via `scope(..)` method- EDIT: Ignore my comment, Martin is right, this is covered by 2.4.4 Default Scope chapter. was (Author: manovotn): Also, the spec doesn't say anything about what happens when you: * First add a stereotype which defines a scope (like {{@Model}}) * Then you set the scope via `scope(..)` method > Spec doesn't talk about BeanConfigurator.read method > ---------------------------------------------------- > > Key: CDI-681 > URL: https://issues.jboss.org/browse/CDI-681 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Priority: Blocker > Fix For: 2.0 .Final > > > Spec doesn't mention this method which could be confusing e.g with following (recently added) rule: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method, the Default Scope rules apply. > {quote} > When you use this {{read}} method then it makes sense to copy scope from original AnnotatedType (current Weld behaviour) so I would reword this e.g to: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method or BeanConfigurator is not initialized with one of its read methods, the Default Scope rules apply. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jan 12 06:14:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Jan 2017 06:14:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-681) Spec doesn't talk about BeanConfigurator.read method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-681: ---------------------------------------- Assignee: Antoine Sabot-Durand > Spec doesn't talk about BeanConfigurator.read method > ---------------------------------------------------- > > Key: CDI-681 > URL: https://issues.jboss.org/browse/CDI-681 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Priority: Blocker > Fix For: 2.0 .Final > > > Spec doesn't mention this method which could be confusing e.g with following (recently added) rule: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method, the Default Scope rules apply. > {quote} > When you use this {{read}} method then it makes sense to copy scope from original AnnotatedType (current Weld behaviour) so I would reword this e.g to: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method or BeanConfigurator is not initialized with one of its read methods, the Default Scope rules apply. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jan 12 07:39:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 12 Jan 2017 07:39:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-681) Spec doesn't talk about BeanConfigurator.read method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13347214#comment-13347214 ] Martin Kouba commented on CDI-681: ---------------------------------- I think the spec text should reference or follow the wording from the section "11.3.23. Obtaining a BeanAttributes". The important part is _"according to the rules defined in Concepts"_ which implies that the scope is defaulted. > Spec doesn't talk about BeanConfigurator.read method > ---------------------------------------------------- > > Key: CDI-681 > URL: https://issues.jboss.org/browse/CDI-681 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Priority: Blocker > Fix For: 2.0 .Final > > > Spec doesn't mention this method which could be confusing e.g with following (recently added) rule: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method, the Default Scope rules apply. > {quote} > When you use this {{read}} method then it makes sense to copy scope from original AnnotatedType (current Weld behaviour) so I would reword this e.g to: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method or BeanConfigurator is not initialized with one of its read methods, the Default Scope rules apply. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jan 12 07:52:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Jan 2017 07:52:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-681) Spec doesn't talk about BeanConfigurator.read method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-681 started by Antoine Sabot-Durand. ------------------------------------------------ > Spec doesn't talk about BeanConfigurator.read method > ---------------------------------------------------- > > Key: CDI-681 > URL: https://issues.jboss.org/browse/CDI-681 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Priority: Blocker > Fix For: 2.0 .Final > > > Spec doesn't mention this method which could be confusing e.g with following (recently added) rule: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method, the Default Scope rules apply. > {quote} > When you use this {{read}} method then it makes sense to copy scope from original AnnotatedType (current Weld behaviour) so I would reword this e.g to: > {quote} > If a BeanConfigurator has no scope specified via the BeanConfigurator.scope() method or BeanConfigurator is not initialized with one of its read methods, the Default Scope rules apply. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jan 12 07:54:01 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Jan 2017 07:54:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-679) ProducerConfigurator should provide the possibility to simulate parameter injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-679: ------------------------------------- Fix Version/s: 2.1 (Discussion) > ProducerConfigurator should provide the possibility to simulate parameter injection > ------------------------------------------------------------------------------------ > > Key: CDI-679 > URL: https://issues.jboss.org/browse/CDI-679 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Fix For: 2.1 (Discussion) > > > As BeanConfigurator, ProducerConfigurator should provide {{ BeanConfigurator produceWith(Function, U> callback);}} to simulate parameter injection in producer method. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From antoine at sabot-durand.net Fri Jan 13 08:20:17 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 13 Jan 2017 13:20:17 +0000 Subject: [cdi-dev] Release schedule Message-ID: Hi all, If everything goes as planned we should be able to start the official release process for CDI 2.0 next week. We still have 3 PR opens impacting only the specs doc, so I started the release of the API today to help RI and TCK to align on it. Reviews on last PRs are most welcome. Thanks to you all, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170113/94c08d3a/attachment.html From antoine at sabot-durand.net Tue Jan 17 10:09:28 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 17 Jan 2017 15:09:28 +0000 Subject: [cdi-dev] CDI 2.0 is (nearly) over, let's start discussion on CDI 2.1 Message-ID: Hi Guys, Release of CDI 2.0 is around the corner and I'd like to thank all of you for your help on this long adventure. Next CDI episode (or season) is also getting closer. We plan to continue our effort on CDI with a new version (probably CDI 2.1). This version try to focus on this main topic: - Java EE 8 alignment - MicroProfile enhancement - Java 9 and Jigsaw support (java 8 will always be the minimum java version support) - ... We also have a list of ticket that we postponed for CDI 2.1: https://issues.jboss.org/browse/CDI-679?filter=12328671 If you have other ideas, suggestion, wishes. Please feel free to share them here so that we can discuss their integration on the coming JSR proposal. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170117/1a432e6a/attachment.html From antoine at sabot-durand.net Tue Jan 17 10:31:17 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 17 Jan 2017 15:31:17 +0000 Subject: [cdi-dev] Canceling meeting tonight Message-ID: won't be able to attend. Sorry, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170117/2e8ef2fb/attachment.html From struberg at yahoo.de Thu Jan 19 04:30:46 2017 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Jan 2017 10:30:46 +0100 Subject: [cdi-dev] CDI 2.0 is (nearly) over, let's start discussion on CDI 2.1 In-Reply-To: References: Message-ID: And also thanks to you, Antoine, for pushing this specification forward. I think CDI-2.0 will be a corner stones of any upcoming JavaEE 8 release (whenever this will be). txs and LieGrue, strub > Am 17.01.2017 um 16:09 schrieb Antoine Sabot-Durand : > > Hi Guys, > > Release of CDI 2.0 is around the corner and I'd like to thank all of you for your help on this long adventure. > > Next CDI episode (or season) is also getting closer. We plan to continue our effort on CDI with a new version (probably CDI 2.1). > > This version try to focus on this main topic: > - Java EE 8 alignment > - MicroProfile enhancement > - Java 9 and Jigsaw support (java 8 will always be the minimum java version support) > - ... > > We also have a list of ticket that we postponed for CDI 2.1: https://issues.jboss.org/browse/CDI-679?filter=12328671 > > If you have other ideas, suggestion, wishes. Please feel free to share them here so that we can discuss their integration on the coming JSR proposal. > > > 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. From reza_rahman at lycos.com Thu Jan 19 11:49:42 2017 From: reza_rahman at lycos.com (Reza Rahman) Date: Thu, 19 Jan 2017 11:49:42 -0500 Subject: [cdi-dev] CDI 2.0 is (nearly) over, let's start discussion on CDI 2.1 In-Reply-To: References: Message-ID: <2784FBAC-A71E-4B61-AA77-6A24CCD951E0@lycos.com> For the record, my wish list for CDI remains the same since CDI 1.1. I'd like to see @Asynchronous and @Lock included in CDI. Oracle has shown no interest in making these features available outside EJB and this continues to be a pain point for many in the Java EE community. > On Jan 17, 2017, at 10:09 AM, Antoine Sabot-Durand wrote: > > Hi Guys, > > Release of CDI 2.0 is around the corner and I'd like to thank all of you for your help on this long adventure. > > Next CDI episode (or season) is also getting closer. We plan to continue our effort on CDI with a new version (probably CDI 2.1). > > This version try to focus on this main topic: > - Java EE 8 alignment > - MicroProfile enhancement > - Java 9 and Jigsaw support (java 8 will always be the minimum java version support) > - ... > > We also have a list of ticket that we postponed for CDI 2.1: https://issues.jboss.org/browse/CDI-679?filter=12328671 > > If you have other ideas, suggestion, wishes. Please feel free to share them here so that we can discuss their integration on the coming JSR proposal. > > > 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/20170119/a2b40d33/attachment.html From john.ament at spartasystems.com Fri Jan 20 04:50:45 2017 From: john.ament at spartasystems.com (John Ament) Date: Fri, 20 Jan 2017 09:50:45 +0000 Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 Message-ID: All, Just as a heads up, not sure if we knew this or not, but presently DeltaSpike does not compile with CDI 2 on the classpath. DS ships with a number of implementations of Annotated within. Was getAnnotations intended to be a default method? 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/20170120/4a3bbaf7/attachment-0001.html From john.ament at spartasystems.com Fri Jan 20 05:00:48 2017 From: john.ament at spartasystems.com (John Ament) Date: Fri, 20 Jan 2017 10:00:48 +0000 Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 In-Reply-To: References: Message-ID: Actually I just double checked, as I thought I asked this already https://github.com/cdi-spec/cdi/pull/330#issuecomment-259986093 So I dug a bit more. It seems that whatever was released as "2.0.Beta1" doesn't include the default methods. I'm not sure why but the tag wasn't pushed up to the repo either, so its hard to tell. John ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of John Ament Sent: Friday, January 20, 2017 4:50 AM To: cdi-dev Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 All, Just as a heads up, not sure if we knew this or not, but presently DeltaSpike does not compile with CDI 2 on the classpath. DS ships with a number of implementations of Annotated within. Was getAnnotations intended to be a default method? 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. ________________________________ 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/20170120/8e3a0698/attachment.html From manovotn at redhat.com Fri Jan 20 05:01:07 2017 From: manovotn at redhat.com (Matej Novotny) Date: Fri, 20 Jan 2017 05:01:07 -0500 (EST) Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 In-Reply-To: References: Message-ID: <584082592.14483061.1484906467122.JavaMail.zimbra@redhat.com> Hi John It is a known "issue" which I even sent an email about to DS mailing list. The cause is that DS compiles against Java 6 and CDI 2.0 adds a bunch of *default* methods which will then not be recognized. This in the end means that some DS classes (implementing interfaces from CDI where such methods were addded) cannot be compiled as implementation will be missing. The easiest solution is to compile with --source=1.8 and --target=1.8 Here is the link to the email conversation I originally sent - https://lists.apache.org/list.html?dev at deltaspike.apache.org:2016-12 Regards Matej ----- Original Message ----- > From: "John Ament" > To: "cdi-dev" > Sent: Friday, January 20, 2017 10:50:45 AM > Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > All, > > > > > Just as a heads up, not sure if we knew this or not, but presently DeltaSpike > does not compile with CDI 2 on the classpath. DS ships with a number of > implementations of Annotated within. Was getAnnotations intended to be a > default method? > > > > > 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 manovotn at redhat.com Fri Jan 20 05:04:02 2017 From: manovotn at redhat.com (Matej Novotny) Date: Fri, 20 Jan 2017 05:04:02 -0500 (EST) Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 In-Reply-To: <584082592.14483061.1484906467122.JavaMail.zimbra@redhat.com> References: <584082592.14483061.1484906467122.JavaMail.zimbra@redhat.com> Message-ID: <965490869.14483507.1484906642515.JavaMail.zimbra@redhat.com> Bad link, sorry, here is a permanent one https://lists.apache.org/thread.html/0cb489f620990037c9eaf16400dd06de7e5a979f8c78c046ab6ff3c1@%3Cdev.deltaspike.apache.org%3E ----- Original Message ----- > From: "Matej Novotny" > To: "John Ament" > Cc: "cdi-dev" > Sent: Friday, January 20, 2017 11:01:07 AM > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > Hi John > > It is a known "issue" which I even sent an email about to DS mailing list. > > The cause is that DS compiles against Java 6 and CDI 2.0 adds a bunch of > *default* methods which will then not be recognized. > This in the end means that some DS classes (implementing interfaces from CDI > where such methods were addded) cannot be compiled as implementation will be > missing. > > The easiest solution is to compile with --source=1.8 and --target=1.8 > > Here is the link to the email conversation I originally sent - > https://lists.apache.org/list.html?dev at deltaspike.apache.org:2016-12 > > Regards > Matej > > ----- Original Message ----- > > From: "John Ament" > > To: "cdi-dev" > > Sent: Friday, January 20, 2017 10:50:45 AM > > Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > > > > > All, > > > > > > > > > > Just as a heads up, not sure if we knew this or not, but presently > > DeltaSpike > > does not compile with CDI 2 on the classpath. DS ships with a number of > > implementations of Annotated within. Was getAnnotations intended to be a > > default method? > > > > > > > > > > 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. > From rmannibucau at gmail.com Fri Jan 20 05:18:59 2017 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 20 Jan 2017 11:18:59 +0100 Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 In-Reply-To: <965490869.14483507.1484906642515.JavaMail.zimbra@redhat.com> References: <584082592.14483061.1484906467122.JavaMail.zimbra@redhat.com> <965490869.14483507.1484906642515.JavaMail.zimbra@redhat.com> Message-ID: Is it still on 2.0? J6 code should still run for backward compatibility. Le 20 janv. 2017 11:05, "Matej Novotny" a ?crit : > Bad link, sorry, here is a permanent one > https://lists.apache.org/thread.html/0cb489f620990037c9eaf16400dd06 > de7e5a979f8c78c046ab6ff3c1@%3Cdev.deltaspike.apache.org%3E > > ----- Original Message ----- > > From: "Matej Novotny" > > To: "John Ament" > > Cc: "cdi-dev" > > Sent: Friday, January 20, 2017 11:01:07 AM > > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > Hi John > > > > It is a known "issue" which I even sent an email about to DS mailing > list. > > > > The cause is that DS compiles against Java 6 and CDI 2.0 adds a bunch of > > *default* methods which will then not be recognized. > > This in the end means that some DS classes (implementing interfaces from > CDI > > where such methods were addded) cannot be compiled as implementation > will be > > missing. > > > > The easiest solution is to compile with --source=1.8 and --target=1.8 > > > > Here is the link to the email conversation I originally sent - > > https://lists.apache.org/list.html?dev at deltaspike.apache.org:2016-12 > > > > Regards > > Matej > > > > ----- Original Message ----- > > > From: "John Ament" > > > To: "cdi-dev" > > > Sent: Friday, January 20, 2017 10:50:45 AM > > > Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > > > > > > > > > All, > > > > > > > > > > > > > > > Just as a heads up, not sure if we knew this or not, but presently > > > DeltaSpike > > > does not compile with CDI 2 on the classpath. DS ships with a number of > > > implementations of Annotated within. Was getAnnotations intended to be > a > > > default method? > > > > > > > > > > > > > > > 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. > > > _______________________________________________ > 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/20170120/1fc28360/attachment-0001.html From EMIJIANG at uk.ibm.com Fri Jan 20 05:38:39 2017 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Fri, 20 Jan 2017 10:38:39 +0000 Subject: [cdi-dev] CDI 2.0 is (nearly) over, let's start discussion on CDI 2.1 In-Reply-To: References: Message-ID: Yes, thanks to Antoine for leading this great piece of work! It was so enjoyable to work with you all! Wonderful journey! 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: Mark Struberg To: Sabot-Durand Antoine Cc: cdi-dev Date: 19/01/2017 09:32 Subject: Re: [cdi-dev] CDI 2.0 is (nearly) over, let's start discussion on CDI 2.1 Sent by: cdi-dev-bounces at lists.jboss.org And also thanks to you, Antoine, for pushing this specification forward. I think CDI-2.0 will be a corner stones of any upcoming JavaEE 8 release (whenever this will be). txs and LieGrue, strub > Am 17.01.2017 um 16:09 schrieb Antoine Sabot-Durand : > > Hi Guys, > > Release of CDI 2.0 is around the corner and I'd like to thank all of you for your help on this long adventure. > > Next CDI episode (or season) is also getting closer. We plan to continue our effort on CDI with a new version (probably CDI 2.1). > > This version try to focus on this main topic: > - Java EE 8 alignment > - MicroProfile enhancement > - Java 9 and Jigsaw support (java 8 will always be the minimum java version support) > - ... > > We also have a list of ticket that we postponed for CDI 2.1: https://issues.jboss.org/browse/CDI-679?filter=12328671 > > If you have other ideas, suggestion, wishes. Please feel free to share them here so that we can discuss their integration on the coming JSR proposal. > > > 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. 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/20170120/e021ffd4/attachment.html From john.ament at spartasystems.com Fri Jan 20 07:39:34 2017 From: john.ament at spartasystems.com (John Ament) Date: Fri, 20 Jan 2017 12:39:34 +0000 Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 In-Reply-To: <965490869.14483507.1484906642515.JavaMail.zimbra@redhat.com> References: <584082592.14483061.1484906467122.JavaMail.zimbra@redhat.com>, <965490869.14483507.1484906642515.JavaMail.zimbra@redhat.com> Message-ID: Matej, Ok, so now I understand better what you were trying to say in your email. Some context may have helped, e.g. "hey guys when compiling with Java 6 the compiler ignores the default flag on an interface and expects it to be implemented .. therefore blah blah blah..." I think I can push up a fix. Tks. John ________________________________ From: Matej Novotny Sent: Friday, January 20, 2017 5:04 AM To: John Ament Cc: cdi-dev Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 Bad link, sorry, here is a permanent one https://lists.apache.org/thread.html/0cb489f620990037c9eaf16400dd06de7e5a979f8c78c046ab6ff3c1@%3Cdev.deltaspike.apache.org%3E ----- Original Message ----- > From: "Matej Novotny" > To: "John Ament" > Cc: "cdi-dev" > Sent: Friday, January 20, 2017 11:01:07 AM > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > Hi John > > It is a known "issue" which I even sent an email about to DS mailing list. > > The cause is that DS compiles against Java 6 and CDI 2.0 adds a bunch of > *default* methods which will then not be recognized. > This in the end means that some DS classes (implementing interfaces from CDI > where such methods were addded) cannot be compiled as implementation will be > missing. > > The easiest solution is to compile with --source=1.8 and --target=1.8 > > Here is the link to the email conversation I originally sent - > https://lists.apache.org/list.html?dev at deltaspike.apache.org:2016-12 > > Regards > Matej > > ----- Original Message ----- > > From: "John Ament" > > To: "cdi-dev" > > Sent: Friday, January 20, 2017 10:50:45 AM > > Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > > > > > All, > > > > > > > > > > Just as a heads up, not sure if we knew this or not, but presently > > DeltaSpike > > does not compile with CDI 2 on the classpath. DS ships with a number of > > implementations of Annotated within. Was getAnnotations intended to be a > > default method? > > > > > > > > > > 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 cdi-dev Info Page - JBoss Developer 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 Apache License, Version 2.0 www.apache.org Home page of The Apache Software Foundation > > 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 cdi-dev Info Page - JBoss Developer 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. > ________________________________ 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/20170120/ef94abd6/attachment-0001.html From werner.keil at gmail.com Fri Jan 20 07:53:16 2017 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 20 Jan 2017 13:53:16 +0100 Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 Message-ID: Actually it doesn't in many cases. We started compiling the JSR 363 API and RI with J6 for support of the largest possible number of runtimes, but Java ME 8 Embedded / CLDC 8 (based on Java SE 7, not 8) would not accept those JARs either. Once we built it with JDK 7 and J7 compatible settings, it worked. Werner On Fri, Jan 20, 2017 at 11:19 AM, 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: DeltaSpike not compiling with CDI 2.0/Weld 3 (John Ament) > 2. Re: DeltaSpike not compiling with CDI 2.0/Weld 3 (Matej Novotny) > 3. Re: DeltaSpike not compiling with CDI 2.0/Weld 3 (Matej Novotny) > 4. Re: DeltaSpike not compiling with CDI 2.0/Weld 3 > (Romain Manni-Bucau) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 20 Jan 2017 10:00:48 +0000 > From: John Ament > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > To: cdi-dev > Message-ID: > namprd04.prod.outlook.com> > > Content-Type: text/plain; charset="iso-8859-1" > > Actually I just double checked, as I thought I asked this already > > > https://github.com/cdi-spec/cdi/pull/330#issuecomment-259986093 > > > So I dug a bit more. It seems that whatever was released as "2.0.Beta1" > doesn't include the default methods. I'm not sure why but the tag wasn't > pushed up to the repo either, so its hard to tell. > > > John > > > ________________________________ > From: cdi-dev-bounces at lists.jboss.org > on behalf of John Ament > Sent: Friday, January 20, 2017 4:50 AM > To: cdi-dev > Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > All, > > > Just as a heads up, not sure if we knew this or not, but presently > DeltaSpike does not compile with CDI 2 on the classpath. DS ships with a > number of implementations of Annotated within. Was getAnnotations > intended to be a default method? > > > 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. > ________________________________ > 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/ > 20170120/8e3a0698/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Fri, 20 Jan 2017 05:01:07 -0500 (EST) > From: Matej Novotny > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > To: John Ament > Cc: cdi-dev > Message-ID: > <584082592.14483061.1484906467122.JavaMail.zimbra at redhat.com> > Content-Type: text/plain; charset=utf-8 > > Hi John > > It is a known "issue" which I even sent an email about to DS mailing list. > > The cause is that DS compiles against Java 6 and CDI 2.0 adds a bunch of > *default* methods which will then not be recognized. > This in the end means that some DS classes (implementing interfaces from > CDI where such methods were addded) cannot be compiled as implementation > will be missing. > > The easiest solution is to compile with --source=1.8 and --target=1.8 > > Here is the link to the email conversation I originally sent - > https://lists.apache.org/list.html?dev at deltaspike.apache.org:2016-12 > > Regards > Matej > > ----- Original Message ----- > > From: "John Ament" > > To: "cdi-dev" > > Sent: Friday, January 20, 2017 10:50:45 AM > > Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > > > > > All, > > > > > > > > > > Just as a heads up, not sure if we knew this or not, but presently > DeltaSpike > > does not compile with CDI 2 on the classpath. DS ships with a number of > > implementations of Annotated within. Was getAnnotations intended to be a > > default method? > > > > > > > > > > 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. > > > ------------------------------ > > Message: 3 > Date: Fri, 20 Jan 2017 05:04:02 -0500 (EST) > From: Matej Novotny > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > To: John Ament > Cc: cdi-dev > Message-ID: > <965490869.14483507.1484906642515.JavaMail.zimbra at redhat.com> > Content-Type: text/plain; charset=utf-8 > > Bad link, sorry, here is a permanent one > https://lists.apache.org/thread.html/0cb489f620990037c9eaf16400dd06 > de7e5a979f8c78c046ab6ff3c1@%3Cdev.deltaspike.apache.org%3E > > ----- Original Message ----- > > From: "Matej Novotny" > > To: "John Ament" > > Cc: "cdi-dev" > > Sent: Friday, January 20, 2017 11:01:07 AM > > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > Hi John > > > > It is a known "issue" which I even sent an email about to DS mailing > list. > > > > The cause is that DS compiles against Java 6 and CDI 2.0 adds a bunch of > > *default* methods which will then not be recognized. > > This in the end means that some DS classes (implementing interfaces from > CDI > > where such methods were addded) cannot be compiled as implementation > will be > > missing. > > > > The easiest solution is to compile with --source=1.8 and --target=1.8 > > > > Here is the link to the email conversation I originally sent - > > https://lists.apache.org/list.html?dev at deltaspike.apache.org:2016-12 > > > > Regards > > Matej > > > > ----- Original Message ----- > > > From: "John Ament" > > > To: "cdi-dev" > > > Sent: Friday, January 20, 2017 10:50:45 AM > > > Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > > > > > > > > > All, > > > > > > > > > > > > > > > Just as a heads up, not sure if we knew this or not, but presently > > > DeltaSpike > > > does not compile with CDI 2 on the classpath. DS ships with a number of > > > implementations of Annotated within. Was getAnnotations intended to be > a > > > default method? > > > > > > > > > > > > > > > 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. > > > > > ------------------------------ > > Message: 4 > Date: Fri, 20 Jan 2017 11:18:59 +0100 > From: Romain Manni-Bucau > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > To: Matej Novotny > Cc: cdi-dev at lists.jboss.org > Message-ID: > qgYw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Is it still on 2.0? J6 code should still run for backward compatibility. > > Le 20 janv. 2017 11:05, "Matej Novotny" a ?crit : > > > Bad link, sorry, here is a permanent one > > https://lists.apache.org/thread.html/0cb489f620990037c9eaf16400dd06 > > de7e5a979f8c78c046ab6ff3c1@%3Cdev.deltaspike.apache.org%3E > > > > ----- Original Message ----- > > > From: "Matej Novotny" > > > To: "John Ament" > > > Cc: "cdi-dev" > > > Sent: Friday, January 20, 2017 11:01:07 AM > > > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > > > Hi John > > > > > > It is a known "issue" which I even sent an email about to DS mailing > > list. > > > > > > The cause is that DS compiles against Java 6 and CDI 2.0 adds a bunch > of > > > *default* methods which will then not be recognized. > > > This in the end means that some DS classes (implementing interfaces > from > > CDI > > > where such methods were addded) cannot be compiled as implementation > > will be > > > missing. > > > > > > The easiest solution is to compile with --source=1.8 and --target=1.8 > > > > > > Here is the link to the email conversation I originally sent - > > > https://lists.apache.org/list.html?dev at deltaspike.apache.org:2016-12 > > > > > > Regards > > > Matej > > > > > > ----- Original Message ----- > > > > From: "John Ament" > > > > To: "cdi-dev" > > > > Sent: Friday, January 20, 2017 10:50:45 AM > > > > Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > > Just as a heads up, not sure if we knew this or not, but presently > > > > DeltaSpike > > > > does not compile with CDI 2 on the classpath. DS ships with a number > of > > > > implementations of Annotated within. Was getAnnotations intended to > be > > a > > > > default method? > > > > > > > > > > > > > > > > > > > > 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. > > > > > _______________________________________________ > > 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/ > 20170120/1fc28360/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 74, Issue 10 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170120/0a8551cb/attachment-0001.html From werner.keil at gmail.com Fri Jan 20 08:06:00 2017 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 20 Jan 2017 14:06:00 +0100 Subject: [cdi-dev] CDI 2.0 is (nearly) over, let's start discussion on CDI 2.1 Message-ID: Yes, thanks Antoine for one of the more active Java EE JSRs in recent months. Hopefully CDI 2.0 will soon release a Public Review, like well-deserved Spec Lead Winner Dimtry did with his 2nd JSON JSR now: https://jcp.org/aboutJava/communityprocess/pr/jsr374/index.html (some of the Apache-inspired ideas were also included, but don't expect Johnzon to work with JSR-374 still built against JDK6 either, it likely must be based on Java SE 8;-) We may see Java EE 8 with a somewhat smaller scope and content (e.g. mostly "Microprofile" related stuff like JSON-B 1.0, JSON-P 1.1, JAX-RS 2.1 and as it looks like CDI 2.0, Servlet 4 or JSF 2.3, not sure about Bean Validation 2.0, depends on its ability to catch-up) but I am very confident, Java EE 8 will be feature-complete no later than JavaOne and we should see a Final at least a year from now. Like prior ones they will keep it time-boxed, among the reasons why Dmitry focusses on his 2 JSRs and won't take the trouble of a config one till early 2018. So it can be added to Java EE 9 (or 8.1;-) Werner On Fri, Jan 20, 2017 at 1:39 PM, 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: CDI 2.0 is (nearly) over, let's start discussion on CDI > 2.1 (Emily Jiang) > 2. Re: DeltaSpike not compiling with CDI 2.0/Weld 3 (John Ament) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 20 Jan 2017 10:38:39 +0000 > From: Emily Jiang > Subject: Re: [cdi-dev] CDI 2.0 is (nearly) over, let's start > discussion on CDI 2.1 > To: Mark Struberg > Cc: cdi-dev > Message-ID: > 003A7D63 at notes.na.collabserv.com> > > Content-Type: text/plain; charset="us-ascii" > > Yes, thanks to Antoine for leading this great piece of work! It was so > enjoyable to work with you all! Wonderful journey! > > 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: Mark Struberg > To: Sabot-Durand Antoine > Cc: cdi-dev > Date: 19/01/2017 09:32 > Subject: Re: [cdi-dev] CDI 2.0 is (nearly) over, let's start > discussion on CDI 2.1 > Sent by: cdi-dev-bounces at lists.jboss.org > > > > And also thanks to you, Antoine, for pushing this specification forward. > > I think CDI-2.0 will be a corner stones of any upcoming JavaEE 8 release > (whenever this will be). > > txs and LieGrue, > strub > > > > Am 17.01.2017 um 16:09 schrieb Antoine Sabot-Durand > : > > > > Hi Guys, > > > > Release of CDI 2.0 is around the corner and I'd like to thank all of you > for your help on this long adventure. > > > > Next CDI episode (or season) is also getting closer. We plan to continue > our effort on CDI with a new version (probably CDI 2.1). > > > > This version try to focus on this main topic: > > - Java EE 8 alignment > > - MicroProfile enhancement > > - Java 9 and Jigsaw support (java 8 will always be the minimum java > version support) > > - ... > > > > We also have a list of ticket that we postponed for CDI 2.1: > https://issues.jboss.org/browse/CDI-679?filter=12328671 > > > > If you have other ideas, suggestion, wishes. Please feel free to share > them here so that we can discuss their integration on the coming JSR > proposal. > > > > > > 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. > > > > 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/ > 20170120/e021ffd4/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Fri, 20 Jan 2017 12:39:34 +0000 > From: John Ament > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > To: Matej Novotny > Cc: cdi-dev > Message-ID: > namprd04.prod.outlook.com> > > Content-Type: text/plain; charset="iso-8859-1" > > Matej, > > > Ok, so now I understand better what you were trying to say in your email. > Some context may have helped, e.g. "hey guys when compiling with Java 6 the > compiler ignores the default flag on an interface and expects it to be > implemented .. therefore blah blah blah..." > > > I think I can push up a fix. Tks. > > > John > > > ________________________________ > From: Matej Novotny > Sent: Friday, January 20, 2017 5:04 AM > To: John Ament > Cc: cdi-dev > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > Bad link, sorry, here is a permanent one > https://lists.apache.org/thread.html/0cb489f620990037c9eaf16400dd06 > de7e5a979f8c78c046ab6ff3c1@%3Cdev.deltaspike.apache.org%3E > > ----- Original Message ----- > > From: "Matej Novotny" > > To: "John Ament" > > Cc: "cdi-dev" > > Sent: Friday, January 20, 2017 11:01:07 AM > > Subject: Re: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > Hi John > > > > It is a known "issue" which I even sent an email about to DS mailing > list. > > > > The cause is that DS compiles against Java 6 and CDI 2.0 adds a bunch of > > *default* methods which will then not be recognized. > > This in the end means that some DS classes (implementing interfaces from > CDI > > where such methods were addded) cannot be compiled as implementation > will be > > missing. > > > > The easiest solution is to compile with --source=1.8 and --target=1.8 > > > > Here is the link to the email conversation I originally sent - > > https://lists.apache.org/list.html?dev at deltaspike.apache.org:2016-12 > > > > Regards > > Matej > > > > ----- Original Message ----- > > > From: "John Ament" > > > To: "cdi-dev" > > > Sent: Friday, January 20, 2017 10:50:45 AM > > > Subject: [cdi-dev] DeltaSpike not compiling with CDI 2.0/Weld 3 > > > > > > > > > > > > All, > > > > > > > > > > > > > > > Just as a heads up, not sure if we knew this or not, but presently > > > DeltaSpike > > > does not compile with CDI 2 on the classpath. DS ships with a number of > > > implementations of Annotated within. Was getAnnotations intended to be > a > > > default method? > > > > > > > > > > > > > > > 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 > cdi-dev Info Page - JBoss Developer 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 > Apache License, Version 2.0 licenses/LICENSE-2.0.html> > www.apache.org > Home page of The Apache Software Foundation > > > > > > 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 > cdi-dev Info Page - JBoss Developer 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. > > > ________________________________ > 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/ > 20170120/ef94abd6/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 74, Issue 11 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170120/0e668826/attachment-0001.html From antoine at sabot-durand.net Mon Jan 23 11:27:21 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 23 Jan 2017 16:27:21 +0000 Subject: [cdi-dev] JSR 365 officially submitted In-Reply-To: References: Message-ID: Hi Team, For your information, you'll find below a copy of the official submission mail sent to the JCP a few minutes ago. Again thanks to you all for the great work. Antoine, ---------- Forwarded message ---------- From: *Antoine Sabot-Durand* Date: Mon, Jan 23, 2017 at 5:17 PM Subject: JSR 365 release submit To: spec-submit at jcp.org Hi, You'll find bellow our final submission for JSR 365 (CDI 2.0). For a possible correction after EC review our deliverables have been called PFD or CR1 but they are in their final form. Also note that for email size limitation or security reason we provide download links instead of attachment for all release elements To follow JCP release procedure find a copy of your form below filled with our elements. 1. Confirmation that the Expert Group agrees that the JSR is ready to go to Final Release. EG have been notified 2 months ago of the release. This announcement raised no disagreement. You'll find the thread in our mailing list in [1]. More recently we discussed within the EG of this current release and next step for CDI [2] 2. The Final Spec, in pdf or zip format (please note that Javadoc files must be zipped). This will be posted first for the Executive Committee's review in the Final Approval Ballot, then for the community in the Final Release when and if the ballot is approved. Find the spec document (zipped pdf) can be downloaded here [3] as well as zipped Javadoc [4] 3. The answers to the following export questions, supplied separately for each file bundle you wish posted. For instance, if you provide both a specification .pdf document and a .zip archive of javadocs, you would provide two sets of answers to these questions. Name of the file: *cdi2-spec.pdf.zip (specification document)* A. Does the specification include software codes in the following format: Binary : Yes _______ No ___X_______ Source (compilable) : Yes _______ No _____X_____ Javadocs : Yes _______ No ____X______ B. Do the codes or the spec call on, contain, use or demonstrate encryption technology? Yes _________ No ____X____ If yes, please describe in detail Name of the file: *CDI-2_0-PFD-Javadoc.zip (CDI 2.0 api javadoc)* A. Does the specification include software codes in the following format: Binary : Yes _______ No ___X_______ Source (compilable) : Yes _______ No _____X_____ Javadocs : Yes ___X____ No __________ B. Do the codes or the spec call on, contain, use or demonstrate encryption technology? Yes _________ No ____X____ If yes, please describe in detail Name of the file: *cdi-api-2.0-PFD.jar (CDI 2.0 api)* A. Does the specification include software codes in the following format: Binary : Yes ___X____ No __________ Source (compilable) : Yes _______ No __________ Javadocs : Yes _______ No __________ B. Do the codes or the spec call on, contain, use or demonstrate encryption technology? Yes _________ No ____X____ If yes, please describe in detail Name of the file: *weld-3.0.0.CR1.zip (CDI 2.0 RI)* A. Does the specification include software codes in the following format: Binary : Yes ___X____ No __________ Source (compilable) : Yes _______ No __________ Javadocs : Yes _______ No __________ B. Do the codes or the spec call on, contain, use or demonstrate encryption technology? Yes _________ No ____X____ If yes, please describe in detail Name of the file: *cdi-tck-2.0.0.CR1-dist.zip (CDI 2.0 TCK)* A. Does the specification include software codes in the following format: Binary : Yes ___X____ No __________ Source (compilable) : Yes _______ No __________ Javadocs : Yes _______ No __________ B. Do the codes or the spec call on, contain, use or demonstrate encryption technology? Yes _________ No ____X____ If yes, please describe in detail 4. The Final Reference Implementation, in .zip format. This will be posted for the Executive Committee's review in the Final Approval Ballot. Final RI in zip format is available at [5] it bundles javadoc and API which can also be downloaded separately at [4] and [6] 5. Confirmation that the Reference Implementation passes the Technology Compatibility Kit. Yes RI passes the TCK as shown in coverage doc [9] 6. The Final Technology Compatibility Kit, in .zip format. This will be posted for the Executive Committee's review in the Final Approval Ballot. TCK is available at [7] 7. The version number of your spec and the full legal name of your company or organization for the specification license. The PMO hosts the Final Approval Ballot for you, and uses Oracle's general Final Release license unless you provide your own Final license. Version number: 2.0 Company legal name: Red Hat, Inc. 8. Checklist transparency ? Is the schedule for the JSR publicly available, current, and updated regularly? Yes on our website http://cdi-spec.org ? Can the public read and/or write to a wiki for the JSR? https://github.com/cdi-spec/cdi/wiki ? Is there a publicly accessible discussion board for the JSR that you read and respond to regularly? Yes, the mailing list whose archive and rules to subscribe are accessible here: http://www.cdi-spec.org/mailinglist/ We are also reachable on IRC : irc://freenode.net/#cdi-dev ? Have you spoken at conferences and events about the JSR recently? Yes : Java One, Devoxx France and Devoxx UK ? Are you using open-source processes for the development of the RI and/or the TCK? Our RI and TCK are developed under Apache Software License 2.0 ? What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA? Mailing list is open to the community. Only EG member can contribute but everybody can bring ideas or comments. ? What is the location of your publicly-accessible Issue list? In order to enable EC members to judge whether Issues have been adequately addressed, the list must make a clear distinction between Issues that are still open, Issues that have been deferred, and those that are closed, and must indicate the reason for any change of state. https://issues.jboss.org/browse/CDI ? What is the mechanism for the public to provide feedback on your JSR? Mailing list, IRC and jira ? Where is the publicly-accessible document archive for your Expert Group? On github : https://github.com/cdi-spec/cdi ? Does the Community tab for my JSR have links to and information about all public communication mechanisms and sites for the development of my JSR? Yes ? Do you have a Twitter account or other social networking feed which people can follow for updates on your JSR? Yes : @cdispec ? Which specific areas of feedback should interested community members (such as the Adopt-a-JSR program) provide to improve the JSR (please also post this to your Community tab)? ? Test asynchronous observersl ? Try using observer ordering ? Try CDI outside java EE with our new Java SE support ? Try new meta data configurator ? Read the spec (which has been rewritten) to find any errors 9. The TCK Coverage Document. This is a one- to two-page summary to assist the EC in evaluating the TCK. Please see more details in the 'Developing TCKs' section of the Spec Lead Guide . TCK documentation is available in [7] zip file in "doc" subfolder. In addition, to Help EC evaluate TCK coverage we provide an HTML version of the spec with links to TCK tests sources at [13] 10. The full text of the final licenses for the RI and TCK (and the specification, if you are not using the standard license). RI and TCK are under Apache License, Version 2.0 available at [10] 11. The process by which qualified individuals, educational and not for profit organizations can access the TCK at no cost. TCK is available at no cost under Apache License, Version 2.0 at [7] 12. The process for making first-level appeals to the tests of the TCK. Chapter 2 of TCK doc (available in [7]) details appeals Process. Challenges should be submitted on CDI TCK Jira [11] 13. The URL where you will make the Reference Implementation available at Final Release. http://download.jboss.org/weld/3.0.0.Final 14. The URL where you will make the Technology Compatibility Kit available at Final Release. http://download.jboss.org/cdi/tck/2.0.0.Final 15. The name and contact info of the Maintenance Lead. The current spec lead Antoine Sabot-Durand (asd at redhat.org) will continue as a maintenance lead 16. The first level TCK Appeals Process, per JCP Document section 3.2.2., which handles challenges to the tests in the TCK. see 12. 17. An answer to the question: Can the Specification be implemented independently of the Reference Implementation? Yes an implementation by Apache Foundation (OpenWebbeans 2.0) is underway [12] 18. Additional information - CDI 2.0 file descriptor (beans.xml) has been updated and a new xsd file [8] must be available at the following URL *http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd * - Specification document will have a dual licensing with standard JCP click through license on jcp.org website and Apache License, Version 2.0 on official CDI website download page [14] [1] http://cdi-development-mailing-list.1064426.n5.nabble.com/Coming-roadmap-for-CDI-2-0-tt5714141.html [2] http://cdi-development-mailing-list.1064426.n5.nabble.com/CDI-2-0-is-nearly-over-let-s-start-discussion-on-CDI-2-1-tt5714384.html#a5714386 [3] http://docs.jboss.org/cdi/jcp/cdi2-spec.pdf.zip [4] http://docs.jboss.org/cdi/jcp/CDI-2_0-PFD-Javadoc.zip [5] http://download.jboss.org/weld/3.0.0.CR1/weld-3.0.0.CR1.zip [6] http://repo1.maven.org/maven2/javax/enterprise/cdi-api/2.0-PFD/cdi-api-2.0-PFD.jar [7] http://download.jboss.org/cdi/tck/2.0.0.CR1/cdi-tck-2.0.0.CR1-dist.zip [8] https://docs.jboss.org/cdi/jcp/beans_2_0.xsd [9] https://repo1.maven.org/maven2/org/jboss/cdi/tck/cdi-tck-impl/2.0.0.CR1/cdi-tck-impl-2.0.0.CR1-coverage-cdi.html [10] https://www.apache.org/licenses/LICENSE-2.0 [11] https://issues.jboss.org/projects/CDITCK [12] http://openwebbeans.apache.org/openwebbeans-20-effort.html [13] https://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec-with-assertions.html [14] http://www.cdi-spec.org/download -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170123/915a02cb/attachment-0001.html From mkouba at redhat.com Tue Jan 24 10:58:07 2017 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 24 Jan 2017 16:58:07 +0100 Subject: [cdi-dev] CDI spec github repo cleanup Message-ID: <08dbdb44-ea4e-472a-8694-d05a023e10b3@redhat.com> Hi all, I think it's time to clean up the CDI spec github repo. It contains useless branches and tags (such as "revert-300-CDI-626" or "Before_2.0-EDR1") but it does not contain e.g. "2.0-PFD" tag... Martin From builds at travis-ci.org Wed Jan 25 06:52:50 2017 From: builds at travis-ci.org (Travis CI) Date: Wed, 25 Jan 2017 11:52:50 +0000 Subject: [cdi-dev] Passed: cdi-spec/cdi#336 (2.0-PRD - d7ab98c) In-Reply-To: Message-ID: <5888919316bc5_43fb7916d23f07565b9@91469bb8-1c98-4a46-bb25-7dac63a216fc.mail> Build Update for cdi-spec/cdi ------------------------------------- Build: #336 Status: Passed Duration: 3 minutes and 16 seconds Commit: d7ab98c (2.0-PRD) Author: Antoine Sabot-Durand Message: Prepare for 2.0-PRD release View the changeset: https://github.com/cdi-spec/cdi/commit/d7ab98cbab62 View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/195148791 -- 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/20170125/1a6b6284/attachment.html From builds at travis-ci.org Wed Jan 25 06:53:09 2017 From: builds at travis-ci.org (Travis CI) Date: Wed, 25 Jan 2017 11:53:09 +0000 Subject: [cdi-dev] Passed: cdi-spec/cdi#337 (2.0-PFD - e44b54f) In-Reply-To: Message-ID: <588891a4ad944_43fbc3f5ad544707982@1c9be277-eca8-4a61-ba3d-af1a86c0b684.mail> Build Update for cdi-spec/cdi ------------------------------------- Build: #337 Status: Passed Duration: 3 minutes and 3 seconds Commit: e44b54f (2.0-PFD) Author: Antoine Sabot-Durand Message: Prepare for 2.0-PFD release View the changeset: https://github.com/cdi-spec/cdi/compare/5999782f7e12^...e44b54fb284e View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/195148951 -- 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/20170125/08eda966/attachment.html From issues at jboss.org Wed Jan 25 07:04:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 25 Jan 2017 07:04:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reopened CDI-547: -------------------------------------- > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jan 25 07:05:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 25 Jan 2017 07:05:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-547: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0-EDR2) > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jan 25 07:05:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 25 Jan 2017 07:05:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-547. ------------------------------------ Resolution: Done > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From werner.keil at gmail.com Wed Jan 25 07:07:27 2017 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 25 Jan 2017 13:07:27 +0100 Subject: [cdi-dev] CDI spec github repo cleanup Message-ID: Hi, Speaking of GitHub, what are those GH issues that remain unsolved for a very long time now? Are they for a next version or why did they sit there for a few months now? Werner -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170125/665c418c/attachment.html From mkouba at redhat.com Wed Jan 25 07:16:46 2017 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 25 Jan 2017 13:16:46 +0100 Subject: [cdi-dev] CDI spec github repo cleanup In-Reply-To: References: Message-ID: <3b202be5-ca8c-2eda-20db-39a054408cb7@redhat.com> There are no GH issues in cdi-spec/cdi repository (CDI API + document). cdi-spec/cdi-spec.org contains the sources for the website. Martin Dne 25.1.2017 v 13:07 Werner Keil napsal(a): > Hi, > > Speaking of GitHub, what are those GH issues that remain unsolved for a > very long time now? Are they for a next version or why did they sit > there for a few months now? > > Werner > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From werner.keil at gmail.com Wed Jan 25 07:20:54 2017 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 25 Jan 2017 13:20:54 +0100 Subject: [cdi-dev] CDI spec github repo cleanup In-Reply-To: <3b202be5-ca8c-2eda-20db-39a054408cb7@redhat.com> References: <3b202be5-ca8c-2eda-20db-39a054408cb7@redhat.com> Message-ID: Looks like those are mostly PRs you have to acknowledge before they go away like https://github.com/cdi-spec/cdi/pull/349#event-893299947 Werner On Wed, Jan 25, 2017 at 1:16 PM, Martin Kouba wrote: > There are no GH issues in cdi-spec/cdi repository (CDI API + document). > > cdi-spec/cdi-spec.org contains the sources for the website. > > Martin > > Dne 25.1.2017 v 13:07 Werner Keil napsal(a): > >> Hi, >> >> Speaking of GitHub, what are those GH issues that remain unsolved for a >> very long time now? Are they for a next version or why did they sit >> there for a few months now? >> >> Werner >> >> >> _______________________________________________ >> 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/license >> s/LICENSE-2.0.html). For all other ideas provided on this list, the >> provider waives all patent and other intellectual property rights inherent >> in such information. >> >> > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170125/fc9d4812/attachment.html From manovotn at redhat.com Wed Jan 25 07:40:26 2017 From: manovotn at redhat.com (Matej Novotny) Date: Wed, 25 Jan 2017 07:40:26 -0500 (EST) Subject: [cdi-dev] CDI spec github repo cleanup In-Reply-To: References: <3b202be5-ca8c-2eda-20db-39a054408cb7@redhat.com> Message-ID: <660824081.15708612.1485348026490.JavaMail.zimbra@redhat.com> I have no idea what are u talking about. I cannot see any PR which would still be "Open". The one you linked was actually merged, what's wrong about that? Matej ----- Original Message ----- > From: "Werner Keil" > To: "Martin Kouba" > Cc: "cdi-dev" > Sent: Wednesday, January 25, 2017 1:20:54 PM > Subject: Re: [cdi-dev] CDI spec github repo cleanup > > Looks like those are mostly PRs you have to acknowledge before they go away > like https://github.com/cdi-spec/cdi/pull/349#event-893299947 > > > > Werner > > > On Wed, Jan 25, 2017 at 1:16 PM, Martin Kouba < mkouba at redhat.com > wrote: > > > There are no GH issues in cdi-spec/cdi repository (CDI API + document). > > cdi-spec/ cdi-spec.org contains the sources for the website. > > Martin > > Dne 25.1.2017 v 13:07 Werner Keil napsal(a): > > > > Hi, > > Speaking of GitHub, what are those GH issues that remain unsolved for a > very long time now? Are they for a next version or why did they sit > there for a few months now? > > Werner > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > > > _______________________________________________ > 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 werner.keil at gmail.com Wed Jan 25 07:44:09 2017 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 25 Jan 2017 13:44:09 +0100 Subject: [cdi-dev] CDI spec github repo cleanup In-Reply-To: <660824081.15708612.1485348026490.JavaMail.zimbra@redhat.com> References: <3b202be5-ca8c-2eda-20db-39a054408cb7@redhat.com> <660824081.15708612.1485348026490.JavaMail.zimbra@redhat.com> Message-ID: They are not "open" they are "unread". And it seems every EG member or contributor in a particular team get them and have to confirm them (as read), regardless of being closed/merged or not. Werner On Wed, Jan 25, 2017 at 1:40 PM, Matej Novotny wrote: > I have no idea what are u talking about. > I cannot see any PR which would still be "Open". > The one you linked was actually merged, what's wrong about that? > > Matej > > ----- Original Message ----- > > From: "Werner Keil" > > To: "Martin Kouba" > > Cc: "cdi-dev" > > Sent: Wednesday, January 25, 2017 1:20:54 PM > > Subject: Re: [cdi-dev] CDI spec github repo cleanup > > > > Looks like those are mostly PRs you have to acknowledge before they go > away > > like https://github.com/cdi-spec/cdi/pull/349#event-893299947 > > > > > > > > Werner > > > > > > On Wed, Jan 25, 2017 at 1:16 PM, Martin Kouba < mkouba at redhat.com > > wrote: > > > > > > There are no GH issues in cdi-spec/cdi repository (CDI API + document). > > > > cdi-spec/ cdi-spec.org contains the sources for the website. > > > > Martin > > > > Dne 25.1.2017 v 13:07 Werner Keil napsal(a): > > > > > > > > Hi, > > > > Speaking of GitHub, what are those GH issues that remain unsolved for a > > very long time now? Are they for a next version or why did they sit > > there for a few months now? > > > > Werner > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code > > under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas > > provided on this list, the provider waives all patent and other > intellectual > > property rights inherent in such information. > > > > > > -- > > Martin Kouba > > Senior Software Engineer > > Red Hat, Czech Republic > > > > > > _______________________________________________ > > 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/20170125/8ce79055/attachment-0001.html