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/
