Symphonious

I was silly enough to open my work email this morning, only to discover that the Apple Java-Dev list had broken out into the age old Java on OS X argument. First up here's what people have reported1:

• Java 6 is not included with Leopard.
• The previous Java 6 DP which was pulled from ADC a while back does not run on Leopard.
• Upgrading to Leopard from a system with the Java 6 DP installed can cause some frustrating issues with switching Java versions.
• Apparently Java 5 is much faster on Leopard.
• Java 5 looks different with quite a few tweaks to the Aqua L&F.
• Some fonts don't look right in Java 5 on Leopard because it uses the Sun 2D graphics pipeline instead of the Quartz pipeline. The Sun 2D pipeline doesn't support sub-pixel antialiasing. You can override the default and there's a few other conditions that trigger the Quartz pipeline to be used by default.
• Java 5 supports 64bit on Intel Core 2s (but not PPC). There seemed to be some problem with it when using the Java tools in /usr/bin though - can't say I followed that discussion too carefully.
• Lots of documentation is coming, but not much is available yet.

Pretty sure that's the Java on Leopard wrap up, the other 150 emails to the list were just the usual gnashing of teeth about Apple abandoning Java and how Apple will lose so much business if they don't get Java 6 out yesterday etc etc etc. Of course, Apple's doing better than it ever has before and JavaOne was full of people using Macs - without Java 6 - so it would seem it's all just talk and insignificant numbers of people are actually leaving OS X. As a fresh twist, this time round people are talking of porting OpenJDK to OS X themselves and finally freeing themselves from the evil clutches of Apple! Apparently no one has told them that Java 6 isn't available from OpenJDK either - it will become Java 7 and is quite some way from that yet. I think it's a safe bet that Apple will have Java 6 out long before even a reasonable uncertified port of OpenJDK is available for OS X.

Oh well, time to put my flame proof underwear on - nothing gets people going like Java on OS X posts, for those who subscribe to the comments feed, this one's likely to drown out the Back to the 80s nonsense for a fair while….

I was so close to having everything working… EC2, S3, automatically pulling down the latest build and deploying it, Tomcat 5.5 with the native APR libraries, SSL support and using iptables to forward ports 80 and 443 directly over to Tomcat. Everything ready to go. Except Tomcat isn't so keen on starting.

It usually starts, though it can take over half an hour to do so and on a couple of occasions it's just flat out sat there and done nothing for multiple hours on end. At startup it outputs the log message:

Aug 20, 2007 3:08:56 PM org.apache.coyote.http11.Http11AprProtocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080

and then nothing until all of a sudden 5-45 minutes later it suddenly comes back to life, finishes starting up and works perfectly. There's no CPU usage while it's out, it's just sitting there waiting for something to happen (network lookup??).

Sigh. I'm sure the world is out to get me….

I've struggled with Lucene before and failed to configure it properly resulting in absolutely horrendous search results so a recent need to implement search functionality wasn't something I particularly wanted to take on. In fact, I was prepared to do almost anything to avoid delving back into Lucene filters and parsers and tokenizers and "stuff". This tends to be problematic given that Lucene is the dominate search library - so popular in fact that it's been ported to other languages.

So I took a look at Solr - a web services front end to Lucene. Exchanging Lucene APIs for HTTP requests seems like a good tradeoff for me and Solr comes with a pretty decent configuration for Lucene right out of the box.

As it turns out, Solr's default configuration isn't just pretty decent, it's also surprisingly well commented. Combined with some reasonable documentation it was pretty straight forward to get Solr to do what I want and provide good search results without much effort. With a bit more effort I should be able to get search highlighting working as well which takes search results to a whole new level.

Two things really made me appreciate the choice to use Solr:

1. It has a DirectSolrConnection class that removes the need for actual HTTP requests. As a bonus, it still uses the HTTP URLs and returns the same responses so if you later need to split Solr out onto it's own server you just have to implement the HTTP stuff and not change the result of your processing.
2. It caches searches automatically.

Caching is just so cool to see in action. Using the built in search from Jackrabbit (which also uses Lucene) it was too slow to include the output of a search with each page (think, related links etc). With Solr's caching this isn't a problem anymore.

There's still a bunch of learning to do so that I can get really optimal results - getting searches to work over multiple fields properly so that I can weight the results based on which field matched would be good and I can see Solr can do it - just not quite sure how to make it all happen. Still, the current search is way better than anything I've managed to do before. Thanks to the Solr and Lucene teams!

That permanent generation had better provide some pretty damn amazing optimizations or I'm going to add it's inventor to my list of people to track down and torture at next JavaOne. It turns out you can only reload a Tomcat webapp so many times before the PermGen space fills up and everything dies. That's annoying enough in development but it means I can't upload a new WAR file to our test server regularly without also bouncing Tomcat. Right now our continuous integration server (Bob the Builder) is doing just that after every commit so the server isn't staying up all that long.

Mock objects for unit tests will also run afoul of PermGen space and apparently something in Eclipse does too because every so often it dies on me too. Sigh.

It took forever, but I've finally how to stop Tomcat adding a Pragma: no-cache header to any resources in a secure context. You need to set disableProxyCaching to false, so if you're using basic authentication you need a valve like:

<Valve className="org.apache.catalina.authenticator.BasicAuthenticator"  disableProxyCaching="false" />

That needs to go within the <context> definition for your web-app. So, within the META-INF (some sources say within WEB-INF?) create a context.xml file like:

<Context><Valve className="org.apache.catalina.authenticator.BasicAuthenticator"  disableProxyCaching="false" /></Context>

I found deploying as a WAR didn't work (it seemed to ignore the context.xml), but deploying the exploded files did work and that's fine by me.

Combine that with the awesome cache control filter that Danny posted in the comments and you have a very nice, easily configurable caching mechanism that doesn't cause browsers to download the CSS and JavaScript resources for every single page.

Dear lazyweb,

Does anyone have best practices for implementing correct, useful caching for a webapp running in Tomcat? I'm using container managed security and it's happily adding Pragma: No-cache to everything, including the static CSS file which is pretty brain dead. It looks like I can add a custom filter to get rid of that header and then manage caching myself, but it seems like something that everyone should have solved before so I thought I'd ask….

Thanks,

Lazy me.