You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by David Bosschaert <da...@gmail.com> on 2017/01/20 09:02:31 UTC
Re: Fwd: Implementation of RFC-193 CDI
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 <em...@googlemail.com> wrote:
> +1 on David's suggestions!
>
> On Thu, Nov 24, 2016 at 1:47 PM, Raymond Auge <ra...@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 <gn...@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 <gn...@apache.org>:
>>>
>>>>
>>>> 2016-11-24 13:48 GMT+01:00 Raymond Auge <ra...@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 <gn...@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 <ra...@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 <gn...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-11-24 11:24 GMT+01:00 Emily Jiang <em...@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 <
>>>>>>>>> chris@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 <gn...@apache.org>:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Le jeudi 24 novembre 2016, Emily Jiang <em...@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 <
>>>>>>>>>>>> gnodet@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_jencks@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 <
>>>>>>>>>>>>>> gnodet@apache.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2016-11-23 19:48 GMT+01:00 Raymond Auge <
>>>>>>>>>>>>>> raymond.auge@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 <
>>>>>>>>>>>>>>> gnodet@apache.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2016-11-23 18:40 GMT+01:00 Raymond Auge <
>>>>>>>>>>>>>>>> raymond.auge@liferay.com>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, Nov 23, 2016 at 12:34 PM, Guillaume Nodet <
>>>>>>>>>>>>>>>>> gnodet@apache.org> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2016-11-23 18:22 GMT+01:00 Raymond Auge <
>>>>>>>>>>>>>>>>>> raymond.auge@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 ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>> chris@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/des
>>>>>>>>>>>>>>>>>>>>> ign/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: gnodet@redhat.com
>>>>>>>>>>>>>>>>>> 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: gnodet@redhat.com
>>>>>>>>>>>>>>>> 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: gnodet@redhat.com
>>>>>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>> Red Hat, Open Source Integration
>>>>>>>>>>>>>
>>>>>>>>>>>>> Email: gnodet@redhat.com
>>>>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Emily
>>>>>>>>>>>> =================
>>>>>>>>>>>> Emily Jiang
>>>>>>>>>>>> ejiang@apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> ------------------------
>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>> ------------------------
>>>>>>>>>>> Red Hat, Open Source Integration
>>>>>>>>>>>
>>>>>>>>>>> Email: gnodet@redhat.com
>>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ------------------------
>>>>>>>>>> Guillaume Nodet
>>>>>>>>>> ------------------------
>>>>>>>>>> Red Hat, Open Source Integration
>>>>>>>>>>
>>>>>>>>>> Email: gnodet@redhat.com
>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ------------------------
>>>>>>>>>> Guillaume Nodet
>>>>>>>>>> ------------------------
>>>>>>>>>> Red Hat, Open Source Integration
>>>>>>>>>>
>>>>>>>>>> Email: gnodet@redhat.com
>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Christian Schneiderhttp://www.liquid-reality.de
>>>>>>>>>>
>>>>>>>>>> Open Source Architecthttp://www.talend.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thanks
>>>>>>>>> Emily
>>>>>>>>> =================
>>>>>>>>> Emily Jiang
>>>>>>>>> ejiang@apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Red Hat, Open Source Integration
>>>>>>>>
>>>>>>>> Email: gnodet@redhat.com
>>>>>>>> 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: gnodet@redhat.com
>>>>>> 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: gnodet@redhat.com
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Red Hat, Open Source Integration
>>>
>>> Email: gnodet@redhat.com
>>> 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)
>>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>
Re: Fwd: Implementation of RFC-193 CDI
Posted by Raymond Auge <ra...@liferay.com>.
Many updates queued already as well...
Sincerely,
- Ray
On Jan 20, 2017 4:03 AM, "David Bosschaert" <da...@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 <em...@googlemail.com> wrote:
> +1 on David's suggestions!
>
> On Thu, Nov 24, 2016 at 1:47 PM, Raymond Auge <ra...@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 <gn...@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 <gn...@apache.org>:
>>>
>>>>
>>>> 2016-11-24 13:48 GMT+01:00 Raymond Auge <ra...@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 <gn...@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 <ra...@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 <gn...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-11-24 11:24 GMT+01:00 Emily Jiang <em...@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 <
>>>>>>>>> chris@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 <gn...@apache.org>:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Le jeudi 24 novembre 2016, Emily Jiang <em...@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 <
>>>>>>>>>>>> gnodet@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_jencks@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 <
>>>>>>>>>>>>>> gnodet@apache.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2016-11-23 19:48 GMT+01:00 Raymond Auge <
>>>>>>>>>>>>>> raymond.auge@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 <
>>>>>>>>>>>>>>> gnodet@apache.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2016-11-23 18:40 GMT+01:00
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ...