thomasknierim.com

Ubuntu 10.04 alias Lucid Lynx has arrived and because this is a long-time support version, many users are bound to upgrade within the next few weeks. It seems like the GUI people from Canonical were unusually daring this time. Not only is this the first Ubuntu version that sports a graphical interface that is NOT BROWN (shock!), but the window control buttons are on the wrong side, namely on the left (double shock!). Apparently, Mac OSX Leopard has godfathered here. Well, I am not going to get used window controls on the left side, so I applied a quick fix which is amply documented on the Internet, as many people seem to feel the same way. Otherwise, the new look is a welcome change, as the permutations of brown and orange seemed to have been exhausted.

The only thing that turned out to be slightly trickier was the Tomcat upgrade to 6.0.24. A surreptitious installation of Apache 2 (the purpose of which eluded me) took possession of port 80 which on my machine was previously occupied by the system-wide Tomcat installation. This was rather easy to solve with the command: sudo update-rc.d -f apache2 remove to disable Apache on boot. It turned out, however, that the application launcher jsvc was removed in Ubuntu 10.04. Since Tomcat previously used jsvc to launch Tomcat on privileged ports, Tomcat was not able to bind to port 80 any longer. I was able to solve this by setting the AUTHBIND variable in /etc/default/tomcat to ‘yes’. After that Tomcat started up on port 80 without complaints.

During the upgrade, the system politely asked whether to replace or keep manually changed system configuration files. I have chosen to replace most files, because, the upgrade manager is kind enough to create a copy of the existing configuration using the *.dpkg-old extension during the upgrade. That way I was able to diff configuration files later and incorporate any customisations into the new files. This method is superior to keeping the old files, because it allows for upgrading the configuration files in sync with the latest program versions, though, of course it takes a bit of work manually diffing and patching those files if you happen to have numerous customisations. You can alternatively keep the old files and then diff and patch the new files created by the upgrade manager with the *.dist extension. In summary, the upgrade was painless and took less than 90 minutes per machine.

I am glad to announce the first release of the Scala Pages (SCP) lightweight web framework, which I wrote for a personal web application project. Although it’s still at a humble stage of development, I believe it is useful enough to be shared. I am planning to extend it in future and I hope that it will contribute to increased diversity in the Scala web development area. Software and manual can be downloaded from this page:

http://www.thomasknierim.com/scala-pages-web-framework/

The source code is included in the distribution zip file. Comments, suggestions, and constructive criticism are always welcome.

Addendum: I was asked to make a brief comparison to the Lift framework, so here’s my answer:

The approach that SCP takes is different. To put it in a nutshell, Lift is Rails-inspired, XML-oriented, and it abstracts from the Servlet API and the request/response model. SCP is inspired by traditional Java MVC frameworks; it is text-oriented, and it builds directly on the request/response model and the Servlet API.

Lift processes templates using the SAX-parser and presents Scala XML data structures to the programmer. By contrast, SCP reads templates as plain text from top to bottom, performs variable replacement and executes embedded instructions. Template processing with SCP thus consumes fewer resources. Lift uses prefixed XML tags; SCP uses processing instructions.

Lift wraps much of the Servlet API and presents a number of abstracted objects to the programmer, such as the S object, the SHtml object, LiftRules, and so on. SCP doesn’t do that. With SCP you get the familiar JEE objects such as HttpServletRequest, ServletContext, etc. and you use these directly from the Scala code. So, it’s easy to use if you’ve done Java web development.

The consequence is that you deal with the request/response model directly, which I personally prefer, because it keeps the control flow simple and clear. The only disadvantage of the MVC request/response model is that controllers tend to become bulky and difficult to reuse. The SCP solution to this problem is the same that Lift offers: snippets.

In SCP, snippets are processing instructions powered by a custom Scala class that the programmer provides. This means you can encapsulate application logic and/or complicated display logic into a snippet class which -if properly coded- is perfectly reusable. SCP also keeps template expressions very simple, because the more complex a template language becomes (many are even Turing-complete), the more likely it is for application logic to sneak into the view. Currently, iteration is the only supported type of control-flow.

Last but not least, Lift is huge compared to SCP. It has a lot of functionality that SCP does not offer, at least not at this time.

As you can gather from the title of this website, I create software in Java, Scala, and PHP. While Java and Scala compile to bytecode that runs on the same virtual machine, PHP is executed by a separate interpreter. The most efficient way to run PHP scripts is to integrate the interpreter directly into the webserver. Hence, most PHP developers use a local Apache Httpd server with mod_php for development. If you also do Java programming, this raises the problem that you need two different web servers, namely Tomcat (or another web container or appserver) for Java development and Apache for PHP development.

Running two servers is a bit of a nuisance. Two servers consume more resources than one and you cannot run both on the same port. This problem can be solved in three different ways: you can only run one server at a time, you can use a different port number for one server which has to be included in the URLs, or you can integrate the two servers. There are again at least three different ways to accomplish the latter: you can proxy requests from Apache to Tomcat, you can proxy request from Tomcat to Apache, or you can use a connector module, such as mod_jk. Of course, maintaining two servers is is more complicated than maintaining one, and the integration adds additional complexity. Fortunately, there is an easier way to integrate PHP and Java web applications.

PHP/Java Bridge is a free open source product for the integration of the native PHP interpreter with the Java VM. It is designed with web applications in mind: Java servlets can “talk” to PHP scripts and vice versa. The official website describes it as an “implementation of a streaming, XML-based network protocol which is up to 50 times faster than local RPC via SOAP.” PHP/Java Bride requires no additional components to invoke Java procedures from PHP or vice versa. Although there are a number of different use cases, I am going to describe a particular one in this article, namely how to configure Tomcat with PHP/Java Bridge in order to have Tomcat serve PHP web pages. Let’s start with software requirements. We need the following software packages:

• A Java virtual machine (JRE is sufficient, but JDK recommended for developers)
• A recent version of Apache Tomcat (http://tomcat.apache.org)
• A recent version of PHP (standalone, without Webserver: http://php.net)
• PHP/Java Bridge (http://php-java-bridge.sourceforge.net/pjb/)

Follow the standard installation procedures for the JVM, Tomcat, and PHP. On Linux, you can use the standard packages for your distribution and on Windows you can use the regular installers. Make sure that both Tomcat and PHP are installed properly, which means that you should see Tomcat’s welcome web page at http://localhost:8080 and you should be able to execute a PHP script via the command line by invoking the standalone “php” command. The PHP/Java Bridge product does not use the regular executable, however, but fast CGI. The fast CGI executable is called php-cgi (or Php.cgi.exe on Windows), so you must make sure that your PHP installation contains it. Then you are all set to install and configure the PHP/Java Bridge.

The PHP/Java Bridge package comes with a sample web application named JavaBridge.war. Deploy the application in Tomcat, point your browser to http://localhost:8080/JavaBridge and try out the examples. If this works, you are half-finished. To provide the capability to execute PHP scripts server-wide, not just in a single web application, you need to make some changes to the Tomcat configuration. Find the three jar files named JavaBridge.jar, php-servlet.jar and php-script.jar (look in WEB-INF/lib) and move them to Tomcat’s shared library directory. This is usually found in $CATALINA_HOME/lib (or $CATALINA_HOME/shared in older Tomcat installations). Then edit Tomcat’s conf/web.xml configuration file and add the following lines:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

<listener>
  <listener-class>
    php.java.servlet.ContextLoaderListener
  </listener-class>
</listener>
 
<servlet>
  <servlet-name>PhpJavaServlet</servlet-name>
  <servlet-class>
    php.java.servlet.PhpJavaServlet
  </servlet-class>
</servlet>
 
<servlet>
  <servlet-name>PhpCGIServlet</servlet-name>
  <servlet-class>
    php.java.servlet.PhpCGIServlet
  </servlet-class>
  <init-param>
<param-name>prefer_system_php_exec</param-name>
<param-value>On</param-value>
  </init-param>
  <init-param>
<param-name>php_include_java</param-name>
<param-value>On</param-value>
  </init-param>
</servlet>
 
<servlet-mapping>
  <servlet-name>PhpJavaServlet</servlet-name>
  <url-pattern>*.phpjavabridge</url-pattern>
</servlet-mapping>
 
<servlet-mapping>
  <servlet-name>PhpCGIServlet</servlet-name>
  <url-pattern>*.php</url-pattern>
</servlet-mapping>

This adds the listeners and servlets required for PHP script execution to all web applications. While you are at it, you might also want to enable index.php files to display when a directory URL is requested. Simply add it to the list of welcome files in conf/web.xml. My list looks like this:

1
2
3
4
5
6

<welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
    <welcome-file>index.php</welcome-file>
</welcome-file-list>

Now you can copy PHP scripts into the context root directory of any web application and type the script URL into your browser. I suggest you try a script with phpinfo(). It gives you plenty of useful configuration info. If this doesn’t work and you are on Unix, the problem might be file permissions. On my machine, I had to copy the contents of “java” directory in the JavaBridge webapp manually to the context root directory where PHP applications were installed. This directory contains two files Java.inc and JavaProxy.php. Normally, the PHP/Java Bridge software copies it automatically, but it might not be able to do so if it does not have proper permissions:

~$ ls -lh /var/lib/tomcat6/webapps/ROOT/java
total 136K
-rw-rw-r-- 1 root root 64K 2009-12-30 14:14 Java.inc
-rw-rw-r-- 1 root root 64K 2009-12-30 14:14 JavaProxy.php

Now try calling a PHP script. For example, a script containing the phpinfo() command displays information about the server:

I have configured my machine to host all PHP web applications in Tomcat’s ROOT context. This eliminates the extra path component of the webapp context, since the ROOT’s context path is “/”. Then I softlinked the folder that contains all my PHP projects into the ROOT webapp directory, so that the actual source files are kept separate from the Tomcat installation. In order to enable Tomcat to follow symlinks, you need to edit the context.xml of the respective web application -in this case ROOT- and add the line: <Context path=”/” allowLinking=”true” /> .

Another possible gotcha is Tomcat’s security manager, which is enabled by default on Ubuntu, but not on Windows. Although a security manager is not necessary for most development scenarios, it is highly recommended for production. I consider it good practice to enable the security manager on the development machine, because it allows me to recognise security problems early during development, before the application is deployed on the production server. The downside is that additional configuration may be required, for PHP applications to function properly. The respective configuration files are located in $CATALINA_BASE/conf/policy.d. Most likely, you need to grant PHP web applications write access to files in the document root and possibly other permissions, such as opening sockets, etc. It’s probably safest to do this on a per-application basis.