2016-11-23 18:22 GMT+01:00 Raymond Auge <raymond.a...@liferay.com>: > 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 ? > > 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) > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
