Manually Set Map Value in Struts 2

Often, the Struts 2 tag library doesn’t offer enough functionality to support a nice DHTML type of layout. In those cases, I find myself creating URLs manually to send to the action.

In most cases, this isn’t a bid deal. However, to make it work right, you have to duplicate the format that Struts uses to receive the data. For example, to send a list of items (such as List<String> names;), you would format your URL to look like


&names=johnny&names=tim&names=bill


Maps are a little harder. To create a URL to send to a map, you can use the following format:


&variableName[key]=value


Say you have the following map:

Map<Integer, Integer> userIdOrderIdMap = new HashMap<Integer, Integer>();

To set the map from Struts 2, you’d use the following URL string:


&userIdOrderIdMap[0]=1&userIdOrderIdMap[10]=15

This is the equivalent of:


userIdOrderIdMap.put(0, 1);
userIdOrderIdMap.put(10, 15);


You will probably have to manually call encodeURIComponent() on the URL string to make sure the brackets and any other special characters are escaped properly, but you already knew that, right?

You can also use a dot notation (such as &variableName.key=value), but I find that a bit counterintuitive to the way KVC types are intended to be represented.

The Power of Unit Tests

Yesterday, my dev team embarked on a significant refactor of our main code base in order to merge in a branch alongside implementing new functionality and changing some existing classes. A trifecta of complexity if you will. For a production quality system, one that we expect to deploy very soon and is the backbone of our company’s infrastructure, you might expect us to have been a bit more careful / timid in making our changes.

However, you’d be wrong and it’s all because of unit tests (that and we are all rock-star engineers, but that’s another post).

I didn’t work with unit tests much before my current position. This was mostly due to legacy platform limitations that did not make automated testing easy. Now, I couldn’t live without them. Confidence in my work is much greater now than it was previously for a good reason: unit tests give engineers power.

I know that the requirements of a particular class are laid out in the classes’ test. Whatever I do to the class, it must not only compile but light up green. This gives me the boldness to make large changes without worrying that the refactor is going to negatively impact (read: break) other parts of the system.

Code these days often exists beyond the classes themselves and in places like configuration files and build scripts, and we’ve created tests that take these pieces of auxiliary setup into account. Doing that extends our confidence beyond our primary classes and into our build process, database connections, and system as a cohesive whole. Very cool.

Unit tests are great for creating interfaces (working with the API before you actually write the implementation is a good way to make sure it doesn’t suck), verifying complex functionality, and system integration. The most empowering thing they offer, however, is confidence. In an agile shop such as ours, this gives us the ability to work as quickly and fluidly as possible and is a huge factor in why our little team has been so successful.

“A compiler tells you your code is well formed, a unit test tells you your code is well behaved.”

– No Fluff Just Stuff, Fall 2008

No Fluff Just Stuff

A few weekends ago (November 14-16), I attended the No Fluff Just Stuff software symposium. It was a three-day long event with some of the best and brightest in the Java, open source, and engineering-in-general space. I took a lot out of this conference, and I’m looking forward to going again in the near future. One of the great things about going to something like this is watching how the touring speakers use different tools. Even with applications that I use on a regular basis (such as TextMate), I was able to pull some new uses and features from the presentations. Here is my take on the sessions I attended:

1. Groovy: The Blue Pill – This was the first talk from Scott Davis on Groovy. It was designed to be an easy introduction to the Groovy space for current Java developers. Some standout information:
   1. Groovy compiles to Java bytecode
   2. Groovy consists of only one .jar file
   3. Groovy includes a lot of Java cruft built in for free (such as automatic getters/setters, default constructors, etc.)
   4. Groovy can easily call Java methods and use Java objects
   5. Groovy can use inline values in Strings (called “G”-strings)
   6. You can easily insert XML, JSON, HTML, etc. into a Groovy string using triple quotes
   7. Unit tests are a great insertion point to begin integration of Groovy into a Java application (but Groovy currently only supports JUnit 3.x and not 4.x)
2. Groovy: The Red Pill – This was the second talk on Groovy from Scott Davis. This talk was intended to demonstrate the real flexibility and power of Groovy rather than simply touting its interoperability with Java:
   1. Groovy can use “Groovy truth” which allows statements such as
      if(array) {}
      rather than
      if(!(array==null || array.isEmpty())) {}
   2. Groovy supports operator overloading
   3. Groovy supports closures and has some great support for iteration through collections
3. Rapid Web Development with Grails and AJAX – This was the third talk on Groovy from Scott Davis which covered how Groovy and Grails integrate to create an incredible web application development experience. Unfortunately, much of the AJAX information was cut short due to a guy in our session asking a bunch of “Rails vs. Grails” questions. Some good points:
   1. Grails was inspired by Rails but is not a clone of Rails
   2. Grails is a full-stack solution and not simply a framework like Struts or Spring MVC
   3. Grails is database agnostic and supports practically every Hibernate dialect available
   4. Grails has some great IDE support
   5. Grails has great built-in AJAX and scaffolding support
4. Give It a Rest – This was Brian Sletten’s first talk on REST (Representational State Transfer). I have a fair amount of practical experience with REST API’s (creating, consuming), but this was a great talk about the goal of a REST API and how it relates to an application as a whole.
   1. SOAP is overkill in many situations and increases complexity
   2. Over 85% of Amazon customers prefer to use the REST API rather than its SOAP counterpart
   3. REST is more than just URLs
   4. REST focuses on information spaces rather than code or objects
   5. REST can use HTTP return codes to dynamically point to moved resources
   6. REST uses HTTP verbs to indicate the desired action
   7. Since REST uses HTTP, it is stateless and takes advantage of built-in browser caching to reduce server overhead
5. Spring 2.5: Spring without XML – This was Ken Sipe’s talk on Spring 2.5 without the XML-hell that many of us Spring 2.0 developers are wading through. I don’t currently use Spring 2.5, so it was difficult at times to follow where Ken was going. However, I soaked in a lot of the capabilities of Spring without XML and finding out exactly “how” to do something is much easier than the information gap of knowing if it is possible or not.
6. Java.Next – Stuart Halloway spoke in this session about all the different languages that are making their way into the JVM. Most of his talk was simply about why this is happening and why it is good for the Java community (and, trust me, it’s very good for us!) I didn’t take too many notes during this session, but he definitely convinced me (although, to be honest, Scott Davis’ sessions on Groovy had me convinced already)
7. Architecture and Scaling – This presentation, by Ken Sipe, was an outstanding pragmatic approach to creating an easily scalable application. Some good points:
   1. Scalability is about predictability (e.g. if you know what a load looks like with 200 users, you should know what it looks like with 400)
   2. Scalability can be horizontal (adding more nodes) or vertical (adding more resources to a node such as increased memory or CPU power)
   3. Performance is not equal to scalability. You often have to sacrifice up-front performance gains to make room for future scalability (one example great Ken used was a load balancer. Load balancers introduce latency to a project, but allow for multiple nodes to be inserted and, therefore, increase scalability)
   4. An engineer should always be trying to manage things outside their control (e.g. user behavior)
   5. Metrics are good; use them
8. Git – Another Stuart Halloway talk revolving around the new SCM system called git. While I was already a bit familiar with git, this talk intrigued me enough to find an environment whereby I use it on a regular basis and can put it through its paces.
9. Introduction to Hibernate – Scott Leberknight’s talk on Java Hibernate.
   1. Hibernate is a very popular open-source ORM framework
   2. Hibernate uses dialects to talk to a database
   3. Hibernate uses annotations to communicate relationships between objects (one-to-many, one-to-one, etc.)
10. Rich Clients, Rich Data Linking and Consuming – These were the last couple of talks of the conference by Brian Sletten. He expanded on REST concepts and showed how RDF can be used for some pretty amazing data combinations. He also encouraged projects to move beyond their silos and expose their data to the rest of the web. He had some amazing examples of this sort of exposure, and I am excited to put some of his ideas to use at some point.

The conference was pretty amazing and I am very happy to have gone. In addition to the sessions above, there was a great keynote by Ken Sipe about inter-relational skills engineers should strive to build. A great quote from this keynote:

Your employer is responsible for your job; you are responsible for your career