I voiced my concern in the EEG 3 years ago when I was working on the RFC I think, maybe not loud enough. I reached to Emily who is leading the RFC about what I've done and exchanged a few emails a few weeks ago. I'll try to write an email to send to the EEG about that to make sure about the visibility of my concerns.
Guillaume 2016-07-13 0:20 GMT+02:00 David Jencks <[email protected]>: > Hi Guillame, > > Are you making your CDI RFC concerns visible, audible, tangible, and > obvious to the eg working on the RFC? For instance, since blueprint seems > to enjoy considerable popularity among some, it might not be obvious to > everyone involved with the RFC why service damping is such a bad idea. > > thanks > david jencks > > On Jul 12, 2016, at 2:41 PM, Guillaume Nodet <[email protected]> wrote: > > Let me describe what I've done which is available in pax-cdi master branch. > > I've defined a bunch of CDI annotations for the DS semantics (@Component, > @Service, @Filter, @Property, @Immediate, @Dynamic, @Greedy, @Optional, > etc...). Multiple cardinality is done through Instance<X>, the usual CDI > way. The extensions delegates to an embedded Felix SCR implementation. SO > it's not DS hosing CDI, but the opposite really, and DS is not visible at > all, since the public APIs do not provide any low-level access required for > such interactions. > > The trick for integrating the dynamic aspect inside CDI is that beans that > have an OSGi service dependency have a specific OSGi scope (so that a > singleton can still be injected and CDI will handle the damping, same as if > it was a servlet request scoped bean for example). This limitation (about > the fact that you can only inject into beans with custom scopes) can be > removed with an additional @Global annotation. The effect is that the > whole container lifecycle will be bound to this dependency being available > or not (as you explained in your solution). > > One deviance from pure DS is the split between components / services. In > DS, you can only inject OSGi services. I've hacked things a bit so that you > can also inject another @Component without the need to go through the OSGi > registry. > > So far, the config admin integration is done using @Config on the > injection point, where the injected type is an annotation too. A proxy is > generated for this annotation based on the configuration from ConfigAdmin > with default values provided by the annotation default values. > > Fwiw, the current RFC drafted at the OSGi alliance for CDI integration > relies heavily on service damping and proxies, which is a really bad > decision. I kinda hope the work I've done could change that a bit, but if > my implementation has to deviate from the OSGi standard to be relevant, so > be it : I don't consider myself bound and limited by crappy standards ;-) > > 2016-07-12 18:43 GMT+02:00 Raymond Auge <[email protected]>: > >> >> On Tue, Jul 12, 2016 at 11:57 AM, Guillaume Nodet <[email protected]> >> wrote: >> >>> >>> I think the CDI+DS extension I've been working on those past weeks could >>> bring the best of both world : strong DS semantics for the OSGi bits, but >>> extensibility and support for proxies provided by CDI ;-) >>> >> >> Guillaume, I decided to start a new thread on this topic. >> >> I'd be very interested in this work. >> >> It's actually a topic I've recently discussed with several other OSGi >> community people and I think there is, at least in my view, reasonable >> doubt that this could be the right approach for dealing with non-osgi >> dependency injection frameworks in general. >> >> I personally believe that all the DI frameworks which have been adapted >> to OSGi have largely done it the same way in the past and are failing for >> the same reasons; they have fundamentally done dynamics wrong. >> >> My belief is that one should NOT try to hammer dynamics into DI >> frameworks which were not originally designed with it in mind. Rather, DS >> has what I consider the perfect model for it AND what should happen is that >> DS should "host" a client DI framework. >> >> This next idea came from Tim Ward. His suggestion is that the DS bits be >> generated into a synthetic class which would: >> >> a) control the lifecycle of the DI client framework (create/destroy) >> b) populate the DI context with the references, letting the client DI >> wire them into the appropriate places. >> >> With this model, I feel that we could make a base implementation on top >> of which we could put >> - Spring DI >> - CDI >> - Google Guice (sisu, peaberry, etc.) >> - Dagger >> - you name it!!! >> - gains all the power of modern OSGi; all the cardinality mappings, >> integration with cm, metatype, etc. >> - gains lossless power of the DI framework >> >> Could you describe the main principles of your design? >> Do they even remotely resemble the ones I mentioned? >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> >> (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> >> (@OSGiAlliance) >> > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
