Butter Dev Logo
Search:   

February 20, 2008

DWR 2.0.x, Spring 2.x, with Spring MVC

If you are using DWR 2.0.x, Spring 2.x, with Spring MVC, dwr.xml is not required. You can use the new DWR namespace feature in your Spring xml.

This page assumes you know how to use Spring MVC, you have a Spring Dispatcher Servlet mapped (dwrSampleApp), and you are ready to integrate Spring with DWR. I strongly encourage you to have a working configuration before attempting to integrate DWR.

You can download the files from this article here. This includes all the source, configuration, and a ready to run web-app.

Step 1: Web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
  http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">
  <servlet>
    <servlet-name>dwrSampleApp</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
      <param-name>contextConfigLocation</param-name>
      <param-value> classpath:dwrSampleApp.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>dwrSampleApp</servlet-name>
    <url-pattern>*.html</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>dwrSampleApp</servlet-name>
    <url-pattern>/dwr/*</url-pattern>
  </servlet-mapping>
</web-app> 

We have added two mappings to the Dispatcher Servlet (*.html and /dwr/*). The problem with the “*.html” mapping alone is that it will not handle all of the DWR requests (described in the next section ‘Spring Application Context’). So, depending on how you have your mappings configured the /dwr/* mapping will or will not be necessary. The key thing to remember is that DWR requests need to be mapped to the configured DispatcherServlet.

Step 2: Spring xml/Application Context (for this example, dwrSampleApp.xml)

  1. Add the DWR namespace declarations to dwrSampleApp.xml:
    <beans
      xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:dwr="http://www.directwebremoting.org/schema/spring-dwr"
      xsi:schemaLocation="http://www.springframework.org/schema/beans
    
    http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
    
    http://www.directwebremoting.org/schema/spring-dwr
    
        http://www.directwebremoting.org/schema/spring-dwr-2.0.xsd">
  2. Create a DWR Controller and a way for Spring (SimpleUrlHandlerMapping) to map DWR requests to this controller. The DWR Controller needs to handle the following requests:
    • /dwr/engine.js
    • /dwr/util.js
    • /dwr/interface/**
    • /dwr/call/**

    Add the DWR Controller to dwrSampleApp.xml:

     <dwr:controller id="dwrController" debug="true" />  
  3. Create the mapping from DWR requests to the DWR controller. There are several ways to create this mapping but I feel the following is the easiest to comprehend and the least verbose option:

    Add the SimpleUrlHandlerMapping to dwrSampleApp.xml:

    <bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
      <property value="true" name="alwaysUseFullPath"></property>
      <property name="mappings">
        <props>
          <prop key="/dwr/**/*">dwrController</prop>
        </props>
     </property>
    </bean>

    Please note the use of the alwaysUseFullPath property. If this is not set to true (by default it is false) we will have to map all of the required DWR requests:

    <prop key="/interface/**">dwrController</prop>

    etc., etc.

    Why? Because we have mapped /dwr/* to the DispatcherServlet in web.xml, what gets passed into the SimpleUrlHandlerMapping is everything after the /dwr/ (We are not matching on the entire path, because alwaysUseFullPath is false by default). I think not understanding how the SimpleUrlHandlerMapping works is one of the most common problems with this configuration. This has nothing to do with DWR directly, but the DWR mailing list pays the price!

    Another important note about Handler Mappings:

    It is important to note that the creation of the SimpleUrlHandlerMapping may cause your existing mappings to fail if you have not explicitly created a Handler Mapping in your Spring configuration.  By default Spring creates a BeanNameUrlHandlerMapping if you have not explicitly created a Handler Mapping.  So when the SimpleUrlHandlerMapping is created for DWR, Spring will no longer create the default BeanNameUrlHandlerMapping and existing mappings will not work.  Spring allows you to have multiple Handler Mappings, so to fix this you need to create a BeanNameUrlHandlerMapping explicitly in your spring.xml (in addition to the SimpleUrlHandlerMapping).  See the Spring documentation section 13.4.1 for more information.

  4. Configure DWR with the configuration tag.

    For this example we are returning an Address POJO from our DWR service. We need to tell DWR to convert the Address POJO with DWR’s “bean” converter. The configuration tag’s children elements mimic the behavior of dwr.xml elements. If you are familiar with the options available in dwr.xml — setting up this tag should be second nature.

    Add the dwr:configuration tag to dwrSampleApp.xml:

    <dwr:configuration>
      <dwr:convert class="org.uk.ltd.dwr.dev.model.Address" type="bean" />
    </dwr:configuration>
  5. Expose your Beans to DWR with the remote tag.

    Add the following bean to dwrSampleApp.xml:

    <bean class="org.uk.ltd.dwr.dev.service.DWRService" id="dwrService">
      <dwr:remote javascript="dwrService">
        <dwr:include method="getAddress"/>
      </dwr:remote>
    </bean> 

You can download the files from this article here. This includes all the source, configuration, and a ready to run web-app.

February 14, 2008

FireBug Lite – FireBug for IE

Have you ever worked on a web application that just didn’t work in Firefox? Many companies still use IE exclusively internally and any web application they develop will never be tested on another browser. This makes debugging client side script very challenging (unless you enjoy the pain of dealing with the Microsoft Script Debugger). Personally, I don’t enjoy the dreaded “Object Error” that seems to be just about the only error IE is capable of displaying. Enter FireBug Lite: A FireBug version that works in IE. Sure, it is a bit more work (to use it you have to include a JavaScript file) but it is way better than anything Microsoft currently has. Check it out: http://www.getfirebug.com/lite.html.

February 9, 2008

Web Application Security with WebGoat (OWASP)

If you develop applications for the web understanding the latest security exploits is crucial to securing your site.  WebGoat by the Open Web Application Security Project is a great tool to test your knowledge.  WebGoat is a J2ee application designed to deploy to Tomcat.  The application contains numerous security holes and lessons dedicated to showing users (hands on) how to exploit them.  I highly recommend WebGoat and enjoyed going through the lessons.  You will need WebScarab for the advanced lessons.

« Older Posts