First you will need to download the Jetty continuation 7 jar and place it in WEB-INF/lib. You can read more about why this works here.

Next you will need to add the JettyContinuationFilter to your web.xml:

<filter>
    <filter-name>JettyContinuationFilter</filter-name>
    <filter-class>org.eclipse.jetty.continuation.ContinuationFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>JettyContinuationFilter</filter-name>
    <url-pattern>/dwr/*</url-pattern>
</filter-mapping>

You should now be up and running.

1. I am using DWR 2.0.x, Spring 2.x, and Spring MVC
2. I am using DWR 2.0.x, Spring 2.x, but I am not using Spring MVC

However, you will need to make the following changes.

Spring 2.5 or greater is Required

You must upgrade to Spring 2.5 or higher.

Update you Spring Application Context

Update your Spring Application Context:

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:dwr="http://www.directwebremoting.org/schema/spring-dwr"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.directwebremoting.org/schema/spring-dwr

         http://www.directwebremoting.org/schema/spring-dwr-3.0.xsd">

Recently while performing a Windows Update my Vista box locked up.  The update ( for Internet Explorer 8 ) hadn’t quite completed and when I restarted, IE 8 was installed and running fine but my Windows Update didn’t think so.

My first thought was to remove IE 8, surely a re-install would solve the problem.  I followed the advice on Microsoft’s support site ( http://support.microsoft.com/kb/957700 ) for removing IE and neither the standard or alternative instructions worked for me.

After days without a resolution I finally figured out how to re-install IE 8 ( of course, you will only need to perform this hack if the Microsoft’s recommendations don’t work for you ).  Here is how to do it:

1. Download IE 8.
2. Run the installer and wait for the “Setup cannot continue because a more recent version of Internet Explorer has been detected on this computer.” prompt to appear.  DO NOT CLOSE THE PROMPT – if you close the prompt this will not work as the temporary directory mentioned in the next step will be removed.
3. The installer is extracted to one of your drives ( in my case it was not my C drive, so make sure you look at all of your available drives ) in a directory named with a random key ( in my case the key was 5c5c0d193eca399daddb3768b3 ).  Find the directory, open it, and run ie8.msu.  This will allow the installer to run and you will be up and running.

I recommend using one of the following tools to accomplish the same thing:

1. http://spoon.net/browsers/ – My first recommendation.
2. http://www.my-debugbar.com/wiki/IETester/HomePage – Seems to work pretty well.

I have to test things on different browser versions regularly due to my work on DWR and both of these tools have been a tremendous help.

DWR provides two main integration points with Hibernate:

1. A converter (hibernate3) that attempts to avoid reading from un-initialized (lazy) properties.
2. A filter (H3SessionAjaxFilter) which provides a Hibernate Session to the hibernate3 converter if un-initialized properties need to be read.

What converter should I use and how do I configure it?

You should use the hibernate3 converter if:

1. The returned object has lazy properties which have not been excluded in your DWR configuration and you do not want DWR to attempt to serialize these properties.
   1. Add a converter to your dwr.xml:

      <allow>
        ....
        <convert converter="hibernate3" match="yourpackage.yourClass" />
        ....
      </allow>
      

2. The returned object has lazy properties and you want DWR to attempt to serialize these properties. 
   1. Add a converter to your dwr.xml with the assumeSession parameter set to true.  This will tell DWR it should attempt to access the Hibernate session to read un-initialized properties:

      <allow>
        ....
        <convert converter="hibernate3" match="yourpackage.yourClass">
          <param name="assumeSession" value="true"/>
        </convert>
        ....
      </allow>
      

   2. Add the H3SessionAjaxFilter filter to your dwr.xml, this filter provides the Hibernate session needed by the hibernate3 converter to read the un-initialized properties.

      <allow>
        ....
        <filter class=" org.directwebremoting.hibernate.H3SessionAjaxFilter"/>
        ....
      </allow>
      

You should use the standard bean converter if:

1. The returned object does not have lazy properties and you want DWR to blindly serialize all properties on the object (or properties based on the exclusions, inclusions set in your DWR configuration).

Where the confusion lies:

So what was the problem that the users on the list were having?  Both users thought it was possible for DWR to make a call to the server to retrieve a lazy property when an attempt was made to access that property in JavaScript.  Here is a code sample to illustrate this point:

  function dwrCallBack(beanFromServer) {
    alert(beanFromServer.lazyProperty);
  }

DWR does a lot of magical things but it DOES NOT access the server when reading JavaScript properties.  All serialization of the object DWR will return to the browser is performed one-time – in the converter.  The converters job is to serialize the bean into a complete JavaScript object. 

In short the conversion of Hibernate beans is an all or nothing process.  The developer needs to understand what properties he needs to display in the view and prepare his converter configuration with this in mind.  Please note that the hibernate converter is very similar to the bean converter and thus you may specify include and exclude parameters (to exclude or include properties in serialization).  For more information on the bean and hibernate converters please see the DWR docs:

1. http://directwebremoting.org/dwr/server/hibernate
2. http://directwebremoting.org/dwr/server/dwrxml/converters/bean

If you have any questions feel free to post them in the comments area. 

First Impressions:

Setting up JAWR is simple!  The project is well documented and by following the quick start I was able to get up and running in no time.  JAWR does a lot more than JavaScript/CSS compression — here are some of the features:

• Allows you to componentize and organize your JavaScript sources.  Not only does this improve your code it also makes maintenance a lot easier.
• Debug mode allows you to debug your JS source with the modification of one property – Great for development.
• DWR 3.x plugin that compresses interface files generated by DWR as well as static DWR scripts.
• Gzips the response.

JAWR does a lot more.  All developers working on Java web apps should check it out — sooner rather than later!

Run the Ratproxy executable (ratproxy.exe):

1. Open a windows command prompt in the directory where ratproxy.exe lives.
2. Enter: ratproxy.exe -v C:\cygwin -w ratproxy.log -p 8282 -d yourdomain.com -lfscm.  The -p parameter specifies the port that Ratproxy will use  (by default Ratproxy will use 8080) and the -d specifies the domain we will be testing (obviously enter your own domain here).  The rest of the parameters are straightforward and can be reviewed in the official documentation. 

Configure your browser to use Ratproxy:

Now that Ratproxy is running you need to configure your browser to use the proxy.

Internet Explorer 7

1. Tools > Internet Options
2. Connections  > LAN Settings
3. Select ‘Use a proxy server for your LAN’
4. Address: The location where Ratproxy is running (localhost or 127.0.0.1 should work).
5. Port: The port you chose to bind Ratproxy to (in this example 8282). 
6. Now close and open a fresh browser window. 

Firefox 3.0

1. Tools > Options
2. Network > Settings
3. Select ‘Manual proxy configuration’
4. HTTP Proxy: The location where Ratproxy is running (localhost or 127.0.0.1 should work).
5. Port: The port you chose to bind Ratproxy to (in this example 8282). 
6. Now close and open a fresh browser window. 

If you don’t have this configured correctly or if Ratproxy is not running your browser will display an error indicating that the proxy server refused connection.

Do Stuff – and let Ratproxy do the hard work!:

That’s it.  Now all you need to do is step through your website highlighting the main errors that you think may be vulnerable.  Ratproxy will be tracking your session behind the scenes. 

Generate a formatted HTML report of Ratproxy findings:

1. Open the Cygwin bash shell.
2. cd to the ratproxy directory
3. Enter: sh ratproxy-report.sh ratproxy.log > report.html

Ratproxy will generate a nicely formatted HTML report.  That is all for this post, I hope it was helpful.

What you will need:

1. In order to run ratproxy in a windows environment you will need Cygwin (http://www.cygwin.com/).
2. The current Ratproxy release — http://code.google.com/p/ratproxy/.

Installing Cygwin:

From the Cygwin home page (http://www.cygwin.com/).:

1. Select the “Install or update now!” link to download the Cygwin setup.
2. When the download is complete run setup.exe.
3. Select “Install from Internet” > Next.
4. The next few screens are self explanatory.  You will choose your installation directory (the default is fine) and a few other options (all of the default options should be fine).
5. After you choose a mirror the download will begin.  After the download is complete you will be presented with a screen prompting you to select the packages you would like to install.  VERY IMPORTANT- There are a few utilities required to build Ratproxy that are not installed by default by the Cygwin installer.
   1. make - Located in ‘Devel’.
   2. gcc-core – Also located in ‘Devel’.
   3. openssl-devel - Also located in ‘Devel’.
   4. openssl (The OpenSSL runtime environment) – Located in ‘Libs’ or ‘Net’.

The preceding four packages must be installed or you will not be able to build or run Ratproxy.  Make sure they are not being skipped (there should be an X in the box next to each item).

Building Ratproxy:

Once Cygwin is installed with all of the required packages you are ready to build Ratproxy.

1. Unzip Ratproxy into your Cygwin directory (c:\cygwin).
2. Modify the make file packaged with Ratproxy – The Ratproxy Makefile contains a flag that is not compatible with the compiler installed with Cygwin.  This can be fixed by making a small modifcation to Makefile.
   1. Open Makefile (located at the root of your Ratproxy install).
   2. Look for this line — CFLAGS  = -Wall -O3 -Wno-pointer-sign -D_GNU_SOURCE
   3. Remove -Wno-pointer-sign

The affected portions of the Makefile should now look like this:

PROGNAME = ratproxy
CFLAGS	 = -Wall -O3 -D_GNU_SOURCE
LDFLAGS  = -lcrypto -lssl

3. Flare-dist – Now you need to download the Flare action script decompiler for Windows. From the Ratproxy root open the flare-dist directory. Directions for downloading the Flare action script decompiler are in the README file. Download the distribution at http://www.nowrap.de/download/flare06doswin.zip. Then unzip the file into Ratproxy/flare-dist. You should now have a file called flare.exe (remove the file that was distributed with Ratproxy — flare with no extension).
4. Make Ratproxy – Now we are ready to make Ratproxy.
   1. Open your Cygwin bash shell (by selecting your Cygwin shortcut or by running Cygwin.bat).
   2. Navigate into the Ratproxy directory – At the command prompt enter ‘cd /ratproxy’ (remember we saved Ratproxy at our Cygwin root).
   3. Run make – At the command prompt enter ‘make’

The ‘make’ command should run and complete successfully. You will be left with a compiled ratproxy.exe in your Ratproxy directory. Important: In order to run Ratproxy you will need to make sure the Cygwin/bin directory is in your Windows path (else the exe will blow up when you run it).

To add the Cygwin libraries to your Windows path (in Vista).

1. Right-click the ‘My Computer Icon’ and select ‘Properties’.
2. Select ‘Advanced system settings’ and then select the ‘Environmental Variables’ button.
3. Find the ‘Path’ variable under ’System variables’ and select the ‘Edit’ button.
4. Append ;C:\Cygwin\bin to the ’Variable value’.

You can now use that executable to run Ratproxy according to the documentation on the Ratproxy site.  That is all for this post in part two I discuss running Ratproxy.

References

Before we get started here are some additional references on DWR/Spring.

• Official DWR Documentation
• Bram Smeets and Jose Noheda have blogged about the integration between DWR and Spring.

The DWR Namespace Handler:

Spring 2.x includes a new “XML Namespace Handlers” feature. DWR 2.x allows you to leverage this feature through a custom namespace — eliminating the need for the DWR configuration file (dwr.xml). If you are using DWR 2.0.x and Spring 2.x this is the recommended approach if you want seamless integration (almost) between DWR and Spring.

There are two configurations to consider, please select a link for a detailed description and to download a fully functioning basic example:

1. I am using DWR 2.0.x, Spring 2.x, and Spring MVC
2. I am using DWR 2.0.x, Spring 2.x, but I am not using Spring MVC
3. I am using DWR 3.x …

dwr.xml:

If you are using an older version (pre 2.x) of DWR or Spring, DWR still provides integration with Spring through the Spring Creator. This configuration requires a dwr.xml configuration.  Information on this set-up is covered in the DWR manual.

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"> 

   <listener>
     <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
   </listener>

   <context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>
       classpath:dwrSampleApp2.xml
     </param-value>
   </context-param>

   <servlet>
     <servlet-name>dwr</servlet-name>
     <servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
     <init-param>
       <param-name>debug</param-name>
       <param-value>true</param-value>
     </init-param>
   </servlet>

   <servlet-mapping>
     <servlet-name>dwr</servlet-name>
     <url-pattern>/dwr/*</url-pattern>
  </servlet-mapping> 

</web-app>

Since we are not using Spring MVC there are two things that we need to take care of in the web.xml:

1. We need a way for our application to find and load our Spring configuration. There is more than one way to do this but I recommend using a Spring ContextLoadListener.
2. The DwrSpringServlet needs to be specified and all DWR requests need to be mapped to it.

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

1. Add the DWR namespace declarations to dwrSampleApp2.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. 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 dwrSampleApp2.xml:

     <dwr:configuration>
       <dwr:convert type="bean" class="org.uk.ltd.dwr.dev.model.Address" />
     </dwr:configuration>
   

3. Expose your Beans to DWR with the remote tag.

   Add the following bean to dwrSampleApp2.xml:

     <bean id="dwrService" class="org.uk.ltd.dwr.dev.service.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.