Your questions about the other pieces of the stack and how they play in sort of echoes what this discussion brought up for me. If there is a collection of libraries and standard idiomatic elements like CDI to be recommended, what would that basic stack look like?
I'd sort of thought of this as a Service Core as opposed to a ServiceMix. It might include libraries that are such common dependencies and those that aren't necessarily used by a lot of other libraries but are so commonly used that they'd belong. The first category would include the obvious like camel-core and slf4j. The second would be things like JAXB and/or Jackson. Obviously if CDI is going to be idiomatic usage with the examples written for it, it would make sense to include that. Keeping that stack as slim as possible but no less, would make it very easy then to use features to add other things like ActiveMQ, CXF, rules engines. But keeping it slim would make it easy to test and create updated revisions while also keeping the number of configuration files down and the number of dependencies down. I'm not sure what that Service Core would look like but I think it would be a useful spring board for building on. It's easier to add to a stack than it is to take away. From: Nick Baker [mailto:nba...@pentaho.com] Sent: Monday, January 16, 2017 11:13 AM To: user <user@karaf.apache.org> Subject: Re: karaf boot I believe one of the goals of the "Boot" project should be to provide an easier introduction to developing with OSGI, Karaf and the broader community projects (CXF, Camel, etc.). One aspect of this is introducing developers to the dynamism, breadth and yes complexity of OSGI. We try to ease people into it here, but there's always another "gotcha" waiting for them around the corner. We have people here who can educate and unblock those newbies. There will need to be a good deal of "art" in progressively introducing these concepts in the documentation. There's also a lot of synergy between a simple/introduction Karaf instance and one which is tuned for microservices (startupFeatures only, CDI or SCR, read-only ConfigAdmin, simplified Aether resolution). This won't always be the case. Production deployments will want a fully populated /system directory and cache.clean turned off for instance. As for the Microservice aspect, I do agree that it should have some Remote Services implementation enabled out of the box, and a Message Bus to service internal communication as well as remote. Where is Event Admin? We're using Guava + Camel + JMS to handle inter/intraProcess communication. Anyway, the combination of the two is a solid foundation to build upon. -Nick Baker _____ From: Guillaume Nodet <gno...@apache.org <mailto:gno...@apache.org> > Sent: Monday, January 16, 2017 10:06:53 AM To: user Subject: Re: karaf boot 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 <mailto: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 <mailto:cschneider...@gmail.com> ] On Behalf Of Christian Schneider Sent: Monday, January 16, 2017 4:37 AM To: user@karaf.apache.org <mailto: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] On Behalf Of Christian Schneider Sent: Wednesday, January 11, 2017 8:52 AM To: user@karaf.apache.org <mailto: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 <mailto:gno...@redhat.com> Web: http://fusesource.com <http://fusesource.com/> Blog: http://gnodet.blogspot.com/
