From john.d.ament at gmail.com Mon May 2 22:47:57 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 03 May 2016 02:47:57 +0000 Subject: [cdi-dev] Meeting on? Message-ID: Hey guys just wanted to check if the meeting for 5/3 is still on? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160503/f2496c20/attachment.html From antoine at sabot-durand.net Mon May 2 23:49:53 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 03 May 2016 03:49:53 +0000 Subject: [cdi-dev] Meeting on? In-Reply-To: References: Message-ID: Yes, it'll we be on Le mar. 3 mai 2016 ? 04:48, John D. Ament a ?crit : > Hey guys just wanted to check if the meeting for 5/3 is still on? > > John > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160503/fc72493d/attachment.html From issues at jboss.org Tue May 3 04:42:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 May 2016 04:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200055#comment-13200055 ] Antoine Sabot-Durand commented on CDI-573: ------------------------------------------ Sorry for the regression. I correct the visibility for the next beta. > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Tue May 3 09:14:06 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 03 May 2016 13:14:06 +0000 Subject: [cdi-dev] New builders API In-Reply-To: <5721CD19.2040603@redhat.com> References: <571DC77E.5000606@redhat.com> <5721CD19.2040603@redhat.com> Message-ID: Thanks for all the feedback on the API. Before going into detail I wanted to put the accent on the Weld 3.0.Alpha16 release post[1] which give a good explanation regarding this API. Its the best starting point to discover this new API IMO. Thanks Martin, Tomas and Matej for this release. @John. The debate Configurator vs Builder is still open. At the moment we focused on configurator since they are easier to limit to a given container lifecycle, but having builders to reuse the configuration could make sense as well. AnnotatedType is a special case since it could make sense to use it at runtime (to ease creation of an InjectionTarget for instance, so perhaps it will require a Builder. If we keep the API in this spirit for the release, it should be better to talk about Configurator API vs Builder API to avoid confusion for missing build() methods ;) @Antonin the enhancement you propose is very interesting but as Martin said we could imagine a solution to load an existing bean after decision on the API (a mute(Bean) method in ABD perhaps). For me the goal is to decide if we are on the right path and avoid decision that will prevent future enhancement. I think having this API perfect and complete in one PR is almost impossible. So we should validate something to move on missing features or enhancements. Antoine [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ Le jeu. 28 avr. 2016 ? 10:43, Martin Kouba a ?crit : > Hi all, > > we've just released Weld 3.0.0.Alpha16. So anyone can start playing with > the API, discover possibilities and find potential issues: > > http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ > > Any feedback is appreciated! > > Martin > > Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): > > Hi all, > > > > me and Matej, we've already tried to explain some points in cdi/pull/287 > > discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on > > 2.0.Alpha4) later this week so that everyone can start playing with the > > new API. And we'd like to prepare some simple examples to help people > > get started as well. > > > > Martin > > > > > > Dne 23.4.2016 v 12:56 John D. Ament napsal(a): > >> Hey guys > >> > >> Based on the last f2f I was in, I took an action item to look at how > >> applications can leverage the new builder methods/classes from this PR: > >> https://github.com/cdi-spec/cdi/pull/287 > >> > >> To do this, I took some existing OSS CDI extensions and converted parts > >> to use the new APIs instead of the old ones. > >> > >> The results were iffy to be honest. Here's some of the key issues I > >> noticed: > >> > >> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean > bean) > >> In the latter, it's clearer to a developer which attributes are required > >> vs optional. Builders typically use sensible defaults. Maybe that was > >> the intention here, but I couldn't really get that sense when converting > >> over. It also wasn't clear what to do when done. I suspect I just > >> leave it, but without some kind of closing "build()" or "done()" method, > >> it becomes ambiguous. > >> > >> - Annotated*Configurator > >> TBH, I have no idea what I was configuring in this one at the first > >> pass. I started with a method. I wanted to replace the method's > >> annotations. It seemed like I could set that up using the configurator, > >> but I ended up having to do setAnnotated at the end anyways, so I'm not > >> sure what the configurator bought me. > >> > >> The one nice thing I saw was the simpler to use lambda functions. Being > >> able to stream through things like annotated method made the code much > >> cleaner. > >> > >> For the open source code, I'll try to get some gists together that show > >> the changes. Maybe there's something I'm missing, so wouldn't mind a > >> second set of eyes on the changes to see. > >> > >> John > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160503/235abcff/attachment-0001.html From issues at jboss.org Tue May 3 09:30:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 3 May 2016 09:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-600) Specialization code sample is misleading In-Reply-To: References: Message-ID: Matej Novotny created CDI-600: --------------------------------- Summary: Specialization code sample is misleading Key: CDI-600 URL: https://issues.jboss.org/browse/CDI-600 Project: CDI Specification Issues Issue Type: Clarification Components: Inheritance and Specialization Affects Versions: 2.0-EDR1 Reporter: Matej Novotny In the spec, there is following code sample explaining how to achieve specialization: {code} @Alternative @Specializes public class MockAsynchronousService extends AsynchronousService { ... } {code} This is IMHO misleading as the {{@Alternative}} annotation is not needed for specialization to work and hence should be removed from this sample. In fact one user approached me recently, asking me some questions regarding CDI specialization, and this sample was a source of his confusion. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Tue May 3 09:44:14 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 03 May 2016 13:44:14 +0000 Subject: [cdi-dev] Accelerate decision process and PR adoption / rejection Message-ID: Hi guys, As you know we plan to release CDI 2.0 before the end of January. It let's us around 6 months to complete the spec. I think we really should find a way to enhance our focus on reviewing proposal and code. Adding special Hangout meetings proved itself a good solution to go that way, but I think we should also work on rules adoption for PR. So I propose that: - PR should stay open at least one week. - It could be merged (after at least a week) if 4 EG members votes for it (+1 on the PR). - As no one is error proof if someone has an objection to a PR to be merged he could raise his concern and justify his objection. - The following discussion should lead either to a revision of the PR or a +1 from the objector - If no agreement is reached, to avoid blocage a vote will be called on this ML to adopt or reject the PR. I'm not a big fan of over processed team work, but we really have to deliver. For the moment I think we can avoid having too much process on ticket choice (we don't have enough contributors to go that way) Wdyt ? Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160503/5dff2f2c/attachment.html From antonin at stefanutti.fr Tue May 3 09:48:39 2016 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Tue, 3 May 2016 13:48:39 +0000 Subject: [cdi-dev] New builders API In-Reply-To: References: <571DC77E.5000606@redhat.com> <5721CD19.2040603@redhat.com> Message-ID: <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> Hi All, Not sure what?s the best form to share my feedback, so here it is :) I?ve tested CDI 2.0.Alpha4 / Weld 3.0.0.Alpha3 and the new "builder API" on the Camel CDI extension and here are the points I?ve had gathered: - There is a read(AnnotatedType type) API: equivalent API for AnnotatedField and AnnotatedMethod would be useful - Having the ability to customise the toString method by providing a Supplier would be useful - There are API (createWith, produceWith, ...) that are basically the decomposition of what an injection target is: in the Camel CDI use case, It?d be useful to be able to reuse some InjectionTarget that are used for discovered beans as well directly instead of having to call instantiate the injection target and call produceWith and destroyWith separately - I found a bit cumbersome to work with addObserverMethod: as the type parameter is not driven by the observedType, generics hiccups come into play with the notifyWith API. In my example, I had to rely on an extra method to have the type parameter provided: https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 Unfortunately, I haven?t been able to get rid of the boilerplate code (like SyntheticBean [1], SyntheticBeanAttributes [2], SyntheticInjectionTarget [3]) that the new builder API would have permitted to eliminate. Indeed, while the "Metadata configuration API" probably solves the majority / simplest use cases, it does not address the one in Camel CDI (as already illustrated by John and I from different angles). IMO, it?d be worth investigating on an unified Builder and configurator API bringing the best of both worlds. The rewrite of Camel CDI on CDI 2.0 is available here: https://github.com/astefanutti/camel-cdi/commits/cdi-2.0. [1]: https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBean.java#L34 [2]: https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBeanAttributes.java#L31 [3]: https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticInjectionTarget.java#L29 Antonin > On 03 May 2016, at 15:14, Antoine Sabot-Durand wrote: > > Thanks for all the feedback on the API. > > Before going into detail I wanted to put the accent on the Weld 3.0.Alpha16 release post[1] which give a good explanation regarding this API. Its the best starting point to discover this new API IMO. Thanks Martin, Tomas and Matej for this release. > > @John. The debate Configurator vs Builder is still open. At the moment we focused on configurator since they are easier to limit to a given container lifecycle, but having builders to reuse the configuration could make sense as well. AnnotatedType is a special case since it could make sense to use it at runtime (to ease creation of an InjectionTarget for instance, so perhaps it will require a Builder. > If we keep the API in this spirit for the release, it should be better to talk about Configurator API vs Builder API to avoid confusion for missing build() methods ;) > > @Antonin the enhancement you propose is very interesting but as Martin said we could imagine a solution to load an existing bean after decision on the API (a mute(Bean) method in ABD perhaps). > > For me the goal is to decide if we are on the right path and avoid decision that will prevent future enhancement. I think having this API perfect and complete in one PR is almost impossible. So we should validate something to move on missing features or enhancements. > > Antoine > > [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ > > Le jeu. 28 avr. 2016 ? 10:43, Martin Kouba a ?crit : > Hi all, > > we've just released Weld 3.0.0.Alpha16. So anyone can start playing with > the API, discover possibilities and find potential issues: > > http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ > > Any feedback is appreciated! > > Martin > > Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): > > Hi all, > > > > me and Matej, we've already tried to explain some points in cdi/pull/287 > > discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on > > 2.0.Alpha4) later this week so that everyone can start playing with the > > new API. And we'd like to prepare some simple examples to help people > > get started as well. > > > > Martin > > > > > > Dne 23.4.2016 v 12:56 John D. Ament napsal(a): > >> Hey guys > >> > >> Based on the last f2f I was in, I took an action item to look at how > >> applications can leverage the new builder methods/classes from this PR: > >> https://github.com/cdi-spec/cdi/pull/287 > >> > >> To do this, I took some existing OSS CDI extensions and converted parts > >> to use the new APIs instead of the old ones. > >> > >> The results were iffy to be honest. Here's some of the key issues I > >> noticed: > >> > >> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean bean) > >> In the latter, it's clearer to a developer which attributes are required > >> vs optional. Builders typically use sensible defaults. Maybe that was > >> the intention here, but I couldn't really get that sense when converting > >> over. It also wasn't clear what to do when done. I suspect I just > >> leave it, but without some kind of closing "build()" or "done()" method, > >> it becomes ambiguous. > >> > >> - Annotated*Configurator > >> TBH, I have no idea what I was configuring in this one at the first > >> pass. I started with a method. I wanted to replace the method's > >> annotations. It seemed like I could set that up using the configurator, > >> but I ended up having to do setAnnotated at the end anyways, so I'm not > >> sure what the configurator bought me. > >> > >> The one nice thing I saw was the simpler to use lambda functions. Being > >> able to stream through things like annotated method made the code much > >> cleaner. > >> > >> For the open source code, I'll try to get some gists together that show > >> the changes. Maybe there's something I'm missing, so wouldn't mind a > >> second set of eyes on the changes to see. > >> > >> John > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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. From john.d.ament at gmail.com Tue May 3 09:50:28 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 3 May 2016 09:50:28 -0400 Subject: [cdi-dev] Accelerate decision process and PR adoption / rejection In-Reply-To: References: Message-ID: Antoine, Why do only some EG members have access to merge PRs? On May 3, 2016 9:44 AM, "Antoine Sabot-Durand" wrote: > Hi guys, > > As you know we plan to release CDI 2.0 before the end of January. It let's > us around 6 months to complete the spec. > > I think we really should find a way to enhance our focus on reviewing > proposal and code. > Adding special Hangout meetings proved itself a good solution to go that > way, but I think we should also work on rules adoption for PR. > > So I propose that: > - PR should stay open at least one week. > - It could be merged (after at least a week) if 4 EG members votes for it > (+1 on the PR). > - As no one is error proof if someone has an objection to a PR to be > merged he could raise his concern and justify his objection. > - The following discussion should lead either to a revision of the PR or a > +1 from the objector > - If no agreement is reached, to avoid blocage a vote will be called on > this ML to adopt or reject the PR. > > I'm not a big fan of over processed team work, but we really have to > deliver. > For the moment I think we can avoid having too much process on ticket > choice (we don't have enough contributors to go that way) > > Wdyt ? > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160503/a8a3f151/attachment.html From antoine at sabot-durand.net Tue May 3 10:28:03 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 03 May 2016 14:28:03 +0000 Subject: [cdi-dev] New builders API In-Reply-To: <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> References: <571DC77E.5000606@redhat.com> <5721CD19.2040603@redhat.com> <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> Message-ID: Thanks Antonin, for your feedback. Camel CDI is a good example to test this new API. Would you be ok to set up a meeting IRL to work on these points with your framework ? Antoine Le mar. 3 mai 2016 ? 15:48, Antonin Stefanutti a ?crit : > Hi All, > > Not sure what?s the best form to share my feedback, so here it is :) > > I?ve tested CDI 2.0.Alpha4 / Weld 3.0.0.Alpha3 and the new "builder API" > on the Camel CDI extension and here are the points I?ve had gathered: > > - There is a read(AnnotatedType type) API: equivalent API for > AnnotatedField and AnnotatedMethod would be useful > - Having the ability to customise the toString method by providing a > Supplier would be useful > - There are API (createWith, produceWith, ...) that are basically the > decomposition of what an injection target is: in the Camel CDI use case, > It?d be useful to be able to reuse some InjectionTarget that are used for > discovered beans as well directly instead of having to call instantiate the > injection target and call produceWith and destroyWith separately > - I found a bit cumbersome to work with addObserverMethod: as the type > parameter is not driven by the observedType, generics hiccups come into > play with the notifyWith API. In my example, I had to rely on an extra > method to have the type parameter provided: > https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 > > Unfortunately, I haven?t been able to get rid of the boilerplate code > (like SyntheticBean [1], SyntheticBeanAttributes [2], > SyntheticInjectionTarget [3]) that the new builder API would have permitted > to eliminate. Indeed, while the "Metadata configuration API" probably > solves the majority / simplest use cases, it does not address the one in > Camel CDI (as already illustrated by John and I from different angles). > > IMO, it?d be worth investigating on an unified Builder and configurator > API bringing the best of both worlds. > > The rewrite of Camel CDI on CDI 2.0 is available here: > https://github.com/astefanutti/camel-cdi/commits/cdi-2.0. > > [1]: > https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBean.java#L34 > [2]: > https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBeanAttributes.java#L31 > [3]: > https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticInjectionTarget.java#L29 > > Antonin > > > On 03 May 2016, at 15:14, Antoine Sabot-Durand > wrote: > > > > Thanks for all the feedback on the API. > > > > Before going into detail I wanted to put the accent on the Weld > 3.0.Alpha16 release post[1] which give a good explanation regarding this > API. Its the best starting point to discover this new API IMO. Thanks > Martin, Tomas and Matej for this release. > > > > @John. The debate Configurator vs Builder is still open. At the moment > we focused on configurator since they are easier to limit to a given > container lifecycle, but having builders to reuse the configuration could > make sense as well. AnnotatedType is a special case since it could make > sense to use it at runtime (to ease creation of an InjectionTarget for > instance, so perhaps it will require a Builder. > > If we keep the API in this spirit for the release, it should be better > to talk about Configurator API vs Builder API to avoid confusion for > missing build() methods ;) > > > > @Antonin the enhancement you propose is very interesting but as Martin > said we could imagine a solution to load an existing bean after decision on > the API (a mute(Bean) method in ABD perhaps). > > > > For me the goal is to decide if we are on the right path and avoid > decision that will prevent future enhancement. I think having this API > perfect and complete in one PR is almost impossible. So we should validate > something to move on missing features or enhancements. > > > > Antoine > > > > [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ > > > > Le jeu. 28 avr. 2016 ? 10:43, Martin Kouba a ?crit : > > Hi all, > > > > we've just released Weld 3.0.0.Alpha16. So anyone can start playing with > > the API, discover possibilities and find potential issues: > > > > http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ > > > > Any feedback is appreciated! > > > > Martin > > > > Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): > > > Hi all, > > > > > > me and Matej, we've already tried to explain some points in > cdi/pull/287 > > > discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on > > > 2.0.Alpha4) later this week so that everyone can start playing with the > > > new API. And we'd like to prepare some simple examples to help people > > > get started as well. > > > > > > Martin > > > > > > > > > Dne 23.4.2016 v 12:56 John D. Ament napsal(a): > > >> Hey guys > > >> > > >> Based on the last f2f I was in, I took an action item to look at how > > >> applications can leverage the new builder methods/classes from this > PR: > > >> https://github.com/cdi-spec/cdi/pull/287 > > >> > > >> To do this, I took some existing OSS CDI extensions and converted > parts > > >> to use the new APIs instead of the old ones. > > >> > > >> The results were iffy to be honest. Here's some of the key issues I > > >> noticed: > > >> > > >> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean > bean) > > >> In the latter, it's clearer to a developer which attributes are > required > > >> vs optional. Builders typically use sensible defaults. Maybe that > was > > >> the intention here, but I couldn't really get that sense when > converting > > >> over. It also wasn't clear what to do when done. I suspect I just > > >> leave it, but without some kind of closing "build()" or "done()" > method, > > >> it becomes ambiguous. > > >> > > >> - Annotated*Configurator > > >> TBH, I have no idea what I was configuring in this one at the first > > >> pass. I started with a method. I wanted to replace the method's > > >> annotations. It seemed like I could set that up using the > configurator, > > >> but I ended up having to do setAnnotated at the end anyways, so I'm > not > > >> sure what the configurator bought me. > > >> > > >> The one nice thing I saw was the simpler to use lambda functions. > Being > > >> able to stream through things like annotated method made the code much > > >> cleaner. > > >> > > >> For the open source code, I'll try to get some gists together that > show > > >> the changes. Maybe there's something I'm missing, so wouldn't mind a > > >> second set of eyes on the changes to see. > > >> > > >> John > > >> > > >> > > >> _______________________________________________ > > >> cdi-dev mailing list > > >> cdi-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >> > > >> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160503/ede734e5/attachment-0001.html From manovotn at redhat.com Tue May 3 10:40:11 2016 From: manovotn at redhat.com (Matej Novotny) Date: Tue, 3 May 2016 10:40:11 -0400 (EDT) Subject: [cdi-dev] New builders API In-Reply-To: <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> References: <571DC77E.5000606@redhat.com> <5721CD19.2040603@redhat.com> <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> Message-ID: <1509090947.48315712.1462286411872.JavaMail.zimbra@redhat.com> Hello > - There is a read(AnnotatedType type) API: equivalent API for > AnnotatedField and AnnotatedMethod would be useful Not sure I understand the use case here. You start with AnnotatedTypeConfigurator and you can call, say, methods(). That will give you a Set>. So the type of of MethodConfigurator is based on the type of the former configurator. Could you support your thoughts by a code snippet showing the usage? > - Having the ability to customise the toString method by providing a > Supplier would be useful This might be a good idea. Where exactly do you need this method? BeanConfigurator or even elsewhere? > It?d be useful to be able to reuse some InjectionTarget that are used for > discovered beans as well directly instead of having to call instantiate the > injection target and call produceWith and destroyWith separately Not sure I follow you here - produceWith is a way to provide a producer method for your bean (assuming we are talking about Beanconfigurator.produceWith). That merely tells CDI how to instantiate the bean if you are to inject it somewhere. You do not really need to handle InjectionTarget here. Same goes for destroyWith. I might be missing something though. > - I found a bit cumbersome to work with addObserverMethod: as the type > parameter is not driven by the observedType, generics hiccups come into play > with the notifyWith API. In my example, I had to rely on an extra method to > have the type parameter provided: As configurators are not reusable, your approach is imho perfectly right. If you were to add several observers, you need to call AfterBeanDiscovery.addObserver() several times anyway. It should be also possible to achieve the same things you have there without additional method (just within the for cycle). So I do not really see the 'generic hiccup' you are talking about. Btw please make sure to attend the CDI mtg in the evening. You can voice your needs/ideas there :) Matej ----- Original Message ----- > From: "Antonin Stefanutti" > To: cdi-dev at lists.jboss.org > Sent: Tuesday, May 3, 2016 3:48:39 PM > Subject: Re: [cdi-dev] New builders API > > Hi All, > > Not sure what?s the best form to share my feedback, so here it is :) > > I?ve tested CDI 2.0.Alpha4 / Weld 3.0.0.Alpha3 and the new "builder API" on > the Camel CDI extension and here are the points I?ve had gathered: > > - There is a read(AnnotatedType type) API: equivalent API for > AnnotatedField and AnnotatedMethod would be useful > - Having the ability to customise the toString method by providing a > Supplier would be useful > - There are API (createWith, produceWith, ...) that are basically the > decomposition of what an injection target is: in the Camel CDI use case, > It?d be useful to be able to reuse some InjectionTarget that are used for > discovered beans as well directly instead of having to call instantiate the > injection target and call produceWith and destroyWith separately > - I found a bit cumbersome to work with addObserverMethod: as the type > parameter is not driven by the observedType, generics hiccups come into play > with the notifyWith API. In my example, I had to rely on an extra method to > have the type parameter provided: > https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 > > Unfortunately, I haven?t been able to get rid of the boilerplate code (like > SyntheticBean [1], SyntheticBeanAttributes [2], SyntheticInjectionTarget > [3]) that the new builder API would have permitted to eliminate. Indeed, > while the "Metadata configuration API" probably solves the majority / > simplest use cases, it does not address the one in Camel CDI (as already > illustrated by John and I from different angles). > > IMO, it?d be worth investigating on an unified Builder and configurator API > bringing the best of both worlds. > > The rewrite of Camel CDI on CDI 2.0 is available here: > https://github.com/astefanutti/camel-cdi/commits/cdi-2.0. > > [1]: > https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBean.java#L34 > [2]: > https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBeanAttributes.java#L31 > [3]: > https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticInjectionTarget.java#L29 > > Antonin > > > On 03 May 2016, at 15:14, Antoine Sabot-Durand > > wrote: > > > > Thanks for all the feedback on the API. > > > > Before going into detail I wanted to put the accent on the Weld 3.0.Alpha16 > > release post[1] which give a good explanation regarding this API. Its the > > best starting point to discover this new API IMO. Thanks Martin, Tomas and > > Matej for this release. > > > > @John. The debate Configurator vs Builder is still open. At the moment we > > focused on configurator since they are easier to limit to a given > > container lifecycle, but having builders to reuse the configuration could > > make sense as well. AnnotatedType is a special case since it could make > > sense to use it at runtime (to ease creation of an InjectionTarget for > > instance, so perhaps it will require a Builder. > > If we keep the API in this spirit for the release, it should be better to > > talk about Configurator API vs Builder API to avoid confusion for missing > > build() methods ;) > > > > @Antonin the enhancement you propose is very interesting but as Martin said > > we could imagine a solution to load an existing bean after decision on the > > API (a mute(Bean) method in ABD perhaps). > > > > For me the goal is to decide if we are on the right path and avoid decision > > that will prevent future enhancement. I think having this API perfect and > > complete in one PR is almost impossible. So we should validate something > > to move on missing features or enhancements. > > > > Antoine > > > > [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ > > > > Le jeu. 28 avr. 2016 ? 10:43, Martin Kouba a ?crit : > > Hi all, > > > > we've just released Weld 3.0.0.Alpha16. So anyone can start playing with > > the API, discover possibilities and find potential issues: > > > > http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ > > > > Any feedback is appreciated! > > > > Martin > > > > Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): > > > Hi all, > > > > > > me and Matej, we've already tried to explain some points in cdi/pull/287 > > > discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on > > > 2.0.Alpha4) later this week so that everyone can start playing with the > > > new API. And we'd like to prepare some simple examples to help people > > > get started as well. > > > > > > Martin > > > > > > > > > Dne 23.4.2016 v 12:56 John D. Ament napsal(a): > > >> Hey guys > > >> > > >> Based on the last f2f I was in, I took an action item to look at how > > >> applications can leverage the new builder methods/classes from this PR: > > >> https://github.com/cdi-spec/cdi/pull/287 > > >> > > >> To do this, I took some existing OSS CDI extensions and converted parts > > >> to use the new APIs instead of the old ones. > > >> > > >> The results were iffy to be honest. Here's some of the key issues I > > >> noticed: > > >> > > >> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean > > >> bean) > > >> In the latter, it's clearer to a developer which attributes are required > > >> vs optional. Builders typically use sensible defaults. Maybe that was > > >> the intention here, but I couldn't really get that sense when converting > > >> over. It also wasn't clear what to do when done. I suspect I just > > >> leave it, but without some kind of closing "build()" or "done()" method, > > >> it becomes ambiguous. > > >> > > >> - Annotated*Configurator > > >> TBH, I have no idea what I was configuring in this one at the first > > >> pass. I started with a method. I wanted to replace the method's > > >> annotations. It seemed like I could set that up using the configurator, > > >> but I ended up having to do setAnnotated at the end anyways, so I'm not > > >> sure what the configurator bought me. > > >> > > >> The one nice thing I saw was the simpler to use lambda functions. Being > > >> able to stream through things like annotated method made the code much > > >> cleaner. > > >> > > >> For the open source code, I'll try to get some gists together that show > > >> the changes. Maybe there's something I'm missing, so wouldn't mind a > > >> second set of eyes on the changes to see. > > >> > > >> John > > >> > > >> > > >> _______________________________________________ > > >> cdi-dev mailing list > > >> cdi-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >> > > >> Note that for all code provided on this list, the provider licenses the > > >> code under the Apache License, Version 2 > > >> (http://www.apache.org/licenses/LICENSE-2.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. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. From antoine at sabot-durand.net Tue May 3 11:02:31 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 03 May 2016 15:02:31 +0000 Subject: [cdi-dev] Accelerate decision process and PR adoption / rejection In-Reply-To: References: Message-ID: John, I'm the only one to merge PR and it's only to simplify process (PR shouldn't be merge in github way but in Fast Forward way to keep a clean history) . This said, except for typos or missing words I never merge without approval of the EG. Now I can understand that you'd like to figure on the member list on the github CDI-SPEC organisation but it's not related to this proposal. The process I proposed is not about "who" merge but on what basis the merger can merge. Antoine Le mar. 3 mai 2016 ? 15:50, John D. Ament a ?crit : > Antoine, > > Why do only some EG members have access to merge PRs? > On May 3, 2016 9:44 AM, "Antoine Sabot-Durand" > wrote: > >> Hi guys, >> >> As you know we plan to release CDI 2.0 before the end of January. It >> let's us around 6 months to complete the spec. >> >> I think we really should find a way to enhance our focus on reviewing >> proposal and code. >> Adding special Hangout meetings proved itself a good solution to go that >> way, but I think we should also work on rules adoption for PR. >> >> So I propose that: >> - PR should stay open at least one week. >> - It could be merged (after at least a week) if 4 EG members votes for it >> (+1 on the PR). >> - As no one is error proof if someone has an objection to a PR to be >> merged he could raise his concern and justify his objection. >> - The following discussion should lead either to a revision of the PR or >> a +1 from the objector >> - If no agreement is reached, to avoid blocage a vote will be called on >> this ML to adopt or reject the PR. >> >> I'm not a big fan of over processed team work, but we really have to >> deliver. >> For the moment I think we can avoid having too much process on ticket >> choice (we don't have enough contributors to go that way) >> >> Wdyt ? >> >> Antoine >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160503/be0da801/attachment.html From john.d.ament at gmail.com Tue May 3 13:20:55 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 03 May 2016 17:20:55 +0000 Subject: [cdi-dev] Proposal - Allow TransientReference to be used on producers. Message-ID: All, I have opened a while ago - https://issues.jboss.org/browse/CDI-457 which was originally to add a disposable interface. The main driver was that if you're using an injection point like @Inject private Instance beanInst; doing beanInst.get() can cause leaking beans since there is no creational context. Upon looking at it further, there's some effort to do this in a safer way and leverage things like TransientReference. This doesn't work for classes provided by external libraries, even the JDK itself (like String). I'd like to propose that the scope of this ticket be to allow TransientReference on producer fields/methods since right now its only allowed on types. WDYT? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160503/36b5d1fe/attachment.html From issues at jboss.org Tue May 3 13:26:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 3 May 2016 13:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Allow producers to provide a @TransientReference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-457: --------------------------- Summary: Allow producers to provide a @TransientReference (was: Add a disposable interface) > Allow producers to provide a @TransientReference > ------------------------------------------------ > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. > I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue May 3 13:27:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 3 May 2016 13:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Allow producers to provide a @TransientReference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-457: --------------------------- Description: Using @TransientReference today for class definitions allows you to mark it as dependent. We should allow arbitrary producers to include transient references. was: Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. > Allow producers to provide a @TransientReference > ------------------------------------------------ > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Using @TransientReference today for class definitions allows you to mark it as dependent. > We should allow arbitrary producers to include transient references. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.d.ament at gmail.com Tue May 3 19:42:34 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 03 May 2016 23:42:34 +0000 Subject: [cdi-dev] Can the website auto update? Message-ID: All, I was wondering, and its probably a question more for our redhat hosts, but can the website be updated automatically with spec changes? Almost like a snapshot build? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160503/9186f932/attachment.html From john.d.ament at gmail.com Tue May 3 20:15:43 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 May 2016 00:15:43 +0000 Subject: [cdi-dev] Proposal - Allow TransientReference to be used on producers. In-Reply-To: References: Message-ID: After some more thought, I'm re-negging on this approach. The underlying problem has to do entirely with dependent scoped beans within instance objects. I've raised a PR making a more appropriate spec change, clarifying more on the user side how they should work with them. There's another section of the spec that I thought about adding this content to, and wouldn't be opposed to making that change. John On Tue, May 3, 2016 at 1:20 PM John D. Ament wrote: > All, > > I have opened a while ago - https://issues.jboss.org/browse/CDI-457 which > was originally to add a disposable interface. The main driver was that if > you're using an injection point like > > @Inject > private Instance beanInst; > > doing beanInst.get() can cause leaking beans since there is no creational > context. Upon looking at it further, there's some effort to do this in a > safer way and leverage things like TransientReference. > > This doesn't work for classes provided by external libraries, even the JDK > itself (like String). I'd like to propose that the scope of this ticket be > to allow TransientReference on producer fields/methods since right now its > only allowed on types. > > WDYT? > > John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160504/530c0feb/attachment.html From john.d.ament at gmail.com Tue May 3 20:32:25 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 May 2016 00:32:25 +0000 Subject: [cdi-dev] CDI-508 - Which java classes can be managed beans Message-ID: All, I think I had an action item to get this clarified, not 100% sure, but let me give this a shot. Tomas raised a PR for CDI-508 to clarify which classes are meant to be managed beans. You can find that PR here: https://github.com/cdi-spec/cdi/pull/282/ The line that doesn't sound right to me in the change is to go from: It is not a non-static inner class. to It is not a non-static nested class. I'll use the java programming language tutorial as a point of reference, you can read the page I'll refer to here: https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html Basically, non-static nested classes are AKA inner classes. The term "non-static inner class" shouldn't exist, and that means the original text doesn't make sense, and should probably be inferred as "It is not an inner class" >From reading this part of the spec, it becomes unreadable due to the double negative (probably why the aka exists). My proposal was to change the line to instead read (in a positive way) "It is a static nested class" but I can also understand if we want to do this in an exclusion pattern rather than an inclusion pattern. Thoughts? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160504/4ddfd800/attachment.html From issues at jboss.org Tue May 3 21:04:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 3 May 2016 21:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Clarify how to properly create and destroy dependent instances In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-457: --------------------------- Summary: Clarify how to properly create and destroy dependent instances (was: Allow producers to provide a @TransientReference) > Clarify how to properly create and destroy dependent instances > -------------------------------------------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Using @TransientReference today for class definitions allows you to mark it as dependent. > We should allow arbitrary producers to include transient references. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed May 4 01:32:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 4 May 2016 01:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Clarify how to properly create and destroy dependent instances In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200650#comment-13200650 ] Martin Kouba commented on CDI-457: ---------------------------------- [~meetoblivion] Please don't change the description of an issue if the discussion already started - this makes the discussion less understandable. And no, {{@TransientReference}} can be only applied to a parameter injection point - @Dependent scoped contextual instances injected into this parameters is destroyed when the invocation completes. > Clarify how to properly create and destroy dependent instances > -------------------------------------------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Using @TransientReference today for class definitions allows you to mark it as dependent. > We should allow arbitrary producers to include transient references. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Wed May 4 02:12:44 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 4 May 2016 08:12:44 +0200 Subject: [cdi-dev] CDI-508 - Which java classes can be managed beans In-Reply-To: References: Message-ID: <572992DC.8050305@redhat.com> Hi all, given that local and anonymous classes are special kinds of inner classes, we could also simply change the sentence to: "It is not an inner class." Anyway, I think the change of the first sentence is much more important, i.e. removing the "top-level"... Maybe we should also remove "top-level" from the next sentence: "It is a top-level non-abstract class, or is annotated `@Decorator`." So that we would end up with: A Java class is a managed bean if it meets all of the following conditions: * It is not an inner class. * It is a non-abstract class, or is annotated `@Decorator`. * It does not implement `javax.enterprise.inject.spi.Extension`. * It is not annotated `@Vetoed` or in a package annotated `@Vetoed`. * It has an appropriate constructor - either: What do you think? Martin Dne 4.5.2016 v 02:32 John D. Ament napsal(a): > All, > > I think I had an action item to get this clarified, not 100% sure, but > let me give this a shot. > > Tomas raised a PR for CDI-508 to clarify which classes are meant to be > managed beans. You can find that PR here: > https://github.com/cdi-spec/cdi/pull/282/ > > The line that doesn't sound right to me in the change is to go from: > > It is not a non-static inner class. > > to > > It is not a non-static nested class. > > I'll use the java programming language tutorial as a point of reference, > you can read the page I'll refer to here: > https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html > > Basically, non-static nested classes are AKA inner classes. The term > "non-static inner class" shouldn't exist, and that means the original > text doesn't make sense, and should probably be inferred as "It is not > an inner class" > > From reading this part of the spec, it becomes unreadable due to the > double negative (probably why the aka exists). My proposal was to > change the line to instead read (in a positive way) "It is a static > nested class" but I can also understand if we want to do this in an > exclusion pattern rather than an inclusion pattern. > > Thoughts? > > John > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 tremes at redhat.com Wed May 4 03:12:23 2016 From: tremes at redhat.com (Tomas Remes) Date: Wed, 4 May 2016 03:12:23 -0400 (EDT) Subject: [cdi-dev] CDI-508 - Which java classes can be managed beans In-Reply-To: <572992DC.8050305@redhat.com> References: <572992DC.8050305@redhat.com> Message-ID: <1475456860.571975.1462345943966.JavaMail.zimbra@redhat.com> Hi, Yes this proposal is sufficient and reads better. I can change my PR if there aren't any further objections? Thank's Tom ----- Original Message ----- From: "Martin Kouba" To: "John D. Ament" , cdi-dev at lists.jboss.org Sent: Wednesday, May 4, 2016 8:12:44 AM Subject: Re: [cdi-dev] CDI-508 - Which java classes can be managed beans Hi all, given that local and anonymous classes are special kinds of inner classes, we could also simply change the sentence to: "It is not an inner class." Anyway, I think the change of the first sentence is much more important, i.e. removing the "top-level"... Maybe we should also remove "top-level" from the next sentence: "It is a top-level non-abstract class, or is annotated `@Decorator`." So that we would end up with: A Java class is a managed bean if it meets all of the following conditions: * It is not an inner class. * It is a non-abstract class, or is annotated `@Decorator`. * It does not implement `javax.enterprise.inject.spi.Extension`. * It is not annotated `@Vetoed` or in a package annotated `@Vetoed`. * It has an appropriate constructor - either: What do you think? Martin Dne 4.5.2016 v 02:32 John D. Ament napsal(a): > All, > > I think I had an action item to get this clarified, not 100% sure, but > let me give this a shot. > > Tomas raised a PR for CDI-508 to clarify which classes are meant to be > managed beans. You can find that PR here: > https://github.com/cdi-spec/cdi/pull/282/ > > The line that doesn't sound right to me in the change is to go from: > > It is not a non-static inner class. > > to > > It is not a non-static nested class. > > I'll use the java programming language tutorial as a point of reference, > you can read the page I'll refer to here: > https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html > > Basically, non-static nested classes are AKA inner classes. The term > "non-static inner class" shouldn't exist, and that means the original > text doesn't make sense, and should probably be inferred as "It is not > an inner class" > > From reading this part of the spec, it becomes unreadable due to the > double negative (probably why the aka exists). My proposal was to > change the line to instead read (in a positive way) "It is a static > nested class" but I can also understand if we want to do this in an > exclusion pattern rather than an inclusion pattern. > > Thoughts? > > John > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 manovotn at redhat.com Wed May 4 03:36:26 2016 From: manovotn at redhat.com (Matej Novotny) Date: Wed, 4 May 2016 03:36:26 -0400 (EDT) Subject: [cdi-dev] CDI-508 - Which java classes can be managed beans In-Reply-To: <1475456860.571975.1462345943966.JavaMail.zimbra@redhat.com> References: <572992DC.8050305@redhat.com> <1475456860.571975.1462345943966.JavaMail.zimbra@redhat.com> Message-ID: <1049679450.48479656.1462347386406.JavaMail.zimbra@redhat.com> Sounds feasible, +1 Matej ----- Original Message ----- > From: "Tomas Remes" > To: "Martin Kouba" > Cc: cdi-dev at lists.jboss.org > Sent: Wednesday, May 4, 2016 9:12:23 AM > Subject: Re: [cdi-dev] CDI-508 - Which java classes can be managed beans > > > Hi, > > Yes this proposal is sufficient and reads better. I can change my PR if there > aren't any further objections? > > Thank's > Tom > > ----- Original Message ----- > From: "Martin Kouba" > To: "John D. Ament" , cdi-dev at lists.jboss.org > Sent: Wednesday, May 4, 2016 8:12:44 AM > Subject: Re: [cdi-dev] CDI-508 - Which java classes can be managed beans > > Hi all, > > given that local and anonymous classes are special kinds of inner > classes, we could also simply change the sentence to: > > "It is not an inner class." > > Anyway, I think the change of the first sentence is much more important, > i.e. removing the "top-level"... > > Maybe we should also remove "top-level" from the next sentence: > "It is a top-level non-abstract class, or is annotated `@Decorator`." > > So that we would end up with: > > A Java class is a managed bean if it meets all of the following conditions: > * It is not an inner class. > * It is a non-abstract class, or is annotated `@Decorator`. > * It does not implement `javax.enterprise.inject.spi.Extension`. > * It is not annotated `@Vetoed` or in a package annotated `@Vetoed`. > * It has an appropriate constructor - either: > > What do you think? > > Martin > > > Dne 4.5.2016 v 02:32 John D. Ament napsal(a): > > All, > > > > I think I had an action item to get this clarified, not 100% sure, but > > let me give this a shot. > > > > Tomas raised a PR for CDI-508 to clarify which classes are meant to be > > managed beans. You can find that PR here: > > https://github.com/cdi-spec/cdi/pull/282/ > > > > The line that doesn't sound right to me in the change is to go from: > > > > It is not a non-static inner class. > > > > to > > > > It is not a non-static nested class. > > > > I'll use the java programming language tutorial as a point of reference, > > you can read the page I'll refer to here: > > https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html > > > > Basically, non-static nested classes are AKA inner classes. The term > > "non-static inner class" shouldn't exist, and that means the original > > text doesn't make sense, and should probably be inferred as "It is not > > an inner class" > > > > From reading this part of the spec, it becomes unreadable due to the > > double negative (probably why the aka exists). My proposal was to > > change the line to instead read (in a positive way) "It is a static > > nested class" but I can also understand if we want to do this in an > > exclusion pattern rather than an inclusion pattern. > > > > Thoughts? > > > > John > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > > code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.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. > From antonin at stefanutti.fr Wed May 4 04:26:07 2016 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Wed, 4 May 2016 08:26:07 +0000 Subject: [cdi-dev] New builders API In-Reply-To: <1509090947.48315712.1462286411872.JavaMail.zimbra@redhat.com> References: <571DC77E.5000606@redhat.com> <5721CD19.2040603@redhat.com> <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> <1509090947.48315712.1462286411872.JavaMail.zimbra@redhat.com> Message-ID: Hi Matej, Please find my answer inline. Let me add an additional point: It is not possible to add @Dependent programmatic bean whose production depends on the injection point. There is the BeanConfigurator produceWith(Function, U> callback) method which is a smart way to be able to produce bean instances depending on other bean instances (like producer methods with injection points as parameters), but it cannot depend on the injection point for @Dependent beans. So similarly to: ObserverMethodConfigurator notifyWith(BiConsumer callback); where EventMetadata is kind of the equivalent of InjectionPoint for event we could have: BeanConfigurator produceWith(Function callback); and: BeanConfigurator produceWith(BiFunction, InjectionPoint, U> callback); Antonin > On 03 May 2016, at 16:40, Matej Novotny wrote: > > Hello > >> - There is a read(AnnotatedType type) API: equivalent API for >> AnnotatedField and AnnotatedMethod would be useful > > Not sure I understand the use case here. You start with AnnotatedTypeConfigurator and you can call, say, methods(). > That will give you a Set>. So the type of of MethodConfigurator is based on the type of the former configurator. > Could you support your thoughts by a code snippet showing the usage? AfterBeanDiscovery.read(AnnotatedType type) is useful to initialise a BeanConfigurator from an annotated type corresponding to a managed bean. In my use case, I?d need to be able to initialise a BeanConfigurator from an annotated method corresponding to a producer method bean. I can imagine that useful for annotated field as well. >> - Having the ability to customise the toString method by providing a >> Supplier would be useful > > This might be a good idea. Where exactly do you need this method? BeanConfigurator or even elsewhere? Yes BeanConfigurator. Ideally there should have a toString(Supplier) and a toString(Function>) method as it my case I rely on the bean information. >> It?d be useful to be able to reuse some InjectionTarget that are used for >> discovered beans as well directly instead of having to call instantiate the >> injection target and call produceWith and destroyWith separately > > Not sure I follow you here - produceWith is a way to provide a producer method for your bean (assuming we are talking about Beanconfigurator.produceWith). > That merely tells CDI how to instantiate the bean if you are to inject it somewhere. You do not really need to handle InjectionTarget here. Same goes for destroyWith. > I might be missing something though. In Camel CDI, there is a mix of discovered beans and programmatic beans to manage Camel context beans. They both should use the same InjectionTarget / Producer. So as the discovered Camel context beans have their InjectionTarget and Producer customised https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L139-L145, the programmatic beans configured with addBean should reuse the came InjectionTarget / Producer: https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextProducer.java#L46 https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextOsgiProducer.java So instead of having to do something like: Producer customProducer = new CustomProducer(); abd.addBean().createWith(customProducer::produce).disposeWith(customProducer::dispose); I?d like to write: abd.addBean().producer(customProducer); >> - I found a bit cumbersome to work with addObserverMethod: as the type >> parameter is not driven by the observedType, generics hiccups come into play >> with the notifyWith API. In my example, I had to rely on an extra method to >> have the type parameter provided: > > As configurators are not reusable, your approach is imho perfectly right. If you were to add several observers, you need to call AfterBeanDiscovery.addObserver() several times anyway. > It should be also possible to achieve the same things you have there without additional method (just within the for cycle). So I do not really see the 'generic hiccup' you are talking about. The point is that the following code doesn?t compile: cdiEventEndpoints.values().stream().forEach(endpoint -> abd.addObserverMethod() .beanClass(CdiEventComponent.class) .observedType(endpoint.getType()) .qualifiers(endpoint.getQualifiers()) .notifyWith(endpoint::notify); I need to write: cdiEventEndpoints.values().stream().forEach(endpoint -> addCdiEventObserver(abd, endpoint)); private void addCdiEventObserver(AfterBeanDiscovery abd, CdiEventEndpoint endpoint) { abd.addObserverMethod() .beanClass(CdiEventComponent.class) .observedType(endpoint.getType()) .qualifiers(endpoint.getQualifiers()) .notifyWith(endpoint::notify); } The code is available here: https://github.com/astefanutti/camel-cdi/blob/cdi-2.0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 It?s similar to the issue with the example presented in Weld 3.0.0.Alpha16: void afterBeanDiscovery(@Observes AfterBeanDiscovery event) { // Add a new synthetic observer method - no need to use the fluent API ObserverMethodConfigurator configurator = event.addObserverMethod(); configurator.observedType(Foo.class); configurator.reception(Reception.ALWAYS); configurator.transactionPhase(TransactionPhase.IN_PROGRESS); configurator.notifyWith((foo) -> System.out.println("Foo observed: " + foo)); } The problem is that the type captured in the lambda expression for ?foo? is Object which is rather useless in most cases, while it should be Foo. > Btw please make sure to attend the CDI mtg in the evening. You can voice your needs/ideas there :) > > Matej > > ----- Original Message ----- >> From: "Antonin Stefanutti" >> To: cdi-dev at lists.jboss.org >> Sent: Tuesday, May 3, 2016 3:48:39 PM >> Subject: Re: [cdi-dev] New builders API >> >> Hi All, >> >> Not sure what?s the best form to share my feedback, so here it is :) >> >> I?ve tested CDI 2.0.Alpha4 / Weld 3.0.0.Alpha3 and the new "builder API" on >> the Camel CDI extension and here are the points I?ve had gathered: >> >> - There is a read(AnnotatedType type) API: equivalent API for >> AnnotatedField and AnnotatedMethod would be useful >> - Having the ability to customise the toString method by providing a >> Supplier would be useful >> - There are API (createWith, produceWith, ...) that are basically the >> decomposition of what an injection target is: in the Camel CDI use case, >> It?d be useful to be able to reuse some InjectionTarget that are used for >> discovered beans as well directly instead of having to call instantiate the >> injection target and call produceWith and destroyWith separately >> - I found a bit cumbersome to work with addObserverMethod: as the type >> parameter is not driven by the observedType, generics hiccups come into play >> with the notifyWith API. In my example, I had to rely on an extra method to >> have the type parameter provided: >> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 >> >> Unfortunately, I haven?t been able to get rid of the boilerplate code (like >> SyntheticBean [1], SyntheticBeanAttributes [2], SyntheticInjectionTarget >> [3]) that the new builder API would have permitted to eliminate. Indeed, >> while the "Metadata configuration API" probably solves the majority / >> simplest use cases, it does not address the one in Camel CDI (as already >> illustrated by John and I from different angles). >> >> IMO, it?d be worth investigating on an unified Builder and configurator API >> bringing the best of both worlds. >> >> The rewrite of Camel CDI on CDI 2.0 is available here: >> https://github.com/astefanutti/camel-cdi/commits/cdi-2.0. >> >> [1]: >> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBean.java#L34 >> [2]: >> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBeanAttributes.java#L31 >> [3]: >> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticInjectionTarget.java#L29 >> >> Antonin >> >>> On 03 May 2016, at 15:14, Antoine Sabot-Durand >>> wrote: >>> >>> Thanks for all the feedback on the API. >>> >>> Before going into detail I wanted to put the accent on the Weld 3.0.Alpha16 >>> release post[1] which give a good explanation regarding this API. Its the >>> best starting point to discover this new API IMO. Thanks Martin, Tomas and >>> Matej for this release. >>> >>> @John. The debate Configurator vs Builder is still open. At the moment we >>> focused on configurator since they are easier to limit to a given >>> container lifecycle, but having builders to reuse the configuration could >>> make sense as well. AnnotatedType is a special case since it could make >>> sense to use it at runtime (to ease creation of an InjectionTarget for >>> instance, so perhaps it will require a Builder. >>> If we keep the API in this spirit for the release, it should be better to >>> talk about Configurator API vs Builder API to avoid confusion for missing >>> build() methods ;) >>> >>> @Antonin the enhancement you propose is very interesting but as Martin said >>> we could imagine a solution to load an existing bean after decision on the >>> API (a mute(Bean) method in ABD perhaps). >>> >>> For me the goal is to decide if we are on the right path and avoid decision >>> that will prevent future enhancement. I think having this API perfect and >>> complete in one PR is almost impossible. So we should validate something >>> to move on missing features or enhancements. >>> >>> Antoine >>> >>> [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>> >>> Le jeu. 28 avr. 2016 ? 10:43, Martin Kouba a ?crit : >>> Hi all, >>> >>> we've just released Weld 3.0.0.Alpha16. So anyone can start playing with >>> the API, discover possibilities and find potential issues: >>> >>> http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>> >>> Any feedback is appreciated! >>> >>> Martin >>> >>> Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): >>>> Hi all, >>>> >>>> me and Matej, we've already tried to explain some points in cdi/pull/287 >>>> discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on >>>> 2.0.Alpha4) later this week so that everyone can start playing with the >>>> new API. And we'd like to prepare some simple examples to help people >>>> get started as well. >>>> >>>> Martin >>>> >>>> >>>> Dne 23.4.2016 v 12:56 John D. Ament napsal(a): >>>>> Hey guys >>>>> >>>>> Based on the last f2f I was in, I took an action item to look at how >>>>> applications can leverage the new builder methods/classes from this PR: >>>>> https://github.com/cdi-spec/cdi/pull/287 >>>>> >>>>> To do this, I took some existing OSS CDI extensions and converted parts >>>>> to use the new APIs instead of the old ones. >>>>> >>>>> The results were iffy to be honest. Here's some of the key issues I >>>>> noticed: >>>>> >>>>> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean >>>>> bean) >>>>> In the latter, it's clearer to a developer which attributes are required >>>>> vs optional. Builders typically use sensible defaults. Maybe that was >>>>> the intention here, but I couldn't really get that sense when converting >>>>> over. It also wasn't clear what to do when done. I suspect I just >>>>> leave it, but without some kind of closing "build()" or "done()" method, >>>>> it becomes ambiguous. >>>>> >>>>> - Annotated*Configurator >>>>> TBH, I have no idea what I was configuring in this one at the first >>>>> pass. I started with a method. I wanted to replace the method's >>>>> annotations. It seemed like I could set that up using the configurator, >>>>> but I ended up having to do setAnnotated at the end anyways, so I'm not >>>>> sure what the configurator bought me. >>>>> >>>>> The one nice thing I saw was the simpler to use lambda functions. Being >>>>> able to stream through things like annotated method made the code much >>>>> cleaner. >>>>> >>>>> For the open source code, I'll try to get some gists together that show >>>>> the changes. Maybe there's something I'm missing, so wouldn't mind a >>>>> second set of eyes on the changes to see. >>>>> >>>>> John >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the >>>>> code under the Apache License, Version 2 >>>>> (http://www.apache.org/licenses/LICENSE-2.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. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code >> under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.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 mkouba at redhat.com Wed May 4 04:43:53 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 4 May 2016 10:43:53 +0200 Subject: [cdi-dev] New builders API In-Reply-To: References: <571DC77E.5000606@redhat.com> <5721CD19.2040603@redhat.com> <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> <1509090947.48315712.1462286411872.JavaMail.zimbra@redhat.com> Message-ID: <5729B649.6040500@redhat.com> Dne 4.5.2016 v 10:26 Antonin Stefanutti napsal(a): > Hi Matej, > > Please find my answer inline. > > Let me add an additional point: > > It is not possible to add @Dependent programmatic bean whose production depends on the injection point. > > There is the BeanConfigurator produceWith(Function, U> callback) method which is a smart way to be able to produce bean instances depending on other bean instances (like producer methods with injection points as parameters), but it cannot depend on the injection point for @Dependent beans. > > So similarly to: > > ObserverMethodConfigurator notifyWith(BiConsumer callback); > > where EventMetadata is kind of the equivalent of InjectionPoint for event > > we could have: > > BeanConfigurator produceWith(Function callback); > > and: > > BeanConfigurator produceWith(BiFunction, InjectionPoint, U> callback); Sound useful. On the other hand, it's a very specific use case - more or less simulating a producer method returning a dependent bean instance. For other scopes the IP would have to be null/absent. Also this is not possible with the current API either (at least not in a portable way - no IP available during Contextual.create()). > > Antonin > >> On 03 May 2016, at 16:40, Matej Novotny wrote: >> >> Hello >> >>> - There is a read(AnnotatedType type) API: equivalent API for >>> AnnotatedField and AnnotatedMethod would be useful >> >> Not sure I understand the use case here. You start with AnnotatedTypeConfigurator and you can call, say, methods(). >> That will give you a Set>. So the type of of MethodConfigurator is based on the type of the former configurator. >> Could you support your thoughts by a code snippet showing the usage? > > AfterBeanDiscovery.read(AnnotatedType type) is useful to initialise a BeanConfigurator from an annotated type corresponding to a managed bean. In my use case, I?d need to be able to initialise a BeanConfigurator from an annotated method corresponding to a producer method bean. I can imagine that useful for annotated field as well. > >>> - Having the ability to customise the toString method by providing a >>> Supplier would be useful >> >> This might be a good idea. Where exactly do you need this method? BeanConfigurator or even elsewhere? > > Yes BeanConfigurator. Ideally there should have a toString(Supplier) and a toString(Function>) method as it my case I rely on the bean information. > >>> It?d be useful to be able to reuse some InjectionTarget that are used for >>> discovered beans as well directly instead of having to call instantiate the >>> injection target and call produceWith and destroyWith separately >> >> Not sure I follow you here - produceWith is a way to provide a producer method for your bean (assuming we are talking about Beanconfigurator.produceWith). >> That merely tells CDI how to instantiate the bean if you are to inject it somewhere. You do not really need to handle InjectionTarget here. Same goes for destroyWith. >> I might be missing something though. > > In Camel CDI, there is a mix of discovered beans and programmatic beans to manage Camel context beans. They both should use the same InjectionTarget / Producer. So as the discovered Camel context beans have their InjectionTarget and Producer customised https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L139-L145, the programmatic beans configured with addBean should reuse the came InjectionTarget / Producer: > https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextProducer.java#L46 > https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextOsgiProducer.java > > So instead of having to do something like: > Producer customProducer = new CustomProducer(); > abd.addBean().createWith(customProducer::produce).disposeWith(customProducer::dispose); > > I?d like to write: > abd.addBean().producer(customProducer); > >>> - I found a bit cumbersome to work with addObserverMethod: as the type >>> parameter is not driven by the observedType, generics hiccups come into play >>> with the notifyWith API. In my example, I had to rely on an extra method to >>> have the type parameter provided: >> >> As configurators are not reusable, your approach is imho perfectly right. If you were to add several observers, you need to call AfterBeanDiscovery.addObserver() several times anyway. >> It should be also possible to achieve the same things you have there without additional method (just within the for cycle). So I do not really see the 'generic hiccup' you are talking about. > > The point is that the following code doesn?t compile: > > cdiEventEndpoints.values().stream().forEach(endpoint -> abd.addObserverMethod() > .beanClass(CdiEventComponent.class) > .observedType(endpoint.getType()) > .qualifiers(endpoint.getQualifiers()) > .notifyWith(endpoint::notify); > > I need to write: > > cdiEventEndpoints.values().stream().forEach(endpoint -> addCdiEventObserver(abd, endpoint)); > > private void addCdiEventObserver(AfterBeanDiscovery abd, CdiEventEndpoint endpoint) { > abd.addObserverMethod() > .beanClass(CdiEventComponent.class) > .observedType(endpoint.getType()) > .qualifiers(endpoint.getQualifiers()) > .notifyWith(endpoint::notify); > } > > The code is available here: > > https://github.com/astefanutti/camel-cdi/blob/cdi-2.0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 > > It?s similar to the issue with the example presented in Weld 3.0.0.Alpha16: > > void afterBeanDiscovery(@Observes AfterBeanDiscovery event) { > // Add a new synthetic observer method - no need to use the fluent API > ObserverMethodConfigurator configurator = event.addObserverMethod(); > configurator.observedType(Foo.class); > configurator.reception(Reception.ALWAYS); > configurator.transactionPhase(TransactionPhase.IN_PROGRESS); > configurator.notifyWith((foo) -> System.out.println("Foo observed: " + foo)); > } > > The problem is that the type captured in the lambda expression for ?foo? is Object which is rather useless in most cases, while it should be Foo. > >> Btw please make sure to attend the CDI mtg in the evening. You can voice your needs/ideas there :) >> >> Matej >> >> ----- Original Message ----- >>> From: "Antonin Stefanutti" >>> To: cdi-dev at lists.jboss.org >>> Sent: Tuesday, May 3, 2016 3:48:39 PM >>> Subject: Re: [cdi-dev] New builders API >>> >>> Hi All, >>> >>> Not sure what?s the best form to share my feedback, so here it is :) >>> >>> I?ve tested CDI 2.0.Alpha4 / Weld 3.0.0.Alpha3 and the new "builder API" on >>> the Camel CDI extension and here are the points I?ve had gathered: >>> >>> - There is a read(AnnotatedType type) API: equivalent API for >>> AnnotatedField and AnnotatedMethod would be useful >>> - Having the ability to customise the toString method by providing a >>> Supplier would be useful >>> - There are API (createWith, produceWith, ...) that are basically the >>> decomposition of what an injection target is: in the Camel CDI use case, >>> It?d be useful to be able to reuse some InjectionTarget that are used for >>> discovered beans as well directly instead of having to call instantiate the >>> injection target and call produceWith and destroyWith separately >>> - I found a bit cumbersome to work with addObserverMethod: as the type >>> parameter is not driven by the observedType, generics hiccups come into play >>> with the notifyWith API. In my example, I had to rely on an extra method to >>> have the type parameter provided: >>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 >>> >>> Unfortunately, I haven?t been able to get rid of the boilerplate code (like >>> SyntheticBean [1], SyntheticBeanAttributes [2], SyntheticInjectionTarget >>> [3]) that the new builder API would have permitted to eliminate. Indeed, >>> while the "Metadata configuration API" probably solves the majority / >>> simplest use cases, it does not address the one in Camel CDI (as already >>> illustrated by John and I from different angles). >>> >>> IMO, it?d be worth investigating on an unified Builder and configurator API >>> bringing the best of both worlds. >>> >>> The rewrite of Camel CDI on CDI 2.0 is available here: >>> https://github.com/astefanutti/camel-cdi/commits/cdi-2.0. >>> >>> [1]: >>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBean.java#L34 >>> [2]: >>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBeanAttributes.java#L31 >>> [3]: >>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticInjectionTarget.java#L29 >>> >>> Antonin >>> >>>> On 03 May 2016, at 15:14, Antoine Sabot-Durand >>>> wrote: >>>> >>>> Thanks for all the feedback on the API. >>>> >>>> Before going into detail I wanted to put the accent on the Weld 3.0.Alpha16 >>>> release post[1] which give a good explanation regarding this API. Its the >>>> best starting point to discover this new API IMO. Thanks Martin, Tomas and >>>> Matej for this release. >>>> >>>> @John. The debate Configurator vs Builder is still open. At the moment we >>>> focused on configurator since they are easier to limit to a given >>>> container lifecycle, but having builders to reuse the configuration could >>>> make sense as well. AnnotatedType is a special case since it could make >>>> sense to use it at runtime (to ease creation of an InjectionTarget for >>>> instance, so perhaps it will require a Builder. >>>> If we keep the API in this spirit for the release, it should be better to >>>> talk about Configurator API vs Builder API to avoid confusion for missing >>>> build() methods ;) >>>> >>>> @Antonin the enhancement you propose is very interesting but as Martin said >>>> we could imagine a solution to load an existing bean after decision on the >>>> API (a mute(Bean) method in ABD perhaps). >>>> >>>> For me the goal is to decide if we are on the right path and avoid decision >>>> that will prevent future enhancement. I think having this API perfect and >>>> complete in one PR is almost impossible. So we should validate something >>>> to move on missing features or enhancements. >>>> >>>> Antoine >>>> >>>> [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>>> >>>> Le jeu. 28 avr. 2016 ? 10:43, Martin Kouba a ?crit : >>>> Hi all, >>>> >>>> we've just released Weld 3.0.0.Alpha16. So anyone can start playing with >>>> the API, discover possibilities and find potential issues: >>>> >>>> http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>>> >>>> Any feedback is appreciated! >>>> >>>> Martin >>>> >>>> Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): >>>>> Hi all, >>>>> >>>>> me and Matej, we've already tried to explain some points in cdi/pull/287 >>>>> discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on >>>>> 2.0.Alpha4) later this week so that everyone can start playing with the >>>>> new API. And we'd like to prepare some simple examples to help people >>>>> get started as well. >>>>> >>>>> Martin >>>>> >>>>> >>>>> Dne 23.4.2016 v 12:56 John D. Ament napsal(a): >>>>>> Hey guys >>>>>> >>>>>> Based on the last f2f I was in, I took an action item to look at how >>>>>> applications can leverage the new builder methods/classes from this PR: >>>>>> https://github.com/cdi-spec/cdi/pull/287 >>>>>> >>>>>> To do this, I took some existing OSS CDI extensions and converted parts >>>>>> to use the new APIs instead of the old ones. >>>>>> >>>>>> The results were iffy to be honest. Here's some of the key issues I >>>>>> noticed: >>>>>> >>>>>> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean >>>>>> bean) >>>>>> In the latter, it's clearer to a developer which attributes are required >>>>>> vs optional. Builders typically use sensible defaults. Maybe that was >>>>>> the intention here, but I couldn't really get that sense when converting >>>>>> over. It also wasn't clear what to do when done. I suspect I just >>>>>> leave it, but without some kind of closing "build()" or "done()" method, >>>>>> it becomes ambiguous. >>>>>> >>>>>> - Annotated*Configurator >>>>>> TBH, I have no idea what I was configuring in this one at the first >>>>>> pass. I started with a method. I wanted to replace the method's >>>>>> annotations. It seemed like I could set that up using the configurator, >>>>>> but I ended up having to do setAnnotated at the end anyways, so I'm not >>>>>> sure what the configurator bought me. >>>>>> >>>>>> The one nice thing I saw was the simpler to use lambda functions. Being >>>>>> able to stream through things like annotated method made the code much >>>>>> cleaner. >>>>>> >>>>>> For the open source code, I'll try to get some gists together that show >>>>>> the changes. Maybe there's something I'm missing, so wouldn't mind a >>>>>> second set of eyes on the changes to see. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses the >>>>>> code under the Apache License, Version 2 >>>>>> (http://www.apache.org/licenses/LICENSE-2.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. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code >>> under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.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 issues at jboss.org Wed May 4 05:38:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 4 May 2016 05:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200787#comment-13200787 ] Mark Struberg commented on CDI-420: ----------------------------------- We had an additional idea in a recent discussion: Keep the current bean-discovery-modes but adding another beans.xml tag or attribute in addition to bean-discovery-mode which enables this functionality. Examples: {quote} {quote} or {quote} false {quote} Of course we need to discuss a.) whether it should be an attribute or tag b.) the name of the attribute or tag c.) if the logic should be 'disabling' (auto-dependent="false") or 'enabling' (only-scoped-beans="true") > add a bean-discovery-mode 'scoped' > ---------------------------------- > > 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.4.11#64026) From issues at jboss.org Wed May 4 05:38:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 4 May 2016 05:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200787#comment-13200787 ] Mark Struberg edited comment on CDI-420 at 5/4/16 5:37 AM: ----------------------------------------------------------- We had an additional idea in a recent discussion: Keep the current bean-discovery-modes but adding another beans.xml tag or attribute in addition to bean-discovery-mode which enables this functionality. Examples: {code} {code} or {code} false {code} Of course we need to discuss a.) whether it should be an attribute or tag b.) the name of the attribute or tag c.) if the logic should be 'disabling' (auto-dependent="false") or 'enabling' (only-scoped-beans="true") was (Author: struberg): We had an additional idea in a recent discussion: Keep the current bean-discovery-modes but adding another beans.xml tag or attribute in addition to bean-discovery-mode which enables this functionality. Examples: {quote} {quote} or {quote} false {quote} Of course we need to discuss a.) whether it should be an attribute or tag b.) the name of the attribute or tag c.) if the logic should be 'disabling' (auto-dependent="false") or 'enabling' (only-scoped-beans="true") > add a bean-discovery-mode 'scoped' > ---------------------------------- > > 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.4.11#64026) From antonin at stefanutti.fr Wed May 4 05:57:55 2016 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Wed, 4 May 2016 09:57:55 +0000 Subject: [cdi-dev] New builders API In-Reply-To: <5729B649.6040500@redhat.com> References: <571DC77E.5000606@redhat.com> <5721CD19.2040603@redhat.com> <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> <1509090947.48315712.1462286411872.JavaMail.zimbra@redhat.com> <5729B649.6040500@redhat.com> Message-ID: <57D40A65-83AD-4FF2-B9DA-278DEF1BC7A8@stefanutti.fr> Hi Martin, > On 04 May 2016, at 10:43, Martin Kouba wrote: > > Dne 4.5.2016 v 10:26 Antonin Stefanutti napsal(a): >> Hi Matej, >> >> Please find my answer inline. >> >> Let me add an additional point: >> >> It is not possible to add @Dependent programmatic bean whose production depends on the injection point. >> >> There is the BeanConfigurator produceWith(Function, U> callback) method which is a smart way to be able to produce bean instances depending on other bean instances (like producer methods with injection points as parameters), but it cannot depend on the injection point for @Dependent beans. >> >> So similarly to: >> >> ObserverMethodConfigurator notifyWith(BiConsumer callback); >> >> where EventMetadata is kind of the equivalent of InjectionPoint for event >> >> we could have: >> >> BeanConfigurator produceWith(Function callback); >> >> and: >> >> BeanConfigurator produceWith(BiFunction, InjectionPoint, U> callback); > > Sound useful. On the other hand, it's a very specific use case - more or less simulating a producer method returning a dependent bean instance. For other scopes the IP would have to be null/absent. Also this is not possible with the current API either (at least not in a portable way - no IP available during Contextual.create()). I?d say it is the equivalent of: BeanConfigurator produceWith(Function, U> callback); For @Dependent bean that rely on the InjectionPoint metadata. The point is that it is very convoluted to customise that kind of bean (producer method that depends on the injection point) in the AfterBeanDiscovery event (given the information is not available at the moment ProcessBeanAttributes is fired). Plus I don?t know of any way to add a programmatic bean that rely on the injection point metadata to create instances. In Camel CDI, here is the way it is done for every Camel primitives beans (like Endpoint, ProducerTemplate, ...): You have a producer method bean, like: @Produces @Typed(MockEndpoint.class) // Alternative is dynamically added in CdiCamelExtension private static MockEndpoint mockEndpointFromMember(InjectionPoint ip, @Any Instance instance, CdiCamelExtension extension) { String uri = "mock:" + ip.getMember().getName(); return selectContext(ip, instance, extension).getEndpoint(uri, MockEndpoint.class); } That bean needs to be customised as extra qualifiers need to be added in AfterBeanDiscovery. So the producer method is first vetoed and a new bean is added that way: private Bean camelProducerBean(BeanManager manager, AnnotatedMethod am, Set qualifiers) { return manager.createBean( new BeanDecorator<>(manager.createBeanAttributes(am), qualifiers), CdiCamelFactory.class, manager.getProducerFactory(am, (Bean) manager.resolve(manager.getBeans(CdiCamelFactory.class)))); } With that API, It could be done with: abd.addBean() .addType(MockEndpoint.class) .produceWith((instance, ip) -> selectContext(ip, instance, extension) .getEndpoint("mock:" + ip.getMember().getName(), MockEndpoint.class)); >> >> Antonin >> >>> On 03 May 2016, at 16:40, Matej Novotny wrote: >>> >>> Hello >>> >>>> - There is a read(AnnotatedType type) API: equivalent API for >>>> AnnotatedField and AnnotatedMethod would be useful >>> >>> Not sure I understand the use case here. You start with AnnotatedTypeConfigurator and you can call, say, methods(). >>> That will give you a Set>. So the type of of MethodConfigurator is based on the type of the former configurator. >>> Could you support your thoughts by a code snippet showing the usage? >> >> AfterBeanDiscovery.read(AnnotatedType type) is useful to initialise a BeanConfigurator from an annotated type corresponding to a managed bean. In my use case, I?d need to be able to initialise a BeanConfigurator from an annotated method corresponding to a producer method bean. I can imagine that useful for annotated field as well. >> >>>> - Having the ability to customise the toString method by providing a >>>> Supplier would be useful >>> >>> This might be a good idea. Where exactly do you need this method? BeanConfigurator or even elsewhere? >> >> Yes BeanConfigurator. Ideally there should have a toString(Supplier) and a toString(Function>) method as it my case I rely on the bean information. >> >>>> It?d be useful to be able to reuse some InjectionTarget that are used for >>>> discovered beans as well directly instead of having to call instantiate the >>>> injection target and call produceWith and destroyWith separately >>> >>> Not sure I follow you here - produceWith is a way to provide a producer method for your bean (assuming we are talking about Beanconfigurator.produceWith). >>> That merely tells CDI how to instantiate the bean if you are to inject it somewhere. You do not really need to handle InjectionTarget here. Same goes for destroyWith. >>> I might be missing something though. >> >> In Camel CDI, there is a mix of discovered beans and programmatic beans to manage Camel context beans. They both should use the same InjectionTarget / Producer. So as the discovered Camel context beans have their InjectionTarget and Producer customised https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L139-L145, the programmatic beans configured with addBean should reuse the came InjectionTarget / Producer: >> https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextProducer.java#L46 >> https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextOsgiProducer.java >> >> So instead of having to do something like: >> Producer customProducer = new CustomProducer(); >> abd.addBean().createWith(customProducer::produce).disposeWith(customProducer::dispose); >> >> I?d like to write: >> abd.addBean().producer(customProducer); >> >>>> - I found a bit cumbersome to work with addObserverMethod: as the type >>>> parameter is not driven by the observedType, generics hiccups come into play >>>> with the notifyWith API. In my example, I had to rely on an extra method to >>>> have the type parameter provided: >>> >>> As configurators are not reusable, your approach is imho perfectly right. If you were to add several observers, you need to call AfterBeanDiscovery.addObserver() several times anyway. >>> It should be also possible to achieve the same things you have there without additional method (just within the for cycle). So I do not really see the 'generic hiccup' you are talking about. >> >> The point is that the following code doesn?t compile: >> >> cdiEventEndpoints.values().stream().forEach(endpoint -> abd.addObserverMethod() >> .beanClass(CdiEventComponent.class) >> .observedType(endpoint.getType()) >> .qualifiers(endpoint.getQualifiers()) >> .notifyWith(endpoint::notify); >> >> I need to write: >> >> cdiEventEndpoints.values().stream().forEach(endpoint -> addCdiEventObserver(abd, endpoint)); >> >> private void addCdiEventObserver(AfterBeanDiscovery abd, CdiEventEndpoint endpoint) { >> abd.addObserverMethod() >> .beanClass(CdiEventComponent.class) >> .observedType(endpoint.getType()) >> .qualifiers(endpoint.getQualifiers()) >> .notifyWith(endpoint::notify); >> } >> >> The code is available here: >> >> https://github.com/astefanutti/camel-cdi/blob/cdi-2.0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 >> >> It?s similar to the issue with the example presented in Weld 3.0.0.Alpha16: >> >> void afterBeanDiscovery(@Observes AfterBeanDiscovery event) { >> // Add a new synthetic observer method - no need to use the fluent API >> ObserverMethodConfigurator configurator = event.addObserverMethod(); >> configurator.observedType(Foo.class); >> configurator.reception(Reception.ALWAYS); >> configurator.transactionPhase(TransactionPhase.IN_PROGRESS); >> configurator.notifyWith((foo) -> System.out.println("Foo observed: " + foo)); >> } >> >> The problem is that the type captured in the lambda expression for ?foo? is Object which is rather useless in most cases, while it should be Foo. >> >>> Btw please make sure to attend the CDI mtg in the evening. You can voice your needs/ideas there :) >>> >>> Matej >>> >>> ----- Original Message ----- >>>> From: "Antonin Stefanutti" >>>> To: cdi-dev at lists.jboss.org >>>> Sent: Tuesday, May 3, 2016 3:48:39 PM >>>> Subject: Re: [cdi-dev] New builders API >>>> >>>> Hi All, >>>> >>>> Not sure what?s the best form to share my feedback, so here it is :) >>>> >>>> I?ve tested CDI 2.0.Alpha4 / Weld 3.0.0.Alpha3 and the new "builder API" on >>>> the Camel CDI extension and here are the points I?ve had gathered: >>>> >>>> - There is a read(AnnotatedType type) API: equivalent API for >>>> AnnotatedField and AnnotatedMethod would be useful >>>> - Having the ability to customise the toString method by providing a >>>> Supplier would be useful >>>> - There are API (createWith, produceWith, ...) that are basically the >>>> decomposition of what an injection target is: in the Camel CDI use case, >>>> It?d be useful to be able to reuse some InjectionTarget that are used for >>>> discovered beans as well directly instead of having to call instantiate the >>>> injection target and call produceWith and destroyWith separately >>>> - I found a bit cumbersome to work with addObserverMethod: as the type >>>> parameter is not driven by the observedType, generics hiccups come into play >>>> with the notifyWith API. In my example, I had to rely on an extra method to >>>> have the type parameter provided: >>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 >>>> >>>> Unfortunately, I haven?t been able to get rid of the boilerplate code (like >>>> SyntheticBean [1], SyntheticBeanAttributes [2], SyntheticInjectionTarget >>>> [3]) that the new builder API would have permitted to eliminate. Indeed, >>>> while the "Metadata configuration API" probably solves the majority / >>>> simplest use cases, it does not address the one in Camel CDI (as already >>>> illustrated by John and I from different angles). >>>> >>>> IMO, it?d be worth investigating on an unified Builder and configurator API >>>> bringing the best of both worlds. >>>> >>>> The rewrite of Camel CDI on CDI 2.0 is available here: >>>> https://github.com/astefanutti/camel-cdi/commits/cdi-2.0. >>>> >>>> [1]: >>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBean.java#L34 >>>> [2]: >>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBeanAttributes.java#L31 >>>> [3]: >>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticInjectionTarget.java#L29 >>>> >>>> Antonin >>>> >>>>> On 03 May 2016, at 15:14, Antoine Sabot-Durand >>>>> wrote: >>>>> >>>>> Thanks for all the feedback on the API. >>>>> >>>>> Before going into detail I wanted to put the accent on the Weld 3.0.Alpha16 >>>>> release post[1] which give a good explanation regarding this API. Its the >>>>> best starting point to discover this new API IMO. Thanks Martin, Tomas and >>>>> Matej for this release. >>>>> >>>>> @John. The debate Configurator vs Builder is still open. At the moment we >>>>> focused on configurator since they are easier to limit to a given >>>>> container lifecycle, but having builders to reuse the configuration could >>>>> make sense as well. AnnotatedType is a special case since it could make >>>>> sense to use it at runtime (to ease creation of an InjectionTarget for >>>>> instance, so perhaps it will require a Builder. >>>>> If we keep the API in this spirit for the release, it should be better to >>>>> talk about Configurator API vs Builder API to avoid confusion for missing >>>>> build() methods ;) >>>>> >>>>> @Antonin the enhancement you propose is very interesting but as Martin said >>>>> we could imagine a solution to load an existing bean after decision on the >>>>> API (a mute(Bean) method in ABD perhaps). >>>>> >>>>> For me the goal is to decide if we are on the right path and avoid decision >>>>> that will prevent future enhancement. I think having this API perfect and >>>>> complete in one PR is almost impossible. So we should validate something >>>>> to move on missing features or enhancements. >>>>> >>>>> Antoine >>>>> >>>>> [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>>>> >>>>> Le jeu. 28 avr. 2016 ? 10:43, Martin Kouba a ?crit : >>>>> Hi all, >>>>> >>>>> we've just released Weld 3.0.0.Alpha16. So anyone can start playing with >>>>> the API, discover possibilities and find potential issues: >>>>> >>>>> http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>>>> >>>>> Any feedback is appreciated! >>>>> >>>>> Martin >>>>> >>>>> Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): >>>>>> Hi all, >>>>>> >>>>>> me and Matej, we've already tried to explain some points in cdi/pull/287 >>>>>> discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on >>>>>> 2.0.Alpha4) later this week so that everyone can start playing with the >>>>>> new API. And we'd like to prepare some simple examples to help people >>>>>> get started as well. >>>>>> >>>>>> Martin >>>>>> >>>>>> >>>>>> Dne 23.4.2016 v 12:56 John D. Ament napsal(a): >>>>>>> Hey guys >>>>>>> >>>>>>> Based on the last f2f I was in, I took an action item to look at how >>>>>>> applications can leverage the new builder methods/classes from this PR: >>>>>>> https://github.com/cdi-spec/cdi/pull/287 >>>>>>> >>>>>>> To do this, I took some existing OSS CDI extensions and converted parts >>>>>>> to use the new APIs instead of the old ones. >>>>>>> >>>>>>> The results were iffy to be honest. Here's some of the key issues I >>>>>>> noticed: >>>>>>> >>>>>>> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean >>>>>>> bean) >>>>>>> In the latter, it's clearer to a developer which attributes are required >>>>>>> vs optional. Builders typically use sensible defaults. Maybe that was >>>>>>> the intention here, but I couldn't really get that sense when converting >>>>>>> over. It also wasn't clear what to do when done. I suspect I just >>>>>>> leave it, but without some kind of closing "build()" or "done()" method, >>>>>>> it becomes ambiguous. >>>>>>> >>>>>>> - Annotated*Configurator >>>>>>> TBH, I have no idea what I was configuring in this one at the first >>>>>>> pass. I started with a method. I wanted to replace the method's >>>>>>> annotations. It seemed like I could set that up using the configurator, >>>>>>> but I ended up having to do setAnnotated at the end anyways, so I'm not >>>>>>> sure what the configurator bought me. >>>>>>> >>>>>>> The one nice thing I saw was the simpler to use lambda functions. Being >>>>>>> able to stream through things like annotated method made the code much >>>>>>> cleaner. >>>>>>> >>>>>>> For the open source code, I'll try to get some gists together that show >>>>>>> the changes. Maybe there's something I'm missing, so wouldn't mind a >>>>>>> second set of eyes on the changes to see. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>>> Note that for all code provided on this list, the provider licenses the >>>>>>> code under the Apache License, Version 2 >>>>>>> (http://www.apache.org/licenses/LICENSE-2.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. >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code >>>> under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.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 antonin at stefanutti.fr Wed May 4 06:01:04 2016 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Wed, 4 May 2016 10:01:04 +0000 Subject: [cdi-dev] New builders API In-Reply-To: References: <571DC77E.5000606@redhat.com> <5721CD19.2040603@redhat.com> <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> <1509090947.48315712.1462286411872.JavaMail.zimbra@redhat.com> Message-ID: <5BE5AAB0-68CE-4394-8E6D-693A1F722D52@stefanutti.fr> For the following point: >>> >>> It?d be useful to be able to reuse some InjectionTarget that are used for >>> discovered beans as well directly instead of having to call instantiate the >>> injection target and call produceWith and destroyWith separately >> >> Not sure I follow you here - produceWith is a way to provide a producer method for your bean (assuming we are talking about Beanconfigurator.produceWith). >> That merely tells CDI how to instantiate the bean if you are to inject it somewhere. You do not really need to handle InjectionTarget here. Same goes for destroyWith. >> I might be missing something though. > > In Camel CDI, there is a mix of discovered beans and programmatic beans to manage Camel context beans. They both should use the same InjectionTarget / Producer. So as the discovered Camel context beans have their InjectionTarget and Producer customised https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L139-L145, the programmatic beans configured with addBean should reuse the came InjectionTarget / Producer: > https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextProducer.java#L46 > https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextOsgiProducer.java > > So instead of having to do something like: > Producer customProducer = new CustomProducer(); > abd.addBean().createWith(customProducer::produce).disposeWith(customProducer::dispose); > > I?d like to write: > abd.addBean().producer(customProducer); Another way to look at the point would be to have a way to customise the InjectionTarget and the Producer in the ProcessInjectionTarget and the ProcessProducer lifecycle events. Antonin > On 04 May 2016, at 10:26, Antonin Stefanutti wrote: > > Hi Matej, > > Please find my answer inline. > > Let me add an additional point: > > It is not possible to add @Dependent programmatic bean whose production depends on the injection point. > > There is the BeanConfigurator produceWith(Function, U> callback) method which is a smart way to be able to produce bean instances depending on other bean instances (like producer methods with injection points as parameters), but it cannot depend on the injection point for @Dependent beans. > > So similarly to: > > ObserverMethodConfigurator notifyWith(BiConsumer callback); > > where EventMetadata is kind of the equivalent of InjectionPoint for event > > we could have: > > BeanConfigurator produceWith(Function callback); > > and: > > BeanConfigurator produceWith(BiFunction, InjectionPoint, U> callback); > > Antonin > >> On 03 May 2016, at 16:40, Matej Novotny wrote: >> >> Hello >> >>> - There is a read(AnnotatedType type) API: equivalent API for >>> AnnotatedField and AnnotatedMethod would be useful >> >> Not sure I understand the use case here. You start with AnnotatedTypeConfigurator and you can call, say, methods(). >> That will give you a Set>. So the type of of MethodConfigurator is based on the type of the former configurator. >> Could you support your thoughts by a code snippet showing the usage? > > AfterBeanDiscovery.read(AnnotatedType type) is useful to initialise a BeanConfigurator from an annotated type corresponding to a managed bean. In my use case, I?d need to be able to initialise a BeanConfigurator from an annotated method corresponding to a producer method bean. I can imagine that useful for annotated field as well. > >>> - Having the ability to customise the toString method by providing a >>> Supplier would be useful >> >> This might be a good idea. Where exactly do you need this method? BeanConfigurator or even elsewhere? > > Yes BeanConfigurator. Ideally there should have a toString(Supplier) and a toString(Function>) method as it my case I rely on the bean information. > >>> It?d be useful to be able to reuse some InjectionTarget that are used for >>> discovered beans as well directly instead of having to call instantiate the >>> injection target and call produceWith and destroyWith separately >> >> Not sure I follow you here - produceWith is a way to provide a producer method for your bean (assuming we are talking about Beanconfigurator.produceWith). >> That merely tells CDI how to instantiate the bean if you are to inject it somewhere. You do not really need to handle InjectionTarget here. Same goes for destroyWith. >> I might be missing something though. > > In Camel CDI, there is a mix of discovered beans and programmatic beans to manage Camel context beans. They both should use the same InjectionTarget / Producer. So as the discovered Camel context beans have their InjectionTarget and Producer customised https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L139-L145, the programmatic beans configured with addBean should reuse the came InjectionTarget / Producer: > https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextProducer.java#L46 > https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextOsgiProducer.java > > So instead of having to do something like: > Producer customProducer = new CustomProducer(); > abd.addBean().createWith(customProducer::produce).disposeWith(customProducer::dispose); > > I?d like to write: > abd.addBean().producer(customProducer); > >>> - I found a bit cumbersome to work with addObserverMethod: as the type >>> parameter is not driven by the observedType, generics hiccups come into play >>> with the notifyWith API. In my example, I had to rely on an extra method to >>> have the type parameter provided: >> >> As configurators are not reusable, your approach is imho perfectly right. If you were to add several observers, you need to call AfterBeanDiscovery.addObserver() several times anyway. >> It should be also possible to achieve the same things you have there without additional method (just within the for cycle). So I do not really see the 'generic hiccup' you are talking about. > > The point is that the following code doesn?t compile: > > cdiEventEndpoints.values().stream().forEach(endpoint -> abd.addObserverMethod() > .beanClass(CdiEventComponent.class) > .observedType(endpoint.getType()) > .qualifiers(endpoint.getQualifiers()) > .notifyWith(endpoint::notify); > > I need to write: > > cdiEventEndpoints.values().stream().forEach(endpoint -> addCdiEventObserver(abd, endpoint)); > > private void addCdiEventObserver(AfterBeanDiscovery abd, CdiEventEndpoint endpoint) { > abd.addObserverMethod() > .beanClass(CdiEventComponent.class) > .observedType(endpoint.getType()) > .qualifiers(endpoint.getQualifiers()) > .notifyWith(endpoint::notify); > } > > The code is available here: > > https://github.com/astefanutti/camel-cdi/blob/cdi-2.0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 > > It?s similar to the issue with the example presented in Weld 3.0.0.Alpha16: > > void afterBeanDiscovery(@Observes AfterBeanDiscovery event) { > // Add a new synthetic observer method - no need to use the fluent API > ObserverMethodConfigurator configurator = event.addObserverMethod(); > configurator.observedType(Foo.class); > configurator.reception(Reception.ALWAYS); > configurator.transactionPhase(TransactionPhase.IN_PROGRESS); > configurator.notifyWith((foo) -> System.out.println("Foo observed: " + foo)); > } > > The problem is that the type captured in the lambda expression for ?foo? is Object which is rather useless in most cases, while it should be Foo. > >> Btw please make sure to attend the CDI mtg in the evening. You can voice your needs/ideas there :) >> >> Matej >> >> ----- Original Message ----- >>> From: "Antonin Stefanutti" >>> To: cdi-dev at lists.jboss.org >>> Sent: Tuesday, May 3, 2016 3:48:39 PM >>> Subject: Re: [cdi-dev] New builders API >>> >>> Hi All, >>> >>> Not sure what?s the best form to share my feedback, so here it is :) >>> >>> I?ve tested CDI 2.0.Alpha4 / Weld 3.0.0.Alpha3 and the new "builder API" on >>> the Camel CDI extension and here are the points I?ve had gathered: >>> >>> - There is a read(AnnotatedType type) API: equivalent API for >>> AnnotatedField and AnnotatedMethod would be useful >>> - Having the ability to customise the toString method by providing a >>> Supplier would be useful >>> - There are API (createWith, produceWith, ...) that are basically the >>> decomposition of what an injection target is: in the Camel CDI use case, >>> It?d be useful to be able to reuse some InjectionTarget that are used for >>> discovered beans as well directly instead of having to call instantiate the >>> injection target and call produceWith and destroyWith separately >>> - I found a bit cumbersome to work with addObserverMethod: as the type >>> parameter is not driven by the observedType, generics hiccups come into play >>> with the notifyWith API. In my example, I had to rely on an extra method to >>> have the type parameter provided: >>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 >>> >>> Unfortunately, I haven?t been able to get rid of the boilerplate code (like >>> SyntheticBean [1], SyntheticBeanAttributes [2], SyntheticInjectionTarget >>> [3]) that the new builder API would have permitted to eliminate. Indeed, >>> while the "Metadata configuration API" probably solves the majority / >>> simplest use cases, it does not address the one in Camel CDI (as already >>> illustrated by John and I from different angles). >>> >>> IMO, it?d be worth investigating on an unified Builder and configurator API >>> bringing the best of both worlds. >>> >>> The rewrite of Camel CDI on CDI 2.0 is available here: >>> https://github.com/astefanutti/camel-cdi/commits/cdi-2.0. >>> >>> [1]: >>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBean.java#L34 >>> [2]: >>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBeanAttributes.java#L31 >>> [3]: >>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticInjectionTarget.java#L29 >>> >>> Antonin >>> >>>> On 03 May 2016, at 15:14, Antoine Sabot-Durand >>>> wrote: >>>> >>>> Thanks for all the feedback on the API. >>>> >>>> Before going into detail I wanted to put the accent on the Weld 3.0.Alpha16 >>>> release post[1] which give a good explanation regarding this API. Its the >>>> best starting point to discover this new API IMO. Thanks Martin, Tomas and >>>> Matej for this release. >>>> >>>> @John. The debate Configurator vs Builder is still open. At the moment we >>>> focused on configurator since they are easier to limit to a given >>>> container lifecycle, but having builders to reuse the configuration could >>>> make sense as well. AnnotatedType is a special case since it could make >>>> sense to use it at runtime (to ease creation of an InjectionTarget for >>>> instance, so perhaps it will require a Builder. >>>> If we keep the API in this spirit for the release, it should be better to >>>> talk about Configurator API vs Builder API to avoid confusion for missing >>>> build() methods ;) >>>> >>>> @Antonin the enhancement you propose is very interesting but as Martin said >>>> we could imagine a solution to load an existing bean after decision on the >>>> API (a mute(Bean) method in ABD perhaps). >>>> >>>> For me the goal is to decide if we are on the right path and avoid decision >>>> that will prevent future enhancement. I think having this API perfect and >>>> complete in one PR is almost impossible. So we should validate something >>>> to move on missing features or enhancements. >>>> >>>> Antoine >>>> >>>> [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>>> >>>> Le jeu. 28 avr. 2016 ? 10:43, Martin Kouba a ?crit : >>>> Hi all, >>>> >>>> we've just released Weld 3.0.0.Alpha16. So anyone can start playing with >>>> the API, discover possibilities and find potential issues: >>>> >>>> http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>>> >>>> Any feedback is appreciated! >>>> >>>> Martin >>>> >>>> Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): >>>>> Hi all, >>>>> >>>>> me and Matej, we've already tried to explain some points in cdi/pull/287 >>>>> discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on >>>>> 2.0.Alpha4) later this week so that everyone can start playing with the >>>>> new API. And we'd like to prepare some simple examples to help people >>>>> get started as well. >>>>> >>>>> Martin >>>>> >>>>> >>>>> Dne 23.4.2016 v 12:56 John D. Ament napsal(a): >>>>>> Hey guys >>>>>> >>>>>> Based on the last f2f I was in, I took an action item to look at how >>>>>> applications can leverage the new builder methods/classes from this PR: >>>>>> https://github.com/cdi-spec/cdi/pull/287 >>>>>> >>>>>> To do this, I took some existing OSS CDI extensions and converted parts >>>>>> to use the new APIs instead of the old ones. >>>>>> >>>>>> The results were iffy to be honest. Here's some of the key issues I >>>>>> noticed: >>>>>> >>>>>> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean >>>>>> bean) >>>>>> In the latter, it's clearer to a developer which attributes are required >>>>>> vs optional. Builders typically use sensible defaults. Maybe that was >>>>>> the intention here, but I couldn't really get that sense when converting >>>>>> over. It also wasn't clear what to do when done. I suspect I just >>>>>> leave it, but without some kind of closing "build()" or "done()" method, >>>>>> it becomes ambiguous. >>>>>> >>>>>> - Annotated*Configurator >>>>>> TBH, I have no idea what I was configuring in this one at the first >>>>>> pass. I started with a method. I wanted to replace the method's >>>>>> annotations. It seemed like I could set that up using the configurator, >>>>>> but I ended up having to do setAnnotated at the end anyways, so I'm not >>>>>> sure what the configurator bought me. >>>>>> >>>>>> The one nice thing I saw was the simpler to use lambda functions. Being >>>>>> able to stream through things like annotated method made the code much >>>>>> cleaner. >>>>>> >>>>>> For the open source code, I'll try to get some gists together that show >>>>>> the changes. Maybe there's something I'm missing, so wouldn't mind a >>>>>> second set of eyes on the changes to see. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses the >>>>>> code under the Apache License, Version 2 >>>>>> (http://www.apache.org/licenses/LICENSE-2.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. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code >>> under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.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 mkouba at redhat.com Wed May 4 07:01:39 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 4 May 2016 13:01:39 +0200 Subject: [cdi-dev] New builders API In-Reply-To: <57D40A65-83AD-4FF2-B9DA-278DEF1BC7A8@stefanutti.fr> References: <571DC77E.5000606@redhat.com> <5721CD19.2040603@redhat.com> <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> <1509090947.48315712.1462286411872.JavaMail.zimbra@redhat.com> <5729B649.6040500@redhat.com> <57D40A65-83AD-4FF2-B9DA-278DEF1BC7A8@stefanutti.fr> Message-ID: <5729D693.1010103@redhat.com> Dne 4.5.2016 v 11:57 Antonin Stefanutti napsal(a): > Hi Martin, > >> On 04 May 2016, at 10:43, Martin Kouba wrote: >> >> Dne 4.5.2016 v 10:26 Antonin Stefanutti napsal(a): >>> Hi Matej, >>> >>> Please find my answer inline. >>> >>> Let me add an additional point: >>> >>> It is not possible to add @Dependent programmatic bean whose production depends on the injection point. >>> >>> There is the BeanConfigurator produceWith(Function, U> callback) method which is a smart way to be able to produce bean instances depending on other bean instances (like producer methods with injection points as parameters), but it cannot depend on the injection point for @Dependent beans. >>> >>> So similarly to: >>> >>> ObserverMethodConfigurator notifyWith(BiConsumer callback); >>> >>> where EventMetadata is kind of the equivalent of InjectionPoint for event >>> >>> we could have: >>> >>> BeanConfigurator produceWith(Function callback); >>> >>> and: >>> >>> BeanConfigurator produceWith(BiFunction, InjectionPoint, U> callback); >> >> Sound useful. On the other hand, it's a very specific use case - more or less simulating a producer method returning a dependent bean instance. For other scopes the IP would have to be null/absent. Also this is not possible with the current API either (at least not in a portable way - no IP available during Contextual.create()). > > I?d say it is the equivalent of: > > BeanConfigurator produceWith(Function, U> callback); > > For @Dependent bean that rely on the InjectionPoint metadata. > > The point is that it is very convoluted to customise that kind of bean (producer method that depends on the injection point) in the AfterBeanDiscovery event (given the information is not available at the moment ProcessBeanAttributes is fired). Plus I don?t know of any way to add a programmatic bean that rely on the injection point metadata to create instances. > > In Camel CDI, here is the way it is done for every Camel primitives beans (like Endpoint, ProducerTemplate, ...): > > You have a producer method bean, like: > > @Produces > @Typed(MockEndpoint.class) > // Alternative is dynamically added in CdiCamelExtension > private static MockEndpoint mockEndpointFromMember(InjectionPoint ip, @Any Instance instance, CdiCamelExtension extension) { > String uri = "mock:" + ip.getMember().getName(); > return selectContext(ip, instance, extension).getEndpoint(uri, MockEndpoint.class); > } > > That bean needs to be customised as extra qualifiers need to be added in AfterBeanDiscovery. So the producer method is first vetoed and a new bean is added that way: > > private Bean camelProducerBean(BeanManager manager, AnnotatedMethod am, Set qualifiers) { > return manager.createBean( > new BeanDecorator<>(manager.createBeanAttributes(am), qualifiers), > CdiCamelFactory.class, > manager.getProducerFactory(am, > (Bean) manager.resolve(manager.getBeans(CdiCamelFactory.class)))); > } > > With that API, It could be done with: > > abd.addBean() > .addType(MockEndpoint.class) > .produceWith((instance, ip) -> selectContext(ip, instance, extension) > .getEndpoint("mock:" + ip.getMember().getName(), MockEndpoint.class)); Yes, this looks nice. My point is that users might be confused if they get null/absent IP. Also I'm not sure the "configurator API" should be more powerful than SPI (i.e. Contextual.create()). It's true we allow to simulate producer methods with produceWith() but that's nothing you couldn't do within extension observer methods. Maybe we should address this on the SPI level first? > >>> >>> Antonin >>> >>>> On 03 May 2016, at 16:40, Matej Novotny wrote: >>>> >>>> Hello >>>> >>>>> - There is a read(AnnotatedType type) API: equivalent API for >>>>> AnnotatedField and AnnotatedMethod would be useful >>>> >>>> Not sure I understand the use case here. You start with AnnotatedTypeConfigurator and you can call, say, methods(). >>>> That will give you a Set>. So the type of of MethodConfigurator is based on the type of the former configurator. >>>> Could you support your thoughts by a code snippet showing the usage? >>> >>> AfterBeanDiscovery.read(AnnotatedType type) is useful to initialise a BeanConfigurator from an annotated type corresponding to a managed bean. In my use case, I?d need to be able to initialise a BeanConfigurator from an annotated method corresponding to a producer method bean. I can imagine that useful for annotated field as well. >>> >>>>> - Having the ability to customise the toString method by providing a >>>>> Supplier would be useful >>>> >>>> This might be a good idea. Where exactly do you need this method? BeanConfigurator or even elsewhere? >>> >>> Yes BeanConfigurator. Ideally there should have a toString(Supplier) and a toString(Function>) method as it my case I rely on the bean information. >>> >>>>> It?d be useful to be able to reuse some InjectionTarget that are used for >>>>> discovered beans as well directly instead of having to call instantiate the >>>>> injection target and call produceWith and destroyWith separately >>>> >>>> Not sure I follow you here - produceWith is a way to provide a producer method for your bean (assuming we are talking about Beanconfigurator.produceWith). >>>> That merely tells CDI how to instantiate the bean if you are to inject it somewhere. You do not really need to handle InjectionTarget here. Same goes for destroyWith. >>>> I might be missing something though. >>> >>> In Camel CDI, there is a mix of discovered beans and programmatic beans to manage Camel context beans. They both should use the same InjectionTarget / Producer. So as the discovered Camel context beans have their InjectionTarget and Producer customised https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L139-L145, the programmatic beans configured with addBean should reuse the came InjectionTarget / Producer: >>> https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextProducer.java#L46 >>> https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextOsgiProducer.java >>> >>> So instead of having to do something like: >>> Producer customProducer = new CustomProducer(); >>> abd.addBean().createWith(customProducer::produce).disposeWith(customProducer::dispose); >>> >>> I?d like to write: >>> abd.addBean().producer(customProducer); >>> >>>>> - I found a bit cumbersome to work with addObserverMethod: as the type >>>>> parameter is not driven by the observedType, generics hiccups come into play >>>>> with the notifyWith API. In my example, I had to rely on an extra method to >>>>> have the type parameter provided: >>>> >>>> As configurators are not reusable, your approach is imho perfectly right. If you were to add several observers, you need to call AfterBeanDiscovery.addObserver() several times anyway. >>>> It should be also possible to achieve the same things you have there without additional method (just within the for cycle). So I do not really see the 'generic hiccup' you are talking about. >>> >>> The point is that the following code doesn?t compile: >>> >>> cdiEventEndpoints.values().stream().forEach(endpoint -> abd.addObserverMethod() >>> .beanClass(CdiEventComponent.class) >>> .observedType(endpoint.getType()) >>> .qualifiers(endpoint.getQualifiers()) >>> .notifyWith(endpoint::notify); >>> >>> I need to write: >>> >>> cdiEventEndpoints.values().stream().forEach(endpoint -> addCdiEventObserver(abd, endpoint)); >>> >>> private void addCdiEventObserver(AfterBeanDiscovery abd, CdiEventEndpoint endpoint) { >>> abd.addObserverMethod() >>> .beanClass(CdiEventComponent.class) >>> .observedType(endpoint.getType()) >>> .qualifiers(endpoint.getQualifiers()) >>> .notifyWith(endpoint::notify); >>> } >>> >>> The code is available here: >>> >>> https://github.com/astefanutti/camel-cdi/blob/cdi-2.0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 >>> >>> It?s similar to the issue with the example presented in Weld 3.0.0.Alpha16: >>> >>> void afterBeanDiscovery(@Observes AfterBeanDiscovery event) { >>> // Add a new synthetic observer method - no need to use the fluent API >>> ObserverMethodConfigurator configurator = event.addObserverMethod(); >>> configurator.observedType(Foo.class); >>> configurator.reception(Reception.ALWAYS); >>> configurator.transactionPhase(TransactionPhase.IN_PROGRESS); >>> configurator.notifyWith((foo) -> System.out.println("Foo observed: " + foo)); >>> } >>> >>> The problem is that the type captured in the lambda expression for ?foo? is Object which is rather useless in most cases, while it should be Foo. >>> >>>> Btw please make sure to attend the CDI mtg in the evening. You can voice your needs/ideas there :) >>>> >>>> Matej >>>> >>>> ----- Original Message ----- >>>>> From: "Antonin Stefanutti" >>>>> To: cdi-dev at lists.jboss.org >>>>> Sent: Tuesday, May 3, 2016 3:48:39 PM >>>>> Subject: Re: [cdi-dev] New builders API >>>>> >>>>> Hi All, >>>>> >>>>> Not sure what?s the best form to share my feedback, so here it is :) >>>>> >>>>> I?ve tested CDI 2.0.Alpha4 / Weld 3.0.0.Alpha3 and the new "builder API" on >>>>> the Camel CDI extension and here are the points I?ve had gathered: >>>>> >>>>> - There is a read(AnnotatedType type) API: equivalent API for >>>>> AnnotatedField and AnnotatedMethod would be useful >>>>> - Having the ability to customise the toString method by providing a >>>>> Supplier would be useful >>>>> - There are API (createWith, produceWith, ...) that are basically the >>>>> decomposition of what an injection target is: in the Camel CDI use case, >>>>> It?d be useful to be able to reuse some InjectionTarget that are used for >>>>> discovered beans as well directly instead of having to call instantiate the >>>>> injection target and call produceWith and destroyWith separately >>>>> - I found a bit cumbersome to work with addObserverMethod: as the type >>>>> parameter is not driven by the observedType, generics hiccups come into play >>>>> with the notifyWith API. In my example, I had to rely on an extra method to >>>>> have the type parameter provided: >>>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 >>>>> >>>>> Unfortunately, I haven?t been able to get rid of the boilerplate code (like >>>>> SyntheticBean [1], SyntheticBeanAttributes [2], SyntheticInjectionTarget >>>>> [3]) that the new builder API would have permitted to eliminate. Indeed, >>>>> while the "Metadata configuration API" probably solves the majority / >>>>> simplest use cases, it does not address the one in Camel CDI (as already >>>>> illustrated by John and I from different angles). >>>>> >>>>> IMO, it?d be worth investigating on an unified Builder and configurator API >>>>> bringing the best of both worlds. >>>>> >>>>> The rewrite of Camel CDI on CDI 2.0 is available here: >>>>> https://github.com/astefanutti/camel-cdi/commits/cdi-2.0. >>>>> >>>>> [1]: >>>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBean.java#L34 >>>>> [2]: >>>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBeanAttributes.java#L31 >>>>> [3]: >>>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticInjectionTarget.java#L29 >>>>> >>>>> Antonin >>>>> >>>>>> On 03 May 2016, at 15:14, Antoine Sabot-Durand >>>>>> wrote: >>>>>> >>>>>> Thanks for all the feedback on the API. >>>>>> >>>>>> Before going into detail I wanted to put the accent on the Weld 3.0.Alpha16 >>>>>> release post[1] which give a good explanation regarding this API. Its the >>>>>> best starting point to discover this new API IMO. Thanks Martin, Tomas and >>>>>> Matej for this release. >>>>>> >>>>>> @John. The debate Configurator vs Builder is still open. At the moment we >>>>>> focused on configurator since they are easier to limit to a given >>>>>> container lifecycle, but having builders to reuse the configuration could >>>>>> make sense as well. AnnotatedType is a special case since it could make >>>>>> sense to use it at runtime (to ease creation of an InjectionTarget for >>>>>> instance, so perhaps it will require a Builder. >>>>>> If we keep the API in this spirit for the release, it should be better to >>>>>> talk about Configurator API vs Builder API to avoid confusion for missing >>>>>> build() methods ;) >>>>>> >>>>>> @Antonin the enhancement you propose is very interesting but as Martin said >>>>>> we could imagine a solution to load an existing bean after decision on the >>>>>> API (a mute(Bean) method in ABD perhaps). >>>>>> >>>>>> For me the goal is to decide if we are on the right path and avoid decision >>>>>> that will prevent future enhancement. I think having this API perfect and >>>>>> complete in one PR is almost impossible. So we should validate something >>>>>> to move on missing features or enhancements. >>>>>> >>>>>> Antoine >>>>>> >>>>>> [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>>>>> >>>>>> Le jeu. 28 avr. 2016 ? 10:43, Martin Kouba a ?crit : >>>>>> Hi all, >>>>>> >>>>>> we've just released Weld 3.0.0.Alpha16. So anyone can start playing with >>>>>> the API, discover possibilities and find potential issues: >>>>>> >>>>>> http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>>>>> >>>>>> Any feedback is appreciated! >>>>>> >>>>>> Martin >>>>>> >>>>>> Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): >>>>>>> Hi all, >>>>>>> >>>>>>> me and Matej, we've already tried to explain some points in cdi/pull/287 >>>>>>> discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on >>>>>>> 2.0.Alpha4) later this week so that everyone can start playing with the >>>>>>> new API. And we'd like to prepare some simple examples to help people >>>>>>> get started as well. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> >>>>>>> Dne 23.4.2016 v 12:56 John D. Ament napsal(a): >>>>>>>> Hey guys >>>>>>>> >>>>>>>> Based on the last f2f I was in, I took an action item to look at how >>>>>>>> applications can leverage the new builder methods/classes from this PR: >>>>>>>> https://github.com/cdi-spec/cdi/pull/287 >>>>>>>> >>>>>>>> To do this, I took some existing OSS CDI extensions and converted parts >>>>>>>> to use the new APIs instead of the old ones. >>>>>>>> >>>>>>>> The results were iffy to be honest. Here's some of the key issues I >>>>>>>> noticed: >>>>>>>> >>>>>>>> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean >>>>>>>> bean) >>>>>>>> In the latter, it's clearer to a developer which attributes are required >>>>>>>> vs optional. Builders typically use sensible defaults. Maybe that was >>>>>>>> the intention here, but I couldn't really get that sense when converting >>>>>>>> over. It also wasn't clear what to do when done. I suspect I just >>>>>>>> leave it, but without some kind of closing "build()" or "done()" method, >>>>>>>> it becomes ambiguous. >>>>>>>> >>>>>>>> - Annotated*Configurator >>>>>>>> TBH, I have no idea what I was configuring in this one at the first >>>>>>>> pass. I started with a method. I wanted to replace the method's >>>>>>>> annotations. It seemed like I could set that up using the configurator, >>>>>>>> but I ended up having to do setAnnotated at the end anyways, so I'm not >>>>>>>> sure what the configurator bought me. >>>>>>>> >>>>>>>> The one nice thing I saw was the simpler to use lambda functions. Being >>>>>>>> able to stream through things like annotated method made the code much >>>>>>>> cleaner. >>>>>>>> >>>>>>>> For the open source code, I'll try to get some gists together that show >>>>>>>> the changes. Maybe there's something I'm missing, so wouldn't mind a >>>>>>>> second set of eyes on the changes to see. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>>>> Note that for all code provided on this list, the provider licenses the >>>>>>>> code under the Apache License, Version 2 >>>>>>>> (http://www.apache.org/licenses/LICENSE-2.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. >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code >>>>> under the Apache License, Version 2 >>>>> (http://www.apache.org/licenses/LICENSE-2.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 > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Wed May 4 08:07:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 4 May 2016 08:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200875#comment-13200875 ] Martin Kouba commented on CDI-420: ---------------------------------- So you would basically allow to "tweak" one of the existing bean discovery mode. If so I think we should tweak the {{annotated}} mode. Having a separate tag/attribute is not very nice (it's rather confusing) but it seems better than adding a new bean discovery mode which is almost identical to {{annotated}}. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > 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.4.11#64026) From antonin at stefanutti.fr Wed May 4 08:08:38 2016 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Wed, 4 May 2016 12:08:38 +0000 Subject: [cdi-dev] New builders API In-Reply-To: <5729D693.1010103@redhat.com> References: <571DC77E.5000606@redhat.com> <5721CD19.2040603@redhat.com> <7F6FF246-EE10-4524-9592-315555634C79@stefanutti.fr> <1509090947.48315712.1462286411872.JavaMail.zimbra@redhat.com> <5729B649.6040500@redhat.com> <57D40A65-83AD-4FF2-B9DA-278DEF1BC7A8@stefanutti.fr> <5729D693.1010103@redhat.com> Message-ID: > On 04 May 2016, at 13:01, Martin Kouba wrote: > > > Dne 4.5.2016 v 11:57 Antonin Stefanutti napsal(a): >> Hi Martin, >> >>> On 04 May 2016, at 10:43, Martin Kouba wrote: >>> >>> Dne 4.5.2016 v 10:26 Antonin Stefanutti napsal(a): >>>> Hi Matej, >>>> >>>> Please find my answer inline. >>>> >>>> Let me add an additional point: >>>> >>>> It is not possible to add @Dependent programmatic bean whose production depends on the injection point. >>>> >>>> There is the BeanConfigurator produceWith(Function, U> callback) method which is a smart way to be able to produce bean instances depending on other bean instances (like producer methods with injection points as parameters), but it cannot depend on the injection point for @Dependent beans. >>>> >>>> So similarly to: >>>> >>>> ObserverMethodConfigurator notifyWith(BiConsumer callback); >>>> >>>> where EventMetadata is kind of the equivalent of InjectionPoint for event >>>> >>>> we could have: >>>> >>>> BeanConfigurator produceWith(Function callback); >>>> >>>> and: >>>> >>>> BeanConfigurator produceWith(BiFunction, InjectionPoint, U> callback); >>> >>> Sound useful. On the other hand, it's a very specific use case - more or less simulating a producer method returning a dependent bean instance. For other scopes the IP would have to be null/absent. Also this is not possible with the current API either (at least not in a portable way - no IP available during Contextual.create()). >> >> I?d say it is the equivalent of: >> >> BeanConfigurator produceWith(Function, U> callback); >> >> For @Dependent bean that rely on the InjectionPoint metadata. >> >> The point is that it is very convoluted to customise that kind of bean (producer method that depends on the injection point) in the AfterBeanDiscovery event (given the information is not available at the moment ProcessBeanAttributes is fired). Plus I don?t know of any way to add a programmatic bean that rely on the injection point metadata to create instances. >> >> In Camel CDI, here is the way it is done for every Camel primitives beans (like Endpoint, ProducerTemplate, ...): >> >> You have a producer method bean, like: >> >> @Produces >> @Typed(MockEndpoint.class) >> // Alternative is dynamically added in CdiCamelExtension >> private static MockEndpoint mockEndpointFromMember(InjectionPoint ip, @Any Instance instance, CdiCamelExtension extension) { >> String uri = "mock:" + ip.getMember().getName(); >> return selectContext(ip, instance, extension).getEndpoint(uri, MockEndpoint.class); >> } >> >> That bean needs to be customised as extra qualifiers need to be added in AfterBeanDiscovery. So the producer method is first vetoed and a new bean is added that way: >> >> private Bean camelProducerBean(BeanManager manager, AnnotatedMethod am, Set qualifiers) { >> return manager.createBean( >> new BeanDecorator<>(manager.createBeanAttributes(am), qualifiers), >> CdiCamelFactory.class, >> manager.getProducerFactory(am, >> (Bean) manager.resolve(manager.getBeans(CdiCamelFactory.class)))); >> } >> >> With that API, It could be done with: >> >> abd.addBean() >> .addType(MockEndpoint.class) >> .produceWith((instance, ip) -> selectContext(ip, instance, extension) >> .getEndpoint("mock:" + ip.getMember().getName(), MockEndpoint.class)); > > Yes, this looks nice. My point is that users might be confused if they get null/absent IP. I?d rather have the container raise a DefinitionException in that case. > Also I'm not sure the "configurator API" should be more powerful than SPI (i.e. Contextual.create()). It's true we allow to simulate producer methods with produceWith() but that's nothing you couldn't do within extension observer methods. > > Maybe we should address this on the SPI level first? Indeed, the gap at the SPI level should ideally be addressed as well. >>>> Antonin >>>> >>>>> On 03 May 2016, at 16:40, Matej Novotny wrote: >>>>> >>>>> Hello >>>>> >>>>>> - There is a read(AnnotatedType type) API: equivalent API for >>>>>> AnnotatedField and AnnotatedMethod would be useful >>>>> >>>>> Not sure I understand the use case here. You start with AnnotatedTypeConfigurator and you can call, say, methods(). >>>>> That will give you a Set>. So the type of of MethodConfigurator is based on the type of the former configurator. >>>>> Could you support your thoughts by a code snippet showing the usage? >>>> >>>> AfterBeanDiscovery.read(AnnotatedType type) is useful to initialise a BeanConfigurator from an annotated type corresponding to a managed bean. In my use case, I?d need to be able to initialise a BeanConfigurator from an annotated method corresponding to a producer method bean. I can imagine that useful for annotated field as well. >>>> >>>>>> - Having the ability to customise the toString method by providing a >>>>>> Supplier would be useful >>>>> >>>>> This might be a good idea. Where exactly do you need this method? BeanConfigurator or even elsewhere? >>>> >>>> Yes BeanConfigurator. Ideally there should have a toString(Supplier) and a toString(Function>) method as it my case I rely on the bean information. >>>> >>>>>> It?d be useful to be able to reuse some InjectionTarget that are used for >>>>>> discovered beans as well directly instead of having to call instantiate the >>>>>> injection target and call produceWith and destroyWith separately >>>>> >>>>> Not sure I follow you here - produceWith is a way to provide a producer method for your bean (assuming we are talking about Beanconfigurator.produceWith). >>>>> That merely tells CDI how to instantiate the bean if you are to inject it somewhere. You do not really need to handle InjectionTarget here. Same goes for destroyWith. >>>>> I might be missing something though. >>>> >>>> In Camel CDI, there is a mix of discovered beans and programmatic beans to manage Camel context beans. They both should use the same InjectionTarget / Producer. So as the discovered Camel context beans have their InjectionTarget and Producer customised https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L139-L145, the programmatic beans configured with addBean should reuse the came InjectionTarget / Producer: >>>> https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextProducer.java#L46 >>>> https://github.com/astefanutti/camel-cdi/blob/ea8b111d285ccb0cd18e08f45c9205ed852b2814/impl/src/main/java/org/apache/camel/cdi/CamelContextOsgiProducer.java >>>> >>>> So instead of having to do something like: >>>> Producer customProducer = new CustomProducer(); >>>> abd.addBean().createWith(customProducer::produce).disposeWith(customProducer::dispose); >>>> >>>> I?d like to write: >>>> abd.addBean().producer(customProducer); >>>> >>>>>> - I found a bit cumbersome to work with addObserverMethod: as the type >>>>>> parameter is not driven by the observedType, generics hiccups come into play >>>>>> with the notifyWith API. In my example, I had to rely on an extra method to >>>>>> have the type parameter provided: >>>>> >>>>> As configurators are not reusable, your approach is imho perfectly right. If you were to add several observers, you need to call AfterBeanDiscovery.addObserver() several times anyway. >>>>> It should be also possible to achieve the same things you have there without additional method (just within the for cycle). So I do not really see the 'generic hiccup' you are talking about. >>>> >>>> The point is that the following code doesn?t compile: >>>> >>>> cdiEventEndpoints.values().stream().forEach(endpoint -> abd.addObserverMethod() >>>> .beanClass(CdiEventComponent.class) >>>> .observedType(endpoint.getType()) >>>> .qualifiers(endpoint.getQualifiers()) >>>> .notifyWith(endpoint::notify); >>>> >>>> I need to write: >>>> >>>> cdiEventEndpoints.values().stream().forEach(endpoint -> addCdiEventObserver(abd, endpoint)); >>>> >>>> private void addCdiEventObserver(AfterBeanDiscovery abd, CdiEventEndpoint endpoint) { >>>> abd.addObserverMethod() >>>> .beanClass(CdiEventComponent.class) >>>> .observedType(endpoint.getType()) >>>> .qualifiers(endpoint.getQualifiers()) >>>> .notifyWith(endpoint::notify); >>>> } >>>> >>>> The code is available here: >>>> >>>> https://github.com/astefanutti/camel-cdi/blob/cdi-2.0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 >>>> >>>> It?s similar to the issue with the example presented in Weld 3.0.0.Alpha16: >>>> >>>> void afterBeanDiscovery(@Observes AfterBeanDiscovery event) { >>>> // Add a new synthetic observer method - no need to use the fluent API >>>> ObserverMethodConfigurator configurator = event.addObserverMethod(); >>>> configurator.observedType(Foo.class); >>>> configurator.reception(Reception.ALWAYS); >>>> configurator.transactionPhase(TransactionPhase.IN_PROGRESS); >>>> configurator.notifyWith((foo) -> System.out.println("Foo observed: " + foo)); >>>> } >>>> >>>> The problem is that the type captured in the lambda expression for ?foo? is Object which is rather useless in most cases, while it should be Foo. >>>> >>>>> Btw please make sure to attend the CDI mtg in the evening. You can voice your needs/ideas there :) >>>>> >>>>> Matej >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Antonin Stefanutti" >>>>>> To: cdi-dev at lists.jboss.org >>>>>> Sent: Tuesday, May 3, 2016 3:48:39 PM >>>>>> Subject: Re: [cdi-dev] New builders API >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Not sure what?s the best form to share my feedback, so here it is :) >>>>>> >>>>>> I?ve tested CDI 2.0.Alpha4 / Weld 3.0.0.Alpha3 and the new "builder API" on >>>>>> the Camel CDI extension and here are the points I?ve had gathered: >>>>>> >>>>>> - There is a read(AnnotatedType type) API: equivalent API for >>>>>> AnnotatedField and AnnotatedMethod would be useful >>>>>> - Having the ability to customise the toString method by providing a >>>>>> Supplier would be useful >>>>>> - There are API (createWith, produceWith, ...) that are basically the >>>>>> decomposition of what an injection target is: in the Camel CDI use case, >>>>>> It?d be useful to be able to reuse some InjectionTarget that are used for >>>>>> discovered beans as well directly instead of having to call instantiate the >>>>>> injection target and call produceWith and destroyWith separately >>>>>> - I found a bit cumbersome to work with addObserverMethod: as the type >>>>>> parameter is not driven by the observedType, generics hiccups come into play >>>>>> with the notifyWith API. In my example, I had to rely on an extra method to >>>>>> have the type parameter provided: >>>>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L263-L271 >>>>>> >>>>>> Unfortunately, I haven?t been able to get rid of the boilerplate code (like >>>>>> SyntheticBean [1], SyntheticBeanAttributes [2], SyntheticInjectionTarget >>>>>> [3]) that the new builder API would have permitted to eliminate. Indeed, >>>>>> while the "Metadata configuration API" probably solves the majority / >>>>>> simplest use cases, it does not address the one in Camel CDI (as already >>>>>> illustrated by John and I from different angles). >>>>>> >>>>>> IMO, it?d be worth investigating on an unified Builder and configurator API >>>>>> bringing the best of both worlds. >>>>>> >>>>>> The rewrite of Camel CDI on CDI 2.0 is available here: >>>>>> https://github.com/astefanutti/camel-cdi/commits/cdi-2.0. >>>>>> >>>>>> [1]: >>>>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBean.java#L34 >>>>>> [2]: >>>>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticBeanAttributes.java#L31 >>>>>> [3]: >>>>>> https://github.com/astefanutti/camel-cdi/blob/310ac823376d086c2c3a9a1b2dabda4be93d04f0/impl/src/main/java/org/apache/camel/cdi/SyntheticInjectionTarget.java#L29 >>>>>> >>>>>> Antonin >>>>>> >>>>>>> On 03 May 2016, at 15:14, Antoine Sabot-Durand >>>>>>> wrote: >>>>>>> >>>>>>> Thanks for all the feedback on the API. >>>>>>> >>>>>>> Before going into detail I wanted to put the accent on the Weld 3.0.Alpha16 >>>>>>> release post[1] which give a good explanation regarding this API. Its the >>>>>>> best starting point to discover this new API IMO. Thanks Martin, Tomas and >>>>>>> Matej for this release. >>>>>>> >>>>>>> @John. The debate Configurator vs Builder is still open. At the moment we >>>>>>> focused on configurator since they are easier to limit to a given >>>>>>> container lifecycle, but having builders to reuse the configuration could >>>>>>> make sense as well. AnnotatedType is a special case since it could make >>>>>>> sense to use it at runtime (to ease creation of an InjectionTarget for >>>>>>> instance, so perhaps it will require a Builder. >>>>>>> If we keep the API in this spirit for the release, it should be better to >>>>>>> talk about Configurator API vs Builder API to avoid confusion for missing >>>>>>> build() methods ;) >>>>>>> >>>>>>> @Antonin the enhancement you propose is very interesting but as Martin said >>>>>>> we could imagine a solution to load an existing bean after decision on the >>>>>>> API (a mute(Bean) method in ABD perhaps). >>>>>>> >>>>>>> For me the goal is to decide if we are on the right path and avoid decision >>>>>>> that will prevent future enhancement. I think having this API perfect and >>>>>>> complete in one PR is almost impossible. So we should validate something >>>>>>> to move on missing features or enhancements. >>>>>>> >>>>>>> Antoine >>>>>>> >>>>>>> [1] http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>>>>>> >>>>>>> Le jeu. 28 avr. 2016 ? 10:43, Martin Kouba a ?crit : >>>>>>> Hi all, >>>>>>> >>>>>>> we've just released Weld 3.0.0.Alpha16. So anyone can start playing with >>>>>>> the API, discover possibilities and find potential issues: >>>>>>> >>>>>>> http://weld.cdi-spec.org/news/2016/04/28/weld-300Alpha16/ >>>>>>> >>>>>>> Any feedback is appreciated! >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> Dne 25.4.2016 v 09:30 Martin Kouba napsal(a): >>>>>>>> Hi all, >>>>>>>> >>>>>>>> me and Matej, we've already tried to explain some points in cdi/pull/287 >>>>>>>> discussion. Anyway, we're going to release Weld 3.0.0.Alpha16 (base on >>>>>>>> 2.0.Alpha4) later this week so that everyone can start playing with the >>>>>>>> new API. And we'd like to prepare some simple examples to help people >>>>>>>> get started as well. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>> >>>>>>>> Dne 23.4.2016 v 12:56 John D. Ament napsal(a): >>>>>>>>> Hey guys >>>>>>>>> >>>>>>>>> Based on the last f2f I was in, I took an action item to look at how >>>>>>>>> applications can leverage the new builder methods/classes from this PR: >>>>>>>>> https://github.com/cdi-spec/cdi/pull/287 >>>>>>>>> >>>>>>>>> To do this, I took some existing OSS CDI extensions and converted parts >>>>>>>>> to use the new APIs instead of the old ones. >>>>>>>>> >>>>>>>>> The results were iffy to be honest. Here's some of the key issues I >>>>>>>>> noticed: >>>>>>>>> >>>>>>>>> - AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean >>>>>>>>> bean) >>>>>>>>> In the latter, it's clearer to a developer which attributes are required >>>>>>>>> vs optional. Builders typically use sensible defaults. Maybe that was >>>>>>>>> the intention here, but I couldn't really get that sense when converting >>>>>>>>> over. It also wasn't clear what to do when done. I suspect I just >>>>>>>>> leave it, but without some kind of closing "build()" or "done()" method, >>>>>>>>> it becomes ambiguous. >>>>>>>>> >>>>>>>>> - Annotated*Configurator >>>>>>>>> TBH, I have no idea what I was configuring in this one at the first >>>>>>>>> pass. I started with a method. I wanted to replace the method's >>>>>>>>> annotations. It seemed like I could set that up using the configurator, >>>>>>>>> but I ended up having to do setAnnotated at the end anyways, so I'm not >>>>>>>>> sure what the configurator bought me. >>>>>>>>> >>>>>>>>> The one nice thing I saw was the simpler to use lambda functions. Being >>>>>>>>> able to stream through things like annotated method made the code much >>>>>>>>> cleaner. >>>>>>>>> >>>>>>>>> For the open source code, I'll try to get some gists together that show >>>>>>>>> the changes. Maybe there's something I'm missing, so wouldn't mind a >>>>>>>>> second set of eyes on the changes to see. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> cdi-dev mailing list >>>>>>>>> cdi-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>> >>>>>>>>> Note that for all code provided on this list, the provider licenses the >>>>>>>>> code under the Apache License, Version 2 >>>>>>>>> (http://www.apache.org/licenses/LICENSE-2.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. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses the code >>>>>> under the Apache License, Version 2 >>>>>> (http://www.apache.org/licenses/LICENSE-2.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 >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic From john.d.ament at gmail.com Wed May 4 08:08:57 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 May 2016 12:08:57 +0000 Subject: [cdi-dev] CDI-508 - Which java classes can be managed beans In-Reply-To: <1475456860.571975.1462345943966.JavaMail.zimbra@redhat.com> References: <572992DC.8050305@redhat.com> <1475456860.571975.1462345943966.JavaMail.zimbra@redhat.com> Message-ID: Just to confirm (because negatives always make things harder to digest) An abstract class annotated Decorator is a managed bean - correct? Because of this line: It is a non-abstract class, or is annotated `@Decorator`. John On Wed, May 4, 2016 at 3:12 AM Tomas Remes wrote: > > Hi, > > Yes this proposal is sufficient and reads better. I can change my PR if > there aren't any further objections? > > Thank's > Tom > > ----- Original Message ----- > From: "Martin Kouba" > To: "John D. Ament" , cdi-dev at lists.jboss.org > Sent: Wednesday, May 4, 2016 8:12:44 AM > Subject: Re: [cdi-dev] CDI-508 - Which java classes can be managed beans > > Hi all, > > given that local and anonymous classes are special kinds of inner > classes, we could also simply change the sentence to: > > "It is not an inner class." > > Anyway, I think the change of the first sentence is much more important, > i.e. removing the "top-level"... > > Maybe we should also remove "top-level" from the next sentence: > "It is a top-level non-abstract class, or is annotated `@Decorator`." > > So that we would end up with: > > A Java class is a managed bean if it meets all of the following conditions: > * It is not an inner class. > * It is a non-abstract class, or is annotated `@Decorator`. > * It does not implement `javax.enterprise.inject.spi.Extension`. > * It is not annotated `@Vetoed` or in a package annotated `@Vetoed`. > * It has an appropriate constructor - either: > > What do you think? > > Martin > > > Dne 4.5.2016 v 02:32 John D. Ament napsal(a): > > All, > > > > I think I had an action item to get this clarified, not 100% sure, but > > let me give this a shot. > > > > Tomas raised a PR for CDI-508 to clarify which classes are meant to be > > managed beans. You can find that PR here: > > https://github.com/cdi-spec/cdi/pull/282/ > > > > The line that doesn't sound right to me in the change is to go from: > > > > It is not a non-static inner class. > > > > to > > > > It is not a non-static nested class. > > > > I'll use the java programming language tutorial as a point of reference, > > you can read the page I'll refer to here: > > https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html > > > > Basically, non-static nested classes are AKA inner classes. The term > > "non-static inner class" shouldn't exist, and that means the original > > text doesn't make sense, and should probably be inferred as "It is not > > an inner class" > > > > From reading this part of the spec, it becomes unreadable due to the > > double negative (probably why the aka exists). My proposal was to > > change the line to instead read (in a positive way) "It is a static > > nested class" but I can also understand if we want to do this in an > > exclusion pattern rather than an inclusion pattern. > > > > Thoughts? > > > > John > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160504/53473028/attachment-0001.html From issues at jboss.org Wed May 4 08:10:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 4 May 2016 08:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200877#comment-13200877 ] Matej Novotny commented on CDI-420: ----------------------------------- I agree with adding either a tag or an attribute. It is IMHO not worth a whole new mode as it is pretty much similar to "annotated" one. Which leads me to a question. [~struberg] did you really mean to add a sample with {{ add a bean-discovery-mode 'scoped' > ---------------------------------- > > 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.4.11#64026) From issues at jboss.org Wed May 4 08:11:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 4 May 2016 08:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-457) Clarify how to properly create and destroy dependent instances In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200878#comment-13200878 ] John Ament commented on CDI-457: -------------------------------- [~mkouba] lets discuss via email, I'm fine if we want to close this out and start from scratch. > Clarify how to properly create and destroy dependent instances > -------------------------------------------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Using @TransientReference today for class definitions allows you to mark it as dependent. > We should allow arbitrary producers to include transient references. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Wed May 4 08:11:24 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 4 May 2016 14:11:24 +0200 Subject: [cdi-dev] CDI-508 - Which java classes can be managed beans In-Reply-To: References: <572992DC.8050305@redhat.com> <1475456860.571975.1462345943966.JavaMail.zimbra@redhat.com> Message-ID: <5729E6EC.3080705@redhat.com> Dne 4.5.2016 v 14:08 John D. Ament napsal(a): > Just to confirm (because negatives always make things harder to digest) > > An abstract class annotated Decorator is a managed bean - correct? Yes. > > Because of this line: It is a non-abstract class, or is annotated > `@Decorator`. It was previously: "It is a concrete class, or is annotated @Decorator." But I believe the JLS does not define a "concrete" class... correct me if I'm wrong. > > John > > On Wed, May 4, 2016 at 3:12 AM Tomas Remes > wrote: > > > Hi, > > Yes this proposal is sufficient and reads better. I can change my PR > if there aren't any further objections? > > Thank's > Tom > > ----- Original Message ----- > From: "Martin Kouba" > > To: "John D. Ament" >, cdi-dev at lists.jboss.org > > Sent: Wednesday, May 4, 2016 8:12:44 AM > Subject: Re: [cdi-dev] CDI-508 - Which java classes can be managed beans > > Hi all, > > given that local and anonymous classes are special kinds of inner > classes, we could also simply change the sentence to: > > "It is not an inner class." > > Anyway, I think the change of the first sentence is much more important, > i.e. removing the "top-level"... > > Maybe we should also remove "top-level" from the next sentence: > "It is a top-level non-abstract class, or is annotated `@Decorator`." > > So that we would end up with: > > A Java class is a managed bean if it meets all of the following > conditions: > * It is not an inner class. > * It is a non-abstract class, or is annotated `@Decorator`. > * It does not implement `javax.enterprise.inject.spi.Extension`. > * It is not annotated `@Vetoed` or in a package annotated `@Vetoed`. > * It has an appropriate constructor - either: > > What do you think? > > Martin > > > Dne 4.5.2016 v 02:32 John D. Ament napsal(a): > > All, > > > > I think I had an action item to get this clarified, not 100% > sure, but > > let me give this a shot. > > > > Tomas raised a PR for CDI-508 to clarify which classes are meant > to be > > managed beans. You can find that PR here: > > https://github.com/cdi-spec/cdi/pull/282/ > > > > The line that doesn't sound right to me in the change is to go from: > > > > It is not a non-static inner class. > > > > to > > > > It is not a non-static nested class. > > > > I'll use the java programming language tutorial as a point of > reference, > > you can read the page I'll refer to here: > > https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html > > > > Basically, non-static nested classes are AKA inner classes. The term > > "non-static inner class" shouldn't exist, and that means the original > > text doesn't make sense, and should probably be inferred as "It > is not > > an inner class" > > > > From reading this part of the spec, it becomes unreadable due to the > > double negative (probably why the aka exists). My proposal was to > > change the line to instead read (in a positive way) "It is a static > > nested class" but I can also understand if we want to do this in an > > exclusion pattern rather than an inclusion pattern. > > > > Thoughts? > > > > John > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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. > > > -- Martin Kouba Software Engineer Red Hat, Czech Republic From john.d.ament at gmail.com Wed May 4 08:16:03 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 May 2016 12:16:03 +0000 Subject: [cdi-dev] CDI-508 - Which java classes can be managed beans In-Reply-To: <5729E6EC.3080705@redhat.com> References: <572992DC.8050305@redhat.com> <1475456860.571975.1462345943966.JavaMail.zimbra@redhat.com> <5729E6EC.3080705@redhat.com> Message-ID: Then I'm +1 on this change as well. And no, I don't believe concrete class is defined. Granted this is Java 8's JLS: https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html John On Wed, May 4, 2016 at 8:11 AM Martin Kouba wrote: > Dne 4.5.2016 v 14:08 John D. Ament napsal(a): > > Just to confirm (because negatives always make things harder to digest) > > > > An abstract class annotated Decorator is a managed bean - correct? > > Yes. > > > > > Because of this line: It is a non-abstract class, or is annotated > > `@Decorator`. > > It was previously: > "It is a concrete class, or is annotated @Decorator." > > But I believe the JLS does not define a "concrete" class... correct me > if I'm wrong. > > > > > John > > > > On Wed, May 4, 2016 at 3:12 AM Tomas Remes > > wrote: > > > > > > Hi, > > > > Yes this proposal is sufficient and reads better. I can change my PR > > if there aren't any further objections? > > > > Thank's > > Tom > > > > ----- Original Message ----- > > From: "Martin Kouba" > > > To: "John D. Ament" > >, cdi-dev at lists.jboss.org > > > > Sent: Wednesday, May 4, 2016 8:12:44 AM > > Subject: Re: [cdi-dev] CDI-508 - Which java classes can be managed > beans > > > > Hi all, > > > > given that local and anonymous classes are special kinds of inner > > classes, we could also simply change the sentence to: > > > > "It is not an inner class." > > > > Anyway, I think the change of the first sentence is much more > important, > > i.e. removing the "top-level"... > > > > Maybe we should also remove "top-level" from the next sentence: > > "It is a top-level non-abstract class, or is annotated `@Decorator`." > > > > So that we would end up with: > > > > A Java class is a managed bean if it meets all of the following > > conditions: > > * It is not an inner class. > > * It is a non-abstract class, or is annotated `@Decorator`. > > * It does not implement `javax.enterprise.inject.spi.Extension`. > > * It is not annotated `@Vetoed` or in a package annotated `@Vetoed`. > > * It has an appropriate constructor - either: > > > > What do you think? > > > > Martin > > > > > > Dne 4.5.2016 v 02:32 John D. Ament napsal(a): > > > All, > > > > > > I think I had an action item to get this clarified, not 100% > > sure, but > > > let me give this a shot. > > > > > > Tomas raised a PR for CDI-508 to clarify which classes are meant > > to be > > > managed beans. You can find that PR here: > > > https://github.com/cdi-spec/cdi/pull/282/ > > > > > > The line that doesn't sound right to me in the change is to go > from: > > > > > > It is not a non-static inner class. > > > > > > to > > > > > > It is not a non-static nested class. > > > > > > I'll use the java programming language tutorial as a point of > > reference, > > > you can read the page I'll refer to here: > > > https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html > > > > > > Basically, non-static nested classes are AKA inner classes. The > term > > > "non-static inner class" shouldn't exist, and that means the > original > > > text doesn't make sense, and should probably be inferred as "It > > is not > > > an inner class" > > > > > > From reading this part of the spec, it becomes unreadable due to > the > > > double negative (probably why the aka exists). My proposal was to > > > change the line to instead read (in a positive way) "It is a > static > > > nested class" but I can also understand if we want to do this in > an > > > exclusion pattern rather than an inclusion pattern. > > > > > > Thoughts? > > > > > > John > > > > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider > > licenses the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.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. > > > > > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160504/19d97adc/attachment-0001.html From issues at jboss.org Wed May 4 08:36:01 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 4 May 2016 08:36:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200900#comment-13200900 ] Mark Struberg commented on CDI-420: ----------------------------------- As already clarified with [~antoinesabot-durand] it is not possible to amend the behaviour of "annotated". But it also provides a benefit for "all" as you will _not_ get interfaces etc for ProcessAnnotatedType if you use "annotated". Thus this new flag only makes sense in combination with "all". Which makes it basically an own sub-flavour and thus it's really the same like introducing a new bean-discovery-mode in the end. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > 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.4.11#64026) From issues at jboss.org Wed May 4 08:37:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 4 May 2016 08:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200900#comment-13200900 ] Mark Struberg edited comment on CDI-420 at 5/4/16 8:36 AM: ----------------------------------------------------------- As already clarified with [~antoinesabot-durand] it is not possible to amend the behaviour of "annotated". But it actually *only* provides a benefit for bean-discovery-mode="all" as you will _not_ get interfaces etc for ProcessAnnotatedType if you use "annotated". Thus this new flag only makes sense in combination with "all". Which makes it basically an own sub-flavour and thus it's really the same like introducing a new bean-discovery-mode in the end. was (Author: struberg): As already clarified with [~antoinesabot-durand] it is not possible to amend the behaviour of "annotated". But it also provides a benefit for "all" as you will _not_ get interfaces etc for ProcessAnnotatedType if you use "annotated". Thus this new flag only makes sense in combination with "all". Which makes it basically an own sub-flavour and thus it's really the same like introducing a new bean-discovery-mode in the end. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > 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.4.11#64026) From issues at jboss.org Wed May 4 09:59:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 4 May 2016 09:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200994#comment-13200994 ] Martin Kouba commented on CDI-420: ---------------------------------- http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2016/%23cdi-dev.2016-05-04.log.html#t2016-05-04T13:16:21 > add a bean-discovery-mode 'scoped' > ---------------------------------- > > 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.4.11#64026) From antoine at sabot-durand.net Fri May 6 11:00:06 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 06 May 2016 15:00:06 +0000 Subject: [cdi-dev] F2F Doodle Message-ID: Hi all, To gather information regarding a possible (we still don't have a final decision on a budget) F2F in Brno, I created a Doodle allowing each of us to enter his/her possible weeks. http://doodle.com/poll/snuudv2f4bhzpyxp Please give the week were you could have 2 days available for such a meeting. It will allow us to knows if setting the meeting is possible and have the impossible weeks. If we can set the meeting before EDR2 (not slot or budget) we'll try to put one in septembre. regards, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160506/b8af29f1/attachment.html From antoine at sabot-durand.net Tue May 10 10:19:12 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 10 May 2016 14:19:12 +0000 Subject: [cdi-dev] Canceling meeting Message-ID: Hi guys, I'm sorry I have to cancel today's meeting being sick with a huge head ache. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160510/ed6f2cc2/attachment.html From arjan.tijms at gmail.com Tue May 10 11:11:10 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 10 May 2016 17:11:10 +0200 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() Message-ID: Hi, Given a simple @Stateless bean: @Stateless public class Foo { public void bar() {} } Then requesting an instance of this via CDI as follows: Foo foo = CDI.current().select(Foo.class).get(); Causes a lot of leaked proxy instances (at least on Weld). Now what I guess needs to be done is destroying the proxy, taking Antoine's answer here as a lead: http://stackoverflow.com/questions/28767536/scope-of-stateless-bean Only the following throws an UnsupportedOperationException (on Weld 2.3.2, haven't tested OWB yet) Instance fooInstance = CDI.current().select(Foo.class); Foo foo = fooInstance.get(); foo.bar(); fooInstance.destroy(foo); The question is, is this how it's supposed to be done via the spec? Implementation wise, what happens in Weld is that the CDI/EJB proxy (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following code doesn't hit the check for a dependent instance (comments in capitals added by me): public void destroy(T instance) { Preconditions.checkNotNull(instance); // check if this is a proxy of a normal-scoped bean if (instance instanceof ProxyObject) { // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY ProxyObject proxy = (ProxyObject) instance; if (proxy.getHandler() instanceof ProxyMethodHandler) { ProxyMethodHandler handler = (ProxyMethodHandler) proxy.getHandler(); Bean bean = handler.getBean(); Context context = getBeanManager().getContext(bean.getScope()); if (context instanceof AlterableContext) { AlterableContext alterableContext = (AlterableContext) context; // CONTEXT IS A DEPENDENTCONTEXTIMPL THAT THROWS // UnsupportedOperationException FROM ITS DESTROY() METHOD alterableContext.destroy(bean); return; } else { throw BeanLogger.LOG.destroyUnsupported(context); } } } // check if this is a dependent instance CreationalContext ctx = getCreationalContext(); if (ctx instanceof WeldCreationalContext) { WeldCreationalContext weldCtx = cast(ctx); // PROXY REFERENCES ARE KEPT HERE IN A // "dependentInstances" LIST, AND WOULD BE CLEARED HERE // BUT THIS CODE IS NEVER REACHED weldCtx.destroyDependentInstance(instance); } } Now I wonder, am I doing something wrong (according to the CDI spec), or could this be a bug in the Weld code? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160510/5996fdfa/attachment-0001.html From john.d.ament at gmail.com Tue May 10 19:35:20 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 10 May 2016 23:35:20 +0000 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: References: Message-ID: Arjan, So this recently came up as well with a PR raised to clarify how instance is used to destroy references: https://github.com/cdi-spec/cdi/pull/286 Take a look at the last paragraph here: http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#dynamic_lookup John On Tue, May 10, 2016 at 11:11 AM arjan tijms wrote: > Hi, > > Given a simple @Stateless bean: > > @Stateless > public class Foo { > public void bar() {} > } > > Then requesting an instance of this via CDI as follows: > > Foo foo = CDI.current().select(Foo.class).get(); > > Causes a lot of leaked proxy instances (at least on Weld). Now what I > guess needs to be done is destroying the proxy, taking Antoine's answer > here as a lead: > http://stackoverflow.com/questions/28767536/scope-of-stateless-bean > > Only the following throws an UnsupportedOperationException (on Weld 2.3.2, > haven't tested OWB yet) > > Instance fooInstance = CDI.current().select(Foo.class); > Foo foo = fooInstance.get(); > foo.bar(); > fooInstance.destroy(foo); > > The question is, is this how it's supposed to be done via the spec? > > Implementation wise, what happens in Weld is that the CDI/EJB proxy > (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following code > doesn't hit the check for a dependent instance (comments in capitals added > by me): > > > public void destroy(T instance) { > Preconditions.checkNotNull(instance); > > // check if this is a proxy of a normal-scoped bean > if (instance instanceof ProxyObject) { > > // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY > > ProxyObject proxy = (ProxyObject) instance; > if (proxy.getHandler() instanceof ProxyMethodHandler) { > ProxyMethodHandler handler = (ProxyMethodHandler) > proxy.getHandler(); > Bean bean = handler.getBean(); > Context context = > getBeanManager().getContext(bean.getScope()); > if (context instanceof AlterableContext) { > AlterableContext alterableContext = (AlterableContext) > context; > > // CONTEXT IS A DEPENDENTCONTEXTIMPL THAT THROWS > // UnsupportedOperationException FROM ITS DESTROY() > METHOD > alterableContext.destroy(bean); > return; > } else { > throw BeanLogger.LOG.destroyUnsupported(context); > } > } > } > > // check if this is a dependent instance > CreationalContext ctx = getCreationalContext(); > if (ctx instanceof WeldCreationalContext) { > WeldCreationalContext weldCtx = cast(ctx); > > // PROXY REFERENCES ARE KEPT HERE IN A > // "dependentInstances" LIST, AND WOULD BE CLEARED HERE > // BUT THIS CODE IS NEVER REACHED > weldCtx.destroyDependentInstance(instance); > } > } > > Now I wonder, am I doing something wrong (according to the CDI spec), or > could this be a bug in the Weld code? > > Kind regards, > Arjan Tijms > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160510/05897aec/attachment.html From issues at jboss.org Wed May 11 03:10:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 11 May 2016 03:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203570#comment-13203570 ] Martin Kouba commented on CDI-594: ---------------------------------- I believe we should mark this issue as duplicate. See also CDI-519. > Instance#destroy should be linked to Instance instance which has been used for the creation > ------------------------------------------------------------------------------------------- > > Key: CDI-594 > URL: https://issues.jboss.org/browse/CDI-594 > Project: CDI Specification Issues > Issue Type: Epic > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > We suppose we have an injection of type Instance. > {code} > // adapted from javaee7-samples repo > Instance select = instance.select(new AnnotationLiteral() {}); > Greeting anotherBean = select.get(); > assertThat(anotherBean, instanceOf(SimpleGreeting.class)); > select.destroy(anotherBean); > {code} > This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work: > {code} > Greeting anotherBean = instance.select(new AnnotationLiteral() {}).get(); > assertThat(anotherBean, instanceOf(SimpleGreeting.class)); > instance.destroy(anotherBean); > {code} > The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Wed May 11 03:11:22 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 11 May 2016 09:11:22 +0200 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: References: Message-ID: <5732DB1A.1060505@redhat.com> Hi Arjan, I believe it's a Weld bug - you should be able to use Instance.destroy() to discard an internal SLSB proxy. See also "Lifecycle of stateless and singleton session beans" [1]. Tomas Remes created WELD-2148 to track this issue [2]. Also the "leak" is an expected behaviour. See for example WELD-920 [3] discussion. Martin [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle [2] https://issues.jboss.org/browse/WELD-2148 [3] https://issues.jboss.org/browse/WELD-920 Dne 10.5.2016 v 17:11 arjan tijms napsal(a): > Hi, > > Given a simple @Stateless bean: > > @Stateless > public class Foo { > public void bar() {} > } > > Then requesting an instance of this via CDI as follows: > > Foo foo = CDI.current().select(Foo.class).get(); > > Causes a lot of leaked proxy instances (at least on Weld). Now what I > guess needs to be done is destroying the proxy, taking Antoine's answer > here as a lead: > http://stackoverflow.com/questions/28767536/scope-of-stateless-bean > > Only the following throws an UnsupportedOperationException (on Weld > 2.3.2, haven't tested OWB yet) > > Instance fooInstance =CDI.current().select(Foo.class); > Foo foo = fooInstance.get(); > foo.bar(); > fooInstance.destroy(foo); > > The question is, is this how it's supposed to be done via the spec? > > Implementation wise, what happens in Weld is that the CDI/EJB proxy > (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following code > doesn't hit the check for a dependent instance (comments in capitals > added by me): > > > public void destroy(T instance) { > Preconditions.checkNotNull(instance); > > // check if this is a proxy of a normal-scoped bean > if (instance instanceof ProxyObject) { > > // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY > > ProxyObject proxy = (ProxyObject) instance; > if (proxy.getHandler() instanceof ProxyMethodHandler) { > ProxyMethodHandler handler = (ProxyMethodHandler) > proxy.getHandler(); > Bean bean = handler.getBean(); > Context context = > getBeanManager().getContext(bean.getScope()); > if (context instanceof AlterableContext) { > AlterableContext alterableContext = > (AlterableContext) context; > > // CONTEXT IS A DEPENDENTCONTEXTIMPL THAT THROWS > // UnsupportedOperationException FROM ITS DESTROY() > METHOD > alterableContext.destroy(bean); > return; > } else { > throw BeanLogger.LOG.destroyUnsupported(context); > } > } > } > > // check if this is a dependent instance > CreationalContext ctx = getCreationalContext(); > if (ctx instanceof WeldCreationalContext) { > WeldCreationalContext weldCtx = cast(ctx); > > // PROXY REFERENCES ARE KEPT HERE IN A > // "dependentInstances" LIST, AND WOULD BE CLEARED HERE > // BUT THIS CODE IS NEVER REACHED > weldCtx.destroyDependentInstance(instance); > } > } > > Now I wonder, am I doing something wrong (according to the CDI spec), or > could this be a bug in the Weld code? > > Kind regards, > Arjan Tijms > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 struberg at yahoo.de Wed May 11 03:30:51 2016 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 11 May 2016 07:30:51 +0000 (UTC) Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: References: Message-ID: <1869026432.191087.1462951852241.JavaMail.yahoo@mail.yahoo.com> Imo the proxy is under the full control of the user. Note that it is _not_ necessary to create a new proxy instance for each usage of a bean. All of the usages could really re-use the same proxy instance. Which of course internally points to different Contextual Instances... In OWB we have a single proxy instance which we share across all Contextual Instances of the same Bean. You will hit the same issue when serialising the proxy, etc. Sounds like an implementation glitch. But it should be easy to fix for Martin and Co. LieGrue, strub On Wednesday, 11 May 2016, 1:36, John D. Ament wrote: > > >Arjan, > > >So this recently came up as well with a PR raised to clarify how instance is used to destroy references: https://github.com/cdi-spec/cdi/pull/286 > > >Take a look at the last paragraph here: http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#dynamic_lookup > > >John > >On Tue, May 10, 2016 at 11:11 AM arjan tijms wrote: > >Hi, >> >> >>Given a simple @Stateless bean: >> >> >>@Stateless >>public class Foo { >> public void bar() {} >>} >> >> >>Then requesting an instance of this via CDI as follows: >> >> >>Foo foo = CDI.current().select(Foo.class).get(); >> >> >>Causes a lot of leaked proxy instances (at least on Weld). Now what I guess needs to be done is destroying the proxy, taking Antoine's answer here as a lead: http://stackoverflow.com/questions/28767536/scope-of-stateless-bean >> >> >>Only the following throws an UnsupportedOperationException (on Weld 2.3.2, haven't tested OWB yet) >> >> >>Instance fooInstance =CDI.current().select(Foo.class); >>Foo foo = fooInstance.get(); >>foo.bar(); >>fooInstance.destroy(foo); >> >> >>The question is, is this how it's supposed to be done via the spec? >> >> >>Implementation wise, what happens in Weld is that the CDI/EJB proxy (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following code doesn't hit the check for a dependent instance (comments in capitals added by me): >> >> >> >> >> public void destroy(T instance) { >> Preconditions.checkNotNull(instance); >> >> >> // check if this is a proxy of a normal-scoped bean >> if (instance instanceof ProxyObject) { >> >> >> // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY >> >> >> ProxyObject proxy = (ProxyObject) instance; >> if (proxy.getHandler() instanceof ProxyMethodHandler) { >> ProxyMethodHandler handler = (ProxyMethodHandler) proxy.getHandler(); >> Bean bean = handler.getBean(); >> Context context = getBeanManager().getContext(bean.getScope()); >> if (context instanceof AlterableContext) { >> AlterableContext alterableContext = (AlterableContext) context; >> >> // CONTEXT IS A DEPENDENTCONTEXTIMPL THAT THROWS >> // UnsupportedOperationException FROM ITS DESTROY() METHOD >> alterableContext.destroy(bean); >> return; >> } else { >> throw BeanLogger.LOG.destroyUnsupported(context); >> } >> } >> } >> >> >> // check if this is a dependent instance >> CreationalContext ctx = getCreationalContext(); >> if (ctx instanceof WeldCreationalContext) { >> WeldCreationalContext weldCtx = cast(ctx); >> >> >> // PROXY REFERENCES ARE KEPT HERE IN A >> // "dependentInstances" LIST, AND WOULD BE CLEARED HERE >> // BUT THIS CODE IS NEVER REACHED >> weldCtx.destroyDependentInstance(instance); >> } >> } >> >> >>Now I wonder, am I doing something wrong (according to the CDI spec), or could this be a bug in the Weld code? >> >> >>Kind regards, >>Arjan Tijms _______________________________________________ >>cdi-dev mailing list >>cdi-dev at lists.jboss.org >>https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 mkouba at redhat.com Wed May 11 04:15:24 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 11 May 2016 10:15:24 +0200 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: <1869026432.191087.1462951852241.JavaMail.yahoo@mail.yahoo.com> References: <1869026432.191087.1462951852241.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5732EA1C.7010807@redhat.com> Just to be clear: we're not talking about client proxies (contextual references) but contextual instances. For a SLSB when Contextual.create() is called the container should create an internal reference to the session bean and when the destroy() method is called, the container should discard this internal reference. See also 7.3.3. Lifecycle of stateless and singleton session beans [1]. Martin [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle Dne 11.5.2016 v 09:30 Mark Struberg napsal(a): > Imo the proxy is under the full control of the user. > > Note that it is _not_ necessary to create a new proxy instance for each usage of a bean. All of the usages could really re-use the same proxy instance. Which of course internally points to different Contextual Instances... > > > In OWB we have a single proxy instance which we share across all Contextual Instances of the same Bean. > You will hit the same issue when serialising the proxy, etc. > Sounds like an implementation glitch. But it should be easy to fix for Martin and Co. > > > LieGrue, > strub > > > > On Wednesday, 11 May 2016, 1:36, John D. Ament wrote: > > >> >> >> Arjan, >> >> >> So this recently came up as well with a PR raised to clarify how instance is used to destroy references: https://github.com/cdi-spec/cdi/pull/286 >> >> >> Take a look at the last paragraph here: http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#dynamic_lookup >> >> >> John >> >> On Tue, May 10, 2016 at 11:11 AM arjan tijms wrote: >> >> Hi, >>> >>> >>> Given a simple @Stateless bean: >>> >>> >>> @Stateless >>> public class Foo { >>> public void bar() {} >>> } >>> >>> >>> Then requesting an instance of this via CDI as follows: >>> >>> >>> Foo foo = CDI.current().select(Foo.class).get(); >>> >>> >>> Causes a lot of leaked proxy instances (at least on Weld). Now what I guess needs to be done is destroying the proxy, taking Antoine's answer here as a lead: http://stackoverflow.com/questions/28767536/scope-of-stateless-bean >>> >>> >>> Only the following throws an UnsupportedOperationException (on Weld 2.3.2, haven't tested OWB yet) >>> >>> >>> Instance fooInstance =CDI.current().select(Foo.class); >>> Foo foo = fooInstance.get(); >>> foo.bar(); >>> fooInstance.destroy(foo); >>> >>> >>> The question is, is this how it's supposed to be done via the spec? >>> >>> >>> Implementation wise, what happens in Weld is that the CDI/EJB proxy (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following code doesn't hit the check for a dependent instance (comments in capitals added by me): >>> >>> >>> >>> >>> public void destroy(T instance) { >>> Preconditions.checkNotNull(instance); >>> >>> >>> // check if this is a proxy of a normal-scoped bean >>> if (instance instanceof ProxyObject) { >>> >>> >>> // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY >>> >>> >>> ProxyObject proxy = (ProxyObject) instance; >>> if (proxy.getHandler() instanceof ProxyMethodHandler) { >>> ProxyMethodHandler handler = (ProxyMethodHandler) proxy.getHandler(); >>> Bean bean = handler.getBean(); >>> Context context = getBeanManager().getContext(bean.getScope()); >>> if (context instanceof AlterableContext) { >>> AlterableContext alterableContext = (AlterableContext) context; >>> >>> // CONTEXT IS A DEPENDENTCONTEXTIMPL THAT THROWS >>> // UnsupportedOperationException FROM ITS DESTROY() METHOD >>> alterableContext.destroy(bean); >>> return; >>> } else { >>> throw BeanLogger.LOG.destroyUnsupported(context); >>> } >>> } >>> } >>> >>> >>> // check if this is a dependent instance >>> CreationalContext ctx = getCreationalContext(); >>> if (ctx instanceof WeldCreationalContext) { >>> WeldCreationalContext weldCtx = cast(ctx); >>> >>> >>> // PROXY REFERENCES ARE KEPT HERE IN A >>> // "dependentInstances" LIST, AND WOULD BE CLEARED HERE >>> // BUT THIS CODE IS NEVER REACHED >>> weldCtx.destroyDependentInstance(instance); >>> } >>> } >>> >>> >>> Now I wonder, am I doing something wrong (according to the CDI spec), or could this be a bug in the Weld code? >>> >>> >>> Kind regards, >>> Arjan Tijms > _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 arjan.tijms at gmail.com Wed May 11 04:40:47 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 11 May 2016 10:40:47 +0200 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: <5732DB1A.1060505@redhat.com> References: <5732DB1A.1060505@redhat.com> Message-ID: Hi Martin, Thanks for the swift action and the reference. I do have one more question looking at the test that was added. It now uses this SLSB: @Stateless public class SLSessionBean { public void ping(){ } static final AtomicBoolean DESTROYED = new AtomicBoolean(); @PreDestroy public void destroy() { DESTROYED.set(true); } } The assertion in the test is that the (a?) SLSB is actually destroyed, but wasn't the idea that only the internal reference is destroyed, and the bean just stays in the pool? Here it looks like the code intends to destroy a random SLSB instance from the pool. (random, since I guess an internal reference doesn't stick to the same actual instance of a SLSB, otherwise you would get stateful like semantics). Or did I miss something? Kind regards, Arjan Tijms On Wed, May 11, 2016 at 9:11 AM, Martin Kouba wrote: > Hi Arjan, > > I believe it's a Weld bug - you should be able to use Instance.destroy() > to discard an internal SLSB proxy. See also "Lifecycle of stateless and > singleton session beans" [1]. Tomas Remes created WELD-2148 to track this > issue [2]. > > Also the "leak" is an expected behaviour. See for example WELD-920 [3] > discussion. > > Martin > > [1] > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle > > [2] > https://issues.jboss.org/browse/WELD-2148 > > [3] > https://issues.jboss.org/browse/WELD-920 > > Dne 10.5.2016 v 17:11 arjan tijms napsal(a): > >> Hi, >> >> Given a simple @Stateless bean: >> >> @Stateless >> public class Foo { >> public void bar() {} >> } >> >> Then requesting an instance of this via CDI as follows: >> >> Foo foo = CDI.current().select(Foo.class).get(); >> >> Causes a lot of leaked proxy instances (at least on Weld). Now what I >> guess needs to be done is destroying the proxy, taking Antoine's answer >> here as a lead: >> http://stackoverflow.com/questions/28767536/scope-of-stateless-bean >> >> Only the following throws an UnsupportedOperationException (on Weld >> 2.3.2, haven't tested OWB yet) >> >> Instance fooInstance =CDI.current().select(Foo.class); >> Foo foo = fooInstance.get(); >> foo.bar(); >> fooInstance.destroy(foo); >> >> The question is, is this how it's supposed to be done via the spec? >> >> Implementation wise, what happens in Weld is that the CDI/EJB proxy >> (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following code >> doesn't hit the check for a dependent instance (comments in capitals >> added by me): >> >> >> public void destroy(T instance) { >> Preconditions.checkNotNull(instance); >> >> // check if this is a proxy of a normal-scoped bean >> if (instance instanceof ProxyObject) { >> >> // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY >> >> ProxyObject proxy = (ProxyObject) instance; >> if (proxy.getHandler() instanceof ProxyMethodHandler) { >> ProxyMethodHandler handler = (ProxyMethodHandler) >> proxy.getHandler(); >> Bean bean = handler.getBean(); >> Context context = >> getBeanManager().getContext(bean.getScope()); >> if (context instanceof AlterableContext) { >> AlterableContext alterableContext = >> (AlterableContext) context; >> >> // CONTEXT IS A DEPENDENTCONTEXTIMPL THAT THROWS >> // UnsupportedOperationException FROM ITS DESTROY() >> METHOD >> alterableContext.destroy(bean); >> return; >> } else { >> throw BeanLogger.LOG.destroyUnsupported(context); >> } >> } >> } >> >> // check if this is a dependent instance >> CreationalContext ctx = getCreationalContext(); >> if (ctx instanceof WeldCreationalContext) { >> WeldCreationalContext weldCtx = cast(ctx); >> >> // PROXY REFERENCES ARE KEPT HERE IN A >> // "dependentInstances" LIST, AND WOULD BE CLEARED HERE >> // BUT THIS CODE IS NEVER REACHED >> weldCtx.destroyDependentInstance(instance); >> } >> } >> >> Now I wonder, am I doing something wrong (according to the CDI spec), or >> could this be a bug in the Weld code? >> >> Kind regards, >> Arjan Tijms >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.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/20160511/73d26766/attachment.html From mkouba at redhat.com Wed May 11 04:54:04 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 11 May 2016 10:54:04 +0200 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: References: <5732DB1A.1060505@redhat.com> Message-ID: <5732F32C.9000202@redhat.com> Hi Arjan, the test attached to WELD-2148 is wrong. We can not inspect an actual SLSB instance. The only thing we could test is that Instance.destroy() does not throw UnsupportedException for SLSB CDI reference. Martin Dne 11.5.2016 v 10:40 arjan tijms napsal(a): > Hi Martin, > > Thanks for the swift action and the reference. I do have one more > question looking at the test that was added. It now uses this SLSB: > > @Stateless > public class SLSessionBean { > > public void ping(){ > } > > static final AtomicBoolean DESTROYED = new AtomicBoolean(); > > @PreDestroy > public void destroy() { > DESTROYED.set(true); > } > } > > The assertion in the test is that the (a?) SLSB is actually destroyed, > but wasn't the idea that only the internal reference is destroyed, and > the bean just stays in the pool? > > Here it looks like the code intends to destroy a random SLSB instance > from the pool. (random, since I guess an internal reference doesn't > stick to the same actual instance of a SLSB, otherwise you would get > stateful like semantics). > > Or did I miss something? > > Kind regards, > Arjan Tijms > > > > > On Wed, May 11, 2016 at 9:11 AM, Martin Kouba > wrote: > > Hi Arjan, > > I believe it's a Weld bug - you should be able to use > Instance.destroy() to discard an internal SLSB proxy. See also > "Lifecycle of stateless and singleton session beans" [1]. Tomas > Remes created WELD-2148 to track this issue [2]. > > Also the "leak" is an expected behaviour. See for example WELD-920 > [3] discussion. > > Martin > > [1] > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle > > [2] > https://issues.jboss.org/browse/WELD-2148 > > [3] > https://issues.jboss.org/browse/WELD-920 > > Dne 10.5.2016 v 17:11 arjan tijms napsal(a): > > Hi, > > Given a simple @Stateless bean: > > @Stateless > public class Foo { > public void bar() {} > } > > Then requesting an instance of this via CDI as follows: > > Foo foo = CDI.current().select(Foo.class).get(); > > Causes a lot of leaked proxy instances (at least on Weld). Now > what I > guess needs to be done is destroying the proxy, taking Antoine's > answer > here as a lead: > http://stackoverflow.com/questions/28767536/scope-of-stateless-bean > > Only the following throws an UnsupportedOperationException (on Weld > 2.3.2, haven't tested OWB yet) > > Instance fooInstance =CDI.current().select(Foo.class); > Foo foo = fooInstance.get(); > foo.bar(); > fooInstance.destroy(foo); > > The question is, is this how it's supposed to be done via the spec? > > Implementation wise, what happens in Weld is that the CDI/EJB proxy > (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following code > doesn't hit the check for a dependent instance (comments in capitals > added by me): > > > public void destroy(T instance) { > Preconditions.checkNotNull(instance); > > // check if this is a proxy of a normal-scoped bean > if (instance instanceof ProxyObject) { > > // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY > > ProxyObject proxy = (ProxyObject) instance; > if (proxy.getHandler() instanceof > ProxyMethodHandler) { > ProxyMethodHandler handler = (ProxyMethodHandler) > proxy.getHandler(); > Bean bean = handler.getBean(); > Context context = > getBeanManager().getContext(bean.getScope()); > if (context instanceof AlterableContext) { > AlterableContext alterableContext = > (AlterableContext) context; > > // CONTEXT IS A DEPENDENTCONTEXTIMPL THAT > THROWS > // UnsupportedOperationException FROM ITS > DESTROY() > METHOD > alterableContext.destroy(bean); > return; > } else { > throw > BeanLogger.LOG.destroyUnsupported(context); > } > } > } > > // check if this is a dependent instance > CreationalContext ctx = getCreationalContext(); > if (ctx instanceof WeldCreationalContext) { > WeldCreationalContext weldCtx = cast(ctx); > > // PROXY REFERENCES ARE KEPT HERE IN A > // "dependentInstances" LIST, AND WOULD BE CLEARED > HERE > // BUT THIS CODE IS NEVER REACHED > weldCtx.destroyDependentInstance(instance); > } > } > > Now I wonder, am I doing something wrong (according to the CDI > spec), or > could this be a bug in the Weld code? > > Kind regards, > Arjan Tijms > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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 > > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Wed May 11 05:20:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 11 May 2016 05:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-594: ----------------------------- Issue Type: Clarification (was: Epic) > Instance#destroy should be linked to Instance instance which has been used for the creation > ------------------------------------------------------------------------------------------- > > Key: CDI-594 > URL: https://issues.jboss.org/browse/CDI-594 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > We suppose we have an injection of type Instance. > {code} > // adapted from javaee7-samples repo > Instance select = instance.select(new AnnotationLiteral() {}); > Greeting anotherBean = select.get(); > assertThat(anotherBean, instanceOf(SimpleGreeting.class)); > select.destroy(anotherBean); > {code} > This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work: > {code} > Greeting anotherBean = instance.select(new AnnotationLiteral() {}).get(); > assertThat(anotherBean, instanceOf(SimpleGreeting.class)); > instance.destroy(anotherBean); > {code} > The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From arjan.tijms at gmail.com Wed May 11 05:20:59 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 11 May 2016 11:20:59 +0200 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: <5732F32C.9000202@redhat.com> References: <5732DB1A.1060505@redhat.com> <5732F32C.9000202@redhat.com> Message-ID: Hi, On Wed, May 11, 2016 at 10:54 AM, Martin Kouba wrote: > Hi Arjan, > > the test attached to WELD-2148 is wrong. We can not inspect an actual SLSB > instance. The only thing we could test is that Instance.destroy() does not > throw UnsupportedException for SLSB CDI reference. > I see, thanks for the clarification! Going forward, would it not be convenient if an Instance was AutoCloseable, so that one could do: try (Instance fooInstance = CDI.current().select(Foo.class)) { Foo foo = fooInstance.get(); foo.bar(); } Kind regards, Arjan Tijms > > Martin > > Dne 11.5.2016 v 10:40 arjan tijms napsal(a): > >> Hi Martin, >> >> Thanks for the swift action and the reference. I do have one more >> question looking at the test that was added. It now uses this SLSB: >> >> @Stateless >> public class SLSessionBean { >> >> public void ping(){ >> } >> >> static final AtomicBoolean DESTROYED = new AtomicBoolean(); >> >> @PreDestroy >> public void destroy() { >> DESTROYED.set(true); >> } >> } >> >> The assertion in the test is that the (a?) SLSB is actually destroyed, >> but wasn't the idea that only the internal reference is destroyed, and >> the bean just stays in the pool? >> >> Here it looks like the code intends to destroy a random SLSB instance >> from the pool. (random, since I guess an internal reference doesn't >> stick to the same actual instance of a SLSB, otherwise you would get >> stateful like semantics). >> >> Or did I miss something? >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> On Wed, May 11, 2016 at 9:11 AM, Martin Kouba > > wrote: >> >> Hi Arjan, >> >> I believe it's a Weld bug - you should be able to use >> Instance.destroy() to discard an internal SLSB proxy. See also >> "Lifecycle of stateless and singleton session beans" [1]. Tomas >> Remes created WELD-2148 to track this issue [2]. >> >> Also the "leak" is an expected behaviour. See for example WELD-920 >> [3] discussion. >> >> Martin >> >> [1] >> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle >> >> [2] >> https://issues.jboss.org/browse/WELD-2148 >> >> [3] >> https://issues.jboss.org/browse/WELD-920 >> >> Dne 10.5.2016 v 17:11 arjan tijms napsal(a): >> >> Hi, >> >> Given a simple @Stateless bean: >> >> @Stateless >> public class Foo { >> public void bar() {} >> } >> >> Then requesting an instance of this via CDI as follows: >> >> Foo foo = CDI.current().select(Foo.class).get(); >> >> Causes a lot of leaked proxy instances (at least on Weld). Now >> what I >> guess needs to be done is destroying the proxy, taking Antoine's >> answer >> here as a lead: >> >> http://stackoverflow.com/questions/28767536/scope-of-stateless-bean >> >> Only the following throws an UnsupportedOperationException (on >> Weld >> 2.3.2, haven't tested OWB yet) >> >> Instance fooInstance =CDI.current().select(Foo.class); >> Foo foo = fooInstance.get(); >> foo.bar(); >> fooInstance.destroy(foo); >> >> The question is, is this how it's supposed to be done via the >> spec? >> >> Implementation wise, what happens in Weld is that the CDI/EJB >> proxy >> (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following >> code >> doesn't hit the check for a dependent instance (comments in >> capitals >> added by me): >> >> >> public void destroy(T instance) { >> Preconditions.checkNotNull(instance); >> >> // check if this is a proxy of a normal-scoped bean >> if (instance instanceof ProxyObject) { >> >> // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY >> >> ProxyObject proxy = (ProxyObject) instance; >> if (proxy.getHandler() instanceof >> ProxyMethodHandler) { >> ProxyMethodHandler handler = >> (ProxyMethodHandler) >> proxy.getHandler(); >> Bean bean = handler.getBean(); >> Context context = >> getBeanManager().getContext(bean.getScope()); >> if (context instanceof AlterableContext) { >> AlterableContext alterableContext = >> (AlterableContext) context; >> >> // CONTEXT IS A DEPENDENTCONTEXTIMPL THAT >> THROWS >> // UnsupportedOperationException FROM ITS >> DESTROY() >> METHOD >> alterableContext.destroy(bean); >> return; >> } else { >> throw >> BeanLogger.LOG.destroyUnsupported(context); >> } >> } >> } >> >> // check if this is a dependent instance >> CreationalContext ctx = >> getCreationalContext(); >> if (ctx instanceof WeldCreationalContext) { >> WeldCreationalContext weldCtx = >> cast(ctx); >> >> // PROXY REFERENCES ARE KEPT HERE IN A >> // "dependentInstances" LIST, AND WOULD BE CLEARED >> HERE >> // BUT THIS CODE IS NEVER REACHED >> weldCtx.destroyDependentInstance(instance); >> } >> } >> >> Now I wonder, am I doing something wrong (according to the CDI >> spec), or >> could this be a bug in the Weld code? >> >> Kind regards, >> Arjan Tijms >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider >> licenses the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.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 >> >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160511/5a051490/attachment.html From issues at jboss.org Wed May 11 05:37:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 11 May 2016 05:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203657#comment-13203657 ] Martin Kouba commented on CDI-594: ---------------------------------- I can see the difference now. Right now, all the child {{Instance}} instances obtained through {{Instance.select()}} share the {{CreationalContext}} of the root (in most cases an injected {{Instance}}). That's why it would probably work. The requirement to be symmetric seems reasonable but I don't get the requirement for untracked instances. For your use case it might be useful but it may break other applications where e.g. {{@PreDestroy}} callback is needed. By the way, in Weld there is an optimization where certain dependent instances are not tracked (e.g. a bean with no transitive dependency with @PreDestroy/disposal method). In any case, CDI-519 clarifies that a bean instance to destroy must be obtained from the same {{Instance}} object. > Instance#destroy should be linked to Instance instance which has been used for the creation > ------------------------------------------------------------------------------------------- > > Key: CDI-594 > URL: https://issues.jboss.org/browse/CDI-594 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > We suppose we have an injection of type Instance. > {code} > // adapted from javaee7-samples repo > Instance select = instance.select(new AnnotationLiteral() {}); > Greeting anotherBean = select.get(); > assertThat(anotherBean, instanceOf(SimpleGreeting.class)); > select.destroy(anotherBean); > {code} > This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work: > {code} > Greeting anotherBean = instance.select(new AnnotationLiteral() {}).get(); > assertThat(anotherBean, instanceOf(SimpleGreeting.class)); > instance.destroy(anotherBean); > {code} > The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Wed May 11 05:43:36 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 11 May 2016 11:43:36 +0200 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: References: <5732DB1A.1060505@redhat.com> <5732F32C.9000202@redhat.com> Message-ID: <5732FEC8.4000208@redhat.com> Dne 11.5.2016 v 11:20 arjan tijms napsal(a): > Hi, > > On Wed, May 11, 2016 at 10:54 AM, Martin Kouba > wrote: > > Hi Arjan, > > the test attached to WELD-2148 is wrong. We can not inspect an > actual SLSB instance. The only thing we could test is that > Instance.destroy() does not throw UnsupportedException for SLSB CDI > reference. > > > I see, thanks for the clarification! > > Going forward, would it not be convenient if an Instance > was AutoCloseable, so that one could do: I don't think so. Remember that Instace is more like a "factory" and not only for @Dependent objects. What would actually close() do? Also the users would be tempted to use this for injected Instance which does not make sense. > > try (Instance fooInstance =CDI.current().select(Foo.class)) { > Foo foo = fooInstance.get(); > foo.bar(); > } > > Kind regards, > Arjan Tijms > > > > > Martin > > Dne 11.5.2016 v 10:40 arjan tijms napsal(a): > > Hi Martin, > > Thanks for the swift action and the reference. I do have one more > question looking at the test that was added. It now uses this SLSB: > > @Stateless > public class SLSessionBean { > > public void ping(){ > } > > static final AtomicBoolean DESTROYED = new AtomicBoolean(); > > @PreDestroy > public void destroy() { > DESTROYED.set(true); > } > } > > The assertion in the test is that the (a?) SLSB is actually > destroyed, > but wasn't the idea that only the internal reference is > destroyed, and > the bean just stays in the pool? > > Here it looks like the code intends to destroy a random SLSB > instance > from the pool. (random, since I guess an internal reference doesn't > stick to the same actual instance of a SLSB, otherwise you would get > stateful like semantics). > > Or did I miss something? > > Kind regards, > Arjan Tijms > > > > > On Wed, May 11, 2016 at 9:11 AM, Martin Kouba > >> wrote: > > Hi Arjan, > > I believe it's a Weld bug - you should be able to use > Instance.destroy() to discard an internal SLSB proxy. See also > "Lifecycle of stateless and singleton session beans" [1]. Tomas > Remes created WELD-2148 to track this issue [2]. > > Also the "leak" is an expected behaviour. See for example > WELD-920 > [3] discussion. > > Martin > > [1] > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle > > [2] > https://issues.jboss.org/browse/WELD-2148 > > [3] > https://issues.jboss.org/browse/WELD-920 > > Dne 10.5.2016 v 17:11 arjan tijms napsal(a): > > Hi, > > Given a simple @Stateless bean: > > @Stateless > public class Foo { > public void bar() {} > } > > Then requesting an instance of this via CDI as follows: > > Foo foo = CDI.current().select(Foo.class).get(); > > Causes a lot of leaked proxy instances (at least on > Weld). Now > what I > guess needs to be done is destroying the proxy, taking > Antoine's > answer > here as a lead: > http://stackoverflow.com/questions/28767536/scope-of-stateless-bean > > Only the following throws an > UnsupportedOperationException (on Weld > 2.3.2, haven't tested OWB yet) > > Instance fooInstance =CDI.current().select(Foo.class); > Foo foo = fooInstance.get(); > foo.bar(); > fooInstance.destroy(foo); > > The question is, is this how it's supposed to be done > via the spec? > > Implementation wise, what happens in Weld is that the > CDI/EJB proxy > (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the > following code > doesn't hit the check for a dependent instance > (comments in capitals > added by me): > > > public void destroy(T instance) { > Preconditions.checkNotNull(instance); > > // check if this is a proxy of a > normal-scoped bean > if (instance instanceof ProxyObject) { > > // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY > > ProxyObject proxy = (ProxyObject) instance; > if (proxy.getHandler() instanceof > ProxyMethodHandler) { > ProxyMethodHandler handler = > (ProxyMethodHandler) > proxy.getHandler(); > Bean bean = handler.getBean(); > Context context = > getBeanManager().getContext(bean.getScope()); > if (context instanceof > AlterableContext) { > AlterableContext alterableContext = > (AlterableContext) context; > > // CONTEXT IS A > DEPENDENTCONTEXTIMPL THAT > THROWS > // UnsupportedOperationException > FROM ITS > DESTROY() > METHOD > alterableContext.destroy(bean); > return; > } else { > throw > BeanLogger.LOG.destroyUnsupported(context); > } > } > } > > // check if this is a dependent instance > CreationalContext ctx = > getCreationalContext(); > if (ctx instanceof WeldCreationalContext) { > WeldCreationalContext weldCtx > = cast(ctx); > > // PROXY REFERENCES ARE KEPT HERE IN A > // "dependentInstances" LIST, AND WOULD > BE CLEARED > HERE > // BUT THIS CODE IS NEVER REACHED > weldCtx.destroyDependentInstance(instance); > } > } > > Now I wonder, am I doing something wrong (according to > the CDI > spec), or > could this be a bug in the Weld code? > > Kind regards, > Arjan Tijms > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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 > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > > -- Martin Kouba Software Engineer Red Hat, Czech Republic From arjan.tijms at gmail.com Wed May 11 05:56:09 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 11 May 2016 11:56:09 +0200 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: <5732FEC8.4000208@redhat.com> References: <5732DB1A.1060505@redhat.com> <5732F32C.9000202@redhat.com> <5732FEC8.4000208@redhat.com> Message-ID: Hi, On Wed, May 11, 2016 at 11:43 AM, Martin Kouba wrote: > I don't think so. Remember that Instace is more like a "factory" and not > only for @Dependent objects. What would actually close() do? I'd intuitively say release and where appropriate destroy all beans that were created from that particular instance of uhm Instance. But maybe the existing semantics of Instance aren't a good fit for that. Thinking out loud, maybe an AutoInstance variant? try (AutoInstance fooInstance = CDI.current().autoSelect(Foo.class)) { Foo foo = fooInstance.get(); foo.bar(); } autoSelect could even throw early if the selected bean is not dependent scoped. But as mentioned, just thinking out loud here. Kind regards, Arjan Tijms > Also the users would be tempted to use this for injected Instance which > does not make sense. > > >> try (Instance fooInstance =CDI.current().select(Foo.class)) { >> >> Foo foo = fooInstance.get(); >> foo.bar(); >> } >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> Martin >> >> Dne 11.5.2016 v 10:40 arjan tijms napsal(a): >> >> Hi Martin, >> >> Thanks for the swift action and the reference. I do have one more >> question looking at the test that was added. It now uses this >> SLSB: >> >> @Stateless >> public class SLSessionBean { >> >> public void ping(){ >> } >> >> static final AtomicBoolean DESTROYED = new AtomicBoolean(); >> >> @PreDestroy >> public void destroy() { >> DESTROYED.set(true); >> } >> } >> >> The assertion in the test is that the (a?) SLSB is actually >> destroyed, >> but wasn't the idea that only the internal reference is >> destroyed, and >> the bean just stays in the pool? >> >> Here it looks like the code intends to destroy a random SLSB >> instance >> from the pool. (random, since I guess an internal reference >> doesn't >> stick to the same actual instance of a SLSB, otherwise you would >> get >> stateful like semantics). >> >> Or did I miss something? >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> On Wed, May 11, 2016 at 9:11 AM, Martin Kouba > >> >> wrote: >> >> Hi Arjan, >> >> I believe it's a Weld bug - you should be able to use >> Instance.destroy() to discard an internal SLSB proxy. See >> also >> "Lifecycle of stateless and singleton session beans" [1]. >> Tomas >> Remes created WELD-2148 to track this issue [2]. >> >> Also the "leak" is an expected behaviour. See for example >> WELD-920 >> [3] discussion. >> >> Martin >> >> [1] >> >> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle >> >> [2] >> https://issues.jboss.org/browse/WELD-2148 >> >> [3] >> https://issues.jboss.org/browse/WELD-920 >> >> Dne 10.5.2016 v 17:11 arjan tijms napsal(a): >> >> Hi, >> >> Given a simple @Stateless bean: >> >> @Stateless >> public class Foo { >> public void bar() {} >> } >> >> Then requesting an instance of this via CDI as follows: >> >> Foo foo = CDI.current().select(Foo.class).get(); >> >> Causes a lot of leaked proxy instances (at least on >> Weld). Now >> what I >> guess needs to be done is destroying the proxy, taking >> Antoine's >> answer >> here as a lead: >> >> http://stackoverflow.com/questions/28767536/scope-of-stateless-bean >> >> Only the following throws an >> UnsupportedOperationException (on Weld >> 2.3.2, haven't tested OWB yet) >> >> Instance fooInstance >> =CDI.current().select(Foo.class); >> Foo foo = fooInstance.get(); >> foo.bar(); >> fooInstance.destroy(foo); >> >> The question is, is this how it's supposed to be done >> via the spec? >> >> Implementation wise, what happens in Weld is that the >> CDI/EJB proxy >> (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the >> following code >> doesn't hit the check for a dependent instance >> (comments in capitals >> added by me): >> >> >> public void destroy(T instance) { >> Preconditions.checkNotNull(instance); >> >> // check if this is a proxy of a >> normal-scoped bean >> if (instance instanceof ProxyObject) { >> >> // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY >> >> ProxyObject proxy = (ProxyObject) instance; >> if (proxy.getHandler() instanceof >> ProxyMethodHandler) { >> ProxyMethodHandler handler = >> (ProxyMethodHandler) >> proxy.getHandler(); >> Bean bean = handler.getBean(); >> Context context = >> getBeanManager().getContext(bean.getScope()); >> if (context instanceof >> AlterableContext) { >> AlterableContext alterableContext = >> (AlterableContext) context; >> >> // CONTEXT IS A >> DEPENDENTCONTEXTIMPL THAT >> THROWS >> // UnsupportedOperationException >> FROM ITS >> DESTROY() >> METHOD >> alterableContext.destroy(bean); >> return; >> } else { >> throw >> BeanLogger.LOG.destroyUnsupported(context); >> } >> } >> } >> >> // check if this is a dependent instance >> CreationalContext ctx = >> getCreationalContext(); >> if (ctx instanceof WeldCreationalContext) { >> WeldCreationalContext weldCtx >> = cast(ctx); >> >> // PROXY REFERENCES ARE KEPT HERE IN A >> // "dependentInstances" LIST, AND WOULD >> BE CLEARED >> HERE >> // BUT THIS CODE IS NEVER REACHED >> weldCtx.destroyDependentInstance(instance); >> } >> } >> >> Now I wonder, am I doing something wrong (according to >> the CDI >> spec), or >> could this be a bug in the Weld code? >> >> Kind regards, >> Arjan Tijms >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the >> provider >> licenses the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.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 >> >> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160511/06fa35a1/attachment-0001.html From john.d.ament at gmail.com Wed May 11 06:16:24 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 11 May 2016 10:16:24 +0000 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: References: <5732DB1A.1060505@redhat.com> <5732F32C.9000202@redhat.com> <5732FEC8.4000208@redhat.com> Message-ID: On Wed, May 11, 2016 at 5:58 AM arjan tijms wrote: > Hi, > > On Wed, May 11, 2016 at 11:43 AM, Martin Kouba wrote: > >> I don't think so. Remember that Instace is more like a "factory" and not >> only for @Dependent objects. What would actually close() do? > > > I'd intuitively say release and where appropriate destroy all beans that > were created from that particular instance of uhm Instance. But maybe the > existing semantics of Instance aren't a good fit for that. > > Thinking out loud, maybe an AutoInstance variant? > > try (AutoInstance fooInstance = CDI.current().autoSelect(Foo.class)) { > > Foo foo = fooInstance.get(); > foo.bar(); > } > > Sounds very similar to my original proposal, I would just use dependent in this case, unless we want to hide that from the developer. > autoSelect could even throw early if the selected bean is not dependent > scoped. But as mentioned, just thinking out loud here. > > Kind regards, > Arjan Tijms > > > > > >> Also the users would be tempted to use this for injected Instance which >> does not make sense. >> >> >>> try (Instance fooInstance =CDI.current().select(Foo.class)) { >>> >>> Foo foo = fooInstance.get(); >>> foo.bar(); >>> } >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> >>> Martin >>> >>> Dne 11.5.2016 v 10:40 arjan tijms napsal(a): >>> >>> Hi Martin, >>> >>> Thanks for the swift action and the reference. I do have one more >>> question looking at the test that was added. It now uses this >>> SLSB: >>> >>> @Stateless >>> public class SLSessionBean { >>> >>> public void ping(){ >>> } >>> >>> static final AtomicBoolean DESTROYED = new AtomicBoolean(); >>> >>> @PreDestroy >>> public void destroy() { >>> DESTROYED.set(true); >>> } >>> } >>> >>> The assertion in the test is that the (a?) SLSB is actually >>> destroyed, >>> but wasn't the idea that only the internal reference is >>> destroyed, and >>> the bean just stays in the pool? >>> >>> Here it looks like the code intends to destroy a random SLSB >>> instance >>> from the pool. (random, since I guess an internal reference >>> doesn't >>> stick to the same actual instance of a SLSB, otherwise you would >>> get >>> stateful like semantics). >>> >>> Or did I miss something? >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> >>> On Wed, May 11, 2016 at 9:11 AM, Martin Kouba >> >>> >> wrote: >>> >>> Hi Arjan, >>> >>> I believe it's a Weld bug - you should be able to use >>> Instance.destroy() to discard an internal SLSB proxy. See >>> also >>> "Lifecycle of stateless and singleton session beans" [1]. >>> Tomas >>> Remes created WELD-2148 to track this issue [2]. >>> >>> Also the "leak" is an expected behaviour. See for example >>> WELD-920 >>> [3] discussion. >>> >>> Martin >>> >>> [1] >>> >>> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle >>> >>> [2] >>> https://issues.jboss.org/browse/WELD-2148 >>> >>> [3] >>> https://issues.jboss.org/browse/WELD-920 >>> >>> Dne 10.5.2016 v 17:11 arjan tijms napsal(a): >>> >>> Hi, >>> >>> Given a simple @Stateless bean: >>> >>> @Stateless >>> public class Foo { >>> public void bar() {} >>> } >>> >>> Then requesting an instance of this via CDI as follows: >>> >>> Foo foo = CDI.current().select(Foo.class).get(); >>> >>> Causes a lot of leaked proxy instances (at least on >>> Weld). Now >>> what I >>> guess needs to be done is destroying the proxy, taking >>> Antoine's >>> answer >>> here as a lead: >>> >>> http://stackoverflow.com/questions/28767536/scope-of-stateless-bean >>> >>> Only the following throws an >>> UnsupportedOperationException (on Weld >>> 2.3.2, haven't tested OWB yet) >>> >>> Instance fooInstance >>> =CDI.current().select(Foo.class); >>> Foo foo = fooInstance.get(); >>> foo.bar(); >>> fooInstance.destroy(foo); >>> >>> The question is, is this how it's supposed to be done >>> via the spec? >>> >>> Implementation wise, what happens in Weld is that the >>> CDI/EJB proxy >>> (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the >>> following code >>> doesn't hit the check for a dependent instance >>> (comments in capitals >>> added by me): >>> >>> >>> public void destroy(T instance) { >>> Preconditions.checkNotNull(instance); >>> >>> // check if this is a proxy of a >>> normal-scoped bean >>> if (instance instanceof ProxyObject) { >>> >>> // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY >>> >>> ProxyObject proxy = (ProxyObject) >>> instance; >>> if (proxy.getHandler() instanceof >>> ProxyMethodHandler) { >>> ProxyMethodHandler handler = >>> (ProxyMethodHandler) >>> proxy.getHandler(); >>> Bean bean = handler.getBean(); >>> Context context = >>> getBeanManager().getContext(bean.getScope()); >>> if (context instanceof >>> AlterableContext) { >>> AlterableContext alterableContext >>> = >>> (AlterableContext) context; >>> >>> // CONTEXT IS A >>> DEPENDENTCONTEXTIMPL THAT >>> THROWS >>> // UnsupportedOperationException >>> FROM ITS >>> DESTROY() >>> METHOD >>> alterableContext.destroy(bean); >>> return; >>> } else { >>> throw >>> BeanLogger.LOG.destroyUnsupported(context); >>> } >>> } >>> } >>> >>> // check if this is a dependent instance >>> CreationalContext ctx = >>> getCreationalContext(); >>> if (ctx instanceof WeldCreationalContext) { >>> WeldCreationalContext weldCtx >>> = cast(ctx); >>> >>> // PROXY REFERENCES ARE KEPT HERE IN A >>> // "dependentInstances" LIST, AND WOULD >>> BE CLEARED >>> HERE >>> // BUT THIS CODE IS NEVER REACHED >>> >>> weldCtx.destroyDependentInstance(instance); >>> } >>> } >>> >>> Now I wonder, am I doing something wrong (according to >>> the CDI >>> spec), or >>> could this be a bug in the Weld code? >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> >> >> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the >>> provider >>> licenses the code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.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 >>> >>> >>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic >>> >>> >>> >> -- >> 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/20160511/d594c1aa/attachment-0001.html From mkouba at redhat.com Wed May 11 07:04:56 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 11 May 2016 13:04:56 +0200 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: References: <5732DB1A.1060505@redhat.com> <5732F32C.9000202@redhat.com> <5732FEC8.4000208@redhat.com> Message-ID: <573311D8.6080206@redhat.com> Dne 11.5.2016 v 11:56 arjan tijms napsal(a): > Hi, > > On Wed, May 11, 2016 at 11:43 AM, Martin Kouba > wrote: > > I don't think so. Remember that Instace is more like a "factory" and > not only for @Dependent objects. What would actually close() do? > > > I'd intuitively say release and where appropriate destroy all beans that > were created from that particular instance of uhm Instance. But maybe > the existing semantics of Instance aren't a good fit for that. > > Thinking out loud, maybe an AutoInstance variant? > > try (AutoInstance fooInstance = CDI.current().autoSelect(Foo.class)) { > > Foo foo = fooInstance.get(); > foo.bar(); > } Well, I'm not sure it's worth adding a new interface + method in CDI API if the only purpose is to call Instance.destroy() (or possibly release() - see cdi/pull/286) automatically. Even now it's possible to have a wrapper/helper class for this, e.g. something like: class AutoDestroyable implements AutoCloseable { static AutoDestroyable from(Instance instance) { return new AutoDestroyable(instance); } private final Instance instance; private final T value; private AutoDestroyable(Instance instance) { this.instance = instance; this.value = instance.get(); } T get() { return value; } void close() { instance.destroy(value); } } try (AutoDestroyable destroyableFoo = AutoDestroyable.from(CDI.current().select(Foo.class))) { Foo foo = destroyableFoo.get(); foo.bar(); } > > autoSelect could even throw early if the selected bean is not dependent > scoped. But as mentioned, just thinking out loud here. > > Kind regards, > Arjan Tijms > > > > Also the users would be tempted to use this for injected Instance > which does not make sense. > > > try (Instance fooInstance =CDI.current().select(Foo.class)) { > > Foo foo = fooInstance.get(); > foo.bar(); > } > > Kind regards, > Arjan Tijms > > > > > Martin > > Dne 11.5.2016 v 10:40 arjan tijms napsal(a): > > Hi Martin, > > Thanks for the swift action and the reference. I do > have one more > question looking at the test that was added. It now > uses this SLSB: > > @Stateless > public class SLSessionBean { > > public void ping(){ > } > > static final AtomicBoolean DESTROYED = new > AtomicBoolean(); > > @PreDestroy > public void destroy() { > DESTROYED.set(true); > } > } > > The assertion in the test is that the (a?) SLSB is actually > destroyed, > but wasn't the idea that only the internal reference is > destroyed, and > the bean just stays in the pool? > > Here it looks like the code intends to destroy a random > SLSB > instance > from the pool. (random, since I guess an internal > reference doesn't > stick to the same actual instance of a SLSB, otherwise > you would get > stateful like semantics). > > Or did I miss something? > > Kind regards, > Arjan Tijms > > > > > On Wed, May 11, 2016 at 9:11 AM, Martin Kouba > > > > > >>> wrote: > > Hi Arjan, > > I believe it's a Weld bug - you should be able to use > Instance.destroy() to discard an internal SLSB > proxy. See also > "Lifecycle of stateless and singleton session > beans" [1]. Tomas > Remes created WELD-2148 to track this issue [2]. > > Also the "leak" is an expected behaviour. See for > example > WELD-920 > [3] discussion. > > Martin > > [1] > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle > > [2] > https://issues.jboss.org/browse/WELD-2148 > > [3] > https://issues.jboss.org/browse/WELD-920 > > Dne 10.5.2016 v 17:11 arjan tijms napsal(a): > > Hi, > > Given a simple @Stateless bean: > > @Stateless > public class Foo { > public void bar() {} > } > > Then requesting an instance of this via CDI as > follows: > > Foo foo = CDI.current().select(Foo.class).get(); > > Causes a lot of leaked proxy instances (at > least on > Weld). Now > what I > guess needs to be done is destroying the > proxy, taking > Antoine's > answer > here as a lead: > http://stackoverflow.com/questions/28767536/scope-of-stateless-bean > > Only the following throws an > UnsupportedOperationException (on Weld > 2.3.2, haven't tested OWB yet) > > Instance fooInstance > =CDI.current().select(Foo.class); > Foo foo = fooInstance.get(); > foo.bar(); > fooInstance.destroy(foo); > > The question is, is this how it's supposed to > be done > via the spec? > > Implementation wise, what happens in Weld is > that the > CDI/EJB proxy > (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) > in the > following code > doesn't hit the check for a dependent instance > (comments in capitals > added by me): > > > public void destroy(T instance) { > Preconditions.checkNotNull(instance); > > // check if this is a proxy of a > normal-scoped bean > if (instance instanceof ProxyObject) { > > // THIS BRANCH IS TAKEN FOR > CDI/EJB PROXY > > ProxyObject proxy = > (ProxyObject) instance; > if (proxy.getHandler() instanceof > ProxyMethodHandler) { > ProxyMethodHandler handler = > (ProxyMethodHandler) > proxy.getHandler(); > Bean bean = > handler.getBean(); > Context context = > getBeanManager().getContext(bean.getScope()); > if (context instanceof > AlterableContext) { > AlterableContext > alterableContext = > (AlterableContext) context; > > // CONTEXT IS A > DEPENDENTCONTEXTIMPL THAT > THROWS > // > UnsupportedOperationException > FROM ITS > DESTROY() > METHOD > > alterableContext.destroy(bean); > return; > } else { > throw > BeanLogger.LOG.destroyUnsupported(context); > } > } > } > > // check if this is a dependent instance > CreationalContext ctx = > getCreationalContext(); > if (ctx instanceof > WeldCreationalContext) { > WeldCreationalContext > weldCtx > = cast(ctx); > > // PROXY REFERENCES ARE KEPT > HERE IN A > // "dependentInstances" LIST, > AND WOULD > BE CLEARED > HERE > // BUT THIS CODE IS NEVER REACHED > > weldCtx.destroyDependentInstance(instance); > } > } > > Now I wonder, am I doing something wrong > (according to > the CDI > spec), or > could this be a bug in the Weld code? > > Kind regards, > Arjan Tijms > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > > > >> > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, > the provider > licenses the code under the Apache License, > Version 2 > > (http://www.apache.org/licenses/LICENSE-2.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 > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > > -- Martin Kouba Software Engineer Red Hat, Czech Republic From john.d.ament at gmail.com Wed May 11 20:49:32 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 12 May 2016 00:49:32 +0000 Subject: [cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select() In-Reply-To: <573311D8.6080206@redhat.com> References: <5732DB1A.1060505@redhat.com> <5732F32C.9000202@redhat.com> <5732FEC8.4000208@redhat.com> <573311D8.6080206@redhat.com> Message-ID: On Wed, May 11, 2016 at 7:05 AM Martin Kouba wrote: > Dne 11.5.2016 v 11:56 arjan tijms napsal(a): > > Hi, > > > > On Wed, May 11, 2016 at 11:43 AM, Martin Kouba > > wrote: > > > > I don't think so. Remember that Instace is more like a "factory" and > > not only for @Dependent objects. What would actually close() do? > > > > > > I'd intuitively say release and where appropriate destroy all beans that > > were created from that particular instance of uhm Instance. But maybe > > the existing semantics of Instance aren't a good fit for that. > > > > Thinking out loud, maybe an AutoInstance variant? > > > > try (AutoInstance fooInstance = > CDI.current().autoSelect(Foo.class)) { > > > > Foo foo = fooInstance.get(); > > foo.bar(); > > } > > Well, I'm not sure it's worth adding a new interface + method in CDI API > if the only purpose is to call Instance.destroy() (or possibly release() > - see cdi/pull/286) automatically. > > Even now it's possible to have a wrapper/helper class for this, e.g. > something like: > > class AutoDestroyable implements AutoCloseable { > > static AutoDestroyable from(Instance instance) { > return new AutoDestroyable(instance); > } > > private final Instance instance; > > private final T value; > > private AutoDestroyable(Instance instance) { > this.instance = instance; > this.value = instance.get(); > } > > T get() { > return value; > } > > void close() { > instance.destroy(value); > } > > } > > try (AutoDestroyable destroyableFoo = > AutoDestroyable.from(CDI.current().select(Foo.class))) { > Foo foo = destroyableFoo.get(); > foo.bar(); > } > > To accomplish this without a spec change, means that essentially every app in the world needs this utility. Its more scalable to write the fix once and get it in the spec. > > > > autoSelect could even throw early if the selected bean is not dependent > > scoped. But as mentioned, just thinking out loud here. > > > > Kind regards, > > Arjan Tijms > > > > > > > > Also the users would be tempted to use this for injected Instance > > which does not make sense. > > > > > > try (Instance fooInstance =CDI.current().select(Foo.class)) > { > > > > Foo foo = fooInstance.get(); > > foo.bar(); > > } > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > Martin > > > > Dne 11.5.2016 v 10:40 arjan tijms napsal(a): > > > > Hi Martin, > > > > Thanks for the swift action and the reference. I do > > have one more > > question looking at the test that was added. It now > > uses this SLSB: > > > > @Stateless > > public class SLSessionBean { > > > > public void ping(){ > > } > > > > static final AtomicBoolean DESTROYED = new > > AtomicBoolean(); > > > > @PreDestroy > > public void destroy() { > > DESTROYED.set(true); > > } > > } > > > > The assertion in the test is that the (a?) SLSB is > actually > > destroyed, > > but wasn't the idea that only the internal reference is > > destroyed, and > > the bean just stays in the pool? > > > > Here it looks like the code intends to destroy a random > > SLSB > > instance > > from the pool. (random, since I guess an internal > > reference doesn't > > stick to the same actual instance of a SLSB, otherwise > > you would get > > stateful like semantics). > > > > Or did I miss something? > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > On Wed, May 11, 2016 at 9:11 AM, Martin Kouba > > > > > > > > > >>> wrote: > > > > Hi Arjan, > > > > I believe it's a Weld bug - you should be able to > use > > Instance.destroy() to discard an internal SLSB > > proxy. See also > > "Lifecycle of stateless and singleton session > > beans" [1]. Tomas > > Remes created WELD-2148 to track this issue [2]. > > > > Also the "leak" is an expected behaviour. See for > > example > > WELD-920 > > [3] discussion. > > > > Martin > > > > [1] > > > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle > > > > [2] > > https://issues.jboss.org/browse/WELD-2148 > > > > [3] > > https://issues.jboss.org/browse/WELD-920 > > > > Dne 10.5.2016 v 17:11 arjan tijms napsal(a): > > > > Hi, > > > > Given a simple @Stateless bean: > > > > @Stateless > > public class Foo { > > public void bar() {} > > } > > > > Then requesting an instance of this via CDI as > > follows: > > > > Foo foo = > CDI.current().select(Foo.class).get(); > > > > Causes a lot of leaked proxy instances (at > > least on > > Weld). Now > > what I > > guess needs to be done is destroying the > > proxy, taking > > Antoine's > > answer > > here as a lead: > > > http://stackoverflow.com/questions/28767536/scope-of-stateless-bean > > > > Only the following throws an > > UnsupportedOperationException (on Weld > > 2.3.2, haven't tested OWB yet) > > > > Instance fooInstance > > =CDI.current().select(Foo.class); > > Foo foo = fooInstance.get(); > > foo.bar(); > > fooInstance.destroy(foo); > > > > The question is, is this how it's supposed to > > be done > > via the spec? > > > > Implementation wise, what happens in Weld is > > that the > > CDI/EJB proxy > > (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) > > in the > > following code > > doesn't hit the check for a dependent instance > > (comments in capitals > > added by me): > > > > > > public void destroy(T instance) { > > Preconditions.checkNotNull(instance); > > > > // check if this is a proxy of a > > normal-scoped bean > > if (instance instanceof ProxyObject) > { > > > > // THIS BRANCH IS TAKEN FOR > > CDI/EJB PROXY > > > > ProxyObject proxy = > > (ProxyObject) instance; > > if (proxy.getHandler() instanceof > > ProxyMethodHandler) { > > ProxyMethodHandler handler = > > (ProxyMethodHandler) > > proxy.getHandler(); > > Bean bean = > > handler.getBean(); > > Context context = > > getBeanManager().getContext(bean.getScope()); > > if (context instanceof > > AlterableContext) { > > AlterableContext > > alterableContext = > > (AlterableContext) context; > > > > // CONTEXT IS A > > DEPENDENTCONTEXTIMPL THAT > > THROWS > > // > > UnsupportedOperationException > > FROM ITS > > DESTROY() > > METHOD > > > > alterableContext.destroy(bean); > > return; > > } else { > > throw > > BeanLogger.LOG.destroyUnsupported(context); > > } > > } > > } > > > > // check if this is a dependent > instance > > CreationalContext ctx = > > getCreationalContext(); > > if (ctx instanceof > > WeldCreationalContext) { > > WeldCreationalContext > > weldCtx > > = cast(ctx); > > > > // PROXY REFERENCES ARE KEPT > > HERE IN A > > // "dependentInstances" LIST, > > AND WOULD > > BE CLEARED > > HERE > > // BUT THIS CODE IS NEVER REACHED > > > > weldCtx.destroyDependentInstance(instance); > > } > > } > > > > Now I wonder, am I doing something wrong > > (according to > > the CDI > > spec), or > > could this be a bug in the Weld code? > > > > Kind regards, > > Arjan Tijms > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > >> > > > > >> > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, > > the provider > > licenses the code under the Apache License, > > Version 2 > > > > (http://www.apache.org/licenses/LICENSE-2.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 > > > > > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > > > > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > > > > > -- > 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/20160512/0eae9af6/attachment-0001.html From issues at jboss.org Fri May 13 20:37:00 2016 From: issues at jboss.org (Michael Remijan (JIRA)) Date: Fri, 13 May 2016 20:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237709#comment-13237709 ] Michael Remijan commented on CDI-573: ------------------------------------- Hi Antonie. If I read these comments correctly, will CDI.getCDIProvider() visibility be back to public in Weld 3.0.0.Alpha17? Because I just tried updating to Weld 3.0.0.Alpha16 and ran into getCDIProvider() no longer being visible. Thanks! > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri May 13 20:37:00 2016 From: issues at jboss.org (Michael Remijan (JIRA)) Date: Fri, 13 May 2016 20:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237709#comment-13237709 ] Michael Remijan edited comment on CDI-573 at 5/13/16 8:36 PM: -------------------------------------------------------------- Hi Antoine. If I read these comments correctly, will CDI.getCDIProvider() visibility be back to public in Weld 3.0.0.Alpha17? Because I just tried updating to Weld 3.0.0.Alpha16 and ran into getCDIProvider() no longer being visible. Thanks! was (Author: mjremijan): Hi Antonie. If I read these comments correctly, will CDI.getCDIProvider() visibility be back to public in Weld 3.0.0.Alpha17? Because I just tried updating to Weld 3.0.0.Alpha16 and ran into getCDIProvider() no longer being visible. Thanks! > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.d.ament at gmail.com Sun May 15 10:14:42 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 15 May 2016 14:14:42 +0000 Subject: [cdi-dev] Managing Dependent Scoped Beans Message-ID: Hey guys Seems like we have some issues in JIRA all focused on managing the lifecycle of Dependent scoped beans. It also seems like we have many differing opinions about how to manage them. - Martin raised a PR to add a release() method to Instance to help destroy a dependent bean https://github.com/cdi-spec/cdi/pull/286 - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to update the spec to clarify how to manage a dependent scoped bean. Right now, it seems that the big disagreement is whether Instance.destroy() can destroy objects not created by it (the case being around the CDI utility class, being an impl of Instance). I'm currently heavily against Martin's proposed changes, but want to get input from others on the group to understand their perspective. - Does the spec require destroy() to be called only on instances that it created? When I read 5.6.1 the only requirement I see is that it has to be a dependent scoped bean. Note when I ask this I'm asking from the spec perspective, its a different problem if there's some issues with implementations following suite (I would imagine there needs to be some shared global registry of dependent scoped beans for this to work). - Do we want two methods that effectively do the same thing? I don't see a strong difference between the two. On the flipside, my change is more a spec clarification. I'm thinking more now that it belongs as a reword of 5.6.1 to clarify how to use destroy() on dependent beans, rather than where I put it. I think realistically we have all of the tools needed to manage the lifecycle of these classes, just need to clarify them for people to use. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160515/1e117add/attachment.html From issues at jboss.org Sun May 15 10:57:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 15 May 2016 10:57:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-30) An API for managing built in contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament reassigned CDI-30: ----------------------------- Assignee: John Ament > An API for managing built in contexts > ------------------------------------- > > Key: CDI-30 > URL: https://issues.jboss.org/browse/CDI-30 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Assignee: John Ament > Fix For: 2.0 (discussion) > > > Add management API for built in contexts allowing them to be reused as needed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun May 15 10:57:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 15 May 2016 10:57:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-30) An API for managing built in contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-30 started by John Ament. ------------------------------------- > An API for managing built in contexts > ------------------------------------- > > Key: CDI-30 > URL: https://issues.jboss.org/browse/CDI-30 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Assignee: John Ament > Fix For: 2.0 (discussion) > > > Add management API for built in contexts allowing them to be reused as needed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From rmannibucau at gmail.com Sun May 15 11:05:02 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 15 May 2016 17:05:02 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: Message-ID: Hi Jon Le 15 mai 2016 16:15, "John D. Ament" a ?crit : > > Hey guys > > Seems like we have some issues in JIRA all focused on managing the lifecycle of Dependent scoped beans. It also seems like we have many differing opinions about how to manage them. > > - Martin raised a PR to add a release() method to Instance to help destroy a dependent bean https://github.com/cdi-spec/cdi/pull/286 > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to update the spec to clarify how to manage a dependent scoped bean. > > Right now, it seems that the big disagreement is whether Instance.destroy() can destroy objects not created by it (the case being around the CDI utility class, being an impl of Instance). I'm currently heavily against Martin's proposed changes, but want to get input from others on the group to understand their perspective. > > - Does the spec require destroy() to be called only on instances that it created? When I read 5.6.1 the only requirement I see is that it has to be a dependent scoped bean. Note when I ask this I'm asking from the spec perspective, its a different problem if there's some issues with implementations following suite (I would imagine there needs to be some shared global registry of dependent scoped beans for this to work). > Sound the only clean impl. Any other is not symmetric and potentially lead to "oops this time it didnt work". I also not seeing any use case limitation with that so think it is the same solution > - Do we want two methods that effectively do the same thing? I don't see a strong difference between the two. > > On the flipside, my change is more a spec clarification. I'm thinking more now that it belongs as a reword of 5.6.1 to clarify how to use destroy() on dependent beans, rather than where I put it. I think realistically we have all of the tools needed to manage the lifecycle of these classes, just need to clarify them for people to use. > > John > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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/20160515/f4a6b562/attachment.html From john.d.ament at gmail.com Sun May 15 11:14:21 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 15 May 2016 15:14:21 +0000 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: Message-ID: Romain, On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau wrote: > Hi Jon > > Le 15 mai 2016 16:15, "John D. Ament" a ?crit : > > > > Hey guys > > > > Seems like we have some issues in JIRA all focused on managing the > lifecycle of Dependent scoped beans. It also seems like we have many > differing opinions about how to manage them. > > > > - Martin raised a PR to add a release() method to Instance to help > destroy a dependent bean https://github.com/cdi-spec/cdi/pull/286 > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to update the > spec to clarify how to manage a dependent scoped bean. > > > > Right now, it seems that the big disagreement is whether > Instance.destroy() can destroy objects not created by it (the case being > around the CDI utility class, being an impl of Instance). I'm currently > heavily against Martin's proposed changes, but want to get input from > others on the group to understand their perspective. > > > > - Does the spec require destroy() to be called only on instances that it > created? When I read 5.6.1 the only requirement I see is that it has to be > a dependent scoped bean. Note when I ask this I'm asking from the spec > perspective, its a different problem if there's some issues with > implementations following suite (I would imagine there needs to be some > shared global registry of dependent scoped beans for this to work). > > > > Sound the only clean impl. Any other is not symmetric and potentially lead > to "oops this time it didnt work". I also not seeing any use case > limitation with that so think it is the same solution > I'm not sure I follow or if this isn't an answer to "Does the spec require destroy() to be called only on instances that it created?" ? Anyways I did look a bit closer and it seems that Martin's statement is consistent with how OWB works, https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293 so I wonder if there's a part of the spec I'm missing, or if there was some offline agreement on how to understand it. John > > - Do we want two methods that effectively do the same thing? I don't > see a strong difference between the two. > > > > On the flipside, my change is more a spec clarification. I'm thinking > more now that it belongs as a reword of 5.6.1 to clarify how to use > destroy() on dependent beans, rather than where I put it. I think > realistically we have all of the tools needed to manage the lifecycle of > these classes, just need to clarify them for people to use. > > > > John > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160515/2e915168/attachment-0001.html From rmannibucau at gmail.com Sun May 15 12:29:23 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 15 May 2016 18:29:23 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: Message-ID: Was to the fact destroy should be used with the relative instance only and unspecified with an unkown instance - we have both behaviors in impl AFAIK so not sure we can break users specifying it now. Le 15 mai 2016 17:14, "John D. Ament" a ?crit : > Romain, > > On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau > wrote: > >> Hi Jon >> >> Le 15 mai 2016 16:15, "John D. Ament" a ?crit : >> > >> > Hey guys >> > >> > Seems like we have some issues in JIRA all focused on managing the >> lifecycle of Dependent scoped beans. It also seems like we have many >> differing opinions about how to manage them. >> > >> > - Martin raised a PR to add a release() method to Instance to help >> destroy a dependent bean https://github.com/cdi-spec/cdi/pull/286 >> > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to update the >> spec to clarify how to manage a dependent scoped bean. >> > >> > Right now, it seems that the big disagreement is whether >> Instance.destroy() can destroy objects not created by it (the case being >> around the CDI utility class, being an impl of Instance). I'm currently >> heavily against Martin's proposed changes, but want to get input from >> others on the group to understand their perspective. >> > >> > - Does the spec require destroy() to be called only on instances that >> it created? When I read 5.6.1 the only requirement I see is that it has to >> be a dependent scoped bean. Note when I ask this I'm asking from the spec >> perspective, its a different problem if there's some issues with >> implementations following suite (I would imagine there needs to be some >> shared global registry of dependent scoped beans for this to work). >> > >> >> Sound the only clean impl. Any other is not symmetric and potentially >> lead to "oops this time it didnt work". I also not seeing any use case >> limitation with that so think it is the same solution >> > > I'm not sure I follow or if this isn't an answer to "Does the spec require > destroy() to be called only on instances that it created?" ? > > Anyways I did look a bit closer and it seems that Martin's statement is > consistent with how OWB works, > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293 so > I wonder if there's a part of the spec I'm missing, or if there was some > offline agreement on how to understand it. > > John > > >> > - Do we want two methods that effectively do the same thing? I don't >> see a strong difference between the two. >> > >> > On the flipside, my change is more a spec clarification. I'm thinking >> more now that it belongs as a reword of 5.6.1 to clarify how to use >> destroy() on dependent beans, rather than where I put it. I think >> realistically we have all of the tools needed to manage the lifecycle of >> these classes, just need to clarify them for people to use. >> > >> > John >> > >> >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.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/20160515/46e531a5/attachment.html From john.d.ament at gmail.com Sun May 15 12:33:58 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 15 May 2016 16:33:58 +0000 Subject: [cdi-dev] API Only PR for Context management Message-ID: All, I've started a PR for API changes to support starting/stopping the built in contexts, which you can find here: https://github.com/cdi-spec/cdi/pull/291/files It's visibly based on what is in DeltaSpike's CDI Ctrl plus some of the external stuff (e.g. https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/api/src/main/java/org/apache/deltaspike/scheduler/api/Scheduled.java#L40 ) so I'd like to get some input. I don't suspect that this will be an SE only feature, today I use programmatic context starting even while on an app server. Even though I'm not using whats provided in DS, it was identified as a clear cross cutting concern hence why there's an interceptor as well. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160515/0d4198f6/attachment.html From issues at jboss.org Sun May 15 15:35:00 2016 From: issues at jboss.org (arjan tijms (JIRA)) Date: Sun, 15 May 2016 15:35:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-30) An API for managing built in contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237840#comment-13237840 ] arjan tijms commented on CDI-30: -------------------------------- [~meetoblivion] [First PR|https://github.com/cdi-spec/cdi/pull/291/files] looks good! Would it be an idea to set a wrapped (or decorated) context controller? What I'm looking for is a way to start contexts possibly earlier than a specific container implementation normally starts them, and stop them possibly later. If the context is started earlier in say a request, then eventually the container will also start that same context later in the request. If that will throw an exception the request will not proceed, which is of course not intended. Likewise, when the container stops the context this will thus be too early. With a wrapped context controller, the {{startContexts}} and {{stopContexts}} calls can be ignored for those contexts the application (extension/library) wanted to start earlier and stop later. This does of course assume that the container itself will also use this context controller instead of the current proprietary code. Additionally, the PR does not contain the check anymore to see if the context is already active or already stopped. Is that still intended to be added? This would be particularly useful for code that needs to be portable between different containers, where one container may already have started the context at a given point, where another container has not (catching the exception would be an alternative here but is obviously not so nice). Another point, what about letting the caller of the {{startContexts}} method optionally pass in the objects (or a lambda to obtain them) on which that context primarily depends (if any). E.g. for the request scope, pass in an {{HttpServletRequest}} instance. > An API for managing built in contexts > ------------------------------------- > > Key: CDI-30 > URL: https://issues.jboss.org/browse/CDI-30 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Assignee: John Ament > Fix For: 2.0 (discussion) > > > Add management API for built in contexts allowing them to be reused as needed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun May 15 17:56:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 15 May 2016 17:56:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-30) An API for managing built in contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237841#comment-13237841 ] John Ament commented on CDI-30: ------------------------------- HI Arjan, I always find it easier to discuss on ML's but will try to answer you here. I think what you're asking for is to intercept at the container level and change how they initialize. I'm curious, under what cases do you not have an active request? In addition, I think you're looking for the equivalent of {{Context.isActive}}. Part of me even wonders if swapping around the impl to be {{Context.activate()}} and {{Context.deactivate()}} may be better from a domain standpoint. > An API for managing built in contexts > ------------------------------------- > > Key: CDI-30 > URL: https://issues.jboss.org/browse/CDI-30 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Assignee: John Ament > Fix For: 2.0 (discussion) > > > Add management API for built in contexts allowing them to be reused as needed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Mon May 16 03:54:51 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 16 May 2016 09:54:51 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: Message-ID: <57397CCB.90101@redhat.com> Dne 15.5.2016 v 17:14 John D. Ament napsal(a): > Romain, > > On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau > > wrote: > > Hi Jon > > Le 15 mai 2016 16:15, "John D. Ament" > a ?crit : > > > > Hey guys > > > > Seems like we have some issues in JIRA all focused on managing > the lifecycle of Dependent scoped beans. It also seems like we have > many differing opinions about how to manage them. > > > > - Martin raised a PR to add a release() method to Instance to > help destroy a dependent bean https://github.com/cdi-spec/cdi/pull/286 > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to > update the spec to clarify how to manage a dependent scoped bean. > > > > Right now, it seems that the big disagreement is whether > Instance.destroy() can destroy objects not created by it (the case > being around the CDI utility class, being an impl of Instance). I'm > currently heavily against Martin's proposed changes, but want to get > input from others on the group to understand their perspective. > > > > - Does the spec require destroy() to be called only on instances > that it created? When I read 5.6.1 the only requirement I see is > that it has to be a dependent scoped bean. Note when I ask this I'm > asking from the spec perspective, its a different problem if there's > some issues with implementations following suite (I would imagine > there needs to be some shared global registry of dependent scoped > beans for this to work). > > > > Sound the only clean impl. Any other is not symmetric and > potentially lead to "oops this time it didnt work". I also not > seeing any use case limitation with that so think it is the same > solution > > > I'm not sure I follow or if this isn't an answer to "Does the spec > require destroy() to be called only on instances that it created?" ? > > Anyways I did look a bit closer and it seems that Martin's statement is > consistent with how OWB works, > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293 so > I wonder if there's a part of the spec I'm missing, or if there was some > offline agreement on how to understand it. John, I believe Instance CANNOT be used to destroy a dependent bean instance it didn't created, because a dependent bean instance doesn't know the dependent objects it depends on - that's what CreationalContext is for. So if you pass any dependent instance to Instance.destroy() there is no CreationalContext apart from the one Instance<> has. In other words you wouldn't be able to destroy the @Dependent dependencies of a @Dependent bean instane. Does it make sense? See also https://issues.jboss.org/browse/CDI-519 (cdi-spec/cdi/pull/278 is already merged). > > John > > > - Do we want two methods that effectively do the same thing? I > don't see a strong difference between the two. > > > > On the flipside, my change is more a spec clarification. I'm > thinking more now that it belongs as a reword of 5.6.1 to clarify > how to use destroy() on dependent beans, rather than where I put > it. I think realistically we have all of the tools needed to manage > the lifecycle of these classes, just need to clarify them for people > to use. > > > > John > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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 mkouba at redhat.com Mon May 16 04:01:07 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 16 May 2016 10:01:07 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: Message-ID: <57397E43.9050708@redhat.com> Dne 15.5.2016 v 16:14 John D. Ament napsal(a): > Hey guys > > Seems like we have some issues in JIRA all focused on managing the > lifecycle of Dependent scoped beans. It also seems like we have many > differing opinions about how to manage them. > > - Martin raised a PR to add a release() method to Instance to help > destroy a dependent bean https://github.com/cdi-spec/cdi/pull/286 > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to update the > spec to clarify how to manage a dependent scoped bean. > > Right now, it seems that the big disagreement is whether > Instance.destroy() can destroy objects not created by it (the case being > around the CDI utility class, being an impl of Instance). I'm currently > heavily against Martin's proposed changes, but want to get input from > others on the group to understand their perspective. > > - Does the spec require destroy() to be called only on instances that it > created? When I read 5.6.1 the only requirement I see is that it has to > be a dependent scoped bean. Note when I ask this I'm asking from the > spec perspective, its a different problem if there's some issues with > implementations following suite (I would imagine there needs to be some > shared global registry of dependent scoped beans for this to work). > > - Do we want two methods that effectively do the same thing? I don't > see a strong difference between the two. Instance.destroy() currently always destroys the contextual instance. Which is not always what users expect. That's why I proposed to add Instance.release() - https://github.com/cdi-spec/cdi/pull/286, previously Instance.getBean() - https://github.com/cdi-spec/cdi/pull/273. > > On the flipside, my change is more a spec clarification. I'm thinking > more now that it belongs as a reword of 5.6.1 to clarify how to use > destroy() on dependent beans, rather than where I put it. I think > realistically we have all of the tools needed to manage the lifecycle of > these classes, just need to clarify them for people to use. > > John > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Mon May 16 04:15:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 16 May 2016 04:15:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: Martin Kouba created CDI-601: -------------------------------- Summary: Add container lifecycle event fired before container destroys all contexts Key: CDI-601 URL: https://issues.jboss.org/browse/CDI-601 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Martin Kouba The name might be something like `BeforeContainerShutdown`. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon May 16 04:16:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 16 May 2016 04:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-601: ----------------------------- Fix Version/s: 2.0 (discussion) > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like `BeforeContainerShutdown`. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon May 16 04:16:00 2016 From: issues at jboss.org (Jive JIRA Integration (JIRA)) Date: Mon, 16 May 2016 04:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jive JIRA Integration updated CDI-601: -------------------------------------- Forum Reference: https://developer.jboss.org/message/956205#956205 > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like `BeforeContainerShutdown`. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From rmannibucau at gmail.com Mon May 16 04:20:26 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 16 May 2016 10:20:26 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: <57397E43.9050708@redhat.com> Message-ID: Le 16 mai 2016 10:01, "Martin Kouba" a ?crit : > > Dne 15.5.2016 v 16:14 John D. Ament napsal(a): > > Hey guys > > > > Seems like we have some issues in JIRA all focused on managing the > > lifecycle of Dependent scoped beans. It also seems like we have many > > differing opinions about how to manage them. > > > > - Martin raised a PR to add a release() method to Instance to help > > destroy a dependent bean https://github.com/cdi-spec/cdi/pull/286 > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to update the > > spec to clarify how to manage a dependent scoped bean. > > > > Right now, it seems that the big disagreement is whether > > Instance.destroy() can destroy objects not created by it (the case being > > around the CDI utility class, being an impl of Instance). I'm currently > > heavily against Martin's proposed changes, but want to get input from > > others on the group to understand their perspective. > > > > - Does the spec require destroy() to be called only on instances that it > > created? When I read 5.6.1 the only requirement I see is that it has to > > be a dependent scoped bean. Note when I ask this I'm asking from the > > spec perspective, its a different problem if there's some issues with > > implementations following suite (I would imagine there needs to be some > > shared global registry of dependent scoped beans for this to work). > > > > - Do we want two methods that effectively do the same thing? I don't > > see a strong difference between the two. > > Instance.destroy() currently always destroys the contextual instance. > Which is not always what users expect. That's why I proposed to add > Instance.release() - https://github.com/cdi-spec/cdi/pull/286, > previously Instance.getBean() - https://github.com/cdi-spec/cdi/pull/273. > Since you give the instance to both I guess the intention from user point of view is obvious and then we dont need 2 methods. What would be the other use case? > > > > On the flipside, my change is more a spec clarification. I'm thinking > > more now that it belongs as a reword of 5.6.1 to clarify how to use > > destroy() on dependent beans, rather than where I put it. I think > > realistically we have all of the tools needed to manage the lifecycle of > > these classes, just need to clarify them for people to use. > > > > John > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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/20160516/d339c8b9/attachment.html From arjan.tijms at gmail.com Mon May 16 04:21:03 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 16 May 2016 10:21:03 +0200 Subject: [cdi-dev] API Only PR for Context management In-Reply-To: References: Message-ID: Hi, > I think what you're asking for is to intercept at the container level and > change how they initialize. I'm curious, under what cases do you not have > an active request? > My primary case is to compensate for container differences regarding a ServerAuthModule (JSR 196/JASPIC). Such ServerAuthModule is called before the first Servlet Filter is, and gets an HttpServletRequest passed in. In many servers (JBoss, GlassFish, TomEE) the CDI default scopes (request, session, etc) are active at that point, but not in all (Liberty, WebLogic). With this proposed API a library such as Soteria could possibly start those scopes earlier on Liberty and WebLogic and do nothing on JBoss, GlassFish and TomEE. Kind regards, Arjan Tijms > In addition, I think you're looking for the equivalent of > Context.isActive. Part of me even wonders if swapping around the impl to be > Context.activate() and Context.deactivate() may be better from a domain > standpoint. > > What I'm looking for is a way to start contexts possibly earlier than a >> specific container implementation normally starts them, and stop them >> possibly later. If the context is started earlier in say a request, then >> eventually the container will also start that same context later in the >> request. If that will throw an exception the request will not proceed, >> which is of course not intended. >> Likewise, when the container stops the context this will thus be too >> early. >> With a wrapped context controller, the startContexts and stopContexts >> calls can be ignored for those contexts the application (extension/library) >> wanted to start earlier and stop later. This does of course assume that the >> container itself will also use this context controller instead of the >> current proprietary code. >> Additionally, the PR does not contain the check anymore to see if the >> context is already active or already stopped. Is that still intended to be >> added? This would be particularly useful for code that needs to be portable >> between different containers, where one container may already have started >> the context at a given point, where another container has not (catching the >> exception would be an alternative here but is obviously not so nice). >> Another point, what about letting the caller of the startContexts method >> optionally pass in the objects (or a lambda to obtain them) on which that >> context primarily depends (if any). E.g. for the request scope, pass in an >> HttpServletRequest instance. > > Would it be an idea to set a wrapped (or decorated) context controller? > > On Sun, May 15, 2016 at 6:33 PM, John D. Ament > wrote: All, I've started a PR for API changes to support starting/stopping the built in > contexts, which you can find here: > https://github.com/cdi-spec/cdi/pull/291/files It's visibly based on what is in DeltaSpike's CDI Ctrl plus some of the > external stuff (e.g. > https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/api/src/main/java/org/apache/deltaspike/scheduler/api/Scheduled.java#L40 ) > so I'd like to get some input. I don't suspect that this will be an SE only feature, today I use > programmatic context starting even while on an app server. Even though I'm > not using whats provided in DS, it was identified as a clear cross cutting > concern hence why there's an interceptor as well. John _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160516/686b75f2/attachment-0001.html From mkouba at redhat.com Mon May 16 04:23:56 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 16 May 2016 10:23:56 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: <57397E43.9050708@redhat.com> Message-ID: <5739839C.7000406@redhat.com> Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a): > > Le 16 mai 2016 10:01, "Martin Kouba" > a ?crit : > > > > Dne 15.5.2016 v 16:14 John D. Ament napsal(a): > > > Hey guys > > > > > > Seems like we have some issues in JIRA all focused on managing the > > > lifecycle of Dependent scoped beans. It also seems like we have many > > > differing opinions about how to manage them. > > > > > > - Martin raised a PR to add a release() method to Instance to help > > > destroy a dependent bean https://github.com/cdi-spec/cdi/pull/286 > > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to update the > > > spec to clarify how to manage a dependent scoped bean. > > > > > > Right now, it seems that the big disagreement is whether > > > Instance.destroy() can destroy objects not created by it (the case > being > > > around the CDI utility class, being an impl of Instance). I'm > currently > > > heavily against Martin's proposed changes, but want to get input from > > > others on the group to understand their perspective. > > > > > > - Does the spec require destroy() to be called only on instances > that it > > > created? When I read 5.6.1 the only requirement I see is that it > has to > > > be a dependent scoped bean. Note when I ask this I'm asking from the > > > spec perspective, its a different problem if there's some issues with > > > implementations following suite (I would imagine there needs to be some > > > shared global registry of dependent scoped beans for this to work). > > > > > > - Do we want two methods that effectively do the same thing? I don't > > > see a strong difference between the two. > > > > Instance.destroy() currently always destroys the contextual instance. > > Which is not always what users expect. That's why I proposed to add > > Instance.release() - https://github.com/cdi-spec/cdi/pull/286, > > previously Instance.getBean() - https://github.com/cdi-spec/cdi/pull/273. > > > > Since you give the instance to both I guess the intention from user > point of view is obvious and then we dont need 2 methods. What would be > the other use case? https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614 > > > > > > > On the flipside, my change is more a spec clarification. I'm thinking > > > more now that it belongs as a reword of 5.6.1 to clarify how to use > > > destroy() on dependent beans, rather than where I put it. I think > > > realistically we have all of the tools needed to manage the > lifecycle of > > > these classes, just need to clarify them for people to use. > > > > > > John > > > > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From rmannibucau at gmail.com Mon May 16 04:36:14 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 16 May 2016 10:36:14 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: <5739839C.7000406@redhat.com> References: <57397E43.9050708@redhat.com> <5739839C.7000406@redhat.com> Message-ID: I see, thks. I dont like having 2 methods with the same semantic there but agree the default is misleading for such cases. 1. Cant we change the default? looks like current one can break apps if misunderstood and not sure changing it is worse. If not 2. Maybe we can type the returned type with a release method in the instance wrapper instead of enriching Instance API making it contextual by nature?: w=instance...get();w.getValue().work();w.release(/*no param*/); That is what most framework did finally to integrate with CDI so looks natural. Le 16 mai 2016 10:23, "Martin Kouba" a ?crit : > Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a): > >> >> Le 16 mai 2016 10:01, "Martin Kouba" > > a ?crit : >> > >> > Dne 15.5.2016 v 16:14 John D. Ament napsal(a): >> > > Hey guys >> > > >> > > Seems like we have some issues in JIRA all focused on managing the >> > > lifecycle of Dependent scoped beans. It also seems like we have many >> > > differing opinions about how to manage them. >> > > >> > > - Martin raised a PR to add a release() method to Instance to help >> > > destroy a dependent bean https://github.com/cdi-spec/cdi/pull/286 >> > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to update >> the >> > > spec to clarify how to manage a dependent scoped bean. >> > > >> > > Right now, it seems that the big disagreement is whether >> > > Instance.destroy() can destroy objects not created by it (the case >> being >> > > around the CDI utility class, being an impl of Instance). I'm >> currently >> > > heavily against Martin's proposed changes, but want to get input from >> > > others on the group to understand their perspective. >> > > >> > > - Does the spec require destroy() to be called only on instances >> that it >> > > created? When I read 5.6.1 the only requirement I see is that it >> has to >> > > be a dependent scoped bean. Note when I ask this I'm asking from the >> > > spec perspective, its a different problem if there's some issues with >> > > implementations following suite (I would imagine there needs to be >> some >> > > shared global registry of dependent scoped beans for this to work). >> > > >> > > - Do we want two methods that effectively do the same thing? I don't >> > > see a strong difference between the two. >> > >> > Instance.destroy() currently always destroys the contextual instance. >> > Which is not always what users expect. That's why I proposed to add >> > Instance.release() - https://github.com/cdi-spec/cdi/pull/286, >> > previously Instance.getBean() - >> https://github.com/cdi-spec/cdi/pull/273. >> > >> >> Since you give the instance to both I guess the intention from user >> point of view is obvious and then we dont need 2 methods. What would be >> the other use case? >> > > https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614 > > >> > > >> > > On the flipside, my change is more a spec clarification. I'm >> thinking >> > > more now that it belongs as a reword of 5.6.1 to clarify how to use >> > > destroy() on dependent beans, rather than where I put it. I think >> > > realistically we have all of the tools needed to manage the >> lifecycle of >> > > these classes, just need to clarify them for people to use. >> > > >> > > John >> > > >> > > >> > > _______________________________________________ >> > > cdi-dev mailing list >> > > cdi-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > >> > > Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.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. >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160516/f6f74ca7/attachment.html From mkouba at redhat.com Mon May 16 04:42:12 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 16 May 2016 10:42:12 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: <57397E43.9050708@redhat.com> <5739839C.7000406@redhat.com> Message-ID: <573987E4.1020405@redhat.com> Dne 16.5.2016 v 10:36 Romain Manni-Bucau napsal(a): > I see, thks. > > I dont like having 2 methods with the same semantic there but agree the > default is misleading for such cases. > > 1. Cant we change the default? looks like current one can break apps if > misunderstood and not sure changing it is worse. I think we cannot due to backward compatibility. > > If not > > 2. Maybe we can type the returned type with a release method in the > instance wrapper instead of enriching Instance API making it contextual > by nature?: w=instance...get();w.getValue().work();w.release(/*no param*/); Sorry, I don't get it. Do you want to change Instance.get() signature and return some kind of wrapper? A simple snippet might help. > > That is what most framework did finally to integrate with CDI so looks > natural. > > Le 16 mai 2016 10:23, "Martin Kouba" > a ?crit : > > Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a): > > > Le 16 mai 2016 10:01, "Martin Kouba" > >> a ?crit : > > > > Dne 15.5.2016 v 16:14 John D. Ament napsal(a): > > > Hey guys > > > > > > Seems like we have some issues in JIRA all focused on > managing the > > > lifecycle of Dependent scoped beans. It also seems like > we have many > > > differing opinions about how to manage them. > > > > > > - Martin raised a PR to add a release() method to Instance > to help > > > destroy a dependent bean > https://github.com/cdi-spec/cdi/pull/286 > > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 > to update the > > > spec to clarify how to manage a dependent scoped bean. > > > > > > Right now, it seems that the big disagreement is whether > > > Instance.destroy() can destroy objects not created by it > (the case > being > > > around the CDI utility class, being an impl of Instance). I'm > currently > > > heavily against Martin's proposed changes, but want to get > input from > > > others on the group to understand their perspective. > > > > > > - Does the spec require destroy() to be called only on > instances > that it > > > created? When I read 5.6.1 the only requirement I see is > that it > has to > > > be a dependent scoped bean. Note when I ask this I'm > asking from the > > > spec perspective, its a different problem if there's some > issues with > > > implementations following suite (I would imagine there > needs to be some > > > shared global registry of dependent scoped beans for this > to work). > > > > > > - Do we want two methods that effectively do the same > thing? I don't > > > see a strong difference between the two. > > > > Instance.destroy() currently always destroys the contextual > instance. > > Which is not always what users expect. That's why I proposed > to add > > Instance.release() - https://github.com/cdi-spec/cdi/pull/286, > > previously Instance.getBean() - > https://github.com/cdi-spec/cdi/pull/273. > > > > Since you give the instance to both I guess the intention from user > point of view is obvious and then we dont need 2 methods. What > would be > the other use case? > > > https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614 > > > > > > > > On the flipside, my change is more a spec clarification. > I'm thinking > > > more now that it belongs as a reword of 5.6.1 to clarify > how to use > > > destroy() on dependent beans, rather than where I put it. > I think > > > realistically we have all of the tools needed to manage the > lifecycle of > > > these classes, just need to clarify them for people to use. > > > > > > John > > > > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider > licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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. > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -- Martin Kouba Software Engineer Red Hat, Czech Republic From rmannibucau at gmail.com Mon May 16 05:08:49 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 16 May 2016 11:08:49 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: <57397E43.9050708@redhat.com> <5739839C.7000406@redhat.com> <573987E4.1020405@redhat.com> Message-ID: Le 16 mai 2016 10:42, "Martin Kouba" a ?crit : > > > > Dne 16.5.2016 v 10:36 Romain Manni-Bucau napsal(a): > >> I see, thks. >> >> I dont like having 2 methods with the same semantic there but agree the >> default is misleading for such cases. >> >> 1. Cant we change the default? looks like current one can break apps if >> misunderstood and not sure changing it is worse. > > > I think we cannot due to backward compatibility. > > >> >> If not >> >> 2. Maybe we can type the returned type with a release method in the >> instance wrapper instead of enriching Instance API making it contextual >> by nature?: w=instance...get();w.getValue().work();w.release(/*no param*/); > > > Sorry, I don't get it. Do you want to change Instance.get() signature and return some kind of wrapper? A simple snippet might help. > Yes get a method to have the wrapper to manage a single instance: @Inject Instance i; ... Wrapper w = i.getSelected(); ... w.getValue().businessmetd(); ... w.release(); >> >> That is what most framework did finally to integrate with CDI so looks >> natural. >> >> Le 16 mai 2016 10:23, "Martin Kouba" > > a ?crit : >> >> Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a): >> >> >> Le 16 mai 2016 10:01, "Martin Kouba" > >> >> a ?crit : >> >> > >> > Dne 15.5.2016 v 16:14 John D. Ament napsal(a): >> > > Hey guys >> > > >> > > Seems like we have some issues in JIRA all focused on >> managing the >> > > lifecycle of Dependent scoped beans. It also seems like >> we have many >> > > differing opinions about how to manage them. >> > > >> > > - Martin raised a PR to add a release() method to Instance >> to help >> > > destroy a dependent bean >> https://github.com/cdi-spec/cdi/pull/286 >> > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 >> to update the >> > > spec to clarify how to manage a dependent scoped bean. >> > > >> > > Right now, it seems that the big disagreement is whether >> > > Instance.destroy() can destroy objects not created by it >> (the case >> being >> > > around the CDI utility class, being an impl of Instance). I'm >> currently >> > > heavily against Martin's proposed changes, but want to get >> input from >> > > others on the group to understand their perspective. >> > > >> > > - Does the spec require destroy() to be called only on >> instances >> that it >> > > created? When I read 5.6.1 the only requirement I see is >> that it >> has to >> > > be a dependent scoped bean. Note when I ask this I'm >> asking from the >> > > spec perspective, its a different problem if there's some >> issues with >> > > implementations following suite (I would imagine there >> needs to be some >> > > shared global registry of dependent scoped beans for this >> to work). >> > > >> > > - Do we want two methods that effectively do the same >> thing? I don't >> > > see a strong difference between the two. >> > >> > Instance.destroy() currently always destroys the contextual >> instance. >> > Which is not always what users expect. That's why I proposed >> to add >> > Instance.release() - https://github.com/cdi-spec/cdi/pull/286 , >> > previously Instance.getBean() - >> https://github.com/cdi-spec/cdi/pull/273. >> > >> >> Since you give the instance to both I guess the intention from user >> point of view is obvious and then we dont need 2 methods. What >> would be >> the other use case? >> >> >> https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614 >> >> >> > > >> > > On the flipside, my change is more a spec clarification. >> I'm thinking >> > > more now that it belongs as a reword of 5.6.1 to clarify >> how to use >> > > destroy() on dependent beans, rather than where I put it. >> I think >> > > realistically we have all of the tools needed to manage the >> lifecycle of >> > > these classes, just need to clarify them for people to use. >> > > >> > > John >> > > >> > > >> > > _______________________________________________ >> > > cdi-dev mailing list >> > > cdi-dev at lists.jboss.org >> > >> >> > > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > >> > > Note that for all code provided on this list, the provider >> licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.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. >> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160516/bb577fcb/attachment-0001.html From mkouba at redhat.com Mon May 16 05:20:20 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 16 May 2016 11:20:20 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: <57397E43.9050708@redhat.com> <5739839C.7000406@redhat.com> <573987E4.1020405@redhat.com> Message-ID: <573990D4.3000407@redhat.com> Dne 16.5.2016 v 11:08 Romain Manni-Bucau napsal(a): > > Le 16 mai 2016 10:42, "Martin Kouba" > a ?crit : > > > > > > > > Dne 16.5.2016 v 10:36 Romain Manni-Bucau napsal(a): > > > >> I see, thks. > >> > >> I dont like having 2 methods with the same semantic there but agree the > >> default is misleading for such cases. > >> > >> 1. Cant we change the default? looks like current one can break apps if > >> misunderstood and not sure changing it is worse. > > > > > > I think we cannot due to backward compatibility. > > > > > >> > >> If not > >> > >> 2. Maybe we can type the returned type with a release method in the > >> instance wrapper instead of enriching Instance API making it contextual > >> by nature?: w=instance...get();w.getValue().work();w.release(/*no > param*/); > > > > > > Sorry, I don't get it. Do you want to change Instance.get() signature > and return some kind of wrapper? A simple snippet might help. > > > > Yes get a method to have the wrapper to manage a single instance: > > @Inject Instance i; > > ... > > Wrapper w = i.getSelected(); > ... > w.getValue().businessmetd(); > ... > w.release(); Well, we could introduce a new wrapper and even make is AutoCloseable, e.g. something like discussed here: http://lists.jboss.org/pipermail/cdi-dev/2016-May/008241.html But still you would have to distinguish between destroy() and release(). My original proposal was to allow a user to inspect the Bean metadata, see also https://issues.jboss.org/browse/CDI-515. But guys convinced me ;-) > > >> > >> That is what most framework did finally to integrate with CDI so looks > >> natural. > >> > >> Le 16 mai 2016 10:23, "Martin Kouba" > >> >> a ?crit : > >> > >> Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a): > >> > >> > >> Le 16 mai 2016 10:01, "Martin Kouba" > >> > > >> > >>> a ?crit : > >> > >> > > >> > Dne 15.5.2016 v 16:14 John D. Ament napsal(a): > >> > > Hey guys > >> > > > >> > > Seems like we have some issues in JIRA all focused on > >> managing the > >> > > lifecycle of Dependent scoped beans. It also seems like > >> we have many > >> > > differing opinions about how to manage them. > >> > > > >> > > - Martin raised a PR to add a release() method to Instance > >> to help > >> > > destroy a dependent bean > >> https://github.com/cdi-spec/cdi/pull/286 > >> > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 > >> to update the > >> > > spec to clarify how to manage a dependent scoped bean. > >> > > > >> > > Right now, it seems that the big disagreement is whether > >> > > Instance.destroy() can destroy objects not created by it > >> (the case > >> being > >> > > around the CDI utility class, being an impl of > Instance). I'm > >> currently > >> > > heavily against Martin's proposed changes, but want to get > >> input from > >> > > others on the group to understand their perspective. > >> > > > >> > > - Does the spec require destroy() to be called only on > >> instances > >> that it > >> > > created? When I read 5.6.1 the only requirement I see is > >> that it > >> has to > >> > > be a dependent scoped bean. Note when I ask this I'm > >> asking from the > >> > > spec perspective, its a different problem if there's some > >> issues with > >> > > implementations following suite (I would imagine there > >> needs to be some > >> > > shared global registry of dependent scoped beans for this > >> to work). > >> > > > >> > > - Do we want two methods that effectively do the same > >> thing? I don't > >> > > see a strong difference between the two. > >> > > >> > Instance.destroy() currently always destroys the contextual > >> instance. > >> > Which is not always what users expect. That's why I proposed > >> to add > >> > Instance.release() - > https://github.com/cdi-spec/cdi/pull/286, > >> > previously Instance.getBean() - > >> https://github.com/cdi-spec/cdi/pull/273. > >> > > >> > >> Since you give the instance to both I guess the intention > from user > >> point of view is obvious and then we dont need 2 methods. What > >> would be > >> the other use case? > >> > >> > >> https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614 > >> > >> > >> > > > >> > > On the flipside, my change is more a spec clarification. > >> I'm thinking > >> > > more now that it belongs as a reword of 5.6.1 to clarify > >> how to use > >> > > destroy() on dependent beans, rather than where I put it. > >> I think > >> > > realistically we have all of the tools needed to > manage the > >> lifecycle of > >> > > these classes, just need to clarify them for people to > use. > >> > > > >> > > John > >> > > > >> > > > >> > > _______________________________________________ > >> > > cdi-dev mailing list > >> > > cdi-dev at lists.jboss.org > > > >> >> > >> > >> > > https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > > > >> > > Note that for all code provided on this list, the provider > >> licenses > >> the code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.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. > >> > >> > >> -- > >> Martin Kouba > >> Software Engineer > >> Red Hat, Czech Republic > >> > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > -- Martin Kouba Software Engineer Red Hat, Czech Republic From rmannibucau at gmail.com Mon May 16 05:23:35 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 16 May 2016 11:23:35 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: <573990D4.3000407@redhat.com> References: <57397E43.9050708@redhat.com> <5739839C.7000406@redhat.com> <573987E4.1020405@redhat.com> <573990D4.3000407@redhat.com> Message-ID: I agree with you bit also the default should be smoother. Just trying to have side by side 2 confusing methods. Like the AutoCloseable idea btw. Le 16 mai 2016 11:20, "Martin Kouba" a ?crit : > Dne 16.5.2016 v 11:08 Romain Manni-Bucau napsal(a): > >> >> Le 16 mai 2016 10:42, "Martin Kouba" > > a ?crit : >> > >> > >> > >> > Dne 16.5.2016 v 10:36 Romain Manni-Bucau napsal(a): >> > >> >> I see, thks. >> >> >> >> I dont like having 2 methods with the same semantic there but agree >> the >> >> default is misleading for such cases. >> >> >> >> 1. Cant we change the default? looks like current one can break apps >> if >> >> misunderstood and not sure changing it is worse. >> > >> > >> > I think we cannot due to backward compatibility. >> > >> > >> >> >> >> If not >> >> >> >> 2. Maybe we can type the returned type with a release method in the >> >> instance wrapper instead of enriching Instance API making it >> contextual >> >> by nature?: w=instance...get();w.getValue().work();w.release(/*no >> param*/); >> > >> > >> > Sorry, I don't get it. Do you want to change Instance.get() signature >> and return some kind of wrapper? A simple snippet might help. >> > >> >> Yes get a method to have the wrapper to manage a single instance: >> >> @Inject Instance i; >> >> ... >> >> Wrapper w = i.getSelected(); >> ... >> w.getValue().businessmetd(); >> ... >> w.release(); >> > > Well, we could introduce a new wrapper and even make is AutoCloseable, > e.g. something like discussed here: > http://lists.jboss.org/pipermail/cdi-dev/2016-May/008241.html > > But still you would have to distinguish between destroy() and release(). > My original proposal was to allow a user to inspect the Bean metadata, see > also https://issues.jboss.org/browse/CDI-515. But guys convinced me ;-) > > >> >> >> >> That is what most framework did finally to integrate with CDI so looks >> >> natural. >> >> >> >> Le 16 mai 2016 10:23, "Martin Kouba" > >> >> >> a ?crit : >> >> >> >> Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a): >> >> >> >> >> >> Le 16 mai 2016 10:01, "Martin Kouba" > >> >> > >> >> >> >>> a ?crit : >> >> >> >> > >> >> > Dne 15.5.2016 v 16:14 John D. Ament napsal(a): >> >> > > Hey guys >> >> > > >> >> > > Seems like we have some issues in JIRA all focused on >> >> managing the >> >> > > lifecycle of Dependent scoped beans. It also seems like >> >> we have many >> >> > > differing opinions about how to manage them. >> >> > > >> >> > > - Martin raised a PR to add a release() method to >> Instance >> >> to help >> >> > > destroy a dependent bean >> >> https://github.com/cdi-spec/cdi/pull/286 >> >> > > - I raised a PR >> https://github.com/cdi-spec/cdi/pull/289 >> >> to update the >> >> > > spec to clarify how to manage a dependent scoped bean. >> >> > > >> >> > > Right now, it seems that the big disagreement is whether >> >> > > Instance.destroy() can destroy objects not created by it >> >> (the case >> >> being >> >> > > around the CDI utility class, being an impl of >> Instance). I'm >> >> currently >> >> > > heavily against Martin's proposed changes, but want to >> get >> >> input from >> >> > > others on the group to understand their perspective. >> >> > > >> >> > > - Does the spec require destroy() to be called only on >> >> instances >> >> that it >> >> > > created? When I read 5.6.1 the only requirement I see >> is >> >> that it >> >> has to >> >> > > be a dependent scoped bean. Note when I ask this I'm >> >> asking from the >> >> > > spec perspective, its a different problem if there's >> some >> >> issues with >> >> > > implementations following suite (I would imagine there >> >> needs to be some >> >> > > shared global registry of dependent scoped beans for >> this >> >> to work). >> >> > > >> >> > > - Do we want two methods that effectively do the same >> >> thing? I don't >> >> > > see a strong difference between the two. >> >> > >> >> > Instance.destroy() currently always destroys the >> contextual >> >> instance. >> >> > Which is not always what users expect. That's why I >> proposed >> >> to add >> >> > Instance.release() - >> https://github.com/cdi-spec/cdi/pull/286, >> >> > previously Instance.getBean() - >> >> https://github.com/cdi-spec/cdi/pull/273. >> >> > >> >> >> >> Since you give the instance to both I guess the intention >> from user >> >> point of view is obvious and then we dont need 2 methods. What >> >> would be >> >> the other use case? >> >> >> >> >> >> https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614 >> >> >> >> >> >> > > >> >> > > On the flipside, my change is more a spec clarification. >> >> I'm thinking >> >> > > more now that it belongs as a reword of 5.6.1 to clarify >> >> how to use >> >> > > destroy() on dependent beans, rather than where I put >> it. >> >> I think >> >> > > realistically we have all of the tools needed to >> manage the >> >> lifecycle of >> >> > > these classes, just need to clarify them for people to >> use. >> >> > > >> >> > > John >> >> > > >> >> > > >> >> > > _______________________________________________ >> >> > > cdi-dev mailing list >> >> > > cdi-dev at lists.jboss.org >> > > >> >> > > >> >> >> >> >> > > https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> > > >> >> > > Note that for all code provided on this list, the >> provider >> >> licenses >> >> the code under the Apache License, Version 2 >> >> (http://www.apache.org/licenses/LICENSE-2.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. >> >> >> >> >> >> -- >> >> Martin Kouba >> >> Software Engineer >> >> Red Hat, Czech Republic >> >> >> > >> > -- >> > Martin Kouba >> > Software Engineer >> > Red Hat, Czech Republic >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160516/8e7ee519/attachment-0001.html From mkouba at redhat.com Mon May 16 05:48:12 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 16 May 2016 11:48:12 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: <57397E43.9050708@redhat.com> <5739839C.7000406@redhat.com> <573987E4.1020405@redhat.com> <573990D4.3000407@redhat.com> Message-ID: <5739975C.8080204@redhat.com> Ok, what about something like this (names to be discussed): add a new interface: ManagedInstance implements AutoCloseable { T get(); } and two new methods on Instance: ManagedInstance getAndDestroy(); ManagedInstance getAndRelease(); The first one would return a ManagedInstance whose close() would always call Instance.destroy(). The latter one - close() would only call Instance.destroy() for @Dependent beans. Just throwing ideas... Dne 16.5.2016 v 11:23 Romain Manni-Bucau napsal(a): > I agree with you bit also the default should be smoother. Just trying to > have side by side 2 confusing methods. > > Like the AutoCloseable idea btw. > > Le 16 mai 2016 11:20, "Martin Kouba" > a ?crit : > > Dne 16.5.2016 v 11:08 Romain Manni-Bucau napsal(a): > > > Le 16 mai 2016 10:42, "Martin Kouba" > >> a ?crit : > > > > > > > > Dne 16.5.2016 v 10:36 Romain Manni-Bucau napsal(a): > > > >> I see, thks. > >> > >> I dont like having 2 methods with the same semantic there > but agree the > >> default is misleading for such cases. > >> > >> 1. Cant we change the default? looks like current one can > break apps if > >> misunderstood and not sure changing it is worse. > > > > > > I think we cannot due to backward compatibility. > > > > > >> > >> If not > >> > >> 2. Maybe we can type the returned type with a release > method in the > >> instance wrapper instead of enriching Instance API making > it contextual > >> by nature?: > w=instance...get();w.getValue().work();w.release(/*no > param*/); > > > > > > Sorry, I don't get it. Do you want to change Instance.get() > signature > and return some kind of wrapper? A simple snippet might help. > > > > Yes get a method to have the wrapper to manage a single instance: > > @Inject Instance i; > > ... > > Wrapper w = i.getSelected(); > ... > w.getValue().businessmetd(); > ... > w.release(); > > > Well, we could introduce a new wrapper and even make is > AutoCloseable, e.g. something like discussed here: > http://lists.jboss.org/pipermail/cdi-dev/2016-May/008241.html > > But still you would have to distinguish between destroy() and > release(). My original proposal was to allow a user to inspect the > Bean metadata, see also https://issues.jboss.org/browse/CDI-515. But > guys convinced me ;-) > > > >> > >> That is what most framework did finally to integrate with > CDI so looks > >> natural. > >> > >> Le 16 mai 2016 10:23, "Martin Kouba" > > > >> > >>> a ?crit : > >> > >> Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a): > >> > >> > >> Le 16 mai 2016 10:01, "Martin Kouba" > > > > >> >> > >> > > > >>>> a ?crit : > >> > >> > > >> > Dne 15.5.2016 v 16:14 John D. Ament napsal(a): > >> > > Hey guys > >> > > > >> > > Seems like we have some issues in JIRA all > focused on > >> managing the > >> > > lifecycle of Dependent scoped beans. It also > seems like > >> we have many > >> > > differing opinions about how to manage them. > >> > > > >> > > - Martin raised a PR to add a release() > method to Instance > >> to help > >> > > destroy a dependent bean > >> https://github.com/cdi-spec/cdi/pull/286 > >> > > - I raised a PR > https://github.com/cdi-spec/cdi/pull/289 > >> to update the > >> > > spec to clarify how to manage a dependent > scoped bean. > >> > > > >> > > Right now, it seems that the big disagreement > is whether > >> > > Instance.destroy() can destroy objects not > created by it > >> (the case > >> being > >> > > around the CDI utility class, being an impl of > Instance). I'm > >> currently > >> > > heavily against Martin's proposed changes, > but want to get > >> input from > >> > > others on the group to understand their > perspective. > >> > > > >> > > - Does the spec require destroy() to be > called only on > >> instances > >> that it > >> > > created? When I read 5.6.1 the only > requirement I see is > >> that it > >> has to > >> > > be a dependent scoped bean. Note when I ask > this I'm > >> asking from the > >> > > spec perspective, its a different problem if > there's some > >> issues with > >> > > implementations following suite (I would > imagine there > >> needs to be some > >> > > shared global registry of dependent scoped > beans for this > >> to work). > >> > > > >> > > - Do we want two methods that effectively do > the same > >> thing? I don't > >> > > see a strong difference between the two. > >> > > >> > Instance.destroy() currently always destroys > the contextual > >> instance. > >> > Which is not always what users expect. That's > why I proposed > >> to add > >> > Instance.release() - > https://github.com/cdi-spec/cdi/pull/286, > >> > previously Instance.getBean() - > >> https://github.com/cdi-spec/cdi/pull/273. > >> > > >> > >> Since you give the instance to both I guess the > intention > from user > >> point of view is obvious and then we dont need 2 > methods. What > >> would be > >> the other use case? > >> > >> > >> https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614 > >> > >> > >> > > > >> > > On the flipside, my change is more a spec > clarification. > >> I'm thinking > >> > > more now that it belongs as a reword of 5.6.1 > to clarify > >> how to use > >> > > destroy() on dependent beans, rather than > where I put it. > >> I think > >> > > realistically we have all of the tools needed to > manage the > >> lifecycle of > >> > > these classes, just need to clarify them for > people to > use. > >> > > > >> > > John > >> > > > >> > > > >> > > _______________________________________________ > >> > > cdi-dev mailing list > >> > > cdi-dev at lists.jboss.org > > > > > >> > >> > > > > >>> > >> > >> > > https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > > > >> > > Note that for all code provided on this list, > the provider > >> licenses > >> the code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.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. > >> > >> > >> -- > >> Martin Kouba > >> Software Engineer > >> Red Hat, Czech Republic > >> > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -- Martin Kouba Software Engineer Red Hat, Czech Republic From rmannibucau at gmail.com Mon May 16 06:12:14 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 16 May 2016 12:12:14 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: <5739975C.8080204@redhat.com> References: <57397E43.9050708@redhat.com> <5739839C.7000406@redhat.com> <573987E4.1020405@redhat.com> <573990D4.3000407@redhat.com> <5739975C.8080204@redhat.com> Message-ID: getInstanceHandler()? +1 for the idea Le 16 mai 2016 11:48, "Martin Kouba" a ?crit : > Ok, what about something like this (names to be discussed): add a new > interface: > > ManagedInstance implements AutoCloseable { > T get(); > } > > and two new methods on Instance: > > ManagedInstance getAndDestroy(); > ManagedInstance getAndRelease(); > > The first one would return a ManagedInstance whose close() would always > call Instance.destroy(). The latter one - close() would only call > Instance.destroy() for @Dependent beans. > > Just throwing ideas... > > > Dne 16.5.2016 v 11:23 Romain Manni-Bucau napsal(a): > >> I agree with you bit also the default should be smoother. Just trying to >> have side by side 2 confusing methods. >> >> Like the AutoCloseable idea btw. >> >> Le 16 mai 2016 11:20, "Martin Kouba" > > a ?crit : >> >> Dne 16.5.2016 v 11:08 Romain Manni-Bucau napsal(a): >> >> >> Le 16 mai 2016 10:42, "Martin Kouba" > >> >> a ?crit : >> > >> > >> > >> > Dne 16.5.2016 v 10:36 Romain Manni-Bucau napsal(a): >> > >> >> I see, thks. >> >> >> >> I dont like having 2 methods with the same semantic there >> but agree the >> >> default is misleading for such cases. >> >> >> >> 1. Cant we change the default? looks like current one can >> break apps if >> >> misunderstood and not sure changing it is worse. >> > >> > >> > I think we cannot due to backward compatibility. >> > >> > >> >> >> >> If not >> >> >> >> 2. Maybe we can type the returned type with a release >> method in the >> >> instance wrapper instead of enriching Instance API making >> it contextual >> >> by nature?: >> w=instance...get();w.getValue().work();w.release(/*no >> param*/); >> > >> > >> > Sorry, I don't get it. Do you want to change Instance.get() >> signature >> and return some kind of wrapper? A simple snippet might help. >> > >> >> Yes get a method to have the wrapper to manage a single instance: >> >> @Inject Instance i; >> >> ... >> >> Wrapper w = i.getSelected(); >> ... >> w.getValue().businessmetd(); >> ... >> w.release(); >> >> >> Well, we could introduce a new wrapper and even make is >> AutoCloseable, e.g. something like discussed here: >> http://lists.jboss.org/pipermail/cdi-dev/2016-May/008241.html >> >> But still you would have to distinguish between destroy() and >> release(). My original proposal was to allow a user to inspect the >> Bean metadata, see also https://issues.jboss.org/browse/CDI-515. But >> guys convinced me ;-) >> >> >> >> >> >> That is what most framework did finally to integrate with >> CDI so looks >> >> natural. >> >> >> >> Le 16 mai 2016 10:23, "Martin Kouba" > >> > >> >> >> >>> a ?crit : >> >> >> >> Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a): >> >> >> >> >> >> Le 16 mai 2016 10:01, "Martin Kouba" >> >> > >> >> > > >> >> >> > > > >> >> >>>> a ?crit >> : >> >> >> >> > >> >> > Dne 15.5.2016 v 16:14 John D. Ament napsal(a): >> >> > > Hey guys >> >> > > >> >> > > Seems like we have some issues in JIRA all >> focused on >> >> managing the >> >> > > lifecycle of Dependent scoped beans. It also >> seems like >> >> we have many >> >> > > differing opinions about how to manage them. >> >> > > >> >> > > - Martin raised a PR to add a release() >> method to Instance >> >> to help >> >> > > destroy a dependent bean >> >> https://github.com/cdi-spec/cdi/pull/286 >> >> > > - I raised a PR >> https://github.com/cdi-spec/cdi/pull/289 >> >> to update the >> >> > > spec to clarify how to manage a dependent >> scoped bean. >> >> > > >> >> > > Right now, it seems that the big disagreement >> is whether >> >> > > Instance.destroy() can destroy objects not >> created by it >> >> (the case >> >> being >> >> > > around the CDI utility class, being an impl of >> Instance). I'm >> >> currently >> >> > > heavily against Martin's proposed changes, >> but want to get >> >> input from >> >> > > others on the group to understand their >> perspective. >> >> > > >> >> > > - Does the spec require destroy() to be >> called only on >> >> instances >> >> that it >> >> > > created? When I read 5.6.1 the only >> requirement I see is >> >> that it >> >> has to >> >> > > be a dependent scoped bean. Note when I ask >> this I'm >> >> asking from the >> >> > > spec perspective, its a different problem if >> there's some >> >> issues with >> >> > > implementations following suite (I would >> imagine there >> >> needs to be some >> >> > > shared global registry of dependent scoped >> beans for this >> >> to work). >> >> > > >> >> > > - Do we want two methods that effectively do >> the same >> >> thing? I don't >> >> > > see a strong difference between the two. >> >> > >> >> > Instance.destroy() currently always destroys >> the contextual >> >> instance. >> >> > Which is not always what users expect. That's >> why I proposed >> >> to add >> >> > Instance.release() - >> https://github.com/cdi-spec/cdi/pull/286, >> >> > previously Instance.getBean() - >> >> https://github.com/cdi-spec/cdi/pull/273. >> >> > >> >> >> >> Since you give the instance to both I guess the >> intention >> from user >> >> point of view is obvious and then we dont need 2 >> methods. What >> >> would be >> >> the other use case? >> >> >> >> >> >> >> https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614 >> >> >> >> >> >> > > >> >> > > On the flipside, my change is more a spec >> clarification. >> >> I'm thinking >> >> > > more now that it belongs as a reword of 5.6.1 >> to clarify >> >> how to use >> >> > > destroy() on dependent beans, rather than >> where I put it. >> >> I think >> >> > > realistically we have all of the tools needed >> to >> manage the >> >> lifecycle of >> >> > > these classes, just need to clarify them for >> people to >> use. >> >> > > >> >> > > John >> >> > > >> >> > > >> >> > > _______________________________________________ >> >> > > cdi-dev mailing list >> >> > > cdi-dev at lists.jboss.org >> >> > > >> >> > >>> >> >> > >> > > >> >> > >>>> >> >> >> >> > > >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> > > >> >> > > Note that for all code provided on this list, >> the provider >> >> licenses >> >> the code under the Apache License, Version 2 >> >> (http://www.apache.org/licenses/LICENSE-2.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. >> >> >> >> >> >> -- >> >> Martin Kouba >> >> Software Engineer >> >> Red Hat, Czech Republic >> >> >> > >> > -- >> > Martin Kouba >> > Software Engineer >> > Red Hat, Czech Republic >> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160516/f5d50279/attachment-0001.html From issues at jboss.org Mon May 16 06:40:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 16 May 2016 06:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-601: ----------------------------- Description: The name might be something like {{BeforeContainerShutdown}. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts. (was: The name might be something like `BeforeContainerShutdown`. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts. ) > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon May 16 06:40:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 16 May 2016 06:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238007#comment-13238007 ] Martin Kouba commented on CDI-601: ---------------------------------- It might be more practical to fire a regular event, similar to {{@Destroyed(X.class)}}. > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like `BeforeContainerShutdown`. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon May 16 06:44:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 16 May 2016 06:44:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-601: ----------------------------- Description: The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). (was: The name might be something like {{BeforeContainerShutdown}. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts. ) > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon May 16 06:53:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 16 May 2016 06:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238013#comment-13238013 ] Matej Novotny commented on CDI-601: ----------------------------------- Similar to {{@Destroyed}} but fired sooner than the actual destruction happens, right? At least that is what the user (in the forum reference link) needs; at least from what I understood. > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon May 16 07:01:02 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 16 May 2016 07:01:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238015#comment-13238015 ] Martin Kouba commented on CDI-601: ---------------------------------- [~manovotn] Yes, sooner. It should be something like _"The container is about to destroy all contexts and shut down. Please execute all cleaning up business which involves invocation of dependencies."_. > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.d.ament at gmail.com Mon May 16 07:34:29 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 16 May 2016 11:34:29 +0000 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: <57397CCB.90101@redhat.com> References: <57397CCB.90101@redhat.com> Message-ID: Martin, On Mon, May 16, 2016 at 3:54 AM Martin Kouba wrote: > Dne 15.5.2016 v 17:14 John D. Ament napsal(a): > > Romain, > > > > On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau > > > wrote: > > > > Hi Jon > > > > Le 15 mai 2016 16:15, "John D. Ament" > > a ?crit : > > > > > > Hey guys > > > > > > Seems like we have some issues in JIRA all focused on managing > > the lifecycle of Dependent scoped beans. It also seems like we have > > many differing opinions about how to manage them. > > > > > > - Martin raised a PR to add a release() method to Instance to > > help destroy a dependent bean > https://github.com/cdi-spec/cdi/pull/286 > > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to > > update the spec to clarify how to manage a dependent scoped bean. > > > > > > Right now, it seems that the big disagreement is whether > > Instance.destroy() can destroy objects not created by it (the case > > being around the CDI utility class, being an impl of Instance). I'm > > currently heavily against Martin's proposed changes, but want to get > > input from others on the group to understand their perspective. > > > > > > - Does the spec require destroy() to be called only on instances > > that it created? When I read 5.6.1 the only requirement I see is > > that it has to be a dependent scoped bean. Note when I ask this I'm > > asking from the spec perspective, its a different problem if there's > > some issues with implementations following suite (I would imagine > > there needs to be some shared global registry of dependent scoped > > beans for this to work). > > > > > > > Sound the only clean impl. Any other is not symmetric and > > potentially lead to "oops this time it didnt work". I also not > > seeing any use case limitation with that so think it is the same > > solution > > > > > > I'm not sure I follow or if this isn't an answer to "Does the spec > > require destroy() to be called only on instances that it created?" ? > > > > Anyways I did look a bit closer and it seems that Martin's statement is > > consistent with how OWB works, > > > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293 > so > > I wonder if there's a part of the spec I'm missing, or if there was some > > offline agreement on how to understand it. > > John, I believe Instance CANNOT be used to destroy a dependent bean > instance it didn't created, because a dependent bean instance doesn't > know the dependent objects it depends on - that's what CreationalContext > is for. > > This is the area I'm looking for clarification around. Where in the spec is this mandated? > So if you pass any dependent instance to Instance.destroy() there is no > CreationalContext apart from the one Instance<> has. In other words you > wouldn't be able to destroy the @Dependent dependencies of a @Dependent > bean instane. Does it make sense? > > See also https://issues.jboss.org/browse/CDI-519 (cdi-spec/cdi/pull/278 > is already merged). > > > > > > John > > > > > - Do we want two methods that effectively do the same thing? I > > don't see a strong difference between the two. > > > > > > On the flipside, my change is more a spec clarification. I'm > > thinking more now that it belongs as a reword of 5.6.1 to clarify > > how to use destroy() on dependent beans, rather than where I put > > it. I think realistically we have all of the tools needed to manage > > the lifecycle of these classes, just need to clarify them for people > > to use. > > > > > > John > > > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider > > licenses the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.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/20160516/e3110364/attachment-0001.html From john.d.ament at gmail.com Mon May 16 07:54:54 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 16 May 2016 11:54:54 +0000 Subject: [cdi-dev] API Only PR for Context management In-Reply-To: References: Message-ID: On Mon, May 16, 2016 at 4:21 AM arjan tijms wrote: > Hi, > > >> I think what you're asking for is to intercept at the container level and >> change how they initialize. I'm curious, under what cases do you not have >> an active request? >> > > My primary case is to compensate for container differences regarding a > ServerAuthModule (JSR 196/JASPIC). Such ServerAuthModule is called before > the first Servlet Filter is, and gets an HttpServletRequest passed in. In > many servers (JBoss, GlassFish, TomEE) the CDI default scopes (request, > session, etc) are active at that point, but not in all (Liberty, WebLogic). > > With this proposed API a library such as Soteria could possibly start > those scopes earlier on Liberty and WebLogic and do nothing on JBoss, > GlassFish and TomEE. > That sounds like a separate issue. We want all of the app servers to behave the same way, I wouldn't expect this change to fix that, or even to make it so that libraries could fix that. Maybe there's a missing TCK assertion? > > Kind regards, > Arjan Tijms > > > > >> In addition, I think you're looking for the equivalent of >> Context.isActive. Part of me even wonders if swapping around the impl to be >> Context.activate() and Context.deactivate() may be better from a domain >> standpoint. >> >> What I'm looking for is a way to start contexts possibly earlier than a >>> specific container implementation normally starts them, and stop them >>> possibly later. If the context is started earlier in say a request, then >>> eventually the container will also start that same context later in the >>> request. If that will throw an exception the request will not proceed, >>> which is of course not intended. >>> Likewise, when the container stops the context this will thus be too >>> early. >>> With a wrapped context controller, the startContexts and stopContexts >>> calls can be ignored for those contexts the application (extension/library) >>> wanted to start earlier and stop later. This does of course assume that the >>> container itself will also use this context controller instead of the >>> current proprietary code. >>> Additionally, the PR does not contain the check anymore to see if the >>> context is already active or already stopped. Is that still intended to be >>> added? This would be particularly useful for code that needs to be portable >>> between different containers, where one container may already have started >>> the context at a given point, where another container has not (catching the >>> exception would be an alternative here but is obviously not so nice). >>> Another point, what about letting the caller of the startContexts method >>> optionally pass in the objects (or a lambda to obtain them) on which that >>> context primarily depends (if any). E.g. for the request scope, pass in an >>> HttpServletRequest instance. >> >> Would it be an idea to set a wrapped (or decorated) context controller? >> > >> On Sun, May 15, 2016 at 6:33 PM, John D. Ament >> wrote: > > All, > > I've started a PR for API changes to support starting/stopping the built >> in contexts, which you can find here: >> https://github.com/cdi-spec/cdi/pull/291/files > > It's visibly based on what is in DeltaSpike's CDI Ctrl plus some of the >> external stuff (e.g. >> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/api/src/main/java/org/apache/deltaspike/scheduler/api/Scheduled.java#L40 ) >> so I'd like to get some input. > > I don't suspect that this will be an SE only feature, today I use >> programmatic context starting even while on an app server. Even though I'm >> not using whats provided in DS, it was identified as a clear cross cutting >> concern hence why there's an interceptor as well. > > John > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.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/20160516/11acf123/attachment.html From issues at jboss.org Mon May 16 07:56:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 16 May 2016 07:56:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238044#comment-13238044 ] John Ament commented on CDI-601: -------------------------------- If I'm already subscribed via a `@PreDestroy` method, shouldn't that continue to work? > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Mon May 16 08:06:33 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 16 May 2016 14:06:33 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: <57397CCB.90101@redhat.com> Message-ID: <5739B7C9.1070502@redhat.com> Dne 16.5.2016 v 13:34 John D. Ament napsal(a): > > Martin, > > > On Mon, May 16, 2016 at 3:54 AM Martin Kouba > wrote: > > Dne 15.5.2016 v 17:14 John D. Ament napsal(a): > > Romain, > > > > On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau > > > >> wrote: > > > > Hi Jon > > > > Le 15 mai 2016 16:15, "John D. Ament" > > >> a ?crit : > > > > > > Hey guys > > > > > > Seems like we have some issues in JIRA all focused on managing > > the lifecycle of Dependent scoped beans. It also seems like > we have > > many differing opinions about how to manage them. > > > > > > - Martin raised a PR to add a release() method to Instance to > > help destroy a dependent bean > https://github.com/cdi-spec/cdi/pull/286 > > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to > > update the spec to clarify how to manage a dependent scoped bean. > > > > > > Right now, it seems that the big disagreement is whether > > Instance.destroy() can destroy objects not created by it (the > case > > being around the CDI utility class, being an impl of > Instance). I'm > > currently heavily against Martin's proposed changes, but want > to get > > input from others on the group to understand their perspective. > > > > > > - Does the spec require destroy() to be called only on > instances > > that it created? When I read 5.6.1 the only requirement I see is > > that it has to be a dependent scoped bean. Note when I ask > this I'm > > asking from the spec perspective, its a different problem if > there's > > some issues with implementations following suite (I would imagine > > there needs to be some shared global registry of dependent scoped > > beans for this to work). > > > > > > > Sound the only clean impl. Any other is not symmetric and > > potentially lead to "oops this time it didnt work". I also not > > seeing any use case limitation with that so think it is the same > > solution > > > > > > I'm not sure I follow or if this isn't an answer to "Does the spec > > require destroy() to be called only on instances that it created?" ? > > > > Anyways I did look a bit closer and it seems that Martin's > statement is > > consistent with how OWB works, > > > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293 > so > > I wonder if there's a part of the spec I'm missing, or if there > was some > > offline agreement on how to understand it. > > John, I believe Instance CANNOT be used to destroy a dependent bean > instance it didn't created, because a dependent bean instance doesn't > know the dependent objects it depends on - that's what CreationalContext > is for. > > > This is the area I'm looking for clarification around. Where in the > spec is this mandated? I think it's implied. When you look at "6.1.1. The CreationalContext interface", there is: "Contextual.create() should use the given CreationalContext when obtaining contextual references to inject, as defined in Contextual reference for a bean, in order to ensure that any dependent objects are associated with the contextual instance that is being created." and also: "Contextual.destroy() should call release() to allow the container to destroy dependent objects of the contextual instance." and "6.2. The Context interface": "The context object must pass the same instance of CreationalContext to Contextual.destroy() that it passed to Contextual.create() when it created the instance." And for dependent beans there is no real context which could hold a reference to a CreationalContext. Each Instance has its own CreationalContext which only tracks the dependent instances produced by a given Instance. Instance does not know anything about CreationalContexts of other dependent instances... > > So if you pass any dependent instance to Instance.destroy() there is no > CreationalContext apart from the one Instance<> has. In other words you > wouldn't be able to destroy the @Dependent dependencies of a @Dependent > bean instane. Does it make sense? > > See also https://issues.jboss.org/browse/CDI-519 (cdi-spec/cdi/pull/278 > is already merged). > > > > > > John > > > > > - Do we want two methods that effectively do the same > thing? I > > don't see a strong difference between the two. > > > > > > On the flipside, my change is more a spec clarification. I'm > > thinking more now that it belongs as a reword of 5.6.1 to clarify > > how to use destroy() on dependent beans, rather than where I put > > it. I think realistically we have all of the tools needed to > manage > > the lifecycle of these classes, just need to clarify them for > people > > to use. > > > > > > John > > > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider > > licenses the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.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 > -- Martin Kouba Software Engineer Red Hat, Czech Republic From john.d.ament at gmail.com Mon May 16 08:13:34 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 16 May 2016 12:13:34 +0000 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: <5739B7C9.1070502@redhat.com> References: <57397CCB.90101@redhat.com> <5739B7C9.1070502@redhat.com> Message-ID: Martin, On Mon, May 16, 2016 at 8:06 AM Martin Kouba wrote: > > Dne 16.5.2016 v 13:34 John D. Ament napsal(a): > > > > Martin, > > > > > > On Mon, May 16, 2016 at 3:54 AM Martin Kouba > > wrote: > > > > Dne 15.5.2016 v 17:14 John D. Ament napsal(a): > > > Romain, > > > > > > On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau > > > > > >> > wrote: > > > > > > Hi Jon > > > > > > Le 15 mai 2016 16:15, "John D. Ament" > > > > > >> a ?crit : > > > > > > > > Hey guys > > > > > > > > Seems like we have some issues in JIRA all focused on > managing > > > the lifecycle of Dependent scoped beans. It also seems like > > we have > > > many differing opinions about how to manage them. > > > > > > > > - Martin raised a PR to add a release() method to Instance > to > > > help destroy a dependent bean > > https://github.com/cdi-spec/cdi/pull/286 > > > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 > to > > > update the spec to clarify how to manage a dependent scoped > bean. > > > > > > > > Right now, it seems that the big disagreement is whether > > > Instance.destroy() can destroy objects not created by it (the > > case > > > being around the CDI utility class, being an impl of > > Instance). I'm > > > currently heavily against Martin's proposed changes, but want > > to get > > > input from others on the group to understand their > perspective. > > > > > > > > - Does the spec require destroy() to be called only on > > instances > > > that it created? When I read 5.6.1 the only requirement I > see is > > > that it has to be a dependent scoped bean. Note when I ask > > this I'm > > > asking from the spec perspective, its a different problem if > > there's > > > some issues with implementations following suite (I would > imagine > > > there needs to be some shared global registry of dependent > scoped > > > beans for this to work). > > > > > > > > > > Sound the only clean impl. Any other is not symmetric and > > > potentially lead to "oops this time it didnt work". I also not > > > seeing any use case limitation with that so think it is the > same > > > solution > > > > > > > > > I'm not sure I follow or if this isn't an answer to "Does the spec > > > require destroy() to be called only on instances that it > created?" ? > > > > > > Anyways I did look a bit closer and it seems that Martin's > > statement is > > > consistent with how OWB works, > > > > > > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293 > > so > > > I wonder if there's a part of the spec I'm missing, or if there > > was some > > > offline agreement on how to understand it. > > > > John, I believe Instance CANNOT be used to destroy a dependent bean > > instance it didn't created, because a dependent bean instance doesn't > > know the dependent objects it depends on - that's what > CreationalContext > > is for. > > > > > > This is the area I'm looking for clarification around. Where in the > > spec is this mandated? > > I think it's implied. When you look at "6.1.1. The CreationalContext > interface", there is: > > "Contextual.create() should use the given CreationalContext when > obtaining contextual references to inject, as defined in Contextual > reference for a bean, in order to ensure that any dependent objects are > associated with the contextual instance that is being created." > > and also: > > "Contextual.destroy() should call release() to allow the container to > destroy dependent objects of the contextual instance." > > and "6.2. The Context interface": > > "The context object must pass the same instance of CreationalContext to > Contextual.destroy() that it passed to Contextual.create() when it > created the instance." > > And for dependent beans there is no real context which could hold a > reference to a CreationalContext. Each Instance has its own > CreationalContext which only tracks the dependent instances produced by > a given Instance. Instance does not know anything about > CreationalContexts of other dependent instances... > I think I'm starting to see your point. However, if its mandated that Instance uses a creational context to create a bean, we should call that out. Right now the text says that it will retrieve a bean, but realistically for dependent it's creating a bean. Maybe something along the lines of "In the case of the target bean being a dependent scoped bean, the instance object used to retrieve that bean will retain a reference to the creational context used to create that bean. That creational context will be used to destroy the bean when calling destroy()" I would still like us to explore ways to do this without requiring the original instance, for the case of CDI.current() usage. John > > > > > So if you pass any dependent instance to Instance.destroy() there is > no > > CreationalContext apart from the one Instance<> has. In other words > you > > wouldn't be able to destroy the @Dependent dependencies of a > @Dependent > > bean instane. Does it make sense? > > > > See also https://issues.jboss.org/browse/CDI-519 > (cdi-spec/cdi/pull/278 > > is already merged). > > > > > > > > > > John > > > > > > > - Do we want two methods that effectively do the same > > thing? I > > > don't see a strong difference between the two. > > > > > > > > On the flipside, my change is more a spec clarification. > I'm > > > thinking more now that it belongs as a reword of 5.6.1 to > clarify > > > how to use destroy() on dependent beans, rather than where I > put > > > it. I think realistically we have all of the tools needed to > > manage > > > the lifecycle of these classes, just need to clarify them for > > people > > > to use. > > > > > > > > John > > > > > > > > > > > _______________________________________________ > > > > cdi-dev mailing list > > > > cdi-dev at lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > Note that for all code provided on this list, the provider > > > licenses the code under the Apache License, Version 2 > > > (http://www.apache.org/licenses/LICENSE-2.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 > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160516/720e7668/attachment-0001.html From issues at jboss.org Mon May 16 08:15:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 16 May 2016 08:15:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238056#comment-13238056 ] Martin Kouba commented on CDI-601: ---------------------------------- [~meetoblivion] It might not work properly if you call dependencies in the callback (e.g. another {{@ApplicationScoped}} bean). > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon May 16 08:18:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 16 May 2016 08:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238059#comment-13238059 ] John Ament commented on CDI-601: -------------------------------- >From your point of view, does observer method ordering also take into account dependencies of beans that the observers will use? > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Mon May 16 08:20:00 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 16 May 2016 14:20:00 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: <57397CCB.90101@redhat.com> <5739B7C9.1070502@redhat.com> Message-ID: <5739BAF0.3030501@redhat.com> Dne 16.5.2016 v 14:13 John D. Ament napsal(a): > Martin, > > On Mon, May 16, 2016 at 8:06 AM Martin Kouba > wrote: > > > Dne 16.5.2016 v 13:34 John D. Ament napsal(a): > > > > Martin, > > > > > > On Mon, May 16, 2016 at 3:54 AM Martin Kouba > > >> wrote: > > > > Dne 15.5.2016 v 17:14 John D. Ament napsal(a): > > > Romain, > > > > > > On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau > > > > > > > > >>> wrote: > > > > > > Hi Jon > > > > > > Le 15 mai 2016 16:15, "John D. Ament" > > > > > > > > > >>> a ?crit : > > > > > > > > Hey guys > > > > > > > > Seems like we have some issues in JIRA all focused > on managing > > > the lifecycle of Dependent scoped beans. It also > seems like > > we have > > > many differing opinions about how to manage them. > > > > > > > > - Martin raised a PR to add a release() method to > Instance to > > > help destroy a dependent bean > > https://github.com/cdi-spec/cdi/pull/286 > > > > - I raised a PR > https://github.com/cdi-spec/cdi/pull/289 to > > > update the spec to clarify how to manage a dependent > scoped bean. > > > > > > > > Right now, it seems that the big disagreement is > whether > > > Instance.destroy() can destroy objects not created by > it (the > > case > > > being around the CDI utility class, being an impl of > > Instance). I'm > > > currently heavily against Martin's proposed changes, > but want > > to get > > > input from others on the group to understand their > perspective. > > > > > > > > - Does the spec require destroy() to be called only on > > instances > > > that it created? When I read 5.6.1 the only > requirement I see is > > > that it has to be a dependent scoped bean. Note when > I ask > > this I'm > > > asking from the spec perspective, its a different > problem if > > there's > > > some issues with implementations following suite (I > would imagine > > > there needs to be some shared global registry of > dependent scoped > > > beans for this to work). > > > > > > > > > > Sound the only clean impl. Any other is not symmetric and > > > potentially lead to "oops this time it didnt work". I > also not > > > seeing any use case limitation with that so think it > is the same > > > solution > > > > > > > > > I'm not sure I follow or if this isn't an answer to "Does > the spec > > > require destroy() to be called only on instances that it > created?" ? > > > > > > Anyways I did look a bit closer and it seems that Martin's > > statement is > > > consistent with how OWB works, > > > > > > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293 > > so > > > I wonder if there's a part of the spec I'm missing, or if > there > > was some > > > offline agreement on how to understand it. > > > > John, I believe Instance CANNOT be used to destroy a > dependent bean > > instance it didn't created, because a dependent bean instance > doesn't > > know the dependent objects it depends on - that's what > CreationalContext > > is for. > > > > > > This is the area I'm looking for clarification around. Where in the > > spec is this mandated? > > I think it's implied. When you look at "6.1.1. The CreationalContext > interface", there is: > > "Contextual.create() should use the given CreationalContext when > obtaining contextual references to inject, as defined in Contextual > reference for a bean, in order to ensure that any dependent objects are > associated with the contextual instance that is being created." > > and also: > > "Contextual.destroy() should call release() to allow the container to > destroy dependent objects of the contextual instance." > > and "6.2. The Context interface": > > "The context object must pass the same instance of CreationalContext to > Contextual.destroy() that it passed to Contextual.create() when it > created the instance." > > And for dependent beans there is no real context which could hold a > reference to a CreationalContext. Each Instance has its own > CreationalContext which only tracks the dependent instances produced by > a given Instance. Instance does not know anything about > CreationalContexts of other dependent instances... > > > > I think I'm starting to see your point. However, if its mandated that > Instance uses a creational context to create a bean, we should call that > out. Right now the text says that it will retrieve a bean, but > realistically for dependent it's creating a bean. Well, I think it's implied as well: Instance is a dependent bean and "6.4.1. Dependent objects": "* An instance of a bean with scope @Dependent obtained by direct invocation of an Instance is a dependent object of the instance of Instance." So it's practically the same as injecting a @Dependent bean into another @Dependent bean. > > Maybe something along the lines of > > "In the case of the target bean being a dependent scoped bean, the > instance object used to retrieve that bean will retain a reference to > the creational context used to create that bean. That creational > context will be used to destroy the bean when calling destroy()" > > I would still like us to explore ways to do this without requiring the > original instance, for the case of CDI.current() usage. > > John > > > > > > So if you pass any dependent instance to Instance.destroy() > there is no > > CreationalContext apart from the one Instance<> has. In other > words you > > wouldn't be able to destroy the @Dependent dependencies of a > @Dependent > > bean instane. Does it make sense? > > > > See also https://issues.jboss.org/browse/CDI-519 > (cdi-spec/cdi/pull/278 > > is already merged). > > > > > > > > > > John > > > > > > > - Do we want two methods that effectively do the same > > thing? I > > > don't see a strong difference between the two. > > > > > > > > On the flipside, my change is more a spec > clarification. I'm > > > thinking more now that it belongs as a reword of 5.6.1 > to clarify > > > how to use destroy() on dependent beans, rather than > where I put > > > it. I think realistically we have all of the tools > needed to > > manage > > > the lifecycle of these classes, just need to clarify > them for > > people > > > to use. > > > > > > > > John > > > > > > > > > > > _______________________________________________ > > > > cdi-dev mailing list > > > > cdi-dev at lists.jboss.org > > > > >> > > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > Note that for all code provided on this list, the > provider > > > licenses the code under the Apache License, Version 2 > > > (http://www.apache.org/licenses/LICENSE-2.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 > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Mon May 16 08:30:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 16 May 2016 08:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238073#comment-13238073 ] Martin Kouba commented on CDI-601: ---------------------------------- I'm not sure I understand. But I would say `no`, this event would merely ensure the injected dependencies are not destroyed during notification. And possibly this could be used together with observer ordering if needed. > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From arjan.tijms at gmail.com Mon May 16 08:47:45 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 16 May 2016 14:47:45 +0200 Subject: [cdi-dev] API Only PR for Context management In-Reply-To: References: Message-ID: Hi, On Mon, May 16, 2016 at 1:54 PM, John D. Ament wrote: > That sounds like a separate issue. > It is technically indeed, but the new context controller is the closest thing to date that I've seen. It's *almost* there. > We want all of the app servers to behave the same way, I wouldn't expect > this change to fix that, or even to make it so that libraries could fix > that. > > Maybe there's a missing TCK assertion? > Root problem is the JSR 196 spec is silent on this. I would have likely been doing the work for a JSR 196 MR that would clarify this by about now, but then the entire "resource problem" situation started, and even though I would practically be doing all the work, this MR never got off the ground. Another option though is to add it to the CDI spec, as that one currently references all the other specs for which the build-in scopes should be active. E.g. in 6.7.1 it now says: "during the service() method of any servlet in the web application, during the doFilter() method of any servlet filter and when the container calls any ServletRequestListener or AsyncListener," This should become something like: "during the service() method of any servlet in the web application, during the doFilter() method of any servlet filter and when the container calls any ServletRequestListener, AsyncListener or ServerAuthContext," To make it extra clear, but slightly longer: "during the service() method of any servlet in the web application, during the doFilter() method of any servlet filter and when the container calls any ServletRequestListener, AsyncListener or ServerAuthContex (and by extension therefor its embedded ServerAuthModules, if any) for the Servlet Container Profile," Thoughts? Kind regards, Arjan Tijms > > >> >> Kind regards, >> Arjan Tijms >> >> >> >> >>> In addition, I think you're looking for the equivalent of >>> Context.isActive. Part of me even wonders if swapping around the impl to be >>> Context.activate() and Context.deactivate() may be better from a domain >>> standpoint. >>> >>> What I'm looking for is a way to start contexts possibly earlier than a >>>> specific container implementation normally starts them, and stop them >>>> possibly later. If the context is started earlier in say a request, then >>>> eventually the container will also start that same context later in the >>>> request. If that will throw an exception the request will not proceed, >>>> which is of course not intended. >>>> Likewise, when the container stops the context this will thus be too >>>> early. >>>> With a wrapped context controller, the startContexts and stopContexts >>>> calls can be ignored for those contexts the application (extension/library) >>>> wanted to start earlier and stop later. This does of course assume that the >>>> container itself will also use this context controller instead of the >>>> current proprietary code. >>>> Additionally, the PR does not contain the check anymore to see if the >>>> context is already active or already stopped. Is that still intended to be >>>> added? This would be particularly useful for code that needs to be portable >>>> between different containers, where one container may already have started >>>> the context at a given point, where another container has not (catching the >>>> exception would be an alternative here but is obviously not so nice). >>>> Another point, what about letting the caller of the startContexts >>>> method optionally pass in the objects (or a lambda to obtain them) on which >>>> that context primarily depends (if any). E.g. for the request scope, pass >>>> in an HttpServletRequest instance. >>> >>> Would it be an idea to set a wrapped (or decorated) context controller? >>> >> >>> On Sun, May 15, 2016 at 6:33 PM, John D. Ament >>> wrote: >> >> All, >> >> I've started a PR for API changes to support starting/stopping the built >>> in contexts, which you can find here: >>> https://github.com/cdi-spec/cdi/pull/291/files >> >> It's visibly based on what is in DeltaSpike's CDI Ctrl plus some of the >>> external stuff (e.g. >>> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/api/src/main/java/org/apache/deltaspike/scheduler/api/Scheduled.java#L40 ) >>> so I'd like to get some input. >> >> I don't suspect that this will be an SE only feature, today I use >>> programmatic context starting even while on an app server. Even though I'm >>> not using whats provided in DS, it was identified as a clear cross cutting >>> concern hence why there's an interceptor as well. >> >> John >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.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/20160516/eb4aad45/attachment-0001.html From john.d.ament at gmail.com Mon May 16 08:52:41 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 16 May 2016 12:52:41 +0000 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: <5739BAF0.3030501@redhat.com> References: <57397CCB.90101@redhat.com> <5739B7C9.1070502@redhat.com> <5739BAF0.3030501@redhat.com> Message-ID: On Mon, May 16, 2016 at 8:20 AM Martin Kouba wrote: > > > Dne 16.5.2016 v 14:13 John D. Ament napsal(a): > > Martin, > > > > On Mon, May 16, 2016 at 8:06 AM Martin Kouba > > wrote: > > > > > > Dne 16.5.2016 v 13:34 John D. Ament napsal(a): > > > > > > Martin, > > > > > > > > > On Mon, May 16, 2016 at 3:54 AM Martin Kouba > > > > >> wrote: > > > > > > Dne 15.5.2016 v 17:14 John D. Ament napsal(a): > > > > Romain, > > > > > > > > On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau > > > > > > > > > > > > >>> > wrote: > > > > > > > > Hi Jon > > > > > > > > Le 15 mai 2016 16:15, "John D. Ament" > > > > > >> > > > > > > > > > >>> a ?crit : > > > > > > > > > > Hey guys > > > > > > > > > > Seems like we have some issues in JIRA all focused > > on managing > > > > the lifecycle of Dependent scoped beans. It also > > seems like > > > we have > > > > many differing opinions about how to manage them. > > > > > > > > > > - Martin raised a PR to add a release() method to > > Instance to > > > > help destroy a dependent bean > > > https://github.com/cdi-spec/cdi/pull/286 > > > > > - I raised a PR > > https://github.com/cdi-spec/cdi/pull/289 to > > > > update the spec to clarify how to manage a dependent > > scoped bean. > > > > > > > > > > Right now, it seems that the big disagreement is > > whether > > > > Instance.destroy() can destroy objects not created by > > it (the > > > case > > > > being around the CDI utility class, being an impl of > > > Instance). I'm > > > > currently heavily against Martin's proposed changes, > > but want > > > to get > > > > input from others on the group to understand their > > perspective. > > > > > > > > > > - Does the spec require destroy() to be called only > on > > > instances > > > > that it created? When I read 5.6.1 the only > > requirement I see is > > > > that it has to be a dependent scoped bean. Note when > > I ask > > > this I'm > > > > asking from the spec perspective, its a different > > problem if > > > there's > > > > some issues with implementations following suite (I > > would imagine > > > > there needs to be some shared global registry of > > dependent scoped > > > > beans for this to work). > > > > > > > > > > > > > Sound the only clean impl. Any other is not symmetric > and > > > > potentially lead to "oops this time it didnt work". I > > also not > > > > seeing any use case limitation with that so think it > > is the same > > > > solution > > > > > > > > > > > > I'm not sure I follow or if this isn't an answer to "Does > > the spec > > > > require destroy() to be called only on instances that it > > created?" ? > > > > > > > > Anyways I did look a bit closer and it seems that Martin's > > > statement is > > > > consistent with how OWB works, > > > > > > > > > > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293 > > > so > > > > I wonder if there's a part of the spec I'm missing, or if > > there > > > was some > > > > offline agreement on how to understand it. > > > > > > John, I believe Instance CANNOT be used to destroy a > > dependent bean > > > instance it didn't created, because a dependent bean instance > > doesn't > > > know the dependent objects it depends on - that's what > > CreationalContext > > > is for. > > > > > > > > > This is the area I'm looking for clarification around. Where in > the > > > spec is this mandated? > > > > I think it's implied. When you look at "6.1.1. The CreationalContext > > interface", there is: > > > > "Contextual.create() should use the given CreationalContext when > > obtaining contextual references to inject, as defined in Contextual > > reference for a bean, in order to ensure that any dependent objects > are > > associated with the contextual instance that is being created." > > > > and also: > > > > "Contextual.destroy() should call release() to allow the container to > > destroy dependent objects of the contextual instance." > > > > and "6.2. The Context interface": > > > > "The context object must pass the same instance of CreationalContext > to > > Contextual.destroy() that it passed to Contextual.create() when it > > created the instance." > > > > And for dependent beans there is no real context which could hold a > > reference to a CreationalContext. Each Instance has its own > > CreationalContext which only tracks the dependent instances produced > by > > a given Instance. Instance does not know anything about > > CreationalContexts of other dependent instances... > > > > > > > > I think I'm starting to see your point. However, if its mandated that > > Instance uses a creational context to create a bean, we should call that > > out. Right now the text says that it will retrieve a bean, but > > realistically for dependent it's creating a bean. > > Well, I think it's implied as well: Instance is a dependent bean and > "6.4.1. Dependent objects": > That means Instance is dependent, not that the objects it creates are dependent. > > "* An instance of a bean with scope @Dependent obtained by direct > invocation of an Instance is a dependent object of the instance of > Instance." > > So it's practically the same as injecting a @Dependent bean into another > @Dependent bean. > > > > > Maybe something along the lines of > > > > "In the case of the target bean being a dependent scoped bean, the > > instance object used to retrieve that bean will retain a reference to > > the creational context used to create that bean. That creational > > context will be used to destroy the bean when calling destroy()" > > > > I would still like us to explore ways to do this without requiring the > > original instance, for the case of CDI.current() usage. > > > > John > > > > > > > > > > So if you pass any dependent instance to Instance.destroy() > > there is no > > > CreationalContext apart from the one Instance<> has. In other > > words you > > > wouldn't be able to destroy the @Dependent dependencies of a > > @Dependent > > > bean instane. Does it make sense? > > > > > > See also https://issues.jboss.org/browse/CDI-519 > > (cdi-spec/cdi/pull/278 > > > is already merged). > > > > > > > > > > > > > > John > > > > > > > > > - Do we want two methods that effectively do the > same > > > thing? I > > > > don't see a strong difference between the two. > > > > > > > > > > On the flipside, my change is more a spec > > clarification. I'm > > > > thinking more now that it belongs as a reword of 5.6.1 > > to clarify > > > > how to use destroy() on dependent beans, rather than > > where I put > > > > it. I think realistically we have all of the tools > > needed to > > > manage > > > > the lifecycle of these classes, just need to clarify > > them for > > > people > > > > to use. > > > > > > > > > > John > > > > > > > > > > > > > > _______________________________________________ > > > > > cdi-dev mailing list > > > > > cdi-dev at lists.jboss.org > > > > > > > > > >> > > > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > > > Note that for all code provided on this list, the > > provider > > > > licenses the code under the Apache License, Version 2 > > > > (http://www.apache.org/licenses/LICENSE-2.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 > > > > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160516/16a035ff/attachment-0001.html From mkouba at redhat.com Mon May 16 09:02:38 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 16 May 2016 15:02:38 +0200 Subject: [cdi-dev] Managing Dependent Scoped Beans In-Reply-To: References: <57397CCB.90101@redhat.com> <5739B7C9.1070502@redhat.com> <5739BAF0.3030501@redhat.com> Message-ID: <5739C4EE.2010102@redhat.com> Dne 16.5.2016 v 14:52 John D. Ament napsal(a): > > > On Mon, May 16, 2016 at 8:20 AM Martin Kouba > wrote: > > > > Dne 16.5.2016 v 14:13 John D. Ament napsal(a): > > Martin, > > > > On Mon, May 16, 2016 at 8:06 AM Martin Kouba > > >> wrote: > > > > > > Dne 16.5.2016 v 13:34 John D. Ament napsal(a): > > > > > > Martin, > > > > > > > > > On Mon, May 16, 2016 at 3:54 AM Martin Kouba > > > > > > > > >>> wrote: > > > > > > Dne 15.5.2016 v 17:14 John D. Ament napsal(a): > > > > Romain, > > > > > > > > On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau > > > > > > > > >> > > > > > > > >>>> wrote: > > > > > > > > Hi Jon > > > > > > > > Le 15 mai 2016 16:15, "John D. Ament" > > > > > > > >> > > > > > > > > > > > > >>>> a ?crit : > > > > > > > > > > Hey guys > > > > > > > > > > Seems like we have some issues in JIRA all > focused > > on managing > > > > the lifecycle of Dependent scoped beans. It also > > seems like > > > we have > > > > many differing opinions about how to manage them. > > > > > > > > > > - Martin raised a PR to add a release() > method to > > Instance to > > > > help destroy a dependent bean > > > https://github.com/cdi-spec/cdi/pull/286 > > > > > - I raised a PR > > https://github.com/cdi-spec/cdi/pull/289 to > > > > update the spec to clarify how to manage a > dependent > > scoped bean. > > > > > > > > > > Right now, it seems that the big disagreement is > > whether > > > > Instance.destroy() can destroy objects not > created by > > it (the > > > case > > > > being around the CDI utility class, being an > impl of > > > Instance). I'm > > > > currently heavily against Martin's proposed > changes, > > but want > > > to get > > > > input from others on the group to understand their > > perspective. > > > > > > > > > > - Does the spec require destroy() to be > called only on > > > instances > > > > that it created? When I read 5.6.1 the only > > requirement I see is > > > > that it has to be a dependent scoped bean. > Note when > > I ask > > > this I'm > > > > asking from the spec perspective, its a different > > problem if > > > there's > > > > some issues with implementations following suite (I > > would imagine > > > > there needs to be some shared global registry of > > dependent scoped > > > > beans for this to work). > > > > > > > > > > > > > Sound the only clean impl. Any other is not > symmetric and > > > > potentially lead to "oops this time it didnt > work". I > > also not > > > > seeing any use case limitation with that so > think it > > is the same > > > > solution > > > > > > > > > > > > I'm not sure I follow or if this isn't an answer to > "Does > > the spec > > > > require destroy() to be called only on instances > that it > > created?" ? > > > > > > > > Anyways I did look a bit closer and it seems that > Martin's > > > statement is > > > > consistent with how OWB works, > > > > > > > > > > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293 > > > so > > > > I wonder if there's a part of the spec I'm missing, > or if > > there > > > was some > > > > offline agreement on how to understand it. > > > > > > John, I believe Instance CANNOT be used to destroy a > > dependent bean > > > instance it didn't created, because a dependent bean > instance > > doesn't > > > know the dependent objects it depends on - that's what > > CreationalContext > > > is for. > > > > > > > > > This is the area I'm looking for clarification around. > Where in the > > > spec is this mandated? > > > > I think it's implied. When you look at "6.1.1. The > CreationalContext > > interface", there is: > > > > "Contextual.create() should use the given CreationalContext when > > obtaining contextual references to inject, as defined in > Contextual > > reference for a bean, in order to ensure that any dependent > objects are > > associated with the contextual instance that is being created." > > > > and also: > > > > "Contextual.destroy() should call release() to allow the > container to > > destroy dependent objects of the contextual instance." > > > > and "6.2. The Context interface": > > > > "The context object must pass the same instance of > CreationalContext to > > Contextual.destroy() that it passed to Contextual.create() > when it > > created the instance." > > > > And for dependent beans there is no real context which could > hold a > > reference to a CreationalContext. Each Instance has its own > > CreationalContext which only tracks the dependent instances > produced by > > a given Instance. Instance does not know anything about > > CreationalContexts of other dependent instances... > > > > > > > > I think I'm starting to see your point. However, if its mandated > that > > Instance uses a creational context to create a bean, we should > call that > > out. Right now the text says that it will retrieve a bean, but > > realistically for dependent it's creating a bean. > > Well, I think it's implied as well: Instance is a dependent bean and > "6.4.1. Dependent objects": > > > That means Instance is dependent, not that the objects it creates are > dependent. Defintely not. Read it again please. Built-in bean instance is @Dependent. And instance of a bean with scope @Dependent obtained by direct invocation of an Instance, ie. Instance.get()... > > > "* An instance of a bean with scope @Dependent obtained by direct > invocation of an Instance is a dependent object of the instance of > Instance." > > So it's practically the same as injecting a @Dependent bean into another > @Dependent bean. > > > > > Maybe something along the lines of > > > > "In the case of the target bean being a dependent scoped bean, the > > instance object used to retrieve that bean will retain a reference to > > the creational context used to create that bean. That creational > > context will be used to destroy the bean when calling destroy()" > > > > I would still like us to explore ways to do this without > requiring the > > original instance, for the case of CDI.current() usage. > > > > John > > > > > > > > > > So if you pass any dependent instance to > Instance.destroy() > > there is no > > > CreationalContext apart from the one Instance<> has. > In other > > words you > > > wouldn't be able to destroy the @Dependent > dependencies of a > > @Dependent > > > bean instane. Does it make sense? > > > > > > See also https://issues.jboss.org/browse/CDI-519 > > (cdi-spec/cdi/pull/278 > > > is already merged). > > > > > > > > > > > > > > John > > > > > > > > > - Do we want two methods that effectively do > the same > > > thing? I > > > > don't see a strong difference between the two. > > > > > > > > > > On the flipside, my change is more a spec > > clarification. I'm > > > > thinking more now that it belongs as a reword > of 5.6.1 > > to clarify > > > > how to use destroy() on dependent beans, rather > than > > where I put > > > > it. I think realistically we have all of the tools > > needed to > > > manage > > > > the lifecycle of these classes, just need to > clarify > > them for > > > people > > > > to use. > > > > > > > > > > John > > > > > > > > > > > > > > _______________________________________________ > > > > > cdi-dev mailing list > > > > > cdi-dev at lists.jboss.org > > > > > > >> > > > > > > > > >>> > > > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > > > Note that for all code provided on this > list, the > > provider > > > > licenses the code under the Apache License, > Version 2 > > > > > (http://www.apache.org/licenses/LICENSE-2.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 > > > > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Mon May 16 10:37:00 2016 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Mon, 16 May 2016 10:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238152#comment-13238152 ] Chris Rankin commented on CDI-601: ---------------------------------- For reference, I think {{BeforeApplicationShutdown}} or {{BeforeApplicationUndeploy}} would be semantically better event names than {{BeforeContainerShutdown}}. Also, the _particular_ bean which I was struggling to shut down was actually {{@Dependent}} scoped with {{@ApplicationScoped}} dependencies, so I don't think that I could have replaced its {{@PreDestroy}} method with an event observer method in this case. What I actually did was locate the {{@ApplicationScoped}} bean that owned the target bean, and then direct the shutdown from a {{@Destroyed(ApplicationScoped.class)}} observer method there instead. My original notion was for {{@ApplicationScoped}} beans not to be destroyed while other beans still hold contextual references to them, although I have no idea how feasible that would be to implement. > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue May 17 06:10:05 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 May 2016 06:10:05 -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 reassigned CDI-519: ---------------------------------------- Fix Version/s: 2.0-EDR2 (was: 2.0 (discussion)) Assignee: Martin Kouba Resolution: Done > 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 > Assignee: Martin Kouba > Fix For: 2.0-EDR2 > > > 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.4.11#64026) From issues at jboss.org Tue May 17 06:11:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 May 2016 06:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Events - clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-494: ---------------------------------------- Fix Version/s: 2.0-EDR2 (was: 2.0 (discussion)) Assignee: Martin Kouba Resolution: Done > Events - clarify that a type variable that resolves to a wildcard is not resolvable > ----------------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: Martin Kouba > Fix For: 2.0-EDR2 > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.d.ament at gmail.com Tue May 17 07:13:31 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 17 May 2016 11:13:31 +0000 Subject: [cdi-dev] Meeting on today? Message-ID: Hey guys Wanted to make sure the meeting is scheduled for today. If so, would like to broach the topic of the dependent scoped mess we have. Second, if time permits, to discuss the new SE API PR. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160517/da338260/attachment.html From issues at jboss.org Tue May 17 07:18:00 2016 From: issues at jboss.org (Pavel Pscheidl (JIRA)) Date: Tue, 17 May 2016 07:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238556#comment-13238556 ] Pavel Pscheidl commented on CDI-414: ------------------------------------ I think a good enough solution is to inject a Instance object, where T is a generic type for the self-injecting bean. {code:java} public class Foo { @Inject private Instance foo; } {code} This works completely fine. Some kind of lazy-injecting proxy would be nice, but unnecessary. Since dependency injection is an acyclic graph, creating cycle dependecies is wrong. The code inside the bean should explicitely state (by calling foo.get()) that it wants to get "yet another" instance from the container. Some (recursive) algorithms actually might want to use self-injected dependecies. However, the algorithm explicitely obtains the instance from the container and is in charge of stopping the recursion. > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > 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.4.11#64026) From antoine at sabot-durand.net Tue May 17 07:18:28 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 17 May 2016 11:18:28 +0000 Subject: [cdi-dev] Meeting on today? In-Reply-To: References: Message-ID: Hi John Yes the meeting is schedule for today. Ok for your agenda. Antoine Le mar. 17 mai 2016 ? 13:13, John D. Ament a ?crit : > Hey guys > > Wanted to make sure the meeting is scheduled for today. > > If so, would like to broach the topic of the dependent scoped mess we have. > Second, if time permits, to discuss the new SE API PR. > > John > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160517/bd97e178/attachment.html From mkouba at redhat.com Tue May 17 10:51:57 2016 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 17 May 2016 16:51:57 +0200 Subject: [cdi-dev] Meeting on today? In-Reply-To: References: Message-ID: <573B300D.7040303@redhat.com> Hi guys, I'm not sure I will be able to attend the mtg today. Anyway, I've prepared a POC with enhanced/unportable version of javax.enterprise.inject.Instance I'd like to add to Weld API (i.e. would be available automatically for Weld SE and Servlet and also in EE servers running on Weld): https://github.com/mkouba/core/blob/WELD-2151/impl/src/main/java/org/jboss/weld/inject/WeldInstance.java There are 3 new methods: Destroyable getAndDestroy() boolean isResolvable() Bean getBean() All more or less discussed within EG. The usage is shown in the test: https://github.com/mkouba/core/blob/WELD-2151/tests-arquillian/src/test/java/org/jboss/weld/tests/instance/enhanced/WeldInstanceTest.java Especially the first one might be interesting in the context of "the dependent scoped mess". Martin Dne 17.5.2016 v 13:18 Antoine Sabot-Durand napsal(a): > Hi John > > Yes the meeting is schedule for today. > Ok for your agenda. > > Antoine > Le mar. 17 mai 2016 ? 13:13, John D. Ament > a ?crit : > > Hey guys > > Wanted to make sure the meeting is scheduled for today. > > If so, would like to broach the topic of the dependent scoped mess > we have. > Second, if time permits, to discuss the new SE API PR. > > John > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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 mkouba at redhat.com Wed May 18 03:54:12 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 18 May 2016 09:54:12 +0200 Subject: [cdi-dev] CDI-519 notes Message-ID: <573C1FA4.90906@redhat.com> Hi all, John is questioning the clarification introduced in CDI-519. I think it's correct although not quite intuitive. Below are some notes we should consider (I know it's long but the topic is quite complicated): CreationalContext ================= Besides other things, holds the references to all depenent bean instances together with their CCs (for normal scopes this is the responsibility of the context). So that these could be correctly destroyed when CC.release() is called. Note that the context must pass the same instance of CC to Contextual.destroy() that it passed to Contextual.create() when it created the instance. Possible "leak" description =========================== The problem is if an Instance is injected into a normal scoped bean Foo and is used to get other @Dependent bean instances via Instance.get(). Each of this call returns a new depenent bean instance bound to the lifecycle of the Instance, which is also depenent and so it's effectively bound to the lifecycle of Foo. And that was the original motivation to introduce Instance.destroy(). Instance.select() ================= The spec states the select() method returns a child Instance. What is that "child" is not defined though. In Weld, a child Instance shares the CreationalContext of the parent Instance. And I think this makes sense. CDI-519 summary =============== Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object. The reason: a dependent bean instance does not know the object it depends on. So if we pass a dependent bean instance it must be "managed" by the CC of the Instance. Otherwise, we would not be able to destroy the bean instance and all its dependent dependencies correctly. From the spec point of view it's clear: "An instance of a bean with scope @Dependent obtained by direct invocation of an Instance is a dependent object of the instance of Instance." A dependent bean instance is bound to the lifecycle of Instance (or one of its child) so the Instance should be responsible for destroying it. Done. From the user point of view: I don't think it's a big problem. BTW it does not work in any CDI 1.1+ version of Weld. I'm not sure about OWB. Impl notes ========== If we allow this then we would probably have to create some central registry of CCs and during Instance.destroy() iterate over all these CCs and try to destroy given depenent bean instance. This will be complicated, error-prone and inefficient. Thanks, -- Martin Kouba Software Engineer Red Hat, Czech Republic From EMIJIANG at uk.ibm.com Wed May 18 05:21:13 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Wed, 18 May 2016 10:21:13 +0100 Subject: [cdi-dev] CDI-519 notes In-Reply-To: <573C1FA4.90906@redhat.com> References: <573C1FA4.90906@redhat.com> Message-ID: <201605180921.u4I9LHtv021902@d06av05.portsmouth.uk.ibm.com> Thank you Martin for the useful summary! +1: only support the Instance.destroy() to destroy the depended scoped objects created by the same Instance object. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Martin Kouba To: cdi-dev , Date: 18/05/2016 08:55 Subject: [cdi-dev] CDI-519 notes Sent by: cdi-dev-bounces at lists.jboss.org Hi all, John is questioning the clarification introduced in CDI-519. I think it's correct although not quite intuitive. Below are some notes we should consider (I know it's long but the topic is quite complicated): CreationalContext ================= Besides other things, holds the references to all depenent bean instances together with their CCs (for normal scopes this is the responsibility of the context). So that these could be correctly destroyed when CC.release() is called. Note that the context must pass the same instance of CC to Contextual.destroy() that it passed to Contextual.create() when it created the instance. Possible "leak" description =========================== The problem is if an Instance is injected into a normal scoped bean Foo and is used to get other @Dependent bean instances via Instance.get(). Each of this call returns a new depenent bean instance bound to the lifecycle of the Instance, which is also depenent and so it's effectively bound to the lifecycle of Foo. And that was the original motivation to introduce Instance.destroy(). Instance.select() ================= The spec states the select() method returns a child Instance. What is that "child" is not defined though. In Weld, a child Instance shares the CreationalContext of the parent Instance. And I think this makes sense. CDI-519 summary =============== Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object. The reason: a dependent bean instance does not know the object it depends on. So if we pass a dependent bean instance it must be "managed" by the CC of the Instance. Otherwise, we would not be able to destroy the bean instance and all its dependent dependencies correctly. From the spec point of view it's clear: "An instance of a bean with scope @Dependent obtained by direct invocation of an Instance is a dependent object of the instance of Instance." A dependent bean instance is bound to the lifecycle of Instance (or one of its child) so the Instance should be responsible for destroying it. Done. From the user point of view: I don't think it's a big problem. BTW it does not work in any CDI 1.1+ version of Weld. I'm not sure about OWB. Impl notes ========== If we allow this then we would probably have to create some central registry of CCs and during Instance.destroy() iterate over all these CCs and try to destroy given depenent bean instance. This will be complicated, error-prone and inefficient. Thanks, -- Martin Kouba Software Engineer Red Hat, Czech Republic _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160518/bb0fcea4/attachment.html From issues at jboss.org Wed May 18 05:24:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 18 May 2016 05:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-602) Unmanaged.UnmanagedInstance.disposed is never to true In-Reply-To: References: Message-ID: Martin Kouba created CDI-602: -------------------------------- Summary: Unmanaged.UnmanagedInstance.disposed is never to true Key: CDI-602 URL: https://issues.jboss.org/browse/CDI-602 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 2.0-EDR1, 1.2.Final Reporter: Martin Kouba As a result an {{IllegalStateException}} is never thrown if any method is called on an instance that has already been disposed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed May 18 05:25:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 18 May 2016 05:25:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-602) Unmanaged.UnmanagedInstance.disposed is never set to true In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-602: ----------------------------- Summary: Unmanaged.UnmanagedInstance.disposed is never set to true (was: Unmanaged.UnmanagedInstance.disposed is never to true) > Unmanaged.UnmanagedInstance.disposed is never set to true > --------------------------------------------------------- > > Key: CDI-602 > URL: https://issues.jboss.org/browse/CDI-602 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Martin Kouba > > As a result an {{IllegalStateException}} is never thrown if any method is called on an instance that has already been disposed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From christian at kaltepoth.de Thu May 19 12:47:27 2016 From: christian at kaltepoth.de (Christian Kaltepoth) Date: Thu, 19 May 2016 18:47:27 +0200 Subject: [cdi-dev] BeanManager visiblity and container archives Message-ID: Hey all, I would like to bring up an issue that we ran into while preparing Ozark (the MVC 1.0 RI) to be usable as a container module in Glassfish. We discussed this issue on Slack and discovered that Mojarra (JSF) and Soteria (Security) had similar issues. MVC 1.0 defines some extension points that users and 3rd party libraries can implement to provide additional functionality. MVC uses CDI for looking up all implementations of these extension point interfaces. Similar concepts are used in in JSF. Historically JSF uses factories which users can implement and register via faces-config.xml. Now for Java EE 8 it was decided to prefer CDI to obtain such custom extension point implementations (ViewHandler, NavigationHandler, etc). So basically JSF uses a similar mechanism to lookup implementations of certain interfaces like MVC does. As of today Ozark is basically a standard bean archive deployed together with the application (in /WEB-INF/lib). Now we want to prepare Ozark to be usable as a Glassfish module which is provided by the container. As CDI doesn't discover bean archives installed as part of the container, we wanted to basically remove beans.xml and provide an portable extension which registers the required annotated types required for Ozark. AFAIK Mojarra and Soteria are also doing it this way. Now as soon as we do this, things are getting weird. There are various ways to get a BeanManager to lookup beans provided by the application: - CDI.current().getBeanManager() - @Inject BeanManager - JNDI lookup Now if we try to lookup beans deployed with the application (in /WEB-INF/classes or in a library in /WEB-INF/lib) we don't get consistent results (many thanks to Arjan Tijms for doing all the testing): - In Glassfish we don't see application beans if we use the injected BeanManager. Looking up the BeanManager via JNDI or using CDI.current().getBeanManager() works fine. - In Wildfly CDi.current() doesn't seem to find beans deployed with the application. The injected BeanManager and the one looked up via JNDI works fine. So it looks like there are quite some inconsistencies between implementations here. *To sum it up:* In Java EE 8 more and more specs rely heavily on CDI. And many specs allow the user and 3rd party libraries to implement interfaces to extend functionality. But it looks like looking up such beans deployed with the application from a container archive isn't working in a consistent way. I hope my explanation of this complicated topic isn't too bad. I hope that we can start some discussion around this. Some of you already joined the discussion on Slack and the corresponding pull request, but I would prefer to discuss this here. :) Christian -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160519/21624d6e/attachment.html From arjan.tijms at gmail.com Thu May 19 13:10:26 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 19 May 2016 19:10:26 +0200 Subject: [cdi-dev] BeanManager visiblity and container archives In-Reply-To: References: Message-ID: Hi, Thanks for the writeup! A couple of things spring to mind. One thing is to clarify which version of the bean manager @Inject, CDI.current() and a JNDI lookup should get/use. Depending on the outcome of that, maybe it's useful to define several constants and/or JNDI entries to more specifically define which bean manager should be used. E.g. CDI.current(CONTAINER) // Only sees beans in the container archive CDI.current(APPLICATION) // Only sees beans in the application archive CDI.current(CONTAINER, APPLICATION) // beans in container and application etc In an EAR there are even some more options, but EARS and CDI are already problematic, so maybe not go there just yet. Similar variations may be used for JNDI lookups: initialContext.lookup("java:comp/BeanManagers/container") initialContext.lookup("java:comp/BeanManagers/application") initialContext.lookup("java:comp/BeanManagers/container_application") Not sure if this is the best way forward, but just throwing the idea out there. Kind regards, Arjan Tijms On Thu, May 19, 2016 at 6:47 PM, Christian Kaltepoth wrote: > Hey all, > > I would like to bring up an issue that we ran into while preparing Ozark > (the MVC 1.0 RI) to be usable as a container module in Glassfish. We > discussed this issue on Slack and discovered that Mojarra (JSF) and Soteria > (Security) had similar issues. > > MVC 1.0 defines some extension points that users and 3rd party libraries > can implement to provide additional functionality. MVC uses CDI for looking > up all implementations of these extension point interfaces. Similar > concepts are used in in JSF. Historically JSF uses factories which users > can implement and register via faces-config.xml. Now for Java EE 8 it was > decided to prefer CDI to obtain such custom extension point implementations > (ViewHandler, NavigationHandler, etc). So basically JSF uses a similar > mechanism to lookup implementations of certain interfaces like MVC does. > > As of today Ozark is basically a standard bean archive deployed together > with the application (in /WEB-INF/lib). Now we want to prepare Ozark to be > usable as a Glassfish module which is provided by the container. As CDI > doesn't discover bean archives installed as part of the container, we > wanted to basically remove beans.xml and provide an portable extension > which registers the required annotated types required for Ozark. AFAIK > Mojarra and Soteria are also doing it this way. Now as soon as we do this, > things are getting weird. > > There are various ways to get a BeanManager to lookup beans provided by > the application: > > - CDI.current().getBeanManager() > - @Inject BeanManager > - JNDI lookup > > Now if we try to lookup beans deployed with the application (in > /WEB-INF/classes or in a library in /WEB-INF/lib) we don't get consistent > results (many thanks to Arjan Tijms for doing all the testing): > > - In Glassfish we don't see application beans if we use the injected > BeanManager. Looking up the BeanManager via JNDI or using > CDI.current().getBeanManager() works fine. > - In Wildfly CDi.current() doesn't seem to find beans deployed with > the application. The injected BeanManager and the one looked up via JNDI > works fine. > > So it looks like there are quite some inconsistencies between > implementations here. > > *To sum it up:* In Java EE 8 more and more specs rely heavily on CDI. And > many specs allow the user and 3rd party libraries to implement interfaces > to extend functionality. But it looks like looking up such beans deployed > with the application from a container archive isn't working in a consistent > way. > > I hope my explanation of this complicated topic isn't too bad. I hope that > we can start some discussion around this. Some of you already joined the > discussion on Slack and the corresponding pull request, but I would prefer > to discuss this here. :) > > Christian > > > -- > Christian Kaltepoth > Blog: http://blog.kaltepoth.de/ > Twitter: http://twitter.com/chkal > GitHub: https://github.com/chkal > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160519/ffc43e4e/attachment.html From mkouba at redhat.com Fri May 20 03:07:09 2016 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 20 May 2016 09:07:09 +0200 Subject: [cdi-dev] BeanManager visiblity and container archives In-Reply-To: References: Message-ID: <573EB79D.5080408@redhat.com> Dne 19.5.2016 v 18:47 Christian Kaltepoth napsal(a): > Hey all, > > I would like to bring up an issue that we ran into while preparing Ozark > (the MVC 1.0 RI) to be usable as a container module in Glassfish. We > discussed this issue on Slack and discovered that Mojarra (JSF) and > Soteria (Security) had similar issues. > > MVC 1.0 defines some extension points that users and 3rd party libraries > can implement to provide additional functionality. MVC uses CDI for > looking up all implementations of these extension point interfaces. > Similar concepts are used in in JSF. Historically JSF uses factories > which users can implement and register via faces-config.xml. Now for > Java EE 8 it was decided to prefer CDI to obtain such custom extension > point implementations (ViewHandler, NavigationHandler, etc). So > basically JSF uses a similar mechanism to lookup implementations of > certain interfaces like MVC does. > > As of today Ozark is basically a standard bean archive deployed together > with the application (in /WEB-INF/lib). Now we want to prepare Ozark to > be usable as a Glassfish module which is provided by the container. > > As CDI doesn't discover bean archives installed as part of the container, Well, this is not necessarily true (although it's not required by the CDI spec). Basically, it's the responsibility of the integrator to put together the "final deployment structure". > we wanted to basically remove beans.xml and provide an portable > extension which registers the required annotated types required for > Ozark. AFAIK Mojarra and Soteria are also doing it this way. Now as soon > as we do this, things are getting weird. > > There are various ways to get a BeanManager to lookup beans provided by > the application: > > * CDI.current().getBeanManager() > * @Inject BeanManager > * JNDI lookup > > Now if we try to lookup beans deployed with the application (in > /WEB-INF/classes or in a library in /WEB-INF/lib) we don't get > consistent results (many thanks to Arjan Tijms for doing all the testing): > > * In Glassfish we don't see application beans if we use the injected > BeanManager. Looking up the BeanManager via JNDI or using > CDI.current().getBeanManager() works fine. > * In Wildfly CDi.current() doesn't seem to find beans deployed with > the application. The injected BeanManager and the one looked up via > JNDI works fine. > > So it looks like there are quite some inconsistencies between > implementations here. > > _To sum it up:_ In Java EE 8 more and more specs rely heavily on CDI. > And many specs allow the user and 3rd party libraries to implement > interfaces to extend functionality. But it looks like looking up such > beans deployed with the application from a container archive isn't > working in a consistent way. > > I hope my explanation of this complicated topic isn't too bad. I hope > that we can start some discussion around this. One important note - BeanManager is NOT a "central management API" for CDI. It has a context (or at least few methods must be called in this context) - a module or library containing the class into which it was injected or the Java EE component from whose JNDI environment namespace the BM was obtained. CDI.current().getBeanManager() is a bit problematic. Esp. from impl. point of view. We should definitely think about this kind of integration issues. > Some of you already > joined the discussion on Slack and the corresponding pull request, but I > would prefer to discuss this here. :) > > Christian > > > -- > Christian Kaltepoth > Blog: http://blog.kaltepoth.de/ > Twitter: http://twitter.com/chkal > GitHub: https://github.com/chkal > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From antoine at sabot-durand.net Sun May 22 05:07:24 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Sun, 22 May 2016 09:07:24 +0000 Subject: [cdi-dev] Need contribution on the new "Learn" section of the site Message-ID: Hi guys, I open a new "learn" section on the Website today [1]. It needs contribution to be less empty. So take time to add your article or documents to it with a PR. The ecosystem section [2] is also waiting for contribution to add framework based or supporting CDI (Tamaya, Infinispan...); I also published a CDI user guide based on Weld documentation (all the Weld reference and specificities were removed)[3], which can probably be improved. Source of this doc can be found here [4] Thanks for your help. Antoine [1] http://www.cdi-spec.org/learn/ [2] http://www.cdi-spec.org/ecosystem/ [3] http://docs.jboss.org/cdi/learn/userguide/CDI-user-guide.html [4] https://github.com/cdi-spec/cdi-user-guide -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160522/ea80b55d/attachment.html From john.d.ament at gmail.com Tue May 24 08:57:21 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 24 May 2016 12:57:21 +0000 Subject: [cdi-dev] Meeting on? Message-ID: Just wanted to check, is today's meeting still planned? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160524/8ae0552d/attachment.html From antoine at sabot-durand.net Tue May 24 09:03:07 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 24 May 2016 13:03:07 +0000 Subject: [cdi-dev] Meeting on? In-Reply-To: References: Message-ID: Yes, we'll try to take a decision about builder PR Antoine Le mar. 24 mai 2016 ? 14:58, John D. Ament a ?crit : > Just wanted to check, is today's meeting still planned? > > John > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160524/64dd3fc8/attachment.html From mpaluch at paluch.biz Tue May 24 09:20:01 2016 From: mpaluch at paluch.biz (Mark Paluch) Date: Tue, 24 May 2016 15:20:01 +0200 Subject: [cdi-dev] Meeting on? In-Reply-To: References: Message-ID: <4BB2E17E-45E2-46A2-AD95-B8CF91DBCEB6@paluch.biz> Could you also add CDI-599 New lifecycle event to handle deployment/statup errors to the topics? I?d like to get an idea how to proceed on this one to progress on Mark Struberg?s UnproxyableResolutionException for beans with non-private final methods. Thanks a lot, Mark > Am 24.05.2016 um 15:03 schrieb Antoine Sabot-Durand : > > Yes, we'll try to take a decision about builder PR > > Antoine > > Le mar. 24 mai 2016 ? 14:58, John D. Ament > a ?crit : > Just wanted to check, is today's meeting still planned? > > John > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20160524/5ece5a62/attachment.html From antoine at sabot-durand.net Wed May 25 05:50:00 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 25 May 2016 09:50:00 +0000 Subject: [cdi-dev] Fwd: [jsr366-experts] Common Annotations Maintenance Draft In-Reply-To: <573E3722.6060907@oracle.com> References: <573E3722.6060907@oracle.com> Message-ID: Hi Guys, I forward below, the mail Linda sent to Java EE EG ML last week regarding MR of Commons annotations. For me it's fine but you may want to have a look. Antoine ---------- Forwarded message --------- From: Linda DeMichiel Date: jeu. 19 mai 2016 ? 23:59 Subject: [jsr366-experts] Common Annotations Maintenance Draft To: I've uploaded drafts of the Common Annotation spec + javadocs to https://java.net/projects/javaee-spec/downloads. The functional changes are the addition of @Target(PARAMETER) to the Priority annotation as requested by the CDI expert group and making the Resource and DataSourceDefinition annotations repeatable. I've also corrected some minor inconsistencies between this spec and the Interceptor spec on PostConstruct and PreDestroy, and replaced the example in section 2.1 referencing WebService/WebMethod, which was inconsistent with the JAX-WS and Web Services Metadata specs. All other changes are intended as purely editorial. If you catch anything amiss, please let me know as soon as possible, as I am planning to submit these materials to the JCP next week to initiate a Maintenance Review. thanks, -Linda -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160525/33534b30/attachment.html From antoine at sabot-durand.net Wed May 25 08:33:48 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 25 May 2016 12:33:48 +0000 Subject: [cdi-dev] Builder API merged Message-ID: Hi all, As decided yesterday, I merged the Builder/configurator code.It's certainly not complete and some of the feedback (from John, Antonin and others) should be considered, but it appeared easier to accept this PR to work from a known and validated code. I rebased PR 290 (Enhanced SE API) on it to make it clearer. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160525/7063a7fc/attachment-0001.html From issues at jboss.org Wed May 25 09:32:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 25 May 2016 09:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-603) Create separate doc section for each Annotated*Configurator In-Reply-To: References: Message-ID: Matej Novotny created CDI-603: --------------------------------- Summary: Create separate doc section for each Annotated*Configurator Key: CDI-603 URL: https://issues.jboss.org/browse/CDI-603 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 2.0-EDR1 Reporter: Matej Novotny Currently, doc section 11.4.1 "AnnotatedTypeConfigurator?SPI" covers all types of Annotated configurators (see below). That is: * {{AnnotatedTypeConfigurator}} * {{AnnotatedFieldConfigurator}} * {{AnnotatedMethodConfigurator}} * {{AnnotatedConstructorConfigurator}} * {{AnnotatedParameterConfigurator}} While {{AnnotatedTypeConfigurator}} is the entry point for all the others, I think it would be better to have a separate doc section for each configurator. It would make it much more readable. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu May 26 02:11:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 26 May 2016 02:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-603) Create separate doc section for each Annotated*Configurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-603: ---------------------------------------- Assignee: Antoine Sabot-Durand > Create separate doc section for each Annotated*Configurator > ----------------------------------------------------------- > > Key: CDI-603 > URL: https://issues.jboss.org/browse/CDI-603 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR1 > Reporter: Matej Novotny > Assignee: Antoine Sabot-Durand > > Currently, doc section 11.4.1 "AnnotatedTypeConfigurator?SPI" covers all types of Annotated configurators (see below). That is: > * {{AnnotatedTypeConfigurator}} > * {{AnnotatedFieldConfigurator}} > * {{AnnotatedMethodConfigurator}} > * {{AnnotatedConstructorConfigurator}} > * {{AnnotatedParameterConfigurator}} > While {{AnnotatedTypeConfigurator}} is the entry point for all the others, I think it would be better to have a separate doc section for each configurator. It would make it much more readable. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu May 26 02:11:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 26 May 2016 02:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-603) Create separate doc section for each Annotated*Configurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-603 started by Antoine Sabot-Durand. ------------------------------------------------ > Create separate doc section for each Annotated*Configurator > ----------------------------------------------------------- > > Key: CDI-603 > URL: https://issues.jboss.org/browse/CDI-603 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR1 > Reporter: Matej Novotny > Assignee: Antoine Sabot-Durand > > Currently, doc section 11.4.1 "AnnotatedTypeConfigurator?SPI" covers all types of Annotated configurators (see below). That is: > * {{AnnotatedTypeConfigurator}} > * {{AnnotatedFieldConfigurator}} > * {{AnnotatedMethodConfigurator}} > * {{AnnotatedConstructorConfigurator}} > * {{AnnotatedParameterConfigurator}} > While {{AnnotatedTypeConfigurator}} is the entry point for all the others, I think it would be better to have a separate doc section for each configurator. It would make it much more readable. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Thu May 26 03:16:36 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 26 May 2016 09:16:36 +0200 Subject: [cdi-dev] Fwd: [jsr366-experts] Common Annotations Maintenance Draft In-Reply-To: References: <573E3722.6060907@oracle.com> Message-ID: <5746A2D4.8080602@redhat.com> I wonder whether it makes sense to restrict @Priority target at all? Specs/libs/frameworks might use it for methods, fields, etc. Martin Dne 25.5.2016 v 11:50 Antoine Sabot-Durand napsal(a): > Hi Guys, > > I forward below, the mail Linda sent to Java EE EG ML last week > regarding MR of Commons annotations. For me it's fine but you may want > to have a look. > > Antoine > > ---------- Forwarded message --------- > From: Linda DeMichiel > > Date: jeu. 19 mai 2016 ? 23:59 > Subject: [jsr366-experts] Common Annotations Maintenance Draft > To: > > > > I've uploaded drafts of the Common Annotation spec + javadocs > to https://java.net/projects/javaee-spec/downloads. > > The functional changes are the addition of @Target(PARAMETER) to > the Priority annotation as requested by the CDI expert group > and making the Resource and DataSourceDefinition annotations > repeatable. > > I've also corrected some minor inconsistencies between this spec and > the Interceptor spec on PostConstruct and PreDestroy, and replaced the > example in section 2.1 referencing WebService/WebMethod, which was > inconsistent with the JAX-WS and Web Services Metadata specs. > > All other changes are intended as purely editorial. > > If you catch anything amiss, please let me know as soon as > possible, as I am planning to submit these materials to the > JCP next week to initiate a Maintenance Review. > > thanks, > > -Linda > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 mkouba at redhat.com Thu May 26 03:20:51 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 26 May 2016 09:20:51 +0200 Subject: [cdi-dev] CDI SE and synthetic bean archives Message-ID: <5746A3D3.1030101@redhat.com> Hi all, few notes WRT discussion about CDI SE and synthetic bean archives (EG mtg, 2016-05-24): * Weld SE does not scan JDK classes ** by default, only jars/dirs with beans.xml are considered ** if org.jboss.weld.se.scan.classpath.entries set to true, Weld SE scans the class path entries and implicit bean archives which don't contain a beans.xml file are also supported; but rt.jar and friends are not listed in the "java.class.path" system property ** AFAIK there is no other way how to implement this in a better way Synthetic bean archive was originally intended as a feature for power users who either know all the beans beforehand (possibly with discovery disabled) or want to add some extra beans (if discovery is enabled). That's the reason why it behaves as it has bean discorey mode "all". If I understand John's concerns, it's all about the case of adding packages (which itself is problematic because of java limitations). If so, we could introduce something like org.jboss.shrinkwrap.api.container.ClassContainer.addPackages(boolean, Filter, Package...). And provide some default "Filter" implementations. Martin From john.d.ament at gmail.com Thu May 26 06:42:53 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 26 May 2016 10:42:53 +0000 Subject: [cdi-dev] Looking for Feedback on PR #291 Message-ID: All, As mentioned during Tuesday's meeting, I'm looking for more feedback on PR #291 - the context control APIs. I think the current version is pretty snazy, and thanks especially to Martin for his input on it thus far. I'm looking for more input though, especially from the OWB team (Mark Struberg??) on whether its realistic or not. https://github.com/cdi-spec/cdi/pull/291 John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160526/fb0f7cf6/attachment.html From issues at jboss.org Thu May 26 07:47:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 26 May 2016 07:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-604) javax.enterprise.inject.spi.builder package should be renamed In-Reply-To: References: Message-ID: Tomas Remes created CDI-604: ------------------------------- Summary: javax.enterprise.inject.spi.builder package should be renamed Key: CDI-604 URL: https://issues.jboss.org/browse/CDI-604 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 2.0-EDR2 Reporter: Tomas Remes Since there are no builders in this package we should rename this one. So far there were proposals like {{configurators}} and {{configuration}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu May 26 20:56:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 26 May 2016 20:56:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-605) Add some built in predicates In-Reply-To: References: Message-ID: John Ament created CDI-605: ------------------------------ Summary: Add some built in predicates Key: CDI-605 URL: https://issues.jboss.org/browse/CDI-605 Project: CDI Specification Issues Issue Type: Feature Request Components: Javadoc and API Reporter: John Ament During review, Antonin pointed out some useful predicates that should be reusable in the context of CDI. https://github.com/astefanutti/camel-cdi/blob/0c9ae969c5721e655da3d396d17ec98a6f1aecaa/impl/src/main/java/org/apache/camel/cdi/CdiSpiHelper.java#L49-L57 {code} static Predicate hasType(Type type) { requireNonNull(type); return bean -> bean.getTypes().contains(type); } static Predicate isAnnotationType(Class clazz) { requireNonNull(clazz); return annotation -> clazz.equals(annotation.annotationType()); } {code} We should consider adding them. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu May 26 21:08:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 26 May 2016 21:08:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-606) Add missing read methods In-Reply-To: References: Message-ID: John Ament created CDI-606: ------------------------------ Summary: Add missing read methods Key: CDI-606 URL: https://issues.jboss.org/browse/CDI-606 Project: CDI Specification Issues Issue Type: Feature Request Components: Javadoc and API Reporter: John Ament Add missing read() methods to Annotated*Configurator to read attributes from an existing source. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu May 26 21:10:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 26 May 2016 21:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-606) Add missing read methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-606: --------------------------- Description: Add a read method that takes a method and can create a bean configurator from it. (was: Add missing read() methods to Annotated*Configurator to read attributes from an existing source.) > Add missing read methods > ------------------------ > > Key: CDI-606 > URL: https://issues.jboss.org/browse/CDI-606 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Javadoc and API > Reporter: John Ament > > Add a read method that takes a method and can create a bean configurator from it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu May 26 21:12:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 26 May 2016 21:12:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-607) Register a bean from a producer In-Reply-To: References: Message-ID: John Ament created CDI-607: ------------------------------ Summary: Register a bean from a producer Key: CDI-607 URL: https://issues.jboss.org/browse/CDI-607 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Assuming I've defined a custom implementation of Producer, register it as a bean via addBean(). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu May 26 21:15:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 26 May 2016 21:15:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-608) Fix generics used within addObserverMethod In-Reply-To: References: Message-ID: John Ament created CDI-608: ------------------------------ Summary: Fix generics used within addObserverMethod Key: CDI-608 URL: https://issues.jboss.org/browse/CDI-608 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament the following code doesn?t compile: {code} cdiEventEndpoints.values().stream().forEach(endpoint -> abd.addObserverMethod() .beanClass(CdiEventComponent.class) .observedType(endpoint.getType()) .qualifiers(endpoint.getQualifiers()) .notifyWith(endpoint::notify); {code} I need to write: {code} cdiEventEndpoints.values().stream().forEach(endpoint -> addCdiEventObserver(abd, endpoint)); private void addCdiEventObserver(AfterBeanDiscovery abd, CdiEventEndpoint endpoint) { abd.addObserverMethod() .beanClass(CdiEventComponent.class) .observedType(endpoint.getType()) .qualifiers(endpoint.getQualifiers()) .notifyWith(endpoint::notify); } {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri May 27 01:53:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 27 May 2016 01:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-609) Clarify behaviour of ObserverMethodConfigurator read In-Reply-To: References: Message-ID: Tomas Remes created CDI-609: ------------------------------- Summary: Clarify behaviour of ObserverMethodConfigurator read Key: CDI-609 URL: https://issues.jboss.org/browse/CDI-609 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 2.0-EDR2 Reporter: Tomas Remes It's not clear what should happen in case if you are using ObserverMethodConfigurator and attempting to read from a method ({{Method}}, {{AnnotatedMethod}}) which doesn't have any parameter annotated @Observes. E.g something like this in ABD lifecycle event ("observesMelon" doesn't have any @Observes): {code} Method melonMethod = FruitObserver.class.getMethod("observesMelon", Melon.class); abd.addObserverMethod().read(melonMethod) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri May 27 03:11:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 27 May 2016 03:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-609) Clarify behaviour of ObserverMethodConfigurator read In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243812#comment-13243812 ] Martin Kouba commented on CDI-609: ---------------------------------- I think we should probably throw an {{IllegalArgumentException}} - this is what we're going to implement as a part of WELD-2159. > Clarify behaviour of ObserverMethodConfigurator read > ------------------------------------------------------- > > Key: CDI-609 > URL: https://issues.jboss.org/browse/CDI-609 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR2 > Reporter: Tomas Remes > > It's not clear what should happen in case if you are using ObserverMethodConfigurator and attempting to read from a method ({{Method}}, {{AnnotatedMethod}}) which doesn't have any parameter annotated @Observes. E.g something like this in ABD lifecycle event ("observesMelon" doesn't have any @Observes): > {code} > Method melonMethod = FruitObserver.class.getMethod("observesMelon", Melon.class); > abd.addObserverMethod().read(melonMethod) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri May 27 03:16:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 27 May 2016 03:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-608) Fix generics used within addObserverMethod In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243814#comment-13243814 ] Martin Kouba commented on CDI-608: ---------------------------------- What's the type of {{cdiEventEndpoints}}? > Fix generics used within addObserverMethod > ------------------------------------------ > > Key: CDI-608 > URL: https://issues.jboss.org/browse/CDI-608 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > the following code doesn?t compile: > {code} > cdiEventEndpoints.values().stream().forEach(endpoint -> abd.addObserverMethod() > .beanClass(CdiEventComponent.class) > .observedType(endpoint.getType()) > .qualifiers(endpoint.getQualifiers()) > .notifyWith(endpoint::notify); > {code} > I need to write: > {code} > cdiEventEndpoints.values().stream().forEach(endpoint -> addCdiEventObserver(abd, endpoint)); > private void addCdiEventObserver(AfterBeanDiscovery abd, CdiEventEndpoint endpoint) { > abd.addObserverMethod() > .beanClass(CdiEventComponent.class) > .observedType(endpoint.getType()) > .qualifiers(endpoint.getQualifiers()) > .notifyWith(endpoint::notify); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri May 27 06:28:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 27 May 2016 06:28:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-609) Clarify behaviour of ObserverMethodConfigurator read In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243922#comment-13243922 ] Tomas Remes commented on CDI-609: --------------------------------- While I am implementing TCK tests I am starting to dislike those read methods at all TBH. They appear to me as a nasty workaround (I don't like the fact that when I want to create fresh new observer method I need to read some existing. It doesn't really make sense to me) . I would really rather go with something like https://github.com/tremes/cdi/commit/6ebc86ad3fdd34a491c53dc90628fbfecbaee5c8. It's much cleaner IMHO - just allow configuration (like qualifiers, reception, isAsync etc.) within {{ProcessObserverMethod}} but things like setting observedType and beanClass allow only within {{AfterBeanDiscovery}} when you really want to add new observer method. With this you can do https://gist.github.com/tremes/84c825a62cd3392c124814d036ee1239. > Clarify behaviour of ObserverMethodConfigurator read > ------------------------------------------------------- > > Key: CDI-609 > URL: https://issues.jboss.org/browse/CDI-609 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR2 > Reporter: Tomas Remes > > It's not clear what should happen in case if you are using ObserverMethodConfigurator and attempting to read from a method ({{Method}}, {{AnnotatedMethod}}) which doesn't have any parameter annotated @Observes. E.g something like this in ABD lifecycle event ("observesMelon" doesn't have any @Observes): > {code} > Method melonMethod = FruitObserver.class.getMethod("observesMelon", Melon.class); > abd.addObserverMethod().read(melonMethod) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri May 27 08:38:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Fri, 27 May 2016 08:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-608) Fix generics used within addObserverMethod In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244000#comment-13244000 ] John Ament commented on CDI-608: -------------------------------- Not sure, what type does it need to be to support this? > Fix generics used within addObserverMethod > ------------------------------------------ > > Key: CDI-608 > URL: https://issues.jboss.org/browse/CDI-608 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > the following code doesn?t compile: > {code} > cdiEventEndpoints.values().stream().forEach(endpoint -> abd.addObserverMethod() > .beanClass(CdiEventComponent.class) > .observedType(endpoint.getType()) > .qualifiers(endpoint.getQualifiers()) > .notifyWith(endpoint::notify); > {code} > I need to write: > {code} > cdiEventEndpoints.values().stream().forEach(endpoint -> addCdiEventObserver(abd, endpoint)); > private void addCdiEventObserver(AfterBeanDiscovery abd, CdiEventEndpoint endpoint) { > abd.addObserverMethod() > .beanClass(CdiEventComponent.class) > .observedType(endpoint.getType()) > .qualifiers(endpoint.getQualifiers()) > .notifyWith(endpoint::notify); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri May 27 08:46:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 27 May 2016 08:46:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-608) Fix generics used within addObserverMethod In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244010#comment-13244010 ] Martin Kouba commented on CDI-608: ---------------------------------- I'm not sure. But we need the complete information to simulate the problem. > Fix generics used within addObserverMethod > ------------------------------------------ > > Key: CDI-608 > URL: https://issues.jboss.org/browse/CDI-608 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > the following code doesn?t compile: > {code} > cdiEventEndpoints.values().stream().forEach(endpoint -> abd.addObserverMethod() > .beanClass(CdiEventComponent.class) > .observedType(endpoint.getType()) > .qualifiers(endpoint.getQualifiers()) > .notifyWith(endpoint::notify); > {code} > I need to write: > {code} > cdiEventEndpoints.values().stream().forEach(endpoint -> addCdiEventObserver(abd, endpoint)); > private void addCdiEventObserver(AfterBeanDiscovery abd, CdiEventEndpoint endpoint) { > abd.addObserverMethod() > .beanClass(CdiEventComponent.class) > .observedType(endpoint.getType()) > .qualifiers(endpoint.getQualifiers()) > .notifyWith(endpoint::notify); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat May 28 14:58:00 2016 From: issues at jboss.org (=?UTF-8?Q?Ondrej_Mih=C3=A1lyi_=28JIRA=29?=) Date: Sat, 28 May 2016 14:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-403) why decorator requires interface In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244395#comment-13244395 ] Ondrej Mih?lyi commented on CDI-403: ------------------------------------ I think that it is worth to remove the requirement on interface in CDI2. It should be fairly easy to specify additional scenario, where the decorator can extend the decorated class => it would inherit all public methods as if all methods would be exposed by an interface, and would decorate all beans injected by their class instead of by interface. Currently, the way to work around this is to declare such decorator using {{@Specialized}} + {{@Alternative}} and delegating to methods in predecessor. This is confusing in the code, as the decorator pattern is implemented using to other patterns. And it is not the same as delegate to another injected delegate, as multiple decorators cannot be chained: {code:java} @Specialized @Alternative public class MyBeanDecorator extends MyBean { @Overrides public String hello() { return super.hello() + ", world!"; // decorates by adding ", world!" after result of hello() } } {code} > why decorator requires interface > -------------------------------- > > Key: CDI-403 > URL: https://issues.jboss.org/browse/CDI-403 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mathieu Lachance > > As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224), > would it be possible to revisit why decorator requires an interface ? > I do not understand the semantic difference between: > 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. > 2. a decorator to be a concrete class which extends a another class, which delegates to the same class. > Why 1. should be allowed and why 2. should be disallowed ? > As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ? > It is kind of sad that only decorators requires an interface while all the others Java EE 6 features do not. > Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat May 28 15:48:00 2016 From: issues at jboss.org (=?UTF-8?Q?Ondrej_Mih=C3=A1lyi_=28JIRA=29?=) Date: Sat, 28 May 2016 15:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244396#comment-13244396 ] Ondrej Mih?lyi commented on CDI-552: ------------------------------------ Isn't this what DeltaSpike provides already with {{BeanProvider.injectFields(myObject)}}? https://deltaspike.apache.org/documentation/core.html#_beanprovider This method clearly only injects the dependencies, it does not invoke any lifecycle methods and does not add the object to any scope. It would be useful to make this into the CDI spec, such as {{CDI.current().injectDependencies(Object o)}}. It might also make sense to execute the lifecycle methods by {{CDI.current().invokePostConstruct(Object o)}} and {{invokePreDestroy(Object o}}, although they may be executed as directly on the object. > Add support for injection, decorators and interceptors on "new-ed" objects > -------------------------------------------------------------------------- > > Key: CDI-552 > URL: https://issues.jboss.org/browse/CDI-552 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Resolution > Affects Versions: 2.0-EDR1 > Reporter: Rogerio Liesenfeld > > The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs. > With this I mean: > 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]). > 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]). > 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object. > Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI: > {code} > MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI); > businessOp.performSomeBusinessOperation(otherArgs); > String result1 = businessOp.getResultXyz(); > List moreResultData = businessOp.getFinalData(); > {code} > ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans). > Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion). > For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do. > Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From ondrej.mihalyi at gmail.com Sat May 28 17:24:28 2016 From: ondrej.mihalyi at gmail.com (=?UTF-8?Q?Ondrej_Mih=C3=A1lyi?=) Date: Sat, 28 May 2016 23:24:28 +0200 Subject: [cdi-dev] API to chain Decorators programmatically? Message-ID: I think that Decorators are a great concept in CDI, but it cannot provide solution to a wide variety of problems where the general decorator pattern makes sense. AFAIK, it is not possible to chain decorators at runtime, in order to reuse the decorator mechanism to solve class explosion problem and create a flexible architecture, similar to what java.io API provides with chained input/output streams (subclasses of java.io.InputStream ). I think it would make sense to be able to apply decorators to a bean at runtime. What do you think about extending *Instance* class by adding a method like* Instance decorateWith(Class c)* as in the following example? @Inject Instance instance; ... DecoratedInterface decorated = instance.*decorateWith(Decorator1.class)* .decorateWith(Decorator2.class) .get(); I haven't find a way to do something similar using the current API, nor did I find any third-party CDI extension to provide something similar. Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160528/8dbc4442/attachment.html From arjan.tijms at gmail.com Sat May 28 17:36:49 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sat, 28 May 2016 23:36:49 +0200 Subject: [cdi-dev] API to chain Decorators programmatically? In-Reply-To: References: Message-ID: Hi, On Sat, May 28, 2016 at 11:24 PM, Ondrej Mih?lyi wrote: > I think it would make sense to be able to apply decorators to a bean at > runtime. > This sounds quite close to Mark Struberg's proposal regarding proxies. It's not just at inject time that you may wish to have a decorator applied, but also e.g. from a producer or the create() method of a Bean. I'm also seeing a use case here for applying interceptors to classes that are not your own. E.g. currently a decorator is typically your own class that can be applied to classes that are not your own, and an interceptor is often not your class that can be applied to classes that are your own. It would be useful to make this more flexible, so that if a library provides interceptor A and another library provides a bean X, an application can easily say that interceptor A should be applied to bean X (class level, or one of more methods). Similarly for decorators that could be provided as alternatives by a library and then on demand applied by the application to certain beans. Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160528/de842c9f/attachment.html From struberg at yahoo.de Tue May 31 02:51:06 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 31 May 2016 08:51:06 +0200 Subject: [cdi-dev] Looking for Feedback on PR #291 In-Reply-To: References: Message-ID: <3D2C60FD-E6CD-44E3-A116-7C98E01BAEAA@yahoo.de> Quick feedback: *) activate might be ambiguous. There is actually a ?start? and a ?activate on this very thread?. Think about @SessionScoped or @ConversationScoped. Not every new thread will start a new Context. Multiple threads might re-use the very same one. Now you need a way to explicitlely say which ?Session? (or Map) you like to attach to *) @ActivateRequestScope et al. Interesting idea but I fear it wont work out. Let?s stick with the @SessionScoped example: _which_ Session should get created/attached for the very thread? But it?s a start! Thanks for getting the ball rolling. LieGrue, strub > Am 26.05.2016 um 12:42 schrieb John D. Ament : > > All, > > As mentioned during Tuesday's meeting, I'm looking for more feedback on PR #291 - the context control APIs. I think the current version is pretty snazy, and thanks especially to Martin for his input on it thus far. I'm looking for more input though, especially from the OWB team (Mark Struberg??) on whether its realistic or not. > > https://github.com/cdi-spec/cdi/pull/291 > > > John > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 Tue May 31 02:52:14 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 31 May 2016 08:52:14 +0200 Subject: [cdi-dev] [jsr366-experts] Common Annotations Maintenance Draft In-Reply-To: <5746A2D4.8080602@redhat.com> References: <573E3722.6060907@oracle.com> <5746A2D4.8080602@redhat.com> Message-ID: <32B20138-C3C2-4F92-9620-8BA9090E7F91@yahoo.de> +1 It makes no sense to restrict the target for such a generic annotation. txs and LieGrue, strub > Am 26.05.2016 um 09:16 schrieb Martin Kouba : > > I wonder whether it makes sense to restrict @Priority target at all? > > Specs/libs/frameworks might use it for methods, fields, etc. > > Martin > > > Dne 25.5.2016 v 11:50 Antoine Sabot-Durand napsal(a): >> Hi Guys, >> >> I forward below, the mail Linda sent to Java EE EG ML last week >> regarding MR of Commons annotations. For me it's fine but you may want >> to have a look. >> >> Antoine >> >> ---------- Forwarded message --------- >> From: Linda DeMichiel > > >> Date: jeu. 19 mai 2016 ? 23:59 >> Subject: [jsr366-experts] Common Annotations Maintenance Draft >> To: > > >> >> >> I've uploaded drafts of the Common Annotation spec + javadocs >> to https://java.net/projects/javaee-spec/downloads. >> >> The functional changes are the addition of @Target(PARAMETER) to >> the Priority annotation as requested by the CDI expert group >> and making the Resource and DataSourceDefinition annotations >> repeatable. >> >> I've also corrected some minor inconsistencies between this spec and >> the Interceptor spec on PostConstruct and PreDestroy, and replaced the >> example in section 2.1 referencing WebService/WebMethod, which was >> inconsistent with the JAX-WS and Web Services Metadata specs. >> >> All other changes are intended as purely editorial. >> >> If you catch anything amiss, please let me know as soon as >> possible, as I am planning to submit these materials to the >> JCP next week to initiate a Maintenance Review. >> >> thanks, >> >> -Linda >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From antoine at sabot-durand.net Tue May 31 04:35:32 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 31 May 2016 08:35:32 +0000 Subject: [cdi-dev] Face to Face meeting approved (at last) Message-ID: Hi All, I received validation of our F2F meeting by Red Hat management. I understand that it's a bit late, but I need to know if you make it next week or should we postpone the meeting to late August early September ? Give me you favorite choice. ASAP of course ;). Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160531/3f37c5ba/attachment.html From mpaluch at paluch.biz Tue May 31 05:09:09 2016 From: mpaluch at paluch.biz (Mark Paluch) Date: Tue, 31 May 2016 11:09:09 +0200 Subject: [cdi-dev] [jsr366-experts] Common Annotations Maintenance Draft In-Reply-To: <32B20138-C3C2-4F92-9620-8BA9090E7F91@yahoo.de> References: <573E3722.6060907@oracle.com> <5746A2D4.8080602@redhat.com> <32B20138-C3C2-4F92-9620-8BA9090E7F91@yahoo.de> Message-ID: <306317A7-0319-4731-8C5B-DD9C98DE5712@paluch.biz> +1 That idea was all the time on my mind. Removing the restriction does not hurt and enables reusability. > Am 31.05.2016 um 08:52 schrieb Mark Struberg : > > +1 > > It makes no sense to restrict the target for such a generic annotation. > > txs and LieGrue, > strub > > >> Am 26.05.2016 um 09:16 schrieb Martin Kouba : >> >> I wonder whether it makes sense to restrict @Priority target at all? >> >> Specs/libs/frameworks might use it for methods, fields, etc. >> >> Martin >> >> >> Dne 25.5.2016 v 11:50 Antoine Sabot-Durand napsal(a): >>> Hi Guys, >>> >>> I forward below, the mail Linda sent to Java EE EG ML last week >>> regarding MR of Commons annotations. For me it's fine but you may want >>> to have a look. >>> >>> Antoine >>> >>> ---------- Forwarded message --------- >>> From: Linda DeMichiel >> > >>> Date: jeu. 19 mai 2016 ? 23:59 >>> Subject: [jsr366-experts] Common Annotations Maintenance Draft >>> To: >> > >>> >>> >>> I've uploaded drafts of the Common Annotation spec + javadocs >>> to https://java.net/projects/javaee-spec/downloads. >>> >>> The functional changes are the addition of @Target(PARAMETER) to >>> the Priority annotation as requested by the CDI expert group >>> and making the Resource and DataSourceDefinition annotations >>> repeatable. >>> >>> I've also corrected some minor inconsistencies between this spec and >>> the Interceptor spec on PostConstruct and PreDestroy, and replaced the >>> example in section 2.1 referencing WebService/WebMethod, which was >>> inconsistent with the JAX-WS and Web Services Metadata specs. >>> >>> All other changes are intended as purely editorial. >>> >>> If you catch anything amiss, please let me know as soon as >>> possible, as I am planning to submit these materials to the >>> JCP next week to initiate a Maintenance Review. >>> >>> thanks, >>> >>> -Linda >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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. From issues at jboss.org Tue May 31 05:10:00 2016 From: issues at jboss.org (arjan tijms (JIRA)) Date: Tue, 31 May 2016 05:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-610) Add API to obtain current injection point from Bean#create In-Reply-To: References: Message-ID: arjan tijms created CDI-610: ------------------------------- Summary: Add API to obtain current injection point from Bean#create Key: CDI-610 URL: https://issues.jboss.org/browse/CDI-610 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Reporter: arjan tijms There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean#create}}. A previously somewhat accepted way (though not specified) was: {code} Bean bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); {code} This however broke in some version of Weld. Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}. Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injection-point-from-Bean-create-td5710505i20.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue May 31 05:29:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 31 May 2016 05:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-610) Add API to obtain current injection point from Bean#create In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245104#comment-13245104 ] Martin Kouba commented on CDI-610: ---------------------------------- Maybe we could add {{getInjectionPoint()}} method to the {{CreationalContext}}? Also it should return null for beans which are not @Dependent. > Add API to obtain current injection point from Bean#create > ---------------------------------------------------------- > > Key: CDI-610 > URL: https://issues.jboss.org/browse/CDI-610 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: arjan tijms > > There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean#create}}. > A previously somewhat accepted way (though not specified) was: > {code} > Bean bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); > InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); > {code} > This however broke in some version of Weld. > Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}. > Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injection-point-from-Bean-create-td5710505i20.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From EMIJIANG at uk.ibm.com Tue May 31 05:34:11 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 31 May 2016 10:34:11 +0100 Subject: [cdi-dev] Face to Face meeting approved (at last) In-Reply-To: References: Message-ID: <201605310934.u4V9YGOU005606@d06av03.portsmouth.uk.ibm.com> As for next week, are we going to do Friday, Saturday? I should be ok on these dates as it will give us more time to book hotels and flights etc. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Antoine Sabot-Durand To: cdi-dev , Date: 31/05/2016 09:37 Subject: [cdi-dev] Face to Face meeting approved (at last) Sent by: cdi-dev-bounces at lists.jboss.org Hi All, I received validation of our F2F meeting by Red Hat management. I understand that it's a bit late, but I need to know if you make it next week or should we postpone the meeting to late August early September ? Give me you favorite choice. ASAP of course ;). 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160531/b3eab270/attachment.html From issues at jboss.org Tue May 31 06:10:00 2016 From: issues at jboss.org (Arjan t (JIRA)) Date: Tue, 31 May 2016 06:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-610) Add API to obtain current injection point from Bean#create In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245130#comment-13245130 ] Arjan t commented on CDI-610: ----------------------------- {quote}Maybe we could add getInjectionPoint() method to the CreationalContext?{quote} For the {{Bean}} case this would surely work as well. Maybe for some code deeper down {{BeanManager}} would still be more convenient, but principally {{CreationalContext}} should work too. {quote}Also it should return null for beans which are not @Dependent.{quote} Naturally, or perhaps even an exception. It should be as much aligned with injecting the {{InjectionPoint}} in a producer method. (I don't know from the top of my head, but does it throw an exception during startup if it concerns a non {{@Dependent}} bean?) > Add API to obtain current injection point from Bean#create > ---------------------------------------------------------- > > Key: CDI-610 > URL: https://issues.jboss.org/browse/CDI-610 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: arjan tijms > > There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean#create}}. > A previously somewhat accepted way (though not specified) was: > {code} > Bean bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); > InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); > {code} > This however broke in some version of Weld. > Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}. > Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injection-point-from-Bean-create-td5710505i20.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue May 31 06:28:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 31 May 2016 06:28:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-610) Add API to obtain current injection point from Bean#create In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245143#comment-13245143 ] Martin Kouba commented on CDI-610: ---------------------------------- bq. For the Bean case this would surely work as well... Which other cases do you have in mind? I wouldn't add this to the {{BeanManager}}. I think it's bound to the lifecycle of a {{@Dependent}} bean. bq. It should be as much aligned with injecting the InjectionPoint in a producer method. Not only producer methods but any {{@Dependent}} bean is allowed to obtain the injection point. bq. I don't know from the top of my head... Yes, it's a definition error. > Add API to obtain current injection point from Bean#create > ---------------------------------------------------------- > > Key: CDI-610 > URL: https://issues.jboss.org/browse/CDI-610 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: arjan tijms > > There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean#create}}. > A previously somewhat accepted way (though not specified) was: > {code} > Bean bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); > InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); > {code} > This however broke in some version of Weld. > Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}. > Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injection-point-from-Bean-create-td5710505i20.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Tue May 31 06:42:14 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 31 May 2016 12:42:14 +0200 Subject: [cdi-dev] Face to Face meeting approved (at last) In-Reply-To: References: Message-ID: Next week is a bit short to plan. Could probably make it but would rather prefer end of August. LieGrue, strub > Am 31.05.2016 um 10:35 schrieb Antoine Sabot-Durand : > > Hi All, > > I received validation of our F2F meeting by Red Hat management. > I understand that it's a bit late, but I need to know if you make it next week or should we postpone the meeting to late August early September ? > > Give me you favorite choice. ASAP of course ;). > > Antoine > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From issues at jboss.org Tue May 31 07:15:01 2016 From: issues at jboss.org (Arjan t (JIRA)) Date: Tue, 31 May 2016 07:15:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-610) Add API to obtain current injection point from Bean#create In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245167#comment-13245167 ] Arjan t commented on CDI-610: ----------------------------- {quote}Which other cases do you have in mind?{quote} Not really so much a wildly different usecase, just something like {code} public Object create(CreationalContext creationalContext) { someclass.somemethod(); } [...] public void somemethod() { InjectionPoint point = beanManager.getCurrentInjectionPoint(); } {code} Utility code would often already have access to the bean manager (or it can pull it out of thin air), and the actual need for the injection point could be some levels deep and via utility code. Passing the {{CreationalContext}} around may be less convenient. Also, the existing (semi-official) methods to get the injection point used the {{BeanManager}} as well. That all said, {{CreationalContext}} would be fine with me ;) > Add API to obtain current injection point from Bean#create > ---------------------------------------------------------- > > Key: CDI-610 > URL: https://issues.jboss.org/browse/CDI-610 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: arjan tijms > > There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean#create}}. > A previously somewhat accepted way (though not specified) was: > {code} > Bean bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); > InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); > {code} > This however broke in some version of Weld. > Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}. > Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injection-point-from-Bean-create-td5710505i20.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From EMIJIANG at uk.ibm.com Tue May 31 08:35:41 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 31 May 2016 13:35:41 +0100 Subject: [cdi-dev] Face to Face meeting approved (at last) In-Reply-To: References: Message-ID: <201605311235.u4VCZkuZ000936@d06av09.portsmouth.uk.ibm.com> I cannot make it if it is end of August due to family holiday. If we all make effort to attend next week, we might be able to push CDI 2.0 spec to a better state and finalise sooner. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Mark Struberg To: Sabot-Durand Antoine , Cc: cdi-dev Date: 31/05/2016 11:43 Subject: Re: [cdi-dev] Face to Face meeting approved (at last) Sent by: cdi-dev-bounces at lists.jboss.org Next week is a bit short to plan. Could probably make it but would rather prefer end of August. LieGrue, strub > Am 31.05.2016 um 10:35 schrieb Antoine Sabot-Durand : > > Hi All, > > I received validation of our F2F meeting by Red Hat management. > I understand that it's a bit late, but I need to know if you make it next week or should we postpone the meeting to late August early September ? > > Give me you favorite choice. ASAP of course ;). > > Antoine > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160531/de4c6082/attachment.html From mkouba at redhat.com Tue May 31 08:43:58 2016 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 31 May 2016 14:43:58 +0200 Subject: [cdi-dev] Face to Face meeting approved (at last) In-Reply-To: <201605311235.u4VCZkuZ000936@d06av09.portsmouth.uk.ibm.com> References: <201605311235.u4VCZkuZ000936@d06av09.portsmouth.uk.ibm.com> Message-ID: <574D870E.5010306@redhat.com> I would rather prefer early September. Martin Dne 31.5.2016 v 14:35 Emily Jiang napsal(a): > I cannot make it if it is end of August due to family holiday. If we all > make effort to attend next week, we might be able to push CDI 2.0 spec > to a better state and finalise sooner. > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Mark Struberg > To: Sabot-Durand Antoine , > Cc: cdi-dev > Date: 31/05/2016 11:43 > Subject: Re: [cdi-dev] Face to Face meeting approved (at last) > Sent by: cdi-dev-bounces at lists.jboss.org > ------------------------------------------------------------------------ > > > > Next week is a bit short to plan. Could probably make it but would > rather prefer end of August. > > LieGrue, > strub > > > Am 31.05.2016 um 10:35 schrieb Antoine Sabot-Durand > : > > > > Hi All, > > > > I received validation of our F2F meeting by Red Hat management. > > I understand that it's a bit late, but I need to know if you make it > next week or should we postpone the meeting to late August early September ? > > > > Give me you favorite choice. ASAP of course ;). > > > > Antoine > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 john.d.ament at gmail.com Tue May 31 08:47:51 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 31 May 2016 12:47:51 +0000 Subject: [cdi-dev] Looking for Feedback on PR #291 In-Reply-To: <3D2C60FD-E6CD-44E3-A116-7C98E01BAEAA@yahoo.de> References: <3D2C60FD-E6CD-44E3-A116-7C98E01BAEAA@yahoo.de> Message-ID: Mark, *) We can enhance the docs. It should be clear, when looking at the javadocs, that its intended for the current thread and cannot be started more than once. John On Tue, May 31, 2016 at 2:51 AM Mark Struberg wrote: > Quick feedback: > > *) activate might be ambiguous. There is actually a ?start? and a > ?activate on this very thread?. Think about @SessionScoped or > @ConversationScoped. Not every new thread will start a new Context. > Multiple threads might re-use the very same one. Now you need a way to > explicitlely say which ?Session? (or Map) you like to attach to > > *) @ActivateRequestScope et al. Interesting idea but I fear it wont work > out. Let?s stick with the @SessionScoped example: _which_ Session should > get created/attached for the very thread? > > But it?s a start! Thanks for getting the ball rolling. > > LieGrue, > strub > > > > Am 26.05.2016 um 12:42 schrieb John D. Ament : > > > > All, > > > > As mentioned during Tuesday's meeting, I'm looking for more feedback on > PR #291 - the context control APIs. I think the current version is pretty > snazy, and thanks especially to Martin for his input on it thus far. I'm > looking for more input though, especially from the OWB team (Mark > Struberg??) on whether its realistic or not. > > > > https://github.com/cdi-spec/cdi/pull/291 > > > > > > John > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160531/699be7d6/attachment.html From mkouba at redhat.com Tue May 31 08:59:59 2016 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 31 May 2016 14:59:59 +0200 Subject: [cdi-dev] Looking for Feedback on PR #291 In-Reply-To: <3D2C60FD-E6CD-44E3-A116-7C98E01BAEAA@yahoo.de> References: <3D2C60FD-E6CD-44E3-A116-7C98E01BAEAA@yahoo.de> Message-ID: <574D8ACF.6000003@redhat.com> I think John's proposal is defacto a standardized version of "unbound contexts" from Weld [1]. These are scoped to the thread in which they are activated and destroyed upon deactivation. For @RequestScoped it makes perfect sense (we use it internally in Weld if needed during @PostConstruct callbacks). For @ConversationScoped and @SessionScoped it would be more like a dummy context just to make beans working. Actually, I find the Weld Context Management API quite nice and powerful. But including all this stuff in the spec might be overkill. Martin [1] http://docs.jboss.org/weld/reference/latest/en-US/html/contexts.html#_managing_the_built_in_contexts Dne 31.5.2016 v 08:51 Mark Struberg napsal(a): > Quick feedback: > > *) activate might be ambiguous. There is actually a ?start? and a ?activate on this very thread?. Think about @SessionScoped or @ConversationScoped. Not every new thread will start a new Context. Multiple threads might re-use the very same one. Now you need a way to explicitlely say which ?Session? (or Map) you like to attach to > > *) @ActivateRequestScope et al. Interesting idea but I fear it wont work out. Let?s stick with the @SessionScoped example: _which_ Session should get created/attached for the very thread? > > But it?s a start! Thanks for getting the ball rolling. > > LieGrue, > strub > > >> Am 26.05.2016 um 12:42 schrieb John D. Ament : >> >> All, >> >> As mentioned during Tuesday's meeting, I'm looking for more feedback on PR #291 - the context control APIs. I think the current version is pretty snazy, and thanks especially to Martin for his input on it thus far. I'm looking for more input though, especially from the OWB team (Mark Struberg??) on whether its realistic or not. >> >> https://github.com/cdi-spec/cdi/pull/291 >> >> >> John >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 antoine at sabot-durand.net Tue May 31 09:48:29 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 31 May 2016 13:48:29 +0000 Subject: [cdi-dev] Looking for Feedback on PR #291 In-Reply-To: <574D8ACF.6000003@redhat.com> References: <3D2C60FD-E6CD-44E3-A116-7C98E01BAEAA@yahoo.de> <574D8ACF.6000003@redhat.com> Message-ID: I think this approach very interesting for built-in context support on Java SE. What bothers me is the use of this under Java EE. I don't say it wouldn't be useful, but it adds a level of complexity that may puzzle users. So my point is : shouldn't we limit this feature to SE only ? Antoine Le mar. 31 mai 2016 ? 15:00, Martin Kouba a ?crit : > I think John's proposal is defacto a standardized version of "unbound > contexts" from Weld [1]. These are scoped to the thread in which they > are activated and destroyed upon deactivation. For @RequestScoped it > makes perfect sense (we use it internally in Weld if needed during > @PostConstruct callbacks). For @ConversationScoped and @SessionScoped it > would be more like a dummy context just to make beans working. > > Actually, I find the Weld Context Management API quite nice and > powerful. But including all this stuff in the spec might be overkill. > > Martin > > [1] > > http://docs.jboss.org/weld/reference/latest/en-US/html/contexts.html#_managing_the_built_in_contexts > > Dne 31.5.2016 v 08:51 Mark Struberg napsal(a): > > Quick feedback: > > > > *) activate might be ambiguous. There is actually a ?start? and a > ?activate on this very thread?. Think about @SessionScoped or > @ConversationScoped. Not every new thread will start a new Context. > Multiple threads might re-use the very same one. Now you need a way to > explicitlely say which ?Session? (or Map) you like to attach to > > > > *) @ActivateRequestScope et al. Interesting idea but I fear it wont work > out. Let?s stick with the @SessionScoped example: _which_ Session should > get created/attached for the very thread? > > > > But it?s a start! Thanks for getting the ball rolling. > > > > LieGrue, > > strub > > > > > >> Am 26.05.2016 um 12:42 schrieb John D. Ament : > >> > >> All, > >> > >> As mentioned during Tuesday's meeting, I'm looking for more feedback on > PR #291 - the context control APIs. I think the current version is pretty > snazy, and thanks especially to Martin for his input on it thus far. I'm > looking for more input though, especially from the OWB team (Mark > Struberg??) on whether its realistic or not. > >> > >> https://github.com/cdi-spec/cdi/pull/291 > >> > >> > >> John > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160531/e61773f9/attachment-0001.html From antoine at sabot-durand.net Tue May 31 09:50:15 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 31 May 2016 13:50:15 +0000 Subject: [cdi-dev] Face to Face meeting approved (at last) In-Reply-To: <574D870E.5010306@redhat.com> References: <201605311235.u4VCZkuZ000936@d06av09.portsmouth.uk.ibm.com> <574D870E.5010306@redhat.com> Message-ID: Ok, let's forget about a meeting before EDR2. I'll start a new Doodle with end of summer time slots. Antoine Le mar. 31 mai 2016 ? 14:44, Martin Kouba a ?crit : > I would rather prefer early September. > > Martin > > Dne 31.5.2016 v 14:35 Emily Jiang napsal(a): > > I cannot make it if it is end of August due to family holiday. If we all > > make effort to attend next week, we might be able to push CDI 2.0 spec > > to a better state and finalise sooner. > > > > Many thanks, > > Emily > > =========================== > > Emily Jiang > > WebSphere Application Server, CDI Development Lead > > > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > > Phone: +44 (0)1962 816278 Internal: 246278 > > > > Email: emijiang at uk.ibm.com > > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > > From: Mark Struberg > > To: Sabot-Durand Antoine , > > Cc: cdi-dev > > Date: 31/05/2016 11:43 > > Subject: Re: [cdi-dev] Face to Face meeting approved (at last) > > Sent by: cdi-dev-bounces at lists.jboss.org > > ------------------------------------------------------------------------ > > > > > > > > Next week is a bit short to plan. Could probably make it but would > > rather prefer end of August. > > > > LieGrue, > > strub > > > > > Am 31.05.2016 um 10:35 schrieb Antoine Sabot-Durand > > : > > > > > > Hi All, > > > > > > I received validation of our F2F meeting by Red Hat management. > > > I understand that it's a bit late, but I need to know if you make it > > next week or should we postpone the meeting to late August early > September ? > > > > > > Give me you favorite choice. ASAP of course ;). > > > > > > Antoine > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > > code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160531/af36c889/attachment.html From john.d.ament at gmail.com Tue May 31 09:51:46 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 31 May 2016 13:51:46 +0000 Subject: [cdi-dev] Looking for Feedback on PR #291 In-Reply-To: References: <3D2C60FD-E6CD-44E3-A116-7C98E01BAEAA@yahoo.de> <574D8ACF.6000003@redhat.com> Message-ID: No, this is useful for both SE and EE. The biggest problem I've run into, which requires context activation, is around multithreading in EE. Say I'm using Quartz in my app server, I need a way to start the context for that job's duration. Its outside the spec since Quartz isn't an EE technology. John On Tue, May 31, 2016 at 9:48 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > I think this approach very interesting for built-in context support on > Java SE. What bothers me is the use of this under Java EE. I don't say it > wouldn't be useful, but it adds a level of complexity that may puzzle users. > So my point is : shouldn't we limit this feature to SE only ? > > Antoine > > Le mar. 31 mai 2016 ? 15:00, Martin Kouba a ?crit : > >> I think John's proposal is defacto a standardized version of "unbound >> contexts" from Weld [1]. These are scoped to the thread in which they >> are activated and destroyed upon deactivation. For @RequestScoped it >> makes perfect sense (we use it internally in Weld if needed during >> @PostConstruct callbacks). For @ConversationScoped and @SessionScoped it >> would be more like a dummy context just to make beans working. >> >> Actually, I find the Weld Context Management API quite nice and >> powerful. But including all this stuff in the spec might be overkill. >> >> Martin >> >> [1] >> >> http://docs.jboss.org/weld/reference/latest/en-US/html/contexts.html#_managing_the_built_in_contexts >> >> Dne 31.5.2016 v 08:51 Mark Struberg napsal(a): >> > Quick feedback: >> > >> > *) activate might be ambiguous. There is actually a ?start? and a >> ?activate on this very thread?. Think about @SessionScoped or >> @ConversationScoped. Not every new thread will start a new Context. >> Multiple threads might re-use the very same one. Now you need a way to >> explicitlely say which ?Session? (or Map) you like to attach to >> > >> > *) @ActivateRequestScope et al. Interesting idea but I fear it wont >> work out. Let?s stick with the @SessionScoped example: _which_ Session >> should get created/attached for the very thread? >> > >> > But it?s a start! Thanks for getting the ball rolling. >> > >> > LieGrue, >> > strub >> > >> > >> >> Am 26.05.2016 um 12:42 schrieb John D. Ament : >> >> >> >> All, >> >> >> >> As mentioned during Tuesday's meeting, I'm looking for more feedback >> on PR #291 - the context control APIs. I think the current version is >> pretty snazy, and thanks especially to Martin for his input on it thus >> far. I'm looking for more input though, especially from the OWB team (Mark >> Struberg??) on whether its realistic or not. >> >> >> >> https://github.com/cdi-spec/cdi/pull/291 >> >> >> >> >> >> John >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.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/20160531/9c9280ac/attachment.html From john.d.ament at gmail.com Tue May 31 10:18:52 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 31 May 2016 14:18:52 +0000 Subject: [cdi-dev] Looking for Feedback on PR #291 In-Reply-To: <574D8ACF.6000003@redhat.com> References: <3D2C60FD-E6CD-44E3-A116-7C98E01BAEAA@yahoo.de> <574D8ACF.6000003@redhat.com> Message-ID: One thing to point out - I explicitly didn't provide a way to manage ConversationScope. There's two problems with it as I see it. 1. Its bound to a CID 2. The CID can only be passed in as an HTTP parameter There's already an API that allows you to manage conversations, assuming you get a reference to the Conversation bean. What's missing is loading an active conversation. I think we can add something to have a long running conversation if needed, otherwise leverage the Conversation bean to start conversation scope. Another point - mostly to reiterate Martin's sentiment. This is merely starting the context to support already scoped beans. The javadocs on session clearly state that there is no correlation between requests and a session. John On Tue, May 31, 2016 at 9:00 AM Martin Kouba wrote: > I think John's proposal is defacto a standardized version of "unbound > contexts" from Weld [1]. These are scoped to the thread in which they > are activated and destroyed upon deactivation. For @RequestScoped it > makes perfect sense (we use it internally in Weld if needed during > @PostConstruct callbacks). For @ConversationScoped and @SessionScoped it > would be more like a dummy context just to make beans working. > > Actually, I find the Weld Context Management API quite nice and > powerful. But including all this stuff in the spec might be overkill. > > Martin > > [1] > > http://docs.jboss.org/weld/reference/latest/en-US/html/contexts.html#_managing_the_built_in_contexts > > Dne 31.5.2016 v 08:51 Mark Struberg napsal(a): > > Quick feedback: > > > > *) activate might be ambiguous. There is actually a ?start? and a > ?activate on this very thread?. Think about @SessionScoped or > @ConversationScoped. Not every new thread will start a new Context. > Multiple threads might re-use the very same one. Now you need a way to > explicitlely say which ?Session? (or Map) you like to attach to > > > > *) @ActivateRequestScope et al. Interesting idea but I fear it wont work > out. Let?s stick with the @SessionScoped example: _which_ Session should > get created/attached for the very thread? > > > > But it?s a start! Thanks for getting the ball rolling. > > > > LieGrue, > > strub > > > > > >> Am 26.05.2016 um 12:42 schrieb John D. Ament : > >> > >> All, > >> > >> As mentioned during Tuesday's meeting, I'm looking for more feedback on > PR #291 - the context control APIs. I think the current version is pretty > snazy, and thanks especially to Martin for his input on it thus far. I'm > looking for more input though, especially from the OWB team (Mark > Struberg??) on whether its realistic or not. > >> > >> https://github.com/cdi-spec/cdi/pull/291 > >> > >> > >> John > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160531/ce882863/attachment-0001.html From antoine at sabot-durand.net Tue May 31 10:36:54 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 31 May 2016 14:36:54 +0000 Subject: [cdi-dev] September F2F meeting Doodle Message-ID: Hi all, The meeting will take place on 2 days. I listed the choices for the starting day in the following Doodle. As we have the budget, we are sure to have it this time, we only have to agree on the date. http://doodle.com/poll/mby6vkkgdsyd2fg9 Sorry for the previous attempt and thank you for your feedback. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160531/a318092c/attachment.html From john.d.ament at gmail.com Tue May 31 22:43:35 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 01 Jun 2016 02:43:35 +0000 Subject: [cdi-dev] Updated PR #291 Message-ID: All, Based on today's discussion I've updated PR #291 for CDI-30 (and probably CDI-103) https://github.com/cdi-spec/cdi/pull/291 One thing to note. Originally I was going to put new methods on Context. This didn't make sense, as Context was clearly something bound to the underlying thread which we had discussed didn't make much sense and preferable to decouple these. As a result I created a new ActiveContext object. So please, comments welcome. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160601/55cbc076/attachment.html