March 23, 2009

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.

8:10pm  |   permalink
FILED UNDER: java php programming jetty quercus 
March 22, 2009

Sundays, Numeric Literals

Programming languages generally allow you to deal with numeric values using a literal syntax. In Ruby (irb), for example:

» 5*5
=> 25

This is a literal expression of multiplying 5 by 5, resulting in 25. Often, languages also provide a literal syntax for expressing numbers of a different number system. Consider this snippet of Java code that creates three integer primitives, each with a decimal value of 15:

int iDec = 15;    // decimal
int iOct = 017;  // octal (base 8)
int iHex = 0xF;  // hexadecimal (base 16)

I was poking around some legacy PHP that has been lurking around my company for some time. I was doing this because we’re seriously considering an exciting new direction that would include deploying legacy PHP in a Java servlet container, via Quercus. In one application, the Quercus interpreter fell over with a deceptive error message when it encountered a specific numeric literal: 078051120. In the end I see this as a good thing, because it alerted me of a bug in our software. This literal was part of an array declared to contain a list of known bogus social security numbers. The programmer had intended for this value to represent the would-be SSN of ‘078051120.’ However, that is wrong and I’m glad Quercus broke (where the PHP C implementation happily moves along).

PHP, like Java, supports literal numeric values in different number systems. Therefore, any literal starting with the digit ‘0’ is interpreted as an octal value. The stupid thing about how PHP handles a literal like ‘078051120’ is that it doesn’t complain at all about the number ‘8.’ The octal system is base 8, and so the only valid digits are 0, 1, 2, 3, 4, 5, 6, and 7.

The other frustrating part is the mistake. Even if the example were a valid octal literal (like 077051120), the code would still be horribly broken. This is because the programmer expected the value to represent the SSN of 077051120, when in reality it represented the decimal value of 16536144.

Be aware of how your chosen languages handle numeric literals!

4:34pm  |   permalink
FILED UNDER: php programming mistakes