Installing couchdb on CentOS 5

Installing on CentOS 5 i386

(Note: COUCHDB-315 has an attached patch for the CouchDB README which adds instructions for RHEL 5.)

1. Install prerequisites. You will need EPEL for js and erlang (or build those from source).

yum install ncurses-devel openssl-devel icu libicu-devel js js-devel curl-devel erlang libtool gcc

You also require curl (7.19.7 worked for me).I had to build it locally though because of some weird libcomm_err.so missing dependency.

2. Install CouchDB

The configure line below is for 64-bit, adjust for your arch (or leave out --with-erlang if configure can find out for itself). You can use a release tarball instead of a checkout, in that case skip right to the ./confgure line.

svn checkout http://svn.apache.org/repos/asf/couchdb/trunk couchdb
cd couchdb
./bootstrap
./configure --with-erlang=/usr/lib/erlang/usr/include && make && make install

3. Edit config file to suit

vi /usr/local/etc/couchdb/local.ini

4. Create user, modify ownership and permissions

Create the couchdb user:

adduser -r --home /usr/local/var/lib/couchdb -M --shell /bin/bash --comment "CouchDB Administrator" couchdb

See the README for additional chown and chmod commands to run.

5. Launch! In console:

sudo -u couchdb couchdb

or as daemon:

sudo /usr/local/etc/rc.d/couchdb start

6. Run as daemon on start-up:

sudo ln -s /usr/local/etc/rc.d/couchdb /etc/init.d/couchdb
sudo chkconfig --add couchdb

JQuery AutoComplete - Lessons Learnt

I can actually go to bed tonight after resolving my bugbear of the past few days: jquery.autocomplete. I usually stay away from JavaScript development in my day job but the past few days has seen me trying to do some work that requires autocomplete functionality. Never knowingly backing away from a challenge, I rolled up my sleeves and got to work.

It wasn't very difficult finding resources to get me started on this very useful plugin to the jquery framework library. Where I met my challenge was the use case which I sought to implement. I was going to be populating the lookup elements dynamically and this data would be supplied by the server-side in JSON at that. JSON being a subset of JavaScript made sense and I figured this would work out of the box....untrue. Thanks to Firebug I found that the JSON data coming back from the server side wasn't understood.

After a few days of sulking, I found some succour in the form of a jquery autocomplete implementation which actually speaks JSON. I had to tweak it to do my bidding in the end of the day but this was a better match for my problem and I am grateful to the codeassembly guy(s).

A few points to note:
It would be nice if the JSON functionality is brought into the main jquery.autocomplete.
It would also be nice to have a user defined formatItem function like the main jquery.autocomplete that is called after the JSON data is returned(this is the part of the codeassembly implementation I had to tweak to do my own thing).

All in all an interesting experience. I have a few more things to do in JavaScript land and will let you know how I get on.

Source code in blogger posts.

UPDATE: I am pleased to tell you that I have just installed the Groovy syntaxhighlighter from the trunk of that project.

I am glad I finally found a solution to my problem. I think the guys at blogger need to write up something in their FAQs about having source code in blog posts. Most of the Google searches I undertook came out with nothing until I found this gem.

I am hoping to find some form of blogger plugin that does this in the future, like what the WordPress guys have done. I will also be hoping that the syntaxhighlighter guys will provide Groovy support soon ;)

More later.

Oracle XMLParser and Grails - Lessons learnt

A few days ago I was trying to integrate the work of a colleague into a light Grails application I am currently maintaining but experienced classpath hell with Oracle's XMLParser V2. A better description of the problem can be found in the JIRA for the Grails project here.

The steps prescribed didn't seem to work so I thought I'd do some digging again. I'll disappoint you by telling you that the JIRA issue remains unresolved and I was only able to come up with a work around. I looked into the script for RunWar and it would appear that for some reason, Grails defaults to a non-validating parser before kicking off Jetty.

The following lines in the RunWar.groovy script for Grails-1.0.3 is telling:

System.setProperty('org.mortbay.xml.XmlParser.NotValidating','true')

This single line of code ensures that you use a non-validating parser to start up Jetty and parse your application's web.xml. Maybe if there was another means for configuring your xml parsing for Jetty in Grails it would solve the problem.

I also tried other hacky things like replacing the SAXParserFactory as suggested here but that didn't work. In the meantime I have had to make do with refactoring my classes so that they don't exchange data of xmlType directly with the database. For now Strings/Clobs will suffice until I can find an unobtrusive way of starting Jetty from Grails that will condone Oracle's XmlParser on the classpath.

Your suggestions are very welcome.

Grails Testing Tip

I had always wondered how to run individual types of tests in Grails. In order words I wanted to be able to run unit tests only or integration tests only. I did some digging in the TestApp.groovy script that ships with Grails and found that all you needed to do was specify it as an option on the command line.

grails test-app -unit

or

grails test-app -integration

This works as far as I know with Grails 1.0.3 not sure of 1.0.4 and 1.1-betas but I assume they won't be decommissioning this feature in a while since it is important. 

Never really got individual tests working though, as I have been unable to find anywhere that says how to run an individual test class.

Pointers to this will be appreciated.

In the coming days, I'll say something about mocking in Groovy using the 'as' feature.