On Jan 2, 2015, at 2:59 AM, Ian Duffy <i...@ianduffy.ie> wrote: > Just out of interest... > > Why do we use the embedded jetty for development purposes and then shipping > on tomcat?
I don't know _the_ answer but _an_ answer is that it used to be that embedded jetty was much leaner than embedded tomcat and so ant/maven/etc typically embedded jetty to shave some seconds of the build time. And then associated with that was some kind of belief that tomcat was a more robust/full-featured production deployment, because, you know, tomcat comes from apache, and they are good at web server stuff. Forward a decade, embedded tomcat is also lean, and production jetty is also common, as is running non-apache web servers :) > Why aren't we using embedded tomcat for development purposes? Does it > matter? It probably doesn't matter. From all I've seen, the cloudstack management server is a bog-standard web application, and both tomcat and jetty provide high quality implementations of the servlet API. > Is there any reason we don't ship a JAR with embedded tomcat and remove the > system dependency on tomcat? Ah, "best practice of java deployment on linux". Such a *lovely* topic :-) The way I see it... The perspective of the linux distribution is that applications should try and use distribution dependencies. It saves space, provides end user choice (via distro-provided alternatives mechanisms), and eases security patching and audit of that patching (upgrade tomcat once, all your java webapps get the patches). The perspective of many developers is that packaging tools are horrible, packaging processes are underdocumented, and linux distribution maintainers get between them and their users. See jpackage.org, along with rants like http://www.lucas-nussbaum.net/blog/?p=617 . The perspective of iaas/paas/saas style layer-cake splitting gave rise to things like http://12factor.net/ (you know, architecture&design rather than opinionated ranting :-D ) which gave rise to embedding the http stack inside the app. Patching concerns get swept aside by mature CI/CD pipelines, and the divide between developer and packager gets bested devops style...yay! :) > It cleans up the binary packages to no end. > Jenkins operates like this with the embedded version of jetty, their > installation is essentially just init script calling a JAR with a bunch of > parameters: https://github.com/jenkinsci/jenkins/tree/master/debian > Spring-boot is also follows a similar approach with tomcat embedded > http://spring.io/blog/2014/03/07/deploying-spring-boot-applications. Doing that IMHO also means signing up to produce security patched releases quickly whenever there's a flaw in a dependency. Which means you better have a very lean and highly automated release process, and minor releases that are a breeze to deploy. Right _now_, comparing release cycles for tomcat and cloudstack, I prefer to have tomcat outside cloudstack, so I can patch my http stacks when I need to, without going through a cloudstack upgrade procedure. > Why do we ship on a system version of tomcat rather than an embedded > version all contained within a JAR? Is there any specific reason why we > used tomcat over jetty for production purposes? ITT tomcat is the default/standard servlet container for most linux distributions. So when you use the distribution's servlet container, you end up with tomcat. I imagine that's the main reason. Just my 2 cents, err, guesses. Happy new year! - Leo
