Re: [cdi-dev] Managing Dependent Scoped Beans

Le 16 mai 2016 10:42, "Martin Kouba" <mkouba(a)redhat.com <mailto:mkouba@redhat.com>> 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" <mkouba(a)redhat.com <mailto:mkouba@redhat.com> >> <mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>> a écrit : >> >> Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a): >> >> >> Le 16 mai 2016 10:01, "Martin Kouba" <mkouba(a)redhat.com <mailto:mkouba@redhat.com> >> <mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>> >> <mailto:mkouba@redhat.com <mailto:mkouba@redhat.com> <mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>>> 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(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>> >> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>> >> >> > > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > >> > > Note that for all code provided on this list, the provider >> licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.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(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>> >> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>> >> >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider >> licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.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