The setup described in the article seems redundant and risky to me.
Tomcat can already determine between various hostnames on the fly. You can have multiple Hosts in a single server.xml file, and each Host can have one or more Contexts (webapps). Tomcat will direct requests to the appropriate Host, or to the default Host if there are no matches. All of this is built-in.
So, you could do away with adding application code to index.jsp and using an external properties file because this is something Tomcat already does for "free". You could just create many Hosts, and deploy the akc webapp to each Host. Then you're done.
At that point, your webapp would already know that a request to www.foobar.com was related to account foobar...no extra code and no external properties file necessary.
This gets you the added benefit of separating each webapp out per domain. In a commercial webhosting situation, sharing one webapp among many clients would be encouraging data integrity and security problems, since conceivably one client would have access to another client's information. If all clients are using the same webapp and the same database tables, how do you keep one client from accessing another's data without all sorts of additional code overhead to differentiate one recordset from another within a table?
Couldn't you also simply create a database for each domain, a Tomcat Host for each domain, and deploy the web app to each Tomcat Host? No need to modify index.jsp, and no need for any sort of proxy arrangement.