This is a follow up of my previous post on Lift and REST discussing the aspects of URI matching and content negotiation. Lift supports Accept header of HTTP by responding back with a representation in accordance with the media type provided in the header. However, it currently doesn't support quality factor (q parameter) of the Accept header, out of the box. Here  I will attempt to provide an approach to provide that support and along the way let's explore another compelling feature of the Lift's REST support.

HTTP Accept Header

Check RFC 2616 for detailed explanation on Accept and other HTTP headers. Let's go over this based on an example: If a client sends an Accept header something like the following --

Accept: application/xml; q=0.8, application/json

is interpreted as: I prefer JSON representation but if you don't have it XML is my second choice.

Quality factor or q parameter is the one that's used to specify the preference. q is a decimal ranging from 0.0 to 1.0 and is delimited with a semi-colon (;) following the media mime type. If no q parameter is specified it defaults to value of 1.0, indicating first among the options provided.

Approach

Before going into the approach for supporting the q parameter (for your Lift-based application) let's get into one of the things that you definitely want to see in a web framework: decouple business logic from the representation. Lift doesn't disappoint you in this area. In my case I was using the same business logic, authorizing the user and making the database lookups, returning the appropriate representation independent of the business logic.

serveJx in RestHelper is there precisely for that purpose. Following code provides the URI matching rule (matches /api/user/{user_id} for GET requests) and returns an object that's of trait Convertable. Also, define an implicit def that converts the object to the appropriate representation (XML or JSON, in this case).

Relevant pieces of case class User is provided below. If you are familiar with Squeryl you may have already identified the annotations provided for the constructor arguments otherwise don't worry about it; Squeryl is an excellent Scala-based ORM (I like Squeryl quite a bit, that's a topic for another blog post!). User implements Convertable, meaning the two representations -- XML and JSON via toXml and toJson functions respectively.

So with all the above in place, the following request would result in an XML or JSON response based on the Accept header. The logic for identifying the appropriate representation  is in the RestHelper's implicit def jxSel shown below. As RestHelper does not support q parameter out of the box, UserManagementService extended from RestHelper changes the behavior by overriding jxSel.

Actual Parsing: Parsing of the Accept header and determining the representation is done using functions in the ClientMediaPreference object. Instead of embedding the code in this already lengthy post, here is a link to the gist covering the parsing logic.

Conclusion

There are a couple of areas that I still have to tighten-up the code, but that's the general idea. One of the Todo items is to send a 406 Not Acceptable response if the representation that a client asks for is not implemented by the server.

Before closing, let's continue checking off another item from Tilkov's litmus test (as we did in the last post) ...

Can I easily use the same business logic while returning different content types in the response?

Answer: Yes, the framework is flexible in this aspect.

You may also like:

1. Lift and REST: URI Matching and Content Negotiation

So far I like what I see, it is a productive framework with a nice set of features (and has cherry-picked some best ideas from other frameworks too), and what else it's Scala-based (my current favorite language).

Setup

Getting started instructions on Liftweb's wiki worked perfectly fine for me. I used instructions for Maven and I'm using Scala 2.8.

URI Matching

RESTHelper is the trait that you may want to extend for building your REST-based web services. Lift's URI dispatch follows the templating approach in which you would leave part of the URIs to be filled by the clients before they are submitted. For example, id can be sent dynamically by the user: http://example.org/api/user/{id}

The following block of code can take care of the above URI matching ...

the List of strings are the tokens after each "/" (forward slash) in the URI. The above code indicates that a GET request can handle that specific URI pattern. And when such a pattern is encountered invoke the method userDetails. If a URI is encountered as http://example.org/api/user/101, 101 is bound to id variable.

Box[LiftResponse] is the return type that's expected. Box goes by the same notion as Option in Scala. When you have stuff to return you would respond with Full(LiftResponse) and Empty when there is no response. So here is an example of how you can URI match and dispatch for a sample CRUD (I'm using simple User account management).

Ideally I would like to write this in a single case block without breaking into multiple units as I did above. When I add more than three case statements of this complexity (which is not that much, IMO) Scala compiler takes way too long and eventually gives up with an OffsetTooBigException. This issue is in bug tracker for a while now, and the above approach of splitting the matchers into multiple units is based on the workaround suggested there.

The pattern matching is flexible and works great for multiple tokens too. Something like http://example.org/user/{userId}/address/{addrId} can be extracted using a very similar pattern like above with values for userId and addrId binding to their corresponding variables.

Here is an excellent article on Scala's partial functions and pattern matching that you may find it useful in the context of this discussion.

Content Negotiation

Content negotiation is one of the core concepts of RESTful systems where a client can indicate which media type(s) it prefers. Also within the media types it can specify the order of preference. Client does this by using Accept header. For example, consider the following Accept header --

Accept: application/xml;q=0.8, application/json;q=0.9

It indicates to the server a) it can accept XML and JSON formats and b) it prefers JSON over XML (by providing higher value for 'q' parameter. q value ranges from 0.0 to 1.0, higher value indicates more preference).

Ok, so how does Lift fares in this area? Mixed results --

• It recognizes which media type to serve by the Accept header. So for example Accept:application/json header from the client is matched to case "api" :: "user" :: id :: _ XmlJson _ => ...
• Similarly for XML, an accept header with text/xml is matched to XmlGet method fine. One issue that I encountered here is it only recognizes text/xml as XML media type and not application/xml. application/xml is actually preferable to text/xml, generally speaking. One reason on top of my head is text/* media types ignore the encoding specified in the content, in this case if you declare a specific encoding (e.g: UTF-8) in the XML declaration header it will be ignored.
• It doesn't respect the q parameter value. So in the above example, Accept: text/xml; q=0.8, application/json;q=0.9 it still serves the client XML as it only looks for if text/xml is present in the header.

So let's look at Tilkov's first question in the list:

Does the framework respect that an HTTP message does not only consist of a URI? I.e., is dispatch done at least based on the HTTP verb, the URI, the Content-type and Accept headers?

My answer, at this point: Yes dispatch works great in terms of -- HTTP verb, the pattern matching URI templates and Accept headers (partially). Lift has to get its act together in further tightening its content negotiation support.

[I would love to contribute some patches for this and more (like hypermedia support, will elaborate it in the future posts). Lift folks, you have a volunteer here!]

Stay tuned!

Update: Follow-up is posted here: Lift and Content Negotiation

You may also like:

1. REST: DELETE operation and tunneling

Need is to restart JBoss once the artifacts are deployed. I have two different jobs, one for building and deploying artifacts (EAR, in this case) and the other one to restart the server. Former invokes the latter as a part of its post-build actions.

I've setup a build step in Hudson that executes a shell script which essentially invokes stop and start operations on the server. The server stops fine, but when I start the server in the background, server process gets killed once the Hudson process is finished. I've tried multiple ways of achieving this -- tried a couple of JBoss Maven plugins and tried Ant route too suspecting if that was an issue with my Shell script. But the real problem lies with the way Hudson deals with the spawned processes. This behavior is consistent with their design according to Hudson docs.

The suggested workaround for Unix systems is to use something like daemonize. That didn't work for me. Daemonize works fine but the process is still being killed by the Hudson.  [Side note: daemonize is a neat tool, glad that I stumbled on it. Need it for some other purposes].

So how was this resolved? Searching the bug tracker, found the exact issue that I mentioned here. The solution/workaround mentioned there works like a charm. Here is what it says --

set the environment variable BUILD_ID to something like 'dontKillMe' in the
process that should stay alive.

Hudson looks for that environment variable when cleaning up stray processes.

SetEnv plugin is already installed on my Hudson server, and setting BUILD_ID variable value worked! May be that Hudson could provide an option on the admin UI for the user to indicate not to kill the intentionally spawned processes.

Sergio Bossa is spearheading the efforts on the project, and he is doing a terrific job at it. I've been in touch with Sergio for a bit and in discussions about how I can contribute to the project. Before jumping into the core aspects of the product I wanted to work on a client implementation so that I can play with Terrastore and understanding some of its intricacies. So I started working on a client implementation in Scala, my language of choice these days.

The client implementation is available at Github. There are few areas that I would like to tighten up a bit in the code, but it's out there for some early feedback.

I'm certainly excited to get started on the Terrastore core, and working with great minds -- Sergio and Greg Luck, a good friend and guru back from Ehcache days.

[Direct link to Terrastore-Scala-Client on Github]

You may also like:

1. Thoughtworks Technology Radar (April 2010)
2. Scala: Game of Life

I will jump to the biggest surprise (but something that's consistent with what I'm hearing these days) -- GWT is moved back from Assess to Hold status. I used to be a fan of the approach GWT took, mostly coming from my angst towards writing Javascript, and to develop client-side stuff using the language that I'm quite familiar with -- Java.  Although I haven't done enterprise stuff with GWT yet, what I heard was it's not as productive as I was earlier thinking about, and this technology radar points to some of the issues with the generation of Javascript in terms of productivity, troubleshoting, not being able to utilize powerful features of Javascript, and unit testing. I'm not giving up yet on GWT, but would certainly like to hear feedback from the folks who used it in production-grade applications with good success.

As far as languages are concerned -- they are excited about two languages that I'm having great fun with -- Scala and Clojure. I'm fairly convinced that the enterprises sooner than later would evaluate options of using these JVM-based languages than sticking with Java alone. Java as a language is not dead yet (in fact far from it and dead is a too harsh a word), but if the current trend continues in terms of these new breed of JVM languages (coupled with some good customer stories) that day may not be that far off. Other than that in the languages section -- HTML 5 is gaining traction, which is expected.

In the tools category -- Restfulie has got a mention. I think this is pretty significant in the world of REST-based development. Restfulie is an excellent tool to achieve Hypermedia constraint (HATEOAS) of REST, which helps significantly in loose coupling between clients and servers. They said it well -- "It [success of Restufulie] is an emperical proof that the web and the hypermedia can be used to orchestrate complex business activities".

Also in the tools category -- Subversion moves back into the Adopt section. It has to be that way all along, in my opinion. I like distributed version control systems (Git and Mercurial) a lot but Subversion still has a place in the enterprise. I second their opinion that it's a solid version control system suitable for most teams. New to enter the radar is Github, another success story, undoubtedly popularized Git along with their source code hosting and social networking abilities.

I tried to write it in a more functional way but you would surely see an overlap of imperative programming style (having worked with Java for over a decade now).

Rules of the game

[Reproduced from the same Wikipedia article linked above]

The universe of the Game of Life is an infinite two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, live or dead. Every cell interacts with its eight neighbors, which are the cells that are directly horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:

1. Any live cell with fewer than two live neighbours dies, as if caused by underpopulation.
2. Any live cell with more than three live neighbours dies, as if by overcrowding.
3. Any live cell with two or three live neighbours lives on to the next generation.
4. Any dead cell with exactly three live neighbours becomes a live cell.

The initial pattern constitutes the seed of the system. The first generation is created by applying the above rules simultaneously to every cell in the seed—births and deaths happen simultaneously, and the discrete moment at which this happens is sometimes called a tick (in other words, each generation is a pure function of the one before). The rules continue to be applied repeatedly to create further generations.

Code

Hopefully self explanatory

Game of Life

object GameOfLife {
  def buildBoard(liveCells:List[Tuple2[Int, Int]], sideWidth:Int):Array[Array[Boolean]] = {
    val board = new Array[Array[Boolean]](sideWidth, sideWidth)
    liveCells foreach (arg => board(arg._1)(arg._2) = true)
    board
  }
 
  def generationalChange(board:Array[Array[Boolean]]):Array[Array[Boolean]] = {
    val newBoard = new Array[Array[Boolean]](board.length, board.length)
    for (row < - 0 until board.length; col <- 0 until board.length) {
      val lives = computeLives(board, row, col)
      newBoard(row)(col) = if (lives == 3 && !board(row)(col)) true
        else if ((lives <= 1 || lives >= 4) && board(row)(col)) false
        else board(row)(col)
    }
    newBoard
  }
 
  def computeLives(board:Array[Array[Boolean]], currentRow:Int, currentColumn:Int):Int = {
    var lives:Int = 0
    for (i < - Math.max(0, currentRow - 1) to Math.min(board.length - 1, currentRow + 1);
         j <- Math.max(0, currentColumn - 1) to Math.min(board.length - 1, currentColumn + 1)) {
      if ((i != currentRow || j != currentColumn) && board(i)(j)) {
          lives += 1
      }
    }
    lives
  }
 
  def printBoard(board:Array[Array[Boolean]]) = {
    println
    board.foreach {i =>
      i.foreach { j =>
        if (j) print("*") else print(".")
      }
      println
    }
  }
}

Test

Let's pass in live cell coordinates and board size to mimic the behavior of Oscillators (Beacon) pattern. See image below:

Test it!

def main(args: Array[String]) = {
    var board = buildBoard(List((1,1), (1,2), (2,1), (3,4), (4,3), (4,4)), 6)
    printBoard(board)
    for (period <- 1 to 2) {
      board = generationalChange(board)
      printBoard(board)
    }
  }

Output

A dot (.) represents an empty cell and a star (*) represents a live cell.  Initial, generation 1 and generation 2 in that order below:

......
.**...
.*....
....*.
...**.
......

......
.**...
.**...
...**.
...**.
......

......
.**...
.*....
....*.
...**.
......

[Image courtesy: wikipedia]

History

Greg started off with a brief history on the progress of Ehcache over the years [I still remember those early conversations that I had with Greg about 5 years ago when I first contributed to the project]. The project was never static, in fact far from it, there has been a steady progress from the stage where it was simple-yet-powerful standalone cache to a well-implemented extensible distributed framework.

In the early stages, Greg was not too keen on building a distributed cache. Once the goal of getting out a great standalone cache was achieved, and that coupled with contributions from various people (and feature requests) the quest towards distributed cache began. This post Ehcache goes distributed on his blog explains the thought process of that time quite well.

Founded in 2003 as a fork of one of the other open source caching frameworks (Apache JCS). It progressed steadily with additions like Hibernate integration, web caching, distributed caching, Cache Server with REST and SOAP services. Terracotta acquired Ehcache in 2009.

Ehcache Configuration and Performance

Greg explained the basic configuration of Ehcache using Spring's Pet Clinic as an example -- configuring Hibernate and using Ehcache as the second-level cache. He went over configuration options and about the cache eviction algorithms.

I think the performance discussion evoked quite a bit of interest in the audience (well, who doesn't like talking about benchmarks and pretty charts! ) Arguably, Ehcache is the one of the best out there, in terms of performance. If you want to know more about the tests check out the source code yourself (requires Terracotta user account to browse that repository, registration is free).

Here are a few performance figures from the presentation, showing Ehcache's superiority in terms of performance. The speaker also demonstrated the performance figures of Hibernate read and write with Ehcache as the second-level cache (not shown below). Tests were performed in a cluster of 8 client JVMs (1.75G heap), 1 Terracotta server (6G heap) and using MySql

Get (Read) and Put (Write) performance charts below:

Ehcache in-process vs Memcached:

Ehcache in-process has to be faster than Memcached. If not for anything, the basic setup of in-process should have an upper hand over the serialization and network overhead for the Memcached setup. I'd be more interested in more apples-to-apples comparison of Ehcache server (REST-based) vs Memcached. Mentioned that to Greg and I'm sure he is on to it next ...

Ehcache Monitor

New Features in Ehcache 2.0

• Hibernate 3.3+ caching API: New SPI addresses some of the synchronization issues with the previous versions to better suit for the clustered environment.
• JTA: From version 2.0, Ehcache acts as an XAResource and participates in JTA transactions. It detects most common transaction managers for various popular application servers.
• Write-through and write-behind caching: Version 2.0 introduces write-through and write-behind caching. In write-through pattern -- cache acts as a facade to an underlying resource, and a write to the cache causes write to the resource behind it. In write-behind the concept is pretty much the same but the writes happen in an asynchronous fashion. Read more here.
• Bulk loading: Greg said this is one of the features that's been requested for a while now. Now 2.0 has the ability to significantly speed up bulk loading into caches using the Terracotta server array. Read more here.

Conclusion

All-in-all I think that was a great session, and as always, I enjoy using Ehcache and the association with the project. I also got a chance to hack some code with Greg while he was here in Philadelphia. Hope to contribute more ...

You may also like:

1. Java’s HTTP Handler and Cache Validation Issues

Here's the trouble. We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

He continues ...

The other trouble is that it's so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers -- ESPECIALLY interruptions by coworkers -- all knock you out of the zone. ...

As Joel rightly points out in the article getting into that "zone" is not that easy. And once you are in, there are quite a few distractions in a typical corporate environment. Great, if you are lucky and gifted to be get into the zone without much effort. If you are like rest of us, you would be all ears for techniques that improve your productivity.

So an year or so ago, I stumbled on this technique called Pomodoro. At the outset it's a simple tracking and feedback process where the unit of work is the pomodoro, a time slot of 25 minutes. The basic principle is to keep you focused enough for specific period of time (in this case: 25 minutes). Here is a free e-book [PDF] if you are interested to know more.

This technique helped me quite well in accomplishing some of the tasks I have either been not focusing enough or procrastinating for various reasons.

This InfoQ article posed some interesting questions with some counter-arguments from Mario Fusco. Mario compares IT professionals with the professionals from other fields and says --

So, why should our work be so different from the former ones? Why do we always think that our work is so special and unique to need a wide set of specific methodologies? Are we professionals or unexperienced kids playing with something bigger then them? I think that, like any other serious professional, I can stay concentrated on what I am doing for hours. I honestly don't need a pomodoro to keep myself focused for just 25 minutes. And if somebody can stay focused for no more than 25 minutes I am afraid that he should really rethink the way he works.

To respond to that, I'm not so sure whether there is an apples-to-apples comparison between the professions and type of work performed. The basic goal is to be productive. Regardless which profession you are in, you find your own tools and techniques to accomplish that goal. I would treat this technique or something else as a chance to improve. Certainly with corporate emails, phone calls, and other interruptions it's certainly not easy to concentrate for a good chunk of time and being productive (I'm not even mentioning about Blogs/RSS readers, Twitter, etc.). As I already mentioned, if you think you are already productive and can concentrate quite well (without any new techniques), great, pat on your back.

On the drawbacks-front he says --

Said that, in my opinion there are also other important drawbacks in the pomodoro technique. What should I reply to my customer who is calling me, possibly from the other side of the ocean? That I am in the middle of my pomodoro and I can't break it? ...

I don't think the technique is that restrictive. Obviously if that call is important you would take it and discard that Pomodoro, attend the urgent task, and get back to Pomodoro when you are ready. Let's not complicate it more than what it is, this is just a way to being more productive cutting down on the distractions. I don't see this as a hindrance to the team work or on your efficiency to deal with more urgent matters.

Have you used Pomodoro technique, how do you like it?

Blog

I have this blog up for a couple of years but it's in 2009 I've started taking it more seriously. My goal with the blog is straight and simple -- share what I learn, and in turn benefit from the collective wisdom of my readers, friends and fellow bloggers. Towards that effect, 2009 is a satisfactory year.

Here are the top posts of the year --

• REST: CRUD with JAX-RS (Jersey) and REST: CRUD with Grails: I did a lot of reading on REST this year. That reading along with discussions with some of the best in the industry helped significantly. Towards that effect, I've written two posts on the CRUD aspect -- using JAX-RS and Grails (just to clarify, REST is lot more than CRUD but these posts concentrated on performing CRUD operations using two most exciting frameworks, IMO). You can find all my posts related with REST here.
• Open Source Software Model - A Positive Sum Game: Blogged about open source software and about a keynote talk that I attended at Philly ETE conference.
• Subversion: LDAP Integration using Apache: I've achieved a good level of proficiency administering Subversion this year. This post discusses about LDAP integration. [Git is next in the list, look forward to work lot more with it in 2010].
• Jira Plugin: Unique Issue ID Across the Projects: Developed a Jira plugin that assigns unique identifier to the issues across the projects. Further, this post extends the functionality and make the IDs search-able.
• Career 2.0: Take control of your life: Write up of an inspiring talk.

Books

Regardless of the vast number of resources that are available online, a book is still my preferred choice. A good book helps in learning something new (or reinforce the concepts) in a systematic and a structured manner. A well-written book may not answer all the questions but helps in generating enough enthusiasm for further exploration.

Here is the list of books that I read in 2009. I could have done bit better on this front, but given all the constraints in place this may not be so bad --

• Groovy in Action: Groovy has become one of my favorite scripting languages. [My review]
• Career 2.0: As the name indicates, a career-oriented book from Pragmatic Bookshelf. [My review]
• Grails in Action: An excellent book on Grails. [My review]
• Hello World: A cool book for Python beginners. [My review]
• The Passionate Programmer: The title says it all, a great read. [My review]
• RESTful Web Services Cookbook: Not released yet, scheduled for the first quarter of 2010. I had great fun reading and reviewing this book. Watch out for it, has got delicious recipes for all REST enthusiasts. [O'reilly link and Safari online]

There are a few more books that I haven't finished reading yet. I will be writing about them soon.

Twitter

I've resisted so long to sign-up on Twitter. Primary reason for that resistance was I was not sure how that 140-character thing would be transformed into something meaningful. That resistance broke down just over an year ago. 1700 tweets later, I'm here to report how much I learnt via Twitter for the last one year or so.

I use my Twitter account primarily to tweet about software, architecture, programming languages and the stuff related. Feel free to follow me there, if you are into it.

There are quite a few geeks out there, Twitter gives a great chance to peek into their thought process. It's also a great place to share the links and articles you are reading. I'm also glad that I gained some great friends and met some of my ex-colleagues with whom I lost touch a little while ago.

It is extremely easy to waste the time and not find any use of Twitter based on how you use it. For me, all that matters is to follow the folks who are willing to share their knowledge, and strictly stick to the passion -- technical topics. You don't see any tweets about what I ate for my lunch, etc. Not that anything wrong with it, I just don't find much value in providing that kind of information.

Conclusion

2009 is an year that I'm reasonably satisfied with some of the milestones that I've set out for myself. However, I know there are many more miles to go ...

You may also like:

1. Book Review: The Passionate Programmer

I guess on Twitter, I first heard about WebDriver, and accolades about its approach and its API design. So decided to give it a try. Best part is Selenium and WebDriver projects are joining forces with a merger in Selenium 2.0. Per my understanding, the plan is to provide both Selenium and WebDriver APIs under Selenium 2.0 umbrella. At the time of writing this post Selenium 2.0a1 (Alpha-release) was out.

So here are my first impressions:

• Approach: At the outset WebDriver is similar to Selenium (Remote Control) and Watij -- developer-focused and API-driven. But the best part, for me at least, WebDriver doesn't take the approach of running as a Javascript application within the browser (like Selenium), rather it takes JNA approach interacting with the browser. That approach rules out same origin issue (a headache with Javascript approach).  Also this doesn't require native libraries installed and registered on the client (e.g: DLLs need to installed on the client for Watij).
• API: API is intuitive. For example, following code snippet finds the element (text box, in this case) by name and simulate the typing by the sendKeys() method.

  driver.findElement(By.name("full_name")).sendKeys("Joe Schmo");
  

  Similarly,

  driver.findElement(By.name("Details")).click();
  

  finds the element (button, in this case) and clicks the button.

• Multiple drivers: Unlike Watij, which only supports IE at this time, WebDriver supports -- IE, Firefox, Chrome, and it also has a HtmlUnit version to run headless.
• Window/Frame handling: This is yet another area where WebDriver excels with a caveat (that I'll get into in a moment). When an operation like a button-click or a hyperlink-click opens a new pop-up browser, WebDriver provides an excellent way to get a handle to the new browser. Following call returns a set of all the window Ids.

  driver.getWindowHandles()
  

  You can iterate over the Set to find which one is your new window and switch to that window for all future operations.

  driver.switchTo().window(windowName)
  

  Windows' handling is quite solid compared to handling of the Frames. In most of the situations it worked except when there are iFrames which load dynamically the behavior is not that consistent.

• Wait behavior: When a particular operation (like a button-click) is underway WebDriver waits for the operation to finish before it executes the next step of the test case. Although this sounds trivial, I've had issues with this while using other tools. In those cases I had to use Thread.sleep() to wait between the page load and the execution of the subsequent step.
• Alert Dialog: Couldn't find a way yet to handle alert dialogs. I have to dig a bit more into the API and forums to see if they are supported at this time.
• Mouse Events: I'd like to see more mouse events -- double click, hover over an element, page scrolling, right click, etc.

Are you using WebDriver? What are your thoughts?

driver.findElement(By.name("q"));