Agreed about the testing. One problem with much of the Camel documentation is it shows the use of Processors/Exchanges instead of just POJOs. For the most part that sort of unit testing is simple if one isn’t using Processor/Exchanges. The CDI makes it even easier yet. But PAX and Camel Blueprint Test Support can be slow and fiddly.
Since Jetty is a simple web server it is commonly included in Karaf/application stacks. Its concerns are orthogonal to those of OSGi/Felix (or Equinox)/Karaf. OSGi based application servers like Glassfish use it for the web server/webservices. I think Jetty is about 10MB soaking wet. I’m not sure what dependency issues you ran into. One of the great benefits to having the classloader isolation in OSGi is that you can run different versions of the same library without stepping on one another. Obviously Docker/Kubernettes, etc. are not at odds with Karaf and exist at different levels. Spinning up multiple Docker containers for single services seems (A) heavy on processes, (B) heavu on configuration of URI/ports, and (c) potentially requires separate security set up for each.. Since Camel routing for received webservice calls is so simple it makes it a relatively easy proposition. So using the Karaf instance for multiple services isn’t just about the classloader isolation. But all that depends on the use case and it’s hard to make any sweeping generalizations. At some point that becomes as much art as science. Testing though is the biggest issue. With the static profiles it should be easy to run a Karaf instance, exercise it as a black box against some test stubs and verify basic operations. I wish they’d redo that Camel documentation to move the information about Procssor/Exhange to the equivalent of an Appendix. From: Elliot Metsger [mailto:[email protected]] Sent: Thursday, January 12, 2017 11:32 AM To: [email protected] Subject: Re: Levels of Containerization - focus on Docker and Karaf Hi, I'm involved in a project [1] that is based on Karaf and Camel. We recently produced a milestone that involved a working demonstration of the code base using Docker [2]. This was one of our first forays into this technology stack, so we not only came away with some impressions of the stack but also noted some of the same questions you ask with regard to the various containerization choices. Fundamentally, we noted that that properly testing our code to work in an OSGI container is challenging and time consuming (we used Pax Exam [3]); we would spend more time fiddling around with the test fixtures than actually writing tests and fixing any bugs they illuminated. Secondarily, we struggled at times to find and resolve any conflicts in our Maven dependency tree related to using an OSGI bundle instead of a dependency's non-OSGI counterpart. We also struggled with some of the nuances of running Karaf and Camel, including discovering bugs in each of these frameworks or their components. All of that being said, the result is something we are very pleased with. In order to produce our milestone demo, we containerized all of our services, which included two different instances of Karaf, an RDF triple store (Java web application server), the Fedora 4 linked data repository [4] (Java web application server), and other services (also a Java web application server). The exercise of producing this Dockerized milestone was very illuminating; we worked out some additional architectural issues and other bugs that our integration tests by themselves didn't do (and later added additional ITs to cover these discovered issues). Personally, my observation is that there seems to be a lot of overlap in containerization technologies, but it seems the levels of abstraction differ with different tradeoffs. For example, if you desire classloader isolation, you could use a single instance of Karaf running multiple services, or you could simply spin up a Docker container for each service, running each service in a traditional web app container. You'd have to decide if embracing Karaf and OSGI way of doing things is better than working with "heavy" Docker containers and traditional, stable, well-understood Java application servers like Jetty. Good discussion, I've enjoyed reading this thread! [1] https://github.com/fcrepo4-labs/fcrepo-api-x [2] https://github.com/fcrepo4-labs/fcrepo-api-x-demo [3] https://ops4j1.jira.com/wiki/x/PwA8Aw [4] https://github.com/fcrepo4/fcrepo4 On Wed, Jan 11, 2017 at 3:07 PM, CodeCola <[email protected] <mailto:[email protected]> > wrote: 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.
