http://blog.dutchworks.nl/2011/12/13/embedding-rss-in-hippo-using-the-pipelines-feature/

http://blog.jteam.nl/2011/08/01/cleaning-up-your-maven-repository

If you want to find out more about this sample read on.

Introducing the sample

The sample is based on the famous address book from the axonframework project. We reuse the axon sample and create a rest like interface that returns json to the clients. The source code is in the rest-ui project within the axonframework source tree under samples. This project also contains the listener code for the Contact and Address based events. The listeners listen for events and publish content from these events to the redis pub/sub mechanism. More on this in the later sections.

The other part of the sample is a node.js application. This application makes use of the rest api to obtain the data via http requests. Events about data changes are received through redis, using the pub/sub mechanism. The node.js application is available on Github. If you want to follow along, you can find the sources here:

https://github.com/jettro/axon-addressbook-nodejs

http://code.google.com/p/axonframework/source/browse/trunk#trunk%2Fsample%2Faddressbook%2Frest-ui

The following screen dump gives you an idea about the application.

In the screen you see the list of contacts. You can add a new contact, change the name of a contact and add addresses to contacts. On the right you see the messages pane. Here you receive messages about new contacts that have been created, changed or deleted.

Now let us have a look at some of the code. We start with the java backend and then continue with the node.js part.

The java part of the sample

Numerous blogs have been written about rest based clients using spring mvc. Therefore I do not want to lose to much time in that area. Most important spring configuration is within the web.xml and the dispatcher-config.xml. In the web.xml we configure that every request is going to the spring dispatcher. We do not have status resources, only json responses. Within spring we make use of annotation to configure the beans. To be able to respond with json we make us of Jackson to transform beans into json objects. All pretty straightforward spring. Check the config file for yourself if you want to see how it works.

Next step is the controller that handles all the requests.

Handling requests in the Cntroller

The Controller handles the following requests:

• /contacts : GET, returns the list of all contacts
• /contacts : POST, creates a new contact
• /contacts : PUT, changes an existing contact
• /contacts : DELETE, removes a contact
• /contacts/{identifier} : GET, returns the details of a contact
• /contacts/{identifier}/address : PUT, creates a new address or updates an existing one based on address type
• /contacts/{identifier}/address : DELETE, removes the address of provided type

Let us have a look at one of the requests to show the flow. For example we take the request for details. The following code block shows the complete method.

@RequestMapping(value = "{identifier}", method = RequestMethod.GET)
public @ResponseBody Map<String, Object> details(@PathVariable String identifier) {
    List<AddressEntry> addressesForContact = repository.findAllAddressesForContact(identifier);
    String name;
    if (addressesForContact.size() > 0) {
        name = addressesForContact.get(0).getName();
    } else {
        name = repository.loadContactDetails(identifier).getName();
    }
    Map<String, Object> map = new HashMap<String, Object>();
    map.put("addresses", addressesForContact);
    map.put("identifier", identifier);
    map.put("name", name);
    return map;
}

The RequestMapping annotation tells spring which requests need to be mapped to this method. The controller already maps all /contacts to this controller. The {identifier} now maps everything with a url like /contacts/{identifier} to this method, as long as it is a GET request. This identifier is also used as a parameter for the method. With the @PathVariable we tell spring to take the value for this parameter from the url or Path that was requested. The final annotation in the method declaration is the @ResponseBody. This tells spring to use the return value as the response body, so not as the name of the view to use. We have already configured to use jackson to transform the response body into json. In the code of the controller you see we return a map with three objects in it. A list of addresses, an identifier of the contact and the name of the contact. The json coming out of this is:

{
"name":"Jettro",
"addresses":[
{
"name":"Jettro",
"identifier":"82b4fef5-3389-440d-8893-6831a64e200d",
"addressType":"PRIVATE",
"streetAndNumber":"Feyenoordlaan 010",
"zipCode":"3000AA",
"city":"Rotterdam"
}],
"identifier":"82b4fef5-3389-440d-8893-6831a64e200d"
}

That is what you need to know about the rest api that I have created. If you want to have a look at the controller, check here. The next step is about the listeners that listen for axon events related to the contacts and addresses and store information in redis.

Listening for events

We register listeners with axon for the contact related events as well as address related events. This is very easy with the annotations provided by the axonframework. The following code block shows how we register an event listener for the ContactCreatedEvent.

@EventHandler
public void handleContactCreatedEvent(ContactCreatedEvent event) {
    ContactEntry value = new ContactEntry();
    value.setName(event.getName());
    value.setIdentifier(event.getContactIdentifier());
    Message<ContactEntry> message = new Message<ContactEntry>("contact-created", value);
    publisher.publish(message);
}

Notice the @EventHandler annotation. This registers the listener with axon. As you can see we take the information from the provided event and put it in a Message object. The message object contains a type and the content. The type can be used at the receiving side to better understand how to handle the received event. The publisher is auto injected by spring. In my case it is a redis publisher.

Publishing to redis

A library to talk with redis is jedis. Jedis makes use of a pool which is configured in spring. Check the listener-context.xml to see how it works. Jedis does not have the most obvious api but it works. The following code block shows how a message is published to redis.

public void publish(Message<?> message) {
    StringWriter writer = new StringWriter();
    try {
        mapper.writeValue(writer, message);
    } catch (IOException e) {
        logger.warn("Problem while writing ContactEntry to a string writer", e);
        return;
    }

    Jedis jedis;
    try {
        jedis = jedisPool.getResource();
    } catch (JedisConnectionException e) {
        logger.debug("Could not obtain redis connection from the pool");
        return;
    }
    try {
        jedis.publish("nl.axonframework.examples.addressbook", writer.toString());
    } finally {
        jedisPool.returnResource(jedis);
    }
}

The code is not very complicated. The important part here is that we use a jackson provided ObjectMapper to map the provided message to a json representation. Then you can see the nice jedis api at work. As you can see we publish a message to a queue. Our node.js client will subscribe to this queue. That is have the redis publish/subscribe works. Not very hard is it?

That is it for the java side. We now know how to get data using the rest api and we know where to get information about events that take place. Let us move on to the node.js side of the application.

The Node.js part of the sample

I do not want to go in setting up a node.js project. Do not want to explain all the different libraries that I use. I have written other blog posts on node.js that I do not want to copy. The most important one is this:

http://blog.jteam.nl/2011/04/18/learning-node-js/

The node.js project uses 4 libraries:

• express – doing the mvc part of the web application
• jade – view templating
• now – server push to the client (will explain this in a bit more detail)
• redis – for redis interaction




Project layout

The public folder contains all the client related files like javascript, css and images. I will explain one file in here later on when discussing node.js. The test folder contains the test for the ContactRepository. Using this test helped me to verify that the integration between the java backend and the node.js application is working without having to start the application and go through the browser to check all requests. The views folder contains all the jade templates. Check mentioned blog post to find more information on jade. The app.’s initializes the application and maps all possible requests to methods in the ContactController. The controller knows where to get the data from and what page to render. The repository is responsible for obtaining data from the rest api on the java side.

Initializing the node.js application

As mentioned the app.js is the start of the application. Let us have a look at the different parts.

var ContactController = require('./ContactController');
var repository = require('./ContactRepository').createRepo('localhost',8080);
var contactController = new ContactController(repository);

This part initializes our components. We will have a look at the createRepo method later on. But notice that we initialize the controller with an instance of the repository.

app.get('/', contactController.listContacts);
app.get('/contact/new', contactController.newContactShowForm);
app.post('/contact/new', contactController.newContactPostForm);
app.get('/contact/:identifier',contactController.contact);
app.get('/contact/:identifier/edit',contactController.changeContactShowForm);
app.post('/contact/:identifier/edit',contactController.changeContactPostForm);
app.get('/contact/:identifier/delete',contactController.deleteContactShowForm);
app.post('/contact/:identifier/delete',contactController.deleteContactPostForm);
app.get('/contact/:identifier/address/new',contactController.newAddressShowForm);
app.post('/contact/:identifier/address/new',contactController.newAddressPostForm);
app.get('/contact/:identifier/address/:addressType/edit',contactController.changeAddressShowForm);
app.post('/contact/:identifier/address/:addressType/edit',contactController.changeAddressPostForm);
app.get('/contact/:identifier/address/:addressType/delete',contactController.deleteAddressShowForm);
app.post('/contact/:identifier/address/:addressType/delete',contactController.deleteAddressPostForm);

These are all the possible requests. The urls are easy to understand. As you can see, all urls are mapped to a method of the contactController

var Now = require('now');
var everyone = Now.initialize(app);

var redis = require("redis"),
    client = redis.createClient();

client.on("error", function (err) {
    console.log("Error %s", err);
});

client.on("message", function (channel, message) {
    everyone.now.receiveContact(message);
});
client.subscribe("nl.axonframework.examples.addressbook");

This is the harder bit. This has to do with receiving messages using the redis pub/sub mechanism and sending it to all connected clients using the nowjs library. I’ll discuss the now.js part later on.

Request handling

By using the repository object the controller becomes very easy. We only have to obtain the right data and render the right view. The most basic method is showing a list of contacts. The following code block shows the complete method.

ContactController.prototype.listContacts = function(req, res) {
    repository.listContacts(function(contacts) {
        res.render('index', {locals: {contacts: contacts, nowjs: true}});
    });
};

Notice that we use a callback that is provided to the repository listContact method. Check that we provide the list of contacts to the view, together with a second parameter called nowjs. Remember this, on this page we enable nowjs, meaning that we can receive messages when looking at this page. Other methods are similar, have a look at the method that handles submitting a form to create a new contact.

ContactController.prototype.newContactPostForm = function(req, res) {
    repository.newContact(req.body.new_name, function(code, message) {
        if (code == "ok") {
            res.redirect("/");
        } else {
            res.render('newcontact', {locals: {error:message}});
        }
    });
};

In line 2 we obtain the form parameter new_name from the request body. Than we create a new contact. The callback method expects a code indicating whether the submission of the new contact was ok. If not, we render the form again with the error message. This happens when we try to create a contact with a name that already exists. The following image shows the screen with an error message.

Next up is the communication with a rest based application

The Repository as a client to a rest application

During the initialization of the application I already mentioned the createRepo method of the ContactRepository. The following code block shows the method. As you can see it initializes a repository with the default values for host and port.

ContactRepository.createRepo = function(host, port) {
    var repo = new ContactRepository();
    repo.host = host;
    repo.port = port;
    return repo;
};

Again most of the interaction with the backend is the same. Therefore I use the create contact again as an example. I have created tests for all the repository methods. Let us have a look at the test first.

function testNewContact() {
    logTestName("New contact");
    repository.newContact("My Test", function(code, message) {
        assert.equal("ok", code, "This should be no problem and an ok should be returned: " + code);
        // Check if the amount of contacts is increased
        repository.listContacts(function(contacts) {
            assert.equal(numContacts + 1, contacts.length, "Number of contacts is not right, create did not work: " + contacts.length);
            testAddAddress();
        });
    });
}

Notice that we check the return code and that the amount of contacts is increased. The following code block shows the implementation of the method of the repository.

ContactRepository.prototype.newContact = function(name, callback) {
    var opts = createHttpRequestOpts('/contacts', 'POST');

    var req = http.request(opts, function(res) {
        res.setEncoding('utf8');
        res.on('data', function(data) {
            if (res.statusCode != 200) {
                console.log(data);
                callback('error', 'Maybe the name is already taken?');
            } else {
                callback('ok', 'The new contact has been send')
            }
        });
    });

    var contact = {};
    contact.name = name;

    req.write(JSON.stringify(contact));
    req.end();
};

function createHttpRequestOpts(path, method) {
    return {
        host: host,
        port: port,
        path:path,
        headers:{'Accept':'application/json','Content-Type':'application/json'},
        method: method
    };
}

I use the nodejs provided http request. Within the help function the opts object is created with the host, port, path, method and the headers. The headers are important to request json. Of course we provide a callback to handle the http response. Everything not 200 is an error as a response code. Here we call the provided callback to the repository method with the ok or error code. At the end of the method we do the actual request creation with the json request.

The final bit is the server push using the now.js library.

Server push using now.js

Node.js comes with a socket.io library. This makes server push very easy. Still it can be a lot easier. That is when using now.js. Now.js enables you to call methods on the client that are actually on the server and vise versa. Let us have a look at the code for sending messages to the client when a redis event is received again.

var Now = require('now');
var everyone = Now.initialize(app);
client.on("message", function (channel, message) {
    console.log("Received message: %s", message);
    everyone.now.receiveContact(message);
});

The important part here is the initialization of now and the line with everyone.now.receiveContact. Now we will call the connected clients method receiveContact and provide the message. Of course we need some client code for this. This code is available in the local.js file in the public folder.

$(document).ready(function() {
    now.receiveContact = function(data) {
        var message = JSON.parse(data);
        var toWrite;
        switch(message.type) {
            case 'contact-removed':
                toWrite = "Contact removed";
                break;
            case 'contact-created':
                toWrite = "Contact with name " + message.content.name + " created";
                break;
            case 'contact-changed':
                toWrite = "Contact changed name to " + message.content.name;
                break;
            case 'address-created':
                toWrite = "Added address of type " + message.content.addressType + " to contact " + message.content.name;
                break;
            case 'address-removed':
                toWrite = "Removed address of type " + message.content.addressType + " to contact " + message.content.contact.name;
                break;
        }
        $("#messages").prepend("<div>" + toWrite + " </div>");
    };
});

As you can see, we construct the message based on the type of the message and prepend a new div within the #messages div. Really that is all there is to it.

Last remarks

That is it. Again a long blog item. Hope you got some new knowledge out of it. Feel free to post comments if you have questions or even better improvements.

Within this blogpost I’ll explain the installation of maven on Snow Leopard and I’ll present the bash script that can help you to switch between installations of maven.

Maven on the Mac (Snow Leopard)

By default maven is installed in the path: /usr/share/java. The maven executables are installed as maven-3.0.2 and maven-2.2.1. Since the upgrade path is a bit slow I tend to install my own maven binaries. I extract them as provided by apache using the apache-maven-x.x.x format.

A soft link is available in /usr/share/maven. This is the link that points to one of the maven binaries. This is the place where you switch between versions of maven. You can remove the soft link and create one to the right maven home folder. A small catch is that you need to be root to remove and create the link. Using sudo is good enough.

The commands to do this are:

cd /usr/share
sudo rm maven
ln -s /usr/share/java/apache-maven-3.0.2 maven

So not a lot of work, but just annoying to do one or more times a day. Therefore I have wanted to have a bash script to do it for me.

Introducing bash

When automating something on the Mac I tend to use bash. I am not an expert, but using google I can do interesting things. I’ll step to the script. To start off, define the two maven installations that I currently use:

maven2=apache-maven-2.2.1
maven3=apache-maven-3.0.2

Next step is to remove the current soft link if it exists.

if [ -e /usr/share/maven ]
then
	sudo rm /usr/share/maven
fi

Next is to store the maven implementation version in a variable

maven=$maven3

if [ $# == 0 ]
then
	echo "No Arguments supplied, using default maven 3"
elif [ $1 == 2 ]
then
	maven=$maven2
else
	echo "Using the default maven setting, provided argument [$1] is not recognized"
fi

The default is maven 3, than we check if arguments are provided to the script. If no arguments are provided, we do nothing and use the default. if an argument is provided we check if it is 2. If so, we set maven 2 as the implementation. If something else than 2 is provided we take the default which is maven 3. The final step is to create the soft link again.

sudo ln -s /usr/share/java/$maven /usr/share/maven

Using spaces

One thing that took me a few moments to understand is the use of spaces within bash. maven=$maven2 is not the same as maven = $maven2

The complete script

#!/bin/bash
echo "Setting the maven implementation version"

maven2=apache-maven-2.2.1
maven3=apache-maven-3.0.2

if [ -e /usr/share/maven ]
then
	echo "Remove the maven soft link."
	sudo rm /usr/share/maven
else
	echo "Maven soft link could not be found."
fi

maven=$maven3

if [ $# == 0 ]
then
	echo "No Arguments supplied, using default maven 3"
elif [ $1 == 2 ]
then
	echo "Setting maven to use to maven 2"
	maven=$maven2
else
	echo "Using the default maven setting, provided argument [$1] is not recognized"
fi

echo "Creating new soft link to $maven"
sudo ln -s /usr/share/java/$maven /usr/share/maven

Room for improvement

It would be nice to do a scan of the directory /usr/share/java and provide you with options to select from. You could also select the most recent version of maven 2 or 3 or even 2.2 and 3.0. If I have a need for that I’ll update the script

Concluding

That is it, you now have a script that you can call with the implementation you want to set. I called mine setmaven.sh and you would call it like:

./setmaven.sh 2

You can check if it is working with the well known mvn –version command

Feel free to comment for improvements.

First the basics. If you want to try these examples yourself you need to request a key. More information can be found here:

http://open.nos.nl/

Because groovy is a very nice language to do this kind of experimentation I’ll show you de groovy code first. Just a few lines to print a JSON string:

def key = "Your Key"
nos = new RESTClient("http://open.nos.nl/v1/")
JSON newsItems = nos.get(path : "latest/article/key/$key/output/json/category/sport/").data
print newsItems

The result is a long string. If you want to convert a string to nice formatted json check the resources for a link. The following image gives you an idea of the structure of the returned JSON:

Now let us do the same thing in java. Usually this takes much more code. To be honest, it is not at all bad if you use the RESTTemplate of the Spring framework. Have a look at the following code:

public class SearchApiUsingSpring {
    public static void main(String[] args) {
        RestTemplate restTemplate = new RestTemplate();
        String result = restTemplate.getForObject("http://open.nos.nl/v1/latest/article/key/{key}/output/json/category/sport/",
                String.class, "YOUR KEY");
        System.out.println(result);
    }
}

Of course the result is the same, not bad is it? Just three lines of real code. Nice, but not enough for my example. Of course I want to use the result as an object. Therefore I am going to use an object mapper called Jackson. Check resources for a link. Jackson is a framework that enables us to map JSON objects to actual java objects. Based on the structure of the returned JSON I created a java object and used jackson annotations to map it to the JSON structure. The spring RESTTemplate facilitates using mappers. A Jackson mapper is available. The following code shows the improved sample.

public class SearchApiUsingSpring {
    public static void main(String[] args) {
        RestTemplate restTemplate = new RestTemplate();
        LatestArticle result = restTemplate.getForObject("http://open.nos.nl/v1/latest/article/key/{key}/output/json/category/sport/",
                LatestArticle.class, "Your Key");

        for (Article article : result.getItems().get(0)) {
            System.out.printf("Title : %s\n", article.getTitle());
            System.out.printf("Description : %s\n", article.getDescription());
            System.out.printf("Link : %s\n", article.getLink());
            System.out.println("_________________________________");
        }
    }
}

Just a very small difference, besides the printing stuff. The change is the type returned by the getForObject method. Now it is not a string anymore but a LatestArticle. To be able to use Jackson you do need to create the classes with a few annotations.

@JsonIgnoreProperties(ignoreUnknown = true)
public class LatestArticle {
    @JsonProperty("latest_article")
    private ArrayList<ArrayList<Article>> items = new ArrayList<ArrayList<Article>>();

	// getters and setters
}

@JsonIgnoreProperties(ignoreUnknown = true)
public class Article {
    private String id;
    private String type;
    private String title;
    private String description;
    private String link;

	// getters and setters
}

I use the annotation @JsonIgnoreProperties, I do not want to break my code if a property that is available in json is not available in my java class. I’ll remove it later on when I have all the properties mapped. Why not immediately? Well I want to explain what I did with the date fields first. Mapping a date is a bit different. We do need to map the date using the specific format. I include Joda time to the path and create a synchronizer for a Joda date time object. Jackson has support for joda time out of the box. But I used a different format and therefore I had to create my own. The class Article is slightly enhanced with a DateTime property called published. I only show the setter this time. This is where we have to assign our own deserializer. The code for my deserializer is also shown.

// from Article
    @JsonDeserialize(using = JsonDateDeserializer.class)
    public void setPublished(DateTime published) {
        this.published = published;
    }

public class JsonDateDeserializer extends JsonDeserializer<DateTime> {
    private final DateTimeFormatter formatter = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss");

    @Override
    public DateTime deserialize(JsonParser jp, DeserializationContext ctxt) throws IOException, JsonProcessingException {
        return formatter.parseDateTime(jp.getText());
    }
}

Now we can also print the published date. Be sure not to put annotations on the field and on the setter. I had the problem with the last_update, I need JsonProperty annotation. First I put it on the field, but than the JsonDeserialize was not read anymore.

That is it for now, I will write more when I am ready. Than I will also publish the code. Some of the resources that were useful to me are written down below.

Resources

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/remoting.html#rest-resttemplate

http://jackson.codehaus.org/

http://jsonviewer.stack.hu/

http://java.dzone.com/articles/how-serialize-javautildate

You can find the complete book review on this page: OSGi and Apache Felix 3.0 Beginner’s Guide

Introduction

Spring mobile has it’s own home, you can find the homepage here. The project has a sample project as well. So why did I write this blog? Just to understand the project better and see how it fits in my personal projects. Maybe others will get a better understanding as well by reading this blog. Let me know if you find something interesting or have some improvements.

The sourcecode is available at Github : http://github.com/jettro/GridshoreSamples.git

The sample

I wanted to keep the sample as simple as possible to show how spring-mobile works. The sample must be complete enough to be able to explain the features that are important. Therefore I do not really create a functional thing. Just one page that shows whether you are using a mobile browser and some information about the browser you are using.

Simulation mobile platforms

Within Safari it is easy to pretend you are using another client than the safari browser that is installed. Use the developer menu bar item. Look at the following screendump.

How does it work?

To understand how the resolvers can do what they do, resolve the client and learn about it capabilities, you need to know a bit about an html request. I take it that all the readers of my blog have the basic understanding of a html request header. Each request has a body and a header. The header contains some meta data about the client. To get the basic understanding, look at the code of the LiteDeviceResolver. This resolver uses a few items from the header like User-Agent, OperaMini and wap support to determine if a client is a mobile client. The class has a number of keywords that it checks for presence in the User-Agent string. In our case using the iPhone browser, there would be a match for the keyword phone.

Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7

Building the application

I use gradle to build the sample. Using the intellij and jetty plugin, gradle works like a charm. I do not want to go into to much details about gradle. You can find the file in the provided git repository.

Most important thing for the build configuration are the dependencies for spring mobile and an important library I use, wurfl. More on that later.


compile "org.springframework.mobile:spring-mobile-device:1.0.0.M1"
runtime "net.sourceforge.wurfl:wurfl:1.2"


Spring mobile configuration

Spring mobile is about resolving the client or device used to send a request. Therefore configuring spring-mobile is about configuring the device resolver. There are two options. The default makes use of the LiteDeviceResolver. The second option makes use of the WurflDeviceResolver. More on these resolvers follows. For both configurations you just need one bean. The following code blocks show both cases.

    <mvc:interceptors>
        <bean class="org.springframework.mobile.device.mvc.DeviceResolvingHandlerInterceptor"/>
    </mvc:interceptors>

    <mvc:interceptors>
        <bean class="org.springframework.mobile.device.mvc.DeviceResolvingHandlerInterceptor">
            <constructor-arg>
                <device:wurfl-device-resolver root-location="/WEB-INF/wurfl/wurfl-2.0.25.zip"/>
            </constructor-arg>
        </bean>
    </mvc:interceptors>

That is most of it already. Now you can resolve the different devices. There is one more thing if you want to actually do something with a the obtained device information. You might want to inject the Device into the Controller. From the reference documentation I copied the following class that registers WebArgumentResolver with the controller invocation. I do not really understand why this is not available as a provided bean. I think this will come, or maybe I misunderstood something. For completeness I’ll show you the code as well.

CustomWebArgumentResolverInstaller

@Component
public class CustomWebArgumentResolverInstaller {
    @Autowired
    public CustomWebArgumentResolverInstaller(AnnotationMethodHandlerAdapter controllerInvoker) {
        WebArgumentResolver[] resolvers = new WebArgumentResolver[1];
        resolvers[0] = new DeviceWebArgumentResolver();
        controllerInvoker.setCustomArgumentResolvers(resolvers);
    }
}

Device resolvers

Device resolvers use headers from the request to determine the Browser. The LiteDeviceResolver and with it the LiteDevice are created using the device resolving technique as copied from wordpress. It does not expose any capabilities of a mobile device, just that you are dealing with a mobile device.

The Device interface only exposes the isMobile method. You can also use the toString method. The following jsp shows some very basic lines of text.

<p>Is Mobile : <c:out value="${device.mobile}"/></p>
<p>Device:</p>
<c:out value="${device}"/>

Spring mobile comes out of the box with support for wurfl, to be honest, I had never heard of it before. But it is a pretty extensive library that knows about a lot of phones and other mobile devices. It knows a lot more about the capabilities of your devise than the default LiteDevice. Spring mobile also provides namespace support for other device resolving strategies. The wurfl device resolver has the option to supply the data in a zip file and a patch in an xml file. The following image shows you part of the toString output of the same jsp. I did not use the patch functionality.

The WurflDevice implementation exposes a lot more properties. You can ask for all capabilities and the markup. The following jsp code is used to show additional information.

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core_rt" %>
<p>Is Mobile : <c:out value="${device.mobile}"/></p>
<h2>Basic Device info</h2>
<table>
    <tr>
        <td>id</td>
        <td><c:out value="${device.id}"/></td>
    </tr>
    <tr>
        <td>UserAgent</td>
        <td><c:out value="${device.userAgent}"/></td>
    </tr>
    <tr>
        <td>MarkUp</td>
        <td><c:out value="${device.markUp}"/></td>
    </tr>
</table>
<h2>Capabilities</h2>
<table>
    <tr>
        <th>key</th>
        <th>value</th>
    </tr>
    <c:forEach var="item" items="${device.capabilities}">
        <tr>
            <td><c:out value="${item.key}"/></td>
            <td><c:out value="${item.value}"/></td>
        </tr>
    </c:forEach>
</table>

The screen than looks like this

iPad and other mobile devices with big screens

Some time a go I wanted to browse to the website of Schradinova using my iPad. I was redirected to the mobile website, but the mobile website was not available yet. There was no way to go to the actual site. By now the mobile site works, but still I cannot go to the original website using the iPad. Therefore I want to present the option to the user to explicitly go to the mobile site or to the normal site.

One way to accomplish this is by providing a mechanism to read a request parameter before doing the client resolving. Therefore I go back to my most simple example of showing the toString of the device. I have created a subclass of the spring provided DeviceResolvingHandlerInterceptor. My interceptor looks for the request param mobile. If found a dummy device is created with the isMobile method implemented. Might not be the nicest solution, but it does show the possibilities. The next code block shows the new HandlerInterceptor and the dummy device which is a direct copy of the LiteDevice.

public class WithOverruleDeviceResolvingHandlerInterceptor extends DeviceResolvingHandlerInterceptor {
    public static final String mobile = "mobile";

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if (null != request.getParameter(mobile)) {
            boolean mobileOverruled = Boolean.parseBoolean(request.getParameter(mobile));
            Device overruledDevice;
            if (mobileOverruled) {
                overruledDevice = DummyDevice.MOBILE_INSTANCE;
            } else {
                overruledDevice = DummyDevice.NOT_MOBILE_INSTANCE;
            }
            request.setAttribute(CURRENT_DEVICE_ATTRIBUTE, overruledDevice);
            return true;
        } else {
            return super.preHandle(request, response, handler);
        }
    }
}

public class DummyDevice implements Device {

    public static final DummyDevice MOBILE_INSTANCE = new DummyDevice(true);

    public static final DummyDevice NOT_MOBILE_INSTANCE = new DummyDevice(false);

    public boolean isMobile() {
        return mobile;
    }

    public String toString() {
        StringBuilder builder = new StringBuilder();
        builder.append("[DummyDevice ");
        builder.append("mobile").append("=").append(isMobile());
        builder.append("]");
        return builder.toString();
    }

    private final boolean mobile;

    /**
     * Creates a GenericDevice.
     */
    private DummyDevice(boolean mobile) {
        this.mobile = mobile;
    }
}

I also add a link to the page to go to the mobile or the normal equivalent of the page. The following screendumps give you the different options using a mobile browser, a normal browser and using the explicit request for a mobile site or the normal site.

We start with the normal browser doing a normal request. Than we push the mobile link and after that the normal link. Look at the url bar, the is mobile and the first part of the description. Without an explicit preferred site it will show LiteDevice, in the other case it shows DummyDevice. Now three screendumps.

If you really want to see it work for a mobile browser I’d urge you to checkout the sample and try it yourself

Last remarks

Well, that is it. You should be capable now of creating your own mobile site. Finally I want to mention that spring mobile also has an option to redirect a user with a mobile browser to a completely different site. Check the reference manual to see how that works.

If you got this far, thanks for reading. See you next time.

If you want to use this for your project have a look at the greenhouse project of springsource. They have created some nice abstractions over multiple social websites. This blog is just to help you understand the mechanism behind it and the way it is implemented in the spring-social project.

What are we going to create?

We are going to create a sample with which you can authenticate against linkedin and print all your contacts and some data about your public profile. Linkedin uses OAuth and the sample will contain the OAuth authentication using the components as provided by the spring-social project.

Introduction to OAuth

So what is up with this OAuth. In just a few words, it is an authentication service. As an application you forward a visitor to the authentication service. The visitor authenticates itself and your application receives the result using a callback. If the result is positive, the visitor has authorized your application to act on the behalf of the visitor. That way you can use services of the provider without knowing who you are dealing with. It is also possible to store the provided authentication for future use. That is what the greenhouse application does, in this sample we ask for the authentication each new session.

There are some very good resources for learning about OAuth. So if you want to know what OAuth really is about and how it works I urge you to check the following links.

• http://thinkvitamin.com/code/introduction-to-oauth/
• http://static.springsource.org/spring-security/oauth/

Linkedin API

Linkedin provides OAuth authentication. They have written a good manual about using linkedin OAuth for authentication and the way linkedin requires authorization to get to the users data. I especially like the image they have created to show how this process works

Let us have a look at the basic steps needed to get some data from linkedin. If they are not clear, check the code later on. I think you can follow along easily.

• Request a api key and secret using your linkedin profile on this page: https://www.linkedin.com/secure/developer.
• In your application, redirect user to the authentication page and provide your api key.
• User authenticates himself on the linkedin website.
• If not done before, user needs to authorize the application to act on behalf of him.
• User gets redirected to your site with a request token and a verification code
• Obtain an access token using the request token and the verification code.
• Start interacting with linkedin using your api key and the obtained access token.

That is about it

Spring-social

What is this spring-social. It is a new project that recently published M1. It provides support to interact with multiple social websites through a consitent api. There are integrations for Linkedin, Twitter, FaceBook and TripIt. There is a blog post from Craig Walls, one of the creators, that gives more details.

Show me the code

Finally, let us have a look at the code. You can find the code through github. It is a very basic spring mvc application. The most interesting part is within the class nl.gridshore.samples.springoauth.web.ConnectController.In the next code blocks I show you the methods that handle all the different stages of getting data from linkedin. Let us start by checking if the user is already connected to linked in or not.

@RequestMapping(value = "linkedin", method = RequestMethod.GET)
public String showConnectLinkedin(WebRequest request) {
    Token accessToken = obtainAccessTokenFromSession(request);
    if (accessToken == null) {
        return "connect/linkedin_connect";
    } else {
        return "connect/linkedin_connected";
    }
}
private Token obtainAccessTokenFromSession(WebRequest request) {
    return (Token) request.getAttribute(OAUTH_ACCESS_TOKEN_ATTRIBUTE, WebRequest.SCOPE_SESSION);
}

If you are authenticated with linkedin, the access token is stored in the session. Therefore we check for availability of this token in the session to determine if we need to show the page with the redirect to linkedin or the page with the options you have to ask linkedin for information. For now we assume that the user is not authenticated yet and he pushes the button to authenticate with linkedin. The form post is received by the following method.

@RequestMapping(value = "linkedin", method = RequestMethod.POST)
public String requestConnectionLinkedin(WebRequest request) {
    Token requestToken = getOAuthService().getRequestToken();
    request.setAttribute(OAUTH_REQUEST_TOKEN_ATTRIBUTE, requestToken, WebRequest.SCOPE_SESSION);
    return "redirect:" + "https://www.linkedin.com/uas/oauth/authorize?oauth_token=" + requestToken.getToken();
}

private OAuthService getOAuthService() {
    OAuthConfig config = new OAuthConfig();
    config.setRequestTokenEndpoint("https://api.linkedin.com/uas/oauth/requestToken");
    config.setAccessTokenEndpoint("https://api.linkedin.com/uas/oauth/accessToken");
    config.setAccessTokenVerb(Verb.POST);
    config.setRequestTokenVerb(Verb.POST);
    config.setApiKey(apiKey);
    config.setApiSecret(apiSecret);
    config.setCallback(callbackUrl);

    return new OAuth10aServiceImpl(
            new HMACSha1SignatureService(),
            new TimestampServiceImpl(),
            new BaseStringExtractorImpl(),
            new HeaderExtractorImpl(),
            new TokenExtractorImpl(),
            new TokenExtractorImpl(),
            config);
}

The code shows we need to create an OAuthCOnfig object using the applications api key and secret and the callback url. Using this service you can generate a request token. This token is provided to linkedin using the redirect service. Now the user does his thing in linkedin and he should see a screen like this:

If the user pushes the “ok, I’ll allow it button”, we get the request token back together with a verification number to the url as provided by the callback url. The following code shows the receiving method.

    @RequestMapping(value = "linkedin", method = RequestMethod.GET, params = "oauth_token")
    public String authorizeCallback(@RequestParam(value = "oauth_verifier", defaultValue = "verifier") String verifier,
                                    WebRequest request) {
        Token requestToken = obtainRequestTokenFromSession(request);
        Token accessToken = getOAuthService().getAccessToken(requestToken, new Verifier(verifier));
        request.setAttribute(OAUTH_ACCESS_TOKEN_ATTRIBUTE, accessToken, WebRequest.SCOPE_SESSION);
        return "redirect:linkedin";

    }

As you can see we obtain the request token from the session. Using this request token and the received verification code we obtain the access token. This access token is then used for all calls to linkedin. That is shown in the following code block to obtain all connections of the authenticated user.

@RequestMapping(value = "linkedin/connections", method = RequestMethod.GET)
public String connections(WebRequest request) {
    LinkedInTemplate template = createLinkedInTemplate(request);
    List<LinkedInProfile> connections = template.getConnections();
    request.setAttribute("connections", connections, WebRequest.SCOPE_REQUEST);
    return "connections";
}

Summary

Pretty amazing that it takes only this amount of lines of code to communicate with a service like linkedin. I like it. I personally like the abstraction as used within the greenhouse application from springsource better than doing this stuff yourself. Still it does give you some insights into the way social integration works.