As a currently-side-but-soon-to-be-main project for work, I’m looking at options and ideas for deploying Java web apps.
Our current infrastructure is normal and boring LAMP: DB server and N Apache+PHP boxes. Our app makes heavy use of SSL so we can’t do name virtual hosting. The current application gets “installed” into each sites docroot.
The “obvious” first solution is Tomcat with the Apache connector. This seems to work on paper: we already have a lot of “institutional” knowledge (despite Tomcat not really having shit to do with Apache proper), it ships with our distro so updates are handled without extra work, we actually have an Apache+PHP+Tomcat instance running for a customer (someone else did the Java) and despite a few glitches and pains (that large-scale dev would require me to solve), it actually works, is stable, and performs well.
I am perhaps swayed by fancy screencasts and white papers about other app servers, though: many offer fancy admin panels that show all sorts of exciting telemetry like memory usage, deployed apps, etc etc. I am not sure Tomcat offers anything even remotely like that. We’d have to write it; and we’re already considering a huge leap to a new platform and tool chain, so the idea of making lots of tools is both appetizing (great way to get deep into the guts of the platform we’re going to have to support) and depressing (I’d rather spend time on the actual app).
Many app servers are essentially repackaged Tomcat with additional pieces bolted on. But there’s your value-add: the very thing I mentioned. That shit takes work.
Other app servers, like JBoss, confuse and confound. Their FOSS offering is loose components, a big pile of Lego all over the floor. I have a $0.00 budget for this project but I can see how throwing some scratch at JBoss and saying, “Just send a fuckin tarball with the pieces I need” is extremely appealing. If integration took longer than a week to get ‘Hello, World!’ up and running, it’s a complete no-go.
There are additional hangups I can’t find clear answers to. Nearly all app servers seem to operate on the same conceptual model: the app server “owns” a domain, and apps are installed “into” it via URLs hung off /, eg www.dom.tld/app1, www.dom.tld/app2, etc. Each .war is installed as a separate instance.
I can’t figure out how to do “shared code” with wars and app servers. The way I was going to do it with PHP was, I’d build a more or less standard ZF app but each dom’s docroot would contain only the bootstrap and per-site views and layouts. That way everyone is running on the same bits. App upgrades upgrade everyone. You pay a price in complexity by spending a lot of time wrangling paths in your bootstrap (you ordinarily don’t need to, beyond setting the top level) but that’s about it.
Since Java apps are deployed as zipped blobs, and each instance is “unique”, I can’t even see how I’d do this, since it relies on a small amount of per-virtual-host wizardry separate from the blob. My understanding is, you can’t do that. Maybe I’m wrong? This shit is confusing.
Lastly I’ve considered using Apache or some other httpd as a proxy to an app server (probably nginx for performance reasons). I could install each instance in a URL off the app server’s notion of ‘/’ and proxy everything, so www.dom.tld maps to ‘internal.local/dom’ and www.dom2.tld maps to ‘internal.local/dom2′ and so on. This doesn’t necessarily solve any of the above problems, save for not asking the app server to do anything crazy.
All of these seem like ridiculously normal cookbook problems: I’ve got decent Google-fu and I find nothing. I also note that there’s very few Java-oriented hosting companies, which is essentially what we’re considering becoming (albeit hosting only our own app).
I should note that utilizing our app in a shared manner, a la Paypal’s skinnable-but-shared checkout service, is unacceptable. Our customers specifically reject a skinned app that takes them off their domain.
