The Servlet spec provides a mechanism for Servlet containers to manage sessions by rewriting the outgoing url's on a page to include a session id. This is implemented as a path parameter, as opposed to a query parameter (denoted by ;jsessiond rather than ?jsessionid). According some interpretations of the http spec 1.0, this should be ok. Different jsessionids should not make otherwise identical URIs different. But tell that to the web agents out there processing our URIs! Feedburner and bloglines both treat the jsessionid as a core part of the url, the pages on our website looked different (in terms of identity) to them every time they arrived. Google's cache reveals plenty of our URIs with sessionids. Realising this we hurriedly removed jsessionid generation from our foreverprecio.us wedding websites.

Removing jsessionids

There are a number of ways to go about this (removing jsessionids). If you are using a servlet engine other than Tomcat, you may be lucky enough to be able to switch them off globabally with a small config change. No such luck for us. We were left with a stark choice, either write a new url generation tag lib, and rewrite all our views. Or implement a filter that hijacks the incoming request and proxies it, overriding the four encodeURI / encodeRedirectURI methods (two are deprecated). Fortunately for us (not that the second option is that bad), we're using Groovy. A little piece of metaclass magic and we were able to plug in our own implementation across the entire app, without so much having to modify an existing line of code! Hurrah, for Groovy then. That still left us with a dilemma.

What to do about the existing indexed links with jsessionid in them?

The best solution to this problem, would be to intercept the call to foreverprecio.us, before it gets to your wedding website, check if jsessionid is present, remove it if it is. Then we'd redirect the requestor back to the same page, sans jsessionid - with a servlet response code of 301 (permanently moved). That way, when Google attempts to see if our pages have updated, Googlebot would be redirected to the correct form of the link. The servlet spec appears to get in the way of itself again here (or maybe it's just the Tomcat implementation). Tomcat strips out the jsessionid on both request.getRequestURI() and request.getRequestURL(). The most obvious solution doesn't work. Fortunately, this time, the cleverness of the spec is well justified and the test for jsessionid's on the incoming URI is nicely abstracted behind request.isRequestedSessionIdFromURL(). This only takes effect when cookies are turned off - so unless there are some hybrid web bots out there, our problem should be solved.

A frustrating, but easily solved gotcha we had recently involved Read Timeouts when uploading very large files to our Tomcat server with Commons FileUpload 1.2.1. The stack trace from the error is below..

org.apache.commons.fileupload.FileUploadException: Read timed out
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:381)
at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)

The solution is relatively straightforward, once you know it.

set disableUploadTimeout in your server.xml in tomcat to false.

Danno Ferrin gave a sneak peak of some of the upcoming features in Groovy 1.6. They've added AST transformations, which seem to add macro like functionality to the Groovy language. Danno demonstrates a transformation that leverages an @Bindable annotation to earmark code to be expanded into a bindable Java Bean property making full use of property change listener. He hints of even greater things (in our opinion!) when he mentioned the @Mixin transformation..

The performance improvements also seem to be spectacular.

Our experiences with Groovy, a dynamic language a bit like Ruby but only with a Java syntax that runs on the JVM have been largely very postive. One of the areas where we were absolutely blown away is XML processing. XMLSlurper and GPath combined are the most powerful technologies for consuming XML we've used. They work by dynamically creating an object graph based on the underlying XML structure. You can then make property access requests on the objects which are handled in roughly the same manner as an XML XPath query by the underlying engine. This produces incredibly concise and readable code, with no external dependancies, and makes using external REST webservices (such as Google's maps API for GeoCoding) a real breeze to use..

Grails, the groovy web framework has some really nice features - we feel GORM in particular leads to more rapid prototyping and cleaner code. However, at least as far as eclipse goes, raw Java is still much better supported than Groovy in terms of IDEs and refactoring (IDEA Groovy support is more advanced - but we use Eclipse here at foreverprecio.us). So we found ourselves in the position of wanting to use Java for a large portion of our code base, but also wanting to take advantage of the dynamic language capabilities of Groovy and the fantastic features of Grails.

Step 1.
Custom Grails app.

We started with a plain vanilla Grails app, but rather than launch the application via 'grails run-app' or 'grails deploy' we created our own GrailsApplication instance and imported the prcompiled classes from Grails. This provided us with a number of advantages. Groovy classes compile to plain old Java byte code, which means that precompiled Grails classes can be very easily referenced from Standard Java classes. The only thing that's missing when you're in standard Java is the Groovy meta-class magic. The solution to that problem is to define a Groovy class that makes any dynamic calls you need..

Step 2.
A Groovy Access Object (GAO - with apologies to the creators of the Data Access Object pattern)

Rather than use the clunky invokeMethod method call available on all Groovy Objects we used a layer of indirection and defined a set of interfaces that defined the dynamic groovy methods we used within our Java application. We implemented these interfaces in a series of Groovy classes that made the calls to the appropriate dynamic Groovy methods. We used this technique to access the dynamic methods on GORM, to take advantage of the Groovy Ant and XML Builders, to make use of the excellent Groovy XMLSlurper and GPath libraries for processing XML responses from remote services.

The development process
We started off rapidly prototyping most code in Groovy and Grails, then piece by piece ported the less dynamic portions to IDE refactorable Java. In a way the original Groovy and Grails code not only helped us get up and running quickly but also served as spec for the application. Grails code and Java code are malleable in different ways - Eclipse provides excellent refactorability for Java, but not yet for Groovy. However in a standard app, this is sometimes mitigated by the reams of XML (or even annotations) needed to configure the application. In Grails convention over configuration and the dynamic nature of Groovy provided malleability at a higher level than the refactorability of Java and served really well for rapid prototyping. Our Java / Groovy bridge - the Groovy Access Object and the syntactic similarities between the languages meant that we were able to reuse much when converting parts from Groovy to Java.

Howdy!

This is where we'll post about some of the technical aspects of creating foreverprecio.us. foreverprecio.us is a Java / Groovy / Grails / Hibernate / Spring application for generating customisable websites. If you take a look around the foreverprecio.us eco-system, you'll see we're focusing on wedding websites at the moment (with lots of new features planned). Do feel free to try out the service, it's free - drop us a line with any feedback.