Configuration Files

If you are not familiar with Struts or the JavaEE Servlet Specification, you might be thinking, What the heck are these configuration files all about? Well, you have come to the right place, because here we will iron out all those details.

Before we get into the fun stuff, we have to stop and understand the Apache configuration a bit. Being that Studs is a PHP application, it certainly does not need an .htaccess file to run. However, there are some very important settings in this file that setup the PHP environment correctly. Since there are many different ways to configure PHP, it is necessary to “tare” the configuration so that Studs knows what to expect.

Some problems await us though, because not all Apache configurations allow for manipulation of settings via the .htaccess file. If you are running Studs from a virtual host, it is necessary to have the following directive in the host definition. Otherwise, a Internal Server Error could result.

AllowOverride Options

This setting permits the use of the php_value flag. With it, settings for error handling, magic quotes, register globals and call time pass reference are adjusted to their proper values. There is also some FileMatch directories for increasing security as explained in Pretty URLs.

Bizarre as it may seem, the servlet specification defines a directory named /WEB-INF/ inside the web directory that holds the configuration data for a web application. (This folder is a protected area for storing such configuration details). The file of most importance is the /WEB-INF/web.xml file. It essentially defines the mappings between URL requests and classes that will process those requests. It can also define initialization parameters and other types of web specific mappings. In order to simulate the JavaEE Servlet Specification, the stratus module of Studs MVC+ parses this configuration file and manages these types of configuration.

While Studs MVC+ uses the format of the JavaEE web module deployment descriptor, it does not yet use all of its elements. The subset of top level elements that Studs does use are:

• display-name
• description
• context-param
• servlet
• servlet-mapping
• mime-mapping
• welcome-file-list

If you are using Studs MVC+ primarily for the MVC servlet that is provided, you probably won’t spend a lot of time messing with this file. That is because the Studs servlet relies on another configuration file, /WEB-INF/struts-config.xml, which provides a second level of mapping to handle URL requests, along with a bunch of other configuration options.

Document how umask() sets the permissions for all file writing and directory creating done by the servlet container.

The equation for how this value is used can be seen by executing:

printf("directory permission: %04o\n", 0777 & (0777 - umask()));
printf("file permission: %04o\n", 0666 & (0666 - umask()));

PHP is notoriously atrocious at validating XML files. In fact, PHP has never really been up to par with XML at all, which is why most XML libraries for PHP fall back to the original SAX libraries. Therefore, the XML validation in Studs is somewhat of a hack. Even in the current codebase, the DOMXML validation is commented out until there is an elegant enough solution. I mean, just look at the hoops you have to go to to register local DTDs!

Anyway, enough ranting and raving. Here is what happens. The web.xml always has validating turned on, whereas the struts-config.xml validation can be controlled through the validating initialization parameter in the servlet definition for Studs. When validation is active, a commandline call to xmllint is attempted. If this program is not present (or this is a windows system), validation returns a successful result. Otherwise, the validation is attempted using local DTDs. If there are errors, they are wrapped in an exception and thrown.

I would attempt validation using PHP’s domxml extension, except that the either DTD declaration in the XML has to refer to a relative local resource, or the library is going to try to go out onto the net to get the DTD (unless, of course, catalogs are used), but that still presents too much room for disaster.

• Understanding web.xml files