Hi, From the side of technology, what we need to run cloudstack management server is J2EE container (JPA, JTX and so on). As for J2EE contianer, there's a TomEE in apache project which is less generally available in common distribution packages. I think Tomcat is an appropriate option referring the availability. # But at the same time, I think TomEE would be appropriate because # cloudstack is also an apache project now.
We would need servlet because we need web UI to take control. For configuration files, I think whatever container we choose, those files would be look like as tomcat at last. There would be no big difference. (2013/03/03 22:04), Noa Resare wrote:
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
