Hi Noa, I like your proposal a lot. This was exactly our question when we saw how this is was done in waf. It was obvious to us at the time that waf tried to make cloudstack look like a linux native application by spreading it to /etc, /var, /usr/share etc and took it away from its webapp origins. I have a few questions/comments.
- Are you sure to get into distros it doesn't have to look like a linux app? That was why we agreed to it so I want to double check here. - How would it look in distros if it is a webapp? - I don't think we have any loyalty to tomcat. Nor should we. - What about the system.iso? Is that packaged in the war too? Thanks. --Alex > -----Original Message----- > From: Noa Resare [mailto:n...@spotify.com] > Sent: Sunday, March 3, 2013 5:04 AM > To: cloudstack-dev@incubator.apache.org > Subject: [DISCUSS] fixing the tomcat situation, post 4.1? > > So, when working with the 4.1 packaging issues I have more than once been > intensely frustrated with the current tomcat situation. > > To recap: Some cloustack components are set up as web applications and > requires a servlet container as their execution environment. The current > solution to provide such as servlet container is to have the cloudstack > package depend on an Apache Tomcat 6 package provided by the OS > distribution. Cloudstack then ships copies of the configuration files needed > by tomcat to run along with init scripts that bootstraps tomcat in a way that > references the cloudstack shipped artifacts. This setup has many problems. > > # Cloudstack assumes that it's configuration files will be enough in sync with > what the externally provided tomcat expects. > > # Lots and lots of fairly esoteric config files included in cloudstack makes > the > learning curve steep > > # Tomcat setup, as it stands without trying any specific hackery to make it do > other stuff, is a labyrinth of shell scripts > > # Things gets even more complicated when cloudstack invokes tomcat > provided scripts. > > # tomcat has it's own log files for the early parts of it's startup. > > It shouldn't need to be this hard. webapps are standardized for a reason, and > the requirements we have on a servlet execution environments are not that > special (one webapp on /client listening one port, and possibly another > webapp for the aws stuff listening on another port) > > As a proof of concept I hacked together the starting points of a replacement > for this whole mess yesterday, a few tens of lines of code setting up an > embedded jetty web container. A few lines of code to parse a config file, set > up logging and spawn an embedded servlet container. > > Points of discussion: > > # What features do we need for our servlet container? Do I miss anything > obvious? > > # Do we have some kind of loyalty towards tomcat, it being one of the main > apache projects after all? 2 minutes of googling seems to indicate that there > are embedded tomcat options as well, but I know jetty better so that > seemed like a better stating point for my proof of concept. > > My proof of concept code is available here: > https://github.com/noaresare/incubator-cloudstack/tree/noa/runner > > /noa > > > > > -- > Engineering Experience, Infrastructure tribe, Spotify
