Guillaume, I was working with Camel SCR over the week end evaluating readiness and state for my next project. So I came back to read your comments about the pax-cdi. While there's a great deal to like about Camel SCR and DS and from all the reading about the problems with service damping it appears that blueprint will either have to fundamentally change in the future or be replaced.
The problem I ran into with Camel specifically was the lack of mechanics for doing any injection of beans for use in routes. Standard annotations don't work and the implementation is very much a straight jacket. Since I'm working almost exclusively in middleware and integration Camel is at the heart and soul. I suspect that 90% of those of us who use blueprint are in that crowd. The great irony in Camel is it is very easy to go from XML to invoke handlers/beans by very simple reference mechanics but trying to do the same thing from the Camel Java DSL isn't any easier and in Camel SCR it is extremely inelegant - .method(this, "invokeMyMethod") where one can't even call the method directly. I'm rewriting an existing application that was written entirely in blueprint XML and XSLTs to be in Java using beanio, dozer, handlers and other more developer friendly items. But it didn't appear there was going to be an easy way to do that with SCR without converting the one bundle into about 10. I think the real issue there might be something like external OSGi concerns versus internal wiring and dependency injection of bundle internals. That seems non-existent. I recognize that isn't directly your concern or project just and observation. Brad On Wed, Jul 13, 2016 at 2:32 AM, Guillaume Nodet <gno...@apache.org> wrote: > 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 <david_jen...@yahoo.com>: > >> 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 <gno...@apache.org> 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 <raymond.a...@liferay.com>: >> >>> >>> On Tue, Jul 12, 2016 at 11:57 AM, Guillaume Nodet <gno...@apache.org> >>> 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: gno...@redhat.com >> Web: http://fusesource.com >> Blog: http://gnodet.blogspot.com/ >> >> >> > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > >
