Legacy PHP on Quercus: Checklist

Since Friday I’ve been playing with Quercus off and on. Running pieces of my company’s legacy code, playing, integrating and accessing Hibernate in PHP code (pretty sweet), and then actually adding some simple (but sane) Hibernate management (initialization and implementing the Hibernate session-per-request pattern for PHP scripts).

Throughout my work today, I experimented with deploying a full legacy application to Jetty. For the uninitiated (like me), Jetty can be somewhat of a bear, but it is extremely fast and very flexible. It’s also a bit complicated when you’re coming from mod_php’s narcissistic, share-nothing paradigm, to Java’s threaded, share-everything opinion. In deploying our applications, we’ve got several things to deal with, apart from the wholesale switch from C-PHP to Quercus:

• Virtual hosts. Our applications (well over 20) all run on our dedicated server, served by Apache and set up as virtual hosts. Some of them are mapped to their own IP address, others share one.
• SSL. Most, if not all of our applications, require SSL.
• URL rewriting. Most of our newer applications rely on Apache’s mod_rewrite to clean up URLs, so something like http://foo.com/index.php?page=MyAccount becomes http://foo.com/MyAccount.
• Symbolic links. Most, if not all of our applications make a ridiculously large use of symlinks.

All this along side digesting the JEE architecture of servlets, and how Jetty implements that. I don’t intend to suggest to my company that old-school servlet technology is the way to go; quite the opposite in fact (when in straight Java I’m a T5 guy). However, when getting into an environment where concurrency matters and there’s such a thing as an actual execution lifecycle, it would be prudent to have a thorough understanding of what’s going on, where, when and why.

Assuming my company elects this route, and I sincerely hope they do, I’ll be documenting the journey. The server side tool-chain will be Jetty, Quercus, and UrlRewrite.