From issues at jboss.org Mon Jun 1 06:03:03 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 1 Jun 2015 06:03:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-26) Bootstrap API for CDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072628#comment-13072628 ] Antoine Sabot-Durand commented on CDI-26: ----------------------------------------- For the scope of EDR1 multiple container support has been removed. Ticket CDI-532, is dealing with this feature. > Bootstrap API for CDI > --------------------- > > Key: CDI-26 > URL: https://issues.jboss.org/browse/CDI-26 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0, 1.1.PFD, 1.2.Final > Reporter: Pete Muir > Assignee: John Ament > Fix For: 2.0-EDR1 > > > Weld and other CDI impls allow an embedded mode. > See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5417 for example -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 1 12:50:02 2015 From: issues at jboss.org (Harald Wellmann (JIRA)) Date: Mon, 1 Jun 2015 12:50:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-532) Support multiple container in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072826#comment-13072826 ] Harald Wellmann commented on CDI-532: ------------------------------------- Use cases: * OSGi * Java 9/Jigsaw * other modular environments. Pax CDI as well as the OSGi EEG CDI draft (currently dormant) work with (at most) one container per bundle. The implementation relies on Weld and OpenWebBeans internal APIs. Pax CDI has a best-effort but incomplete support for {{CDI.current()}}. Standard APIs for these scenarios would be extremely helpful. For Jigsaw, it should be possible to regard a CDI container as an implementation detail of a given module. If module {{A}} uses a service {{Foo}} provided by module {{B}}, then module {{B}} might require CDI for its {{FooImpl}}. This should neither imply nor exclude {{A}} from being part of the same CDI container. {{A}} may not use CDI at all, or be part of another CDI container disjoint from {{B}}'s. Each CDI container may contain beans from multiple modules. > Support multiple container in Java SE > ------------------------------------- > > Key: CDI-532 > URL: https://issues.jboss.org/browse/CDI-532 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > > We should propose a solution to support multiple container in Java SE. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 1 14:51:02 2015 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Mon, 1 Jun 2015 14:51:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072860#comment-13072860 ] Martin Andersson commented on CDI-280: -------------------------------------- bq. The proxy for a Contextual Instance should be referred to as 'Contextual Reference' Or why not just call the proxy a proxy? If the origin of the proxy is not clear, call it a CDI proxy. In either way, I find that "contextual reference" is confusing. > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, CDI_spec_chge > Fix For: 2.0 (discussion) > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 1 16:22:02 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 1 Jun 2015 16:22:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072884#comment-13072884 ] Mark Struberg commented on CDI-280: ----------------------------------- No, just calling it 'the proxy' would not be enough. Actually there are many different kind of proxies involved besides the 'Contextual Reference'. And depending on the implementation it could even be more. 1.) interceptor proxies 2.) decorator proxies 3.) subclassing proxies for abstract decorators 4.) EJB API proxies 5.) EJB NIV proxies 6.) JPA proxies 7.) customer specific proxies like custom InjectionTarget 8.) tenant proxies etc All those can be either used in parallel or some of them even stacked for the same bean! > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, CDI_spec_chge > Fix For: 2.0 (discussion) > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 1 16:47:02 2015 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Mon, 1 Jun 2015 16:47:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072885#comment-13072885 ] Martin Andersson commented on CDI-280: -------------------------------------- What is a "tenant proxy"? You mean a proxy written by the application developer himself? If so, then I'd not worry about it at all. Half of the rest is related to EJB and JPA. If CDI enforce different proxy types, then it should be clarified (but it doesn't right?). "CDI proxy" would be a valid term that encapsulate all types (but again, there are no different CDI proxy types?), or just "proxy" for short. The bottom line is that if we deal with a proxy, why not just call it that? Everything in the spec is "contextual" already. The word feels a bit bloated. Actually, I think that the word "proxy" is one of those things that is quite clear without semantic noise. Now you want to replace all references made to a proxy with "contextual reference"? I just don't get it why. > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, CDI_spec_chge > Fix For: 2.0 (discussion) > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message was sent by Atlassian JIRA (v6.3.15#6346) From antoine at sabot-durand.net Tue Jun 2 05:08:41 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 2 Jun 2015 11:08:41 +0200 Subject: [cdi-dev] Today's meeting Message-ID: <4FB29736-4671-4A08-913F-A36508AAC178@sabot-durand.net> Hi all, Today I?d like to discuss EDR1 release and its final content. And then, discuss about the next step: - finishing features started in EDR1 - prioritize our feature list for the coming months. Meeting is still at 6:00pm CET on IRC (freenode #cdi-dev channel) Regards, Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150602/5dbcf9b0/attachment-0001.bin From werner.keil at gmail.com Tue Jun 2 05:14:28 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 2 Jun 2015 11:14:28 +0200 Subject: [cdi-dev] cdi-dev Digest, Vol 55, Issue 1 In-Reply-To: References: Message-ID: Hi, I'm in a new project and country now. Actually though earlier releases as of now CDI plays an important role here, so unless IRC or the web-based variants are blocked for security reasons I might be able to join the call. Werner On Tue, Jun 2, 2015 at 11:08 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: > > > 10. Today's meeting (Antoine Sabot-Durand) > > > ---------------------------------------------------------------------- > > Message: 10 > Date: Tue, 2 Jun 2015 11:08:41 +0200 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Today's meeting > To: cdi-dev > Message-ID: <4FB29736-4671-4A08-913F-A36508AAC178 at sabot-durand.net> > Content-Type: text/plain; charset="utf-8" > > Hi all, > > Today I?d like to discuss EDR1 release and its final content. > > And then, discuss about the next step: > > - finishing features started in EDR1 > - prioritize our feature list for the coming months. > > Meeting is still at 6:00pm CET on IRC (freenode #cdi-dev channel) > > Regards, > > Antoine > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 495 bytes > Desc: Message signed with OpenPGP using GPGMail > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150602/5dbcf9b0/attachment.bin > > ------------------------------ > > _______________________________________________ > 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 55, Issue 1 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150602/49a77dfe/attachment.html From issues at jboss.org Tue Jun 2 13:05:03 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 2 Jun 2015 13:05:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-499: ------------------------------------- Fix Version/s: 2.0 (discussion) > Firing events asynchronously > ----------------------------- > > Key: CDI-499 > URL: https://issues.jboss.org/browse/CDI-499 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface. > Our proposal is: > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}} > Signature of the method on {{Event}} would be > {code:java} > CompletionStage fireAsync(U event); > {code} > Signature on {{BeanManager}} would be > {code:java} > CompletionStage fireAsyncEvent(T event, Annotation... qualifiers) > {code} > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}} > For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect. > So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously. > h2. 3. Observer bound to a transaction phase > these observer will be invoked in the right transaction phase but asynchronously > h2. 4. Event Ordering > Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync). > h2. 5. Event state (payload mutability) > We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 2 18:05:02 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Tue, 2 Jun 2015 18:05:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12 In-Reply-To: References: Message-ID: Emily Jiang created CDI-533: ------------------------------- Summary: Bean Deployment archive conflicts between section 5 and section 12 Key: CDI-533 URL: https://issues.jboss.org/browse/CDI-533 Project: CDI Specification Issues Issue Type: Clarification Components: Packaging and Deployment Affects Versions: 1.2.Final Environment: n/a Reporter: Emily Jiang In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12; In section 5, Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file. This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib. While in section 12: When determining which archives are bean archives, the container must consider: ? Library jars, EJB jars or application client jars ? The WEB-INF/classes directory of a war ? Directories in the JVM classpath It indicates each jar should be a bean archive. The smallest unit is a jar. I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked. All conversation is on the cdi-dev mailing list. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From emijiang6 at googlemail.com Tue Jun 2 18:05:25 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Tue, 2 Jun 2015 23:05:25 +0100 Subject: [cdi-dev] bean archives In-Reply-To: References: <1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com> <55471AB8.5020900@redhat.com> <55484FD3.6000100@redhat.com> <5548ABF2.3030107@redhat.com> Message-ID: I raised https://issues.jboss.org/browse/CDI-533 for spec update. On Mon, May 11, 2015 at 1:43 PM, Emily Jiang wrote: > Has anyone created a cdi spec jira for this or I should create one? > > On Tue, May 5, 2015 at 12:56 PM, Romain Manni-Bucau > wrote: > >> 2015-05-05 13:39 GMT+02:00 Jozef Hartinger : >> >>> On 05/05/2015 11:38 AM, Mark Struberg wrote: >>> > Or section 12. >>> > >>> > Both ways are perfectly backward incompatible. If you drop BDA in >>> section 5 then you break EE modularity and compatibility to EE6 servers >>> (incuding RI). If you drop BDA in section 12 then you break scanning. >>> They are not incompatible. The only problem with Chapter 5 is that the >>> way it is written gives some room for a wrong interpretation that is >>> seemingly inconsistent with Chapter 12. The only open issue here >>> therefore is how to rephrase the chapter to make it easier to read >>> correctly the first time. >>> > >>> > We really need to handle this carefully. >>> > >>> > Imo we should finally accept that there are 2 different ?BDA? use >>> cases and they both need a different Term. What about using the term BDA >>> for section 12 and only for scanning. >>> There is a behavior defined in the spec, implemented in the EE7 RI (and >>> all other compliant implementations) and tested in the TCK. We are not >>> going to redefine the behavior. What we should do is to update the spec >>> wording to be more easily understood. >>> > And the term ?EE module? for section 5 (visibility) + interceptors, >>> alternatives and decorators. That is basically how the EE6 RI behaved and >>> what is the best for users. >>> Wrong. The EE6 RI implements bean archive isolation correctly (I just >>> checked). >>> >> >> Didn't check glassfish but most of EE 6 servers didn't respect it cause >> it was just impossible to write an application using a CDI library with >> such a rule. I think it should be taken into account anyway because it is >> an important feedback to the spec. >> >> >>> > It also allows for_much_ better performance! And also please >>> acknowledge the Alternatives-per-JAR is a major PITA in_real_ projects. >>> >>> _______________________________________________ >>> 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. >> > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150602/9ca26250/attachment.html From issues at jboss.org Tue Jun 2 22:08:02 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 2 Jun 2015 22:08:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073479#comment-13073479 ] Mark Struberg commented on CDI-533: ----------------------------------- {quote} The correct implementation is section 12. {quote} No that is not correct. The _original_ (way back in early 2008) intention was EE module. Then there was some discussion about interceptor ordering ambiguity and it got narrowed to JARs. But this was only intended for interceptors, and only half done. So it is still ambiguous till today and many containers enable Alternatives for the whole EE module if they are enabled in one of the beans.xml in it. Even the EE6 RI behaved that way (and only got 'patched' by a Weld update and the RI implementers seems to not even have been aware of that functional change). The important point is that the per-jar interceptor/alternatives/decorator interpretation is pure PITA for all users. > Bean Deployment archive conflicts between section 5 and section 12 > ------------------------------------------------------------------ > > Key: CDI-533 > URL: https://issues.jboss.org/browse/CDI-533 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12; > In section 5, > Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file. > This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib. > While in section 12: > When determining which archives are bean archives, the container must consider: > ? Library jars, EJB jars or application client jars > ? The WEB-INF/classes directory of a war > ? Directories in the JVM classpath > It indicates each jar should be a bean archive. The smallest unit is a jar. > I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked. > All conversation is on the cdi-dev mailing list. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 3 01:22:02 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 3 Jun 2015 01:22:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073487#comment-13073487 ] Jozef Hartinger commented on CDI-533: ------------------------------------- I don't think there is a conflict actually: Section 5.1 says: {quote} Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file. {quote} It basically says that a bean archive is either a Java EE module or a library jar. Let's use an example {noformat} app.ear |-- web1.war | |-- WEB-INF/classes | |-- WEB-INF/lib | |-- weblib1.jar | |-- weblib2.jar |-- ejb1.jar |-- lib/ | |-- earlib1.jar {noformat} According to section 5.1 we (possibly) have the following bean archives: * web1.war and ejb1.jar which are modules * weblib1.jar, weblib2.jar and earlib1.jar are library jars On top of 5.1, section 12.1 defines what it means for a module to be a bean archive. More specifically it says: {quote} When determining which archives are bean archives, the container must consider: * Library jars, EJB jars or application client jars * The WEB-INF/classes directory of a war * Directories in the JVM classpath {quote} The *The WEB-INF/classes directory of a war* is important here. It defines what it means specifically for a web module to be a bean archive. It defines that the web1.war, as a bean archive, only contains classes located under the _WEB-INF/classes_ directory. Therefore, in our application we have the following bean archives: * web1.war (contains WEB-INF/classes only) and ejb1.jar which are modules * weblib1.jar, weblib2.jar and earlib1.jar which are library jars Therefore, there is no overlap as library jars are handled separately (by 5.1 and 12.1) and the bean archive for a web module is defined to contain classes from _WEB-INF/classes_ only. > Bean Deployment archive conflicts between section 5 and section 12 > ------------------------------------------------------------------ > > Key: CDI-533 > URL: https://issues.jboss.org/browse/CDI-533 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12; > In section 5, > Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file. > This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib. > While in section 12: > When determining which archives are bean archives, the container must consider: > ? Library jars, EJB jars or application client jars > ? The WEB-INF/classes directory of a war > ? Directories in the JVM classpath > It indicates each jar should be a bean archive. The smallest unit is a jar. > I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked. > All conversation is on the cdi-dev mailing list. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 3 02:05:02 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 3 Jun 2015 02:05:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073496#comment-13073496 ] Mark Struberg commented on CDI-533: ----------------------------------- Of course you _can_ interpret it that way. But there is the other option as well. And your interpretation is a.) not historically sound and b.) not what the users really want. Just go over to the DeltaSpike list and ask the question what behaviour they like most. In OpenWebBeans we interpreted it as Section 5 wide ever since. Any no user ever complained. As you know I do quite a lot conference talks. And I asked the question whether they like it per jar or app wide. And there was literally no single hand for the per-jar but the whole room for the application wide behaviour. And I asked this on quite a few occasions in front of a few thousand people till now! This is the no 1 most hated thing in CDI (which people otherwise really love ever since). > Bean Deployment archive conflicts between section 5 and section 12 > ------------------------------------------------------------------ > > Key: CDI-533 > URL: https://issues.jboss.org/browse/CDI-533 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12; > In section 5, > Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file. > This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib. > While in section 12: > When determining which archives are bean archives, the container must consider: > ? Library jars, EJB jars or application client jars > ? The WEB-INF/classes directory of a war > ? Directories in the JVM classpath > It indicates each jar should be a bean archive. The smallest unit is a jar. > I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked. > All conversation is on the cdi-dev mailing list. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 3 02:16:02 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 3 Jun 2015 02:16:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073499#comment-13073499 ] Jozef Hartinger commented on CDI-533: ------------------------------------- You're confusing things, Mark. We are talking about the definition of a bean archive whereas you are talking about enablement (per bean archive or per application). The question of enablement has been resolved with @Priority. > Bean Deployment archive conflicts between section 5 and section 12 > ------------------------------------------------------------------ > > Key: CDI-533 > URL: https://issues.jboss.org/browse/CDI-533 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12; > In section 5, > Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file. > This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib. > While in section 12: > When determining which archives are bean archives, the container must consider: > ? Library jars, EJB jars or application client jars > ? The WEB-INF/classes directory of a war > ? Directories in the JVM classpath > It indicates each jar should be a bean archive. The smallest unit is a jar. > I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked. > All conversation is on the cdi-dev mailing list. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 3 02:25:02 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 3 Jun 2015 02:25:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073503#comment-13073503 ] Mark Struberg commented on CDI-533: ----------------------------------- In that sense you are right. There should actually be 2 different 'BDA' terms. If you are talking about bean-scanning and class pickup then this of course should be per-jar (or classpath entry). I otoh was solely talking about the enablement of Alternatives, Interceptors and Decorators which imo is fine to behave on a per-EE-module basis. The reason why I answered this issue is that the spec links those 2 via the 'BDA' term, which is highly confusing. > Bean Deployment archive conflicts between section 5 and section 12 > ------------------------------------------------------------------ > > Key: CDI-533 > URL: https://issues.jboss.org/browse/CDI-533 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12; > In section 5, > Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file. > This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib. > While in section 12: > When determining which archives are bean archives, the container must consider: > ? Library jars, EJB jars or application client jars > ? The WEB-INF/classes directory of a war > ? Directories in the JVM classpath > It indicates each jar should be a bean archive. The smallest unit is a jar. > I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked. > All conversation is on the cdi-dev mailing list. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From antoine at sabot-durand.net Wed Jun 3 10:14:07 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 3 Jun 2015 16:14:07 +0200 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE Message-ID: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> Hi all, Yesterday during the meeting we had a discussion about implicit bean archive support under Java SE. The idea is to have it disabled by default and provide a way to activate it thru parameter "javax.enterprise.inject.scan.implicit=true?on command line or in the parameter map of the initialize method. Details of the discussion and points of people pro and against this support can be found in meeting log : http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html I?d like to call for a vote regarding the support of implicit bean archive under Java SE. This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 (no) to this mail to vote. Thanks Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150603/8a6fdafe/attachment.bin From rmannibucau at gmail.com Wed Jun 3 10:26:09 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 3 Jun 2015 16:26:09 +0200 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> Message-ID: I'd be +1 for the param thats said why not allowing to pass names/regex? j avax.enterprise.inject.scan.implicit=myapp-* a bit like EJB modules but with matching pattern(s) Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-06-03 16:14 GMT+02:00 Antoine Sabot-Durand : > Hi all, > > > Yesterday during the meeting we had a discussion about implicit bean > archive support under Java SE. > The idea is to have it disabled by default and provide a way to activate > it thru parameter "javax.enterprise.inject.scan.implicit=true?on command > line or in the parameter map of the initialize method. > Details of the discussion and points of people pro and against this > support can be found in meeting log : > > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html > > I?d like to call for a vote regarding the support of implicit bean archive > under Java SE. > > This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 > (no) to this mail to vote. > > Thanks > > 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/20150603/cb3f1d9e/attachment-0001.html From antoine at sabot-durand.net Wed Jun 3 10:34:29 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 3 Jun 2015 16:34:29 +0200 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> Message-ID: <96961516-F138-4042-BCEC-4F0AB295144D@sabot-durand.net> The vote is not choosing between command line or param map (sorry for the confusion and both could be useful) but on the general adoption of implicit param support. After EDR1 we?ll still have a more general ticket to deal with bean discovery mode in Java SE to resolve : https://issues.jboss.org/browse/CDI-529 > Le 3 juin 2015 ? 16:26, Romain Manni-Bucau a ?crit : > > I'd be +1 for the param > > thats said why not allowing to pass names/regex? javax.enterprise.inject.scan.implicit=myapp-* a bit like EJB modules but with matching pattern(s) > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > 2015-06-03 16:14 GMT+02:00 Antoine Sabot-Durand >: > Hi all, > > > Yesterday during the meeting we had a discussion about implicit bean archive support under Java SE. > The idea is to have it disabled by default and provide a way to activate it thru parameter "javax.enterprise.inject.scan.implicit=true?on command line or in the parameter map of the initialize method. > Details of the discussion and points of people pro and against this support can be found in meeting log : > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html > > I?d like to call for a vote regarding the support of implicit bean archive under Java SE. > > This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 (no) to this mail to vote. > > Thanks > > 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/20150603/98cc52c5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150603/98cc52c5/attachment.bin From antoine at sabot-durand.net Wed Jun 3 10:34:43 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 3 Jun 2015 16:34:43 +0200 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> Message-ID: <05827BED-A645-42F5-9172-E4E1446169AA@sabot-durand.net> +1 > Le 3 juin 2015 ? 16:14, Antoine Sabot-Durand a ?crit : > > Hi all, > > > Yesterday during the meeting we had a discussion about implicit bean archive support under Java SE. > The idea is to have it disabled by default and provide a way to activate it thru parameter "javax.enterprise.inject.scan.implicit=true?on command line or in the parameter map of the initialize method. > Details of the discussion and points of people pro and against this support can be found in meeting log : > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html > > I?d like to call for a vote regarding the support of implicit bean archive under Java SE. > > This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 (no) to this mail to vote. > > Thanks > > Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150603/9cdae365/attachment.bin From ggastald at redhat.com Wed Jun 3 10:46:50 2015 From: ggastald at redhat.com (George Gastaldi) Date: Wed, 03 Jun 2015 11:46:50 -0300 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> Message-ID: <556F135A.5080907@redhat.com> +1 On 06/03/2015 11:14 AM, Antoine Sabot-Durand wrote: > Hi all, > > > Yesterday during the meeting we had a discussion about implicit bean archive support under Java SE. > The idea is to have it disabled by default and provide a way to activate it thru parameter "javax.enterprise.inject.scan.implicit=true?on command line or in the parameter map of the initialize method. > Details of the discussion and points of people pro and against this support can be found in meeting log : > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html > > I?d like to call for a vote regarding the support of implicit bean archive under Java SE. > > This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 (no) to this mail to vote. > > Thanks > > 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/20150603/c0d690da/attachment.html From issues at jboss.org Wed Jun 3 10:52:02 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Wed, 3 Jun 2015 10:52:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073739#comment-13073739 ] Emily Jiang commented on CDI-533: --------------------------------- Jozef, If you interpret weblib1.jar, weblib2.jar and earlib1.jar as library jars, it makes sense. However, I don't think people who read the spec interpret that way. In your example, app.ear |-- web1.war | |-- WEB-INF/classes | |-- WEB-INF/lib | |-- weblib1.jar | |-- weblib2.jar |-- ejb1.jar |-- lib/ | |-- earlib1.jar A big portion of people will think weblib1.jar belongs to the war module, which is logical. Besides these jars lie in the war module physically. Maybe the section 5 needs to be rephrased to spell it out. > Bean Deployment archive conflicts between section 5 and section 12 > ------------------------------------------------------------------ > > Key: CDI-533 > URL: https://issues.jboss.org/browse/CDI-533 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12; > In section 5, > Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file. > This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib. > While in section 12: > When determining which archives are bean archives, the container must consider: > ? Library jars, EJB jars or application client jars > ? The WEB-INF/classes directory of a war > ? Directories in the JVM classpath > It indicates each jar should be a bean archive. The smallest unit is a jar. > I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked. > All conversation is on the cdi-dev mailing list. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 3 11:05:02 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Wed, 3 Jun 2015 11:05:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-534) Section 3.8 on CDI 1.2 spec javax.security.Principal In-Reply-To: References: Message-ID: Emily Jiang created CDI-534: ------------------------------- Summary: Section 3.8 on CDI 1.2 spec javax.security.Principal Key: CDI-534 URL: https://issues.jboss.org/browse/CDI-534 Project: CDI Specification Issues Issue Type: Bug Components: Beans Affects Versions: 1.2.Final Environment: n/a Reporter: Emily Jiang Priority: Minor In section 3.8 Additional built-in beans a bean with bean type javax.security.Principal, allowing injection of a Principal representing the current caller identity. javax.security.Principle should be java.security.Principal. The same typo exists in CDI 1.0, 1.1 and 1.2. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From john.d.ament at gmail.com Wed Jun 3 11:19:17 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 03 Jun 2015 15:19:17 +0000 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> Message-ID: Just to clarify, are you saying that by default, only JARs that contain META-INF/beans.xml will be scanned. when you set this parameter to true, all JARs are scanned? John On Wed, Jun 3, 2015 at 10:14 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > > Yesterday during the meeting we had a discussion about implicit bean > archive support under Java SE. > The idea is to have it disabled by default and provide a way to activate > it thru parameter "javax.enterprise.inject.scan.implicit=true?on command > line or in the parameter map of the initialize method. > Details of the discussion and points of people pro and against this > support can be found in meeting log : > > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html > > I?d like to call for a vote regarding the support of implicit bean archive > under Java SE. > > This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 > (no) to this mail to vote. > > Thanks > > 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/20150603/160015ea/attachment-0001.html From antoine at sabot-durand.net Wed Jun 3 12:29:16 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 03 Jun 2015 16:29:16 +0000 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> Message-ID: Yes. that's the reason why this problem was raised by Jozef: having to scan all jars can be very resource consuming. Le mer. 3 juin 2015 ? 17:19, John D. Ament a ?crit : > Just to clarify, are you saying that by default, only JARs that contain > META-INF/beans.xml will be scanned. > when you set this parameter to true, all JARs are scanned? > > John > > On Wed, Jun 3, 2015 at 10:14 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi all, >> >> >> Yesterday during the meeting we had a discussion about implicit bean >> archive support under Java SE. >> The idea is to have it disabled by default and provide a way to activate >> it thru parameter "javax.enterprise.inject.scan.implicit=true?on command >> line or in the parameter map of the initialize method. >> Details of the discussion and points of people pro and against this >> support can be found in meeting log : >> >> >> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html >> >> I?d like to call for a vote regarding the support of implicit bean >> archive under Java SE. >> >> This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 >> (no) to this mail to vote. >> >> Thanks >> >> 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/20150603/cf07f08b/attachment.html From john.d.ament at gmail.com Wed Jun 3 12:30:49 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 03 Jun 2015 16:30:49 +0000 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> Message-ID: Ok then -1 from me. The reason I say -1 is because using a boolean is too restrictive. On Wed, Jun 3, 2015 at 12:29 PM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Yes. that's the reason why this problem was raised by Jozef: having to > scan all jars can be very resource consuming. > > Le mer. 3 juin 2015 ? 17:19, John D. Ament a > ?crit : > >> Just to clarify, are you saying that by default, only JARs that contain >> META-INF/beans.xml will be scanned. >> when you set this parameter to true, all JARs are scanned? >> >> John >> >> On Wed, Jun 3, 2015 at 10:14 AM Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> Hi all, >>> >>> >>> Yesterday during the meeting we had a discussion about implicit bean >>> archive support under Java SE. >>> The idea is to have it disabled by default and provide a way to activate >>> it thru parameter "javax.enterprise.inject.scan.implicit=true?on command >>> line or in the parameter map of the initialize method. >>> Details of the discussion and points of people pro and against this >>> support can be found in meeting log : >>> >>> >>> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html >>> >>> I?d like to call for a vote regarding the support of implicit bean >>> archive under Java SE. >>> >>> This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 >>> (no) to this mail to vote. >>> >>> Thanks >>> >>> 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/20150603/11c65a8c/attachment.html From antoine at sabot-durand.net Thu Jun 4 04:08:43 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 4 Jun 2015 10:08:43 +0200 Subject: [cdi-dev] Async event proposal Message-ID: <6DF8E1FB-4122-49A5-B9E0-D8039E2D406C@sabot-durand.net> Hi all, You may have missed the proposal I sent in this PR https://github.com/cdi-spec/cdi/pull/250 . It gathers most facts we agreed on regarding async events but I had to make some choices that could be discussed t have a consistent a real proposal: 1) Introducing @ObservesAsync I won?t go back on the discussion around backward compatibility for Asyc Event. If you want read a sum up on it please go there: http://cdi-development-mailing-list.1064426.n5.nabble.com/Previously-on-Double-end-async-events-activation-tp5711284.html We had 4 solutions to activate async on the observer side. I removed the ones bringing modification to @Observes annotation, removed the @Async solution since I didn?t want to to introduce such a generic annotation in CDI and the place to put it elsewhere in Java EE is not obvious. That would let us @AsyncSupported and @ObservesAsync solutions. I kept @ObservesAsync because it?s simpler for user to have only one annotation to activate this feature and because @AsyncSupport didn?t seems to have other application than activating async on observer. I think form an user pov it?s the less worst solution to support this double activation requirement 2) Restricting fireAsync to ObservesAsync Following the logic in 1 my draft restrict fireAsync call to only notify ObservesAsync observers. As we introduce a new feature and don?t want to break previously existing one I found this approach less confusing for our users. If we?re not happy with this restriction we could add parameter to fireAsync to target synchronous observer as well, but I really think we should consider this default behavior? 3) Change fireAsync signature In our initial proposal fireAsync basic signature was CompletionStage fireAsync(U event); I simplified the signature with CompletionStage fireAsync (U event); As the original fire method returns void I found confusing to return anything something letting think that a value (different than a status) was obtained from the observers notification. As Jozef pointed there are aspect lacking to the proposal. I plan to add a solution to solve multiple exception and need proposal for Invocation context definition and mention for thread safety. So help and feedback are welcome. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150604/e10b0351/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150604/e10b0351/attachment.bin From struberg at yahoo.de Thu Jun 4 04:31:58 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 4 Jun 2015 10:31:58 +0200 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> Message-ID: <852BF002-7E6A-4D77-99A8-136AC97DBB98@yahoo.de> +1 for making it configurable whether or not implicit bean archives should get picked up automatically +1 for only scanning explicit bean archives in SE mode +0.5 for having a regexp exclude mechanism for defining classapth entries which should *not* get scanned. Containers WILL have this. But it might be too much depending on the environment you are working in. E.g. for an OSGi environment it might not work out that way and a different mechanism is needed. LieGrue, strub > Am 03.06.2015 um 18:30 schrieb John D. Ament : > > Ok then -1 from me. > The reason I say -1 is because using a boolean is too restrictive. > > On Wed, Jun 3, 2015 at 12:29 PM Antoine Sabot-Durand wrote: > Yes. that's the reason why this problem was raised by Jozef: having to scan all jars can be very resource consuming. > > Le mer. 3 juin 2015 ? 17:19, John D. Ament a ?crit : > Just to clarify, are you saying that by default, only JARs that contain META-INF/beans.xml will be scanned. > when you set this parameter to true, all JARs are scanned? > > John > > On Wed, Jun 3, 2015 at 10:14 AM Antoine Sabot-Durand wrote: > Hi all, > > > Yesterday during the meeting we had a discussion about implicit bean archive support under Java SE. > The idea is to have it disabled by default and provide a way to activate it thru parameter "javax.enterprise.inject.scan.implicit=true?on command line or in the parameter map of the initialize method. > Details of the discussion and points of people pro and against this support can be found in meeting log : > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html > > I?d like to call for a vote regarding the support of implicit bean archive under Java SE. > > This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 (no) to this mail to vote. > > Thanks > > Antoine > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From thjanssen123 at gmail.com Thu Jun 4 06:44:49 2015 From: thjanssen123 at gmail.com (Thorben Janssen) Date: Thu, 4 Jun 2015 12:44:49 +0200 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: <852BF002-7E6A-4D77-99A8-136AC97DBB98@yahoo.de> References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> <852BF002-7E6A-4D77-99A8-136AC97DBB98@yahoo.de> Message-ID: +1 -- *Thorben Janssen* @thjanssen123 www.thoughts-on-java.org 2015-06-04 10:31 GMT+02:00 Mark Struberg : > +1 for making it configurable whether or not implicit bean archives should > get picked up automatically > +1 for only scanning explicit bean archives in SE mode > > +0.5 for having a regexp exclude mechanism for defining classapth entries > which should *not* get scanned. > Containers WILL have this. But it might be too much depending on the > environment you are working in. E.g. for an OSGi environment it might not > work out that way and a different mechanism is needed. > > LieGrue, > strub > > > Am 03.06.2015 um 18:30 schrieb John D. Ament : > > > > Ok then -1 from me. > > The reason I say -1 is because using a boolean is too restrictive. > > > > On Wed, Jun 3, 2015 at 12:29 PM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > Yes. that's the reason why this problem was raised by Jozef: having to > scan all jars can be very resource consuming. > > > > Le mer. 3 juin 2015 ? 17:19, John D. Ament a > ?crit : > > Just to clarify, are you saying that by default, only JARs that contain > META-INF/beans.xml will be scanned. > > when you set this parameter to true, all JARs are scanned? > > > > John > > > > On Wed, Jun 3, 2015 at 10:14 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > Hi all, > > > > > > Yesterday during the meeting we had a discussion about implicit bean > archive support under Java SE. > > The idea is to have it disabled by default and provide a way to activate > it thru parameter "javax.enterprise.inject.scan.implicit=true?on command > line or in the parameter map of the initialize method. > > Details of the discussion and points of people pro and against this > support can be found in meeting log : > > > > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html > > > > I?d like to call for a vote regarding the support of implicit bean > archive under Java SE. > > > > This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 > (no) to this mail to vote. > > > > Thanks > > > > 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. > > > _______________________________________________ > 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/20150604/62694f49/attachment.html From jharting at redhat.com Fri Jun 5 02:49:19 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 05 Jun 2015 08:49:19 +0200 Subject: [cdi-dev] Async event proposal In-Reply-To: <6DF8E1FB-4122-49A5-B9E0-D8039E2D406C@sabot-durand.net> References: <6DF8E1FB-4122-49A5-B9E0-D8039E2D406C@sabot-durand.net> Message-ID: <5571466F.6020305@redhat.com> On 06/04/2015 10:08 AM, Antoine Sabot-Durand wrote: > In our initial proposal fireAsync basic signature was > > CompletionStage fireAsync(U event); > > I simplified the signature with > > CompletionStage fireAsync (U event); > > As the original fire method returns void I found confusing to return > anything something letting think that a value (different than a > status) was obtained from the observers notification. The reason for the original signature was that it allows the event payload to be processed further once all the observers finish. This is useful in the common pattern where you fire a mutable event, let the (possibly unknown) observers contribute to the result by mutating the payload, and then work with the payload when all finish. See e.g. https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/experimental/event/async/complex/ComplexAsyncEventTest.java#L74 This of course assumes mutable event payloads are supported. From j.j.snyder at oracle.com Fri Jun 5 11:50:39 2015 From: j.j.snyder at oracle.com (JJ Snyder) Date: Fri, 05 Jun 2015 11:50:39 -0400 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> Message-ID: <5571C54F.60301@oracle.com> +1 On 06/03/2015 10:14 AM, Antoine Sabot-Durand wrote: > Hi all, > > > Yesterday during the meeting we had a discussion about implicit bean archive support under Java SE. > The idea is to have it disabled by default and provide a way to activate it thru parameter "javax.enterprise.inject.scan.implicit=true?on command line or in the parameter map of the initialize method. > Details of the discussion and points of people pro and against this support can be found in meeting log : > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html > > I?d like to call for a vote regarding the support of implicit bean archive under Java SE. > > This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 (no) to this mail to vote. > > Thanks > > 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/20150605/b53fa83a/attachment.html From antoine at sabot-durand.net Fri Jun 5 13:43:41 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 05 Jun 2015 17:43:41 +0000 Subject: [cdi-dev] Async event proposal In-Reply-To: <5571466F.6020305@redhat.com> References: <6DF8E1FB-4122-49A5-B9E0-D8039E2D406C@sabot-durand.net> <5571466F.6020305@redhat.com> Message-ID: Yes Jozef, As said multiple times we cannot prevent users to mute payload in async events but they should know that it's their responsibility to do so (no concurrency or thread safety guaranteed by us). I have no problem to revert this. My idea was to be consistent with synchronous observer returning void. I also feared that returning an handle on the payload could confuse users, making them think that we manage concurrency and thread safety on the payload when we don't do it. Now, adding the payload to the async pipeline coule make sense... Antoine Le ven. 5 juin 2015 ? 08:49, Jozef Hartinger a ?crit : > On 06/04/2015 10:08 AM, Antoine Sabot-Durand wrote: > > In our initial proposal fireAsync basic signature was > > > > CompletionStage fireAsync(U event); > > > > I simplified the signature with > > > > CompletionStage fireAsync (U event); > > > > As the original fire method returns void I found confusing to return > > anything something letting think that a value (different than a > > status) was obtained from the observers notification. > > The reason for the original signature was that it allows the event > payload to be processed further once all the observers finish. This is > useful in the common pattern where you fire a mutable event, let the > (possibly unknown) observers contribute to the result by mutating the > payload, and then work with the payload when all finish. See e.g. > > https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/experimental/event/async/complex/ComplexAsyncEventTest.java#L74 > > This of course assumes mutable event payloads are supported. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150605/aeba6b78/attachment.html From thjanssen123 at gmail.com Sat Jun 6 07:39:43 2015 From: thjanssen123 at gmail.com (Thorben Janssen) Date: Sat, 6 Jun 2015 13:39:43 +0200 Subject: [cdi-dev] Async event proposal In-Reply-To: References: <6DF8E1FB-4122-49A5-B9E0-D8039E2D406C@sabot-durand.net> <5571466F.6020305@redhat.com> Message-ID: I like the idea of returning the event payload but it would be inconsistent with the existing fire(U event) method. Am I right, that changing the old fire method in the same way is not an option? Regards, Thorben -- *Thorben Janssen* @thjanssen123 www.thoughts-on-java.org 2015-06-05 19:43 GMT+02:00 Antoine Sabot-Durand : > Yes Jozef, > > As said multiple times we cannot prevent users to mute payload in async > events but they should know that it's their responsibility to do so (no > concurrency or thread safety guaranteed by us). > I have no problem to revert this. My idea was to be consistent with > synchronous observer returning void. > I also feared that returning an handle on the payload could confuse users, > making them think that we manage concurrency and thread safety on the > payload when we don't do it. > Now, adding the payload to the async pipeline coule make sense... > > Antoine > > > Le ven. 5 juin 2015 ? 08:49, Jozef Hartinger a > ?crit : > >> On 06/04/2015 10:08 AM, Antoine Sabot-Durand wrote: >> > In our initial proposal fireAsync basic signature was >> > >> > CompletionStage fireAsync(U event); >> > >> > I simplified the signature with >> > >> > CompletionStage fireAsync (U event); >> > >> > As the original fire method returns void I found confusing to return >> > anything something letting think that a value (different than a >> > status) was obtained from the observers notification. >> >> The reason for the original signature was that it allows the event >> payload to be processed further once all the observers finish. This is >> useful in the common pattern where you fire a mutable event, let the >> (possibly unknown) observers contribute to the result by mutating the >> payload, and then work with the payload when all finish. See e.g. >> >> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/experimental/event/async/complex/ComplexAsyncEventTest.java#L74 >> >> This of course assumes mutable event payloads are supported. >> > > _______________________________________________ > 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/20150606/90bff290/attachment-0001.html From issues at jboss.org Sat Jun 6 10:54:02 2015 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Sat, 6 Jun 2015 10:54:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-526) Include filters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13074999#comment-13074999 ] Antonio Goncalves commented on CDI-526: --------------------------------------- +1 And you could mix both includes and excludes for the same application (including some packages and excluding others) {code} {code} > Include filters > --------------- > > Key: CDI-526 > URL: https://issues.jboss.org/browse/CDI-526 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > > CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g: > {code:XML} > > {code} > With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.: > {code:XML} > > {code} > Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Sat Jun 6 11:02:02 2015 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Sat, 6 Jun 2015 11:02:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-529) Define bean discovery rules when CDI in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13075000#comment-13075000 ] Antonio Goncalves commented on CDI-529: --------------------------------------- And what about improving filters as Jozef proposed in [CDI-526] > Define bean discovery rules when CDI in Java SE > ----------------------------------------------- > > Key: CDI-529 > URL: https://issues.jboss.org/browse/CDI-529 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > > We should specify how bean discovery works under Java SE. Since the default {{annotated}} bean discovery mode in Java EE could lead to performance issue we need to provide a different behavior for SE. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Sat Jun 6 11:20:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 6 Jun 2015 11:20:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-529) Define bean discovery rules when CDI in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13075003#comment-13075003 ] Antoine Sabot-Durand commented on CDI-529: ------------------------------------------ [~agoncal] this ticket doesn't exclude CDI-529, it's a reminder to seriously deal with general discovery mode in SE. CDI-526 is more general and could be applied at core level (so for SE and EE). > Define bean discovery rules when CDI in Java SE > ----------------------------------------------- > > Key: CDI-529 > URL: https://issues.jboss.org/browse/CDI-529 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > > We should specify how bean discovery works under Java SE. Since the default {{annotated}} bean discovery mode in Java EE could lead to performance issue we need to provide a different behavior for SE. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From antonio.goncalves at gmail.com Sat Jun 6 11:25:29 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Sat, 6 Jun 2015 17:25:29 +0200 Subject: [cdi-dev] [VOTE] support of implicit bean archive under Java SE In-Reply-To: <5571C54F.60301@oracle.com> References: <6CBDA78A-B6DB-4C81-AD7F-214877F7E10E@sabot-durand.net> <5571C54F.60301@oracle.com> Message-ID: That reminds me the web-fragments that get "implicitly" aggregated except if you explicitly set the metadata-complete tag in the web.xml. I don't know other cases in Java EE, but it sounds that implicit scanning is activated by default in EE. I can understand the performance impact, but looks like implicit scanning is more natural in the EE world. That being said, we are targeting the SE world. +1 for me On Fri, Jun 5, 2015 at 5:50 PM, JJ Snyder wrote: > +1 > > On 06/03/2015 10:14 AM, Antoine Sabot-Durand wrote: > > Hi all, > > > Yesterday during the meeting we had a discussion about implicit bean archive support under Java SE. > The idea is to have it disabled by default and provide a way to activate it thru parameter "javax.enterprise.inject.scan.implicit=true?on command line or in the parameter map of the initialize method. > Details of the discussion and points of people pro and against this support can be found in meeting log : > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-06-02-16.01.log.html > > I?d like to call for a vote regarding the support of implicit bean archive under Java SE. > > This vote will be open for 72 hrs. Answer +1 (yes), 0 (don?t care), -1 (no) to this mail to vote. > > Thanks > > Antoine > > > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150606/c196fe54/attachment.html From antoine at sabot-durand.net Mon Jun 8 09:39:37 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 8 Jun 2015 15:39:37 +0200 Subject: [cdi-dev] Tomorrow's meeting agenda Message-ID: Hi all, In tomorrow?s meeting I?d like to close EDR1 to release it ASAP. Main content I target to release is : - API split - Java SE bootstrap - Event ordering - Asynchronous events We?ll deal this content (I?m actually working to integrate the 3 last in the first). I?ll have question to validate with you like : - ApplicationContext in Java SE - Signature of fireAsync - Choice of separating Async event from sync event If you have other points please send me them to have a complete list by tomorrow meeting. And please remember that the target of an Early Draft is not to release a final part of the spec, it is to propose feature to have feedback. Features in the EDR may be removed or radically changed from the final spec. Even during the EDR review content may change as specified in the JCP : https://jcp.org/en/procedures/jcp2#3 Thanks for your input. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150608/2b4b4e3d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150608/2b4b4e3d/attachment.bin From issues at jboss.org Tue Jun 9 06:34:01 2015 From: issues at jboss.org (Ochieng Marembo (JIRA)) Date: Tue, 9 Jun 2015 06:34:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: Ochieng Marembo created CDI-535: ----------------------------------- Summary: cdi instance injection ordering Key: CDI-535 URL: https://issues.jboss.org/browse/CDI-535 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 2.0 (discussion) Reporter: Ochieng Marembo Priority: Optional We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. h3. Use case: Developer always define a kind of chain of processor beans, which may need to run in specific order. h3. Current scenario: Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: #1 {code} private Iterable myBeans; @Inject void injectBeans(@Any Instance myBeans) { //the create order does some kind of ordering on the beans. this.myBeans = createOrder(myBeans); } {code} #2 This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. {code} @Any @Inject private Instance myBeans; public void doSomething() { Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); } {code} h3. Our Proposal We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} {code} public interface MyBeanInterface {} @MyQualifier @Priority(0) public class MyFirstBean implements MyBeanInterface{ } @MyQualifier @Priority(2) public class MySecondBean implements MyBeanInterface{ } @ApplicationScoped public class MyBeanProcessor { //We expect that this injected instances shall be in order based on the @Priority annotation @Any @Inject private Instance myBeans; } {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From antoine at sabot-durand.net Tue Jun 9 09:55:28 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 9 Jun 2015 15:55:28 +0200 Subject: [cdi-dev] Face to Face meeting in Paris, please choose your date Message-ID: Hi all, After discussion with Red Hat team. We chose Paris for the CDI Face to Face meeting. It was the second choice in our place survey, but this choice suits more our budget allow Red Hat to have a budget for EG members meal. This meeting will last 2 days (friday-saturday) in September or early October To choose the dat, I updated the Doodle here : http://doodle.com/ecvpshxceup8b278 My modifications reset your former participation to this Doodle (if you did one) so people that already entered choices will have to it again (sorry). I?m so happly to meet you there! Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150609/ad1e0fad/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150609/ad1e0fad/attachment-0001.bin From asd at redhat.com Tue Jun 9 09:21:20 2015 From: asd at redhat.com (Antoine Sabot-Durand) Date: Tue, 9 Jun 2015 15:21:20 +0200 Subject: [cdi-dev] Face to Face meeting in Paris, please choose your date Message-ID: <6F92A27D-9E65-4A62-AB42-0FECAFD6376D@redhat.com> Hi all, After discussion with Red Hat team. We chose Paris for the CDI Face to Face meeting. It was the second choice in our place survey, but this choice suits more our budget allow Red Hat to have a budget for EG members meal. This meeting will last 2 days (friday-saturday) in September or early October To choose the dat, I updated the Doodle here : http://doodle.com/ecvpshxceup8b278 My modifications reset your former participation to this Doodle (if you did one) so people that already entered choices will have to it again (sorry). Hope to see you there, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150609/e3075ff0/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150609/e3075ff0/attachment.bin From antoine at sabot-durand.net Wed Jun 10 11:25:06 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: 10 Jun 2015 15:25:06 +0000 Subject: [cdi-dev] Cancelled: CDI weekly meeting Message-ID: <201506101525.t5AFP6gV009762@lists01.dmz-a.mwc.hst.phx2.redhat.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150610/9f956650/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 6702 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150610/9f956650/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 6702 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150610/9f956650/attachment-0003.bin From antoine at sabot-durand.net Wed Jun 10 11:31:33 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: 10 Jun 2015 15:31:33 +0000 Subject: [cdi-dev] Cancelled: CDI weekly meeting Message-ID: <201506101531.t5AFVY5p010031@lists01.dmz-a.mwc.hst.phx2.redhat.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150610/9e013f0f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 6578 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150610/9e013f0f/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 6578 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150610/9e013f0f/attachment-0001.bin From mkouba at redhat.com Thu Jun 11 08:38:06 2015 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 11 Jun 2015 14:38:06 +0200 Subject: [cdi-dev] Deploy failing due to WELD-000071: Managed bean class org.apache.cxf.jaxrs.provider.DataBindingJSONProvider must be @Dependent In-Reply-To: <1432145817057-5711473.post@n5.nabble.com> References: <1432145817057-5711473.post@n5.nabble.com> Message-ID: <5579812E.2010509@redhat.com> You can't exclude a jar file in CDI. In your case, org.apache.cxf.jaxrs.provider.DataBindingJSONProvider is probably registered automatically by the JAX-RS integration as an @ApplicationScoped bean (see also JAX-RS spec, 10.2.3 Context and Dependency Injection). However, in CDI a managed bean with a parameterized bean class may NOT declare other scope than @Dependent. Note that WildFly has a JAX-RS impl integrated so maybe you don't need to bundle this class at all. Anyway, you should definitely ask on WildFly ML/forums and not on cdi-dev. HTH, Martin Dne 20.5.2015 v 20:16 Dev napsal(a): > It seems it is failing as i am using an external jar file in which > javax.Inject is used. > When my war is deployed with this jar file it fails. > > I tried to exclude the packages in jar file by declaring them in > WEB-INF/beans.xml i.e. > > > xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" > http://xmlns.jcp.org/xml/ns/javaee > http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"> > > > > > > > > CDI version is 1.2 > Server is WILDFLY 8.2.0 > > > Error that i am getting : > ############### > > Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000071: > Managed bean class org.apache.cxf.jaxrs.provider.DataBindingJSONProvider > must be @Dependent > at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:198) > at > org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:105) > at > org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:113) > at > org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136) > at > org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127) > at > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60) > at > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [rt.jar:1.8.0_25] > ... 3 more > > 23:23:19,370 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: > ([("deployment" => "CaseManagementSystem.war")]) - failure description: > {"JBAS014671: Failed services" => > {"jboss.deployment.unit.\"CaseManagementSystem.war\".WeldStartService" => > "org.jboss.msc.service.StartException in service > jboss.deployment.unit.\"CaseManagementSystem.war\".WeldStartService: Failed > to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000071: > Managed bean class org.apache.cxf.jaxrs.provider.DataBindingJSONProvider > must be @Dependent"}} > 23:23:19,437 INFO [org.jboss.as.server] (ServerService Thread Pool -- 31) > JBAS018559: Deployed "CaseManagementSystem.war" (runtime-name : > "CaseManagementSystem.war") > 23:23:19,466 INFO [org.jboss.as.controller] (Controller Boot Thread) > JBAS014774: Service status report > JBAS014777: Services which failed to start: service > jboss.deployment.unit."CaseManagementSystem.war".WeldStartService: > org.jboss.msc.service.StartException in service > jboss.deployment.unit."CaseManagementSystem.war".WeldStartService: Failed to > start service > > 23:23:19,822 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service > thread 1-3) JBAS010418: Stopped Driver service with driver-name = > CaseManagementSystem.war_com.mysql.jdbc.Driver_5_1 > 23:23:19,832 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 6) > JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service > 'CaseManagementSystem.war#hsn18cms' > 23:23:19,842 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 17) > JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service > 'CaseManagementSystem.war#hsn18cmsaspect' > 23:23:19,842 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service > thread 1-4) JBAS010418: Stopped Driver service with driver-name = > CaseManagementSystem.war_org.h2.Driver_1_4 > 23:23:19,852 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) > JBAS016009: Stopping weld service for deployment CaseManagementSystem.war > 23:23:19,972 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 17) > JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service > 'CaseManagementSystem.war#hsn18cmsaspect' > 23:23:19,972 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 6) > JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service > 'CaseManagementSystem.war#hsn18cms' > 23:23:21,872 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) > JBAS015877: Stopped deployment CaseManagementSystem.war (runtime-name: > CaseManagementSystem.war) in 2076ms > 23:23:21,872 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http > management interface listening on http://127.0.0.1:9990/management > 23:23:21,872 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin > console listening on http://127.0.0.1:9990 > 23:23:21,872 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: > WildFly 8.2.0.Final "Tweek" started in 134751ms - Started 241 of 290 > services (95 services are lazy, passive or on-demand) > 23:23:22,152 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) > JBAS018558: Undeployed "CaseManagementSystem.war" (runtime-name: > "CaseManagementSystem.war") > 23:23:22,162 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) > JBAS014774: Service status report > > ###################### > > Kindly help and let me know how i can exclude the jar files in CDI. > > Thanks, > Dev > > > > > -- > View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Deploy-failing-due-to-WELD-000071-Managed-bean-class-org-apache-cxf-jaxrs-provider-DataBindingJSONPrt-tp5711473.html > Sent from the CDI Development mailing list mailing list archive at Nabble.com. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > From issues at jboss.org Fri Jun 12 07:51:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Jun 2015 07:51:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-501: ------------------------------------- Fix Version/s: 2.0-EDR1 (was: 2.0 (discussion)) > Firing and consuming events should take place in the same thread > ---------------------------------------------------------------- > > Key: CDI-501 > URL: https://issues.jboss.org/browse/CDI-501 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jos? Paumard > Fix For: 2.0-EDR1 > > > An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload. > All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state. > The issue is the following : > - the payload object is not specified, it can then be mutable, non-synchronized etc... > - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread. > So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise. > Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From antoine at sabot-durand.net Mon Jun 15 03:26:54 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 15 Jun 2015 09:26:54 +0200 Subject: [cdi-dev] Last line before EDR review of PR 250 Message-ID: <51CFFA15-70EC-4406-AA98-E265276F8D7C@sabot-durand.net> Hi all, Last week and this week-end I rework on CDI-499 and PR 250. https://github.com/cdi-spec/cdi/pull/250 Correct /addition are: - reverted fireAsync signature to add the type of the event in it - fireAsync triggers observers and async observers - @ObservesAsync doesn?t support transnational phase - Security context is propagated for async observer. Transaction context is not and CDI context are not except for application context which is shared. - Mention that container doesn?t guarantee thread safeties for payload in async observer - Exception in async observer must be caught by the container and added as suppressed exception (thanks Jos? for this solution) : http://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#addSuppressed-java.lang.Throwable- Please try to give me your feedback ASAP as I?d like to release EDR in the coming days. Remember, feature in EDR cane changed or removed during or after review, so if a point should launch a discussion we could bring change later. IF you din a big flaw in my proposal thanks to raise hand and try to propose a solution. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150615/dae025bf/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150615/dae025bf/attachment.bin From struberg at yahoo.de Mon Jun 15 04:08:33 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 15 Jun 2015 10:08:33 +0200 Subject: [cdi-dev] outdated OWB link on cdi-spec.org Message-ID: Hi folks! CDI-1.1 and CDI-1.2 support has been added to OpenWebBeans for quite some time. But still it doesn?t show up on http://www.cdi-spec.org/download/ Could you please add http://openwebbeans.apache.org/download.html to the roaster? txs and LieGrue, strub From antoine at sabot-durand.net Mon Jun 15 07:39:21 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 15 Jun 2015 11:39:21 +0000 Subject: [cdi-dev] outdated OWB link on cdi-spec.org In-Reply-To: References: Message-ID: Done, but you know that Pull request are possible for the site. The repo is: https://github.com/cdi-spec/cdi-spec.org Antoine Le lun. 15 juin 2015 ? 10:08, Mark Struberg a ?crit : > Hi folks! > > CDI-1.1 and CDI-1.2 support has been added to OpenWebBeans for quite some > time. But still it doesn?t show up on > > http://www.cdi-spec.org/download/ > > Could you please add > http://openwebbeans.apache.org/download.html > to the roaster? > > txs and LieGrue, > strub > _______________________________________________ > 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/20150615/41df1ee1/attachment.html From antoine at sabot-durand.net Mon Jun 15 10:25:32 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 15 Jun 2015 16:25:32 +0200 Subject: [cdi-dev] Added chapter for context in Java SE. Message-ID: Hi all, I added a Scopes and contexts in Java SE chapter to specify that only Application Context is active under Java SE. This part will probably refine later thru CDI-530 Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150615/16e1f827/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150615/16e1f827/attachment.bin From antoine at sabot-durand.net Tue Jun 16 04:05:13 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 16 Jun 2015 10:05:13 +0200 Subject: [cdi-dev] Today's meeting cancelled Message-ID: Hi all, Im? not sure to make it for our meeting today. I?m going to JCP EC and Devoxx UK in London, and just learn that I?ll probably have a meeting at the time of our meeting. The goal is still to release EDR this week. I thanks you for your feedback pointing incosistencies in my proposal for async events (some of them were due to 2 losts commits ;) ). I?ll answer to your review today or tomorrow, so keep doing them. regards, Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150616/debeb76c/attachment.bin From issues at jboss.org Tue Jun 16 07:39:02 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 16 Jun 2015 07:39:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-536) Redundant statement in "2.6.2. Default bean names" chapter In-Reply-To: References: Message-ID: Tomas Remes created CDI-536: ------------------------------- Summary: Redundant statement in "2.6.2. Default bean names" chapter Key: CDI-536 URL: https://issues.jboss.org/browse/CDI-536 Project: CDI Specification Issues Issue Type: Bug Reporter: Tomas Remes Priority: Minor This chapter currently says: {quote} In the following circumstances, a default name must be assigned by the container: - A bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified by the value member. {quote} and then: {quote} If a bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified the value of the value member is defaulted. {quote} These 2 statements declare the same IMO. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 07:39:02 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 16 Jun 2015 07:39:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-536) Redundant statement in "2.6.2. Default bean names" chapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated CDI-536: ---------------------------- Affects Version/s: 1.2.Final > Redundant statement in "2.6.2. Default bean names" chapter > ---------------------------------------------------------- > > Key: CDI-536 > URL: https://issues.jboss.org/browse/CDI-536 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Priority: Minor > > This chapter currently says: > {quote} > In the following circumstances, a default name must be assigned by the container: > - A bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified by the value member. > {quote} > and then: > {quote} > If a bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified the value of the value member is defaulted. > {quote} > These 2 statements declare the same IMO. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From antoine at sabot-durand.net Tue Jun 16 09:53:14 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 16 Jun 2015 14:53:14 +0100 Subject: [cdi-dev] Slides I presented on the JCP EC Message-ID: <58096086-060E-4580-9AF9-1A48C6E63217@sabot-durand.net> Hi guys, FYI, here are the slides I presented today in the JCP EC F2F meeting in = London: https://dl.dropboxusercontent.com/u/2898173/JSR-365-Review.pdf Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150616/098f76a1/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150616/098f76a1/attachment.bin From antoine at sabot-durand.net Tue Jun 16 09:44:59 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 16 Jun 2015 14:44:59 +0100 Subject: [cdi-dev] Slides I presented on the JCP EC Message-ID: <9E75686E-202C-4004-8B25-176C47AD69A6@sabot-durand.net> Hi guys, FYI, here are the slides I presented today in the JCP EC F2F meeting in London: -------------- next part -------------- A non-text attachment was scrubbed... Name: JSR-365-Review.pdf Type: application/pdf Size: 996647 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150616/8ea0a582/attachment-0001.pdf -------------- next part -------------- Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150616/8ea0a582/attachment-0001.bin From otaviojava at java.net Tue Jun 16 15:37:21 2015 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Tue, 16 Jun 2015 20:37:21 +0100 Subject: [cdi-dev] Slides I presented on the JCP EC In-Reply-To: <9E75686E-202C-4004-8B25-176C47AD69A6@sabot-durand.net> References: <9E75686E-202C-4004-8B25-176C47AD69A6@sabot-durand.net> Message-ID: It was great, congratulations. On Tue, Jun 16, 2015 at 2:44 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi guys, > > FYI, here are the slides I presented today in the JCP EC F2F meeting in > London: > > > > > 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. > -- Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150616/346cb316/attachment.html From antoine at sabot-durand.net Thu Jun 18 09:10:25 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 18 Jun 2015 14:10:25 +0100 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 Message-ID: Hi guys, We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. What is you feeling about this ? Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150618/da56d078/attachment.bin From rmannibucau at gmail.com Thu Jun 18 09:13:23 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 18 Jun 2015 15:13:23 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: Message-ID: Hi I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : > Hi guys, > > We should finally decide how to manage normal scope context (other than > application context ) in SE and during Async Event for EDR1. > > Having only RequestContext active during async event as Martin suggest in > the PR makes sense and would be consistent with its behavior during async > EJB call. > > Mark asked twice to activate Request Context all the time in SE (making it > a new Application Context). I?m not found of it, but I?ml not the only one > to decide here. > > What is you feeling about this ? > > 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/20150618/9310da0b/attachment.html From struberg at yahoo.de Thu Jun 18 15:37:38 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 18 Jun 2015 21:37:38 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: Message-ID: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> 1.) The whole point is that @RequestScoped is NOT a web context! Otherwise it would _not_ be active in JMS etc? And that was not an accident but intentional. 2.) And no, different async threads will _never_ get the same request context? 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you would get the same context for 2 JMS invocations which get (randomly) executed on the same worker thread. Got me? LieGrue, strub > Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau : > > Hi > > I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. > > Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : > Hi guys, > > We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. > > Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. > > Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. > > What is you feeling about this ? > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From rmannibucau at gmail.com Thu Jun 18 18:36:56 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 19 Jun 2015 00:36:56 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> Message-ID: Le 18 juin 2015 20:37, "Mark Struberg" a ?crit : > > 1.) The whole point is that @RequestScoped is NOT a web context! > > Otherwise it would _not_ be active in JMS etc? > And that was not an accident but intentional. > Excepted it is highly bound to web (events, lifecycle etc...). Ejb integ is weak and could have been ignored - just my opinion on this last part, dont want a thread on this. > 2.) And no, different async threads will _never_ get the same request context? > Start to use it and you ll miss it - or u missed my point. > > 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you would get the same context for 2 JMS invocations which get (randomly) executed on the same worker thread. Got me? > ThreadScoped =TaskScope for an executor service. The whole point is while you cant use it urself - without DS - it is not a threadscope. Is it clearer? > > LieGrue, > strub > > > > Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau : > > > > Hi > > > > I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. > > > > Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. > > > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > > > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand < antoine at sabot-durand.net>: > > Hi guys, > > > > We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. > > > > Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. > > > > Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. > > > > What is you feeling about this ? > > > > Antoine > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150619/f7c36725/attachment-0001.html From antoine at sabot-durand.net Fri Jun 19 02:43:48 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 19 Jun 2015 07:43:48 +0100 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> Message-ID: Jozef, Martin, What is your POV on that ? Antoine > Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : > > 1.) The whole point is that @RequestScoped is NOT a web context! > > Otherwise it would _not_ be active in JMS etc? > And that was not an accident but intentional. > > 2.) And no, different async threads will _never_ get the same request context? > > > 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you would get the same context for 2 JMS invocations which get (randomly) executed on the same worker thread. Got me? > > > LieGrue, > strub > > >> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau : >> >> Hi >> >> I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. >> >> Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : >> Hi guys, >> >> We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. >> >> Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. >> >> Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. >> >> What is you feeling about this ? >> >> 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. > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150619/7e86740f/attachment.bin From mkouba at redhat.com Fri Jun 19 03:14:16 2015 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 19 Jun 2015 09:14:16 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> Message-ID: <5583C148.8030109@redhat.com> I'm in favour of having the request context active during async event delivery. I.e. each notification will have it's own request context. The name of the context is not perfect but it would be consistent with other parts of the spec (@PostConstruct, EJB async, MDB, web service, ...). As I already said - HTTP-specific contexts should not be active during async delivery. WRT @ThreadScoped - I don't think it's a good name. A better name would be @TaskScoped. We have a similar context in Weld SE but it needs some revision [1]. I'm not sure whether it would deserve to become/inspire a new built-in context though. Martin [1] https://issues.jboss.org/browse/WELD-1905 Dne 19.6.2015 v 08:43 Antoine Sabot-Durand napsal(a): > Jozef, Martin, > > > What is your POV on that ? > > Antoine > > >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : >> >> 1.) The whole point is that @RequestScoped is NOT a web context! >> >> Otherwise it would _not_ be active in JMS etc? >> And that was not an accident but intentional. >> >> 2.) And no, different async threads will _never_ get the same request context? >> >> >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you would get the same context for 2 JMS invocations which get (randomly) executed on the same worker thread. Got me? >> >> >> LieGrue, >> strub >> >> >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau : >>> >>> Hi >>> >>> I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. >>> >>> Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : >>> Hi guys, >>> >>> We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. >>> >>> Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. >>> >>> Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. >>> >>> What is you feeling about this ? >>> >>> 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. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > From antoine at sabot-durand.net Fri Jun 19 03:26:34 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 19 Jun 2015 07:26:34 +0000 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <5583C148.8030109@redhat.com> References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <5583C148.8030109@redhat.com> Message-ID: Thanks Martin And about request context activation in java SE (for edr1 scope) ? Le ven. 19 juin 2015 ? 08:14, Martin Kouba a ?crit : > I'm in favour of having the request context active during async event > delivery. I.e. each notification will have it's own request context. The > name of the context is not perfect but it would be consistent with other > parts of the spec (@PostConstruct, EJB async, MDB, web service, ...). As > I already said - HTTP-specific contexts should not be active during > async delivery. > > WRT @ThreadScoped - I don't think it's a good name. A better name would > be @TaskScoped. We have a similar context in Weld SE but it needs some > revision [1]. I'm not sure whether it would deserve to become/inspire a > new built-in context though. > > Martin > > [1] > https://issues.jboss.org/browse/WELD-1905 > > Dne 19.6.2015 v 08:43 Antoine Sabot-Durand napsal(a): > > Jozef, Martin, > > > > > > What is your POV on that ? > > > > Antoine > > > > > >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : > >> > >> 1.) The whole point is that @RequestScoped is NOT a web context! > >> > >> Otherwise it would _not_ be active in JMS etc? > >> And that was not an accident but intentional. > >> > >> 2.) And no, different async threads will _never_ get the same request > context? > >> > >> > >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you > would get the same context for 2 JMS invocations which get (randomly) > executed on the same worker thread. Got me? > >> > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau < > rmannibucau at gmail.com>: > >>> > >>> Hi > >>> > >>> I wouldn't activate any "web" scope by default, in particular for > async events where I think most of the time it will not be used. Next > feature request will be to inherit the scope between async threads....and > here I guess we agree it will not go very far. > >>> > >>> Side note: using request scope where actually a thread scope is needed > is a pain, maybe time to add a thread scoped with an accessible manual > activation. Would make "batches", "timers" etc easy to impl/integrate. > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > >>> Hi guys, > >>> > >>> We should finally decide how to manage normal scope context (other > than application context ) in SE and during Async Event for EDR1. > >>> > >>> Having only RequestContext active during async event as Martin > suggest in the PR makes sense and would be consistent with its behavior > during async EJB call. > >>> > >>> Mark asked twice to activate Request Context all the time in SE > (making it a new Application Context). I?m not found of it, but I?ml not > the only one to decide here. > >>> > >>> What is you feeling about this ? > >>> > >>> 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. > >> > >> > >> _______________________________________________ > >> 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/20150619/5d437cc0/attachment.html From antoine at sabot-durand.net Fri Jun 19 06:43:18 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 19 Jun 2015 11:43:18 +0100 Subject: [cdi-dev] Doodle on CDI F2F closing on monday Message-ID: <7777167C-BA06-4CE7-AE0D-C4575B03F651@sabot-durand.net> Hi guys, I only got 6 participants to our Doodle for the F2F date in Paris. Right now Sept 18th seems to be the best choice, but you can still give your choices on: http://doodle.com/ecvpshxceup8b278 I?ll close the votes on monday to set the final date. Thanks for your commitment Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150619/1d381a5a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150619/1d381a5a/attachment-0001.bin From jharting at redhat.com Fri Jun 19 08:57:12 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 19 Jun 2015 14:57:12 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> Message-ID: <558411A8.9040508@redhat.com> I agree with Martin and Mark. @RequestScoped already is used as a general purpose task-bound scope. This covers, but is not limited to, HTTP request. On the other hand @SessionScoped and @ConversationScoped are only defined to be available for HTTP requests. On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: > Jozef, Martin, > > > What is your POV on that ? > > Antoine > > >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : >> >> 1.) The whole point is that @RequestScoped is NOT a web context! >> >> Otherwise it would _not_ be active in JMS etc? >> And that was not an accident but intentional. >> >> 2.) And no, different async threads will _never_ get the same request context? >> >> >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you would get the same context for 2 JMS invocations which get (randomly) executed on the same worker thread. Got me? >> >> >> LieGrue, >> strub >> >> >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau : >>> >>> Hi >>> >>> I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. >>> >>> Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : >>> Hi guys, >>> >>> We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. >>> >>> Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. >>> >>> Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. >>> >>> What is you feeling about this ? >>> >>> 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. >> >> _______________________________________________ >> 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 Jun 19 08:59:45 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 19 Jun 2015 14:59:45 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <558411A8.9040508@redhat.com> References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> Message-ID: Looks like you miss the main point. The usage is not portable most of the time. Cant we make it portable? Le 19 juin 2015 13:57, "Jozef Hartinger" a ?crit : > I agree with Martin and Mark. @RequestScoped already is used as a > general purpose task-bound scope. This covers, but is not limited to, > HTTP request. On the other hand @SessionScoped and @ConversationScoped > are only defined to be available for HTTP requests. > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: > > Jozef, Martin, > > > > > > What is your POV on that ? > > > > Antoine > > > > > >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : > >> > >> 1.) The whole point is that @RequestScoped is NOT a web context! > >> > >> Otherwise it would _not_ be active in JMS etc? > >> And that was not an accident but intentional. > >> > >> 2.) And no, different async threads will _never_ get the same request > context? > >> > >> > >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you > would get the same context for 2 JMS invocations which get (randomly) > executed on the same worker thread. Got me? > >> > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau < > rmannibucau at gmail.com>: > >>> > >>> Hi > >>> > >>> I wouldn't activate any "web" scope by default, in particular for > async events where I think most of the time it will not be used. Next > feature request will be to inherit the scope between async threads....and > here I guess we agree it will not go very far. > >>> > >>> Side note: using request scope where actually a thread scope is needed > is a pain, maybe time to add a thread scoped with an accessible manual > activation. Would make "batches", "timers" etc easy to impl/integrate. > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > >>> Hi guys, > >>> > >>> We should finally decide how to manage normal scope context (other > than application context ) in SE and during Async Event for EDR1. > >>> > >>> Having only RequestContext active during async event as Martin > suggest in the PR makes sense and would be consistent with its behavior > during async EJB call. > >>> > >>> Mark asked twice to activate Request Context all the time in SE > (making it a new Application Context). I?m not found of it, but I?ml not > the only one to decide here. > >>> > >>> What is you feeling about this ? > >>> > >>> 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. > >> > >> _______________________________________________ > >> 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/20150619/2922c2f8/attachment.html From mkouba at redhat.com Fri Jun 19 09:04:29 2015 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 19 Jun 2015 15:04:29 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> Message-ID: <5584135D.6090206@redhat.com> Dne 19.6.2015 v 14:59 Romain Manni-Bucau napsal(a): > Looks like you miss the main point. The usage is not portable most of > the time. Cant we make it portable? What do you mean with "portable" here? Could you explain please? > > Le 19 juin 2015 13:57, "Jozef Hartinger" > a ?crit : > > I agree with Martin and Mark. @RequestScoped already is used as a > general purpose task-bound scope. This covers, but is not limited to, > HTTP request. On the other hand @SessionScoped and @ConversationScoped > are only defined to be available for HTTP requests. > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: > > Jozef, Martin, > > > > > > What is your POV on that ? > > > > Antoine > > > > > >> Le 18 juin 2015 ? 20:37, Mark Struberg > a ?crit : > >> > >> 1.) The whole point is that @RequestScoped is NOT a web context! > >> > >> Otherwise it would _not_ be active in JMS etc? > >> And that was not an accident but intentional. > >> > >> 2.) And no, different async threads will _never_ get the same > request context? > >> > >> > >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. > Otherwise you would get the same context for 2 JMS invocations which > get (randomly) executed on the same worker thread. Got me? > >> > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau > >: > >>> > >>> Hi > >>> > >>> I wouldn't activate any "web" scope by default, in particular > for async events where I think most of the time it will not be used. > Next feature request will be to inherit the scope between async > threads....and here I guess we agree it will not go very far. > >>> > >>> Side note: using request scope where actually a thread scope is > needed is a pain, maybe time to add a thread scoped with an > accessible manual activation. Would make "batches", "timers" etc > easy to impl/integrate. > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand > >: > >>> Hi guys, > >>> > >>> We should finally decide how to manage normal scope context > (other than application context ) in SE and during Async Event for EDR1. > >>> > >>> Having only RequestContext active during async event as Martin > suggest in the PR makes sense and would be consistent with its > behavior during async EJB call. > >>> > >>> Mark asked twice to activate Request Context all the time in SE > (making it a new Application Context). I?m not found of it, but I?ml > not the only one to decide here. > >>> > >>> What is you feeling about this ? > >>> > >>> 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. > >> > >> _______________________________________________ > >> 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From jharting at redhat.com Fri Jun 19 09:08:01 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 19 Jun 2015 15:08:01 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> Message-ID: <55841431.8030409@redhat.com> I am talking about: * remote method invocations * @Asynchronous method invocation * @Timeout method invocation * MDB message delivery * @PostConstruct callback invocation all of which are portable. We can expand the definition for other "tasks" that make sense, e.g. async observer notification. On 06/19/2015 02:59 PM, Romain Manni-Bucau wrote: > > Looks like you miss the main point. The usage is not portable most of > the time. Cant we make it portable? > > Le 19 juin 2015 13:57, "Jozef Hartinger" > a ?crit : > > I agree with Martin and Mark. @RequestScoped already is used as a > general purpose task-bound scope. This covers, but is not limited to, > HTTP request. On the other hand @SessionScoped and @ConversationScoped > are only defined to be available for HTTP requests. > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: > > Jozef, Martin, > > > > > > What is your POV on that ? > > > > Antoine > > > > > >> Le 18 juin 2015 ? 20:37, Mark Struberg > a ?crit : > >> > >> 1.) The whole point is that @RequestScoped is NOT a web context! > >> > >> Otherwise it would _not_ be active in JMS etc? > >> And that was not an accident but intentional. > >> > >> 2.) And no, different async threads will _never_ get the same > request context? > >> > >> > >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. > Otherwise you would get the same context for 2 JMS invocations > which get (randomly) executed on the same worker thread. Got me? > >> > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau > >: > >>> > >>> Hi > >>> > >>> I wouldn't activate any "web" scope by default, in particular > for async events where I think most of the time it will not be > used. Next feature request will be to inherit the scope between > async threads....and here I guess we agree it will not go very far. > >>> > >>> Side note: using request scope where actually a thread scope > is needed is a pain, maybe time to add a thread scoped with an > accessible manual activation. Would make "batches", "timers" etc > easy to impl/integrate. > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand > >: > >>> Hi guys, > >>> > >>> We should finally decide how to manage normal scope context > (other than application context ) in SE and during Async Event for > EDR1. > >>> > >>> Having only RequestContext active during async event as > Martin suggest in the PR makes sense and would be consistent with > its behavior during async EJB call. > >>> > >>> Mark asked twice to activate Request Context all the time in > SE (making it a new Application Context). I?m not found of it, but > I?ml not the only one to decide here. > >>> > >>> What is you feeling about this ? > >>> > >>> 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. > >> > >> _______________________________________________ > >> 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/20150619/a2a7724e/attachment-0001.html From rmannibucau at gmail.com Fri Jun 19 09:50:04 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 19 Jun 2015 15:50:04 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <55841431.8030409@redhat.com> References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> <55841431.8030409@redhat.com> Message-ID: I dont think defining all cases works. Why not letting user handling their lifecyle? Le 19 juin 2015 14:08, "Jozef Hartinger" a ?crit : > I am talking about: > > * remote method invocations > * @Asynchronous method invocation > * @Timeout method invocation > * MDB message delivery > * @PostConstruct callback invocation > > all of which are portable. We can expand the definition for other "tasks" > that make sense, e.g. async observer notification. > > On 06/19/2015 02:59 PM, Romain Manni-Bucau wrote: > > Looks like you miss the main point. The usage is not portable most of the > time. Cant we make it portable? > Le 19 juin 2015 13:57, "Jozef Hartinger" a ?crit : > >> I agree with Martin and Mark. @RequestScoped already is used as a >> general purpose task-bound scope. This covers, but is not limited to, >> HTTP request. On the other hand @SessionScoped and @ConversationScoped >> are only defined to be available for HTTP requests. >> >> On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: >> > Jozef, Martin, >> > >> > >> > What is your POV on that ? >> > >> > Antoine >> > >> > >> >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : >> >> >> >> 1.) The whole point is that @RequestScoped is NOT a web context! >> >> >> >> Otherwise it would _not_ be active in JMS etc? >> >> And that was not an accident but intentional. >> >> >> >> 2.) And no, different async threads will _never_ get the same request >> context? >> >> >> >> >> >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you >> would get the same context for 2 JMS invocations which get (randomly) >> executed on the same worker thread. Got me? >> >> >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau < >> rmannibucau at gmail.com>: >> >>> >> >>> Hi >> >>> >> >>> I wouldn't activate any "web" scope by default, in particular for >> async events where I think most of the time it will not be used. Next >> feature request will be to inherit the scope between async threads....and >> here I guess we agree it will not go very far. >> >>> >> >>> Side note: using request scope where actually a thread scope is >> needed is a pain, maybe time to add a thread scoped with an accessible >> manual activation. Would make "batches", "timers" etc easy to >> impl/integrate. >> >>> >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>> >> >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand < >> antoine at sabot-durand.net>: >> >>> Hi guys, >> >>> >> >>> We should finally decide how to manage normal scope context (other >> than application context ) in SE and during Async Event for EDR1. >> >>> >> >>> Having only RequestContext active during async event as Martin >> suggest in the PR makes sense and would be consistent with its behavior >> during async EJB call. >> >>> >> >>> Mark asked twice to activate Request Context all the time in SE >> (making it a new Application Context). I?m not found of it, but I?ml not >> the only one to decide here. >> >>> >> >>> What is you feeling about this ? >> >>> >> >>> 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. >> >> >> >> _______________________________________________ >> >> 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/20150619/8b15e8f7/attachment.html From antonio.goncalves at gmail.com Fri Jun 19 10:33:17 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Fri, 19 Jun 2015 16:33:17 +0200 Subject: [cdi-dev] Added chapter for context in Java SE. In-Reply-To: References: Message-ID: Are we talking about this version of the spec : https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html ? Antonio On Mon, Jun 15, 2015 at 4:25 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > > I added a Scopes and contexts in Java SE chapter to specify that only > Application Context is active under Java SE. > This part will probably refine later thru CDI-530 > > 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150619/a355ab1f/attachment.html From struberg at yahoo.de Fri Jun 19 12:20:32 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 19 Jun 2015 18:20:32 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <558411A8.9040508@redhat.com> References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> Message-ID: +1, I fully agree that we should _not_ activate @SessionScoped and @ConversationScoped in any ?real? non-http request. But @RequestScoped is not really a ?pure? http context. LieGrue, strub > Am 19.06.2015 um 14:57 schrieb Jozef Hartinger : > > I agree with Martin and Mark. @RequestScoped already is used as a > general purpose task-bound scope. This covers, but is not limited to, > HTTP request. On the other hand @SessionScoped and @ConversationScoped > are only defined to be available for HTTP requests. > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: >> Jozef, Martin, >> >> >> What is your POV on that ? >> >> Antoine >> >> >>> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : >>> >>> 1.) The whole point is that @RequestScoped is NOT a web context! >>> >>> Otherwise it would _not_ be active in JMS etc? >>> And that was not an accident but intentional. >>> >>> 2.) And no, different async threads will _never_ get the same request context? >>> >>> >>> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you would get the same context for 2 JMS invocations which get (randomly) executed on the same worker thread. Got me? >>> >>> >>> LieGrue, >>> strub >>> >>> >>>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau : >>>> >>>> Hi >>>> >>>> I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. >>>> >>>> Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : >>>> Hi guys, >>>> >>>> We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. >>>> >>>> Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. >>>> >>>> Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. >>>> >>>> What is you feeling about this ? >>>> >>>> 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. >>> >>> _______________________________________________ >>> 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 struberg at yahoo.de Fri Jun 19 12:21:16 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 19 Jun 2015 18:21:16 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> Message-ID: <3AA990B0-A1B5-4DA4-A647-4FFC9A2F49DB@yahoo.de> Romain, I think I totally lost you. Which part of it is not portable? Do you have any example? LieGrue, strub > Am 19.06.2015 um 14:59 schrieb Romain Manni-Bucau : > > Looks like you miss the main point. The usage is not portable most of the time. Cant we make it portable? > > Le 19 juin 2015 13:57, "Jozef Hartinger" a ?crit : > I agree with Martin and Mark. @RequestScoped already is used as a > general purpose task-bound scope. This covers, but is not limited to, > HTTP request. On the other hand @SessionScoped and @ConversationScoped > are only defined to be available for HTTP requests. > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: > > Jozef, Martin, > > > > > > What is your POV on that ? > > > > Antoine > > > > > >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : > >> > >> 1.) The whole point is that @RequestScoped is NOT a web context! > >> > >> Otherwise it would _not_ be active in JMS etc? > >> And that was not an accident but intentional. > >> > >> 2.) And no, different async threads will _never_ get the same request context? > >> > >> > >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you would get the same context for 2 JMS invocations which get (randomly) executed on the same worker thread. Got me? > >> > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau : > >>> > >>> Hi > >>> > >>> I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. > >>> > >>> Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : > >>> Hi guys, > >>> > >>> We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. > >>> > >>> Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. > >>> > >>> Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. > >>> > >>> What is you feeling about this ? > >>> > >>> 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. > >> > >> _______________________________________________ > >> 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. From struberg at yahoo.de Fri Jun 19 12:23:24 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 19 Jun 2015 18:23:24 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> <55841431.8030409@redhat.com> Message-ID: <8F1AC1D8-E9AE-4C56-9BAB-D1857C3B619E@yahoo.de> No, in all the the listed cases the Context for @RequestScoped is specified to be active. This is even nailed down in multiple specs. LieGrue, strub > Am 19.06.2015 um 15:50 schrieb Romain Manni-Bucau : > > I dont think defining all cases works. Why not letting user handling their lifecyle? > > Le 19 juin 2015 14:08, "Jozef Hartinger" a ?crit : > I am talking aNbout: > > * remote method invocations > * @Asynchronous method invocation > * @Timeout method invocation > * MDB message delivery > * @PostConstruct callback invocation > > all of which are portable. We can expand the definition for other "tasks" that make sense, e.g. async observer notification. > > On 06/19/2015 02:59 PM, Romain Manni-Bucau wrote: >> Looks like you miss the main point. The usage is not portable most of the time. Cant we make it portable? >> >> Le 19 juin 2015 13:57, "Jozef Hartinger" a ?crit : >> I agree with Martin and Mark. @RequestScoped already is used as a >> general purpose task-bound scope. This covers, but is not limited to, >> HTTP request. On the other hand @SessionScoped and @ConversationScoped >> are only defined to be available for HTTP requests. >> >> On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: >> > Jozef, Martin, >> > >> > >> > What is your POV on that ? >> > >> > Antoine >> > >> > >> >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : >> >> >> >> 1.) The whole point is that @RequestScoped is NOT a web context! >> >> >> >> Otherwise it would _not_ be active in JMS etc? >> >> And that was not an accident but intentional. >> >> >> >> 2.) And no, different async threads will _never_ get the same request context? >> >> >> >> >> >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you would get the same context for 2 JMS invocations which get (randomly) executed on the same worker thread. Got me? >> >> >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau : >> >>> >> >>> Hi >> >>> >> >>> I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. >> >>> >> >>> Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. >> >>> >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>> >> >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : >> >>> Hi guys, >> >>> >> >>> We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. >> >>> >> >>> Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. >> >>> >> >>> Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. >> >>> >> >>> What is you feeling about this ? >> >>> >> >>> 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. >> >> >> >> _______________________________________________ >> >> 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. From rmannibucau at gmail.com Fri Jun 19 12:26:54 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 19 Jun 2015 18:26:54 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <3AA990B0-A1B5-4DA4-A647-4FFC9A2F49DB@yahoo.de> References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> <3AA990B0-A1B5-4DA4-A647-4FFC9A2F49DB@yahoo.de> Message-ID: @Mark: said shortly cdictrl should go in the spec. Allowing to write an request scoped executor service should be possible for frameworks Le 19 juin 2015 17:21, "Mark Struberg" a ?crit : > Romain, I think I totally lost you. Which part of it is not portable? Do > you have any example? > > LieGrue, > strub > > > > > Am 19.06.2015 um 14:59 schrieb Romain Manni-Bucau >: > > > > Looks like you miss the main point. The usage is not portable most of > the time. Cant we make it portable? > > > > Le 19 juin 2015 13:57, "Jozef Hartinger" a ?crit : > > I agree with Martin and Mark. @RequestScoped already is used as a > > general purpose task-bound scope. This covers, but is not limited to, > > HTTP request. On the other hand @SessionScoped and @ConversationScoped > > are only defined to be available for HTTP requests. > > > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: > > > Jozef, Martin, > > > > > > > > > What is your POV on that ? > > > > > > Antoine > > > > > > > > >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : > > >> > > >> 1.) The whole point is that @RequestScoped is NOT a web context! > > >> > > >> Otherwise it would _not_ be active in JMS etc? > > >> And that was not an accident but intentional. > > >> > > >> 2.) And no, different async threads will _never_ get the same request > context? > > >> > > >> > > >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you > would get the same context for 2 JMS invocations which get (randomly) > executed on the same worker thread. Got me? > > >> > > >> > > >> LieGrue, > > >> strub > > >> > > >> > > >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau < > rmannibucau at gmail.com>: > > >>> > > >>> Hi > > >>> > > >>> I wouldn't activate any "web" scope by default, in particular for > async events where I think most of the time it will not be used. Next > feature request will be to inherit the scope between async threads....and > here I guess we agree it will not go very far. > > >>> > > >>> Side note: using request scope where actually a thread scope is > needed is a pain, maybe time to add a thread scoped with an accessible > manual activation. Would make "batches", "timers" etc easy to > impl/integrate. > > >>> > > >>> > > >>> > > >>> Romain Manni-Bucau > > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > >>> > > >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > >>> Hi guys, > > >>> > > >>> We should finally decide how to manage normal scope context (other > than application context ) in SE and during Async Event for EDR1. > > >>> > > >>> Having only RequestContext active during async event as Martin > suggest in the PR makes sense and would be consistent with its behavior > during async EJB call. > > >>> > > >>> Mark asked twice to activate Request Context all the time in SE > (making it a new Application Context). I?m not found of it, but I?ml not > the only one to decide here. > > >>> > > >>> What is you feeling about this ? > > >>> > > >>> 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. > > >> > > >> _______________________________________________ > > >> 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/20150619/72430d1c/attachment-0001.html From struberg at yahoo.de Fri Jun 19 12:31:03 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 19 Jun 2015 18:31:03 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> <3AA990B0-A1B5-4DA4-A647-4FFC9A2F49DB@yahoo.de> Message-ID: Well, CdiCtrl is on the way. The missing part is ContextControl. But we need to find a better solution as I?m not yet perfectly happy with what we have in DeltaSpike. That is also the reason why it?s not yet in EDR1. But I agree that it surely should be in the Final CDI-2.0 release! That doesn?t change the fact that the RequestContext should be available by default. At least for now (where we have no ContextCtrl). LieGrue, strub > Am 19.06.2015 um 18:26 schrieb Romain Manni-Bucau : > > @Mark: said shortly cdictrl should go in the spec. Allowing to write an request scoped executor service should be possible for frameworks > > Le 19 juin 2015 17:21, "Mark Struberg" a ?crit : > Romain, I think I totally lost you. Which part of it is not portable? Do you have any example? > > LieGrue, > strub > > > > > Am 19.06.2015 um 14:59 schrieb Romain Manni-Bucau : > > > > Looks like you miss the main point. The usage is not portable most of the time. Cant we make it portable? > > > > Le 19 juin 2015 13:57, "Jozef Hartinger" a ?crit : > > I agree with Martin and Mark. @RequestScoped already is used as a > > general purpose task-bound scope. This covers, but is not limited to, > > HTTP request. On the other hand @SessionScoped and @ConversationScoped > > are only defined to be available for HTTP requests. > > > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: > > > Jozef, Martin, > > > > > > > > > What is your POV on that ? > > > > > > Antoine > > > > > > > > >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : > > >> > > >> 1.) The whole point is that @RequestScoped is NOT a web context! > > >> > > >> Otherwise it would _not_ be active in JMS etc? > > >> And that was not an accident but intentional. > > >> > > >> 2.) And no, different async threads will _never_ get the same request context? > > >> > > >> > > >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you would get the same context for 2 JMS invocations which get (randomly) executed on the same worker thread. Got me? > > >> > > >> > > >> LieGrue, > > >> strub > > >> > > >> > > >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau : > > >>> > > >>> Hi > > >>> > > >>> I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. > > >>> > > >>> Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. > > >>> > > >>> > > >>> > > >>> Romain Manni-Bucau > > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > >>> > > >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : > > >>> Hi guys, > > >>> > > >>> We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. > > >>> > > >>> Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. > > >>> > > >>> Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. > > >>> > > >>> What is you feeling about this ? > > >>> > > >>> 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. > > >> > > >> _______________________________________________ > > >> 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. > From rmannibucau at gmail.com Fri Jun 19 12:34:36 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 19 Jun 2015 18:34:36 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> <3AA990B0-A1B5-4DA4-A647-4FFC9A2F49DB@yahoo.de> Message-ID: Guess we reach the point we say the same thing differently so let switch to how we get this new API in the final version? Le 19 juin 2015 17:31, "Mark Struberg" a ?crit : > Well, CdiCtrl is on the way. The missing part is ContextControl. But we > need to find a better solution as I?m not yet perfectly happy with what we > have in DeltaSpike. That is also the reason why it?s not yet in EDR1. But I > agree that it surely should be in the Final CDI-2.0 release! > That doesn?t change the fact that the RequestContext should be available > by default. At least for now (where we have no ContextCtrl). > > LieGrue, > strub > > > > Am 19.06.2015 um 18:26 schrieb Romain Manni-Bucau >: > > > > @Mark: said shortly cdictrl should go in the spec. Allowing to write an > request scoped executor service should be possible for frameworks > > > > Le 19 juin 2015 17:21, "Mark Struberg" a ?crit : > > Romain, I think I totally lost you. Which part of it is not portable? Do > you have any example? > > > > LieGrue, > > strub > > > > > > > > > Am 19.06.2015 um 14:59 schrieb Romain Manni-Bucau < > rmannibucau at gmail.com>: > > > > > > Looks like you miss the main point. The usage is not portable most of > the time. Cant we make it portable? > > > > > > Le 19 juin 2015 13:57, "Jozef Hartinger" a > ?crit : > > > I agree with Martin and Mark. @RequestScoped already is used as a > > > general purpose task-bound scope. This covers, but is not limited to, > > > HTTP request. On the other hand @SessionScoped and @ConversationScoped > > > are only defined to be available for HTTP requests. > > > > > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: > > > > Jozef, Martin, > > > > > > > > > > > > What is your POV on that ? > > > > > > > > Antoine > > > > > > > > > > > >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit > : > > > >> > > > >> 1.) The whole point is that @RequestScoped is NOT a web context! > > > >> > > > >> Otherwise it would _not_ be active in JMS etc? > > > >> And that was not an accident but intentional. > > > >> > > > >> 2.) And no, different async threads will _never_ get the same > request context? > > > >> > > > >> > > > >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise > you would get the same context for 2 JMS invocations which get (randomly) > executed on the same worker thread. Got me? > > > >> > > > >> > > > >> LieGrue, > > > >> strub > > > >> > > > >> > > > >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau < > rmannibucau at gmail.com>: > > > >>> > > > >>> Hi > > > >>> > > > >>> I wouldn't activate any "web" scope by default, in particular for > async events where I think most of the time it will not be used. Next > feature request will be to inherit the scope between async threads....and > here I guess we agree it will not go very far. > > > >>> > > > >>> Side note: using request scope where actually a thread scope is > needed is a pain, maybe time to add a thread scoped with an accessible > manual activation. Would make "batches", "timers" etc easy to > impl/integrate. > > > >>> > > > >>> > > > >>> > > > >>> Romain Manni-Bucau > > > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > > >>> > > > >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > > >>> Hi guys, > > > >>> > > > >>> We should finally decide how to manage normal scope context (other > than application context ) in SE and during Async Event for EDR1. > > > >>> > > > >>> Having only RequestContext active during async event as Martin > suggest in the PR makes sense and would be consistent with its behavior > during async EJB call. > > > >>> > > > >>> Mark asked twice to activate Request Context all the time in SE > (making it a new Application Context). I?m not found of it, but I?ml not > the only one to decide here. > > > >>> > > > >>> What is you feeling about this ? > > > >>> > > > >>> 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. > > > >> > > > >> _______________________________________________ > > > >> 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/20150619/46ac828b/attachment.html From struberg at yahoo.de Fri Jun 19 12:43:26 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 19 Jun 2015 18:43:26 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <78F36BC8-DA2F-4A10-AEB6-8F436791A737@yahoo.de> <558411A8.9040508@redhat.com> <3AA990B0-A1B5-4DA4-A647-4FFC9A2F49DB@yahoo.de> Message-ID: <49EFB8F1-E68F-4325-95D9-CB886638FD73@yahoo.de> +1 :) LieGrue, strub > Am 19.06.2015 um 18:34 schrieb Romain Manni-Bucau : > > Guess we reach the point we say the same thing differently so let switch to how we get this new API in the final version? > Le 19 juin 2015 17:31, "Mark Struberg" a ?crit : > Well, CdiCtrl is on the way. The missing part is ContextControl. But we need to find a better solution as I?m not yet perfectly happy with what we have in DeltaSpike. That is also the reason why it?s not yet in EDR1. But I agree that it surely should be in the Final CDI-2.0 release! > That doesn?t change the fact that the RequestContext should be available by default. At least for now (where we have no ContextCtrl). > > LieGrue, > strub > > > > Am 19.06.2015 um 18:26 schrieb Romain Manni-Bucau : > > > > @Mark: said shortly cdictrl should go in the spec. Allowing to write an request scoped executor service should be possible for frameworks > > > > Le 19 juin 2015 17:21, "Mark Struberg" a ?crit : > > Romain, I think I totally lost you. Which part of it is not portable? Do you have any example? > > > > LieGrue, > > strub > > > > > > > > > Am 19.06.2015 um 14:59 schrieb Romain Manni-Bucau : > > > > > > Looks like you miss the main point. The usage is not portable most of the time. Cant we make it portable? > > > > > > Le 19 juin 2015 13:57, "Jozef Hartinger" a ?crit : > > > I agree with Martin and Mark. @RequestScoped already is used as a > > > general purpose task-bound scope. This covers, but is not limited to, > > > HTTP request. On the other hand @SessionScoped and @ConversationScoped > > > are only defined to be available for HTTP requests. > > > > > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: > > > > Jozef, Martin, > > > > > > > > > > > > What is your POV on that ? > > > > > > > > Antoine > > > > > > > > > > > >> Le 18 juin 2015 ? 20:37, Mark Struberg a ?crit : > > > >> > > > >> 1.) The whole point is that @RequestScoped is NOT a web context! > > > >> > > > >> Otherwise it would _not_ be active in JMS etc? > > > >> And that was not an accident but intentional. > > > >> > > > >> 2.) And no, different async threads will _never_ get the same request context? > > > >> > > > >> > > > >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you would get the same context for 2 JMS invocations which get (randomly) executed on the same worker thread. Got me? > > > >> > > > >> > > > >> LieGrue, > > > >> strub > > > >> > > > >> > > > >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau : > > > >>> > > > >>> Hi > > > >>> > > > >>> I wouldn't activate any "web" scope by default, in particular for async events where I think most of the time it will not be used. Next feature request will be to inherit the scope between async threads....and here I guess we agree it will not go very far. > > > >>> > > > >>> Side note: using request scope where actually a thread scope is needed is a pain, maybe time to add a thread scoped with an accessible manual activation. Would make "batches", "timers" etc easy to impl/integrate. > > > >>> > > > >>> > > > >>> > > > >>> Romain Manni-Bucau > > > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > > >>> > > > >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : > > > >>> Hi guys, > > > >>> > > > >>> We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. > > > >>> > > > >>> Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. > > > >>> > > > >>> Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. > > > >>> > > > >>> What is you feeling about this ? > > > >>> > > > >>> 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. > > > >> > > > >> _______________________________________________ > > > >> 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. > > > From atsticks at gmail.com Fri Jun 19 18:51:21 2015 From: atsticks at gmail.com (Anatole Tresch) Date: Sat, 20 Jun 2015 00:51:21 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: Message-ID: Hi all, for me the question is: do we need a RequestContext? We have the Event payload, which is shared (and AFAIK also still mutable) and can be used to represent the common context as well, for both synch or asynch event cases. Adding a parallel "context" does not necessarily make things easier IMO, because you have to exactly define what a request in that sense is, when does it start, where does it end, how it is propagated/stacked etc. So my question is: what is the benefit of defining the request scope additional to the event payload already in place? Anatole 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : > Hi guys, > > We should finally decide how to manage normal scope context (other than > application context ) in SE and during Async Event for EDR1. > > Having only RequestContext active during async event as Martin suggest in > the PR makes sense and would be consistent with its behavior during async > EJB call. > > Mark asked twice to activate Request Context all the time in SE (making it > a new Application Context). I?m not found of it, but I?ml not the only one > to decide here. > > What is you feeling about this ? > > 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. > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150620/5785fb8e/attachment.html From struberg at yahoo.de Sat Jun 20 16:25:07 2015 From: struberg at yahoo.de (Mark Struberg) Date: Sat, 20 Jun 2015 22:25:07 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: Message-ID: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> The Request context is not needed by the eventing system itself. But tons of usercode around needs the requestcontext to be set up and active. This is the default for almost every spec definedmanaged bean invocation. So we should rather not change this for async events neither. If we change this then you could not reuse lots of existing code in your new async observer. The lifecycle is rather easy to define: it starts shortly before the async method (including interceptors/decorators/etc) gets started and ends afterwards. LieGrue, strub > Am 20.06.2015 um 00:51 schrieb Anatole Tresch : > > Hi all, > > for me the question is: do we need a RequestContext? We have the Event payload, which is shared (and AFAIK also still mutable) and can be used to represent the common context as well, for both synch or asynch event cases. Adding a parallel "context" does not necessarily make things easier IMO, because you have to exactly define what a request in that sense is, when does it start, where does it end, how it is propagated/stacked etc. So my question is: what is the benefit of defining the request scope additional to the event payload already in place? > > Anatole > > > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand : > Hi guys, > > We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1. > > Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call. > > Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I?m not found of it, but I?ml not the only one to decide here. > > What is you feeling about this ? > > 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. > > > > -- > Anatole Tresch > Java Engineer & Architect, JSR Spec Lead > Gl?rnischweg 10 > CH - 8620 Wetzikon > > Switzerland, Europe Zurich, GMT+1 > Twitter: @atsticks > Blogs: http://javaremarkables.blogspot.ch/ > Google: atsticks > Mobile +41-76 344 62 79 > _______________________________________________ > 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 Sun Jun 21 08:03:02 2015 From: issues at jboss.org (arjan tijms (JIRA)) Date: Sun, 21 Jun 2015 08:03:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081947#comment-13081947 ] arjan tijms commented on CDI-492: --------------------------------- {quote}I understand those concerns, but I think there are solution for most of them.{quote} Just wondering if there's any progress here or someone still looking into this? Like Antoine I can't help but feel the issues raised are worth looking into to see if they can be solved. A part of the solution can simply be education, as perhaps it's just a matter of not everyone being fully up to date with how CDI works. > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From antoine at sabot-durand.net Mon Jun 22 05:05:48 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 22 Jun 2015 09:05:48 +0000 Subject: [cdi-dev] Fwd: Added chapter for context in Java SE. In-Reply-To: <234754C2-CA8E-4921-866F-8711765D26EF@yahoo.de> References: <1434405910.78580.YahooMailIosMobile@web121604.mail.ne1.yahoo.com> <234754C2-CA8E-4921-866F-8711765D26EF@yahoo.de> Message-ID: Discussion that was accidentally in private mode ---------- Forwarded message --------- From: Mark Struberg Date: ven. 19 juin 2015 ? 18:17 Subject: Re: [cdi-dev] Added chapter for context in Java SE. To: Sabot-Durand Antoine Good evening Antoine! Is this mail deliberately private or did you just forget to cc cdi-dev? In any case, feel free to forward my reply to the public list. You bring up a good point. Is JavaSE really a NEW mode? Or is it rather making official what was initially intended? This was looong before your time - this was back when the spec still was coined ?WebBeans?. Back then we originally wanted to make a DI for ALL Java. We even wanted to use the javax.inject package looong before there was even an atinject spec. But ?politics? forced us to add the JavaEE moniker. Ask Gavin or Pete over a Beer or a good Scotch if you like to hear those story :) I rather would _not_ make it a new mode but just stretch the officially supported usage of the CDI programming model 1:1 to JavaSE as well. That is what exists with DeltaSpike CdiCtrl and what user already use in a _broad_ way. People imo like to be able to re-use their CDI jars regardless whether it is SE or EE. If we define that the programming model is behaving different between SE and EE than I fear we might upset a lot or users. LieGrue, strub PS: trying to make it to Paris, but need to check with customers and probably have to move a few university lectures. So not sure. > Am 17.06.2015 um 18:28 schrieb Antoine Sabot-Durand < antoine at sabot-durand.net>: > > Mark, > > CDI for Java SE breaks the compatibility with the rest of CDI since it's a new feature. And again this will be discussed in CDI-530. I find more logical to propose a restraint feature in the EDR and open it later than the contrary. > Unless you think that CDI-530 is irrelevant and that context control in SE are useless... > > Antoine > > Le lun. 15 juin 2015 ? 23:05, Mark Struberg a ?crit : > Again: this breaks compat with the rest of CDI. > CDI defines that the request context is basically always on by default. > So we need this to be enabled by default as well imp. > > LieGrue, > Strub > > > Gesendet von Yahoo Mail f?r iPad > > Um 15.06.2015 16:26:12 schrieb Antoine Sabot-Durand:Hi all, > > > I added a Scopes and contexts in Java SE chapter to specify that only Application Context is active under Java SE. > This part will probably refine later thru CDI-530 > > Antoine > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150622/7988ff37/attachment.html From antoine at sabot-durand.net Mon Jun 22 05:26:55 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 22 Jun 2015 09:26:55 +0000 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> References: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> Message-ID: To synthetize: - Requestcontext will be active during async events - To be consistent, Requestcontext should be up in Java SE - Other HTTP context (eception application) will be inactive This will clarified later, with context control ticket CDI-530 I produce the EDR1 today and go back to you. Antoine Le sam. 20 juin 2015 ? 22:26, Mark Struberg a ?crit : > The Request context is not needed by the eventing system itself. But tons > of usercode around needs the requestcontext to be set up and active. This > is the default for almost every spec definedmanaged bean invocation. So we > should rather not change this for async events neither. If we change this > then you could not reuse lots of existing code in your new async observer. > > The lifecycle is rather easy to define: it starts shortly before the async > method (including interceptors/decorators/etc) gets started and ends > afterwards. > > LieGrue, > strub > > > Am 20.06.2015 um 00:51 schrieb Anatole Tresch : > > > > Hi all, > > > > for me the question is: do we need a RequestContext? We have the Event > payload, which is shared (and AFAIK also still mutable) and can be used to > represent the common context as well, for both synch or asynch event cases. > Adding a parallel "context" does not necessarily make things easier IMO, > because you have to exactly define what a request in that sense is, when > does it start, where does it end, how it is propagated/stacked etc. So my > question is: what is the benefit of defining the request scope additional > to the event payload already in place? > > > > Anatole > > > > > > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > Hi guys, > > > > We should finally decide how to manage normal scope context (other than > application context ) in SE and during Async Event for EDR1. > > > > Having only RequestContext active during async event as Martin suggest > in the PR makes sense and would be consistent with its behavior during > async EJB call. > > > > Mark asked twice to activate Request Context all the time in SE (making > it a new Application Context). I?m not found of it, but I?ml not the only > one to decide here. > > > > What is you feeling about this ? > > > > 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. > > > > > > > > -- > > Anatole Tresch > > Java Engineer & Architect, JSR Spec Lead > > Gl?rnischweg 10 > > CH - 8620 Wetzikon > > > > Switzerland, Europe Zurich, GMT+1 > > Twitter: @atsticks > > Blogs: http://javaremarkables.blogspot.ch/ > > Google: atsticks > > Mobile +41-76 344 62 79 > > _______________________________________________ > > 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/20150622/b1c47316/attachment-0001.html From jharting at redhat.com Mon Jun 22 06:48:43 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 22 Jun 2015 12:48:43 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> Message-ID: <5587E80B.2040405@redhat.com> What does "Requestcontext should be up in Java SE" mean exactly? On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: > To synthetize: > > - Requestcontext will be active during async events > - To be consistent, Requestcontext should be up in Java SE > - Other HTTP context (eception application) will be inactive > > This will clarified later, with context control ticket CDI-530 > > I produce the EDR1 today and go back to you. > > Antoine > > > Le sam. 20 juin 2015 ? 22:26, Mark Struberg > a ?crit : > > The Request context is not needed by the eventing system itself. > But tons of usercode around needs the requestcontext to be set up > and active. This is the default for almost every spec > definedmanaged bean invocation. So we should rather not change > this for async events neither. If we change this then you could > not reuse lots of existing code in your new async observer. > > The lifecycle is rather easy to define: it starts shortly before > the async method (including interceptors/decorators/etc) gets > started and ends afterwards. > > LieGrue, > strub > > > Am 20.06.2015 um 00:51 schrieb Anatole Tresch > >: > > > > Hi all, > > > > for me the question is: do we need a RequestContext? We have the > Event payload, which is shared (and AFAIK also still mutable) and > can be used to represent the common context as well, for both > synch or asynch event cases. Adding a parallel "context" does not > necessarily make things easier IMO, because you have to exactly > define what a request in that sense is, when does it start, where > does it end, how it is propagated/stacked etc. So my question is: > what is the benefit of defining the request scope additional to > the event payload already in place? > > > > Anatole > > > > > > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand > >: > > Hi guys, > > > > We should finally decide how to manage normal scope context > (other than application context ) in SE and during Async Event for > EDR1. > > > > Having only RequestContext active during async event as Martin > suggest in the PR makes sense and would be consistent with its > behavior during async EJB call. > > > > Mark asked twice to activate Request Context all the time in SE > (making it a new Application Context). I?m not found of it, but > I?ml not the only one to decide here. > > > > What is you feeling about this ? > > > > 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. > > > > > > > > -- > > Anatole Tresch > > Java Engineer & Architect, JSR Spec Lead > > Gl?rnischweg 10 > > CH - 8620 Wetzikon > > > > Switzerland, Europe Zurich, GMT+1 > > Twitter: @atsticks > > Blogs: http://javaremarkables.blogspot.ch/ > > Google: atsticks > > Mobile +41-76 344 62 79 > > _______________________________________________ > > 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/20150622/9b7e548f/attachment.html From antoine at sabot-durand.net Mon Jun 22 07:15:47 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 22 Jun 2015 11:15:47 +0000 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <5587E80B.2040405@redhat.com> References: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> <5587E80B.2040405@redhat.com> Message-ID: "Should be active". It was one of the subject of this email Le lun. 22 juin 2015 ? 12:48, Jozef Hartinger a ?crit : > What does "Requestcontext should be up in Java SE" mean exactly? > > > On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: > > To synthetize: > > - Requestcontext will be active during async events > - To be consistent, Requestcontext should be up in Java SE > - Other HTTP context (eception application) will be inactive > > This will clarified later, with context control ticket CDI-530 > > I produce the EDR1 today and go back to you. > > Antoine > > > Le sam. 20 juin 2015 ? 22:26, Mark Struberg a ?crit : > >> The Request context is not needed by the eventing system itself. But tons >> of usercode around needs the requestcontext to be set up and active. This >> is the default for almost every spec definedmanaged bean invocation. So we >> should rather not change this for async events neither. If we change this >> then you could not reuse lots of existing code in your new async observer. >> >> The lifecycle is rather easy to define: it starts shortly before the >> async method (including interceptors/decorators/etc) gets started and ends >> afterwards. >> >> LieGrue, >> strub >> >> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch : >> > >> > Hi all, >> > >> > for me the question is: do we need a RequestContext? We have the Event >> payload, which is shared (and AFAIK also still mutable) and can be used to >> represent the common context as well, for both synch or asynch event cases. >> Adding a parallel "context" does not necessarily make things easier IMO, >> because you have to exactly define what a request in that sense is, when >> does it start, where does it end, how it is propagated/stacked etc. So my >> question is: what is the benefit of defining the request scope additional >> to the event payload already in place? >> > >> > Anatole >> > >> > >> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand < >> antoine at sabot-durand.net>: >> > Hi guys, >> > >> > We should finally decide how to manage normal scope context (other than >> application context ) in SE and during Async Event for EDR1. >> > >> > Having only RequestContext active during async event as Martin suggest >> in the PR makes sense and would be consistent with its behavior during >> async EJB call. >> > >> > Mark asked twice to activate Request Context all the time in SE (making >> it a new Application Context). I?m not found of it, but I?ml not the only >> one to decide here. >> > >> > What is you feeling about this ? >> > >> > 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. >> > >> > >> > >> > -- >> > Anatole Tresch >> > Java Engineer & Architect, JSR Spec Lead >> > Gl?rnischweg 10 >> > CH - 8620 Wetzikon >> > >> > Switzerland, Europe Zurich, GMT+1 >> > Twitter: @atsticks >> > Blogs: http://javaremarkables.blogspot.ch/ >> > Google: atsticks >> > Mobile +41-76 344 62 79 >> > _______________________________________________ >> > 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 listcdi-dev at lists.jboss.orghttps://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/20150622/3e8f76e5/attachment-0001.html From mkouba at redhat.com Mon Jun 22 07:26:57 2015 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 22 Jun 2015 13:26:57 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> <5587E80B.2040405@redhat.com> Message-ID: <5587F101.6080108@redhat.com> Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a): > "Should be active". It was one of the subject of this email To make it clear - the request context will not be active all the time... I mean it makes sense to have it active during @PostConstruct invocation and async delivery. Or in case of an emebedded servlet container running as a part of a CDI SE app (something like DropWizard), during servlet requests processing. But not all the time like application context is... > Le lun. 22 juin 2015 ? 12:48, Jozef Hartinger > a ?crit : > > What does "Requestcontext should be up in Java SE" mean exactly? > > > On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: >> To synthetize: >> >> - Requestcontext will be active during async events >> - To be consistent, Requestcontext should be up in Java SE >> - Other HTTP context (eception application) will be inactive >> >> This will clarified later, with context control ticket CDI-530 >> >> I produce the EDR1 today and go back to you. >> >> Antoine >> >> >> Le sam. 20 juin 2015 ? 22:26, Mark Struberg > > a ?crit : >> >> The Request context is not needed by the eventing system >> itself. But tons of usercode around needs the requestcontext >> to be set up and active. This is the default for almost every >> spec definedmanaged bean invocation. So we should rather not >> change this for async events neither. If we change this then >> you could not reuse lots of existing code in your new async >> observer. >> >> The lifecycle is rather easy to define: it starts shortly >> before the async method (including >> interceptors/decorators/etc) gets started and ends afterwards. >> >> LieGrue, >> strub >> >> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch >> >: >> > >> > Hi all, >> > >> > for me the question is: do we need a RequestContext? We have >> the Event payload, which is shared (and AFAIK also still >> mutable) and can be used to represent the common context as >> well, for both synch or asynch event cases. Adding a parallel >> "context" does not necessarily make things easier IMO, because >> you have to exactly define what a request in that sense is, >> when does it start, where does it end, how it is >> propagated/stacked etc. So my question is: what is the benefit >> of defining the request scope additional to the event payload >> already in place? >> > >> > Anatole >> > >> > >> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand >> >: >> > Hi guys, >> > >> > We should finally decide how to manage normal scope context >> (other than application context ) in SE and during Async Event >> for EDR1. >> > >> > Having only RequestContext active during async event as >> Martin suggest in the PR makes sense and would be consistent >> with its behavior during async EJB call. >> > >> > Mark asked twice to activate Request Context all the time in >> SE (making it a new Application Context). I?m not found of it, >> but I?ml not the only one to decide here. >> > >> > What is you feeling about this ? >> > >> > 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. >> > >> > >> > >> > -- >> > Anatole Tresch >> > Java Engineer & Architect, JSR Spec Lead >> > Gl?rnischweg 10 >> > CH - 8620 Wetzikon >> > >> > Switzerland, Europe Zurich, GMT+1 >> > Twitter: @atsticks >> > Blogs: http://javaremarkables.blogspot.ch/ >> > Google: atsticks >> > Mobile +41-76 344 62 79 >> > _______________________________________________ >> > 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. > > > > _______________________________________________ > 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 pmuir at redhat.com Mon Jun 22 07:29:20 2015 From: pmuir at redhat.com (Pete Muir) Date: Mon, 22 Jun 2015 07:29:20 -0400 Subject: [cdi-dev] Added chapter for context in Java SE. In-Reply-To: References: <1434405910.78580.YahooMailIosMobile@web121604.mail.ne1.yahoo.com> <234754C2-CA8E-4921-866F-8711765D26EF@yahoo.de> Message-ID: I think regardless of the original intent of the authors, it?s very clear that 1.0 was targeted at Java EE, and includes a number of Java EE specific concepts in it?s core such as Conversation scope. I agree with Antoine that it?s clearer to specify a Java SE mode cleanly, that is a subset of the current features (mostly, those that make sense in Java SE). > On 22 Jun 2015, at 05:05, Antoine Sabot-Durand wrote: > > Discussion that was accidentally in private mode > > ---------- Forwarded message --------- > From: Mark Struberg > > Date: ven. 19 juin 2015 ? 18:17 > Subject: Re: [cdi-dev] Added chapter for context in Java SE. > To: Sabot-Durand Antoine > > > > Good evening Antoine! > > Is this mail deliberately private or did you just forget to cc cdi-dev? > In any case, feel free to forward my reply to the public list. > > > You bring up a good point. Is JavaSE really a NEW mode? > Or is it rather making official what was initially intended? This was looong before your time - this was back when the spec still was coined ?WebBeans?. Back then we originally wanted to make a DI for ALL Java. We even wanted to use the javax.inject package looong before there was even an atinject spec. But ?politics? forced us to add the JavaEE moniker. Ask Gavin or Pete over a Beer or a good Scotch if you like to hear those story :) > > I rather would _not_ make it a new mode but just stretch the officially supported usage of the CDI programming model 1:1 to JavaSE as well. That is what exists with DeltaSpike CdiCtrl and what user already use in a _broad_ way. People imo like to be able to re-use their CDI jars regardless whether it is SE or EE. If we define that the programming model is behaving different between SE and EE than I fear we might upset a lot or users. > > LieGrue, > strub > > PS: trying to make it to Paris, but need to check with customers and probably have to move a few university lectures. So not sure. > > > > Am 17.06.2015 um 18:28 schrieb Antoine Sabot-Durand >: > > > > Mark, > > > > CDI for Java SE breaks the compatibility with the rest of CDI since it's a new feature. And again this will be discussed in CDI-530. I find more logical to propose a restraint feature in the EDR and open it later than the contrary. > > Unless you think that CDI-530 is irrelevant and that context control in SE are useless... > > > > Antoine > > > > Le lun. 15 juin 2015 ? 23:05, Mark Struberg > a ?crit : > > Again: this breaks compat with the rest of CDI. > > CDI defines that the request context is basically always on by default. > > So we need this to be enabled by default as well imp. > > > > LieGrue, > > Strub > > > > > > Gesendet von Yahoo Mail f?r iPad > > > > Um 15.06.2015 16:26:12 schrieb Antoine Sabot-Durand:Hi all, > > > > > > I added a Scopes and contexts in Java SE chapter to specify that only Application Context is active under Java SE. > > This part will probably refine later thru CDI-530 > > > > 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/20150622/eb2d447c/attachment.html From antoine at sabot-durand.net Mon Jun 22 08:52:45 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 22 Jun 2015 12:52:45 +0000 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <5587F101.6080108@redhat.com> References: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> <5587E80B.2040405@redhat.com> <5587F101.6080108@redhat.com> Message-ID: Sorry Martin, I don't agree For me there are 2 scenarios for EDR1 : 1) Request context is never active in SE (the one I started with). 2) Request context is always active to provide a behavior similar than Java EE. Yes that probably mean that Request context will be like another application context. Having something in the middle, even if it could make sense at the sec level would be totality puzzling from users POV (why I have a request context in an async event and not in a sync ? why in a postconstruct and when I use my bean later). Again that wouldn't be the final behavior since we should work on CDI-530 but it could ease the work review of the community. Personally I think that we should go for 1) only if we are sure that CDI-530 won't give possibility to user to have an active request context which I hope won't be the case. Antoine Le lun. 22 juin 2015 ? 13:27, Martin Kouba a ?crit : > Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a): > > "Should be active". It was one of the subject of this email > > To make it clear - the request context will not be active all the > time... I mean it makes sense to have it active during @PostConstruct > invocation and async delivery. Or in case of an emebedded servlet > container running as a part of a CDI SE app (something like DropWizard), > during servlet requests processing. But not all the time like > application context is... > > > Le lun. 22 juin 2015 ? 12:48, Jozef Hartinger > > a ?crit : > > > > What does "Requestcontext should be up in Java SE" mean exactly? > > > > > > On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: > >> To synthetize: > >> > >> - Requestcontext will be active during async events > >> - To be consistent, Requestcontext should be up in Java SE > >> - Other HTTP context (eception application) will be inactive > >> > >> This will clarified later, with context control ticket CDI-530 > >> > >> I produce the EDR1 today and go back to you. > >> > >> Antoine > >> > >> > >> Le sam. 20 juin 2015 ? 22:26, Mark Struberg >> > a ?crit : > >> > >> The Request context is not needed by the eventing system > >> itself. But tons of usercode around needs the requestcontext > >> to be set up and active. This is the default for almost every > >> spec definedmanaged bean invocation. So we should rather not > >> change this for async events neither. If we change this then > >> you could not reuse lots of existing code in your new async > >> observer. > >> > >> The lifecycle is rather easy to define: it starts shortly > >> before the async method (including > >> interceptors/decorators/etc) gets started and ends afterwards. > >> > >> LieGrue, > >> strub > >> > >> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch > >> >: > >> > > >> > Hi all, > >> > > >> > for me the question is: do we need a RequestContext? We have > >> the Event payload, which is shared (and AFAIK also still > >> mutable) and can be used to represent the common context as > >> well, for both synch or asynch event cases. Adding a parallel > >> "context" does not necessarily make things easier IMO, because > >> you have to exactly define what a request in that sense is, > >> when does it start, where does it end, how it is > >> propagated/stacked etc. So my question is: what is the benefit > >> of defining the request scope additional to the event payload > >> already in place? > >> > > >> > Anatole > >> > > >> > > >> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand > >> >: > >> > Hi guys, > >> > > >> > We should finally decide how to manage normal scope context > >> (other than application context ) in SE and during Async Event > >> for EDR1. > >> > > >> > Having only RequestContext active during async event as > >> Martin suggest in the PR makes sense and would be consistent > >> with its behavior during async EJB call. > >> > > >> > Mark asked twice to activate Request Context all the time in > >> SE (making it a new Application Context). I?m not found of it, > >> but I?ml not the only one to decide here. > >> > > >> > What is you feeling about this ? > >> > > >> > 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. > >> > > >> > > >> > > >> > -- > >> > Anatole Tresch > >> > Java Engineer & Architect, JSR Spec Lead > >> > Gl?rnischweg 10 > >> > CH - 8620 Wetzikon > >> > > >> > Switzerland, Europe Zurich, GMT+1 > >> > Twitter: @atsticks > >> > Blogs: http://javaremarkables.blogspot.ch/ > >> > Google: atsticks > >> > Mobile +41-76 344 62 79 > >> > _______________________________________________ > >> > 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. > > > > > > > > _______________________________________________ > > 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/20150622/a556aa79/attachment-0001.html From antoine at sabot-durand.net Mon Jun 22 09:14:35 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 22 Jun 2015 15:14:35 +0200 Subject: [cdi-dev] Tomorrow's meeting Agenda Message-ID: Hi Guys, Tomorrow, we really need to close EDR1 a go for submission. It should be possible since our last discussion point is for Request Context behavior in SE. I?d like also to set the final date of our F2F meeting in Paris (18th or 25th September) Regarding the spec, I think that it would be nice to go for Quick Win tickets in Jira to have a rhythm change after the big features we worked on since octobre. It could be great if you could take one or two ticket that you think are quick wins ones and send me them to discuss during the meeting. What is a quick win ticket? A ticket that you think obvious and easy to solve regarding adoption of other EG members and way to solve it. We?ll check during the meeting if your perception of quick win is shared among us ;). So the agenda is: 1) Closing the EDR1 2) Closing discussion around F2F date 3) Discuss a first list of quick win tickets. Please send your wish list to me Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150622/e69585d9/attachment.bin From jharting at redhat.com Mon Jun 22 14:30:31 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 22 Jun 2015 20:30:31 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> <5587E80B.2040405@redhat.com> <5587F101.6080108@redhat.com> Message-ID: <55885447.8040803@redhat.com> Can you in detail describe the semantics of what you propose? So far I've found it quite vague. On 06/22/2015 02:52 PM, Antoine Sabot-Durand wrote: > Sorry Martin, I don't agree > > For me there are 2 scenarios for EDR1 : > > 1) Request context is never active in SE (the one I started with). > 2) Request context is always active to provide a behavior similar than > Java EE. Yes that probably mean that Request context will be like > another application context. > > Having something in the middle, even if it could make sense at the sec > level would be totality puzzling from users POV (why I have a request > context in an async event and not in a sync ? why in a postconstruct > and when I use my bean later). > > Again that wouldn't be the final behavior since we should work on > CDI-530 but it could ease the work review of the community. > > Personally I think that we should go for 1) only if we are sure that > CDI-530 won't give possibility to user to have an active request > context which I hope won't be the case. > > Antoine > > Le lun. 22 juin 2015 ? 13:27, Martin Kouba > a ?crit : > > Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a): > > "Should be active". It was one of the subject of this email > > To make it clear - the request context will not be active all the > time... I mean it makes sense to have it active during @PostConstruct > invocation and async delivery. Or in case of an emebedded servlet > container running as a part of a CDI SE app (something like > DropWizard), > during servlet requests processing. But not all the time like > application context is... > > > Le lun. 22 juin 2015 ? 12:48, Jozef Hartinger > > > >> a ?crit : > > > > What does "Requestcontext should be up in Java SE" mean exactly? > > > > > > On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: > >> To synthetize: > >> > >> - Requestcontext will be active during async events > >> - To be consistent, Requestcontext should be up in Java SE > >> - Other HTTP context (eception application) will be inactive > >> > >> This will clarified later, with context control ticket CDI-530 > >> > >> I produce the EDR1 today and go back to you. > >> > >> Antoine > >> > >> > >> Le sam. 20 juin 2015 ? 22:26, Mark Struberg > > >> >> a > ?crit : > >> > >> The Request context is not needed by the eventing system > >> itself. But tons of usercode around needs the > requestcontext > >> to be set up and active. This is the default for almost > every > >> spec definedmanaged bean invocation. So we should > rather not > >> change this for async events neither. If we change this > then > >> you could not reuse lots of existing code in your new async > >> observer. > >> > >> The lifecycle is rather easy to define: it starts shortly > >> before the async method (including > >> interceptors/decorators/etc) gets started and ends > afterwards. > >> > >> LieGrue, > >> strub > >> > >> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch > >> > >>: > >> > > >> > Hi all, > >> > > >> > for me the question is: do we need a RequestContext? > We have > >> the Event payload, which is shared (and AFAIK also still > >> mutable) and can be used to represent the common context as > >> well, for both synch or asynch event cases. Adding a > parallel > >> "context" does not necessarily make things easier IMO, > because > >> you have to exactly define what a request in that sense is, > >> when does it start, where does it end, how it is > >> propagated/stacked etc. So my question is: what is the > benefit > >> of defining the request scope additional to the event > payload > >> already in place? > >> > > >> > Anatole > >> > > >> > > >> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand > >> >>: > >> > Hi guys, > >> > > >> > We should finally decide how to manage normal scope > context > >> (other than application context ) in SE and during > Async Event > >> for EDR1. > >> > > >> > Having only RequestContext active during async event as > >> Martin suggest in the PR makes sense and would be > consistent > >> with its behavior during async EJB call. > >> > > >> > Mark asked twice to activate Request Context all the > time in > >> SE (making it a new Application Context). I?m not found > of it, > >> but I?ml not the only one to decide here. > >> > > >> > What is you feeling about this ? > >> > > >> > 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. > >> > > >> > > >> > > >> > -- > >> > Anatole Tresch > >> > Java Engineer & Architect, JSR Spec Lead > >> > Gl?rnischweg 10 > >> > CH - 8620 Wetzikon > >> > > >> > Switzerland, Europe Zurich, GMT+1 > >> > Twitter: @atsticks > >> > Blogs: http://javaremarkables.blogspot.ch/ > >> > Google: atsticks > >> > Mobile +41-76 344 62 79 > >> > _______________________________________________ > >> > 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. > > > > > > > > _______________________________________________ > > 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/20150622/123fb380/attachment-0001.html From struberg at yahoo.de Tue Jun 23 01:20:50 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 23 Jun 2015 07:20:50 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: References: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> <5587E80B.2040405@redhat.com> <5587F101.6080108@redhat.com> Message-ID: <9CFB3066-BDAE-474F-B4D5-DA799A4414C1@yahoo.de> +1. Imo this is the best we can do until we have a proper ContextControl in place. Otherwise many users would not be able to reuse existing libs in SE. LieGrue, strub > Am 22.06.2015 um 14:52 schrieb Antoine Sabot-Durand : > > Sorry Martin, I don't agree > > For me there are 2 scenarios for EDR1 : > > 1) Request context is never active in SE (the one I started with). > 2) Request context is always active to provide a behavior similar than Java EE. Yes that probably mean that Request context will be like another application context. > > Having something in the middle, even if it could make sense at the sec level would be totality puzzling from users POV (why I have a request context in an async event and not in a sync ? why in a postconstruct and when I use my bean later). > > Again that wouldn't be the final behavior since we should work on CDI-530 but it could ease the work review of the community. > > Personally I think that we should go for 1) only if we are sure that CDI-530 won't give possibility to user to have an active request context which I hope won't be the case. > > Antoine > > Le lun. 22 juin 2015 ? 13:27, Martin Kouba a ?crit : > Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a): > > "Should be active". It was one of the subject of this email > > To make it clear - the request context will not be active all the > time... I mean it makes sense to have it active during @PostConstruct > invocation and async delivery. Or in case of an emebedded servlet > container running as a part of a CDI SE app (something like DropWizard), > during servlet requests processing. But not all the time like > application context is... > > > Le lun. 22 juin 2015 ? 12:48, Jozef Hartinger > > a ?crit : > > > > What does "Requestcontext should be up in Java SE" mean exactly? > > > > > > On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: > >> To synthetize: > >> > >> - Requestcontext will be active during async events > >> - To be consistent, Requestcontext should be up in Java SE > >> - Other HTTP context (eception application) will be inactive > >> > >> This will clarified later, with context control ticket CDI-530 > >> > >> I produce the EDR1 today and go back to you. > >> > >> Antoine > >> > >> > >> Le sam. 20 juin 2015 ? 22:26, Mark Struberg >> > a ?crit : > >> > >> The Request context is not needed by the eventing system > >> itself. But tons of usercode around needs the requestcontext > >> to be set up and active. This is the default for almost every > >> spec definedmanaged bean invocation. So we should rather not > >> change this for async events neither. If we change this then > >> you could not reuse lots of existing code in your new async > >> observer. > >> > >> The lifecycle is rather easy to define: it starts shortly > >> before the async method (including > >> interceptors/decorators/etc) gets started and ends afterwards. > >> > >> LieGrue, > >> strub > >> > >> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch > >> >: > >> > > >> > Hi all, > >> > > >> > for me the question is: do we need a RequestContext? We have > >> the Event payload, which is shared (and AFAIK also still > >> mutable) and can be used to represent the common context as > >> well, for both synch or asynch event cases. Adding a parallel > >> "context" does not necessarily make things easier IMO, because > >> you have to exactly define what a request in that sense is, > >> when does it start, where does it end, how it is > >> propagated/stacked etc. So my question is: what is the benefit > >> of defining the request scope additional to the event payload > >> already in place? > >> > > >> > Anatole > >> > > >> > > >> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand > >> >: > >> > Hi guys, > >> > > >> > We should finally decide how to manage normal scope context > >> (other than application context ) in SE and during Async Event > >> for EDR1. > >> > > >> > Having only RequestContext active during async event as > >> Martin suggest in the PR makes sense and would be consistent > >> with its behavior during async EJB call. > >> > > >> > Mark asked twice to activate Request Context all the time in > >> SE (making it a new Application Context). I?m not found of it, > >> but I?ml not the only one to decide here. > >> > > >> > What is you feeling about this ? > >> > > >> > 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. > >> > > >> > > >> > > >> > -- > >> > Anatole Tresch > >> > Java Engineer & Architect, JSR Spec Lead > >> > Gl?rnischweg 10 > >> > CH - 8620 Wetzikon > >> > > >> > Switzerland, Europe Zurich, GMT+1 > >> > Twitter: @atsticks > >> > Blogs: http://javaremarkables.blogspot.ch/ > >> > Google: atsticks > >> > Mobile +41-76 344 62 79 > >> > _______________________________________________ > >> > 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. > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From rmannibucau at gmail.com Tue Jun 23 02:10:10 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 23 Jun 2015 08:10:10 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <9CFB3066-BDAE-474F-B4D5-DA799A4414C1@yahoo.de> References: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> <5587E80B.2040405@redhat.com> <5587F101.6080108@redhat.com> <9CFB3066-BDAE-474F-B4D5-DA799A4414C1@yahoo.de> Message-ID: Le 23 juin 2015 07:21, "Mark Struberg" a ?crit : > > +1. Imo this is the best we can do until we have a proper ContextControl in place. Otherwise many users would not be able to reuse existing libs in SE. > This is true but not sure I get what prevent us to add a ContextControl *now*? > LieGrue, > strub > > > Am 22.06.2015 um 14:52 schrieb Antoine Sabot-Durand < antoine at sabot-durand.net>: > > > > Sorry Martin, I don't agree > > > > For me there are 2 scenarios for EDR1 : > > > > 1) Request context is never active in SE (the one I started with). > > 2) Request context is always active to provide a behavior similar than Java EE. Yes that probably mean that Request context will be like another application context. > > > > Having something in the middle, even if it could make sense at the sec level would be totality puzzling from users POV (why I have a request context in an async event and not in a sync ? why in a postconstruct and when I use my bean later). > > > > Again that wouldn't be the final behavior since we should work on CDI-530 but it could ease the work review of the community. > > > > Personally I think that we should go for 1) only if we are sure that CDI-530 won't give possibility to user to have an active request context which I hope won't be the case. > > > > Antoine > > > > Le lun. 22 juin 2015 ? 13:27, Martin Kouba a ?crit : > > Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a): > > > "Should be active". It was one of the subject of this email > > > > To make it clear - the request context will not be active all the > > time... I mean it makes sense to have it active during @PostConstruct > > invocation and async delivery. Or in case of an emebedded servlet > > container running as a part of a CDI SE app (something like DropWizard), > > during servlet requests processing. But not all the time like > > application context is... > > > > > Le lun. 22 juin 2015 ? 12:48, Jozef Hartinger > > > a ?crit : > > > > > > What does "Requestcontext should be up in Java SE" mean exactly? > > > > > > > > > On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: > > >> To synthetize: > > >> > > >> - Requestcontext will be active during async events > > >> - To be consistent, Requestcontext should be up in Java SE > > >> - Other HTTP context (eception application) will be inactive > > >> > > >> This will clarified later, with context control ticket CDI-530 > > >> > > >> I produce the EDR1 today and go back to you. > > >> > > >> Antoine > > >> > > >> > > >> Le sam. 20 juin 2015 ? 22:26, Mark Struberg > >> > a ?crit : > > >> > > >> The Request context is not needed by the eventing system > > >> itself. But tons of usercode around needs the requestcontext > > >> to be set up and active. This is the default for almost every > > >> spec definedmanaged bean invocation. So we should rather not > > >> change this for async events neither. If we change this then > > >> you could not reuse lots of existing code in your new async > > >> observer. > > >> > > >> The lifecycle is rather easy to define: it starts shortly > > >> before the async method (including > > >> interceptors/decorators/etc) gets started and ends afterwards. > > >> > > >> LieGrue, > > >> strub > > >> > > >> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch > > >> >: > > >> > > > >> > Hi all, > > >> > > > >> > for me the question is: do we need a RequestContext? We have > > >> the Event payload, which is shared (and AFAIK also still > > >> mutable) and can be used to represent the common context as > > >> well, for both synch or asynch event cases. Adding a parallel > > >> "context" does not necessarily make things easier IMO, because > > >> you have to exactly define what a request in that sense is, > > >> when does it start, where does it end, how it is > > >> propagated/stacked etc. So my question is: what is the benefit > > >> of defining the request scope additional to the event payload > > >> already in place? > > >> > > > >> > Anatole > > >> > > > >> > > > >> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand > > >> >: > > >> > Hi guys, > > >> > > > >> > We should finally decide how to manage normal scope context > > >> (other than application context ) in SE and during Async Event > > >> for EDR1. > > >> > > > >> > Having only RequestContext active during async event as > > >> Martin suggest in the PR makes sense and would be consistent > > >> with its behavior during async EJB call. > > >> > > > >> > Mark asked twice to activate Request Context all the time in > > >> SE (making it a new Application Context). I?m not found of it, > > >> but I?ml not the only one to decide here. > > >> > > > >> > What is you feeling about this ? > > >> > > > >> > 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. > > >> > > > >> > > > >> > > > >> > -- > > >> > Anatole Tresch > > >> > Java Engineer & Architect, JSR Spec Lead > > >> > Gl?rnischweg 10 > > >> > CH - 8620 Wetzikon > > >> > > > >> > Switzerland, Europe Zurich, GMT+1 > > >> > Twitter: @atsticks > > >> > Blogs: http://javaremarkables.blogspot.ch/ > > >> > Google: atsticks > > >> > Mobile +41-76 344 62 79 > > >> > _______________________________________________ > > >> > 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. > > > > > > > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > _______________________________________________ > 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/20150623/4505f4ba/attachment-0001.html From jharting at redhat.com Tue Jun 23 02:28:46 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 23 Jun 2015 08:28:46 +0200 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <9CFB3066-BDAE-474F-B4D5-DA799A4414C1@yahoo.de> References: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> <5587E80B.2040405@redhat.com> <5587F101.6080108@redhat.com> <9CFB3066-BDAE-474F-B4D5-DA799A4414C1@yahoo.de> Message-ID: <5588FC9E.5010307@redhat.com> Given that we plan on adding ContextControl to the spec, which deals with this much better, why even bother figuring out and specifying a temporary solution for the meantime? On 06/23/2015 07:20 AM, Mark Struberg wrote: > +1. Imo this is the best we can do until we have a proper ContextControl in place. Otherwise many users would not be able to reuse existing libs in SE. > > LieGrue, > strub > >> Am 22.06.2015 um 14:52 schrieb Antoine Sabot-Durand : >> >> Sorry Martin, I don't agree >> >> For me there are 2 scenarios for EDR1 : >> >> 1) Request context is never active in SE (the one I started with). >> 2) Request context is always active to provide a behavior similar than Java EE. Yes that probably mean that Request context will be like another application context. >> >> Having something in the middle, even if it could make sense at the sec level would be totality puzzling from users POV (why I have a request context in an async event and not in a sync ? why in a postconstruct and when I use my bean later). >> >> Again that wouldn't be the final behavior since we should work on CDI-530 but it could ease the work review of the community. >> >> Personally I think that we should go for 1) only if we are sure that CDI-530 won't give possibility to user to have an active request context which I hope won't be the case. >> >> Antoine >> >> Le lun. 22 juin 2015 ? 13:27, Martin Kouba a ?crit : >> Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a): >>> "Should be active". It was one of the subject of this email >> To make it clear - the request context will not be active all the >> time... I mean it makes sense to have it active during @PostConstruct >> invocation and async delivery. Or in case of an emebedded servlet >> container running as a part of a CDI SE app (something like DropWizard), >> during servlet requests processing. But not all the time like >> application context is... >> >>> Le lun. 22 juin 2015 ? 12:48, Jozef Hartinger >> > a ?crit : >>> >>> What does "Requestcontext should be up in Java SE" mean exactly? >>> >>> >>> On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: >>>> To synthetize: >>>> >>>> - Requestcontext will be active during async events >>>> - To be consistent, Requestcontext should be up in Java SE >>>> - Other HTTP context (eception application) will be inactive >>>> >>>> This will clarified later, with context control ticket CDI-530 >>>> >>>> I produce the EDR1 today and go back to you. >>>> >>>> Antoine >>>> >>>> >>>> Le sam. 20 juin 2015 ? 22:26, Mark Struberg >>> > a ?crit : >>>> >>>> The Request context is not needed by the eventing system >>>> itself. But tons of usercode around needs the requestcontext >>>> to be set up and active. This is the default for almost every >>>> spec definedmanaged bean invocation. So we should rather not >>>> change this for async events neither. If we change this then >>>> you could not reuse lots of existing code in your new async >>>> observer. >>>> >>>> The lifecycle is rather easy to define: it starts shortly >>>> before the async method (including >>>> interceptors/decorators/etc) gets started and ends afterwards. >>>> >>>> LieGrue, >>>> strub >>>> >>>> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch >>>> >: >>>> > >>>> > Hi all, >>>> > >>>> > for me the question is: do we need a RequestContext? We have >>>> the Event payload, which is shared (and AFAIK also still >>>> mutable) and can be used to represent the common context as >>>> well, for both synch or asynch event cases. Adding a parallel >>>> "context" does not necessarily make things easier IMO, because >>>> you have to exactly define what a request in that sense is, >>>> when does it start, where does it end, how it is >>>> propagated/stacked etc. So my question is: what is the benefit >>>> of defining the request scope additional to the event payload >>>> already in place? >>>> > >>>> > Anatole >>>> > >>>> > >>>> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand >>>> >: >>>> > Hi guys, >>>> > >>>> > We should finally decide how to manage normal scope context >>>> (other than application context ) in SE and during Async Event >>>> for EDR1. >>>> > >>>> > Having only RequestContext active during async event as >>>> Martin suggest in the PR makes sense and would be consistent >>>> with its behavior during async EJB call. >>>> > >>>> > Mark asked twice to activate Request Context all the time in >>>> SE (making it a new Application Context). I?m not found of it, >>>> but I?ml not the only one to decide here. >>>> > >>>> > What is you feeling about this ? >>>> > >>>> > 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. >>>> > >>>> > >>>> > >>>> > -- >>>> > Anatole Tresch >>>> > Java Engineer & Architect, JSR Spec Lead >>>> > Gl?rnischweg 10 >>>> > CH - 8620 Wetzikon >>>> > >>>> > Switzerland, Europe Zurich, GMT+1 >>>> > Twitter: @atsticks >>>> > Blogs: http://javaremarkables.blogspot.ch/ >>>> > Google: atsticks >>>> > Mobile +41-76 344 62 79 >>>> > _______________________________________________ >>>> > 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. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From jharting at redhat.com Tue Jun 23 03:07:05 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 23 Jun 2015 09:07:05 +0200 Subject: [cdi-dev] Tomorrow's meeting Agenda In-Reply-To: References: Message-ID: <55890599.6030008@redhat.com> There are a lot of open CDI issues with the potential of being "quick wins". I list some of them here. This selection is within trivial to easy range. I may not be able to make it to the meeting this evening. https://issues.jboss.org/browse/CDI-536 https://issues.jboss.org/browse/CDI-534 https://issues.jboss.org/browse/CDI-531 https://issues.jboss.org/browse/CDI-528 https://issues.jboss.org/browse/CDI-524 https://issues.jboss.org/browse/CDI-519 https://issues.jboss.org/browse/CDI-508 https://issues.jboss.org/browse/CDI-506 https://issues.jboss.org/browse/CDI-502 https://issues.jboss.org/browse/CDI-500 https://issues.jboss.org/browse/CDI-495 https://issues.jboss.org/browse/CDI-494 https://issues.jboss.org/browse/CDI-490 https://issues.jboss.org/browse/CDI-488 https://issues.jboss.org/browse/CDI-482 On 06/22/2015 03:14 PM, Antoine Sabot-Durand wrote: > Hi Guys, > > > Tomorrow, we really need to close EDR1 a go for submission. It should be possible since our last discussion point is for Request Context behavior in SE. > > I?d like also to set the final date of our F2F meeting in Paris (18th or 25th September) > > Regarding the spec, I think that it would be nice to go for Quick Win tickets in Jira to have a rhythm change after the big features we worked on since octobre. > It could be great if you could take one or two ticket that you think are quick wins ones and send me them to discuss during the meeting. > > What is a quick win ticket? A ticket that you think obvious and easy to solve regarding adoption of other EG members and way to solve it. > > We?ll check during the meeting if your perception of quick win is shared among us ;). > > So the agenda is: > > 1) Closing the EDR1 > 2) Closing discussion around F2F date > 3) Discuss a first list of quick win tickets. Please send your wish list to me > > > 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/20150623/4944b7d0/attachment.html From antoine at sabot-durand.net Tue Jun 23 03:13:32 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 23 Jun 2015 07:13:32 +0000 Subject: [cdi-dev] Contexts behavior in SE and Async Event for EDR1 In-Reply-To: <5588FC9E.5010307@redhat.com> References: <6AEB224D-CFC7-4A29-9ED0-A76B4662AAFE@yahoo.de> <5587E80B.2040405@redhat.com> <5587F101.6080108@redhat.com> <9CFB3066-BDAE-474F-B4D5-DA799A4414C1@yahoo.de> <5588FC9E.5010307@redhat.com> Message-ID: If we plan to release an impl for edr1 we have to decide its behavior IMO. But I agree with you, it shouldn't take this time to do it. Le mar. 23 juin 2015 ? 08:28, Jozef Hartinger a ?crit : > Given that we plan on adding ContextControl to the spec, which deals > with this much better, why even bother figuring out and specifying a > temporary solution for the meantime? > > On 06/23/2015 07:20 AM, Mark Struberg wrote: > > +1. Imo this is the best we can do until we have a proper ContextControl > in place. Otherwise many users would not be able to reuse existing libs in > SE. > > > > LieGrue, > > strub > > > >> Am 22.06.2015 um 14:52 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > >> > >> Sorry Martin, I don't agree > >> > >> For me there are 2 scenarios for EDR1 : > >> > >> 1) Request context is never active in SE (the one I started with). > >> 2) Request context is always active to provide a behavior similar than > Java EE. Yes that probably mean that Request context will be like another > application context. > >> > >> Having something in the middle, even if it could make sense at the sec > level would be totality puzzling from users POV (why I have a request > context in an async event and not in a sync ? why in a postconstruct and > when I use my bean later). > >> > >> Again that wouldn't be the final behavior since we should work on > CDI-530 but it could ease the work review of the community. > >> > >> Personally I think that we should go for 1) only if we are sure that > CDI-530 won't give possibility to user to have an active request context > which I hope won't be the case. > >> > >> Antoine > >> > >> Le lun. 22 juin 2015 ? 13:27, Martin Kouba a ?crit > : > >> Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a): > >>> "Should be active". It was one of the subject of this email > >> To make it clear - the request context will not be active all the > >> time... I mean it makes sense to have it active during @PostConstruct > >> invocation and async delivery. Or in case of an emebedded servlet > >> container running as a part of a CDI SE app (something like DropWizard), > >> during servlet requests processing. But not all the time like > >> application context is... > >> > >>> Le lun. 22 juin 2015 ? 12:48, Jozef Hartinger >>> > a ?crit : > >>> > >>> What does "Requestcontext should be up in Java SE" mean exactly? > >>> > >>> > >>> On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: > >>>> To synthetize: > >>>> > >>>> - Requestcontext will be active during async events > >>>> - To be consistent, Requestcontext should be up in Java SE > >>>> - Other HTTP context (eception application) will be inactive > >>>> > >>>> This will clarified later, with context control ticket CDI-530 > >>>> > >>>> I produce the EDR1 today and go back to you. > >>>> > >>>> Antoine > >>>> > >>>> > >>>> Le sam. 20 juin 2015 ? 22:26, Mark Struberg >>>> > a ?crit : > >>>> > >>>> The Request context is not needed by the eventing system > >>>> itself. But tons of usercode around needs the requestcontext > >>>> to be set up and active. This is the default for almost every > >>>> spec definedmanaged bean invocation. So we should rather not > >>>> change this for async events neither. If we change this then > >>>> you could not reuse lots of existing code in your new async > >>>> observer. > >>>> > >>>> The lifecycle is rather easy to define: it starts shortly > >>>> before the async method (including > >>>> interceptors/decorators/etc) gets started and ends > afterwards. > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>>> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch > >>>> >: > >>>> > > >>>> > Hi all, > >>>> > > >>>> > for me the question is: do we need a RequestContext? We > have > >>>> the Event payload, which is shared (and AFAIK also still > >>>> mutable) and can be used to represent the common context as > >>>> well, for both synch or asynch event cases. Adding a parallel > >>>> "context" does not necessarily make things easier IMO, > because > >>>> you have to exactly define what a request in that sense is, > >>>> when does it start, where does it end, how it is > >>>> propagated/stacked etc. So my question is: what is the > benefit > >>>> of defining the request scope additional to the event payload > >>>> already in place? > >>>> > > >>>> > Anatole > >>>> > > >>>> > > >>>> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand > >>>> >>: > >>>> > Hi guys, > >>>> > > >>>> > We should finally decide how to manage normal scope context > >>>> (other than application context ) in SE and during Async > Event > >>>> for EDR1. > >>>> > > >>>> > Having only RequestContext active during async event as > >>>> Martin suggest in the PR makes sense and would be consistent > >>>> with its behavior during async EJB call. > >>>> > > >>>> > Mark asked twice to activate Request Context all the time > in > >>>> SE (making it a new Application Context). I?m not found of > it, > >>>> but I?ml not the only one to decide here. > >>>> > > >>>> > What is you feeling about this ? > >>>> > > >>>> > 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. > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > Anatole Tresch > >>>> > Java Engineer & Architect, JSR Spec Lead > >>>> > Gl?rnischweg 10 > >>>> > CH - 8620 Wetzikon > >>>> > > >>>> > Switzerland, Europe Zurich, GMT+1 > >>>> > Twitter: @atsticks > >>>> > Blogs: http://javaremarkables.blogspot.ch/ > >>>> > Google: atsticks > >>>> > Mobile +41-76 344 62 79 > >>>> > _______________________________________________ > >>>> > 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. > >>> > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> cdi-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >>> > >> -- > >> Martin Kouba > >> Software Engineer > >> Red Hat, Czech Republic > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150623/48643ff0/attachment-0001.html From antoine at sabot-durand.net Tue Jun 23 05:09:48 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 23 Jun 2015 09:09:48 +0000 Subject: [cdi-dev] Tomorrow's meeting Agenda In-Reply-To: <55890599.6030008@redhat.com> References: <55890599.6030008@redhat.com> Message-ID: Thanks Jozef, Yes, most of these are typos or easy clarification to do. Antoine Le mar. 23 juin 2015 ? 09:07, Jozef Hartinger a ?crit : > There are a lot of open CDI issues with the potential of being "quick > wins". I list some of them here. This selection is within trivial to easy > range. I may not be able to make it to the meeting this evening. > > https://issues.jboss.org/browse/CDI-536 > https://issues.jboss.org/browse/CDI-534 > https://issues.jboss.org/browse/CDI-531 > https://issues.jboss.org/browse/CDI-528 > https://issues.jboss.org/browse/CDI-524 > https://issues.jboss.org/browse/CDI-519 > https://issues.jboss.org/browse/CDI-508 > https://issues.jboss.org/browse/CDI-506 > https://issues.jboss.org/browse/CDI-502 > https://issues.jboss.org/browse/CDI-500 > https://issues.jboss.org/browse/CDI-495 > https://issues.jboss.org/browse/CDI-494 > https://issues.jboss.org/browse/CDI-490 > https://issues.jboss.org/browse/CDI-488 > https://issues.jboss.org/browse/CDI-482 > > > On 06/22/2015 03:14 PM, Antoine Sabot-Durand wrote: > > Hi Guys, > > > Tomorrow, we really need to close EDR1 a go for submission. It should be possible since our last discussion point is for Request Context behavior in SE. > > I?d like also to set the final date of our F2F meeting in Paris (18th or 25th September) > > Regarding the spec, I think that it would be nice to go for Quick Win tickets in Jira to have a rhythm change after the big features we worked on since octobre. > It could be great if you could take one or two ticket that you think are quick wins ones and send me them to discuss during the meeting. > > What is a quick win ticket? A ticket that you think obvious and easy to solve regarding adoption of other EG members and way to solve it. > > We?ll check during the meeting if your perception of quick win is shared among us ;). > > So the agenda is: > > 1) Closing the EDR1 > 2) Closing discussion around F2F date > 3) Discuss a first list of quick win tickets. Please send your wish list to me > > > Antoine > > > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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/20150623/decb3c6b/attachment.html From antoine at sabot-durand.net Tue Jun 23 05:36:58 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 23 Jun 2015 11:36:58 +0200 Subject: [cdi-dev] EDR1, proposed draft Message-ID: <55551A94-C376-42B4-8322-1F185B44F5A7@sabot-durand.net> Hi guys, I generated the EDR1 document for a final review feedback before making it official: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html Last changes concerns Request and Application context in SE which should be temporarily specified for EDR1 (CDI-530 will bring the true spec to them): https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#request_context_se They are both active during all method invocation and are destroyed when container is shut down. The difference is that application context is hared between all methods invocation Don?t miss the last changes in Events chapter and more precisely in observer method invocation context: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#observer_method_invocation_context Remember that EDR1 is not a final proposition and that it could be changed (even during its review). This said if you find errors or if you have serious issue with the proposal, your feedback is welcome. If some of you have the courage to do a review of API split, it would be great. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150623/09ee1015/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150623/09ee1015/attachment.bin From jharting at redhat.com Tue Jun 23 06:03:07 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 23 Jun 2015 12:03:07 +0200 Subject: [cdi-dev] EDR1, proposed draft In-Reply-To: <55551A94-C376-42B4-8322-1F185B44F5A7@sabot-durand.net> References: <55551A94-C376-42B4-8322-1F185B44F5A7@sabot-durand.net> Message-ID: <55892EDB.5020605@redhat.com> On 06/23/2015 11:36 AM, Antoine Sabot-Durand wrote: > Last changes concerns Request and Application context in SE which > should be temporarily specified for EDR1 (CDI-530 will bring the true > spec to them): > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#request_context_se Is there a diff/pull request anywhere on github? > > They are both active during all method invocation and are destroyed > when container is shut down. The difference is that application > context is hared between all methods invocation So request context isn't shared between method invocations? I really cannot tell from the proposal as the wording is very vague. Has any thought been given on how this is supposed to be implemented? From antoine at sabot-durand.net Tue Jun 23 06:07:22 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 23 Jun 2015 12:07:22 +0200 Subject: [cdi-dev] EDR1, proposed draft In-Reply-To: <55892EDB.5020605@redhat.com> References: <55551A94-C376-42B4-8322-1F185B44F5A7@sabot-durand.net> <55892EDB.5020605@redhat.com> Message-ID: <16FA04A0-4F83-4CDD-BB17-1E0F119B5C86@sabot-durand.net> Yes, you?ll get everything is PR 251 that I rebased to have all the modifications at hand: https://github.com/cdi-spec/cdi/pull/251 > Le 23 juin 2015 ? 12:03, Jozef Hartinger a ?crit : > > On 06/23/2015 11:36 AM, Antoine Sabot-Durand wrote: >> Last changes concerns Request and Application context in SE which should be temporarily specified for EDR1 (CDI-530 will bring the true spec to them): >> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#request_context_se > Is there a diff/pull request anywhere on github? >> >> They are both active during all method invocation and are destroyed when container is shut down. The difference is that application context is hared between all methods invocation > > So request context isn't shared between method invocations? I really cannot tell from the proposal as the wording is very vague. Has any thought been given on how this is supposed to be implemented? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150623/936ad48e/attachment.bin From antoine at sabot-durand.net Tue Jun 23 06:11:51 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 23 Jun 2015 12:11:51 +0200 Subject: [cdi-dev] EDR1, proposed draft In-Reply-To: <16FA04A0-4F83-4CDD-BB17-1E0F119B5C86@sabot-durand.net> References: <55551A94-C376-42B4-8322-1F185B44F5A7@sabot-durand.net> <55892EDB.5020605@redhat.com> <16FA04A0-4F83-4CDD-BB17-1E0F119B5C86@sabot-durand.net> Message-ID: <80984AAC-1752-43ED-A611-FE85497A714D@sabot-durand.net> and if you want to only focus on async event PR 250 has also been updated, but there won?t be modification linked to contexts and observer invocation context in it. Quite hard to live with API split PR and others ;. Antoine > Le 23 juin 2015 ? 12:07, Antoine Sabot-Durand a ?crit : > > Yes, you?ll get everything is PR 251 that I rebased to have all the modifications at hand: > > https://github.com/cdi-spec/cdi/pull/251 > > >> Le 23 juin 2015 ? 12:03, Jozef Hartinger a ?crit : >> >> On 06/23/2015 11:36 AM, Antoine Sabot-Durand wrote: >>> Last changes concerns Request and Application context in SE which should be temporarily specified for EDR1 (CDI-530 will bring the true spec to them): >>> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#request_context_se >> Is there a diff/pull request anywhere on github? >>> >>> They are both active during all method invocation and are destroyed when container is shut down. The difference is that application context is hared between all methods invocation >> >> So request context isn't shared between method invocations? I really cannot tell from the proposal as the wording is very vague. Has any thought been given on how this is supposed to be implemented? >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150623/c199c3a6/attachment.bin From issues at jboss.org Tue Jun 23 09:16:01 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Tue, 23 Jun 2015 09:16:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-537) Event firing on JavaEE component classes- JPA entity listener In-Reply-To: References: Message-ID: Emily Jiang created CDI-537: ------------------------------- Summary: Event firing on JavaEE component classes- JPA entity listener Key: CDI-537 URL: https://issues.jboss.org/browse/CDI-537 Project: CDI Specification Issues Issue Type: Feature Request Components: Java EE integration Reporter: Emily Jiang -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 09:22:01 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Tue, 23 Jun 2015 09:22:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-537) Event firing on JavaEE component classes- JPA entity listener In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emily Jiang updated CDI-537: ---------------------------- Affects Version/s: 1.2.Final Description: In CDI 1.2 spec 11.5.7. ProcessInjectionPoint event The container must fire an event for every injection point of every Java EE component class supporting injection that may be instantiated by the container at runtime, including every managed bean declared using @ManagedBean, EJB session or message-driven bean, bean, interceptor or decorator. The JavaEE component classes are mentioned in JavaEE platform EE.5-1, which includes servlets, servlet filters, entity listeners etc. My concern is about entity listeners in JPA. Eclipse link has done all the injection for entity listeners. It does not fire the event, @See createEntityListenerAndInjectDependancies(...) JPA spec section 3.5.1 does not mention this event requirement. How can the eclipse cdi implementation satisfy the CDI spec? [1] http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS] I had an initial discussion with Jozef. Jozef wrote: " Doing this using purely CDI APIs can be a bit tricky. One option that will most likely work is to combine BeanManager.resolveObserverMethods() method with a custom implementation of ProcessInjectionTarget interface. That way you can resolve the matching observer methods and then call their notify() method to deliver the event. Exception handling needs to be implemented to match the spec. We should update the spec to define a more direct route and for the JPA spec to mention this requirement." My response: "+1 on revisiting this on the CDI spec. I think adding an additional method on the BeanManager api, e.g. fireProcessInjectionTarget would be good. Effectively, it is to promote this very method on WeldManager to BeanManager." > Event firing on JavaEE component classes- JPA entity listener > ------------------------------------------------------------- > > Key: CDI-537 > URL: https://issues.jboss.org/browse/CDI-537 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.2.Final > Reporter: Emily Jiang > > In CDI 1.2 spec > 11.5.7. ProcessInjectionPoint event > The container must fire an event for every injection point of every Java EE component class > supporting injection that may be instantiated by the container at runtime, including every managed bean declared using @ManagedBean, EJB session or message-driven bean, bean, interceptor or decorator. > The JavaEE component classes are mentioned in JavaEE platform EE.5-1, which includes servlets, servlet filters, entity listeners etc. > My concern is about entity listeners in JPA. Eclipse link has done all the injection for entity listeners. It does not fire the event, @See createEntityListenerAndInjectDependancies(...) > JPA spec section 3.5.1 does not mention this event requirement. How can the eclipse cdi implementation satisfy the CDI spec? > [1] http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS] > I had an initial discussion with Jozef. > Jozef wrote: " > Doing this using purely CDI APIs can be a bit tricky. One option that will most likely work is to combine BeanManager.resolveObserverMethods() method with a custom implementation of ProcessInjectionTarget interface. That way you can resolve the matching observer methods and then call their notify() method to deliver the event. Exception handling needs to be implemented to match the spec. > We should update the spec to define a more direct route and for the JPA spec to mention this requirement." > My response: > "+1 on revisiting this on the CDI spec. I think adding an additional method on the BeanManager api, e.g. fireProcessInjectionTarget would be good. Effectively, it is to promote this very method on WeldManager to BeanManager." -- This message was sent by Atlassian JIRA (v6.3.15#6346) From struberg at yahoo.de Tue Jun 23 11:11:20 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 23 Jun 2015 17:11:20 +0200 Subject: [cdi-dev] Tomorrow's meeting Agenda In-Reply-To: References: <55890599.6030008@redhat.com> Message-ID: <4E5151B6-F121-44A5-9F7B-A7F16271232A@yahoo.de> I?m on the train to a ee lecture in M?nchen right now. Thus not sure how good the connection on the train will be. LieGrue, strub > Am 23.06.2015 um 11:09 schrieb Antoine Sabot-Durand : > > Thanks Jozef, > > Yes, most of these are typos or easy clarification to do. > > Antoine > > Le mar. 23 juin 2015 ? 09:07, Jozef Hartinger a ?crit : > There are a lot of open CDI issues with the potential of being "quick wins". I list some of them here. This selection is within trivial to easy range. I may not be able to make it to the meeting this evening. > > https://issues.jboss.org/browse/CDI-536 > https://issues.jboss.org/browse/CDI-534 > https://issues.jboss.org/browse/CDI-531 > https://issues.jboss.org/browse/CDI-528 > https://issues.jboss.org/browse/CDI-524 > https://issues.jboss.org/browse/CDI-519 > https://issues.jboss.org/browse/CDI-508 > https://issues.jboss.org/browse/CDI-506 > https://issues.jboss.org/browse/CDI-502 > https://issues.jboss.org/browse/CDI-500 > https://issues.jboss.org/browse/CDI-495 > https://issues.jboss.org/browse/CDI-494 > https://issues.jboss.org/browse/CDI-490 > https://issues.jboss.org/browse/CDI-488 > https://issues.jboss.org/browse/CDI-482 > > > On 06/22/2015 03:14 PM, Antoine Sabot-Durand wrote: >> Hi Guys, >> >> >> Tomorrow, we really need to close EDR1 a go for submission. It should be possible since our last discussion point is for Request Context behavior in SE. >> >> I?d like also to set the final date of our F2F meeting in Paris (18th or 25th September) >> >> Regarding the spec, I think that it would be nice to go for Quick Win tickets in Jira to have a rhythm change after the big features we worked on since octobre. >> It could be great if you could take one or two ticket that you think are quick wins ones and send me them to discuss during the meeting. >> >> What is a quick win ticket? A ticket that you think obvious and easy to solve regarding adoption of other EG members and way to solve it. >> >> We?ll check during the meeting if your perception of quick win is shared among us ;). >> >> So the agenda is: >> >> 1) Closing the EDR1 >> 2) Closing discussion around F2F date >> 3) Discuss a first list of quick win tickets. Please send your wish list to me >> >> >> Antoine >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From struberg at yahoo.de Wed Jun 24 03:46:15 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 24 Jun 2015 09:46:15 +0200 Subject: [cdi-dev] @ObservesAsync missing in cdi-spec api? Message-ID: <17D93B8C-4614-4158-BD53-DA7D0F699B48@yahoo.de> Hi folks! The @ObeservesAsync is mentioned in the new CDI-2.0-EDR1 but I cannot find it in the api. Anything I?m missing. Or am I looking at the wrong code? https://github.com/cdi-spec/cdi/tree/2.0-EDR1/api/src/main/java/javax/enterprise/event LieGrue, strub From antoine at sabot-durand.net Wed Jun 24 03:53:12 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 24 Jun 2015 07:53:12 +0000 Subject: [cdi-dev] @ObservesAsync missing in cdi-spec api? In-Reply-To: <17D93B8C-4614-4158-BD53-DA7D0F699B48@yahoo.de> References: <17D93B8C-4614-4158-BD53-DA7D0F699B48@yahoo.de> Message-ID: Looking a the Wong branch. Try CDI-160 Le mer. 24 juin 2015 ? 09:49, Mark Struberg a ?crit : > Hi folks! > The @ObeservesAsync is mentioned in the new CDI-2.0-EDR1 but I cannot find > it in the api. Anything I?m missing. Or am I looking at the wrong code? > > > https://github.com/cdi-spec/cdi/tree/2.0-EDR1/api/src/main/java/javax/enterprise/event > > LieGrue, > strub > _______________________________________________ > 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/20150624/52814e6f/attachment.html From struberg at yahoo.de Wed Jun 24 03:55:34 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 24 Jun 2015 09:55:34 +0200 Subject: [cdi-dev] @ObservesAsync missing in cdi-spec api? In-Reply-To: References: <17D93B8C-4614-4158-BD53-DA7D0F699B48@yahoo.de> Message-ID: <3E2F98AD-31C9-4BD7-9A36-2A3D04BF48EF@yahoo.de> But this branch doesn?t exist in https://github.com/cdi-spec/cdi , isn?t? LieGrue, strub > Am 24.06.2015 um 09:53 schrieb Antoine Sabot-Durand : > > Looking a the Wong branch. Try CDI-160 > Le mer. 24 juin 2015 ? 09:49, Mark Struberg a ?crit : > Hi folks! > The @ObeservesAsync is mentioned in the new CDI-2.0-EDR1 but I cannot find it in the api. Anything I?m missing. Or am I looking at the wrong code? > > https://github.com/cdi-spec/cdi/tree/2.0-EDR1/api/src/main/java/javax/enterprise/event > > LieGrue, > strub > _______________________________________________ > 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 jharting at redhat.com Wed Jun 24 04:50:54 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 24 Jun 2015 10:50:54 +0200 Subject: [cdi-dev] On @RequestScoped hack Message-ID: <558A6F6E.5070901@redhat.com> Hi all, unfortunately I did not make it to the meeting yesterday. After reading the transcript I found out that the @RequestScoped hack is still being added to the EDR. What do I mean by "@RequestScoped hack"? By that I am referring to the following part of the spec: " In Java SE: The request scope is active during any method invocation. The request context is destroyed when the container is shut down. " This is vague, almost undefined and not correctly implementable. Most importantly, everyone seems to agree that it would be a bad idea for this to end up in the final spec. Instead, it is supposed to be replaced entirely by ContextControl API (https://issues.jboss.org/browse/CDI-530) post EDR1. Yet, we are adding this hack to EDR1 for the meantime. Why? The only argument to back this was "supporting existing libraries and applications". That seems reasonable, doesn't it? Well, no. Antoine took a detailed look into probably the most prominent CDI library - DeltaSpike. Yes, you can find @RequestScoped beans in DeltaSpike. You can find Servlet artifact producers, JSF view root and navigation handlers, etc. And that's it. Nothing one could really use outside of the EE stack. That's not a coincidence. When a user marks a bean as @RequestScoped we can assume they do it for a reason. The reason most likely would be to scope the state per "task" (often HTTP request processing) and isolate the state from the state of other tasks. That's very different from the @Singleton-like behavior that the @RequestScoped hack adds. Therefore, even if a library exists that relies on @RequestScoped it is not going to work properly anyway. The @RequestScoped hack just suppresses a fast failure and trades it for weird state inconsistencies later. Another part of the argument is "existing applications". More specifically: "struberg: well, I have a few customers with 10k++ classes. And some core components use it heavily" Does the @RequestScoped hack really address customers' problem? Remember that the @RequestScoped hack is planned to be temporary and replaced with proper context control post EDR1. Are those customers planning to migrate to EDR1 implementation (Weld Alpha probably) before the spec gets context control? Do they expect to take their "10k++ class" Java EE applications, throw the EE container out entirely and run the *unmodified* application in a plain Java SE environment with CDI SE? Will their apps work even if their @RequestScoped beans start behaving like singletons? Probably not, right? And then we have early adopters of CDI 2.0. Why should they be exposed to magical hacks that we know are going to disappear later? And let's not forget that: * CDI implementations already have their own APIs for controlling contexts that can be used if needed * A CDI implementation may add such hack by itself - no need to have it the spec temporarily Therefore, I cannot see a single reason for polluting the spec with temporary hacks. Jozef From struberg at yahoo.de Wed Jun 24 05:10:53 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 24 Jun 2015 11:10:53 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: <558A6F6E.5070901@redhat.com> References: <558A6F6E.5070901@redhat.com> Message-ID: Jozef, read the rest of the meeting minutes as well. Throne and I enlisted dozen of REAL use cases where it is needed. > Does the @RequestScoped hack really address customers' problem? Yes it does. In the final spec a programmer could programmatically enable the request context and ends it again IF he needs it. But today he cannot. And many users code really needs it. So the only thing we can do TODAY is to enable it by default. > * A CDI implementation may add such hack by itself - no need to have it > the spec temporarily Well that is an option but the users then cannot rely on it. And no, it is perfectly implementable as it is worded right now. LieGrue, strub > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger : > > Hi all, > > unfortunately I did not make it to the meeting yesterday. After reading > the transcript I found out that the @RequestScoped hack is still being > added to the EDR. What do I mean by "@RequestScoped hack"? > By that I am referring to the following part of the spec: > > " > In Java SE: > The request scope is active during any method invocation. > The request context is destroyed when the container is shut down. > " > > This is vague, almost undefined and not correctly implementable. Most > importantly, everyone seems to agree that it would be a bad idea for > this to end up in the final spec. Instead, it is supposed to be replaced > entirely by ContextControl API (https://issues.jboss.org/browse/CDI-530) > post EDR1. > > Yet, we are adding this hack to EDR1 for the meantime. Why? The only > argument to back this was "supporting existing libraries and applications". > > That seems reasonable, doesn't it? Well, no. Antoine took a detailed > look into probably the most prominent CDI library - DeltaSpike. Yes, you > can find @RequestScoped beans in DeltaSpike. You can find Servlet > artifact producers, JSF view root and navigation handlers, etc. And > that's it. Nothing one could really use outside of the EE stack. > > That's not a coincidence. When a user marks a bean as @RequestScoped we > can assume they do it for a reason. The reason most likely would be to > scope the state per "task" (often HTTP request processing) and isolate > the state from the state of other tasks. That's very different from the > @Singleton-like behavior that the @RequestScoped hack adds. Therefore, > even if a library exists that relies on @RequestScoped it is not going > to work properly anyway. The @RequestScoped hack just suppresses a fast > failure and trades it for weird state inconsistencies later. > > Another part of the argument is "existing applications". More specifically: > > "struberg: well, I have a few customers with 10k++ classes. And some > core components use it heavily" > > Does the @RequestScoped hack really address customers' problem? Remember > that the @RequestScoped hack is planned to be temporary and replaced > with proper context control post EDR1. > Are those customers planning to migrate to EDR1 implementation (Weld > Alpha probably) before the spec gets context control? Do they expect to > take their "10k++ class" Java EE applications, throw the EE container > out entirely and run the *unmodified* application in a plain Java SE > environment with CDI SE? Will their apps work even if their > @RequestScoped beans start behaving like singletons? > Probably not, right? > > And then we have early adopters of CDI 2.0. Why should they be exposed > to magical hacks that we know are going to disappear later? > > And let's not forget that: > * CDI implementations already have their own APIs for controlling > contexts that can be used if needed > * A CDI implementation may add such hack by itself - no need to have it > the spec temporarily > > Therefore, I cannot see a single reason for polluting the spec with > temporary hacks. > > Jozef > _______________________________________________ > 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 jharting at redhat.com Wed Jun 24 05:25:45 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 24 Jun 2015 11:25:45 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: <558A7799.3020906@redhat.com> On 06/24/2015 11:10 AM, Mark Struberg wrote: >> Does the @RequestScoped hack really address customers' problem? > Yes it does. In the final spec a programmer could programmatically enable the request context and ends it again IF he needs it. But today he cannot. And many users code really needs it. So the only thing we can do TODAY is to enable it by default. Are those customers planning to migrate to EDR1 implementation (Weld Alpha probably) before the spec gets context control? Do they expect to take their "10k++ class" Java EE applications, throw the EE container out entirely and run the *unmodified* application in a plain Java SE environment with CDI SE? Will their apps work even if their @RequestScoped beans start behaving like singletons? > >> * A CDI implementation may add such hack by itself - no need to have it >> the spec temporarily > Well that is an option but the users then cannot rely on it. We are talking about an early draft. Users cannot and shouldn't really rely on anything in the draft as chances are it is going to change. From rmannibucau at gmail.com Wed Jun 24 05:29:00 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 24 Jun 2015 11:29:00 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: <558A7799.3020906@redhat.com> References: <558A6F6E.5070901@redhat.com> <558A7799.3020906@redhat.com> Message-ID: Agree with Jozef. This looks like we are asking users to review something we know we'll not keep. Sounds very wrong even if the motivation is "no time to do it right before the release". We can just mention we'll be able to handle req scope manually but that it is not yet final/done. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-06-24 11:25 GMT+02:00 Jozef Hartinger : > On 06/24/2015 11:10 AM, Mark Struberg wrote: > >> Does the @RequestScoped hack really address customers' problem? > > Yes it does. In the final spec a programmer could programmatically > enable the request context and ends it again IF he needs it. But today he > cannot. And many users code really needs it. So the only thing we can do > TODAY is to enable it by default. > Are those customers planning to migrate to EDR1 implementation (Weld > Alpha probably) before the spec gets context control? Do they expect to > take their "10k++ class" Java EE applications, throw the EE container > out entirely and run the *unmodified* application in a plain Java SE > environment with CDI SE? Will their apps work even if their > @RequestScoped beans start behaving like singletons? > > > >> * A CDI implementation may add such hack by itself - no need to have it > >> the spec temporarily > > Well that is an option but the users then cannot rely on it. > We are talking about an early draft. Users cannot and shouldn't really > rely on anything in the draft as chances are it is going to change. > _______________________________________________ > 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/20150624/b5b697fd/attachment.html From antoine at sabot-durand.net Wed Jun 24 05:31:11 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 24 Jun 2015 09:31:11 +0000 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: Jozef, I think I really got your disagreement on that point. You repeated it many times. My point and the question I keep asking to you is "what is your suggestion?". Personally I see 5 solutions here: 1) Don't do anything since there's no alternative solution 2) Change the wording regarding request scope activation in something like "is active from the initialization of the container until its shutdown" 3) Give the same behavior than application scope request scope is shared 4) Revert and say that Request Scope is not active in SE. But it's also a hack since we'll change it with CDI-530 5) Don't specify anything I guess that you're choice is 4 or 5, but I may be wrong again, so why not tell us what you'd like to see and save us some time ? thanks Antoine Le mer. 24 juin 2015 ? 11:13, Mark Struberg a ?crit : > Jozef, read the rest of the meeting minutes as well. Throne and I enlisted > dozen of REAL use cases where it is needed. > > > Does the @RequestScoped hack really address customers' problem? > Yes it does. In the final spec a programmer could programmatically enable > the request context and ends it again IF he needs it. But today he cannot. > And many users code really needs it. So the only thing we can do TODAY is > to enable it by default. > > > * A CDI implementation may add such hack by itself - no need to have it > > the spec temporarily > Well that is an option but the users then cannot rely on it. > > > And no, it is perfectly implementable as it is worded right now. > > LieGrue, > strub > > > > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger : > > > > Hi all, > > > > unfortunately I did not make it to the meeting yesterday. After reading > > the transcript I found out that the @RequestScoped hack is still being > > added to the EDR. What do I mean by "@RequestScoped hack"? > > By that I am referring to the following part of the spec: > > > > " > > In Java SE: > > The request scope is active during any method invocation. > > The request context is destroyed when the container is shut down. > > " > > > > This is vague, almost undefined and not correctly implementable. Most > > importantly, everyone seems to agree that it would be a bad idea for > > this to end up in the final spec. Instead, it is supposed to be replaced > > entirely by ContextControl API (https://issues.jboss.org/browse/CDI-530) > > post EDR1. > > > > Yet, we are adding this hack to EDR1 for the meantime. Why? The only > > argument to back this was "supporting existing libraries and > applications". > > > > That seems reasonable, doesn't it? Well, no. Antoine took a detailed > > look into probably the most prominent CDI library - DeltaSpike. Yes, you > > can find @RequestScoped beans in DeltaSpike. You can find Servlet > > artifact producers, JSF view root and navigation handlers, etc. And > > that's it. Nothing one could really use outside of the EE stack. > > > > That's not a coincidence. When a user marks a bean as @RequestScoped we > > can assume they do it for a reason. The reason most likely would be to > > scope the state per "task" (often HTTP request processing) and isolate > > the state from the state of other tasks. That's very different from the > > @Singleton-like behavior that the @RequestScoped hack adds. Therefore, > > even if a library exists that relies on @RequestScoped it is not going > > to work properly anyway. The @RequestScoped hack just suppresses a fast > > failure and trades it for weird state inconsistencies later. > > > > Another part of the argument is "existing applications". More > specifically: > > > > "struberg: well, I have a few customers with 10k++ classes. And some > > core components use it heavily" > > > > Does the @RequestScoped hack really address customers' problem? Remember > > that the @RequestScoped hack is planned to be temporary and replaced > > with proper context control post EDR1. > > Are those customers planning to migrate to EDR1 implementation (Weld > > Alpha probably) before the spec gets context control? Do they expect to > > take their "10k++ class" Java EE applications, throw the EE container > > out entirely and run the *unmodified* application in a plain Java SE > > environment with CDI SE? Will their apps work even if their > > @RequestScoped beans start behaving like singletons? > > Probably not, right? > > > > And then we have early adopters of CDI 2.0. Why should they be exposed > > to magical hacks that we know are going to disappear later? > > > > And let's not forget that: > > * CDI implementations already have their own APIs for controlling > > contexts that can be used if needed > > * A CDI implementation may add such hack by itself - no need to have it > > the spec temporarily > > > > Therefore, I cannot see a single reason for polluting the spec with > > temporary hacks. > > > > Jozef > > _______________________________________________ > > 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/20150624/d1eeab4f/attachment.html From jharting at redhat.com Wed Jun 24 05:37:54 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 24 Jun 2015 11:37:54 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: <558A7A72.1070007@redhat.com> My suggestion would be to not specify any temporary hack in the spec (and revert that part of the PR). Address this properly with CDI-530. On 06/24/2015 11:31 AM, Antoine Sabot-Durand wrote: > Jozef, > > I think I really got your disagreement on that point. You repeated it > many times. > > My point and the question I keep asking to you is "what is your > suggestion?". > Personally I see 5 solutions here: > > 1) Don't do anything since there's no alternative solution > 2) Change the wording regarding request scope activation in something > like "is active from the initialization of the container until its > shutdown" > 3) Give the same behavior than application scope request scope is shared > 4) Revert and say that Request Scope is not active in SE. But it's > also a hack since we'll change it with CDI-530 > 5) Don't specify anything > > I guess that you're choice is 4 or 5, but I may be wrong again, so why > not tell us what you'd like to see and save us some time ? > > thanks > > Antoine > > > > Le mer. 24 juin 2015 ? 11:13, Mark Struberg > a ?crit : > > Jozef, read the rest of the meeting minutes as well. Throne and I > enlisted dozen of REAL use cases where it is needed. > > > Does the @RequestScoped hack really address customers' problem? > Yes it does. In the final spec a programmer could programmatically > enable the request context and ends it again IF he needs it. But > today he cannot. And many users code really needs it. So the only > thing we can do TODAY is to enable it by default. > > > * A CDI implementation may add such hack by itself - no need to > have it > > the spec temporarily > Well that is an option but the users then cannot rely on it. > > > And no, it is perfectly implementable as it is worded right now. > > LieGrue, > strub > > > > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger > >: > > > > Hi all, > > > > unfortunately I did not make it to the meeting yesterday. After > reading > > the transcript I found out that the @RequestScoped hack is still > being > > added to the EDR. What do I mean by "@RequestScoped hack"? > > By that I am referring to the following part of the spec: > > > > " > > In Java SE: > > The request scope is active during any method invocation. > > The request context is destroyed when the container is shut down. > > " > > > > This is vague, almost undefined and not correctly implementable. > Most > > importantly, everyone seems to agree that it would be a bad idea for > > this to end up in the final spec. Instead, it is supposed to be > replaced > > entirely by ContextControl API > (https://issues.jboss.org/browse/CDI-530) > > post EDR1. > > > > Yet, we are adding this hack to EDR1 for the meantime. Why? The only > > argument to back this was "supporting existing libraries and > applications". > > > > That seems reasonable, doesn't it? Well, no. Antoine took a detailed > > look into probably the most prominent CDI library - DeltaSpike. > Yes, you > > can find @RequestScoped beans in DeltaSpike. You can find Servlet > > artifact producers, JSF view root and navigation handlers, etc. And > > that's it. Nothing one could really use outside of the EE stack. > > > > That's not a coincidence. When a user marks a bean as > @RequestScoped we > > can assume they do it for a reason. The reason most likely would > be to > > scope the state per "task" (often HTTP request processing) and > isolate > > the state from the state of other tasks. That's very different > from the > > @Singleton-like behavior that the @RequestScoped hack adds. > Therefore, > > even if a library exists that relies on @RequestScoped it is not > going > > to work properly anyway. The @RequestScoped hack just suppresses > a fast > > failure and trades it for weird state inconsistencies later. > > > > Another part of the argument is "existing applications". More > specifically: > > > > "struberg: well, I have a few customers with 10k++ classes. And some > > core components use it heavily" > > > > Does the @RequestScoped hack really address customers' problem? > Remember > > that the @RequestScoped hack is planned to be temporary and replaced > > with proper context control post EDR1. > > Are those customers planning to migrate to EDR1 implementation (Weld > > Alpha probably) before the spec gets context control? Do they > expect to > > take their "10k++ class" Java EE applications, throw the EE > container > > out entirely and run the *unmodified* application in a plain Java SE > > environment with CDI SE? Will their apps work even if their > > @RequestScoped beans start behaving like singletons? > > Probably not, right? > > > > And then we have early adopters of CDI 2.0. Why should they be > exposed > > to magical hacks that we know are going to disappear later? > > > > And let's not forget that: > > * CDI implementations already have their own APIs for controlling > > contexts that can be used if needed > > * A CDI implementation may add such hack by itself - no need to > have it > > the spec temporarily > > > > Therefore, I cannot see a single reason for polluting the spec with > > temporary hacks. > > > > Jozef > > _______________________________________________ > > 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/20150624/1e83925e/attachment-0001.html From antoine at sabot-durand.net Wed Jun 24 05:39:10 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 24 Jun 2015 09:39:10 +0000 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: Romain, CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in one shot didn't made it. To get out of the dead end I didn't see other solution than to cut the features in smaller pieces. That's why it's not finished and I intend to explain it in my blog post. As I'll explain that the EDR is for testing not early adoption. Le mer. 24 juin 2015 ? 11:31, Antoine Sabot-Durand a ?crit : > Jozef, > > I think I really got your disagreement on that point. You repeated it many > times. > > My point and the question I keep asking to you is "what is your > suggestion?". > Personally I see 5 solutions here: > > 1) Don't do anything since there's no alternative solution > 2) Change the wording regarding request scope activation in something like > "is active from the initialization of the container until its shutdown" > 3) Give the same behavior than application scope request scope is shared > 4) Revert and say that Request Scope is not active in SE. But it's also a > hack since we'll change it with CDI-530 > 5) Don't specify anything > > I guess that you're choice is 4 or 5, but I may be wrong again, so why not > tell us what you'd like to see and save us some time ? > > thanks > > Antoine > > > > Le mer. 24 juin 2015 ? 11:13, Mark Struberg a ?crit : > >> Jozef, read the rest of the meeting minutes as well. Throne and I >> enlisted dozen of REAL use cases where it is needed. >> >> > Does the @RequestScoped hack really address customers' problem? >> Yes it does. In the final spec a programmer could programmatically enable >> the request context and ends it again IF he needs it. But today he cannot. >> And many users code really needs it. So the only thing we can do TODAY is >> to enable it by default. >> >> > * A CDI implementation may add such hack by itself - no need to have it >> > the spec temporarily >> Well that is an option but the users then cannot rely on it. >> >> >> And no, it is perfectly implementable as it is worded right now. >> >> LieGrue, >> strub >> >> >> > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger : >> > >> > Hi all, >> > >> > unfortunately I did not make it to the meeting yesterday. After reading >> > the transcript I found out that the @RequestScoped hack is still being >> > added to the EDR. What do I mean by "@RequestScoped hack"? >> > By that I am referring to the following part of the spec: >> > >> > " >> > In Java SE: >> > The request scope is active during any method invocation. >> > The request context is destroyed when the container is shut down. >> > " >> > >> > This is vague, almost undefined and not correctly implementable. Most >> > importantly, everyone seems to agree that it would be a bad idea for >> > this to end up in the final spec. Instead, it is supposed to be replaced >> > entirely by ContextControl API (https://issues.jboss.org/browse/CDI-530 >> ) >> > post EDR1. >> > >> > Yet, we are adding this hack to EDR1 for the meantime. Why? The only >> > argument to back this was "supporting existing libraries and >> applications". >> > >> > That seems reasonable, doesn't it? Well, no. Antoine took a detailed >> > look into probably the most prominent CDI library - DeltaSpike. Yes, you >> > can find @RequestScoped beans in DeltaSpike. You can find Servlet >> > artifact producers, JSF view root and navigation handlers, etc. And >> > that's it. Nothing one could really use outside of the EE stack. >> > >> > That's not a coincidence. When a user marks a bean as @RequestScoped we >> > can assume they do it for a reason. The reason most likely would be to >> > scope the state per "task" (often HTTP request processing) and isolate >> > the state from the state of other tasks. That's very different from the >> > @Singleton-like behavior that the @RequestScoped hack adds. Therefore, >> > even if a library exists that relies on @RequestScoped it is not going >> > to work properly anyway. The @RequestScoped hack just suppresses a fast >> > failure and trades it for weird state inconsistencies later. >> > >> > Another part of the argument is "existing applications". More >> specifically: >> > >> > "struberg: well, I have a few customers with 10k++ classes. And some >> > core components use it heavily" >> > >> > Does the @RequestScoped hack really address customers' problem? Remember >> > that the @RequestScoped hack is planned to be temporary and replaced >> > with proper context control post EDR1. >> > Are those customers planning to migrate to EDR1 implementation (Weld >> > Alpha probably) before the spec gets context control? Do they expect to >> > take their "10k++ class" Java EE applications, throw the EE container >> > out entirely and run the *unmodified* application in a plain Java SE >> > environment with CDI SE? Will their apps work even if their >> > @RequestScoped beans start behaving like singletons? >> > Probably not, right? >> > >> > And then we have early adopters of CDI 2.0. Why should they be exposed >> > to magical hacks that we know are going to disappear later? >> > >> > And let's not forget that: >> > * CDI implementations already have their own APIs for controlling >> > contexts that can be used if needed >> > * A CDI implementation may add such hack by itself - no need to have it >> > the spec temporarily >> > >> > Therefore, I cannot see a single reason for polluting the spec with >> > temporary hacks. >> > >> > Jozef >> > _______________________________________________ >> > 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/20150624/e1e141fe/attachment.html From rmannibucau at gmail.com Wed Jun 24 05:40:54 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 24 Jun 2015 11:40:54 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: @Antoine: didnt complain about the in progress status. Just prefer as Jozef to not put something we ll revert which will lock us as @New did but in a worse manner. Said otherwise better to not do than doing it wrong knowing it is wrong. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand : > Romain, > > CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in one > shot didn't made it. To get out of the dead end I didn't see other solution > than to cut the features in smaller pieces. That's why it's not finished > and I intend to explain it in my blog post. As I'll explain that the EDR is > for testing not early adoption. > > > > Le mer. 24 juin 2015 ? 11:31, Antoine Sabot-Durand < > antoine at sabot-durand.net> a ?crit : > >> Jozef, >> >> I think I really got your disagreement on that point. You repeated it >> many times. >> >> My point and the question I keep asking to you is "what is your >> suggestion?". >> Personally I see 5 solutions here: >> >> 1) Don't do anything since there's no alternative solution >> 2) Change the wording regarding request scope activation in something >> like "is active from the initialization of the container until its shutdown" >> 3) Give the same behavior than application scope request scope is shared >> 4) Revert and say that Request Scope is not active in SE. But it's also a >> hack since we'll change it with CDI-530 >> 5) Don't specify anything >> >> I guess that you're choice is 4 or 5, but I may be wrong again, so why >> not tell us what you'd like to see and save us some time ? >> >> thanks >> >> Antoine >> >> >> >> Le mer. 24 juin 2015 ? 11:13, Mark Struberg a ?crit : >> >>> Jozef, read the rest of the meeting minutes as well. Throne and I >>> enlisted dozen of REAL use cases where it is needed. >>> >>> > Does the @RequestScoped hack really address customers' problem? >>> Yes it does. In the final spec a programmer could programmatically >>> enable the request context and ends it again IF he needs it. But today he >>> cannot. And many users code really needs it. So the only thing we can do >>> TODAY is to enable it by default. >>> >>> > * A CDI implementation may add such hack by itself - no need to have it >>> > the spec temporarily >>> Well that is an option but the users then cannot rely on it. >>> >>> >>> And no, it is perfectly implementable as it is worded right now. >>> >>> LieGrue, >>> strub >>> >>> >>> > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger : >>> > >>> > Hi all, >>> > >>> > unfortunately I did not make it to the meeting yesterday. After reading >>> > the transcript I found out that the @RequestScoped hack is still being >>> > added to the EDR. What do I mean by "@RequestScoped hack"? >>> > By that I am referring to the following part of the spec: >>> > >>> > " >>> > In Java SE: >>> > The request scope is active during any method invocation. >>> > The request context is destroyed when the container is shut down. >>> > " >>> > >>> > This is vague, almost undefined and not correctly implementable. Most >>> > importantly, everyone seems to agree that it would be a bad idea for >>> > this to end up in the final spec. Instead, it is supposed to be >>> replaced >>> > entirely by ContextControl API ( >>> https://issues.jboss.org/browse/CDI-530) >>> > post EDR1. >>> > >>> > Yet, we are adding this hack to EDR1 for the meantime. Why? The only >>> > argument to back this was "supporting existing libraries and >>> applications". >>> > >>> > That seems reasonable, doesn't it? Well, no. Antoine took a detailed >>> > look into probably the most prominent CDI library - DeltaSpike. Yes, >>> you >>> > can find @RequestScoped beans in DeltaSpike. You can find Servlet >>> > artifact producers, JSF view root and navigation handlers, etc. And >>> > that's it. Nothing one could really use outside of the EE stack. >>> > >>> > That's not a coincidence. When a user marks a bean as @RequestScoped we >>> > can assume they do it for a reason. The reason most likely would be to >>> > scope the state per "task" (often HTTP request processing) and isolate >>> > the state from the state of other tasks. That's very different from the >>> > @Singleton-like behavior that the @RequestScoped hack adds. Therefore, >>> > even if a library exists that relies on @RequestScoped it is not going >>> > to work properly anyway. The @RequestScoped hack just suppresses a fast >>> > failure and trades it for weird state inconsistencies later. >>> > >>> > Another part of the argument is "existing applications". More >>> specifically: >>> > >>> > "struberg: well, I have a few customers with 10k++ classes. And some >>> > core components use it heavily" >>> > >>> > Does the @RequestScoped hack really address customers' problem? >>> Remember >>> > that the @RequestScoped hack is planned to be temporary and replaced >>> > with proper context control post EDR1. >>> > Are those customers planning to migrate to EDR1 implementation (Weld >>> > Alpha probably) before the spec gets context control? Do they expect to >>> > take their "10k++ class" Java EE applications, throw the EE container >>> > out entirely and run the *unmodified* application in a plain Java SE >>> > environment with CDI SE? Will their apps work even if their >>> > @RequestScoped beans start behaving like singletons? >>> > Probably not, right? >>> > >>> > And then we have early adopters of CDI 2.0. Why should they be exposed >>> > to magical hacks that we know are going to disappear later? >>> > >>> > And let's not forget that: >>> > * CDI implementations already have their own APIs for controlling >>> > contexts that can be used if needed >>> > * A CDI implementation may add such hack by itself - no need to have it >>> > the spec temporarily >>> > >>> > Therefore, I cannot see a single reason for polluting the spec with >>> > temporary hacks. >>> > >>> > Jozef >>> > _______________________________________________ >>> > 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/20150624/72db1a2c/attachment-0001.html From antoine at sabot-durand.net Wed Jun 24 05:51:46 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 24 Jun 2015 09:51:46 +0000 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: So Jozef, 1) do you suggest to remove only the request context part or all chapter 14 (https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#contexts_se), which could make more sense. 2) What will be the request and application context behavior in the RI? Le mer. 24 juin 2015 ? 11:41, Romain Manni-Bucau a ?crit : > @Antoine: didnt complain about the in progress status. Just prefer as > Jozef to not put something we ll revert which will lock us as @New did but > in a worse manner. Said otherwise better to not do than doing it wrong > knowing it is wrong. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand > : > >> Romain, >> >> CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in >> one shot didn't made it. To get out of the dead end I didn't see other >> solution than to cut the features in smaller pieces. That's why it's not >> finished and I intend to explain it in my blog post. As I'll explain that >> the EDR is for testing not early adoption. >> >> >> >> Le mer. 24 juin 2015 ? 11:31, Antoine Sabot-Durand < >> antoine at sabot-durand.net> a ?crit : >> >>> Jozef, >>> >>> I think I really got your disagreement on that point. You repeated it >>> many times. >>> >>> My point and the question I keep asking to you is "what is your >>> suggestion?". >>> Personally I see 5 solutions here: >>> >>> 1) Don't do anything since there's no alternative solution >>> 2) Change the wording regarding request scope activation in something >>> like "is active from the initialization of the container until its shutdown" >>> 3) Give the same behavior than application scope request scope is shared >>> 4) Revert and say that Request Scope is not active in SE. But it's also >>> a hack since we'll change it with CDI-530 >>> 5) Don't specify anything >>> >>> I guess that you're choice is 4 or 5, but I may be wrong again, so why >>> not tell us what you'd like to see and save us some time ? >>> >>> thanks >>> >>> Antoine >>> >>> >>> >>> Le mer. 24 juin 2015 ? 11:13, Mark Struberg a >>> ?crit : >>> >>>> Jozef, read the rest of the meeting minutes as well. Throne and I >>>> enlisted dozen of REAL use cases where it is needed. >>>> >>>> > Does the @RequestScoped hack really address customers' problem? >>>> Yes it does. In the final spec a programmer could programmatically >>>> enable the request context and ends it again IF he needs it. But today he >>>> cannot. And many users code really needs it. So the only thing we can do >>>> TODAY is to enable it by default. >>>> >>>> > * A CDI implementation may add such hack by itself - no need to have >>>> it >>>> > the spec temporarily >>>> Well that is an option but the users then cannot rely on it. >>>> >>>> >>>> And no, it is perfectly implementable as it is worded right now. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger : >>>> > >>>> > Hi all, >>>> > >>>> > unfortunately I did not make it to the meeting yesterday. After >>>> reading >>>> > the transcript I found out that the @RequestScoped hack is still being >>>> > added to the EDR. What do I mean by "@RequestScoped hack"? >>>> > By that I am referring to the following part of the spec: >>>> > >>>> > " >>>> > In Java SE: >>>> > The request scope is active during any method invocation. >>>> > The request context is destroyed when the container is shut down. >>>> > " >>>> > >>>> > This is vague, almost undefined and not correctly implementable. Most >>>> > importantly, everyone seems to agree that it would be a bad idea for >>>> > this to end up in the final spec. Instead, it is supposed to be >>>> replaced >>>> > entirely by ContextControl API ( >>>> https://issues.jboss.org/browse/CDI-530) >>>> > post EDR1. >>>> > >>>> > Yet, we are adding this hack to EDR1 for the meantime. Why? The only >>>> > argument to back this was "supporting existing libraries and >>>> applications". >>>> > >>>> > That seems reasonable, doesn't it? Well, no. Antoine took a detailed >>>> > look into probably the most prominent CDI library - DeltaSpike. Yes, >>>> you >>>> > can find @RequestScoped beans in DeltaSpike. You can find Servlet >>>> > artifact producers, JSF view root and navigation handlers, etc. And >>>> > that's it. Nothing one could really use outside of the EE stack. >>>> > >>>> > That's not a coincidence. When a user marks a bean as @RequestScoped >>>> we >>>> > can assume they do it for a reason. The reason most likely would be to >>>> > scope the state per "task" (often HTTP request processing) and isolate >>>> > the state from the state of other tasks. That's very different from >>>> the >>>> > @Singleton-like behavior that the @RequestScoped hack adds. Therefore, >>>> > even if a library exists that relies on @RequestScoped it is not going >>>> > to work properly anyway. The @RequestScoped hack just suppresses a >>>> fast >>>> > failure and trades it for weird state inconsistencies later. >>>> > >>>> > Another part of the argument is "existing applications". More >>>> specifically: >>>> > >>>> > "struberg: well, I have a few customers with 10k++ classes. And some >>>> > core components use it heavily" >>>> > >>>> > Does the @RequestScoped hack really address customers' problem? >>>> Remember >>>> > that the @RequestScoped hack is planned to be temporary and replaced >>>> > with proper context control post EDR1. >>>> > Are those customers planning to migrate to EDR1 implementation (Weld >>>> > Alpha probably) before the spec gets context control? Do they expect >>>> to >>>> > take their "10k++ class" Java EE applications, throw the EE container >>>> > out entirely and run the *unmodified* application in a plain Java SE >>>> > environment with CDI SE? Will their apps work even if their >>>> > @RequestScoped beans start behaving like singletons? >>>> > Probably not, right? >>>> > >>>> > And then we have early adopters of CDI 2.0. Why should they be exposed >>>> > to magical hacks that we know are going to disappear later? >>>> > >>>> > And let's not forget that: >>>> > * CDI implementations already have their own APIs for controlling >>>> > contexts that can be used if needed >>>> > * A CDI implementation may add such hack by itself - no need to have >>>> it >>>> > the spec temporarily >>>> > >>>> > Therefore, I cannot see a single reason for polluting the spec with >>>> > temporary hacks. >>>> > >>>> > Jozef >>>> > _______________________________________________ >>>> > 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/20150624/9cb0e727/attachment.html From struberg at yahoo.de Wed Jun 24 05:58:39 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 24 Jun 2015 11:58:39 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: <558A7799.3020906@redhat.com> References: <558A6F6E.5070901@redhat.com> <558A7799.3020906@redhat.com> Message-ID: No of course not, but we should imo _always_ deliver something something ?real? and never anything which comes from an ivorytower and cannot be used in reality. > Will their apps work even if their > @RequestScoped beans start behaving like singletons? It doesn?t. It?s more like ?@ThreadScoped? in that case? LieGrue, strub > Am 24.06.2015 um 11:25 schrieb Jozef Hartinger : > > On 06/24/2015 11:10 AM, Mark Struberg wrote: >>> Does the @RequestScoped hack really address customers' problem? >> Yes it does. In the final spec a programmer could programmatically enable the request context and ends it again IF he needs it. But today he cannot. And many users code really needs it. So the only thing we can do TODAY is to enable it by default. > Are those customers planning to migrate to EDR1 implementation (Weld > Alpha probably) before the spec gets context control? Do they expect to > take their "10k++ class" Java EE applications, throw the EE container > out entirely and run the *unmodified* application in a plain Java SE > environment with CDI SE? Will their apps work even if their > @RequestScoped beans start behaving like singletons? >> >>> * A CDI implementation may add such hack by itself - no need to have it >>> the spec temporarily >> Well that is an option but the users then cannot rely on it. > We are talking about an early draft. Users cannot and shouldn't really rely on anything in the draft as chances are it is going to change. From struberg at yahoo.de Wed Jun 24 06:01:12 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 24 Jun 2015 12:01:12 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: What about this solution: we don?t mention it in the spec _now_ but agree to activate it in the impls for now. (weld and owb)? LieGrue, strub > Am 24.06.2015 um 11:51 schrieb Antoine Sabot-Durand : > > So Jozef, > > 1) do you suggest to remove only the request context part or all chapter 14 (https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#contexts_se), which could make more sense. > 2) What will be the request and application context behavior in the RI? > > Le mer. 24 juin 2015 ? 11:41, Romain Manni-Bucau a ?crit : > @Antoine: didnt complain about the in progress status. Just prefer as Jozef to not put something we ll revert which will lock us as @New did but in a worse manner. Said otherwise better to not do than doing it wrong knowing it is wrong. > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand : > Romain, > > CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in one shot didn't made it. To get out of the dead end I didn't see other solution than to cut the features in smaller pieces. That's why it's not finished and I intend to explain it in my blog post. As I'll explain that the EDR is for testing not early adoption. > > > > Le mer. 24 juin 2015 ? 11:31, Antoine Sabot-Durand a ?crit : > Jozef, > > I think I really got your disagreement on that point. You repeated it many times. > > My point and the question I keep asking to you is "what is your suggestion?". > Personally I see 5 solutions here: > > 1) Don't do anything since there's no alternative solution > 2) Change the wording regarding request scope activation in something like "is active from the initialization of the container until its shutdown" > 3) Give the same behavior than application scope request scope is shared > 4) Revert and say that Request Scope is not active in SE. But it's also a hack since we'll change it with CDI-530 > 5) Don't specify anything > > I guess that you're choice is 4 or 5, but I may be wrong again, so why not tell us what you'd like to see and save us some time ? > > thanks > > Antoine > > > > Le mer. 24 juin 2015 ? 11:13, Mark Struberg a ?crit : > Jozef, read the rest of the meeting minutes as well. Throne and I enlisted dozen of REAL use cases where it is needed. > > > Does the @RequestScoped hack really address customers' problem? > Yes it does. In the final spec a programmer could programmatically enable the request context and ends it again IF he needs it. But today he cannot. And many users code really needs it. So the only thing we can do TODAY is to enable it by default. > > > * A CDI implementation may add such hack by itself - no need to have it > > the spec temporarily > Well that is an option but the users then cannot rely on it. > > > And no, it is perfectly implementable as it is worded right now. > > LieGrue, > strub > > > > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger : > > > > Hi all, > > > > unfortunately I did not make it to the meeting yesterday. After reading > > the transcript I found out that the @RequestScoped hack is still being > > added to the EDR. What do I mean by "@RequestScoped hack"? > > By that I am referring to the following part of the spec: > > > > " > > In Java SE: > > The request scope is active during any method invocation. > > The request context is destroyed when the container is shut down. > > " > > > > This is vague, almost undefined and not correctly implementable. Most > > importantly, everyone seems to agree that it would be a bad idea for > > this to end up in the final spec. Instead, it is supposed to be replaced > > entirely by ContextControl API (https://issues.jboss.org/browse/CDI-530) > > post EDR1. > > > > Yet, we are adding this hack to EDR1 for the meantime. Why? The only > > argument to back this was "supporting existing libraries and applications". > > > > That seems reasonable, doesn't it? Well, no. Antoine took a detailed > > look into probably the most prominent CDI library - DeltaSpike. Yes, you > > can find @RequestScoped beans in DeltaSpike. You can find Servlet > > artifact producers, JSF view root and navigation handlers, etc. And > > that's it. Nothing one could really use outside of the EE stack. > > > > That's not a coincidence. When a user marks a bean as @RequestScoped we > > can assume they do it for a reason. The reason most likely would be to > > scope the state per "task" (often HTTP request processing) and isolate > > the state from the state of other tasks. That's very different from the > > @Singleton-like behavior that the @RequestScoped hack adds. Therefore, > > even if a library exists that relies on @RequestScoped it is not going > > to work properly anyway. The @RequestScoped hack just suppresses a fast > > failure and trades it for weird state inconsistencies later. > > > > Another part of the argument is "existing applications". More specifically: > > > > "struberg: well, I have a few customers with 10k++ classes. And some > > core components use it heavily" > > > > Does the @RequestScoped hack really address customers' problem? Remember > > that the @RequestScoped hack is planned to be temporary and replaced > > with proper context control post EDR1. > > Are those customers planning to migrate to EDR1 implementation (Weld > > Alpha probably) before the spec gets context control? Do they expect to > > take their "10k++ class" Java EE applications, throw the EE container > > out entirely and run the *unmodified* application in a plain Java SE > > environment with CDI SE? Will their apps work even if their > > @RequestScoped beans start behaving like singletons? > > Probably not, right? > > > > And then we have early adopters of CDI 2.0. Why should they be exposed > > to magical hacks that we know are going to disappear later? > > > > And let's not forget that: > > * CDI implementations already have their own APIs for controlling > > contexts that can be used if needed > > * A CDI implementation may add such hack by itself - no need to have it > > the spec temporarily > > > > Therefore, I cannot see a single reason for polluting the spec with > > temporary hacks. > > > > Jozef > > _______________________________________________ > > 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. > From antoine at sabot-durand.net Wed Jun 24 06:04:24 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 24 Jun 2015 10:04:24 +0000 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: Ok, let me phrase it again: "the EDR is not a partial spec, feature in it can be amend, changed or totally removed". It's main purpose is to have our end users feedback. This idea of having a temporary specified part was introduced nearly 2 months ago and was discussed many time... Would have been nice to have this discussion before doing the work. Le mer. 24 juin 2015 ? 11:41, Romain Manni-Bucau a ?crit : > @Antoine: didnt complain about the in progress status. Just prefer as > Jozef to not put something we ll revert which will lock us as @New did but > in a worse manner. Said otherwise better to not do than doing it wrong > knowing it is wrong. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand > : > >> Romain, >> >> CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in >> one shot didn't made it. To get out of the dead end I didn't see other >> solution than to cut the features in smaller pieces. That's why it's not >> finished and I intend to explain it in my blog post. As I'll explain that >> the EDR is for testing not early adoption. >> >> >> >> Le mer. 24 juin 2015 ? 11:31, Antoine Sabot-Durand < >> antoine at sabot-durand.net> a ?crit : >> >>> Jozef, >>> >>> I think I really got your disagreement on that point. You repeated it >>> many times. >>> >>> My point and the question I keep asking to you is "what is your >>> suggestion?". >>> Personally I see 5 solutions here: >>> >>> 1) Don't do anything since there's no alternative solution >>> 2) Change the wording regarding request scope activation in something >>> like "is active from the initialization of the container until its shutdown" >>> 3) Give the same behavior than application scope request scope is shared >>> 4) Revert and say that Request Scope is not active in SE. But it's also >>> a hack since we'll change it with CDI-530 >>> 5) Don't specify anything >>> >>> I guess that you're choice is 4 or 5, but I may be wrong again, so why >>> not tell us what you'd like to see and save us some time ? >>> >>> thanks >>> >>> Antoine >>> >>> >>> >>> Le mer. 24 juin 2015 ? 11:13, Mark Struberg a >>> ?crit : >>> >>>> Jozef, read the rest of the meeting minutes as well. Throne and I >>>> enlisted dozen of REAL use cases where it is needed. >>>> >>>> > Does the @RequestScoped hack really address customers' problem? >>>> Yes it does. In the final spec a programmer could programmatically >>>> enable the request context and ends it again IF he needs it. But today he >>>> cannot. And many users code really needs it. So the only thing we can do >>>> TODAY is to enable it by default. >>>> >>>> > * A CDI implementation may add such hack by itself - no need to have >>>> it >>>> > the spec temporarily >>>> Well that is an option but the users then cannot rely on it. >>>> >>>> >>>> And no, it is perfectly implementable as it is worded right now. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger : >>>> > >>>> > Hi all, >>>> > >>>> > unfortunately I did not make it to the meeting yesterday. After >>>> reading >>>> > the transcript I found out that the @RequestScoped hack is still being >>>> > added to the EDR. What do I mean by "@RequestScoped hack"? >>>> > By that I am referring to the following part of the spec: >>>> > >>>> > " >>>> > In Java SE: >>>> > The request scope is active during any method invocation. >>>> > The request context is destroyed when the container is shut down. >>>> > " >>>> > >>>> > This is vague, almost undefined and not correctly implementable. Most >>>> > importantly, everyone seems to agree that it would be a bad idea for >>>> > this to end up in the final spec. Instead, it is supposed to be >>>> replaced >>>> > entirely by ContextControl API ( >>>> https://issues.jboss.org/browse/CDI-530) >>>> > post EDR1. >>>> > >>>> > Yet, we are adding this hack to EDR1 for the meantime. Why? The only >>>> > argument to back this was "supporting existing libraries and >>>> applications". >>>> > >>>> > That seems reasonable, doesn't it? Well, no. Antoine took a detailed >>>> > look into probably the most prominent CDI library - DeltaSpike. Yes, >>>> you >>>> > can find @RequestScoped beans in DeltaSpike. You can find Servlet >>>> > artifact producers, JSF view root and navigation handlers, etc. And >>>> > that's it. Nothing one could really use outside of the EE stack. >>>> > >>>> > That's not a coincidence. When a user marks a bean as @RequestScoped >>>> we >>>> > can assume they do it for a reason. The reason most likely would be to >>>> > scope the state per "task" (often HTTP request processing) and isolate >>>> > the state from the state of other tasks. That's very different from >>>> the >>>> > @Singleton-like behavior that the @RequestScoped hack adds. Therefore, >>>> > even if a library exists that relies on @RequestScoped it is not going >>>> > to work properly anyway. The @RequestScoped hack just suppresses a >>>> fast >>>> > failure and trades it for weird state inconsistencies later. >>>> > >>>> > Another part of the argument is "existing applications". More >>>> specifically: >>>> > >>>> > "struberg: well, I have a few customers with 10k++ classes. And some >>>> > core components use it heavily" >>>> > >>>> > Does the @RequestScoped hack really address customers' problem? >>>> Remember >>>> > that the @RequestScoped hack is planned to be temporary and replaced >>>> > with proper context control post EDR1. >>>> > Are those customers planning to migrate to EDR1 implementation (Weld >>>> > Alpha probably) before the spec gets context control? Do they expect >>>> to >>>> > take their "10k++ class" Java EE applications, throw the EE container >>>> > out entirely and run the *unmodified* application in a plain Java SE >>>> > environment with CDI SE? Will their apps work even if their >>>> > @RequestScoped beans start behaving like singletons? >>>> > Probably not, right? >>>> > >>>> > And then we have early adopters of CDI 2.0. Why should they be exposed >>>> > to magical hacks that we know are going to disappear later? >>>> > >>>> > And let's not forget that: >>>> > * CDI implementations already have their own APIs for controlling >>>> > contexts that can be used if needed >>>> > * A CDI implementation may add such hack by itself - no need to have >>>> it >>>> > the spec temporarily >>>> > >>>> > Therefore, I cannot see a single reason for polluting the spec with >>>> > temporary hacks. >>>> > >>>> > Jozef >>>> > _______________________________________________ >>>> > 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/20150624/21a7eb03/attachment.html From rmannibucau at gmail.com Wed Jun 24 06:07:55 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 24 Jun 2015 12:07:55 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: the issue isnot hqving something temporary but something temporary and really different from the final solution we seem to all desire. Stupid question surely but qsking it qnyway: cant we add a ContextControl taken from deltaspike in the EDR and the refine it? sounds like a closer solution than activating a scope then removing this. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-06-24 12:04 GMT+02:00 Antoine Sabot-Durand : > Ok, let me phrase it again: "the EDR is not a partial spec, feature in it > can be amend, changed or totally removed". It's main purpose is to have our > end users feedback. > This idea of having a temporary specified part was introduced nearly 2 > months ago and was discussed many time... Would have been nice to have this > discussion before doing the work. > > > Le mer. 24 juin 2015 ? 11:41, Romain Manni-Bucau > a ?crit : > >> @Antoine: didnt complain about the in progress status. Just prefer as >> Jozef to not put something we ll revert which will lock us as @New did but >> in a worse manner. Said otherwise better to not do than doing it wrong >> knowing it is wrong. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand > >: >> >>> Romain, >>> >>> CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in >>> one shot didn't made it. To get out of the dead end I didn't see other >>> solution than to cut the features in smaller pieces. That's why it's not >>> finished and I intend to explain it in my blog post. As I'll explain that >>> the EDR is for testing not early adoption. >>> >>> >>> >>> Le mer. 24 juin 2015 ? 11:31, Antoine Sabot-Durand < >>> antoine at sabot-durand.net> a ?crit : >>> >>>> Jozef, >>>> >>>> I think I really got your disagreement on that point. You repeated it >>>> many times. >>>> >>>> My point and the question I keep asking to you is "what is your >>>> suggestion?". >>>> Personally I see 5 solutions here: >>>> >>>> 1) Don't do anything since there's no alternative solution >>>> 2) Change the wording regarding request scope activation in something >>>> like "is active from the initialization of the container until its shutdown" >>>> 3) Give the same behavior than application scope request scope is shared >>>> 4) Revert and say that Request Scope is not active in SE. But it's also >>>> a hack since we'll change it with CDI-530 >>>> 5) Don't specify anything >>>> >>>> I guess that you're choice is 4 or 5, but I may be wrong again, so why >>>> not tell us what you'd like to see and save us some time ? >>>> >>>> thanks >>>> >>>> Antoine >>>> >>>> >>>> >>>> Le mer. 24 juin 2015 ? 11:13, Mark Struberg a >>>> ?crit : >>>> >>>>> Jozef, read the rest of the meeting minutes as well. Throne and I >>>>> enlisted dozen of REAL use cases where it is needed. >>>>> >>>>> > Does the @RequestScoped hack really address customers' problem? >>>>> Yes it does. In the final spec a programmer could programmatically >>>>> enable the request context and ends it again IF he needs it. But today he >>>>> cannot. And many users code really needs it. So the only thing we can do >>>>> TODAY is to enable it by default. >>>>> >>>>> > * A CDI implementation may add such hack by itself - no need to have >>>>> it >>>>> > the spec temporarily >>>>> Well that is an option but the users then cannot rely on it. >>>>> >>>>> >>>>> And no, it is perfectly implementable as it is worded right now. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger >>>> >: >>>>> > >>>>> > Hi all, >>>>> > >>>>> > unfortunately I did not make it to the meeting yesterday. After >>>>> reading >>>>> > the transcript I found out that the @RequestScoped hack is still >>>>> being >>>>> > added to the EDR. What do I mean by "@RequestScoped hack"? >>>>> > By that I am referring to the following part of the spec: >>>>> > >>>>> > " >>>>> > In Java SE: >>>>> > The request scope is active during any method invocation. >>>>> > The request context is destroyed when the container is shut down. >>>>> > " >>>>> > >>>>> > This is vague, almost undefined and not correctly implementable. Most >>>>> > importantly, everyone seems to agree that it would be a bad idea for >>>>> > this to end up in the final spec. Instead, it is supposed to be >>>>> replaced >>>>> > entirely by ContextControl API ( >>>>> https://issues.jboss.org/browse/CDI-530) >>>>> > post EDR1. >>>>> > >>>>> > Yet, we are adding this hack to EDR1 for the meantime. Why? The only >>>>> > argument to back this was "supporting existing libraries and >>>>> applications". >>>>> > >>>>> > That seems reasonable, doesn't it? Well, no. Antoine took a detailed >>>>> > look into probably the most prominent CDI library - DeltaSpike. Yes, >>>>> you >>>>> > can find @RequestScoped beans in DeltaSpike. You can find Servlet >>>>> > artifact producers, JSF view root and navigation handlers, etc. And >>>>> > that's it. Nothing one could really use outside of the EE stack. >>>>> > >>>>> > That's not a coincidence. When a user marks a bean as @RequestScoped >>>>> we >>>>> > can assume they do it for a reason. The reason most likely would be >>>>> to >>>>> > scope the state per "task" (often HTTP request processing) and >>>>> isolate >>>>> > the state from the state of other tasks. That's very different from >>>>> the >>>>> > @Singleton-like behavior that the @RequestScoped hack adds. >>>>> Therefore, >>>>> > even if a library exists that relies on @RequestScoped it is not >>>>> going >>>>> > to work properly anyway. The @RequestScoped hack just suppresses a >>>>> fast >>>>> > failure and trades it for weird state inconsistencies later. >>>>> > >>>>> > Another part of the argument is "existing applications". More >>>>> specifically: >>>>> > >>>>> > "struberg: well, I have a few customers with 10k++ classes. And some >>>>> > core components use it heavily" >>>>> > >>>>> > Does the @RequestScoped hack really address customers' problem? >>>>> Remember >>>>> > that the @RequestScoped hack is planned to be temporary and replaced >>>>> > with proper context control post EDR1. >>>>> > Are those customers planning to migrate to EDR1 implementation (Weld >>>>> > Alpha probably) before the spec gets context control? Do they expect >>>>> to >>>>> > take their "10k++ class" Java EE applications, throw the EE container >>>>> > out entirely and run the *unmodified* application in a plain Java SE >>>>> > environment with CDI SE? Will their apps work even if their >>>>> > @RequestScoped beans start behaving like singletons? >>>>> > Probably not, right? >>>>> > >>>>> > And then we have early adopters of CDI 2.0. Why should they be >>>>> exposed >>>>> > to magical hacks that we know are going to disappear later? >>>>> > >>>>> > And let's not forget that: >>>>> > * CDI implementations already have their own APIs for controlling >>>>> > contexts that can be used if needed >>>>> > * A CDI implementation may add such hack by itself - no need to have >>>>> it >>>>> > the spec temporarily >>>>> > >>>>> > Therefore, I cannot see a single reason for polluting the spec with >>>>> > temporary hacks. >>>>> > >>>>> > Jozef >>>>> > _______________________________________________ >>>>> > 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/20150624/f1544a8d/attachment-0001.html From struberg at yahoo.de Wed Jun 24 07:05:24 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 24 Jun 2015 13:05:24 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: <611935BD-AA81-44D1-A936-68E158D7EC62@yahoo.de> No because the DS solution is not enough for the CDI spec. We need a mixture of features. At least if it should also be usable in EE. What we miss in DS is that you can give a well defined ?storage? from outside. You can just start the SessionScope but it is always only for the current thread. Any other Thread will get a new context storage underneath. This is great if you just need some code which uses @SessionScoped to work somehow. But I think this is not enough if we want something inside the spec. LieGrue, strub > Am 24.06.2015 um 12:07 schrieb Romain Manni-Bucau : > > the issue isnot hqving something temporary but something temporary and really different from the final solution we seem to all desire. > > Stupid question surely but qsking it qnyway: cant we add a ContextControl taken from deltaspike in the EDR and the refine it? sounds like a closer solution than activating a scope then removing this. > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-06-24 12:04 GMT+02:00 Antoine Sabot-Durand : > Ok, let me phrase it again: "the EDR is not a partial spec, feature in it can be amend, changed or totally removed". It's main purpose is to have our end users feedback. > This idea of having a temporary specified part was introduced nearly 2 months ago and was discussed many time... Would have been nice to have this discussion before doing the work. > > > Le mer. 24 juin 2015 ? 11:41, Romain Manni-Bucau a ?crit : > @Antoine: didnt complain about the in progress status. Just prefer as Jozef to not put something we ll revert which will lock us as @New did but in a worse manner. Said otherwise better to not do than doing it wrong knowing it is wrong. > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand : > Romain, > > CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in one shot didn't made it. To get out of the dead end I didn't see other solution than to cut the features in smaller pieces. That's why it's not finished and I intend to explain it in my blog post. As I'll explain that the EDR is for testing not early adoption. > > > > Le mer. 24 juin 2015 ? 11:31, Antoine Sabot-Durand a ?crit : > Jozef, > > I think I really got your disagreement on that point. You repeated it many times. > > My point and the question I keep asking to you is "what is your suggestion?". > Personally I see 5 solutions here: > > 1) Don't do anything since there's no alternative solution > 2) Change the wording regarding request scope activation in something like "is active from the initialization of the container until its shutdown" > 3) Give the same behavior than application scope request scope is shared > 4) Revert and say that Request Scope is not active in SE. But it's also a hack since we'll change it with CDI-530 > 5) Don't specify anything > > I guess that you're choice is 4 or 5, but I may be wrong again, so why not tell us what you'd like to see and save us some time ? > > thanks > > Antoine > > > > Le mer. 24 juin 2015 ? 11:13, Mark Struberg a ?crit : > Jozef, read the rest of the meeting minutes as well. Throne and I enlisted dozen of REAL use cases where it is needed. > > > Does the @RequestScoped hack really address customers' problem? > Yes it does. In the final spec a programmer could programmatically enable the request context and ends it again IF he needs it. But today he cannot. And many users code really needs it. So the only thing we can do TODAY is to enable it by default. > > > * A CDI implementation may add such hack by itself - no need to have it > > the spec temporarily > Well that is an option but the users then cannot rely on it. > > > And no, it is perfectly implementable as it is worded right now. > > LieGrue, > strub > > > > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger : > > > > Hi all, > > > > unfortunately I did not make it to the meeting yesterday. After reading > > the transcript I found out that the @RequestScoped hack is still being > > added to the EDR. What do I mean by "@RequestScoped hack"? > > By that I am referring to the following part of the spec: > > > > " > > In Java SE: > > The request scope is active during any method invocation. > > The request context is destroyed when the container is shut down. > > " > > > > This is vague, almost undefined and not correctly implementable. Most > > importantly, everyone seems to agree that it would be a bad idea for > > this to end up in the final spec. Instead, it is supposed to be replaced > > entirely by ContextControl API (https://issues.jboss.org/browse/CDI-530) > > post EDR1. > > > > Yet, we are adding this hack to EDR1 for the meantime. Why? The only > > argument to back this was "supporting existing libraries and applications". > > > > That seems reasonable, doesn't it? Well, no. Antoine took a detailed > > look into probably the most prominent CDI library - DeltaSpike. Yes, you > > can find @RequestScoped beans in DeltaSpike. You can find Servlet > > artifact producers, JSF view root and navigation handlers, etc. And > > that's it. Nothing one could really use outside of the EE stack. > > > > That's not a coincidence. When a user marks a bean as @RequestScoped we > > can assume they do it for a reason. The reason most likely would be to > > scope the state per "task" (often HTTP request processing) and isolate > > the state from the state of other tasks. That's very different from the > > @Singleton-like behavior that the @RequestScoped hack adds. Therefore, > > even if a library exists that relies on @RequestScoped it is not going > > to work properly anyway. The @RequestScoped hack just suppresses a fast > > failure and trades it for weird state inconsistencies later. > > > > Another part of the argument is "existing applications". More specifically: > > > > "struberg: well, I have a few customers with 10k++ classes. And some > > core components use it heavily" > > > > Does the @RequestScoped hack really address customers' problem? Remember > > that the @RequestScoped hack is planned to be temporary and replaced > > with proper context control post EDR1. > > Are those customers planning to migrate to EDR1 implementation (Weld > > Alpha probably) before the spec gets context control? Do they expect to > > take their "10k++ class" Java EE applications, throw the EE container > > out entirely and run the *unmodified* application in a plain Java SE > > environment with CDI SE? Will their apps work even if their > > @RequestScoped beans start behaving like singletons? > > Probably not, right? > > > > And then we have early adopters of CDI 2.0. Why should they be exposed > > to magical hacks that we know are going to disappear later? > > > > And let's not forget that: > > * CDI implementations already have their own APIs for controlling > > contexts that can be used if needed > > * A CDI implementation may add such hack by itself - no need to have it > > the spec temporarily > > > > Therefore, I cannot see a single reason for polluting the spec with > > temporary hacks. > > > > Jozef > > _______________________________________________ > > 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. > > From rmannibucau at gmail.com Wed Jun 24 07:12:43 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 24 Jun 2015 13:12:43 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: <611935BD-AA81-44D1-A936-68E158D7EC62@yahoo.de> References: <558A6F6E.5070901@redhat.com> <611935BD-AA81-44D1-A936-68E158D7EC62@yahoo.de> Message-ID: @Mark: not sure I follow, if we have: /** * Start the specified scope. This only works for scopes which are handled * by the CDI container itself. Custom scoped of 3rd party * Context implementations shall be started directly (they are portable anyway). * * @param scopeClass e.g. RequestScoped.class */ void startContext(Class scopeClass); /** * Stop the specified scope. This only works for scopes which are handled * by the CDI container itself. Custom scoped of 3rd party * Context implementations shall be stopped directly (they are portable anyway). * * @param scopeClass e.g. RequestScoped.class */ void stopContext(Class scopeClass); Then we aredone and it works even in EE since context can be alterable now - this is clearly something to discuss inbetween EDR and final but introducing this API solves the SE case and doesnt break the EE one. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-06-24 13:05 GMT+02:00 Mark Struberg : > No because the DS solution is not enough for the CDI spec. We need a > mixture of features. At least if it should also be usable in EE. > What we miss in DS is that you can give a well defined ?storage? from > outside. You can just start the SessionScope but it is always only for the > current thread. Any other Thread will get a new context storage underneath. > This is great if you just need some code which uses @SessionScoped to work > somehow. But I think this is not enough if we want something inside the > spec. > > LieGrue, > strub > > > > > Am 24.06.2015 um 12:07 schrieb Romain Manni-Bucau >: > > > > the issue isnot hqving something temporary but something temporary and > really different from the final solution we seem to all desire. > > > > Stupid question surely but qsking it qnyway: cant we add a > ContextControl taken from deltaspike in the EDR and the refine it? sounds > like a closer solution than activating a scope then removing this. > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > > > 2015-06-24 12:04 GMT+02:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > Ok, let me phrase it again: "the EDR is not a partial spec, feature in > it can be amend, changed or totally removed". It's main purpose is to have > our end users feedback. > > This idea of having a temporary specified part was introduced nearly 2 > months ago and was discussed many time... Would have been nice to have this > discussion before doing the work. > > > > > > Le mer. 24 juin 2015 ? 11:41, Romain Manni-Bucau > a ?crit : > > @Antoine: didnt complain about the in progress status. Just prefer as > Jozef to not put something we ll revert which will lock us as @New did but > in a worse manner. Said otherwise better to not do than doing it wrong > knowing it is wrong. > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > > > 2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > Romain, > > > > CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in > one shot didn't made it. To get out of the dead end I didn't see other > solution than to cut the features in smaller pieces. That's why it's not > finished and I intend to explain it in my blog post. As I'll explain that > the EDR is for testing not early adoption. > > > > > > > > Le mer. 24 juin 2015 ? 11:31, Antoine Sabot-Durand < > antoine at sabot-durand.net> a ?crit : > > Jozef, > > > > I think I really got your disagreement on that point. You repeated it > many times. > > > > My point and the question I keep asking to you is "what is your > suggestion?". > > Personally I see 5 solutions here: > > > > 1) Don't do anything since there's no alternative solution > > 2) Change the wording regarding request scope activation in something > like "is active from the initialization of the container until its shutdown" > > 3) Give the same behavior than application scope request scope is shared > > 4) Revert and say that Request Scope is not active in SE. But it's also > a hack since we'll change it with CDI-530 > > 5) Don't specify anything > > > > I guess that you're choice is 4 or 5, but I may be wrong again, so why > not tell us what you'd like to see and save us some time ? > > > > thanks > > > > Antoine > > > > > > > > Le mer. 24 juin 2015 ? 11:13, Mark Struberg a ?crit > : > > Jozef, read the rest of the meeting minutes as well. Throne and I > enlisted dozen of REAL use cases where it is needed. > > > > > Does the @RequestScoped hack really address customers' problem? > > Yes it does. In the final spec a programmer could programmatically > enable the request context and ends it again IF he needs it. But today he > cannot. And many users code really needs it. So the only thing we can do > TODAY is to enable it by default. > > > > > * A CDI implementation may add such hack by itself - no need to have it > > > the spec temporarily > > Well that is an option but the users then cannot rely on it. > > > > > > And no, it is perfectly implementable as it is worded right now. > > > > LieGrue, > > strub > > > > > > > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger : > > > > > > Hi all, > > > > > > unfortunately I did not make it to the meeting yesterday. After reading > > > the transcript I found out that the @RequestScoped hack is still being > > > added to the EDR. What do I mean by "@RequestScoped hack"? > > > By that I am referring to the following part of the spec: > > > > > > " > > > In Java SE: > > > The request scope is active during any method invocation. > > > The request context is destroyed when the container is shut down. > > > " > > > > > > This is vague, almost undefined and not correctly implementable. Most > > > importantly, everyone seems to agree that it would be a bad idea for > > > this to end up in the final spec. Instead, it is supposed to be > replaced > > > entirely by ContextControl API ( > https://issues.jboss.org/browse/CDI-530) > > > post EDR1. > > > > > > Yet, we are adding this hack to EDR1 for the meantime. Why? The only > > > argument to back this was "supporting existing libraries and > applications". > > > > > > That seems reasonable, doesn't it? Well, no. Antoine took a detailed > > > look into probably the most prominent CDI library - DeltaSpike. Yes, > you > > > can find @RequestScoped beans in DeltaSpike. You can find Servlet > > > artifact producers, JSF view root and navigation handlers, etc. And > > > that's it. Nothing one could really use outside of the EE stack. > > > > > > That's not a coincidence. When a user marks a bean as @RequestScoped we > > > can assume they do it for a reason. The reason most likely would be to > > > scope the state per "task" (often HTTP request processing) and isolate > > > the state from the state of other tasks. That's very different from the > > > @Singleton-like behavior that the @RequestScoped hack adds. Therefore, > > > even if a library exists that relies on @RequestScoped it is not going > > > to work properly anyway. The @RequestScoped hack just suppresses a fast > > > failure and trades it for weird state inconsistencies later. > > > > > > Another part of the argument is "existing applications". More > specifically: > > > > > > "struberg: well, I have a few customers with 10k++ classes. And some > > > core components use it heavily" > > > > > > Does the @RequestScoped hack really address customers' problem? > Remember > > > that the @RequestScoped hack is planned to be temporary and replaced > > > with proper context control post EDR1. > > > Are those customers planning to migrate to EDR1 implementation (Weld > > > Alpha probably) before the spec gets context control? Do they expect to > > > take their "10k++ class" Java EE applications, throw the EE container > > > out entirely and run the *unmodified* application in a plain Java SE > > > environment with CDI SE? Will their apps work even if their > > > @RequestScoped beans start behaving like singletons? > > > Probably not, right? > > > > > > And then we have early adopters of CDI 2.0. Why should they be exposed > > > to magical hacks that we know are going to disappear later? > > > > > > And let's not forget that: > > > * CDI implementations already have their own APIs for controlling > > > contexts that can be used if needed > > > * A CDI implementation may add such hack by itself - no need to have it > > > the spec temporarily > > > > > > Therefore, I cannot see a single reason for polluting the spec with > > > temporary hacks. > > > > > > Jozef > > > _______________________________________________ > > > 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/20150624/70e2bf35/attachment-0001.html From jharting at redhat.com Wed Jun 24 09:26:45 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 24 Jun 2015 15:26:45 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> Message-ID: <558AB015.9080206@redhat.com> On 06/24/2015 11:51 AM, Antoine Sabot-Durand wrote: > So Jozef, > > 1) do you suggest to remove only the request context part or all > chapter 14 > (https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#contexts_se), > which could make more sense. The request context part. > 2) What will be the request and application context behavior in the RI? Depends on the spec mostly. For the application context it IMHO makes sense to be have a single storage shared across threads that starts once CDI is booted and shuts down with it. For @RequestScoped there is no natural notion of a request in plain Java SE. It's the user that needs to set the boundaries of a task that the @RequestScope is supposed to represent. This can be done using Weld API and hopefully using ContextControl soon. In the meantime I see no point in blurring this with magical contexts that try to guess what the use wants. > > Le mer. 24 juin 2015 ? 11:41, Romain Manni-Bucau > > a ?crit : > > @Antoine: didnt complain about the in progress status. Just prefer > as Jozef to not put something we ll revert which will lock us as > @New did but in a worse manner. Said otherwise better to not do > than doing it wrong knowing it is wrong. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand > >: > > Romain, > > CDI-26 was open 4,5 years ago. Obviously working on the whole > stuff in one shot didn't made it. To get out of the dead end I > didn't see other solution than to cut the features in smaller > pieces. That's why it's not finished and I intend to explain > it in my blog post. As I'll explain that the EDR is for > testing not early adoption. > > > > Le mer. 24 juin 2015 ? 11:31, Antoine Sabot-Durand > > a > ?crit : > > Jozef, > > I think I really got your disagreement on that point. You > repeated it many times. > > My point and the question I keep asking to you is "what is > your suggestion?". > Personally I see 5 solutions here: > > 1) Don't do anything since there's no alternative solution > 2) Change the wording regarding request scope activation > in something like "is active from the initialization of > the container until its shutdown" > 3) Give the same behavior than application scope request > scope is shared > 4) Revert and say that Request Scope is not active in SE. > But it's also a hack since we'll change it with CDI-530 > 5) Don't specify anything > > I guess that you're choice is 4 or 5, but I may be wrong > again, so why not tell us what you'd like to see and save > us some time ? > > thanks > > Antoine > > > > Le mer. 24 juin 2015 ? 11:13, Mark Struberg > > a ?crit : > > Jozef, read the rest of the meeting minutes as well. > Throne and I enlisted dozen of REAL use cases where it > is needed. > > > Does the @RequestScoped hack really address > customers' problem? > Yes it does. In the final spec a programmer could > programmatically enable the request context and ends > it again IF he needs it. But today he cannot. And many > users code really needs it. So the only thing we can > do TODAY is to enable it by default. > > > * A CDI implementation may add such hack by itself - > no need to have it > > the spec temporarily > Well that is an option but the users then cannot rely > on it. > > > And no, it is perfectly implementable as it is worded > right now. > > LieGrue, > strub > > > > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger > >: > > > > Hi all, > > > > unfortunately I did not make it to the meeting > yesterday. After reading > > the transcript I found out that the @RequestScoped > hack is still being > > added to the EDR. What do I mean by "@RequestScoped > hack"? > > By that I am referring to the following part of the > spec: > > > > " > > In Java SE: > > The request scope is active during any method > invocation. > > The request context is destroyed when the container > is shut down. > > " > > > > This is vague, almost undefined and not correctly > implementable. Most > > importantly, everyone seems to agree that it would > be a bad idea for > > this to end up in the final spec. Instead, it is > supposed to be replaced > > entirely by ContextControl API > (https://issues.jboss.org/browse/CDI-530) > > post EDR1. > > > > Yet, we are adding this hack to EDR1 for the > meantime. Why? The only > > argument to back this was "supporting existing > libraries and applications". > > > > That seems reasonable, doesn't it? Well, no. Antoine > took a detailed > > look into probably the most prominent CDI library - > DeltaSpike. Yes, you > > can find @RequestScoped beans in DeltaSpike. You can > find Servlet > > artifact producers, JSF view root and navigation > handlers, etc. And > > that's it. Nothing one could really use outside of > the EE stack. > > > > That's not a coincidence. When a user marks a bean > as @RequestScoped we > > can assume they do it for a reason. The reason most > likely would be to > > scope the state per "task" (often HTTP request > processing) and isolate > > the state from the state of other tasks. That's very > different from the > > @Singleton-like behavior that the @RequestScoped > hack adds. Therefore, > > even if a library exists that relies on > @RequestScoped it is not going > > to work properly anyway. The @RequestScoped hack > just suppresses a fast > > failure and trades it for weird state > inconsistencies later. > > > > Another part of the argument is "existing > applications". More specifically: > > > > "struberg: well, I have a few customers with 10k++ > classes. And some > > core components use it heavily" > > > > Does the @RequestScoped hack really address > customers' problem? Remember > > that the @RequestScoped hack is planned to be > temporary and replaced > > with proper context control post EDR1. > > Are those customers planning to migrate to EDR1 > implementation (Weld > > Alpha probably) before the spec gets context > control? Do they expect to > > take their "10k++ class" Java EE applications, throw > the EE container > > out entirely and run the *unmodified* application in > a plain Java SE > > environment with CDI SE? Will their apps work even > if their > > @RequestScoped beans start behaving like singletons? > > Probably not, right? > > > > And then we have early adopters of CDI 2.0. Why > should they be exposed > > to magical hacks that we know are going to disappear > later? > > > > And let's not forget that: > > * CDI implementations already have their own APIs > for controlling > > contexts that can be used if needed > > * A CDI implementation may add such hack by itself - > no need to have it > > the spec temporarily > > > > Therefore, I cannot see a single reason for > polluting the spec with > > temporary hacks. > > > > Jozef > > _______________________________________________ > > 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/20150624/4bdd7d62/attachment-0001.html From antoine at sabot-durand.net Wed Jun 24 09:56:06 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 24 Jun 2015 13:56:06 +0000 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: <558AB015.9080206@redhat.com> References: <558A6F6E.5070901@redhat.com> <558AB015.9080206@redhat.com> Message-ID: Jozef, Sorry my question wasn't precise enough. What will be the Request Context behavior in your implementation of EDR1 ? Antoine Le mer. 24 juin 2015 ? 15:26, Jozef Hartinger a ?crit : > On 06/24/2015 11:51 AM, Antoine Sabot-Durand wrote: > > So Jozef, > > 1) do you suggest to remove only the request context part or all chapter > 14 (https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#contexts_se), > which could make more sense. > > The request context part. > > 2) What will be the request and application context behavior in the RI? > > Depends on the spec mostly. > > For the application context it IMHO makes sense to be have a single > storage shared across threads that starts once CDI is booted and shuts down > with it. > > For @RequestScoped there is no natural notion of a request in plain Java > SE. It's the user that needs to set the boundaries of a task that the > @RequestScope is supposed to represent. This can be done using Weld API and > hopefully using ContextControl soon. In the meantime I see no point in > blurring this with magical contexts that try to guess what the use wants. > > > Le mer. 24 juin 2015 ? 11:41, Romain Manni-Bucau > a ?crit : > >> @Antoine: didnt complain about the in progress status. Just prefer as >> Jozef to not put something we ll revert which will lock us as @New did but >> in a worse manner. Said otherwise better to not do than doing it wrong >> knowing it is wrong. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand < >> antoine at sabot-durand.net>: >> >>> Romain, >>> >>> CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in >>> one shot didn't made it. To get out of the dead end I didn't see other >>> solution than to cut the features in smaller pieces. That's why it's not >>> finished and I intend to explain it in my blog post. As I'll explain that >>> the EDR is for testing not early adoption. >>> >>> >>> >>> Le mer. 24 juin 2015 ? 11:31, Antoine Sabot-Durand < >>> antoine at sabot-durand.net> a ?crit : >>> >>>> Jozef, >>>> >>>> I think I really got your disagreement on that point. You repeated it >>>> many times. >>>> >>>> My point and the question I keep asking to you is "what is your >>>> suggestion?". >>>> Personally I see 5 solutions here: >>>> >>>> 1) Don't do anything since there's no alternative solution >>>> 2) Change the wording regarding request scope activation in something >>>> like "is active from the initialization of the container until its shutdown" >>>> 3) Give the same behavior than application scope request scope is shared >>>> 4) Revert and say that Request Scope is not active in SE. But it's also >>>> a hack since we'll change it with CDI-530 >>>> 5) Don't specify anything >>>> >>>> I guess that you're choice is 4 or 5, but I may be wrong again, so >>>> why not tell us what you'd like to see and save us some time ? >>>> >>>> thanks >>>> >>>> Antoine >>>> >>>> >>>> >>>> Le mer. 24 juin 2015 ? 11:13, Mark Struberg a >>>> ?crit : >>>> >>>>> Jozef, read the rest of the meeting minutes as well. Throne and I >>>>> enlisted dozen of REAL use cases where it is needed. >>>>> >>>>> > Does the @RequestScoped hack really address customers' problem? >>>>> Yes it does. In the final spec a programmer could programmatically >>>>> enable the request context and ends it again IF he needs it. But today he >>>>> cannot. And many users code really needs it. So the only thing we can do >>>>> TODAY is to enable it by default. >>>>> >>>>> > * A CDI implementation may add such hack by itself - no need to have >>>>> it >>>>> > the spec temporarily >>>>> Well that is an option but the users then cannot rely on it. >>>>> >>>>> >>>>> And no, it is perfectly implementable as it is worded right now. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger >>>> >: >>>>> > >>>>> > Hi all, >>>>> > >>>>> > unfortunately I did not make it to the meeting yesterday. After >>>>> reading >>>>> > the transcript I found out that the @RequestScoped hack is still >>>>> being >>>>> > added to the EDR. What do I mean by "@RequestScoped hack"? >>>>> > By that I am referring to the following part of the spec: >>>>> > >>>>> > " >>>>> > In Java SE: >>>>> > The request scope is active during any method invocation. >>>>> > The request context is destroyed when the container is shut down. >>>>> > " >>>>> > >>>>> > This is vague, almost undefined and not correctly implementable. Most >>>>> > importantly, everyone seems to agree that it would be a bad idea for >>>>> > this to end up in the final spec. Instead, it is supposed to be >>>>> replaced >>>>> > entirely by ContextControl API ( >>>>> https://issues.jboss.org/browse/CDI-530) >>>>> > post EDR1. >>>>> > >>>>> > Yet, we are adding this hack to EDR1 for the meantime. Why? The only >>>>> > argument to back this was "supporting existing libraries and >>>>> applications". >>>>> > >>>>> > That seems reasonable, doesn't it? Well, no. Antoine took a detailed >>>>> > look into probably the most prominent CDI library - DeltaSpike. Yes, >>>>> you >>>>> > can find @RequestScoped beans in DeltaSpike. You can find Servlet >>>>> > artifact producers, JSF view root and navigation handlers, etc. And >>>>> > that's it. Nothing one could really use outside of the EE stack. >>>>> > >>>>> > That's not a coincidence. When a user marks a bean as @RequestScoped >>>>> we >>>>> > can assume they do it for a reason. The reason most likely would be >>>>> to >>>>> > scope the state per "task" (often HTTP request processing) and >>>>> isolate >>>>> > the state from the state of other tasks. That's very different from >>>>> the >>>>> > @Singleton-like behavior that the @RequestScoped hack adds. >>>>> Therefore, >>>>> > even if a library exists that relies on @RequestScoped it is not >>>>> going >>>>> > to work properly anyway. The @RequestScoped hack just suppresses a >>>>> fast >>>>> > failure and trades it for weird state inconsistencies later. >>>>> > >>>>> > Another part of the argument is "existing applications". More >>>>> specifically: >>>>> > >>>>> > "struberg: well, I have a few customers with 10k++ classes. And some >>>>> > core components use it heavily" >>>>> > >>>>> > Does the @RequestScoped hack really address customers' problem? >>>>> Remember >>>>> > that the @RequestScoped hack is planned to be temporary and replaced >>>>> > with proper context control post EDR1. >>>>> > Are those customers planning to migrate to EDR1 implementation (Weld >>>>> > Alpha probably) before the spec gets context control? Do they expect >>>>> to >>>>> > take their "10k++ class" Java EE applications, throw the EE container >>>>> > out entirely and run the *unmodified* application in a plain Java SE >>>>> > environment with CDI SE? Will their apps work even if their >>>>> > @RequestScoped beans start behaving like singletons? >>>>> > Probably not, right? >>>>> > >>>>> > And then we have early adopters of CDI 2.0. Why should they be >>>>> exposed >>>>> > to magical hacks that we know are going to disappear later? >>>>> > >>>>> > And let's not forget that: >>>>> > * CDI implementations already have their own APIs for controlling >>>>> > contexts that can be used if needed >>>>> > * A CDI implementation may add such hack by itself - no need to have >>>>> it >>>>> > the spec temporarily >>>>> > >>>>> > Therefore, I cannot see a single reason for polluting the spec with >>>>> > temporary hacks. >>>>> > >>>>> > Jozef >>>>> > _______________________________________________ >>>>> > 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/20150624/1bf7e70f/attachment-0001.html From issues at jboss.org Wed Jun 24 10:09:03 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 24 Jun 2015 10:09:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-434: ------------------------------------- Fix Version/s: 2.0-EDR1 (was: 2.0 (discussion)) > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0-EDR1 > > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDiscovery.html#getAlternatives%28%29 > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From jharting at redhat.com Wed Jun 24 10:22:11 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 24 Jun 2015 16:22:11 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> <558AB015.9080206@redhat.com> Message-ID: <558ABD13.3010407@redhat.com> Depends on the spec mostly. For @RequestScoped there is no natural notion of a request in plain Java SE. It's the user that needs to set the boundaries of a task that the @RequestScope is supposed to represent. This can be done using Weld API and hopefully using ContextControl soon. In the meantime I see no point in blurring this with magical contexts that try to guess what the use wants. That means that the context is not active by default but can be controlled using the API. On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote: > Jozef, > > Sorry my question wasn't precise enough. What will be the Request > Context behavior in your implementation of EDR1 ? From antoine at sabot-durand.net Wed Jun 24 10:28:54 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 24 Jun 2015 14:28:54 +0000 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: <558ABD13.3010407@redhat.com> References: <558A6F6E.5070901@redhat.com> <558AB015.9080206@redhat.com> <558ABD13.3010407@redhat.com> Message-ID: Ok, but now in the chapter I have mention for Session Scope and conversation Scope not being active in SE. Wouldn't it be strange to have no mention of Request Scope or should we make a "temp hack" saying that session scope is not active... Le mer. 24 juin 2015 ? 16:22, Jozef Hartinger a ?crit : > Depends on the spec mostly. > > For @RequestScoped there is no natural notion of a request in plain Java > SE. It's the user that needs to set the boundaries of a task that the > @RequestScope is supposed to represent. This can be done using Weld API > and hopefully using ContextControl soon. In the meantime I see no point > in blurring this with magical contexts that try to guess what the use > wants. > > That means that the context is not active by default but can be > controlled using the API. > > On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote: > > Jozef, > > > > Sorry my question wasn't precise enough. What will be the Request > > Context behavior in your implementation of EDR1 ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150624/732bcc64/attachment.html From rmannibucau at gmail.com Wed Jun 24 10:38:01 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 24 Jun 2015 16:38:01 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> <558AB015.9080206@redhat.com> <558ABD13.3010407@redhat.com> Message-ID: What happen if we say nothing? will not hurt later IMHO Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-06-24 16:28 GMT+02:00 Antoine Sabot-Durand : > Ok, but now in the chapter I have mention for Session Scope and > conversation Scope not being active in SE. Wouldn't it be strange to have > no mention of Request Scope or should we make a "temp hack" saying that > session scope is not active... > > Le mer. 24 juin 2015 ? 16:22, Jozef Hartinger a > ?crit : > >> Depends on the spec mostly. >> >> For @RequestScoped there is no natural notion of a request in plain Java >> SE. It's the user that needs to set the boundaries of a task that the >> @RequestScope is supposed to represent. This can be done using Weld API >> and hopefully using ContextControl soon. In the meantime I see no point >> in blurring this with magical contexts that try to guess what the use >> wants. >> >> That means that the context is not active by default but can be >> controlled using the API. >> >> On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote: >> > Jozef, >> > >> > Sorry my question wasn't precise enough. What will be the Request >> > Context behavior in your implementation of EDR1 ? >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150624/c51b4f33/attachment.html From antonio.goncalves at gmail.com Wed Jun 24 10:38:01 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Wed, 24 Jun 2015 16:38:01 +0200 Subject: [cdi-dev] Tomorrow's meeting Agenda In-Reply-To: References: Message-ID: Hi all, Sorry, I couldn't make it yesterday for the meeting (Tuesday 6pm is quite difficult for me :o( and I was wondering if you had choosen a date : 18th or 25th September ? Antonio On Mon, Jun 22, 2015 at 3:14 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi Guys, > > > Tomorrow, we really need to close EDR1 a go for submission. It should be > possible since our last discussion point is for Request Context behavior in > SE. > > I?d like also to set the final date of our F2F meeting in Paris (18th or > 25th September) > > Regarding the spec, I think that it would be nice to go for Quick Win > tickets in Jira to have a rhythm change after the big features we worked on > since octobre. > It could be great if you could take one or two ticket that you think are > quick wins ones and send me them to discuss during the meeting. > > What is a quick win ticket? A ticket that you think obvious and easy to > solve regarding adoption of other EG members and way to solve it. > > We?ll check during the meeting if your perception of quick win is shared > among us ;). > > So the agenda is: > > 1) Closing the EDR1 > 2) Closing discussion around F2F date > 3) Discuss a first list of quick win tickets. Please send your wish list > to me > > > 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150624/c247385f/attachment.html From jharting at redhat.com Wed Jun 24 10:42:26 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 24 Jun 2015 16:42:26 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> <558AB015.9080206@redhat.com> <558ABD13.3010407@redhat.com> Message-ID: <558AC1D2.1030503@redhat.com> +1 . So far the spec has been listing the situations in which a particular context is active. Not in which it is inactive. We should carry on with that IMO. On 06/24/2015 04:38 PM, Romain Manni-Bucau wrote: > What happen if we say nothing? will not hurt later IMHO > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-06-24 16:28 GMT+02:00 Antoine Sabot-Durand > >: > > Ok, but now in the chapter I have mention for Session Scope and > conversation Scope not being active in SE. Wouldn't it be strange > to have no mention of Request Scope or should we make a "temp > hack" saying that session scope is not active... > > Le mer. 24 juin 2015 ? 16:22, Jozef Hartinger > a ?crit : > > Depends on the spec mostly. > > For @RequestScoped there is no natural notion of a request in > plain Java > SE. It's the user that needs to set the boundaries of a task > that the > @RequestScope is supposed to represent. This can be done using > Weld API > and hopefully using ContextControl soon. In the meantime I see > no point > in blurring this with magical contexts that try to guess what > the use wants. > > That means that the context is not active by default but can be > controlled using the API. > > On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote: > > Jozef, > > > > Sorry my question wasn't precise enough. What will be the > Request > > Context behavior in your implementation of EDR1 ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150624/71c54463/attachment-0001.html From mkouba at redhat.com Wed Jun 24 10:43:33 2015 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 24 Jun 2015 16:43:33 +0200 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> <558AB015.9080206@redhat.com> <558ABD13.3010407@redhat.com> Message-ID: <558AC215.8050903@redhat.com> +1 for removing all 14.1.x sections except for "14.1.3. Application context lifecycle in Java SE". Martin Dne 24.6.2015 v 16:38 Romain Manni-Bucau napsal(a): > What happen if we say nothing? will not hurt later IMHO > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-06-24 16:28 GMT+02:00 Antoine Sabot-Durand > >: > > Ok, but now in the chapter I have mention for Session Scope and > conversation Scope not being active in SE. Wouldn't it be strange to > have no mention of Request Scope or should we make a "temp hack" > saying that session scope is not active... > > Le mer. 24 juin 2015 ? 16:22, Jozef Hartinger > a ?crit : > > Depends on the spec mostly. > > For @RequestScoped there is no natural notion of a request in > plain Java > SE. It's the user that needs to set the boundaries of a task > that the > @RequestScope is supposed to represent. This can be done using > Weld API > and hopefully using ContextControl soon. In the meantime I see > no point > in blurring this with magical contexts that try to guess what > the use wants. > > That means that the context is not active by default but can be > controlled using the API. > > On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote: > > Jozef, > > > > Sorry my question wasn't precise enough. What will be the Request > > Context behavior in your implementation of EDR1 ? > > > > > _______________________________________________ > 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 pmuir at redhat.com Wed Jun 24 10:44:46 2015 From: pmuir at redhat.com (Pete Muir) Date: Wed, 24 Jun 2015 10:44:46 -0400 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: References: <558A6F6E.5070901@redhat.com> <558AB015.9080206@redhat.com> <558ABD13.3010407@redhat.com> Message-ID: <838FBB72-105C-4D97-8E4F-0C93950E1FD1@redhat.com> I agree. The EDR is supposed to be a draft for review. It?s not supposed to be production ready. Add a note saying ?OPEN ISSUE: We need to provide the ability to start the request scope?. In Weld, you can add a release note saying how to do it in Weld. > On 24 Jun 2015, at 10:38, Romain Manni-Bucau wrote: > > What happen if we say nothing? will not hurt later IMHO > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > 2015-06-24 16:28 GMT+02:00 Antoine Sabot-Durand >: > Ok, but now in the chapter I have mention for Session Scope and conversation Scope not being active in SE. Wouldn't it be strange to have no mention of Request Scope or should we make a "temp hack" saying that session scope is not active... > > Le mer. 24 juin 2015 ? 16:22, Jozef Hartinger > a ?crit : > Depends on the spec mostly. > > For @RequestScoped there is no natural notion of a request in plain Java > SE. It's the user that needs to set the boundaries of a task that the > @RequestScope is supposed to represent. This can be done using Weld API > and hopefully using ContextControl soon. In the meantime I see no point > in blurring this with magical contexts that try to guess what the use wants. > > That means that the context is not active by default but can be > controlled using the API. > > On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote: > > Jozef, > > > > Sorry my question wasn't precise enough. What will be the Request > > Context behavior in your implementation of EDR1 ? > > > _______________________________________________ > 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/20150624/a8eec413/attachment.html From antoine at sabot-durand.net Wed Jun 24 10:47:13 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 24 Jun 2015 14:47:13 +0000 Subject: [cdi-dev] Tomorrow's meeting Agenda In-Reply-To: References: Message-ID: Not enough person to make a choice. I'll ask for a vote, but 25th is more probable since John can cross the atlantic to meet us... Le mer. 24 juin 2015 ? 16:38, Antonio Goncalves a ?crit : > Hi all, > > Sorry, I couldn't make it yesterday for the meeting (Tuesday 6pm is quite > difficult for me :o( and I was wondering if you had choosen a date : 18th > or 25th September ? > > Antonio > > On Mon, Jun 22, 2015 at 3:14 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi Guys, >> >> >> Tomorrow, we really need to close EDR1 a go for submission. It should be >> possible since our last discussion point is for Request Context behavior in >> SE. >> >> I?d like also to set the final date of our F2F meeting in Paris (18th or >> 25th September) >> >> Regarding the spec, I think that it would be nice to go for Quick Win >> tickets in Jira to have a rhythm change after the big features we worked on >> since octobre. >> It could be great if you could take one or two ticket that you think are >> quick wins ones and send me them to discuss during the meeting. >> >> What is a quick win ticket? A ticket that you think obvious and easy to >> solve regarding adoption of other EG members and way to solve it. >> >> We?ll check during the meeting if your perception of quick win is shared >> among us ;). >> >> So the agenda is: >> >> 1) Closing the EDR1 >> 2) Closing discussion around F2F date >> 3) Discuss a first list of quick win tickets. Please send your wish list >> to me >> >> >> 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. >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150624/cfaaf309/attachment.html From antoine at sabot-durand.net Wed Jun 24 10:48:41 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 24 Jun 2015 14:48:41 +0000 Subject: [cdi-dev] On @RequestScoped hack In-Reply-To: <838FBB72-105C-4D97-8E4F-0C93950E1FD1@redhat.com> References: <558A6F6E.5070901@redhat.com> <558AB015.9080206@redhat.com> <558ABD13.3010407@redhat.com> <838FBB72-105C-4D97-8E4F-0C93950E1FD1@redhat.com> Message-ID: Ok, I remove all the scopes mention except Application. Le mer. 24 juin 2015 ? 16:44, Pete Muir a ?crit : > I agree. The EDR is supposed to be a draft for review. It?s not supposed > to be production ready. > > Add a note saying ?OPEN ISSUE: We need to provide the ability to start the > request scope?. > > In Weld, you can add a release note saying how to do it in Weld. > > On 24 Jun 2015, at 10:38, Romain Manni-Bucau > wrote: > > What happen if we say nothing? will not hurt later IMHO > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-06-24 16:28 GMT+02:00 Antoine Sabot-Durand > : > >> Ok, but now in the chapter I have mention for Session Scope and >> conversation Scope not being active in SE. Wouldn't it be strange to have >> no mention of Request Scope or should we make a "temp hack" saying that >> session scope is not active... >> >> Le mer. 24 juin 2015 ? 16:22, Jozef Hartinger a >> ?crit : >> >>> Depends on the spec mostly. >>> >>> For @RequestScoped there is no natural notion of a request in plain Java >>> SE. It's the user that needs to set the boundaries of a task that the >>> @RequestScope is supposed to represent. This can be done using Weld API >>> and hopefully using ContextControl soon. In the meantime I see no point >>> in blurring this with magical contexts that try to guess what the use >>> wants. >>> >>> That means that the context is not active by default but can be >>> controlled using the API. >>> >>> On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote: >>> > Jozef, >>> > >>> > Sorry my question wasn't precise enough. What will be the Request >>> > Context behavior in your implementation of EDR1 ? >>> >>> > _______________________________________________ > 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/20150624/cc622f8e/attachment-0001.html From issues at jboss.org Wed Jun 24 10:57:01 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 24 Jun 2015 10:57:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-538) Fix parameterized types discrepancies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-538: ------------------------------------- Fix Version/s: 2.0-EDR1 > Fix parameterized types discrepancies > ------------------------------------- > > Key: CDI-538 > URL: https://issues.jboss.org/browse/CDI-538 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > In the SPI, the spec states the following: > {quote} > * For a producer method with method return type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerMethod}}. > * For a producer field with field type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerField}}. > {quote} > But the Javadoc and impl behavior is > {quote} > * For a producer method with method return type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerMethod}}. > * For a producer field with field type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerField}}. > {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 10:57:01 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 24 Jun 2015 10:57:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-538) Fix parameterized types discrepancies In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-538: ---------------------------------------- Summary: Fix parameterized types discrepancies Key: CDI-538 URL: https://issues.jboss.org/browse/CDI-538 Project: CDI Specification Issues Issue Type: Bug Components: Portable Extensions Affects Versions: 1.2.Final Reporter: Antoine Sabot-Durand In the SPI, the spec states the following: {quote} * For a producer method with method return type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerMethod}}. * For a producer field with field type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerField}}. {quote} But the Javadoc and impl behavior is {quote} * For a producer method with method return type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerMethod}}. * For a producer field with field type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerField}}. {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 10:58:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 24 Jun 2015 10:58:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-538) Fix parameterized types discrepancies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-538: ------------------------------------- Reporter: Antonin Stefanutti (was: Antoine Sabot-Durand) > Fix parameterized types discrepancies > ------------------------------------- > > Key: CDI-538 > URL: https://issues.jboss.org/browse/CDI-538 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.2.Final > Reporter: Antonin Stefanutti > Fix For: 2.0-EDR1 > > > In the SPI, the spec states the following: > {quote} > * For a producer method with method return type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerMethod}}. > * For a producer field with field type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerField}}. > {quote} > But the Javadoc and impl behavior is > {quote} > * For a producer method with method return type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerMethod}}. > * For a producer field with field type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerField}}. > {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From antoine at sabot-durand.net Thu Jun 25 05:19:40 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 25 Jun 2015 11:19:40 +0200 Subject: [cdi-dev] EDR1 ready to be released Message-ID: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> Hi guys, The branch 2.0-EDR1 is ready for release. Beyond the source, you can check javadoc here: https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html And spec here: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html Or PDF version: https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf I have still some work on introduction (major changes, etc?) and on copyright in source files and intend to start release process (three the JCP) tomorrow. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150625/63b8ab91/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150625/63b8ab91/attachment.bin From antoine at sabot-durand.net Thu Jun 25 10:16:43 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 25 Jun 2015 16:16:43 +0200 Subject: [cdi-dev] Let's Sept 25th -26th for our F2F meeting Message-ID: <4C409AF7-57D7-4B62-A82F-B40EC9C778BC@sabot-durand.net> Hi all, So the vote closed on modally. We should have talk about the final date in the last meeting, but there was too much on our plate ;). We have a tie between 18th and 25th, but as John can make it for the 25th and he?s probably the farthest one from Paris to come I propose to keep this date. Regards, Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150625/bf53ea6c/attachment.bin From antonio.goncalves at gmail.com Thu Jun 25 10:27:16 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Thu, 25 Jun 2015 16:27:16 +0200 Subject: [cdi-dev] Let's Sept 25th -26th for our F2F meeting In-Reply-To: <4C409AF7-57D7-4B62-A82F-B40EC9C778BC@sabot-durand.net> References: <4C409AF7-57D7-4B62-A82F-B40EC9C778BC@sabot-durand.net> Message-ID: +1 On Thu, Jun 25, 2015 at 4:16 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > So the vote closed on modally. We should have talk about the final date in > the last meeting, but there was too much on our plate ;). > > We have a tie between 18th and 25th, but as John can make it for the 25th > and he?s probably the farthest one from Paris to come I propose to keep > this date. > > Regards, > > 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150625/fc81250c/attachment.html From jharting at redhat.com Mon Jun 29 05:38:36 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 29 Jun 2015 11:38:36 +0200 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> Message-ID: <5591121C.2090905@redhat.com> How do we deal with the lack of parameter-level @Priority in the meantime? On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: > Hi guys, > > The branch 2.0-EDR1 is ready for release. > > Beyond the source, you can check javadoc here: > https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > > And spec here: > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > > Or PDF version: > https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf > > I have still some work on introduction (major changes, etc?) and on > copyright in source files and intend to start release process (three > the JCP) tomorrow. > > 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/20150629/354fedf6/attachment-0001.html From werner.keil at gmail.com Mon Jun 29 05:50:49 2015 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 29 Jun 2015 11:50:49 +0200 Subject: [cdi-dev] Let's Sept 25th -26th for our F2F meeting Message-ID: +1 As the 25th is a Fri. I am not as far from Paris as at least John (and using CDI a lot here right now;-) so depending on when it'll start on the 25th I hope to make it as early as possible on Fri and all of Sat. Werner On Mon, Jun 29, 2015 at 11:39 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. [JBoss JIRA] (CDI-538) Fix parameterized types discrepancies > (Antoine Sabot-Durand (JIRA)) > 2. [JBoss JIRA] (CDI-538) Fix parameterized types discrepancies > (Antoine Sabot-Durand (JIRA)) > 3. [JBoss JIRA] (CDI-538) Fix parameterized types discrepancies > (Antoine Sabot-Durand (JIRA)) > 4. EDR1 ready to be released (Antoine Sabot-Durand) > 5. Let's Sept 25th -26th for our F2F meeting (Antoine Sabot-Durand) > 6. Re: Let's Sept 25th -26th for our F2F meeting (Antonio Goncalves) > 7. Re: EDR1 ready to be released (Jozef Hartinger) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 24 Jun 2015 10:57:01 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-538) Fix parameterized types > discrepancies > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Antoine Sabot-Durand updated CDI-538: > ------------------------------------- > Fix Version/s: 2.0-EDR1 > > > > Fix parameterized types discrepancies > > ------------------------------------- > > > > Key: CDI-538 > > URL: https://issues.jboss.org/browse/CDI-538 > > Project: CDI Specification Issues > > Issue Type: Bug > > Components: Portable Extensions > > Affects Versions: 1.2.Final > > Reporter: Antoine Sabot-Durand > > Fix For: 2.0-EDR1 > > > > > > In the SPI, the spec states the following: > > {quote} > > * For a producer method with method return type {{X}} of a bean with > bean class {{T}}, the container must raise an event of type > {{ProcessProducerMethod}}. > > * For a producer field with field type {{X}} of a bean with bean class > {{T}}, the container must raise an event of type {{ProcessProducerField X>}}. > > {quote} > > But the Javadoc and impl behavior is > > {quote} > > * For a producer method with method return type {{T}} of a bean with > bean class {{X}}, the container must raise an event of type > {{ProcessProducerMethod}}. > > * For a producer field with field type {{T}} of a bean with bean class > {{X}}, the container must raise an event of type {{ProcessProducerField X>}}. > > {quote} > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) > > > ------------------------------ > > Message: 2 > Date: Wed, 24 Jun 2015 10:57:01 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-538) Fix parameterized types > discrepancies > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Antoine Sabot-Durand created CDI-538: > ---------------------------------------- > > Summary: Fix parameterized types discrepancies > Key: CDI-538 > URL: https://issues.jboss.org/browse/CDI-538 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > > > In the SPI, the spec states the following: > > {quote} > * For a producer method with method return type {{X}} of a bean with bean > class {{T}}, the container must raise an event of type > {{ProcessProducerMethod}}. > * For a producer field with field type {{X}} of a bean with bean class > {{T}}, the container must raise an event of type {{ProcessProducerField X>}}. > {quote} > > But the Javadoc and impl behavior is > > {quote} > * For a producer method with method return type {{T}} of a bean with bean > class {{X}}, the container must raise an event of type > {{ProcessProducerMethod}}. > * For a producer field with field type {{T}} of a bean with bean class > {{X}}, the container must raise an event of type {{ProcessProducerField X>}}. > {quote} > > > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) > > > ------------------------------ > > Message: 3 > Date: Wed, 24 Jun 2015 10:58:02 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-538) Fix parameterized types > discrepancies > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Antoine Sabot-Durand updated CDI-538: > ------------------------------------- > Reporter: Antonin Stefanutti (was: Antoine Sabot-Durand) > > > > Fix parameterized types discrepancies > > ------------------------------------- > > > > Key: CDI-538 > > URL: https://issues.jboss.org/browse/CDI-538 > > Project: CDI Specification Issues > > Issue Type: Bug > > Components: Portable Extensions > > Affects Versions: 1.2.Final > > Reporter: Antonin Stefanutti > > Fix For: 2.0-EDR1 > > > > > > In the SPI, the spec states the following: > > {quote} > > * For a producer method with method return type {{X}} of a bean with > bean class {{T}}, the container must raise an event of type > {{ProcessProducerMethod}}. > > * For a producer field with field type {{X}} of a bean with bean class > {{T}}, the container must raise an event of type {{ProcessProducerField X>}}. > > {quote} > > But the Javadoc and impl behavior is > > {quote} > > * For a producer method with method return type {{T}} of a bean with > bean class {{X}}, the container must raise an event of type > {{ProcessProducerMethod}}. > > * For a producer field with field type {{T}} of a bean with bean class > {{X}}, the container must raise an event of type {{ProcessProducerField X>}}. > > {quote} > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) > > > ------------------------------ > > Message: 4 > Date: Thu, 25 Jun 2015 11:19:40 +0200 > From: Antoine Sabot-Durand > Subject: [cdi-dev] EDR1 ready to be released > To: cdi-dev > Message-ID: <0E18098B-212C-4183-9772-560430AFA89E at sabot-durand.net> > Content-Type: text/plain; charset="utf-8" > > Hi guys, > > The branch 2.0-EDR1 is ready for release. > > Beyond the source, you can check javadoc here: > https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html < > https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html> > > And spec here: > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html < > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html> > > Or PDF version: > https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf < > https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf> > > I have still some work on introduction (major changes, etc?) and on > copyright in source files and intend to start release process (three the > JCP) tomorrow. > > Antoine > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150625/63b8ab91/attachment-0001.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 495 bytes > Desc: Message signed with OpenPGP using GPGMail > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150625/63b8ab91/attachment-0001.bin > > ------------------------------ > > Message: 5 > Date: Thu, 25 Jun 2015 16:16:43 +0200 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Let's Sept 25th -26th for our F2F meeting > To: cdi-dev > Message-ID: <4C409AF7-57D7-4B62-A82F-B40EC9C778BC at sabot-durand.net> > Content-Type: text/plain; charset="utf-8" > > Hi all, > > So the vote closed on modally. We should have talk about the final date in > the last meeting, but there was too much on our plate ;). > > We have a tie between 18th and 25th, but as John can make it for the 25th > and he?s probably the farthest one from Paris to come I propose to keep > this date. > > Regards, > > Antoine > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 495 bytes > Desc: Message signed with OpenPGP using GPGMail > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150625/bf53ea6c/attachment-0001.bin > > ------------------------------ > > Message: 6 > Date: Thu, 25 Jun 2015 16:27:16 +0200 > From: Antonio Goncalves > Subject: Re: [cdi-dev] Let's Sept 25th -26th for our F2F meeting > To: Antoine Sabot-Durand > Cc: cdi-dev > Message-ID: > yyQfethzEzBb3SY-wWBXFxT-RvG_2nFsnqcEmXfQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > +1 > > On Thu, Jun 25, 2015 at 4:16 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > > Hi all, > > > > So the vote closed on modally. We should have talk about the final date > in > > the last meeting, but there was too much on our plate ;). > > > > We have a tie between 18th and 25th, but as John can make it for the 25th > > and he?s probably the farthest one from Paris to come I propose to keep > > this date. > > > > Regards, > > > > 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. > > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn < > http://www.linkedin.com/in/agoncal> | > Pluralsight > | > Paris > JUG | Devoxx France > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150625/fc81250c/attachment-0001.html > > ------------------------------ > > Message: 7 > Date: Mon, 29 Jun 2015 11:38:36 +0200 > From: Jozef Hartinger > Subject: Re: [cdi-dev] EDR1 ready to be released > To: Antoine Sabot-Durand , cdi-dev > > Message-ID: <5591121C.2090905 at redhat.com> > Content-Type: text/plain; charset="windows-1252" > > How do we deal with the lack of parameter-level @Priority in the meantime? > > On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: > > Hi guys, > > > > The branch 2.0-EDR1 is ready for release. > > > > Beyond the source, you can check javadoc here: > > https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > > > > And spec here: > > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > > > > Or PDF version: > > https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf > > > > I have still some work on introduction (major changes, etc?) and on > > copyright in source files and intend to start release process (three > > the JCP) tomorrow. > > > > 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/20150629/354fedf6/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 55, Issue 37 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/954fe955/attachment-0001.html From antoine at sabot-durand.net Mon Jun 29 06:19:59 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 29 Jun 2015 10:19:59 +0000 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: <5591121C.2090905@redhat.com> References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <5591121C.2090905@redhat.com> Message-ID: Hi Jozef, I thought you didn't like to have temp stuff in the spec, so fr me it was obvious that we should use the weld experimental package. Any thoughts? Antoine Le lun. 29 juin 2015 ? 11:38, Jozef Hartinger a ?crit : > How do we deal with the lack of parameter-level @Priority in the meantime? > > > On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: > > Hi guys, > > The branch 2.0-EDR1 is ready for release. > > Beyond the source, you can check javadoc here: > https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > > And spec here: > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > > Or PDF version: > https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf > > I have still some work on introduction (major changes, etc?) and on > copyright in source files and intend to start release process (three the > JCP) tomorrow. > > Antoine > > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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/20150629/6d92cd6e/attachment.html From jharting at redhat.com Mon Jun 29 06:44:34 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 29 Jun 2015 12:44:34 +0200 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <5591121C.2090905@redhat.com> Message-ID: <55912192.9080202@redhat.com> Hi Antoine, I dislike inventing temporary behavior. For @Priority there seems to be consensus about the observer ordering behavior already. We just need a way to enable it until the annotations spec is updated. Weld experimental package will work fine. Jozef On 06/29/2015 12:19 PM, Antoine Sabot-Durand wrote: > Hi Jozef, > > I thought you didn't like to have temp stuff in the spec, so fr me it > was obvious that we should use the weld experimental package. > Any thoughts? > > Antoine > Le lun. 29 juin 2015 ? 11:38, Jozef Hartinger > a ?crit : > > How do we deal with the lack of parameter-level @Priority in the > meantime? > > > On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: >> Hi guys, >> >> The branch 2.0-EDR1 is ready for release. >> >> Beyond the source, you can check javadoc here: >> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html >> >> And spec here: >> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html >> >> Or PDF version: >> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf >> >> I have still some work on introduction (major changes, etc?) and >> on copyright in source files and intend to start release process >> (three the JCP) tomorrow. >> >> 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/20150629/fc05ec5b/attachment.html From rmannibucau at gmail.com Mon Jun 29 06:51:07 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 29 Jun 2015 12:51:07 +0200 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: <55912192.9080202@redhat.com> References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <5591121C.2090905@redhat.com> <55912192.9080202@redhat.com> Message-ID: Isnt endorsing an option? Weld can provide its endorsed-API bundle no? Le 29 juin 2015 03:44, "Jozef Hartinger" a ?crit : > Hi Antoine, > > I dislike inventing temporary behavior. For @Priority there seems to be > consensus about the observer ordering behavior already. We just need a way > to enable it until the annotations spec is updated. Weld experimental > package will work fine. > > Jozef > > On 06/29/2015 12:19 PM, Antoine Sabot-Durand wrote: > > Hi Jozef, > > I thought you didn't like to have temp stuff in the spec, so fr me it was > obvious that we should use the weld experimental package. > Any thoughts? > > Antoine > Le lun. 29 juin 2015 ? 11:38, Jozef Hartinger a > ?crit : > >> How do we deal with the lack of parameter-level @Priority in the >> meantime? >> >> >> On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: >> >> Hi guys, >> >> The branch 2.0-EDR1 is ready for release. >> >> Beyond the source, you can check javadoc here: >> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html >> >> And spec here: >> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html >> >> Or PDF version: >> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf >> >> I have still some work on introduction (major changes, etc?) and on >> copyright in source files and intend to start release process (three the >> JCP) tomorrow. >> >> Antoine >> >> >> _______________________________________________ >> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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/20150629/563a3693/attachment.html From jharting at redhat.com Mon Jun 29 08:13:59 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 29 Jun 2015 14:13:59 +0200 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <5591121C.2090905@redhat.com> <55912192.9080202@redhat.com> Message-ID: <55913687.2040207@redhat.com> That would work though given the extra steps to set up endorsed dir it will be simpler to use the experimental package for now I guess? On 06/29/2015 12:51 PM, Romain Manni-Bucau wrote: > > Isnt endorsing an option? Weld can provide its endorsed-API bundle no? > > Le 29 juin 2015 03:44, "Jozef Hartinger" > a ?crit : > > Hi Antoine, > > I dislike inventing temporary behavior. For @Priority there seems > to be consensus about the observer ordering behavior already. We > just need a way to enable it until the annotations spec is > updated. Weld experimental package will work fine. > > Jozef > > On 06/29/2015 12:19 PM, Antoine Sabot-Durand wrote: >> Hi Jozef, >> >> I thought you didn't like to have temp stuff in the spec, so fr >> me it was obvious that we should use the weld experimental package. >> Any thoughts? >> >> Antoine >> Le lun. 29 juin 2015 ? 11:38, Jozef Hartinger >> > a ?crit : >> >> How do we deal with the lack of parameter-level @Priority in >> the meantime? >> >> >> On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: >>> Hi guys, >>> >>> The branch 2.0-EDR1 is ready for release. >>> >>> Beyond the source, you can check javadoc here: >>> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html >>> >>> And spec here: >>> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html >>> >>> Or PDF version: >>> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf >>> >>> I have still some work on introduction (major changes, etc?) >>> and on copyright in source files and intend to start release >>> process (three the JCP) tomorrow. >>> >>> Antoine >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/df6c86e1/attachment-0001.html From jharting at redhat.com Mon Jun 29 08:17:12 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 29 Jun 2015 14:17:12 +0200 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> Message-ID: <55913748.2050108@redhat.com> I noticed there's a new isAsync() method in the ObserverMethod interface. That is a breaking change. We'll need to use a default method or some other way that does not break existing OM implementations. Jozef On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: > Hi guys, > > The branch 2.0-EDR1 is ready for release. > > Beyond the source, you can check javadoc here: > https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > > And spec here: > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > > Or PDF version: > https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf > > I have still some work on introduction (major changes, etc?) and on > copyright in source files and intend to start release process (three > the JCP) tomorrow. > > 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/20150629/362d68a5/attachment.html From antoine at sabot-durand.net Mon Jun 29 08:36:22 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 29 Jun 2015 12:36:22 +0000 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: <55913748.2050108@redhat.com> References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <55913748.2050108@redhat.com> Message-ID: I noticed there's a new isAsync() method in the ObserverMethod interface. > It was a correction after one of your feedback: https://github.com/cdi-spec/cdi/pull/250#issuecomment-112107108 There's the same in EventMetaData > That is a breaking change. We'll need to use a default method or some > other way that does not break existing OM implementations. > No problem to switch to private method. Sorry for the naive question but I need to understand, why this change is "breaking" while the ones in CDIProvider are not? More widely how did you manage to add all these new methods in BeanManager for CDI 1.1 without introducing breaking change as well? Antoine > > > Jozef > > > On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: > > Hi guys, > > The branch 2.0-EDR1 is ready for release. > > Beyond the source, you can check javadoc here: > https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > > And spec here: > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > > Or PDF version: > https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf > > I have still some work on introduction (major changes, etc?) and on > copyright in source files and intend to start release process (three the > JCP) tomorrow. > > Antoine > > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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/20150629/f6c01cae/attachment.html From antoine at sabot-durand.net Mon Jun 29 08:45:24 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 29 Jun 2015 12:45:24 +0000 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: <55913687.2040207@redhat.com> References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <5591121C.2090905@redhat.com> <55912192.9080202@redhat.com> <55913687.2040207@redhat.com> Message-ID: Weld experimental is my favorite, because it clearly states that it's not final. I agree with Jozef, that we should avoid adding classes that are obviously temporary in the API if we can. Endorsement add extra steps making the code evaluation harder IMO. and code evaluation by our users is our main target here. Antoine Le lun. 29 juin 2015 ? 14:14, Jozef Hartinger a ?crit : > That would work though given the extra steps to set up endorsed dir it > will be simpler to use the experimental package for now I guess? > > > On 06/29/2015 12:51 PM, Romain Manni-Bucau wrote: > > Isnt endorsing an option? Weld can provide its endorsed-API bundle no? > Le 29 juin 2015 03:44, "Jozef Hartinger" a ?crit : > >> Hi Antoine, >> >> I dislike inventing temporary behavior. For @Priority there seems to be >> consensus about the observer ordering behavior already. We just need a way >> to enable it until the annotations spec is updated. Weld experimental >> package will work fine. >> >> Jozef >> >> On 06/29/2015 12:19 PM, Antoine Sabot-Durand wrote: >> >> Hi Jozef, >> >> I thought you didn't like to have temp stuff in the spec, so fr me it was >> obvious that we should use the weld experimental package. >> Any thoughts? >> >> Antoine >> Le lun. 29 juin 2015 ? 11:38, Jozef Hartinger a >> ?crit : >> >>> How do we deal with the lack of parameter-level @Priority in the >>> meantime? >>> >>> >>> On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: >>> >>> Hi guys, >>> >>> The branch 2.0-EDR1 is ready for release. >>> >>> Beyond the source, you can check javadoc here: >>> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html >>> >>> And spec here: >>> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html >>> >>> Or PDF version: >>> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf >>> >>> I have still some work on introduction (major changes, etc?) and on >>> copyright in source files and intend to start release process (three the >>> JCP) tomorrow. >>> >>> Antoine >>> >>> >>> _______________________________________________ >>> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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/20150629/4e148a5e/attachment.html From struberg at yahoo.de Mon Jun 29 09:33:36 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 29 Jun 2015 15:33:36 +0200 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <55913748.2050108@redhat.com> Message-ID: <2798CF0B-86A7-408F-9BB1-EBA6CA5D553E@yahoo.de> adding new methods to the BeanManager is not a problem. I think there are not that many implementations of the BeanManager interface in customer projects ;) But for CDI SPI event interfaces like ObserverMethod, Producer, etc there ARE such impls in customer projects. Thus we need a default method in the interface for those . LieGrue, strub > Am 29.06.2015 um 14:36 schrieb Antoine Sabot-Durand : > > > > > I noticed there's a new isAsync() method in the ObserverMethod interface. > > It was a correction after one of your feedback: https://github.com/cdi-spec/cdi/pull/250#issuecomment-112107108 > > There's the same in EventMetaData > > That is a breaking change. We'll need to use a default method or some other way that does not break existing OM implementations. > > No problem to switch to private method. > Sorry for the naive question but I need to understand, why this change is "breaking" while the ones in CDIProvider are not? > > More widely how did you manage to add all these new methods in BeanManager for CDI 1.1 without introducing breaking change as well? > > Antoine > > > > Jozef > > > On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: >> Hi guys, >> >> The branch 2.0-EDR1 is ready for release. >> >> Beyond the source, you can check javadoc here: >> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html >> >> And spec here: >> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html >> >> Or PDF version: >> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf >> >> I have still some work on introduction (major changes, etc?) and on copyright in source files and intend to start release process (three the JCP) tomorrow. >> >> Antoine >> >> >> _______________________________________________ >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From antonio.goncalves at gmail.com Mon Jun 29 09:43:14 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 29 Jun 2015 15:43:14 +0200 Subject: [cdi-dev] Meeting at GeeCon Prague ? Message-ID: Hi guys, Don't know if some of you will be at GeeCon Prague in October (22nd//23rd of October). If yes, we could maybe organize a meeting. And I know that some of the Jersey team is also based in Prague. It would be great to have the JAX-RS and CDI team talking about possible improvments. WDYT ? -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/72272764/attachment.html From antoine at sabot-durand.net Mon Jun 29 10:40:53 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 29 Jun 2015 14:40:53 +0000 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: <2798CF0B-86A7-408F-9BB1-EBA6CA5D553E@yahoo.de> References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <55913748.2050108@redhat.com> <2798CF0B-86A7-408F-9BB1-EBA6CA5D553E@yahoo.de> Message-ID: Ok, thanks Mark. I realized how naive my question was ;). Le lun. 29 juin 2015 ? 15:33, Mark Struberg a ?crit : > adding new methods to the BeanManager is not a problem. I think there are > not that many implementations of the BeanManager interface in customer > projects ;) > > But for CDI SPI event interfaces like ObserverMethod, Producer, etc there > ARE such impls in customer projects. Thus we need a default method in the > interface for those . > > LieGrue, > strub > > > > Am 29.06.2015 um 14:36 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > > > > > > > > > I noticed there's a new isAsync() method in the ObserverMethod interface. > > > > It was a correction after one of your feedback: > https://github.com/cdi-spec/cdi/pull/250#issuecomment-112107108 > > > > There's the same in EventMetaData > > > > That is a breaking change. We'll need to use a default method or some > other way that does not break existing OM implementations. > > > > No problem to switch to private method. > > Sorry for the naive question but I need to understand, why this change > is "breaking" while the ones in CDIProvider are not? > > > > More widely how did you manage to add all these new methods in > BeanManager for CDI 1.1 without introducing breaking change as well? > > > > Antoine > > > > > > > > Jozef > > > > > > On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: > >> Hi guys, > >> > >> The branch 2.0-EDR1 is ready for release. > >> > >> Beyond the source, you can check javadoc here: > >> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > >> > >> And spec here: > >> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > >> > >> Or PDF version: > >> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf > >> > >> I have still some work on introduction (major changes, etc?) and on > copyright in source files and intend to start release process (three the > JCP) tomorrow. > >> > >> Antoine > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> > >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/be20537d/attachment.html From issues at jboss.org Mon Jun 29 11:01:03 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:01:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-536) Redundant statement in "2.6.2. Default bean names" chapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-536: ------------------------------------- Fix Version/s: 2.0-EDR1 > Redundant statement in "2.6.2. Default bean names" chapter > ---------------------------------------------------------- > > Key: CDI-536 > URL: https://issues.jboss.org/browse/CDI-536 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Priority: Minor > Fix For: 2.0-EDR1 > > > This chapter currently says: > {quote} > In the following circumstances, a default name must be assigned by the container: > - A bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified by the value member. > {quote} > and then: > {quote} > If a bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified the value of the value member is defaulted. > {quote} > These 2 statements declare the same IMO. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:03:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:03:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-536) Redundant statement in "2.6.2. Default bean names" chapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-536. -------------------------------------- Assignee: Antoine Sabot-Durand Resolution: Done > Redundant statement in "2.6.2. Default bean names" chapter > ---------------------------------------------------------- > > Key: CDI-536 > URL: https://issues.jboss.org/browse/CDI-536 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Priority: Minor > Fix For: 2.0-EDR1 > > > This chapter currently says: > {quote} > In the following circumstances, a default name must be assigned by the container: > - A bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified by the value member. > {quote} > and then: > {quote} > If a bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified the value of the value member is defaulted. > {quote} > These 2 statements declare the same IMO. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:13:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:13:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-534) Section 3.8 on CDI 1.2 spec javax.security.Principal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-534. ------------------------------------ Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 Resolution: Done Was in section 17.8 after CDI-160. > Section 3.8 on CDI 1.2 spec javax.security.Principal > ---------------------------------------------------- > > Key: CDI-534 > URL: https://issues.jboss.org/browse/CDI-534 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > Assignee: Antoine Sabot-Durand > Priority: Minor > Fix For: 2.0-EDR1 > > > In section 3.8 Additional built-in beans > a bean with bean type javax.security.Principal, allowing injection of a Principal > representing the current caller identity. > javax.security.Principle should be java.security.Principal. > The same typo exists in CDI 1.0, 1.1 and 1.2. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:15:05 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:15:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-528) Minor inconsistency in Built-in qualifiers chapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-528: ------------------------------------- Fix Version/s: 2.0 (discussion) > Minor inconsistency in Built-in qualifiers chapter > -------------------------------------------------- > > Key: CDI-528 > URL: https://issues.jboss.org/browse/CDI-528 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Tomas Remes > Priority: Minor > Fix For: 2.0 (discussion) > > > 2.3.1. Built-in qualifier types states: > {quote} > If a bean does not explicitly declare a qualifier other than @Named , the bean has exactly one additional qualifier, of type @Default . > {quote} > This means that following bean has @Named, @Default, @Any qualifiers: > {code} > @Named > public class Dog {} > {code} > but this one is not required to have @Default qualifier: > {code} > @Named > @Any > public class Dog {} > {code} > It doesn't make much sense IMHO. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:15:05 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:15:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-528) Minor inconsistency in Built-in qualifiers chapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-528: ---------------------------------------- Assignee: Antoine Sabot-Durand > Minor inconsistency in Built-in qualifiers chapter > -------------------------------------------------- > > Key: CDI-528 > URL: https://issues.jboss.org/browse/CDI-528 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Priority: Minor > Fix For: 2.0 (discussion) > > > 2.3.1. Built-in qualifier types states: > {quote} > If a bean does not explicitly declare a qualifier other than @Named , the bean has exactly one additional qualifier, of type @Default . > {quote} > This means that following bean has @Named, @Default, @Any qualifiers: > {code} > @Named > public class Dog {} > {code} > but this one is not required to have @Default qualifier: > {code} > @Named > @Any > public class Dog {} > {code} > It doesn't make much sense IMHO. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:16:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:16:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-524) CDI spec make reference to Java EE 6. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-524: ------------------------------------- Issue Type: Bug (was: Epic) > CDI spec make reference to Java EE 6. > ------------------------------------- > > Key: CDI-524 > URL: https://issues.jboss.org/browse/CDI-524 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Andersson > Priority: Minor > > Section "1.2.1. Relationship to the Java EE platform specification" says: > {quote} > In the Java EE 6 environment, all component classes supporting injection, as defined by the Java EE 6 platform specification, may inject beans via the dependency injection service. > {quote} > The reference should be made to EE 7? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:19:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:19:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-524) CDI spec make reference to Java EE 6. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-524. -------------------------------------- Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 Resolution: Done switch to Java EE. > CDI spec make reference to Java EE 6. > ------------------------------------- > > Key: CDI-524 > URL: https://issues.jboss.org/browse/CDI-524 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Andersson > Assignee: Antoine Sabot-Durand > Priority: Minor > Fix For: 2.0-EDR1 > > > Section "1.2.1. Relationship to the Java EE platform specification" says: > {quote} > In the Java EE 6 environment, all component classes supporting injection, as defined by the Java EE 6 platform specification, may inject beans via the dependency injection service. > {quote} > The reference should be made to EE 7? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:20:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:20:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-519) Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-519: ------------------------------------- Fix Version/s: 2.0 (discussion) > Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object > ------------------------------------------------------------------------------------------------------ > > Key: CDI-519 > URL: https://issues.jboss.org/browse/CDI-519 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > 5.6.1. The Instance interface: > {quote} > The method destroy() instructs the container to destroy the instance. The bean instance passed to destroy() should be *a dependent scoped bean instance*, or... > {quote} > I think this should be more obvious. E.g. this wouldn't work correctly even though it doesn't violate the spec: > {code:java} > @Dependent > class Bar { > } > class Foo { > @Inject > Instance instance; > void ping() { > instance.destroy(CDI.current().select(Bar.class).get()); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:44:11 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:44:11 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-506) '10.4.4. Conditional observer methods' - specifies incorrect Element name for @Observes annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-506. -------------------------------------- Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 Resolution: Done > '10.4.4. Conditional observer methods' - specifies incorrect Element name for @Observes annotation > -------------------------------------------------------------------------------------------------- > > Key: CDI-506 > URL: https://issues.jboss.org/browse/CDI-506 > Project: CDI Specification Issues > Issue Type: Bug > Environment: --NA-- (Documentation issue) > Reporter: Abhishek Gupta > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > Section 10.4.4. Conditional observer methods' - specifies 'receive' as the element name for the @Observes annotation. The correct element should be 'notifyObserver' as per Javadocs http://bit.ly/16PfyhD > public void refreshOnDocumentUpdate(@Observes(notifyObserver=IF_EXISTS) @Updated Document doc) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:46:05 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:46:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-502: ------------------------------------- Fix Version/s: 2.0-EDR1 > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > Fix For: 2.0 (discussion) > > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:46:06 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:46:06 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-502: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: 2.0-EDR1) > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > Fix For: 2.0 (discussion) > > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:46:06 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:46:06 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-502: ---------------------------------------- Assignee: Antoine Sabot-Durand > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:47:05 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:47:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata injection for EE components In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-500: ------------------------------------- Fix Version/s: 2.0 (discussion) > Clarify @Intercepted Bean metadata injection for EE components > -------------------------------------------------------------- > > Key: CDI-500 > URL: https://issues.jboss.org/browse/CDI-500 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component. > See the CDI spec, "5.5.8. Bean metadata": > {quote} > Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate: > * a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and > * ... > {quote} > However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection": > {quote} > The component classes listed in Table EE.5-1 with support level "Standard" > all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled?which it is by default?these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors. > {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 11:49:03 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 11:49:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-490: ------------------------------------- Fix Version/s: 2.0 (discussion) > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:01:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:01:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-531) CDI JavaDocs link to Extension Architecture broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-531. -------------------------------------- Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 Resolution: Done Correct link was in Jar specification : https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#sealing > CDI JavaDocs link to Extension Architecture broken > -------------------------------------------------- > > Key: CDI-531 > URL: https://issues.jboss.org/browse/CDI-531 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Joseph Snyder > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > It appears that the Java SE team have moved their "Extension Architecture" documentation. This invalidates the link in the CDI JavaDocs we publish as follows: > In the file: > cdi-api-1.2-sources\javax\enterprise\inject\Vetoed.java > Is a link in the meta data for JavaDoc: > > Which returns <404>, file not found. > I suspect this is now moved to: > https://docs.oracle.com/javase/8/docs/technotes/guides/extensions/spec.html > But I can't be sure because there's no Anchor titled "sealing" in that moved document. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:05:03 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:05:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-510) Update JCP license In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-510. -------------------------------------- Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 Resolution: Done > Update JCP license > ------------------ > > Key: CDI-510 > URL: https://issues.jboss.org/browse/CDI-510 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > Update the JCP license file to reflect CDI 2.0, JSR 365 (instead of JSR 346) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:06:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:06:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-498) Revise "6.7.5. The Conversation interface" - dots are not valid in EL name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-498: ------------------------------------- Fix Version/s: 2.0 (discussion) > Revise "6.7.5. The Conversation interface" - dots are not valid in EL name > -------------------------------------------------------------------------- > > Key: CDI-498 > URL: https://issues.jboss.org/browse/CDI-498 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Fix For: 2.0 (discussion) > > > Seems that following part contradicts the EL spec: > {quote}The container provides a built-in bean with bean type Conversation , scope @RequestScoped , > and qualifier @Default , named javax.enterprise.context.conversation .{quote} > The EL name "javax.enterprise.context.conversation" is not valid. > Discussion available at http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23cdi-dev.2015-01-06.log.html > and > http://lists.jboss.org/pipermail/cdi-dev/2015-January/thread.html - topic "where is defined javax.enterprise.context.conversation.id?" -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:07:03 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:07:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java in javax.enterprise.inject package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-477: ------------------------------------- Fix Version/s: 2.0 (discussion) > Update outdated package-info.java in javax.enterprise.inject package > -------------------------------------------------------------------- > > Key: CDI-477 > URL: https://issues.jboss.org/browse/CDI-477 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Update or remove this javadoc. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:07:03 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:07:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-456: ------------------------------------- Fix Version/s: 2.0 (discussion) > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:08:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:08:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-449) beans.xml examples are not valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-449: ------------------------------------- Fix Version/s: 2.0 (discussion) > beans.xml examples are not valid > -------------------------------- > > Key: CDI-449 > URL: https://issues.jboss.org/browse/CDI-449 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well. > The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:09:03 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:09:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-523: ------------------------------------- Fix Version/s: 2.0 (discussion) > CDI spec tries to dispose a container-managed entity manager. > ------------------------------------------------------------- > > Key: CDI-523 > URL: https://issues.jboss.org/browse/CDI-523 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final, 1.1.Final > Reporter: Martin Andersson > Fix For: 2.0 (discussion) > > > Section "3.5.2. Declaring a disposer method" has this example: > {code:java} > public class Resources { > @PersistenceContext > @Produces @UserDatabase > private EntityManager em; > > public void close(@Disposes @UserDatabase EntityManager em) { > em.close(); > } > } > {code} > The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says: > {quote} > The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager. > {quote} > This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java]. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:11:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:11:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-438: ------------------------------------- Fix Version/s: 2.0 (discussion) > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod. > {quote} > API: > {code:java} > /** > * @param The return type of the producer method > * @param The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod extends ProcessBean { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:31:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:31:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084678#comment-13084678 ] Antoine Sabot-Durand commented on CDI-438: ------------------------------------------ Spec was corrected with CDI-538. I removed the comment in API. I'm afraid we have to keep this "wrong order" in API. therefore it becomes the "right order". With this change done, is there still any reason to prevent delivering of {{ProcessProducerMethod}} to observer of {{ProcessBean}}? I think it could make sense in certain use cases... > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod. > {quote} > API: > {code:java} > /** > * @param The return type of the producer method > * @param The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod extends ProcessBean { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:31:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:31:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-438: ---------------------------------------- Assignee: Antoine Sabot-Durand > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod. > {quote} > API: > {code:java} > /** > * @param The return type of the producer method > * @param The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod extends ProcessBean { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:33:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:33:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-416) Typo for @PersistencContext at section 7.3.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-416. -------------------------------------- Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 Resolution: Done > Typo for @PersistencContext at section 7.3.6 > -------------------------------------------- > > Key: CDI-416 > URL: https://issues.jboss.org/browse/CDI-416 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Michel Graciano > Assignee: Antoine Sabot-Durand > Priority: Minor > Fix For: 2.0-EDR1 > > > At section 7.3.6 [1] there is a typo for @PersistencContext where it should be @PersistenceContext. > [1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#resource_lifecycle -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:39:06 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:39:06 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-409) Having @Alternatives for resource definition In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-409: ------------------------------------- Issue Type: Feature Request (was: Bug) > Having @Alternatives for resource definition > -------------------------------------------- > > Key: CDI-409 > URL: https://issues.jboss.org/browse/CDI-409 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: TBD > Reporter: Antonio Goncalves > > Java EE 6 introduced @DataSourceDefinition and Java EE 7 introduced the same way of defining other resources (JMS factory/destination, Mail factory, JCA connectors....). > It would be interesting to have @Alternatives working with these resource definitions. For example you could have a default DS for development : > {code} > @DataSourceDefinition( > className = "org.apache.derby.jdbc.EmbeddedDataSource", > name = "java:global/jdbc/devDS", > user = "dev", > password = "dev", > databaseName = "dev", > properties = {"connectionAttributes=;create=true"} > ) > public class DevResources {...} > {code} > And another DS that would be used, let say, in production as an alternative : > {code} > @Alternative > @DataSourceDefinition( > className = "org.apache.derby.jdbc.EmbeddedDataSource", > name = "java:global/jdbc/prodDS", > user = "prod", > password = "prod", > databaseName = "prod", > properties = {"connectionAttributes=;create=true"} > ) > public class ProdResources {...} > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:39:07 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:39:07 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-414: ------------------------------------- Fix Version/s: 2.0 (discussion) > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:39:07 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:39:07 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'detected' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-420: ------------------------------------- Fix Version/s: 2.0 (discussion) > add a bean-discovery-mode 'detected' > ------------------------------------ > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:40:03 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:40:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-435) cdi-spec.org/faq outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-435: ------------------------------------- Fix Version/s: 2.0 (proposed) > cdi-spec.org/faq outdated > ------------------------- > > Key: CDI-435 > URL: https://issues.jboss.org/browse/CDI-435 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Frequently asked questions at http://www.cdi-spec.org/faq/ are outdated - mostly in sync with CDI 1.0 or CDI 1.1. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 12:52:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 12:52:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-501. -------------------------------------- Assignee: Antoine Sabot-Durand Resolution: Done Was stated during CDI-499 writing > Firing and consuming events should take place in the same thread > ---------------------------------------------------------------- > > Key: CDI-501 > URL: https://issues.jboss.org/browse/CDI-501 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jos? Paumard > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload. > All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state. > The issue is the following : > - the payload object is not specified, it can then be mutable, non-synchronized etc... > - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread. > So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise. > Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From struberg at yahoo.de Mon Jun 29 13:05:27 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 29 Jun 2015 19:05:27 +0200 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: <55912192.9080202@redhat.com> References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <5591121C.2090905@redhat.com> <55912192.9080202@redhat.com> Message-ID: <3D2A8E53-BB91-4834-96EF-5564EC6795D8@yahoo.de> Please correct me if I got this wrong, you like to have a org.boss.weld package in the EDR wording? In that case a strict -1 for any org.jboss.weld package in the official spec EDR! That?s a total no-go and is legally not possible as you would force ALL implementors to break trademark laws. This would also probably (in extremis) diminish the Weld trademark? So this is something I guess JBoss would like to prevent as well? LieGrue, strub > Am 29.06.2015 um 12:44 schrieb Jozef Hartinger : > > Hi Antoine, > > I dislike inventing temporary behavior. For @Priority there seems to be consensus about the observer ordering behavior already. We just need a way to enable it until the annotations spec is updated. Weld experimental package will work fine. > > Jozef > > On 06/29/2015 12:19 PM, Antoine Sabot-Durand wrote: >> Hi Jozef, >> >> I thought you didn't like to have temp stuff in the spec, so fr me it was obvious that we should use the weld experimental package. >> Any thoughts? >> >> Antoine >> Le lun. 29 juin 2015 ? 11:38, Jozef Hartinger a ?crit : >> How do we deal with the lack of parameter-level @Priority in the meantime? >> >> >> On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: >>> Hi guys, >>> >>> The branch 2.0-EDR1 is ready for release. >>> >>> Beyond the source, you can check javadoc here: >>> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html >>> >>> And spec here: >>> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html >>> >>> Or PDF version: >>> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf >>> >>> I have still some work on introduction (major changes, etc?) and on copyright in source files and intend to start release process (three the JCP) tomorrow. >>> >>> Antoine >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From rmannibucau at gmail.com Mon Jun 29 13:09:48 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 29 Jun 2015 10:09:48 -0700 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: <3D2A8E53-BB91-4834-96EF-5564EC6795D8@yahoo.de> References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <5591121C.2090905@redhat.com> <55912192.9080202@redhat.com> <3D2A8E53-BB91-4834-96EF-5564EC6795D8@yahoo.de> Message-ID: think javax.cdi.experimental.Priority would be a compromise (using cdi and not enterprise is surely better since it is not aligned on other packages and clearly states where it comes from for experimental stuff) Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-06-29 10:05 GMT-07:00 Mark Struberg : > Please correct me if I got this wrong, you like to have a org.boss.weld > package in the EDR wording? > > In that case a strict -1 for any org.jboss.weld package in the official > spec EDR! > That?s a total no-go and is legally not possible as you would force ALL > implementors to break trademark laws. > This would also probably (in extremis) diminish the Weld trademark? So > this is something I guess JBoss would like to prevent as well? > > LieGrue, > strub > > > Am 29.06.2015 um 12:44 schrieb Jozef Hartinger : > > > > Hi Antoine, > > > > I dislike inventing temporary behavior. For @Priority there seems to be > consensus about the observer ordering behavior already. We just need a way > to enable it until the annotations spec is updated. Weld experimental > package will work fine. > > > > Jozef > > > > On 06/29/2015 12:19 PM, Antoine Sabot-Durand wrote: > >> Hi Jozef, > >> > >> I thought you didn't like to have temp stuff in the spec, so fr me it > was obvious that we should use the weld experimental package. > >> Any thoughts? > >> > >> Antoine > >> Le lun. 29 juin 2015 ? 11:38, Jozef Hartinger a > ?crit : > >> How do we deal with the lack of parameter-level @Priority in the > meantime? > >> > >> > >> On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: > >>> Hi guys, > >>> > >>> The branch 2.0-EDR1 is ready for release. > >>> > >>> Beyond the source, you can check javadoc here: > >>> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > >>> > >>> And spec here: > >>> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > >>> > >>> Or PDF version: > >>> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf > >>> > >>> I have still some work on introduction (major changes, etc?) and on > copyright in source files and intend to start release process (three the > JCP) tomorrow. > >>> > >>> 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. > > > _______________________________________________ > 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/20150629/6abc6391/attachment-0001.html From antoine at sabot-durand.net Mon Jun 29 15:43:41 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 29 Jun 2015 19:43:41 +0000 Subject: [cdi-dev] EDR1 ready to be released In-Reply-To: <3D2A8E53-BB91-4834-96EF-5564EC6795D8@yahoo.de> References: <0E18098B-212C-4183-9772-560430AFA89E@sabot-durand.net> <5591121C.2090905@redhat.com> <55912192.9080202@redhat.com> <3D2A8E53-BB91-4834-96EF-5564EC6795D8@yahoo.de> Message-ID: > Please correct me if I got this wrong, you like to have a org.boss.weld > package in the EDR wording? > You're wrong. Nobody's proposed such a thing. But to be sure, you might want to re-read carefully the spec (nice trick to have another review on the spec split ;) ). More seriously, the spec mention @Priority from commons annotation and it will stay like that, because it's the target. Wether we keep it in weld or move it in an experimental package in the spec, this content will not change. I'll write a blog post explaining why user can't use the official @Priority yet and what package to use in the meantime. I said I find more consistent to have it in Weld experimental, because we said last week that we didn't want to put temp feature in the spec & API. > In that case a strict -1 for any org.jboss.weld package in the official > spec EDR! > That?s a total no-go and is legally not possible as you would force ALL > implementors to break trademark laws. > This would also probably (in extremis) diminish the Weld trademark? So > this is something I guess JBoss would like to prevent as well? > > LieGrue, > strub > > > Am 29.06.2015 um 12:44 schrieb Jozef Hartinger : > > > > Hi Antoine, > > > > I dislike inventing temporary behavior. For @Priority there seems to be > consensus about the observer ordering behavior already. We just need a way > to enable it until the annotations spec is updated. Weld experimental > package will work fine. > > > > Jozef > > > > On 06/29/2015 12:19 PM, Antoine Sabot-Durand wrote: > >> Hi Jozef, > >> > >> I thought you didn't like to have temp stuff in the spec, so fr me it > was obvious that we should use the weld experimental package. > >> Any thoughts? > >> > >> Antoine > >> Le lun. 29 juin 2015 ? 11:38, Jozef Hartinger a > ?crit : > >> How do we deal with the lack of parameter-level @Priority in the > meantime? > >> > >> > >> On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: > >>> Hi guys, > >>> > >>> The branch 2.0-EDR1 is ready for release. > >>> > >>> Beyond the source, you can check javadoc here: > >>> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > >>> > >>> And spec here: > >>> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > >>> > >>> Or PDF version: > >>> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf > >>> > >>> I have still some work on introduction (major changes, etc?) and on > copyright in source files and intend to start release process (three the > JCP) tomorrow. > >>> > >>> Antoine > >>> > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> > >>> cdi-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> > >>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >> > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/4766954d/attachment.html From issues at jboss.org Mon Jun 29 15:52:05 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 15:52:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-499: ---------------------------------------- Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 (was: 2.0 (discussion)) Resolution: Done > Firing events asynchronously > ----------------------------- > > Key: CDI-499 > URL: https://issues.jboss.org/browse/CDI-499 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface. > Our proposal is: > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}} > Signature of the method on {{Event}} would be > {code:java} > CompletionStage fireAsync(U event); > {code} > Signature on {{BeanManager}} would be > {code:java} > CompletionStage fireAsyncEvent(T event, Annotation... qualifiers) > {code} > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}} > For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect. > So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously. > h2. 3. Observer bound to a transaction phase > these observer will be invoked in the right transaction phase but asynchronously > h2. 4. Event Ordering > Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync). > h2. 5. Event state (payload mutability) > We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 15:57:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 29 Jun 2015 15:57:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-438. -------------------------------------- Fix Version/s: 2.0-EDR1 (was: 2.0 (discussion)) Resolution: Done > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod. > {quote} > API: > {code:java} > /** > * @param The return type of the producer method > * @param The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod extends ProcessBean { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From antoine at sabot-durand.net Mon Jun 29 17:02:59 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 29 Jun 2015 23:02:59 +0200 Subject: [cdi-dev] Final elements for EDR1 Message-ID: Hi guys, Unless you send feedback about them here are the final elements I plan to submit to JCP tomorrow at 12:00 CET Spec HTML: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html Spec PDF (with a fancy new Look And Feel): https://dl.dropboxusercontent.com/u/2898173/cdi-spec.pdf Javadoc: https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html Thanks for your sharp eyes in this ultimate review ;). Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/b18dcddc/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/b18dcddc/attachment.bin From jharting at redhat.com Tue Jun 30 03:54:17 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 30 Jun 2015 09:54:17 +0200 Subject: [cdi-dev] Meeting at GeeCon Prague ? In-Reply-To: References: Message-ID: <55924B29.2020100@redhat.com> Hi Antonio, good idea. I will probably be there. Jozef On 06/29/2015 03:43 PM, Antonio Goncalves wrote: > Hi guys, > > Don't know if some of you will be at GeeCon Prague in October > (22nd//23rd of October). If yes, we could maybe organize a meeting. > And I know that some of the Jersey team is also based in Prague. It > would be great to have the JAX-RS and CDI team talking about possible > improvments. > > WDYT ? > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | > Paris JUG | Devoxx France > > > _______________________________________________ > 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/20150630/9ad55611/attachment-0001.html From jharting at redhat.com Tue Jun 30 04:01:43 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 30 Jun 2015 10:01:43 +0200 Subject: [cdi-dev] Final elements for EDR1 In-Reply-To: References: Message-ID: <55924CE7.1010909@redhat.com> I fixed some minor grammar issues here: https://github.com/cdi-spec/cdi/pull/252 On 06/29/2015 11:02 PM, Antoine Sabot-Durand wrote: > Hi guys, > > > Unless you send feedback about them here are the final elements I plan > to submit to JCP tomorrow at 12:00 CET > > Spec HTML: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > Spec PDF (with a fancy new Look And Feel): > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.pdf > Javadoc: https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > > Thanks for your sharp eyes in this ultimate review ;). > > 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/20150630/bb61eac5/attachment.html From werner.keil at gmail.com Tue Jun 30 04:17:57 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 30 Jun 2015 10:17:57 +0200 Subject: [cdi-dev] Meeting at GeeCon Prague ? (Jozef Hartinger) Message-ID: Antonio/Jozef, Sorry, but the guys in Prague got awfully bad timing for their GeeCon;-O https://jcp.org/en/whatsnew/calendar shows, there's a JCP EC F2F and at least some Spec Leads (like Alex from 375) plan to report to the EC right before JavaOne. Which starts immediately after that (I think there's several JUG, Adopt-a-JSR or DevoXX for Kids events on the 24th, at least it was lasts year) Werner On Tue, Jun 30, 2015 at 9:54 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: EDR1 ready to be released (Antoine Sabot-Durand) > 2. [JBoss JIRA] (CDI-499) Firing events asynchronously > (Antoine Sabot-Durand (JIRA)) > 3. [JBoss JIRA] (CDI-438) Fix type parameters ordering in > ProcessProducerMethod and ProcessProducerField events > (Antoine Sabot-Durand (JIRA)) > 4. Final elements for EDR1 (Antoine Sabot-Durand) > 5. Re: Meeting at GeeCon Prague ? (Jozef Hartinger) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 29 Jun 2015 19:43:41 +0000 > From: Antoine Sabot-Durand > Subject: Re: [cdi-dev] EDR1 ready to be released > To: Mark Struberg , "jharting at redhat.com" > > Cc: cdi-dev > Message-ID: > 5HcNf4zm8JD+tokjJF4w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > > Please correct me if I got this wrong, you like to have a org.boss.weld > > package in the EDR wording? > > > > You're wrong. Nobody's proposed such a thing. But to be sure, you might > want to re-read carefully the spec (nice trick to have another review on > the spec split ;) ). > > More seriously, the spec mention @Priority from commons annotation and it > will stay like that, because it's the target. Wether we keep it in weld or > move it in an experimental package in the spec, this content will not > change. > I'll write a blog post explaining why user can't use the official @Priority > yet and what package to use in the meantime. > I said I find more consistent to have it in Weld experimental, because we > said last week that we didn't want to put temp feature in the spec & API. > > > > In that case a strict -1 for any org.jboss.weld package in the official > > spec EDR! > > That?s a total no-go and is legally not possible as you would force ALL > > implementors to break trademark laws. > > This would also probably (in extremis) diminish the Weld trademark? So > > this is something I guess JBoss would like to prevent as well? > > > > LieGrue, > > strub > > > > > Am 29.06.2015 um 12:44 schrieb Jozef Hartinger : > > > > > > Hi Antoine, > > > > > > I dislike inventing temporary behavior. For @Priority there seems to be > > consensus about the observer ordering behavior already. We just need a > way > > to enable it until the annotations spec is updated. Weld experimental > > package will work fine. > > > > > > Jozef > > > > > > On 06/29/2015 12:19 PM, Antoine Sabot-Durand wrote: > > >> Hi Jozef, > > >> > > >> I thought you didn't like to have temp stuff in the spec, so fr me it > > was obvious that we should use the weld experimental package. > > >> Any thoughts? > > >> > > >> Antoine > > >> Le lun. 29 juin 2015 ? 11:38, Jozef Hartinger a > > ?crit : > > >> How do we deal with the lack of parameter-level @Priority in the > > meantime? > > >> > > >> > > >> On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: > > >>> Hi guys, > > >>> > > >>> The branch 2.0-EDR1 is ready for release. > > >>> > > >>> Beyond the source, you can check javadoc here: > > >>> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > > >>> > > >>> And spec here: > > >>> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > > >>> > > >>> Or PDF version: > > >>> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf > > >>> > > >>> I have still some work on introduction (major changes, etc?) and on > > copyright in source files and intend to start release process (three the > > JCP) tomorrow. > > >>> > > >>> Antoine > > >>> > > >>> > > >>> _______________________________________________ > > >>> cdi-dev mailing list > > >>> > > >>> cdi-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >>> > > >>> > > >>> Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 ( > > >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > >> > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider licenses the > > code under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/4766954d/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Mon, 29 Jun 2015 15:52:05 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Antoine Sabot-Durand reassigned CDI-499: > ---------------------------------------- > > Assignee: Antoine Sabot-Durand > Fix Version/s: 2.0-EDR1 > (was: 2.0 (discussion)) > Resolution: Done > > > > Firing events asynchronously > > ----------------------------- > > > > Key: CDI-499 > > URL: https://issues.jboss.org/browse/CDI-499 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Events > > Affects Versions: 1.2.Final > > Reporter: Antoine Sabot-Durand > > Assignee: Antoine Sabot-Durand > > Fix For: 2.0-EDR1 > > > > > > We should allow a way to fire event asynchronously. This mechanism > should leverage new async API in JDK8 especially the {{CompletionStage}} > interface. > > Our proposal is: > > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}} > > Signature of the method on {{Event}} would be > > {code:java} > > CompletionStage fireAsync(U event); > > {code} > > Signature on {{BeanManager}} would be > > {code:java} > > CompletionStage fireAsyncEvent(T event, Annotation... qualifiers) > > {code} > > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}} > > For backward compatibility reason the possibility to invoke an observer > asynchronously should be let to the observer (legacy observers should be > called synchronously). We propose to add the boolean {{asyncSupported()}} > member with the {{false}} default value to support this backward > compatibility aspect. > > So to be notified asynchronously an observer should have > {{asyncSupported}} member to true. otherwise it will be called > synchronously. > > h2. 3. Observer bound to a transaction phase > > these observer will be invoked in the right transaction phase but > asynchronously > > h2. 4. Event Ordering > > Should we decide to add events ordering in CDI 2.0, the order will be > keep in asynchronous observer notification. If there are a mix of > synchronous and asynchronous observer, asynchronous will be called first in > order, then synchronous in their order (async has priority on sync). > > h2. 5. Event state (payload mutability) > > We'll keep payload mutability with async events (but should explicitly > specify it). That means that we should guarantee the event state > consistency between observers and in case of ordered observers the fact > that observer N+1 get the event state at the end of observer N. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) > > > ------------------------------ > > Message: 3 > Date: Mon, 29 Jun 2015 15:57:02 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering > in ProcessProducerMethod and ProcessProducerField events > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Antoine Sabot-Durand resolved CDI-438. > -------------------------------------- > Fix Version/s: 2.0-EDR1 > (was: 2.0 (discussion)) > Resolution: Done > > > > Fix type parameters ordering in ProcessProducerMethod and > ProcessProducerField events > > > ------------------------------------------------------------------------------------- > > > > Key: CDI-438 > > URL: https://issues.jboss.org/browse/CDI-438 > > Project: CDI Specification Issues > > Issue Type: Bug > > Affects Versions: 1.2.Final > > Reporter: Martin Kouba > > Assignee: Antoine Sabot-Durand > > Fix For: 2.0-EDR1 > > > > > > Since CDI 1.0 there is an inconsistency in the description of > {{ProcessProducerMethod}} event... > > The text: > > {quote} > > For a producer method with method *return type X* of a bean with *bean > class T*, the container must raise an event of type > ProcessProducerMethod. > > {quote} > > API: > > {code:java} > > /** > > * @param The return type of the producer method > > * @param The class of the bean declaring the producer method > > */ > > public interface ProcessProducerMethod extends ProcessBean { > > } > > {code} > > The same applies to {{ProcessProducerField}}. > > TCK and RI (Weld) follow the API. As one of the consequences an > {{ProcessProducerMethod}} event is not delivered to an > observer with the event parameter {{ProcessBean}} - which is required > by the spec but does not make sense at the same time. > > It's obvious that JCP compatibility rules required to keep the wrong > ordering for CDI 1.x (see also the comments in > {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this > should be fixed in CDI 2.0. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) > > > ------------------------------ > > Message: 4 > Date: Mon, 29 Jun 2015 23:02:59 +0200 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Final elements for EDR1 > To: cdi-dev > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi guys, > > > Unless you send feedback about them here are the final elements I plan to > submit to JCP tomorrow at 12:00 CET > > Spec HTML: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html < > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html> > Spec PDF (with a fancy new Look And Feel): > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.pdf < > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.pdf> > Javadoc: https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html < > https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html> > > Thanks for your sharp eyes in this ultimate review ;). > > Antoine > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/b18dcddc/attachment-0001.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 495 bytes > Desc: Message signed with OpenPGP using GPGMail > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/b18dcddc/attachment-0001.bin > > ------------------------------ > > Message: 5 > Date: Tue, 30 Jun 2015 09:54:17 +0200 > From: Jozef Hartinger > Subject: Re: [cdi-dev] Meeting at GeeCon Prague ? > To: Antonio Goncalves , cdi-dev > > Message-ID: <55924B29.2020100 at redhat.com> > Content-Type: text/plain; charset="windows-1252" > > Hi Antonio, > > good idea. I will probably be there. > > Jozef > > On 06/29/2015 03:43 PM, Antonio Goncalves wrote: > > Hi guys, > > > > Don't know if some of you will be at GeeCon Prague in October > > (22nd//23rd of October). If yes, we could maybe organize a meeting. > > And I know that some of the Jersey team is also based in Prague. It > > would be great to have the JAX-RS and CDI team talking about possible > > improvments. > > > > WDYT ? > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter > > | LinkedIn > > | Pluralsight > > | > > Paris JUG | Devoxx France < > http://www.devoxx.fr> > > > > > > _______________________________________________ > > 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/20150630/9ad55611/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 55, Issue 45 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150630/99968235/attachment-0001.html From antoine at sabot-durand.net Tue Jun 30 04:32:56 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 30 Jun 2015 08:32:56 +0000 Subject: [cdi-dev] Final elements for EDR1 In-Reply-To: <55924CE7.1010909@redhat.com> References: <55924CE7.1010909@redhat.com> Message-ID: PR merged. Thanks Jozef! Le mar. 30 juin 2015 ? 10:01, Jozef Hartinger a ?crit : > I fixed some minor grammar issues here: > https://github.com/cdi-spec/cdi/pull/252 > > > On 06/29/2015 11:02 PM, Antoine Sabot-Durand wrote: > > Hi guys, > > > Unless you send feedback about them here are the final elements I plan > to submit to JCP tomorrow at 12:00 CET > > Spec HTML: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > Spec PDF (with a fancy new Look And Feel): > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.pdf > Javadoc: https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > > Thanks for your sharp eyes in this ultimate review ;). > > Antoine > > > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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/20150630/06eee5e4/attachment.html From antoine at sabot-durand.net Tue Jun 30 08:53:12 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 30 Jun 2015 14:53:12 +0200 Subject: [cdi-dev] Canceling meeting today Message-ID: I won?t be available for our meeting today, let?s meet next week. regards, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150630/4230aee8/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150630/4230aee8/attachment.bin From john.d.ament at gmail.com Tue Jun 30 08:53:54 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 30 Jun 2015 12:53:54 +0000 Subject: [cdi-dev] Final elements for EDR1 In-Reply-To: References: <55924CE7.1010909@redhat.com> Message-ID: Hey, so 15.1 looks a little weird. the application is launched with system property javax.enterprise.inject.scan.implicit set to true Should probably just be "A system property with the name "javax.enterprise.inject.scan.implicit" set to "true". Otherwise it looks like you can only set it with a JVM flag. On Tue, Jun 30, 2015 at 4:33 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > PR merged. Thanks Jozef! > > Le mar. 30 juin 2015 ? 10:01, Jozef Hartinger a > ?crit : > >> I fixed some minor grammar issues here: >> https://github.com/cdi-spec/cdi/pull/252 >> >> >> On 06/29/2015 11:02 PM, Antoine Sabot-Durand wrote: >> >> Hi guys, >> >> >> Unless you send feedback about them here are the final elements I plan >> to submit to JCP tomorrow at 12:00 CET >> >> Spec HTML: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html >> Spec PDF (with a fancy new Look And Feel): >> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.pdf >> Javadoc: https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html >> >> Thanks for your sharp eyes in this ultimate review ;). >> >> Antoine >> >> >> >> _______________________________________________ >> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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/20150630/b5265756/attachment.html From john.d.ament at gmail.com Tue Jun 30 08:55:00 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 30 Jun 2015 12:55:00 +0000 Subject: [cdi-dev] Let's Sept 25th -26th for our F2F meeting In-Reply-To: <4C409AF7-57D7-4B62-A82F-B40EC9C778BC@sabot-durand.net> References: <4C409AF7-57D7-4B62-A82F-B40EC9C778BC@sabot-durand.net> Message-ID: Hi Antoine, Sorry, somethings are coming up at work and I won't be around either of those weekends now :-( If 18th is more convenient for people please use that. John On Thu, Jun 25, 2015 at 10:17 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > So the vote closed on modally. We should have talk about the final date in > the last meeting, but there was too much on our plate ;). > > We have a tie between 18th and 25th, but as John can make it for the 25th > and he?s probably the farthest one from Paris to come I propose to keep > this date. > > Regards, > > 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/20150630/d550fcee/attachment.html