[DrunkAndRetired.com Podcast] Episode 62 – Mongrel, Servlet Problems, Packaging, Tron

In this episode, we talk about Mongrel, Charles & Co.’s problem with JEE servlets and headers, packaging software (or the lack thereof), and memories of Tron.

(This episode edited by Coté.)

Tags: , , , , .

Join the Conversation


  1. Charles seemed pretty confused in this episode. I think his first instinct for packaging web resources was the right one – use a servlet that can serve static assets from the classpath.

    Instead of copying and pasting the Tomcat default servlet like an insane person, check out Tapestry’s asset service which does what you want and — while I think you’ll have to re-implement some of Tapestry’s core service logic to produce URLs — it’s probably more or less “butt pluggable” into your framework.

    By the way, how can a JavaScript masochist like Charles be so afraid of a few HTTP headers?

  2. I probably became a javascript masochist because I was overly optimistic about how difficult it can be to resolve nasty things like browser inconsistencies. A year or so later, I have lots of valueable knowledge, but I still bear the fresh thrash marks of the experience on my back.

    I know all to well how easily a simple abstraction can continue to grind and grind and never fully resolve itself because little issues keep coming up that force you to change your base of assumptions, and then finally, you have to stop and do a full and exhaustive research of the problem so that you understand it so well it makes you physically ill.

    In this case, I’d like to afford not understanding the problem fully and delegate to a mature code base that does.

    Or put another way: Just because I like some nice boiling wax on my nipples every now and then, doesn’t mean I like to be anally flogged.

    So about this tapestry… do you know of a good treatment of what problems asset management solves, and how you can use it in some different contexts?

  3. arrrrgh! I thought I was helping out by pointing you to the Tapestry asset service. Now that I’ve gone half-blind poring over the source code to tell you what parts might be interesting, it turns out that this resource serving stuff is baked in pretty deeply. The asset service in Tapestry leverages HiveMind’s Resource class (specifically ClasspathResource) and utilities to create and respond to URI’s that represent static resources embedded in a jar (or wherever in the classpath). This is probably more or less what you already did in Freestyle the first time around.

    However, I did notice a couple of things that relate to the header issues and your general desire to avoid anal self-flagellation. First, there’s really not a lot of header magic going on. They obviously have to call ServletResponse.setMimeType() to set the content type (they encapsulate mime types in ContentType class but that only seems to exist for more complex cases). Other than that it looks they only set the Last-Modified and Expires headers. Now, you might think this is where it gets complex, right? Wrong! (that comes later)

    They don’t really have to worry about cache expiration policy because of another problem that you have to deal with when you open up your entire classpath to the network. Every request for a classpath resource contains a digest (MD5 in this case) to prevent random browsing for class files, etc. The digest is a file checksum so it (and thus the URI you have to generate to get to it) changes whenever the file is updated. At the end of the day this means that cache headers are set like: Last-Modified = now and Expires = whatever, a year from now.

    You can see most of that logic in the AssetService class and branch off into the digest stuff from there. If you’re interested, check out the 4.0 (stable) branch of Tapestry and the 1.1.1 branch of HiveMind. They already include Eclipse .settings files so you just have to drop in the missing jars and browse away.

    So you’re probably thinking this sounds like a major pain in the ass, and you might be right. But there are a couple of justifications for going down this road. While it’s kind of a subtle point, I think it’s way cleaner to be able to drop a framework jar file into your classpath instead of having to copy stuff into directories. The much bigger payoff, at least for Tapestry, is that custom (or any 3rd party) component libraries can be packaged into jars that include all the static resources. Now just sit back and think about *that* for a while…

    So here’s the bombshell. You could use HiveMind as your framework’s IoC container (assuming you’re not already using Spring or whatever). It would give you the building blocks for this classpath resource stuff besides all the usual good stuff you get with DI, etc. Again, there’s a bigger payoff that’s illustrated pretty well in Tapestry: Tapestry is more or less just a collection of HiveMind services and configuration points which means users can extend and override pieces of the framework without having to maintain a forked version. You don’t tend to use this every day but when you need it, it’s powerful stuff (some might say “ten times as pow’rful”).

    Okay, I think I’ve gone way too far now and told you to completely rewrite your framework. Sorry. Hope some of this did more good than harm.

Leave a comment

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.