On Tue, Jul 12, 2016 at 12:54 PM, Brad Johnson <[email protected] > wrote:
> Raymond, > > I'm interested to hear your perception or definition of how DI frameworks > are failing. That's quite possibly true but I'm not sure. Are they not > succeeding commercially and in adoption? Are they failing technically? > Obviously the community feels rather motivated to find a different answer. > When you say the dynamics were done wrong are you specifically referring to > the use of proxies to allow for bootstrap without concern for ordering at > the downside cost of perhaps a proxy never gets bound? > Service damping is an utter failure from my point of view. It simply cannot be used in a on premise product with optional features. We had blueprint in place for several months in the initial phases of our project and simply had to gut it out completely. We needed real non-busy wait behavior. Besides blueprint we also built our very own proxy based dependency mechanism for those places where we could not use DS or blueprint (because the code is outside the framework) on which we followed the very best practices based on blueprint's design and still it's subject to the same painful limitations. In short, there's simply no way wish away dynamics! The only solution is making the code aware of dynamics OR put the dynamics outside the reach of the code that can't handle it. We have lots of spring customers, we have lots of CDI customers, we have transactions, we have AOP, we have tones of proxies, we pretty much have the entire Java EE stack to support. But I simply will not subject them to the pain of service damping! - Ray Insights are always welcome. > > Brad > > On Tue, Jul 12, 2016 at 11:43 AM, Raymond Auge <[email protected]> > wrote: > >> >> 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) >> > > -- *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)
