Many updates queued already as well... Sincerely, - Ray
On Jan 20, 2017 4:03 AM, "David Bosschaert" <david.bosscha...@gmail.com> wrote: For those who may have missed it, Ray has submitted his initial contribution here: https://issues.apache.org/jira/browse/ARIES-1665 Thanks Ray! David On 24 November 2016 at 13:53, Emily Jiang <emijia...@googlemail.com> wrote: > +1 on David's suggestions! > > On Thu, Nov 24, 2016 at 1:47 PM, Raymond Auge <raymond.a...@liferay.com> > wrote: > >> As far as I'm concerned I'd love to get feedback on the in-progress-spec >> from people outside the Alliance EGs. Currently we're doing this with more >> than half of the work in progress for R7 and it has proven to be hugely >> valuable. I think DavidB and TimWard would agree with me on that. >> >> - Ray >> >> >> On Thu, Nov 24, 2016 at 8:31 AM, Guillaume Nodet <gno...@apache.org> >> wrote: >> >>> Another thing to consider is how the Aries community will be involved. >>> If the goal is to develop the would-be RI with the community or just use >>> Aries as a dumping ground ? >>> If the later, a better idea would be for you to create a github repo to >>> work on the RI, and when everything is done, propose the code donation to >>> Aries once the spec, RI and tck are finalized. If the former, we may have >>> a problem with some community members which do not have access to the OSGi >>> Alliance specification process because they are not employed by OSGi >>> members (that's the case for Talend guys at least). >>> >>> Is there anything the Alliance can do about that ? Can the ASF be given >>> membership in the Alliance ? I think this has already been discussed years >>> ago in the context of Felix, but I don't really recall the outcome. Anyone >>> recalls anything ? >>> >>> That solved, the next steps would be to raise a JIRA and attach the code >>> or a link to it and start a formal vote. >>> >>> Guillaume >>> >>> 2016-11-24 14:12 GMT+01:00 Guillaume Nodet <gno...@apache.org>: >>> >>>> >>>> 2016-11-24 13:48 GMT+01:00 Raymond Auge <raymond.a...@liferay.com>: >>>> >>>>> There's presently ongoing work in Aries on unreleased specs.. so this >>>>> shouldn't be a problem? >>>>> >>>> >>>> The fact it has already been done does not mean it's right. I'll pay >>>> more attention in the future. >>>> >>>> I think the OSGi Alliance has some controls over the org.osgi packages: >>>> https://www.osgi.org/developer/specifications/licensing/ >>>> >>>> Here's what the Felix PMC came up with: >>>> http://felix.apache.org/documentation/development/provision >>>> al-osgi-api-policy.html >>>> >>>> Here's the discussion: >>>> http://www.mail-archive.com/dev@felix.apache.org/msg33029.html >>>> >>>> I think the Aries PMC should decide on a similar policy that can be >>>> double checked by legal@apache. >>>> >>>> >>>>> As long as no "final" release of OSGi APIs are made. But it's fine to >>>>> make snapshots of evolving OSGi APIs. >>>>> >>>> >>>> There's no "final" or "non final" releases. Either it's a release from >>>> the Apache Aries PMC or it's not. If it is, it has to be legit. >>>> >>>> Anyway, it certainly does not prevent working on something at Apache. >>>> Worst scenario, it prevents a release before the spec is finalized by the >>>> OSGi Alliance. >>>> >>>> Guillaume >>>> >>>> >>>>> >>>>> See: >>>>> https://svn.apache.org/repos/asf/aries/trunk/tx-control/tx-c >>>>> ontrol-api/ >>>>> https://svn.apache.org/repos/asf/aries/trunk/pushstream/ >>>>> >>>>> >>>>> - Ray >>>>> >>>>> On Thu, Nov 24, 2016 at 7:37 AM, Guillaume Nodet <gno...@apache.org> >>>>> wrote: >>>>> >>>>>> From a legal standpoint, I'm not sure we can actually release >>>>>> anything before the spec is out. >>>>>> >>>>>> 2016-11-24 13:24 GMT+01:00 Raymond Auge <raymond.a...@liferay.com>: >>>>>> >>>>>>> ... I think that we've got more critical mass of interest than I've >>>>>>> seen on any OSGi topic in a long time and this is encouraging! :) >>>>>>> >>>>>>> Than being said, I'd like to avoid going farther off the rails and >>>>>>> back to the original request. >>>>>>> >>>>>>> I'd like to push something (bad or good 0.0.1 version) so that >>>>>>> people can hate or love it. >>>>>>> >>>>>>> 1) I'm requesting to become a committer, if you'll have me! >>>>>>> 2) I guess we need a repo (I'd personally prefer a git repo) >>>>>>> >>>>>>> Guillaume, Emily, Christian, DavidJ, DavidB it would be my pleasure >>>>>>> to work with you all in making something we can all be proud of. >>>>>>> >>>>>>> Sincerely, >>>>>>> - Ray >>>>>>> >>>>>>> On Thu, Nov 24, 2016 at 6:54 AM, Guillaume Nodet <gno...@apache.org> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2016-11-24 11:24 GMT+01:00 Emily Jiang <emijia...@googlemail.com>: >>>>>>>> >>>>>>>>> What about rhe following requirements: >>>>>>>>>> CDI016 – The specification MUST extend the life-cycle >>>>>>>>>> dependency model as provided in CDI, to support the dynamic >>>>>>>>>> life-cycle >>>>>>>>>> provided by OSGi. For example, it MUST NOT be fatal to deploy a CDI >>>>>>>>>> bean >>>>>>>>>> that does not have all its dependencies initially satisfied and it >>>>>>>>>> MUST be >>>>>>>>>> possible to change bean dependencies without requiring the CDI >>>>>>>>>> application >>>>>>>>>> to be redeployed or restarted. >>>>>>>>>> >>>>>>>>>> CDI031 – The specification MUST extend the life-cycle dependency >>>>>>>>>> model of CDI to include dynamic OSGi service dependencies. >>>>>>>>>> >>>>>>>>>> CDI017 – The specification MUST make it possible to declare a CDI >>>>>>>>>> injection point to an OSGi service as optional. >>>>>>>>>> >>>>>>>>>> These requirements are for bundle service damping, not changing >>>>>>>>> any CDI scope definition. >>>>>>>>> Your observation was right that inter-bundle injection must go >>>>>>>>> through OSGi services (missed inter-bundle, my bad). For inner bundle >>>>>>>>> injection, it can be done bypassing the service registry. >>>>>>>>> >>>>>>>>> "To summarize, my big objections to the current state of the RFC >>>>>>>>> are: >>>>>>>>> * the scope is too limited and only cover a very small number of >>>>>>>>> use cases >>>>>>>>> * the fact that dependencies changes affect the whole CDI >>>>>>>>> application should definitely not be the default behavior >>>>>>>>> * mandatory dependencies should not be limited to services >>>>>>>>> * optional dependencies should not require a proxy to be injected >>>>>>>>> * we need to support greedy / reluctant, static / dynamic, >>>>>>>>> global / local, immediate / delayed components, etc... >>>>>>>>> * support for configurations" >>>>>>>>> It is absolutely valid to provide any custom scopes in the >>>>>>>>> specification. However, as per Ray's comments, the RequestScoped and >>>>>>>>> SessionScoped are mapped nicely to prototypeScope in OSGi and the >>>>>>>>> implementation is straightforward. Can you list your user cases and >>>>>>>>> we can >>>>>>>>> explore them and introduce any suitable custom scopes if possible? >>>>>>>>> >>>>>>>> >>>>>>>> Why on earth are you always talking about scopes, and especially >>>>>>>> OSGi scopes ? I'm not talking about exposing services, I'm mainly >>>>>>>> focusing >>>>>>>> on injecting OSGi services into beans. >>>>>>>> >>>>>>>> I just stated my use cases above. For injection, I want to support >>>>>>>> any combination of: >>>>>>>> * reluctant | greedy >>>>>>>> * static | dynamic >>>>>>>> * mandatory | optional >>>>>>>> In addition, we should have: >>>>>>>> * individual bean lifecycles : there should be no need to >>>>>>>> destroy/recreate the whole app >>>>>>>> * injecting configuration (based on user defined annotations to >>>>>>>> hold the configuration) with support for greedy | reluctant / >>>>>>>> mandatory | >>>>>>>> optional >>>>>>>> You should be able to inject any OSGi service into a CDI bean, not >>>>>>>> limited to a service. Please refer to the DS spec if you're not sure >>>>>>>> about >>>>>>>> the meaning of greedy, reluctant, static, dynamic, mandatory and >>>>>>>> optional. >>>>>>>> If the bean needs to be re-injected, it should be cleanly destroyed and >>>>>>>> recreated without impacting the whole application lifecycle. >>>>>>>> >>>>>>>> Those are standard OSGi use cases for dealing with services >>>>>>>> dependencies. They have been solved nicely with DS. Blueprint did >>>>>>>> things >>>>>>>> differently and failed. Unless you want another failure, I suggest you >>>>>>>> look at what's working well, i.e. DS and use the same concepts to >>>>>>>> create a >>>>>>>> nice CDI / OSGi integration. >>>>>>>> >>>>>>>> That said, the only solution I found to cover the above use cases >>>>>>>> without having to restart the whole application is to define a custom >>>>>>>> scope >>>>>>>> for the CDI beans that are injected with OSGi services. This allow the >>>>>>>> implementation to manage the bean lifecycle and destroy / recreate them >>>>>>>> when the service dependencies have changed. >>>>>>>> I fully understand that there are use cases where you don't want to >>>>>>>> use a custom scope for a given bean, so I've added the global flag in >>>>>>>> order >>>>>>>> to support any cdi scope and move the lifecycle to the whole container >>>>>>>> instead. That does not mean it should be the only way. >>>>>>>> >>>>>>>> Is that a bit clearer now ? >>>>>>>> >>>>>>>> I have working unit tests for nearly all those use cases if you're >>>>>>>> interested. >>>>>>>> >>>>>>>> Guillaume Nodet >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I suspect you and Ray means extensions differently. Ray's >>>>>>>>> extension meant extender patter (e.g. JPA, JMS etc). Your extension >>>>>>>>> meant >>>>>>>>> CDI SPI extensions. Hence the further confusion. Right? >>>>>>>>> >>>>>>>> >>>>>>>> Not sure. Ray ? >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I suggest we discuss more in next week's F2F meeting, which might >>>>>>>>> be much easier via email exchanges. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Emily >>>>>>>>> >>>>>>>>> On Thu, Nov 24, 2016 at 9:27 AM, Christian Schneider < >>>>>>>>> ch...@die-schneider.net> wrote: >>>>>>>>> >>>>>>>>>> I agree with both sides here. >>>>>>>>>> >>>>>>>>>> I clearly see the need for compatiblity with existing code. One >>>>>>>>>> important question is if this compatiblity can only be provided using >>>>>>>>>> the behaviour currently in the spec or if Guillaume's proposal >>>>>>>>>> would also provide this compatibilty. >>>>>>>>>> >>>>>>>>>> I really like DS and it would be great to have the per >>>>>>>>>> bean/component dynamic behaviour of ds in CDI too. >>>>>>>>>> If the proposal of Guillaume can provide the compatiblity then I >>>>>>>>>> think we should go with it and adapt the spec accordingly (if >>>>>>>>>> possible). >>>>>>>>>> >>>>>>>>>> If the dynamic behaviour is a bit incompatible then we might be >>>>>>>>>> able to offer it in addition to the spec and allow to switch it on >>>>>>>>>> per >>>>>>>>>> bundle. >>>>>>>>>> So legacy code would use the default compatible behaviour and >>>>>>>>>> OSGi centric new code could enable the more dynamic behaviour. >>>>>>>>>> Of course the spec could also define the more dynamic behaviour >>>>>>>>>> and the switch to make it portable but I would also go with it if it >>>>>>>>>> is >>>>>>>>>> just an >>>>>>>>>> aries cdi feature. >>>>>>>>>> >>>>>>>>>> Unfortunately I do not understand all the details that were >>>>>>>>>> discussed before but I hope my basic idea still makes sense :-) >>>>>>>>>> >>>>>>>>>> Christian >>>>>>>>>> >>>>>>>>>> On 24.11.2016 09:46, Guillaume Nodet wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-11-24 3:21 GMT+01:00 Guillaume Nodet <gno...@apache.org>: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le jeudi 24 novembre 2016, Emily Jiang <emijia...@googlemail.com> >>>>>>>>>>> a écrit : >>>>>>>>>>> >>>>>>>>>>>> Late on the party... >>>>>>>>>>>> 2 things I must stress: >>>>>>>>>>>> 1. Supporting the current built-in scopes is much more >>>>>>>>>>>> important than introducing any custom scopes. >>>>>>>>>>>> >>>>>>>>>>> What does supporting mean here ? >>>>>>>>>>> What does supporting @RequestScope means ? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think I now understand what Ray said when he talked about "bean >>>>>>>>>> wrapping" in an earlier email. Now, I think I understand what you >>>>>>>>>> are both >>>>>>>>>> saying is that we should support annotating a CDI bean with @Service >>>>>>>>>> in >>>>>>>>>> scopes like @ApplicationScoped, @Dependent, or whatever, I don't >>>>>>>>>> really >>>>>>>>>> have any problem with that. If we map to my earlier definitions of >>>>>>>>>> global >>>>>>>>>> / local injection point, then this would be a global service and the >>>>>>>>>> lifecycle and instantiations of the beans should be delegated to the >>>>>>>>>> scope >>>>>>>>>> of the bean and not redefined. >>>>>>>>>> I'm fine with that. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Besides, we should not change their lifecycle. Most of user >>>>>>>>>>>> cases are around "bundlised EE apps containing CDI to run in OSGi". >>>>>>>>>>>> >>>>>>>>>>> Most ? Maybe you mean most of *your* use cases ? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2. All injections must go through OSGi service registry. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I don't see any requirement in the RFC about that. And I don't >>>>>>>>>>> see why a limitation should become a requirement. The CDI023 req >>>>>>>>>>> says >>>>>>>>>>> inter-bundle interactions, that's definitely different. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> The CDI specification declares clearly on the start/finish of >>>>>>>>>>>> each scope (https://docs.jboss.org/cdi/sp >>>>>>>>>>>> ec/1.2/cdi-spec.html#scopes). @Singleton for EJB is treated >>>>>>>>>>>> same as @ApplicationScoped. >>>>>>>>>>>> >>>>>>>>>>>> Cool, though i haven't suggested redefining existing scopes in >>>>>>>>>>> a different way... >>>>>>>>>>> >>>>>>>>>>> What about rhe following requirements: >>>>>>>>>>> CDI016 – The specification MUST extend the life-cycle >>>>>>>>>>> dependency model as provided in CDI, to support the dynamic >>>>>>>>>>> life-cycle >>>>>>>>>>> provided by OSGi. For example, it MUST NOT be fatal to deploy a CDI >>>>>>>>>>> bean >>>>>>>>>>> that does not have all its dependencies initially satisfied and it >>>>>>>>>>> MUST be >>>>>>>>>>> possible to change bean dependencies without requiring the CDI >>>>>>>>>>> application >>>>>>>>>>> to be redeployed or restarted. >>>>>>>>>>> >>>>>>>>>>> CDI031 – The specification MUST extend the life-cycle dependency >>>>>>>>>>> model of CDI to include dynamic OSGi service dependencies. >>>>>>>>>>> >>>>>>>>>>> CDI017 – The specification MUST make it possible to declare a >>>>>>>>>>> CDI injection point to an OSGi service as optional. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I don't have any problems with the main use case you want to >>>>>>>>>> support, i.e.: >>>>>>>>>> * exposing any CDI bean as a an service >>>>>>>>>> * being able to inject an OSGi service into any CDI bean >>>>>>>>>> This is the static + greedy + global use case where the whole CDI >>>>>>>>>> application lifecycle is affected by dependencies changes. >>>>>>>>>> >>>>>>>>>> To summarize, my big objections to the current state of the RFC >>>>>>>>>> are: >>>>>>>>>> * the scope is too limited and only cover a very small number >>>>>>>>>> of use cases >>>>>>>>>> * the fact that dependencies changes affect the whole CDI >>>>>>>>>> application should definitely not be the default behavior >>>>>>>>>> * mandatory dependencies should not be limited to services >>>>>>>>>> * optional dependencies should not require a proxy to be >>>>>>>>>> injected >>>>>>>>>> * we need to support greedy / reluctant, static / dynamic, >>>>>>>>>> global / local, immediate / delayed components, etc... >>>>>>>>>> * support for configurations >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Guillaume >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I saw Christine on this thread, which is great. I remind myself >>>>>>>>>>>> to get you involved, Christine, and it is great to know that you >>>>>>>>>>>> are happy >>>>>>>>>>>> to work with Ray. I am willing to answer any questions you might >>>>>>>>>>>> have. >>>>>>>>>>>> Thanks >>>>>>>>>>>> Emily >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Nov 23, 2016 at 11:00 PM, Guillaume Nodet < >>>>>>>>>>>> gno...@apache.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> A "global" injection point means: >>>>>>>>>>>>> * the container will not start until the dependency is >>>>>>>>>>>>> satisfied >>>>>>>>>>>>> * the container will be destroyed if the dependency is not >>>>>>>>>>>>> satisfied anymore >>>>>>>>>>>>> By default, dependencies on OSGi services are "local", i.e. >>>>>>>>>>>>> the injected bean lifecycle is tied to the dependency being >>>>>>>>>>>>> satisfied or >>>>>>>>>>>>> not, and that cascades to other beans (so that inside the same >>>>>>>>>>>>> container, >>>>>>>>>>>>> if A is injected with B and B is injected with an OSGi service C, >>>>>>>>>>>>> if C goes >>>>>>>>>>>>> away, B and A will be destroyed ; that's not really supported by >>>>>>>>>>>>> DS btw >>>>>>>>>>>>> because DS can only inject osgi services, not DS components into >>>>>>>>>>>>> another DS >>>>>>>>>>>>> component), but it does not affect the cdi application as a whole. >>>>>>>>>>>>> So that's not postponing anything. >>>>>>>>>>>>> It's merely a side-effect of the fact that handling dynamics >>>>>>>>>>>>> require a custom CDI scope, and there may be use cases where you >>>>>>>>>>>>> want to >>>>>>>>>>>>> use a standard scope. In those cases, you can use a global >>>>>>>>>>>>> dependency, >>>>>>>>>>>>> because the bean lifecycle does not have to be managed >>>>>>>>>>>>> specifically (the >>>>>>>>>>>>> whole container lifecycle is managed instead). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2016-11-23 22:27 GMT+01:00 David Jencks < >>>>>>>>>>>>> david_jen...@yahoo.com>: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Guillaume, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don’t completely understand what you mean by local/global…. >>>>>>>>>>>>>> and my knowledge of CDI is much less than either your or Ray’s >>>>>>>>>>>>>> knowledge. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Lets consider a request-scoped CDI bean A into which we’ve >>>>>>>>>>>>>> injected a service from a DS component B which has a mandatory >>>>>>>>>>>>>> reference to >>>>>>>>>>>>>> service C. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If we start to unregister C, B’s deactivate method will be >>>>>>>>>>>>>> called. If A was a DS component, with a mandatory reference to >>>>>>>>>>>>>> B, first >>>>>>>>>>>>>> A’s deactivate method would be called. But iA is a CDI bean. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Should deactivate on B be postponed until A goes out of scope >>>>>>>>>>>>>> (the request completes)? This would be somewhat similar to, if >>>>>>>>>>>>>> A was DS >>>>>>>>>>>>>> component, having a read-write lock where all the service >>>>>>>>>>>>>> methods get a >>>>>>>>>>>>>> read lock and the DS lifecycle methods get the write lock. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is this related to what you mean by local/global? >>>>>>>>>>>>>> >>>>>>>>>>>>>> hoping for more concrete details… >>>>>>>>>>>>>> thanks >>>>>>>>>>>>>> david jencks >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Nov 23, 2016, at 12:10 PM, Guillaume Nodet < >>>>>>>>>>>>>> gno...@apache.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016-11-23 19:48 GMT+01:00 Raymond Auge < >>>>>>>>>>>>>> raymond.a...@liferay.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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" >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd say those are the same. The singleton scope is just one >>>>>>>>>>>>>> scope which uses boundaries equals to the container lifecycle. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, they all define a boundary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> What do you mean by "supporting any CDI scope" ? You mean >>>>>>>>>>>>>> exposing beans with any CDI scope in the OSGi registry ? >>>>>>>>>>>>>> I'm not sure I understand what that would mean exporting a >>>>>>>>>>>>>> @RequestScoped bean as an OSGi service. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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!!! >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not sure that we have to think about exposing OSGi >>>>>>>>>>>>>> services the way you do. I don't see the use case for choosing >>>>>>>>>>>>>> any CDI >>>>>>>>>>>>>> bean from an existing application and exposing is over OSGi. >>>>>>>>>>>>>> Services are >>>>>>>>>>>>>> usually well defined interfaces so there is a decision to expose >>>>>>>>>>>>>> a service >>>>>>>>>>>>>> in the OSGi registry. So I'm fine with using custom annotations >>>>>>>>>>>>>> if needed. >>>>>>>>>>>>>> Also, I'm not sure what you describe accomodates with the >>>>>>>>>>>>>> exposed bean lifecycle having to be tied to its dependencies as >>>>>>>>>>>>>> I advocate. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So basically I'm fine with the 3 scopes defined in the RFC >>>>>>>>>>>>>> when exposing beans OSGi services: >>>>>>>>>>>>>> * BundleScoped >>>>>>>>>>>>>> * PrototypeScoped >>>>>>>>>>>>>> * SingletonScoped >>>>>>>>>>>>>> We could do some mapping with existing CDI scopes if needed. >>>>>>>>>>>>>> But my main concern is certainly not that one. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My concern is about the lifecycle when you inject services >>>>>>>>>>>>>> from the OSGi registry into a CDI bean, not exporting services. >>>>>>>>>>>>>> As I indicated in my first email, my concern is about >>>>>>>>>>>>>> handling OSGi dynamics, not exporting OSGi services which is the >>>>>>>>>>>>>> easy part, >>>>>>>>>>>>>> and not about CDI extensions, which I fully agree we need to >>>>>>>>>>>>>> support. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What I'd like is a real injection framework that we can point >>>>>>>>>>>>>> OSGi users to. >>>>>>>>>>>>>> Blueprint has some deficiencies ; the service damping >>>>>>>>>>>>>> mechanism is a pain to deal with and also a pain to work around. >>>>>>>>>>>>>> DS is very good at handling OSGi dynamics : it supports a >>>>>>>>>>>>>> great range of use cases and the defaults makes users life easy. >>>>>>>>>>>>>> The >>>>>>>>>>>>>> problem with DS is that it's limited to wiring OSGi services >>>>>>>>>>>>>> together, it's >>>>>>>>>>>>>> not pluggable, and can't do anything else. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If I'm understanding things right: >>>>>>>>>>>>>> * if you inject an OSGI service into a bean, the while >>>>>>>>>>>>>> container lifecycle will be tied to the availability of that bean >>>>>>>>>>>>>> * if you use an optional dependency, a null proxy is >>>>>>>>>>>>>> injected >>>>>>>>>>>>>> That's basically the only 2 scenarios supported by the RFC >>>>>>>>>>>>>> for injecting services. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My proposal supports: >>>>>>>>>>>>>> * mandatory / optional >>>>>>>>>>>>>> * greedy / reluctant >>>>>>>>>>>>>> * static / dynamic >>>>>>>>>>>>>> * local / global >>>>>>>>>>>>>> Those should not deviate from the fact that a bean will never >>>>>>>>>>>>>> change during it's lifecycle. The way to implement that is to >>>>>>>>>>>>>> make the >>>>>>>>>>>>>> bean lifecycle boundary defined by the availability of its >>>>>>>>>>>>>> dependencies. >>>>>>>>>>>>>> It means beans injected with OSGi services have to be in a >>>>>>>>>>>>>> custom CDI >>>>>>>>>>>>>> scope so that its lifecycle can be managed. So whenever the >>>>>>>>>>>>>> dependencies >>>>>>>>>>>>>> of a CDI bean injected with OSGi services change in a way that >>>>>>>>>>>>>> the bean >>>>>>>>>>>>>> needs to be re-injected, we destroy the bean correctly and >>>>>>>>>>>>>> re-create it >>>>>>>>>>>>>> with the new dependencies. IT supports the mandatory / optional >>>>>>>>>>>>>> and greedy >>>>>>>>>>>>>> / reluctant DS semantics. >>>>>>>>>>>>>> We also have the use case where you have a bean, but you >>>>>>>>>>>>>> don't want the lifecycle to be modified and you want a proxy to >>>>>>>>>>>>>> be injected >>>>>>>>>>>>>> to use service damping. It's not the default, but it can be >>>>>>>>>>>>>> supported. >>>>>>>>>>>>>> That's the static / dynamic semantic. >>>>>>>>>>>>>> There are some use cases where you don't want to change the >>>>>>>>>>>>>> scope. For those use cases, the injection point needs to be >>>>>>>>>>>>>> flagged >>>>>>>>>>>>>> properly so that the whole container lifecycle will be tied to >>>>>>>>>>>>>> the >>>>>>>>>>>>>> dependencies. That's the local / global semantic which does not >>>>>>>>>>>>>> exist in DS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On the other side, i.e. exposing a service, there is: >>>>>>>>>>>>>> * bundle / service / prototype service scope >>>>>>>>>>>>>> * immediate / delayed >>>>>>>>>>>>>> >>>>>>>>>>>>>> A bunch of other things that should be supported: >>>>>>>>>>>>>> * injecting configuration using annotations as in DS >>>>>>>>>>>>>> (configuration can be mandatory / optional, greedy / reluctant) >>>>>>>>>>>>>> : an >>>>>>>>>>>>>> annotation defines the injected config with optional default >>>>>>>>>>>>>> values, as >>>>>>>>>>>>>> specified in DS 112.8.2 >>>>>>>>>>>>>> * injecting Instance<X> for mutiple cardinality injection >>>>>>>>>>>>>> * filtering using generic filters or attributes (attributes >>>>>>>>>>>>>> can be used also when exposing services and can hide >>>>>>>>>>>>>> >>>>>>>>>>>>>> So yes, I need a custom scope to support the above use >>>>>>>>>>>>>> cases. But that makes things actually useful for OSGi >>>>>>>>>>>>>> developers imho, and >>>>>>>>>>>>>> not only simple use cases for EE developers porting applications >>>>>>>>>>>>>> to OSGi. >>>>>>>>>>>>>> Supporting all well known DS semantics ensures a complete >>>>>>>>>>>>>> usability for all >>>>>>>>>>>>>> known OSGi use cases. I think if we go this way, we can end up >>>>>>>>>>>>>> with >>>>>>>>>>>>>> something really useful for both OSGi beginners and more >>>>>>>>>>>>>> seasoned OSGi >>>>>>>>>>>>>> developers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Guillaume >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Ray >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Nov 23, 2016 at 12:48 PM, Guillaume Nodet < >>>>>>>>>>>>>>> gno...@apache.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2016-11-23 18:40 GMT+01:00 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ...