One more thing, Guillaume, you have much much much more knowledge of CDI than I. There is no debate there. So let's just put that out there to start so that no one get's confused about it.
- Ray On Wed, Nov 23, 2016 at 12:40 PM, Raymond Auge <[email protected]> wrote: > > > On Wed, Nov 23, 2016 at 12:34 PM, Guillaume Nodet <[email protected]> > wrote: > >> >> >> 2016-11-23 18:22 GMT+01:00 Raymond Auge <[email protected]>: >> >>> Actually, we have a perfect solution in OSGi for the scenario of >>> intermittent scopes like web requests, session scope, etc. That is >>> prototype scope! This is already suggested by the requirements and works >>> very well with the scoped bean concept. You need a Provider for those beans >>> and an OSGi prototype scope service is the perfect provider including >>> reclamation and destruction. >>> >>> Finally, we do want to support existing CDI extensions because that's >>> where a lot of the value is (JSF, JPA, JMS, etc.) and we don't want to >>> change their understanding of the lifecycle of CDI beans otherwise they >>> will break and people won't like it and lose faith that it's useful. >>> >>> My fear is to over-dynamic-fication of things which are not inherently >>> dynamic and fail to produce something useful. >>> >>> The point here is that people can still assemble modular apps using peer >>> bundles containing extensions, beans, osgi services in as complex or simple >>> a constellation as they need and everything needs very little change; that >>> adding and removing bundles from this constellation will behave as expected >>> in a dynamic environment. In fact existing things should largely work with >>> only slight metadata changes including; extensions and support for OSGi >>> services in existing code work without any code changes. >>> >>> Lastly, CDI is fundamentally the same as spring in that when the >>> "container" is declared to be done... it's done! It's like you've exited >>> the constructor of an object. It's effectively a static singleton and that >>> behaviour is expected by pretty much everything that uses it. Invariants >>> introduced after the fact such as trying to shoehorn dynamicity on >>> individual beans I believe will simply break peoples understanding and will >>> cause OSGi's impl to diverge too far away from future CDI work, which I >>> feel is WAY too important to risk since CDI is being introduced on other >>> non-Java EE specifications and will soon touch the JRE. >>> >> >> Are you basically taking @RequestScoped and @SessionScoped out of the >> CDI spec ? Or implying those scopes do not work well with JPA, JMS, JSF >> etc... ? >> Or is there something I'm not understanding in CDI ? >> > > Hmm, I'm not sure how that got inferred by what I said. What I said was > literally: > > >Actually, we have a perfect solution in OSGi for the scenario of > intermittent scopes like web requests, session scope, etc. That is > prototype scope! This is already suggested by the requirements and works > very well with the scoped bean concept. > > Furthermore, JPA, JMS, JSF should be implementable as extensions as they > pretty much are in CDI already and why CDI can be used without any of those > features available. The use of those features in your applications however > infer the requirement on an extension capability providing them which > should be available so your application can function. > > Does that make sense? > - Ray > > >> >> >>> >>> But this is just my opinion, >>> - Ray >>> >>> >>> On Wed, Nov 23, 2016 at 11:38 AM, Christian Schneider < >>> [email protected]> wrote: >>> >>>> I think it would be great if Guillaume and Ray could work on the impl >>>> together. Ray could then feed the experiences back into the RFC. >>>> In any case I would support having Ray as an aries committer. >>>> >>>> Christian >>>> >>>> On 23.11.2016 17:30, David Bosschaert wrote: >>>> >>>>> Hi Guillaume, >>>>> >>>>> My understanding is that the technical design of the RFC will be >>>>> significantly changed to better support the OSGi dynamics - hopefully >>>>> we'll >>>>> see an update soon at https://github.com/osgi/design >>>>> /tree/master/rfcs/rfc0193 >>>>> >>>>> If I understand things correctly then Ray's CDI implementation will >>>>> support the improved design. >>>>> >>>>> Cheers, >>>>> >>>>> David >>>>> >>>> >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Open Source Architect >>>> http://www.talend.com >>>> >>>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> (@rotty3000) >>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>> (@Liferay) >>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >>> (@OSGiAlliance) >>> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Red Hat, Open Source Integration >> >> Email: [email protected] >> Web: http://fusesource.com >> Blog: http://gnodet.blogspot.com/ >> >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > (@OSGiAlliance) > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
