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, architecturedesign 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
