MSG Source Code Overview

The following sections are just a brief summary of some of the main files and classes, but they are a good starting point if you are looking at the code for the first time.


All interactions with buddyxml pass through this class, so it’s a good place to start. One instance of CommandProcessor is created for each tomcat session. This is the only object instance that buddyxml stores within a tomcat session. (Note that the CommandProcessor object is not currently serializable, so sessions can not be transferred between tomcat servers)

BuddyXMLServlet creates an XML document object for each transaction, the document is populated with information by CommandProcessor. The final part of each transaction serializes the XML document (or converts it to JSON encoding) for output in the HTTP response.

The set of commands supported by CommandProcessor is calculated by using java reflection to enumerate the methods of interface InstantMessagingClient.  Commands are processed by calling methods of an implementation of InstantMessagingClient. The method called is the one matches the value specified for the command argument in the request URL.  The only implementation of InstantMessagingCient currently used is class JabberInstantMessagingClient. This is the default client class, but a different implementation can be specified using the request URL parameter client set to the full class name.

This is the default implementation of interface InstantMessagingClient. This class opens and maintains Jabber/XMPP client connection to a Jabber Server.  Basically it translates BuddyXML commands into XMPP, and builds the XML document response that is returned by BuddyXMLServlet.


The ‘authenticate’ method of this class is called whenever a user logs in to the Openfire server. This is where replication of externally provided users and groups is initiated.

The ‘loadUser’ method of this class calls is called whenever a User object is required which maps to the passed in username. For most purposes, replicated users are treated that same as other local Openfire users, so the only purpose of the method is to provide the mapping between authenticed username, and the username that was actually created for that user by the replication process.

Wildfire User Web Admin

This class contains the ‘core’ functionality of the plugin that is used to drive the user interface of the JSP pages listed below.

The plugin configuration accessed from the Openfire admin console

User login page. Also allows password reset request via email.

Allows user to set password policy and to set local password.

Displays current user profile inclusing group membership

Allows the user to display/edit membership a Openfire group

Allows group admins to create new users.

Wildfire Mashup

This class contains the ‘core’ functionality of the plugin.

The plugin configuration accessed from the Openfire admin console

MSG Client

  • Detects if you are logged in via buddyxml.
  • Allows user to enter username/password/host and login to a jabber server.
  • Launchs MSG in an 'undecorated' browser window.
  • Builds and displays the user's roster.
  • Dynamically updates presence states of users.
  • Notification when incomming chat messages arrive.
  • Dispatches chat messages to chat windows.
  • User interface for a chat conversation.
  • Notifies user if chat arrives from another user.
  • JavaScript functions for handing AJAX http requests.
  • JavaScript functions and objects for rendering and updating the contacts window DOM.