Luke + Lucene 3.4.0

Ugh. It seems like every time Lucene gets updated lately something breaks. They've been making lots of API changes lately and if it's not a backward compatibility issue within Lucene itself, it's something else that depends on Lucene.

After rebuilding our indexes with Lucene 3.4.0 we discovered that we could no longer open them with Luke. All we'd get was a super helpful "unknown format version -3". This happens even when the index is built on 3.4.0 with an older Version flag.

And we're not the only ones: Issue 46 and Issue 47.

So... Yay for open source. Here's a working version of Luke for Lucene 3.4.0: lukeall-3.4.0.jar.

Here's a patch for the Luke 3.3.0 branch if you wish to build it yourself: lucene-3.4.0-support.patch. You'll need to replace all the lucene 3.3.0 libraries with matching ones from lucene 3.4.0.

On a side note, after using github it feels so... archaic to be using something else. It would have been so much simpler for me to share this if I could've just forked it.

If Only I'd Known

Better late than never, I guess, but this sure would have helped when I was having problems with Java's security manager.

SecurityManager Woes

*grrr*

Charity and I decided to set up a website for our wedding that our guests could use to RSVP. It's all very basic stuff and I pretty much had it up and running without too much problems... Until I tried to deploy it.

That's when I ran right into Java's SecurityManager. The web hosting provider we're using runs Tomcat with security enabled, which makes sense, but it's something I've never had to deal with in the past.

I've been banging my head against the wall for a few days now and it looks like I finally have everything working. My three biggest problems were/are:

• Figuring out how to grant the webapp permission to read files that are inside a JAR (e.g. with a URI of "jar:file:/path/to/jar.jar!/file"). Nothing I do seems to work, and my current solution is to just expand the jar file.
• Apparently OGNL implements its own security checks if you're running with a SecurityManager, and you need to grant special OGNL-specific permissions if you want it to work. Since my provider is loath to grant new permissions, my solution was to just fool OGNL into thinking that there is no SecurityManager by implementing a ServletContextListener that calls OgnlRuntime.setSecurityManager(null).
• Figuring out how to use Log4J with the SMTPAppender. Haven't had time to dig through the source, so I decided not to use it instead.

These aren't solutions so much as dirty hacks to side step the SecurityManager. It just shouldn't be this hard...