What's happening here?

If you look through the web.xml file you'll see that there is one servlet handling the app. Looking at the HelloWorld servlet, you'll see that it determines the handset and device based on the request details and then routes the request to the appropriate JSP. The web.xml file also explains that there is a context listener set up from Spring, which then reads in details from the wurfl-default-ctx.xml file. This file, also under WEB-INF, is a regular spring configuration file that instantiates and loads a number of beans used by Wurlf. This is all explained nicely on the Wurfl page explaining the new Java API, so do take the time to look through it more closely to see what's possible.

Wurfl and the Spring Travelagent

We can now use this simple setup to add Wurfl to our travelagent example. In order to ensure that nothing happens to your working example, I'd suggest that you copy the working version and rename the copy to 'spring-travelagent-wurfl', which is what I did. Then you can import the project into Eclipse and edit the build.xml file to change the project name so that you know which app is being loaded into tomcat. Do remember to remove the current travelagent deployed to tomcat so that your reading of the console logs doesn't get too confusing.

Make sure that this version runs ok so that we have a baseline to work from in case any thing goes wrong along the way.

Add the Wurfl jars and config files to the project

Before we go too far we need to add in the Wurfl details to the project so that they are smoothly added as imports when we get to the coding part of the process.

First, we need to copy a number of jars to the WEB-INF/lib directory of our project. You can copy all of the jars across except for spring-aop-2.5.6 and spring-beans-2.5.6 jars, which we have already included as part of the spring.jar in our project.

Second, we need to put the xml configuration details of Wurfl. However, to ensure that our current web.xml file is kept intact, rename it to web-orig.xml. Now, copy all of the xml files from the WEB-INF directory of the helloworld app, and paste them into the WEB-INF directory of our modified travelagent app. Do the same for the wurfl.zip. Do the same for the files in the WEB-INF/tld folder too.

Third, rename the current web.xml file to web-wurfl.xml, and change the web-orig.xml file back to web.xml. A pain, I know, but it keeps the process clean as to which one we're using and want to change.

That will do for now and we'll configure the files after we add the new code to the application.

Add two new service classes to handle Wurfl

We'll use code inspired by the example from IllegalArgumentException about using Wurfl as the basis for our own code. The code there is simple, as is ours, but we put in a little more to get more details back about the device. Create a new class called MobileServiceManager in the travelagent.service package and put this code into the class.

import javax.servlet.http.HttpServletRequest;

import net.sourceforge.wurfl.core.Device;
import net.sourceforge.wurfl.core.WURFLManager;
import org.apache.commons.lang.StringUtils;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class MobileServiceManager implements MobileService {
    @Autowired
    private WURFLManager wurflManager;
   
    protected final Log logger = LogFactory.getLog(getClass());
  
    public boolean isMobile(HttpServletRequest request) {
         boolean isMobile = false;
         String element = request.getHeader("user-agent");
         logger.info("user-agent: " + element);
         if (element != null) {
             
        Device device = wurflManager.getDeviceForRequest(request);
      
        String mobileBrowser = device.getCapability("mobile_browser");
       if(mobileBrowser != null) {
           isMobile = true;
       }
           
        }
       // return StringUtils.isNotBlank(mobileBrowser);
         return isMobile;
    }
   public Device getDevice(HttpServletRequest request) {
         Device device = wurflManager.getDeviceForRequest(request);
        return device;
       
    }
}

This should all work ok, you may need to add some import statements. You will also need to let Eclipse create an interface of MobileService for you, which you can then complete by putting in the isMobile and getDevice methods.

Integrate new classes into CruiseController

We can now use the new service in our app by calling the MobileServiceManager from the CruiseController and passing the details onto the JSP view. This code will allow us to check whether we've a mobile client, and if so, then return the correct device for inclusion as an attribute to be used by the view. The new code is in bold.

 public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
       
         logger.info("cc: user-agent: " + request.getHeader("user-agent"));
         MobileServiceManager msm = new MobileServiceManager();
         Device device = null;
         boolean myDevice = msm.isMobile(request);
         if (myDevice == true) {
             device = msm.getDevice(request);
         }
        logger.info("Returning cruise view");
        Map<String, Object> myModel = new HashMap<String, Object>();
        myModel.put("cruises", this.cruiseManager.getCruises());
        myModel.put("device", device);
        return new ModelAndView("cruise", "model", myModel);
    }

Inside of the cruise.jsp file we can add a few lines to display the device details like this:

<h3>Some mobile values</h3>
<p>Device: <%=((Device)request.getAttribute("device")).getId() %></p>

We also need to add an import statement to the @page declaration for import="net.sourceforge.wurfl.core.Device".

Modify the web.xml file

The next step is to modify the web.xml file so that we tell it about Wurfl. Open the file for editing. Also open up the web-wurfl.xml file, which is the one we used for wurfl-helloworld as it has some code we need to copy into the web.xml file that we'll use for this application.

Wurfl needs to get some values from the request objects, and then hand them off to the MobileServiceManager so that it can determine the handset being used. Therefore we need to use the HelloWorld servlet in our application.

First, copy these details into the web.xml file from the web-wurfl.xml file.

<servlet>
        <servlet-name>HelloWorldServlet</servlet-name>
        <servlet-class>net.sourceforge.wurfl.core.example.HelloWorld</servlet-class>
       
        <!-- Default value -->
        <!--
        <init-param>
            <param-name>wurflHolderKey</param-name>
            <param-value>net.sourceforge.wurfl.core.WURFLHolder</param-value>
        </init-param>
         -->
    </servlet>

Second, change the name from HelloWorldServlet to 'hello' as it will run alongside the DispatcherServlet currently in use by our application. What we want to do is have all requests first go to the HelloWorldServlet, and then be passed onto the DispatcherServlet. This means we need to have two servlet-mappings for our application. Copy the declaration of the <servlet-mapping> for the travelagent so that it appears twice. Change the mapping of the servlet that goes to *.htm to be the 'hello' servlet, and change the mapping for the travelagent to *.do. This will allow us to reroute requests to the DispatcherServlet without any problems. The two servlets should now look like this:

Third, copy the <context-param> statement from web-wurfl.xml to web.xml. This points to another xml file, which is used by Spring to instantiate and load the beans used by Wurfl for our application.Then add two more file declarations to the statement so that it looks like this:

Fourth,copy the three different <taglib> declarations from web-wurfl.xml to web.xml.

Modify the travelagent-servlet.xml file

We need to make a slight change to the travelagent-servlet.xml file so that we can call the DispatcherServlet from the HelloWorldServlet after Wurfl's done its device detection. In the past the file extensions used were .htm so we sent the requests to /cruise.htm and /cruisesearch.htm. This won't work any more, and if you do use them, you'll create an endless loop when you request one of those pages as tomcat routes between the two servlets in a neverending loop. While that may be interesting to see now and again, it's not what you want your web app to do. So change the extention to .do for both. Now your beans should be names /cruise.do and /cruisesearch.do as is consistent with what we set in place for the web.xml file.

Integrate the HelloWorld Servlet

We now need to integrate the HelloWorld servlet into our application so that it replaces the functionality of the DispatcherServlet we previously used.

First, copy the package and the class and paste it into the packages in our current project.

Second, open the file for editing as we don't want it to do anything except forward requests as appropriate. Comment out the lines checking for the MarkUp, and the line request.getRequestDispatcher....

Third, copy the request.getRequestDispatcher line and past it after itself. Then change it to point to your cruise.do file instead of the location on the line above. Yes, this will mean we don't go to any other page, but you'll get the idea of how this works. It should now look like this:

    request.getRequestDispatcher("cruise.do").forward(request,response);

With this in place we now route the request back to the CruiseController and return pages as expected.

Beyond the basics

Ok, yes, this is incomplete. In order for this work fully we need to make a few more changes.

First, we need to have HelloWorld check for all destination requests, and not just, as now send everything to the one page.

Second, we need to consider whether we need to have anything special done with the navigation and views of the pages determined to be mobile. So far we've not done this, but we now have a framework in place to handle this and could use screensize, colours, etc to determine which view a request received. You'll find more about this in the dotMobi Developer's Guide. You can also find some good discussions on this at the Little Spring Design blog and the Design4Mobile site they maintain.