I fully agree. However, I'm not sure if there are any pieces actually missing but some documentation and advertisement ... We could eventually add a bit of tooling, but I'm not even sure that's really needed.
Guillaume 2017-01-12 16:46 GMT+01:00 Brad Johnson <[email protected]>: > Guillaume, > > > > I’d mentioned that in an early post as my preferred way to do > microservices and perhaps a good way of doing a Karaf Boot. I’ve worked > with the Karaf 4 profiles and they are great. Also used your CDI OSGi > service. If we could use the Karaf 4 profiles with the CDI implementation > with OSGi services and the Camel Java DSL as a standard stack, it would > permit focused development and standardized bundle configurations. > > > > When I created a zip with Karaf, CXF and Camel the footprint was 30MB. > > > > While having Karaf Boot support DS, Blueprint, CDI, etc. I’m not sure > that’s the healthiest move to encourage adoption. We need less > fragmentation in the OSGi world and not more. Obviously even if Karaf Boot > adopts one as the recommended standard it doesn’t mean that the others > can’t be used. When reading through Camel documentation on-line, for > example, the confusion such fragmentation brings is obvious. One becomes > adept at converting Java DSL to blueprint or from blueprint to the Java DSL > in one’s mind. > > > > The static profiles work great and will let us create a number of > standardized appliances for a wide variety of topology concerns and not > just for microservices. A “switchboard” appliance, for example, might be > used for orchestrating microservices and managing the APIs. A “gateway” > appliance might have standard JAAS, web service configuration and a routing > mechanism for calling microservices. An “AB” appliance could be used for > 80/20 testing. And so on. Take the idea of enterprise integration > patterns and bring it up to enterprise integration patterns using Karaf > appliances. > > > > Many appliances might be “sealed”. An appliance for AB testing, for > example, would have configuration for two addresses in the configuration > file and a percentage of traffic going to each. Non need to actually > program or re-program the internals any more than we’d usually re-program a > Camel component. But the source would be there if one wanted to create a > new component or modify how an existing one functioned. > > > > I’d vote for using CDI along with the Camel Java DSL for a couple of > reasons. The first would be the standardization and portability of both > code and skills. Using CDI would mean that any Glassfish, JBoss, etc. > developer would feel comfortable using the code. Using Java Camel DSL > would be for the same reason. It would also give a programmer a sense that > if they give Karaf Boot with the static profiles a shot, they aren’t locked > in but can easily move to a different stack if necessary. In a sense this > is the same reason that Google chose Java language to run on the DVM. It > tapped into a large existing skillbase instead of trying to get the world > to adopt and learn a new language. CDI with OSGi extensions also allows > developers to use one paradigm for everything from lashing up internal > dependency injections to working with OSGi services. I believe when you put > that CDI extension out there you used blueprint style proxies under the > cover. As a developer using the CDI OSGi extension it was transparent to > me. If you later decided to rework that as a DS service, it would remain > transparent and very much in the whole spirit of OSGi and its mechanisms > for allowing refactoring and even rewriting without breaking the world. It > also makes unit testing a snap. Any of us who have wrestled with Camel > Blueprint Test Support can appreciate that. > > > > This would also permit for standardization of documentation and of Karaf > Boot appliance project structures and Maven plug-in use. A bit of > convention over configuration. Projects would have a standard > configuration.cfg file that gets deployed via features to the pid.cfg. A > standard features file in the filtered folder. Those already exist, of > course, but it isn’t as standardized as it could be. > > > > Personally I think this sort of goal with CDI, Karaf 4 and its profiles, > and Camel Java DSL should be accelerated since Spring Boot is already out > there. Waiting for another couple of years to release this as a standard > might be too late. > > > > The pieces are already there so it isn’t like we’d have to start from > scratch. This would also play well with larger container concerns like > Docker and Kubernettes. > > > > Brad > > > > *From:* Guillaume Nodet [mailto:[email protected]] > *Sent:* Thursday, January 12, 2017 4:55 AMJ > *To:* user <[email protected]> > *Subject:* Re: Levels of Containerization - focus on Docker and Karaf > > > > Fwiw, starting with Karaf 4.x, you can build custom distributions which > are mostly static, and that more closely map to micro-services / docker > images. The "static" images are called this way because you they kinda > remove all the OSGi dynamism, i.e. no feature service, no deploy folder, > read-only config admin, all bundles being installed at startup time from > etc/startup.properties. > > This can be easily done by using the karaf maven plugin and configuring > startupFeatures and referencing the static kar, as shown in: > > https://github.com/apache/karaf/blob/master/demos/ > profiles/static/pom.xml > > > > > > 2017-01-11 21:07 GMT+01:00 CodeCola <[email protected]>: > > Not a question but a request for comments. With a focus on Java. > > Container technology has traditionally been messy with dependencies and no > easy failsafe way until Docker came along to really pack ALL dependencies > (including the JVM) together in one ready-to-ship image that was faster, > more comfortable, and easier to understand than other container and code > shipping methods out there. The spectrum from (Classical) Java EE > Containers > (e.g. Tomcat, Jetty) --> Java Application Servers that are containerized > (Karaf, Wildfly, etc), Application Delivery Containers (Docker) and > Virtualization (VMWare, Hyper-V) etc. offers a different level of isolation > with different goals (abstraction, isolation and delivery). > > What are the choices, how should they play together, should they be used in > conjunction with each other as they offer different kinds of > Containerization? > > <http://karaf.922171.n3.nabble.com/file/n4049162/ > Levels_of_Containerization.png> > > > > -- > View this message in context: http://karaf.922171.n3.nabble.com/Levels-of- > Containerization-focus-on-Docker-and-Karaf-tp4049162.html > Sent from the Karaf - User mailing list archive at Nabble.com. > > > > > > -- > > ------------------------ > Guillaume Nodet > ------------------------ > > Red Hat, Open Source Integration > > > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
