Child pages
  • Providing your own data service implementation

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

In this session I will show how to implement the following Shindig services to connect your own datastore.


During my first steps I have created another sample implementation where all the social data is held in memory. It's just another sample, but I think it is perfect for debugging reasons, because you can any time inspect your whole data at once.


The full code is available as attachement ( to this site.

1. Make an implementation for all three interfaces

No Format
public Future<Person> getPerson(UserId id, Set<String> fields, SecurityToken token) throws SocialSpiException {
  if (id != null) {
    Person currentPerson = db.findPerson(id.getUserId(token));
    if (currentPerson != null) {
      return ImmediateFuture.newInstance(currentPerson);
  throw new SocialSpiException(ResponseError.BAD_REQUEST, "Person not found");

Snippet of

This implementation looks similiar to the sample implementation provided with Shindig. The big difference is, that the db instance is a instance of a class that holds the data in memory.

No Format
public class ShindigIntegratorPersistenceAdapter {

private Map<String, Person> persons;.
private void init() {
  if (persons == null) {
    // create personlist
    persons = new HashMap<String, Person>();

    Name name = new NameImpl();
    name.setFormatted("James Bond");
    Person john = new PersonImpl("john.doe", "007", name);
    persons.put(john.getId(), john);
public Person findPerson(String id) {
  Person person = persons.get(id);
  return person;

Snippet of

2. Register these classes in your own guice module

No Format
protected void configure() {



  bind(new TypeLiteral<List<AuthenticationHandler>>(){}).toProvider(

Snippet of

This class binds the Shindig services to the new implementations. So they will be called instead of the sample coming with Shindig. Another way to tell Shindig which implementation to use is to change the @ImplementedBy annotation in for example PersonService.class. But to me the binding solution sounds better.

For unit tests I have registered the classes in a guice module specifically for unit tests. This is done the same way as in the upper guice module.

In the unit test itself this modul has to be called on setup. In the test methods the service can then be used directly.

No Format
public void setUp() throws Exception {
  Injector injector = Guice.createInjector(new ShindigIntegratorTestsGuiceModule());
  personService = injector.getInstance(ShindigIntegratorPersonService.class);
 * Tests getPerson with a UserId typed as Userid. The Id string is set in the UserId.
 * @throws Exception
public void testGetExpectedPersonByUserId() throws Exception {
  Future<Person> selectedObject = personService.getPerson(JOHN_DOE, Collections.<String> emptySet(),
    new FakeGadgetToken());
  Person person = selectedObject.get();
  assertEquals(JOHN_DOE.getUserId(), person.getId());

Snippet of ShindigIntegratorPersonServiceTest.class

3. Register the guice module in the web.xml

In the web.xml the param guice-modules has to be changed to reference the new implementation.

No Format

Snippet of web.xml

There are several web.xml files in the shindig installation. Comments in the web.xml files indicate what they're for:

  • web.gadgets.xml: just the gadget rendering server
  • just the social data / RESTful server
  • web.full.xml: both servers in a single container

4. Rebuild Shindig and you are ready

After all maven has to be run with a clean install and things are done.

After this you can run the samplecontainer as before. Just things like a dump in the samplecontainer page doesn't work as I did not implement it.


This documentation shows how to implement the interfaces for Shindig. Next step would be to connect to a real database.

I think Implementing this services is very straightforward. The hardest thing is to get familiarized with Shindig.