The simplest way to get CouchDB running on Ubuntu is to install the package from the repository using aptitude. But I decided to install CouchDB from the sources in my home directory, so that I could play with the configuration without interfering with the CouchDB that comes with the OS and might be used by other software packages. Even the installation from the souces is pretty simple, just follow one of the examples given here: http://wiki.apache.org/couchdb/Installing_on_Ubuntu .

After the installation everything looked good at first: I could start CouchDB with couchdb -b and stop it with couchdb -d. I changed the http port in the local.ini file. After that futon came up on the new address: http://localhost:5994/_utils/index.html. The creation of a new database went well and I pushed a new application, generated with couchapp, into it. So far so good. But when I tried to call my first view, curl didn’t come back because CouchDB did not answer. A look into the logfiles showed the following error:

libmozjs.so: cannot open shared object file: No such file or directory

Fortunately google found me the answer to this problem. If I had only read the whole page about installing CouchDB on Ubuntu: http://wiki.apache.org/couchdb/Installing_on_Ubuntu. There the issue is analyzed and a fix is proposed. A xulrunner configuration file must be created. When done as recommended, and after a restart of CouchDB the logfile didn’t show no errors anymore, and the request of the view brought back the expected response. Everything’s fine. Once again: RTM – read the fucking manual.

Couchapp is a simple toolkit to generate an initial web application based on CouchDB and JavaScript / JQuery. It also helps to update documents in CouchDB, which otherwise, using curl or futon, is quite painful.

Couchapp can be integrated in Eclipse in a straightforward way, so that the editors and viewers can be used to work with the CouchDB documents, and an automatic update gets triggered when a document was changed. Here is my recipe.

Create a new Eclipse workspace.

Create a new generalEclipse project in that workspace.

Use a terminal, go to the project directory and create the initial couchapp content:

couchapp generate <design_document>

Create two new variables which will be used to define the project builders:

Goto Window > Preferences > Run/Debug > String Substitution

Create a variable couchapp with the full path to the couchapp executable as value

Create a variable couch_url with the url to your couchdb database

Configure the couchapp push builder for the project:

Goto Project > Properties > Builders

Create a new builder

Edit the launch configuration properties:

In the Main tab enter couchapp_push as the name of the builder, select the variable ${couchapp} for the location, as working directory select ${workspace_loc:/<project_name>}, as arguments enter -v push ${workspace_loc:/<project_name>/<design_document>} ${couchdb_url}

In the tab Build Options check the option During auto builds, also specify<project_name>/<design_document> as working set of relevant resources

Click OK

Create a new folder docs in the project to hold the json documwnts which will be uploaded to the CouchDB.

Configure the couchapp push_docs builder for the project:

Goto Project > Properties > Builders

Create a new builder

Edit the launch configuration properties:

In the Main tab enter couchapp_pushdocs as the name of the builder, select the variable ${couchapp} for the location, as working directory select ${workspace_loc:/<project_name>}, as arguments enter -v pushdocs ${workspace_loc:/<project_name>/docs} ${couchdb_url}

In the tab Build Options check the option During auto builds, also specify<project_name>/docsas working set of relevant resources

Click OK

Associate json files to the Java Script Editor:

Goto Window > Preferences > General > Editors > File Associations

Select *.json from the File types and add the Java Script Editor as default editor.

Now if you change any document under the <design-document> or the docs directory, they are loaded into the CouchDB with each save .

Today I created a first version of a mastermind game for android and loaded it up to GitHub. The program gave me the opportunity to experiment with views, events, handlers, menus and file resources on android. I tested it on a Samsung Galaxy S with Android 2.1.

My OS on the PC is Ubuntu Lucid Lynx. My phone is a Samsung Galaxy S, it runs Android 2.1.

Define an appropriate udev-rule. In my case I created a file /etc/udev/rules.d/51-android.rules with the following content: SUBSYSTEM==“usb“, SYSFS{idVendor}==“04e8 „, SYSFS{idProduct}==“681c“, MODE=“0666″, OWNER=“myuser“. The vendor and the product id can be found by calling lsub.

Java Server Faces are cool but they do not really support a REST-based, document centric approach (well, perhaps JSF 2.0 has got a bit better here). Jersey is a simple-to-use, but highly configurable implementation of RESTful WebServices (JSR 311). Jersey supports the routing of http-calls according to the URL and the http-headers, and allows to access the http-request and response. But it comes with absolutely no support for the rendering of a response. Thats where Velocity comes handy. Velocity is a template infrastructure, which allows you to use Java beans to fill data into html-pages or other types of documents. In the following I will show how I configured Velocity to be used in a web application and how I used the injection capabilty of Jersey to keep URL-handlers free from infrastructural coding of initializing Velocity.

I used a Tomcat web application server. In principal other application servers can be taken as well, but the way to make libraries available will be different. The Tomcat I used has the version 6.0.26.

Add the Jersey, JAX-WS and the Velocity libraries to the libs of Tomcat. Probably not all the libraries are required but they did not harm. Additionall, as I found out later, I needed libraries from the Velocity-Tools project, velocity-tools and velocity-tools-generic.

Create a new web-application (using Eclipse or NetBeans) for your Tomcat installation. Open the web.xml and enter and configure the Jersey servlet. Have a look on the configuration. You see the packages explicitely named, that Jersey are inspecting.

Now we create a resource class for Jersey. I took an example class from the Jersey Users Guide. When you built and deploy the web-app the resource should become available under the URL: http://localhost:8080/<context-root>/helloworld.

Next step is to bring Velocity into play. The first issue to solve is the location of the Velocity templates. By default Velocity loads its templates from a path in the file system. This is not quite what you would like to have if you have a packaged we application. Fortunately the Velocity Tools project provides a webapp loader, which allows you to package the templates with the web application.We already copied the velocity tool libraries in the lib directory of Tomcat. Now we must configure Velocity to use this loader. We tell Velocity that the webapp loader should be used as resource loader, set the relative path, where the templates will be located and hand over the servlet context. You find the code in the class VelocityResolver.

This brings us to the question where this initialization can be done. As you can see in the last line of code above, Velocity needs to know the servlet context. In principal the servlet context can be accessed in the Jersey resource classes. Jersey makes it available using injection. But is the resource class the right place for the initialization of an infrastructure component? I think not. First, the resource should focus solely on retrieving and rendering data, and should not be mixed up with infrastructure coding. And secondly, we probably want to reuse the Velocity engine across many resource classes.

Fortunately Jersey allows for own InjectableProviders. These providers can be used to extend the injections Velocity provides to resources. This is a very powerful mechanism. So, I wrote a class called „VelocityResolver„, which does nothing more then providing an „Injectable“, which in turn initializes and serves the Velocity engine.

Please note in the code above that the class is annotated as Provider. This is how Jersey recognizes that the class is an Injectable Provider which will be used for injections. Also note the usage of the annotation Context which gives us access to the servlet context which is needed for the initialization of the Velocity engine. Having this in place the usage of Velocity in resource classes is rather simple. The class HelloWorldResource provides an example.

The VelocityEngine is injected using again the annotation @Context. Later a new VelocityContext is created and populated with sample variables. These can be accessed from within the Velocity templates. As you can see in the configuration of the webapp loader above the templates are searched in the folder WEB-INF/mytemplates. If you place there a simple script named mytemplate.vm with a content like Hello $name, the call to the URL http://localhost:8080/<context-root>/helloworld yields „Hello Velocity“ as result.

That’s the setup of Jersey with Velocity. You can use this couple for the provisioning of documents of any format according to the REST principals from within any web application server. I’m going to use this framework for the rendering of data that I store in a CouchDB. CouchDB fits very well to the REST apporach, as it stores documents instead of records within a table. It is extremely fast and supports replication within the cloud. Its rendering capabilities are rather poor, and thats the point where Velocity wins the game. Have fun!

It’s good programming praxis to separate persistency from application logic from presentation logic. In my application I use EMF to create the data model and Teneo to link the model to either Hibernate or JDO. The EMF model, Teneo, database libraries, Hibernate and the libs required by Hibernate should all get their own OSGi-bundle / Eclipse-plugin. This helps to track and control dependencies between these pieces of separately developed software.

First of all install the plugins for EMF, Teneo and Derby from the Ganymede update site (or library plugins for any other database supported by Hibernate). A Hibernate plugin is available too. But even if I tried everything a whole saturday afternoon long, I always run on this error: org.hibernate.MappingException: Could not determine type for: org.eclipse.emf.teneo.hibernate.mapping.econtainer.EContainerUserType I know this is related to the „Buddy nightmare“, and I followed the hints in the net, that suggest to use the Buddy-Registry in the plugins using hibernate. Nothing helped. So I decided to to create the required plugins myself. This gives me more control on the usage of libraries (logging) anyway.

So these are the plugins I created:

antlr: wraps the antlr.jar from the hibernate distribution. The manifest.mf must have the line: Eclipse-BuddyPolicy: dependent

commons-collections: wraps the commons-collections.jar from the hibernate distro.

dom4j: again a wrapper around the respective jar in the hibernate distro

jta: the same

sl4j: this time I took sl4j-api.jar and sl4j-jcl from the sl4j-package.The manifest declares a dependency to the commons-loggin plugin (available on the Ganymede update site, if not already installed): Require-Bundle: org.apache.commons.logging

hibernate: contains only the hibernate3.jar. In the manifest the dependency to the 5 before mentioned plugins must be declared. And in addition Buddy-classloaders from dependent plugins must get access to the hibernate classes by Eclipse-BuddyPolicy: dependent

This does the job. My own code I keep in separate plugins for the EMF model classes (actually I preferred to use a simple OSGI bundle for this) and a second one with the application code. The application plugin must refer to emf.ecore, emf.teneo.hibernate, derby.core, the model bundle and our hibernate bundle as defined above. That’s it! In the application instances of the EMF model classes are created, modified and used in queries, and finally stored in a database. Cool stuff!