Plain-vanilla Java Servlets and Pretty URLs

I'm writing this because I was recently asked about the growing complexity of Java-based web MVC frameworks. It made me think about the kinds of web applications a Java developer can build with just the plain-vanilla Java Servlets.

As I was pondering on the thought, I could not help ask myself about the following:

• What happens to pretty URLs?
• How can we add page templates like those provided by SiteMesh and Apache Tiles?

Pretty URLs and Mapping Conventions

It's common nowadays to consider question mark (?) and ampersand (&) characters in the URL as being ugly. But are they really that bad? Do they really affect SEO in a negative way? The truth is... it is just a myth. Why would Google (and other search engines) put so much weight on the URL? Fact is... Google will (and should) do a good job by looking into the contents the URL is pointing to. It should not just be looking at the URL. If it did put so much weight on URLs, then we'll all be filled with spammed links by those who just want to be on top of SERPs.

If so, how do we now map URLs to Java servlets? Below show the typical URL mapping.

Method	URL	Action
GET	/magazines	index (default)
GET	/magazines/{id}	show
GET	/magazines/{id}/edit	edit	Render HTML form for editing magazine with given {id}
PUT	/magazines/{id}	update	Updates magazine with given {id}. Redirect to GET /magazines.
GET	/magazines/new	new	Render HTML form for new magazine.
POST	/magazines	save	Save magazine ad and generate new unique ID. Redirect to GET /magazines.
DELETE	/magazines/{id}	delete	Remove magazine with given {id}

Given the above URL mappings, it's impossible to implement using a web.xml. So, are we really forced to use the above conventions? Are we really forced to use a single servlet, mapped to /app/*, and have it apply a regular expression to determine which controller should handle the incoming request?

IMO, we should not be forced to do so. Assuming you'd allow URLs that contain question marks (?) and ampersands (&), we can have the following mappings.

Method	URL	Action
GET	/magazines	index (default)
GET	/magazines?id={id}	show
GET	/magazines?id={id}&edit	edit	Render HTML form for editing magazine with given {id}
PUT	/magazines?id={id}	update	Updates magazine with given {id}. Redirect to GET /magazines.
GET	/magazines?new	new	Render HTML form for new magazine.
POST	/magazines	save	Save magazine and generate new unique ID. Redirect to GET /magazines.
DELETE	/magazines?id={id}	delete	Remove magazine with given {id}

The above mappings are definitely possible to implement in a web.xml. It just needs a servlet mapped to /magazines/*. It will also need a filter to support the translation of PUT and DELETE methods (as most browsers only support GET and POST). As for nested resources/namespaces, a similar approach applies. It will need another servlet mapped to /magazines/ads/*.

Method	URL	Action
GET	/magazines/ads?m_id={magazine_id}	index (default)	List ads under the magazine with the given {magazine_id}.
GET	/magazines/ads?m_id={magazine_id}&id={id}	show	Show magazine ad with given {id}.
GET	/magazines/ads?m_id={magazine_id}&id={id}&edit	edit	Render HTML form for editing magazine ad with given {id}
PUT	/magazines/ads?m_id={magazine_id}&id={id}	update	Updates magazine ad with given {id}. Redirect to GET /magazines/ads.
GET	/magazines/ads?m_id={magazine_id}&new	new	Render HTML form for new magazine ad.
POST	/magazines/ads?m_id={magazine_id}	save	Save magazine ad and generate new unique ID. Redirect to GET /magazines/ads?m_id={magazine_id}.
DELETE	/magazines/ads?m_id={magazine_id}&id={id}	delete	Remove magazine ad with given {id}

To extend the conventions further, each servlet acting as controller (in MVC) should forward to a view (typically implemented as a JSP). These JSPs can be located under /WEB-INF/views/magazines and /WEB-INF/views/magazines/ads to match their servlet URL mappings.

Templating Frameworks

I find it more and more common to use SiteMesh or Tiles in developing Java-based web applications. In fact, it would be uncommon to see a Java web application that does not use SiteMesh or Tiles.

After doing some research, I found a lesser known feature of Java Server Pages (JSPs) 2.0: <include-prelude> and <include-coda>. These allow developers to have templates included in the beginning and end of all JSPs that matched the URL.

An example configuration in web.xml looks like this:

  <jsp-config>
    <jsp-property-group>
      <url-pattern>*.jsp</url-pattern>
      <include-prelude>/WEB-INF/includes/prelude.jspf</include-prelude>
      <include-coda>/WEB-INF/includes/coda.jspf</include-coda>
    </jsp-property-group>
  </jsp-config>

The *.jspf is just a common filename extension for JSP fragments.

If the page layout is simple enough to allow a header and footer implemented as a prelude and coda, then using this JSP 2.0 feature should do the trick.

Conclusion

So, is it really that bad? What do you think?

IMO, it's not that bad. There's definitely more to building web apps using just plain Java Servlets and JSPs. But these alone are quite powerful. And the MVC frameworks enhance it further.

That's all for now. Happy holidays!

2019 September Update

If you'd like to know more, checkout how a Java Servlet works. It even contains a cool trivia about the people who created the Java Servlet 1.0 specification! Happy reading!

Spring MVC Slow on Google App Engine for Java?

We previously tried deploying Spring-based Java web applications on Google's App Engine (GAE). And I remember abandoning it due to the time it takes to handle a loading request.

Now, I was able to get some time to create a minimal Spring MVC web application and see how it performs on GAE. Below is the result. The web.xml loads the ContextLoaderListener and DispatcherServlet. The application context is empty (i.e. no beans). The dispatcher-servlet.xml contains a <context:component-scan /> tag and a ViewResolver. It takes about 6.75 seconds for a loading request (approximately cpu_ms=3600).

6.75 seconds for a loading request is probably not much. But the 1100 cpu_ms by slim3 is sure enviable. I also found this article helpful in explaining the cause of increase in loading request time.

Here's some detailed log entries:

javax.servlet.ServletContext log: Initializing Spring root WebApplicationContext
…
org.springframework.web.context.ContextLoader initWebApplicationContext: Root WebApplicationContext:
initialization completed in 2420 ms
…
javax.servlet.ServletContext log: Initializing Spring FrameworkServlet 'dispatcher'
org.springframework.web.servlet.FrameworkServlet initServletBean: FrameworkServlet 'dispatcher': initialization started
…
org.springframework.web.servlet.FrameworkServlet initServletBean: FrameworkServlet 'dispatcher':
initialization completed in 2995 ms

Looks like the DispatcherServlet eats up some processing time. If we just use the ContextLoader, and plain-vanilla servlets, the loading request time should be tolerable.

Google Closure Compiler with Maven Builds

In my previous post, I showed how we used Closure Library with our Maven-based project. More specifically, we used the Jetty Maven plugin to expose the JS code, and make it available in raw form for a fast and convenient code-run-debug cycle. This time, let me show how we used the Closure Compiler to compile and generate the minified JS file, and how we used it in our builds.

Running Closure Compiler

Running the compiler was a bit tricky. Since we didn't have just one single JS file, we needed to provide the compiler a list of JS files in the correct order (where providing classes are declared before the ones that required them). Good thing the library comes with Python scripts that does just that.

<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>exec-maven-plugin</artifactId>
 <executions>
  <execution>
   <id>calculate-dependencies</id>
   <phase>process-sources</phase>
   <goals>
    <goal>exec</goal>
   </goals>
   <configuration>
    <executable>python</executable>
    <arguments>
     <argument>src/main/js/closure-library/closure/bin/build/depswriter.py</argument>
     <argument>--root_with_prefix</argument>
     <!-- prefix is relative to location of closure-library/closure/goog/base.js -->
     <argument>src/main/js/myapp/ ../../../myapp/</argument>
     <argument>--output_file</argument>
     <argument>src/main/js/myapp/deps.js</argument>
    </arguments>
   </configuration>
  </execution>
  <execution>
   <id>compile-javascript</id>
   <phase>prepare-package</phase>
   <goals>
    <goal>exec</goal>
   </goals>
   <configuration>
    <executable>python</executable>
    <arguments>
     <argument>src/main/js/closure-library/closure/bin/build/closurebuilder.py</argument>
     <argument>--root</argument>
     <argument>src/main/js/closure-library</argument>
     <argument>--root</argument>
     <argument>src/main/js/myapp</argument>
     <argument>--output_mode</argument>
     <argument>compiled</argument>
     <argument>--compiler_jar</argument>
     <argument>src/lib/closure-compiler-20120430.jar</argument>
     <!-- WHITESPACE_ONLY, SIMPLE_OPTIMIZATIONS, ADVANCED_OPTIMIZATIONS -->
     <argument>--compiler_flags=--compilation_level=ADVANCED_OPTIMIZATIONS</argument>
     <!-- QUIET, DEFAULT, VERBOSE -->
     <argument>--compiler_flags=--warning_level=VERBOSE</argument>
     <argument>--namespace</argument>
     <argument>myapp</argument>
     <argument>--output_file</argument>
     <argument>${project.build.directory}/replaced-webapp/scripts/myapp.min.js</argument>
    </arguments>
   </configuration>
  </execution>
 </executions>
</plugin>

I've included the portion that calculates dependencies (from my previous post). Note that use of src/lib/closure-compiler-yyyymmdd.jar. You can download it from here, and extract the compiler.jar file. We just renamed it so we can track which version we're using. And in case of updates, just update the pom.xml.

Note also that we invoke the compiler during the prepare-package phase. This means that when you run jetty:run, the compiler does not get invoked. This makes it faster (and easier to repeat). But when you need to run/debug with the compiled/minified form (with advanced optimization), you run jetty:run-war.

The astute reader would notice that the minified file is currently not being referenced in any web page. This shall be explained in the next section.

Replacing Tags in Web Pages

Since the output of the compiler was one single JS file, we needed to modify our web pages (e.g. JSPs) to refer to it (and not the multiple files). Obviously, we could manually modify the JSP files. But we needed something that would automatically replace them during the build. We decided to use maven-replacer-plugin.

<plugin>
  <groupId>com.google.code.maven-replacer-plugin</groupId>
  <artifactId>maven-replacer-plugin</artifactId>
  <version>1.4.1</version>
  <executions>
    <execution>
      <phase>prepare-package</phase>
      <goals>
        <goal>replace</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <ignoreMissingFile>true</ignoreMissingFile>
    <file>src/main/webapp/index.jsp</file>
    <outputFile>${project.build.directory}/replaced-webapp/index.jsp</outputFile>
    <regex>true</regex>
    <regexFlags>
      <regexFlag>MULTILINE</regexFlag>
      <regexFlag>DOTALL</regexFlag>
    </regexFlags>
    <replacements>
      <replacement>
        <token><!-- SCRIPTS.*END SCRIPTS --></token>
        <value><script src="<c:url value='/scripts/myapp.min.js' />" ></script></value>
      </replacement>
    </replacements>
  </configuration>
</plugin>

This effectively replaces the following:

<!-- SCRIPTS -->
<script src="/closure-library/closure/goog/base.js"></script>
<script src="/myapp/deps.js"></script>
<script src="/myapp/myapp.js"></script>
<!-- END SCRIPTS -->
<script>init();</script><!-- our JS code's entry point -->

with

<script src="<c:url value='/scripts/myapp.min.js' />"></script>
<script>init();</script><!-- our JS code's entry point -->

Note that the minified JS file is written to target/replaced-webapp/scripts. But this folder is never used to build the WAR. So, we need to modify our pom.xml to include this folder when building the WAR file.

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-war-plugin</artifactId>
 <configuration>
  <webResources>
   <resource>
    <directory>src/main/webapp</directory>
    <filtering>true</filtering>
   </resource>
   <resource>
    <directory>target/replaced-webapp</directory>
    <filtering>true</filtering>
    <includes>
     <include>**/*.jsp</include>
    </includes>
   </resource>
  </webResources>
 </configuration>
</plugin>

The above configuration effectively adds the target/replaced-webapp directory on to the WAR file. This adds a scripts folder with a minified JS file in it. It also contains the modified index.jsp file. When the web page references /scripts/myapp.min.js, it will find it.

Conclusion

It is great that we're able to debug in raw form. This provides an easier way to find which JS file/line is causing the error. We are also able to debug in minified form, and deploy the minified form. I hope this helps.