Alan's Ramblings - j2ee tag

Producing CSS with self-caching JSPs

Mon, 15 Oct 2007 06:29:59 GMT

One thing that's always bugged me about CSS is that it doesn't have any sort of macro facility, so if you want to use (say) a HTML colour code in several places you need to hard-code it into all of them, which is a right pain. As the app I'm working on is written using JSPs, the obvious thing to do was to output the stylesheet from a JSP, and then use EL to define variables and then insert them in the appropriate places, e.g.:

<c:set var="background" value="#292B4F"/>

body {
    background-color:   ${background};
}

That works just fine, but each time the stylesheet is referenced it is regenerated, and as the content is completely static that was obviously a bit inefficient. Some googling found a number of ways to cache the output of JSPs, from the simple to the extremely complex, e.g. using a servlet filter to intercept requests and cache output. I wanted the simplest possible mechanism that would do the job, with no external dependencies.

A fairly obvious technique is to cache the output in the servlet's application scope the first time it is generated, then on subsequent requests you just send back the cached output rather than regenerating the content. The basic outline looks like this:

<c:if test="${empty cachedStylesheet}">
<c:set var="cachedStylesheet" scope="application">

    <!%-- Cached content goes here -->

</c:set>
${cachedStylesheet}

That works fine, but if you watch the conversation between the browser and the servlet, the cached content is still refetched each time this is referenced. This is because JSP output is usually dynamic, so the servlet container sets things up so that the client browser doesn't cache the content obtained from JSPs. To fix this we need to manually add the appropriate headers to the HTTP response we send back to the client to that it knows to cache the content, and we also need to respond to requests from the browser asking if the content has changed. The relevant HTTP headers are If-Modified-Since, Last-Modified and Expires, see the HTTP specification for more details. This requires a little bit of additional inline Java code in the JSP, so the final version looks like this:

<%@page contentType="text/css; charset=UTF-8" pageEncoding="UTF-8" session="false"%>
<%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
<c:if test="${empty cachedStylesheet}">
<c:set var="cachedStylesheet" scope="application">

<%-- Cached content goes here -->

</c:set>
<c:set var="cachedStylesheetDate"
  value="<%= new Long(new java.util.Date().getTime()) %>"
  scope="application"/>
</c:if>
<%
  long date = (Long) application.getAttribute("cachedStylesheetDate");
  long mod = request.getDateHeader("If-Modified-Since");
  if (mod > date) {
      response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
      return;
  }
  response.setDateHeader("Last-Modified", date);
  response.setDateHeader("Expires", new java.util.Date().getTime() + 86400000);
%>
${cachedStylesheet}

Here's how it works: We cache the content the first time the JSP is accessed as before, but we also set a session scope variable cachedStylesheetDate that records the time when the output was generated. Then on each request we fetch the value of any If-Modified-Since header specified by the browser. If the content was generated before the date, the browser already has an up-to-date version of the content, so we just send back a 304 response (Not Modified) to indicate that fact. Otherwise we set the Last-Modified header to the date when the content was generated, and then set the Expires header to tell the browser to check again in (60 * 60 * 24) * 1000 = 86400000 milliseconds, i.e. in 24 hours, and then we send the cached output. That way, after the initial fetch, the browser will only check once a day to see if the content has been updated - that figure can of course be adjusted as necessary.

XML-based J2EE frameworks considered harmful

Thu, 03 May 2007 03:44:05 GMT

Are you using one of the XML-based web frameworks such as Spring, WebWork or Struts? Then you've been duped. Conned. Flimflammed. Bamboozled. Hornswoggled. (Yes, this is a rant ;-) Here's why:

XML doesn't get executed, it gets read
Unlike Java source code, XML just gets read once rather than being executed. That means that it can't respond dynamically to changes in the application environment. You are stuck with whatever is configured at the time the XML is read - usually this is at the very beginning of your applications startup processing.
XML doesn't have constants or variables
Want to use the same configuration value across multiple XML files? Tough, you can't. The only way you can get even remotely near to this is to use vile preprocessing hacks.
XML doesn't have flow-of-control
Want to put some conditional logic or loops in your XML? Sorry, there's no standard way of doing this. Sure, some frameworks attempt to provide this using their own custom XML entities, but every one of them does it differently.
XML files aren't programs
All that good stuff you were taught in your CS classes about type safety, information hiding, coupling, cohesion and so forth? Forget it, thanks to XML you are now back in the 1960's.
Welcome to action at a distance
See that attribute you set in your XML? Well, that probably has to map onto a method call on an object. Which method and which object? Prepare to spend hours pouring over the source of your framework to find out.
You can't garbage-collect XML
See all that XML goop you've lovingly crafted? Well, say goodbye to large chunks of the memory on your machine. The application frameworks usually like instantiate all of the objects you might ever need at startup, because they have no way of knowing if they are ever used. And the frameworks make sure they are nailed into place, so forget about them ever being GC'd if they aren't actually used.
You'd better understand all about classloader leaks
All this XML you've used requires all sorts of introspective sleight of hand by your application framework. And that involves getting it's grubby little hands into the Java runtime support mechanisms, and holding references to bits of its innards such as classloaders. And the next time you redeploy your application, all those references probably aren't going to be cleaned up properly, so say goodbye to lots of leaked memory. And if you redeploy just a few times more, expect your application to fall over completely as it runs out of memory.
You've defeated type checking
Most everything in XML ends up being a text string. That includes class names, method names and method parameters. Got one of them wrong? Oops, more mysterious exceptions will be heading your way at some random point in the future.
Debuggers don't debug XML
That cool debugger your IDE has? Don't bother. It doesn't work on XML files. The important bits of your application logic are now buried in some introspective labyrinth buried deep inside a library that you probably don't understand fully. Welcome instead to the world of cryptic stack traces and sleepless nights.
You can't run FindBugs or PMD on XML
Those nice tools that check your source code for programming errors? Guess what? They don't work on XML. You've just thrown away another tool in your armoury.
You've moved bug detection to run-time
All that wonderful checking that the Java compiler does to make sure your application is correct? Gone, javac doesn't do XML. You aren't going to know if your application is even minimally correct until you try running it - and there's a fair chance that it will run for some considerable time before you find out that you've made some simple programming error or other.
You still have to rebuild your application if you modify it
XML proponents tell us that one of the major benefits of XML for configuring J2EE frameworks is that you can reconfigure your application without changing the source. Really? How? Does anyone ever change the XML files in a deployed WAR file? Of course not, that would be insane. Ah, you have to edit the source XML files then rebuild and redeploy your WAR file - Oh dear, you still would have had to do that even if you didn't use XML at all.
You've just doubled your troubles
Think that Java is a big, complicated language? You 'aint seen nothing yet. Faced with a big complex application and want to figure out who is calling a method? Well, don't expect your IDE to be of any help, it doesn't understand your application framework's XML files. Trying to trace through the code and figure out what happens? Forget it. You'll go insane hopping between Java and XML source and trying to figure out which bit of opaque magic provided by your application framework is doing what, where and when.

I'm fully aware that the list above is crammed with generalisations, and that there are various hacks and workarounds for some of the issues. However the overall point I'm making is that XML isn't a programming language, yet virtually all of the major J2EE frameworks use it as if it is. The pervasive use of XML for tasks for which it is not suited has effectively discarded the last 30 years of software engineering advances. This is a huge mistake, and I expect that in 5 years time people will look back at the current XML mania and say "What the hell were we thinking of?"