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)
