So let's purely focus on scopes then. Because as far as I've observed, in my limited CDI experience, is that there are really only two scopes in CDI, technically:
- singleton - not-singleton or rather "limited by some boundary" Take any CDI scope and you can fit it in one of those two buckets: ApplicationScoped ConversationScoped RequestScoped SessionScoped Dependent Singleton etc. Enter any custom scope and they should pretty much fall into one of those two buckets. The instance either lives from the beginning of the application 'til the end OR some "Context" logic instantiates an instance at some point in time, and later releases it. Perhaps multiple threads create their own instance, perhaps the instance lives during the life of a transaction, etc. The business logic around the actual lifetime is irrelevant, but the instantiation and reclamation is important. The one difference in scopes that exists in OSGi but not in CDI is "osgi bundle scope" vs "osgi singleton scope". However this difference only relates to what CDI can emit or consume from OSGi as services. Internally it would have no meaning because the CDI container is fundamentally scoped to the bundle (at least in terms of the RFC requirements... which I think are sound in this case) and so it need not concern itself to distinguish between a singleton scoped service and a bundle scoped service (but it can certainly force the requirement either way if it really wishes but internally to CDI it makes no difference). In fact, the bean wrapper we place around OSGi services is really the guardian of how the implementation creates and destroys instances based on the context of the CDI scope. However, the OSGi service layer very nicely abstracts this for us in a clever way for which we don't necessarily need to concern ourselves over the context, and lifetime (or boundary) of the scope. If we simply always assume and use of the OSGi prototype API, then we transparently satisfy any boundaries implemented by the CDI scope because the osgi prototype API transparently supports services which are any of singleton, bundle or prototype scope. So with a single bean implementation around all osgi services we safely support pretty much any CDI scope. The problem then becomes having a mechanism to enforce that a given scope really only allows binding prototype scoped osgi services, but I think this is not a real issue. It sounds reasonable that people would not redefine a singleton, or application scope, and in that respect we could simply assume that if the scope is not explicitly declared as: Singleton ApplicationScoped BundleScoped (osgi cdi spec) SingletonScoped (osgi cdi spec?? not really sure we need to redefine this) that we automatically assume they should require prototype scoped services in order to satisfy the fact that the scope needs to create and destroy instances at it's own leisure. 😕😲🙄 Hopefully that made some kind of sense!!! - Ray On Wed, Nov 23, 2016 at 12:48 PM, Guillaume Nodet <[email protected]> wrote: > > > 2016-11-23 18:40 GMT+01:00 Raymond Auge <[email protected]>: > >> >> >> 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. >> > > And you're ruling out the existence of other scopes or that the spec > supports custom scopes. The prototype scope is the default scope, it does > not mean it's the only one. @RequestScope and @SessionScope do handle > dynamics very well : the beans are not created until a request or session > exist and is destroyed when the request / session is destroyed : if that's > not dynamic, I'm not sure what it is. > That's what I'm proposing : having the ability to use a custom scope to > support more OSGi dynamics. > My solution has both a global lifecycle suited to porting JEE applications > (where the whole container lifecycle is tied to the global set of > dependencies) and one custom scope that can handle specific bean > lifecycles, so that OSGi users can benefit from a correct support of OSGi > dynamism as in DS. > > >> >> 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. >> > > I don't see how having extensions is related to scopes and lifecycle. > Supporting extensions is a must-have in CDI. What you implied is that > because you want to support extensions, we can't use custom scopes. I > think I was the one to suggest using generic capabilities to support > extension in the RFC years ago. > > And to answer your other email, I do not pretend to have a really good > knowledge of CDI (really, I don't). I may be missing things in using custom > scopes, but I'd like to understand what exactly, if any. > > >> >> 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) >> > > > > -- > ------------------------ > 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)
