After a great suggestion from a colleague I was inspired to create what I think is an under-used utility.  That utility is an Instant Messaging Bot.  I know they seem dated, and harken back to the days of AIM bots, but in this world of rapid publishing and communications I think they’re an under utilized tool.  This post is meant to highlight the use of two technologies: Java, and Openfire.

The Technology

Openfire is an open-source Jabber(XMPP) server.  The installation is quite simple, the only thing that is required is a JRE, and if you would like, a MySQL database.  In my installation I have installed Openfire on Ubuntu JeOS that has the sun-java6-jdk and mysqld-server packages installed.  Openfire is distributed as a debian package, so installation is a breeze.  You can read more here on how to install, this post will assume you have a working server and a Java development environment…with maven.

The Application

We want our application to login to the Jabber server, and listen for messages bound for the bot user.  Once a message is received it should be checked for a command, and a proper response should be sent back to the user.  In order to accomplish this we need three classes.  One class will handle logging into the Jabber server and beginning to listen for chat messages.  The other class will be invoked when a chat is initiated, and the other will handle messages sent in that chat session.

Smack is the client library that we will use for this project and can be download from the same site that you downloaded Openfire from.  Smack includes the two interfaces we will use for the class that listens for chat requests, and handles chat messages.  These interfaces are ChatManagerListener, and MessageListener.

The Code

We’ll start by adding our dependency for the Smack client library:

<dependency>
  <groupId>jivesoftware</groupId>
  <artifactId>smack</artifactId>
  <version>3.0.4</version>
</dependency>

Now that we have the necessary dependency we can focus on our three classes. We will start with our App class. This class as stated before is responsible for connecting to the Openfire server. Here is the App.java class.

public class App {
  public static void main(String[] args) {
    // Assumes you have the SRV records setup in DNS
    XMPPConnection conn = new XMPPConnection("yourdomain.com");
    try {
      conn.connect();
      conn.login("IM_BOT", "Your Bot Password");
      ChatManager chatManager = conn.getChatManager();
      chatManager.addChatListener(new BotChatListener());

      System.out.println("Connected");
      while (conn.isConnected()) {
        try {
          Thread.sleep(1000);
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
      }
      conn.disconnect();
    } catch (XMPPException e) {
      e.printStackTrace();
    }
  }
}

Our next class is the class responsible for listening and handling incoming chat requests and adding a message listener to the new chat. Here is the BotChatListener.java class.

public class BotChatListener implements ChatManagerListener {

  public void chatCreated(Chat chat, boolean local) {
	  chat.addMessageListener(new BotMessageListener());
  }
}

The MessageListener referred to in the BotChatListener is responsible for handling commands passed to the bot and responding to them appropriately. Here is the BotMessageListener.java class.

public class BotMessageListener implements MessageListener {

  public void processMessage(Chat chat, Message message) {
    System.out.println(chat.getParticipant() + " said -> "
        + message.getBody());
    Message botMessage = null;

    try {
      botMessage = new Message();
      if (message.getBody().equals("nothing")) {
        botMessage.setBody("Fine...");
      } else if (message.getBody().equals("make me toast")) {
        botMessage.setBody("Sure thing");
      } else {
        botMessage.setBody("What do you need?");
      }
      chat.sendMessage(botMessage);
    } catch (XMPPException e) {
      e.printStackTrace();
    }
  }
}

And that’s it…the next step is to extend the BotMessageListener class to do whatever it is you want to accomplish with your bot. If you wish, you can make a Ferris Bueller type bot, and use it to log into Google Talk with your Gmail account and respond to your co-workers messages while you’re out doing whatever it is that you do for fun.

If you are using lazy loading rather than eager loading for obvious reasons, and you’re trying to access associated objects in your view code, this error can be a bit difficult to resolve. Luckily there is the OpenSessionInViewInterceptor, or the OpenSessionInViewFilter. These solutions will keep the hibernate session open long enough for the view to render what is needed before it is closed, thus allowing you to access your lazy loaded associations without raising an exception. The detail of what this functionality provides can be found on the Hibernate website here.

Now, how does one get this to work in their application? Well, I’ve chosen to illustrate the basic steps necessary to implement the OpenSessionInViewInterceptor. You will need to modify 2 files. These being your applicationContext.xml, and YourApplication-servlet.xml files. We’ll start with the applicationContext.xml file. You will need to place the following snippet after you’ve defined your sessionFactory bean.

<bean id="openSessionInViewInterceptor"
    class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">
    <property name="sessionFactory">
        <ref local="sessionFactory"/>
    </property>
    <property> name="flushModeName">
        <value>FLUSH_AUTO</value>
    </property>
</bean>

What does the FLUSH_AUTO do? Here is a quote from the javadoc for the interceptor:

“This interceptor will by default not flush the Hibernate Session, with the flush mode being set to FlushMode.NEVER. It assumes that it will be used in combination with service layer transactions that handle the flushing: the active transaction manager will temporarily change the flush mode to FlushMode.AUTO during a read-write transaction, with the flush mode reset to FlushMode.NEVER at the end of each transaction.”

We use the FLUSH_AUTO to automatically flush the session in this case because I am not using transactions.
Now comes the edit to your YourApplication-servlet.xml file, or whatever file you’ve used to define your URL Mappings. Add the following snippet to your URL mapping bean.

<property name="interceptors">
  <list>
    <ref bean="openSessionInViewInterceptor" />
  </list>
</property>

And that’s that, redeploy and you will no longer see that dreaded exception.

Sitemesh Integration

What do you have to do to integrate Sitemesh with your newly created Spring application? Well, here is the list of prerequisites:

• Download Sitemesh from OpenSymphony.
• Build the sitemesh-2.x.jar using ant.
• Copy the sitemesh-2.x.jar to the WEB-INF/lib directory of your web application

Now we can move on to integrating Sitemesh into your web application. To use sitemesh with your application only 1 file needs to be edited amazingly enough. Open up your web.xml file and add this snippet:

<!-- Sitemesh -->
<filter>
	<filter-name>sitemesh</filter-name>
	<filter-class>
		com.opensymphony.module.sitemesh.filter.PageFilter
	</filter-class>
</filter>

<filter-mapping>
	<filter-name>sitemesh</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

So, now what? The next step is to setup the directory structure and files necessary to make things work. Refer to this page on the OpenSymphony site detailing the creation of your first decorator, and creating the WEB-INF/decorators.xml file. I’ve included a copy of my main.jsp file for reference:

<%@ taglib uri="http://www.opensymphony.com/sitemesh/decorator"
	prefix="decorator"%>
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags"%>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	<head>
		<title><spring:message code="application.title" /></title>
		<decorator:head />
		<%@ include file="/WEB-INF/view/includes/style.jsp"%>
		<%@ include file="/WEB-INF/view/includes/js.jsp"%>
	</head>
	<body>
		<div id="container">
			<%@ include file="/WEB-INF/view/includes/header.jsp"%>
			<div id="internalWrapper">
				<%@ include file="/WEB-INF/view/includes/links.jsp"%>
				<div id="content">
					<decorator:body />
				</div>
			</div>
			<%@ include file="/WEB-INF/view/includes/footer.jsp"%>
		</div>
	</body>
</html>

So, how do you get your Controllers to spit out decorated pages? Easy, just create a jsp that will be used as the content of the <decorator:body /> tag in the main.jsp file. When you’re returning your ModelAndView just refer to that jsp like the example below:

public ModelAndView list(HttpServletRequest request,
			HttpServletResponse response) throws Exception {
	List<DomainObject> userList = userService.findAll();
	request.setAttribute("userList", userList);
	return new ModelAndView("list.jsp", null);
}

Here is an example snippet of my url mapping for reference as to where the jsp is located:

<prop key="/users/*.html">userController</prop>

In this case my list.jsp is located in the users folder under my web root.

So, isn’t this easier than Tiles?

Part of the reason for this blog is to share information from developer to developer issues that I’ve encountered that have either been unable or too busy to find solutions to. In this case my solution is to let the reader know that the best bet client to use when consuming RoR web services in Java is Apache Axis. If anyone would enjoy a code example or two I’d be glad to oblige…although the artifacts generated by Axis 1.4 are fairly involved, the process is fairly easy especially when using the SoapUI tool to generate the artifacts based on the RoR WSDL e.g. http://localhost:3000/web_service_name/service.wsdl .