Out of the box, Spring Shell supports printing command results to the terminal in a fairly basic way.

Spring Shell also provides the ExecutionProcessor interface, allowing a “command provider to be called in a generic fashion just before, and right after, executing a command”.

The interface defines three lifecycle events that can be intercepted:

  • before a command has been invoked
  • after an invocation has been returned
  • after an exception was thrown

I was interested in hooking into the afterReturningInvocation to provide “step logic” - potentially allowing user or system input to execute additional logic based on the result of the initial command result (and/or each step result) e.g. paging backwards or forwards on the command line through lists of data.

I was able to achieve this and opened a JIRA ticket and the following pull request on Spring Shell’s GitHub repo: SHL-174: Multi-Step Commands #67

Read on →

Be it DVCS workflows, JSON transformations, or blogging frameworks, I always favor tools that allow me to use the terminal.

I’ve recently started using Spring Shell for rapidly experimenting with consuming data from a series of APIs I had created.

I have become allergic to XML configuration for Spring applications in recent times, so I was disappointed to see a lack of support for Java configuration within Spring Shell.

However, I did find a JIRA issue tracking the feature request. The ticket creator had even submitted a pull request with a potential solution. However, Spring Shell lead Mark Pollack responded that the feature could be provided in a simpler manner and even provided guidance to the solution.

Implementing this solution seemed quite straightforward, so I gave it a go and it turned out well.

I’ve submitted the following pull request to the Spring Shell GitHub repository: SHL-106: Java Configuration support #66

Read on →

At SportsLabs we regularly encounter proprietary, non-standard APIs and formats. Our job is to integrate with these APIs, normalize them, and distribute the data is web- and mobile-friendly web services.

One of the scenarios we often encounter is a provider supplying multiple resource JSON-based APIs that share a lot of the same data in their responses, but without any particular field dedicated to identying the type of the resource e.g.

1
2
3
4
5
6
{
...
  "common": "a common field within multiple resource responses",
  "one": "one is a field only within this response type"
...
}

and

1
2
3
4
5
6
{
...
  "common": "a common field within multiple resource responses",
  "two": "two is a field only within this response type"
...
}

Instead of mapping 1-to-1 with these APIs, we often try to follow DRY principles and model them as implementations of a common polymorphic abstraction.

When using Jackson for polmorphic deserialization and not being in control of the API response data, the lack of any kind of type identifier requires a different solution.

One of the ways we’ve addressed this problem is to identify fields and properties that are unique to a particular resource API’s response.

We then add this field to a registry of known unique-property-to-type mappings and then, during deserialization, lookup the response’s field names to see if any of them are stored within the registry.

Read on →

A partner recently provided a useful HTTP-based API for me at short notice.

The API returned simple JSON representations of the current state of various events they had periodically ingested from our REST APIs.

A decision they made was to use "yes"/"no" values in the response, rather than booleans e.g.

1
2
3
4
5
6
{
...
  "exists": "yes",
  "has_ended": "no"
...
}

I had written a Spring Social-based API client to interact with their API but wanted to deserialize their API response representation into a POJO that followed Java convention.

Jackson is a great Java library for processing JSON data format. It’s quite straightforward to use it to solve a problem like the above with a custom JsonDeserializer.

Read on →

Our team recently built a Spring MVC 3.1 application for a web service API. We had used the traditional XML-based configuration but I wanted to see how easy would it be to migrate a Spring application from an XML-based to a Java annotation-based configuration.

I referenced three great resources for this migration:

Read on →