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. But this is just my opinion, - Ray On Wed, Nov 23, 2016 at 11:38 AM, Christian Schneider < ch...@die-schneider.net> 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)
