Introduction to DWR
Setting Up DWR
If you are familiar with the main JEE project structure, setting up DWR is relatively simple on any Java application server. To add Direct Web Remoting to any JEE project, there are three main steps. First, put the dwr.jar in the application path (this is usually the lib folder under the WEB-INF); second, add mapping to the special DWR Servlet in the main web.xml; and third, add a special dwr.xml descriptor file in the same folder as the web.xml file. The dwr.xml is the xml file that describes what objects and methods are “exposed” for the direct web remoting calls.
This is really all needed to set up the DWR on the server. The client-side is where the “exposed” methods are called. As you can see, the server setup does not require any changes to the existing Java code or server configuration code except extra mapping to just one Servlet.
Here is the directory structure in Eclipse:
The Servlet mapping in WEB-INF/web.xml can look like this:
The WEB-INF/dwr.xml can look like this, and I will follow up on this later.
<script src='/[WEBAPP-NAME]/dwr/engine.js'></script> <script src='/[WEBAPP-NAME]/dwr/util.js'></script>
Note that the second parameter is the ID, and the first is a callback function that will be invoked when the response comes back with the data from the server.
The test client provided by the DWR Servlet also let you invoke methods, but it is a visual interface that hides the true method signature, and can only verify if the correct result returns. Nevertheless, it is a very useful tool (see next section).
Here is the flow diagram:
Recall that the DWR Servlet was mapped under the dwr pattern in the web.xml file.
Also, recall that in the dwr.xml file there is a definition to expose ItemManager class.
The general format for the dynamic address is:
In the <script> tag, this address is set as the src attribute’s value. For example:
If you want to debug/test the DWR calls, the DWR Servlet needs to be in debug mode in the web.xml file. To enable debug, set the parameter for debug to true. Note that this is probably not desirable in production because it shows all available methods of the object to the client.
<init-param> <param-name>debug</param-name> <param-value>true</param-value> </init-param>
To see the test client point your browser to
This will show all exposed objects, and if you click on the object name, you will see available methods—both exposed and not exposed by the DWR.
Only exposed methods are callable directly on the test page.
Notice that the methods defined in the dwr.xml are active and some methods even take parameters.
Download the source code for the article here. The author would like to acknowledge and thank James Harmon for his contribution of the source code.
About the Author
Vlad Kofman is working on enterprise-scale projects for the major Wall Street firms. He has also worked on the defense contracts for the U.S. government. His main interests are object-oriented programming methodologies, UI, and design patterns.