We have been seeing this issue in DWR/Spring integrations. It looks like the Spring guys changed (changed since Spring 3.x?) their schema and now require an id attribute on top-level annotation-config elements. DWR uses a Spring class to parse the XML and it throws the following error:

“Configuration problem: Id is required for element ‘annotation-config’ when used as a top-level tag”

It appears for now adding an id attribute resolves the issue. I will continue to look into this.

This post applies to DWR 3.x and Spring 3.x. Configuring DWR to work with annotations and Spring isn’t difficult, but there are a lot of moving parts and many users struggle with it. There are a few elements that DWR has available and understanding them is key (these elements can be viewed in the DWR Spring schema – http://directwebremoting.org/schema/spring-dwr-3.0.xsd):

annotation-scan – This element enables DWR to scan the classpath, detect beans annotated with @RemoteProxy, @RemoteMethod, @DataTransferObject and register the beans (@DataTransferObject) and Creator proxies (@RemoteProxy & @RemoteMethod) for them.

annotation-config – This element enables DWR to scan the Spring context, detect beans annotated with @RemoteProxy and @RemoteMethod and registers Creator proxies for them. Note this element will only search the Spring context and will only create the Creator proxies. You will need to manually register converters for the types the proxy methods will return or accepts as parameters.

For now I have completed two sample applications that you can use to get started. I don’t have time to discuss the code right now but it is pretty straightforward.

• dwr3SampleAppSpring3AnnotNonSpringMVC
• dwr3SampleAppSpring3Annot

For Jetty 7 a lot of re-factoring has been done on the Continuations API. I recently took a look at the changes and modified DWR’s code to reflect the latest API. If you are using the latest version of DWR 3.x (currently unreleased) and you are still using a Jetty version < 7.x you will need to follow these directions to get Continuations working. 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.

If you want to integrate DWR 3.x with Spring you can follow my previous posts (note – I have included a working sample application and updated source at the bottom of this page):

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 (I am using Spring 3.0.4).

Update you Spring Application Context

Update your Spring Application Context:

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:aop="http://www.springframework.org/schema/aop"
    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-.0.xsd
    http://www.springframework.org/schema/aop
    http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
    http://www.directwebremoting.org/schema/spring-dwr
    http://www.directwebremoting.org/schema/spring-dwr-3.0.xsd">

I have added two working examples (~10 mb in size), both of these zip files contain all source as well as a working web-app that you can drop into your container:

• DWR 3.x, Spring 3.x using Spring MVC
• DWR 3.x, Spring 3.x, without Spring MVC

“Setup cannot continue because a more recent version of Internet Explorer has been detected on this computer.”

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.

Any developer that has worked on web interfaces knows the pains involved in dealing with different browsers and browser versions.  Microsoft  has notoriously made this difficult by not permitting more than one version of IE to run on a machine.  The solution – install a VM for each version of IE you want to run.  Does that sound crazy to you?  It does to me.

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.

Recently there have been some questions on DWR’s user mailing list about integration with Hibernate.  Most of the questions stem from a misunderstanding of how DWR works and I thought it would be helpful to write a post to give new users some information on what to expect from DWR.

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. 

JAWR is an open source tool written in Java that compresses and organizes an applications JavaScript/CSS source.  I found out about JAWR through the DWR mailing list.  It took me awhile to check it out, but I finally got around to it.  I have been working on a DWR application with an ExtJS front-end and I thought this would be a perfect place to try JAWR. 

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!

In my first Ratproxy post I provided instructions on building Ratproxy in a Windows/Cygwin environment.  In this post I will discuss running and using Ratproxy in a Windows/Cygwin environment. 

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.

Recently, I have been studying web application security and some of my research led me to Ratproxy.  Ratproxy is a web application security audit tool recently released by Google.  In this post I will show you how to install Ratproxy in a Windows environment.

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.