I have investigated reworking the blueprint core extender on top of DS months ago, but I did not pursue. The Felix SCR core is now more reusable (I made it that way in order to reuse it in pax-cdi), so maybe I could have another quick look about the feasibility. But I am pessimistic as IIRC, the problems were more about some requirements in the blueprint spec which could not be mapped correctly to DS.
2017-01-16 15:44 GMT+01:00 Brad Johnson <bradj...@redhat.com>: > I wonder if there’s a way to start the implementation of a CDI common > practice with DS where possible but blueprint where not and then migrate > toward DS. > > > > From my point of view when mentoring new developer’s there are going to be > two general use cases for CDI, one is just for internal wiring inside a > bundle and dependency injection with internals. Among other things it > makes testing a heck of a lot easier. > > > > The other use case is an easy way to export services and get references to > them. I’m not sure how well DS and blueprint play together. > > > > It is also one of the reasons I’ve migrated away from using blueprint XML > for routes to the Java DSL. Consistent and easy for Java developers to > understand. Because I’ve used blueprint so much I have a limited > understanding of CDI but from what I’ve seen of it, it is a very sane way > of handling wire up. > > > > So the question I guess is how hard is it to create a migration plan to > move pieces from blueprint to DS under the covers? Does using the Camel > Java DSL make that easier? > > > > I don’t see a problem for a “next generation” of the stack to say that the > XML variant is no longer being supported and recommend migration to the > Java DSL with CDI. That isn’t difficult in any case. But from the > framework perspective it may eliminate one level of indirection that > requires XML parsing, schema namespaces and the mapping of those through a > plugin into the constituent parts. > > > > Would adopting such an approach make conversion away from blueprint > easier? Would it make a migration path easier? > > > > Brad > > > > *From:* Christian Schneider [mailto:cschneider...@gmail.com] *On Behalf > Of *Christian Schneider > *Sent:* Monday, January 16, 2017 4:37 AM > > *To:* user@karaf.apache.org > *Subject:* Re: karaf boot > > > > I generally like the idea of having one standard way to do dependency > injection in OSGi. Unfortunately until now we do not have a single > framework that most people are happy with. > > I pushed a lot to make blueprint easier by using the CDI and JEE > annotations and create blueprint from it using the aries blueprint maven > plugin. This allows a CDI style development and works very well already. > Recently Dominik extended my approach a lot and covered much of the CDI > functionality. Currently this might be the best approach when your > developers are experienced in JEE. Unfortunately blueprint has some bad > behaviours like the blocking proxies when a mandatory service goes away. > Blueprint is also quite complex internally and there is not standardized > API for extension namespaces. > > CDI would be great but it is is less well supported on OSGi than blueprint > and the current implementations also have the same bad proxy behaviour. So > while I would like to see a really good CDI implementation on OSGi with > dynamic behaviour like DS we are not there yet. > > DS is a little limited with its lack of extensibility but it works by far > best of all frameworks in OSGi. The way it creates and destroy components > when mandatory references come and go makes it so easy to implement code > that works well in the dynamic OSGi environment. It also nicely supports > configs even when using the config factories where you can have one > instance of your component per config instance. > > So for the moment I would rather use DS as a default dependency injection > for karaf boot. It is also the smallest footprint. When CDI is ready we > could switch to CDI. > > Christian > > > On 11.01.2017 22:03, Brad Johnson wrote: > > I definitely like the direction of the Karaf Boot with the CDI, blueprint, > DS, etc. starters. Now if we could integrate that with the Karaf profiles > and have standardized Karaf Boot containers to configure like tinkertoys > we’d be there. I may work on some of that. I believe the synergy between > Karaf Boot and the profiles could be outstanding. It would make any > development easier by using all the standard OSGi libraries and mak > microservices a snap. > > > > If we have a workable CDI version of service/reference annotation then I’m > not sure why I’d use DS. It may be that the external configuration of DS is > more fleshed out but CDI has so much by way of easy injection that it makes > coding and especially testing a lot easier. I guess the CDI OSGi services > could leverage much of DS. Dunno. > > > > In any case, I think that’s on the right track. > > > > *From:* Christian Schneider [mailto:cschneider...@gmail.com > <cschneider...@gmail.com>] *On Behalf Of *Christian Schneider > *Sent:* Wednesday, January 11, 2017 8:52 AM > *To:* user@karaf.apache.org > *Subject:* Re: karaf boot > > > > Sounds like you have a good case to validate karaf boot on. > > Can you explain how you create your deployments now and what you are > missing in current karaf? Until now we only discussed internally about the > scope and requirements of karaf boot. It would be very valuable to get some > input from a real world case. > > Christian > > On 11.01.2017 13:41, Nick Baker wrote: > > We'd be interested in this as well. Beginning to move toward Microservices > deployments + Remote Services for interop. I'll have a look at your branch > JB! > > > > We've added support in our Karaf main for multiple instances from the same > install on disk. Cache directories segmented, port conflicts handled. This > of course isn't an issue in container-based cloud deployments (Docker). > Still, may be of use. > > > > -Nick Baker > > > > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Open Source Architect > > http://www.talend.com > > > > > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Open Source Architect > > http://www.talend.com > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
