I’ve been doing a bit of exploration in spring-amqp lately and came across some of the built-in features to automatically marshall/unmarshall AMQP messages to java objects. Although you can get away with just having java objects implement Serializable but that just means you’ll only be dealing with java to java communication and that’ll break down the amount of flexibility you have.

Luckily there’s JsonMessageConverter, which allows you to marshal and unmarshal messages as JSON. By default this uses a _TypeID_ header which maps to the java class name. For this me this just didn’t work as I have an app in node.js communicating with a Consumer and Producer living in java land. The solution comes from a little undocumented feature.

Essentially you just need to set a map of class mappings on the java side of things:

Then assign it to the JsonMessageConverter you’ll be using to marshall messages… in this example it’s used for both a consumer and producer, but I’ll just focus on the consumer:

And the actual consumer (which is just a plain java object).

Now whatever messages get published will just refer to the _TypeId_ header to map json objects to classes behind the scenes (no JAXB annotations or anything needed). For example, publishing a message from node.js:

As a final note, I didn’t like the default header field _TypeId_. The only way to change this with the current API is to override getClassIdField in DefaultClassMapper to return the header field name you want to use. For my purposes I just changed this to the field type:

Pretty sweet stuff. Feel free to check out some of the examples in the github repository for this.

No tags

Recently I’ve been working with some legacy code and have hit a situation that I’ve been in before when pair programming on such projects. Something I like to call “The Ditch.” I say legacy code because I don’t see this situation arise often in greenfield projects unless we’ve made a mistake, but I’d like to hear some feedback and other experiences.

Typically we’re all probably familiar with a good pair programming session. One person writes a test, the other person passes it and writes the next test, the original person passes that, repeat. Throughout the course you usually have some pretty high communication and try to take equal turns at the keyboard. It’s usually a feel good experience and quite productive with both parties feeling like they’ve been pretty active. However this seems to break down sometimes when dealing with poorly designed code.

Lately, we’ve been working in a project with lots of integration tests but zero unit tests. The side effect is that it is very difficult to test drive new features because the resulting code is very poorly designed (static singletons, large object graphs that get created and thrown away for single purpose uses, hidden dependencies, etc). Making the code testable can be a real burden and before you know it, you’re pulling dependencies up so they can be properly injected for the next couple of hours. To make things worse, the cycle is broke and your partner is just sitting there watching you apply all of these simple refactorings as you try to get some proper inversion of control in place in order to write a test that won’t span 5,000 lines to set up all the crap the system under test depends on due to high coupling to other components. At this point, you’re in the ditch, struggling wildly to get out.

You can take turns at the keyboard, but sometimes it doesn’t even make sense to switch. You can keep the communication high, talking as you do it and sometimes your partner might even be able to jump in and do some re-arranging as well but it still doesn’t change the fact that your partner is just sitting there watching you as you madly try to pull dependencies out and up through the object graph.

Things do return to normal once you get out but it still feels pretty rough when you’re stuck in the ditch.

No tags