actually, I have to correct myself because after a little more consideration, it seems that @ApplicationScoped and @Singleton map quite literally to osgi's "bundle scope" and "singleton scope" respectively.
- Ray On Wed, Nov 23, 2016 at 1:48 PM, Raymond Auge <[email protected]> wrote: > 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) > -- *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)
