Serving content with Solr's Jetty instance.

When prototyping with Solr 1.4.x, I've found it useful to serve webpages, javascript and images using the Jetty server used by Solr's example instance. Doing so is straightforward:

Create a directory named contexts in the Solr examples directory which contains the etc and start.jar files. Create a context definition file inside this directory. It can be named anything, I commonly call it root-context.xml

The file contains the following:

<Configure class="org.mortbay.jetty.webapp.WebAppContext">
  <Set name="contextPath">/</Set>
  <Set name="resourceBase"><SystemProperty name="jetty.home" default="."/>/contexts/root</Set>
  <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>
</Configure>

In the contexts directory, create a directory named root and place your content there. Voila -- once you launch the solr instance with java -jar start.jar, everything placed in the root directory is available under http://yourhostname:8983, while solr is availble at http://yourhostname:8983/solr

A Useful Hint to Young Engineers

When I visited Thomas Edison's lab in Orange, NJ last winter, I spotted a clipping in one of the displays:

"A Useful Hint to Young Engineers -- 'The man for whom every employer of men is searching, everywhere and always is the man who will accept the responsibility for the work he has to do -- who will not lean at every point upon his superior for additional instructions, advice or encouragement.

There is no more valuable subordinate than the man to whom you can give a piece of work and then forget about it, in the confident expectation that the next time it is brought to your attention it will come in the form of a report that the thing has been done. When this master quality is joined to the executive power, loyalty and common sense, the result is a man whom you can trust. On the other hand, there is no greater nuisance to a man heavily burdened with the direction of affairs than the weak-backed assistant who is continually trying to get his chief to do his work for him, on the feeble idea that he thought the chief would like to decide this or [that]."

Gender bias aside, a useful hint indeed.

Ubuntu 9.10 and sticky java dialog boxes.

I'm running Ubuntu 9.10 in my laptop and have been suffering from an unusual problem. The buttons on dialog boxes created by the eclipse ide 'stick'. When I click on any button in a dialog, it gets stuck in the down position and never activates. The only solution is to tab over to the button if possible and activate it with the return key. Very irritating.

I finally tracked down the fix today. The problem is caused by something related to the way in which GDK renders its windows in the latest version. The solution is to set the environment variable GDK_NATIVE_WINDOWS=1 prior to launching eclipse. Apparently this is also a problem on newer versions of Fedora as well. Indeed it is probably an issue with anything running gdk 2.18 or newer, where the switch to 'client side windows' was made.

I've fixed this by renaming eclipse to eclipse.bin and placing the following script named eclipse in the same directory:

#!/bin/bash
BASE=$(dirname $0)
export GDK_NATIVE_WINDOWS=1
exec $BASE/eclipse.bin

don't forget to chmod +x it so that it is executable. You'll also have to rename eclipse.ini to eclipse.bin.ini -- eclipse finds its ini based on the binary name.

sheesh.

For an explanation of what GDK_NATIVE_WINDOWS is all about, check out the post "What GDK_NATIVE_WINDOWS=1" means over on Dax's blog.

GUID vs. Auto-Increment Primary Keys.

This all started off from reading yet another wonderful post over at Better Explained, which is currently my favorite blog of the moment. My Google reader starred items list overflows with entries to-read from this blog. I wanted to brush up on the semantics of GUIDs/UUIDs because I'm currently implementing RDF output for one of our products from work and keeping the object URIs unique and consistent is a good thing. I'm using a simple MD5 hash for that.

The interesting aspect that cem out of this is the discussion of using GUIDs as database primary keys. We'd tried that a couple years ago but abandoned the implementation for a number of reasons.

I'll come back and finish this post some day, but I really just want to capture a bunch of links in one place. It would be cool if those social bookmarking services would allow you to cluster a bunch of links together into a single posting. At any rate, I'll use a blog for this instead and see how it works.

• Coding Horror: Primary Keys: IDs versus GUIDs
• Brian "Krow" Aker's Idle Thoughts - Myths, GUID vs Autoincrement: Excellent discussion here, need to go back and find out if he ever did benchmarks for secondary keys.
• MySQL Performance Blog: To UUID or not to UUID?

The general sentiment here is is that using UUID's instead of auto-incrementing ints decentralizes id assignment, enabling scale and avoiding having to re-key data when it's merged. The tradeoffs related to space are worth it and the performance impact is likely to be minimal

Earthquake in NJ

Growing up in NJ, earthquakes were unheard of. Back when I was a kid in Bergen County I felt one. It was a Saturday morning, and I was at a friend's house after sleeping there the night before. It lasted long enough for us to realize we didn't know what was going on and to run outside of the house and witness everything moving.

I was thinking about the quake lately and finally managed to track down the event. According to the Lamont-Doherty Earth Observatory of Columbia University, the earthquake occured about 6:04am on October 19th, 1985 and was measured at 4.0 on the Richter scale. Its epicenter was in Ardsley, NY. (40.98N, 73.83W), referred to as the "Ardsley Quake".

Color Grep

I was grep-ing through some RSS feeds today when it struck me that there's got to be a way to highlight the text that grep matches much like the matching text in vi or less is when searching. Well, it turns out there is.

Just like ls, grep supports the --color option. This means with --color=auto, grep will colorize the portion of the line that matches when it sends output to a terminal, but avoid adding the color escape sequences when you're sending the output to a file or pipe. Unlike ls, which relies on some setup to get it displaying colors properly (see: /etc/profile.d/colorls.sh if you don't believe me), setting up grep to colorize matches by default is as easy as defining the environment variable GREP_OPTIONS='--color=auto' in either your local or system-wide shell startup script.

A typical use-case for me is to pipe the output of grep output to less. If you do this too, keep in mind that the right invocation to get colorized output in less is:

grep --color=always foo bar.txt | less -R

The -R argument to less allows it to pass ANSI color codes unchanged, and --color=always forces grep to colorize its output even though it is going to a pipe.

If you're interested in customizing the color of the highlighted matches, you can set the GREP_COLOR environment variable. A good source of example colors is available in the adequately-commented /etc/DIR_COLORS that's used for setting up color ls. I like GREP_COLOR='43;30;01' which gives you a nice black on yellow highlight for the matched text.

del.icio.us and xhtml parsing in java.

To find the information that del.icio.us knows about any url use http://del.icio.us/url/(url-md5sum). The md5 is a standard 32-character md5 string with downcased hex digits. URLs should be properly slash terminated prior to generating the md5, for example, http://www.slashdot.org/ but not http://www.slashdot.org. In some cases people have tagged the urls without the trailing slash.

The html (xhtml really) served by del.icio.us is really clean, so occured to me that the various entries I'm interested in extracting could be retrieved using the same strategy used to identify microformats. That also started me thinking about using xpath expressions to identify and exract the right xhtml nodes.

I didn't have much luck. xhtml is an interesting beast. When following the java Xpath api usage examples, the parser complains about the contents of script tags containing illegal characters, and del.icio.us doesn't wrap their script tag contents contents in a CDATA, which doesn't seem to be required or common practice anyways.

It turns out that a combination of jTidy and dom4j seems to work reasonably well.

InputStream in = new FileInputStream("target/out.xhtml");

Tidy tidy = new Tidy();
tidy.setShowWarnings(false);
tidy.setQuiet(true);
tidy.setXHTML(true);
tidy.setXmlOut(true);
org.w3c.dom.Document domDocument = tidy.parseDOM(in, null);

DOMReader domReader = new DOMReader();
Document doc = domReader.read(domDocument);

List list = doc.selectNodes("//div");

for (int i=0; i < list.size(); i++) {
System.out.println(list.get(i).toString());
}