Thursday, October 24, 2013

Openfire Plugin Dev / Customization

Openfire Plugin Dev / Customization

Now that I have openfire up and running... the next thing I want to do is to customize it to my needs. The normal way to extend openfire is by way of plugin. This allows you to enjoy future upgrades of openfire while not blowing away your source code additions. Admittedly it took a little more digging that I would have liked to find the right getting started guide.

Im my case I decided to go with using eclipse (Scala IDE). Originally I had hopes of writing my plugins in scala.. but ran into a number of problems there, so in the interest of time decided to continue forward with eclipse java. The first guide you should look at to get setup in eclipse is the following doc. Once you have that setup you may want to look at this one as well regarding building all the plugins.

One of the other things that you will notice is the ability to customize the data storage. The architecture here was really focused on JDBC and a SQL back-end... In my case I am using a graph database store so none of this helps me. Looking a little further into it and seems that replacing the JDBC provider with a custom implementation would not take to long ref here. However in the interest of time I have put it on the list of TODO: and forged ahead. There is however a method that will get us partly there. I will outline the goals and methods for achieving them in the following paragraphs

Goals

The idea here is that I would like to replace the "user" and "roster" aka "buddy" list of openfire with my own graphdb full of FOAF like relations. The next thing is I don't want to be slowed down at this stage in dev... so it is ok to leave some "hacks" in the interest of time and then circle back.

Method

In browsing the Plugins I noticed the "userservice". Here is a bit of text right out of the README

The User Service Plugin provides the ability to add,edit,delete users and manage their rosters by sending an http request to the server. It is intended to be used by applications automating the user administration process. This plugin's functionality is useful for applications that need to administer users outside of the Openfire admin console. An example of such an application might be a live sports reporting application that uses XMPP as its transport, and creates/deletes users according to the receipt, or non receipt, of a subscription fee. 


Perfect... this solves our quick and dirty way of getting our users into the system. Next we just need to deal with the roster... so that we get the proper "presence" requests for users coming on and offline.

Again a bit of digging lead me to the creation of a Custom Roster Item Provider. Here is the documentation that describes how to implement.

With not a ton of code, I was able to write a simple Roster Provider that calls my Scala Play webservice. The webservice of course is a REST Json service wrapper for all the good things stored in the graphdb :)

Few last points

In order to get things to work correctly I had to return roster items using the constructor that takes a domain (for example: jid@mydomain.com). But when creating that user inside open fire we only want to pass in the "jid" portion for the user name. Failing this the two ends will not be linked how you would expect them to be.

No comments:

Post a Comment