Ajax框架 DWR 简介（3）---配置web.xml文件

Reference to DWR entries in WEB-INF/web.xml

The minimum possible additions to your web.xml, are simply those to declare the DWR servlet without which none of this would work. So the least you can get away with looks something like this:

<servlet>
  <servlet-name>dwr-invoker</servlet-name>
  <servlet-class>uk.ltd.getahead.dwr.DWRServlet</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>dwr-invoker</servlet-name>
  <url-pattern>/dwr/*</url-pattern>
</servlet-mapping>

In addition to this there are several extra servlet parameters that are somewhere between important and vaguely useful.

 

Logging

DWR works in JDK 1.3 which does not support java.util.logging, but we don't want to force anyone to use commons-logging or log4j, so DWR will work if no logging classes are present by using the HttpServlet.log() methods. However if DWR discovers commons-logging then it will use that.

Commons-Logging

Almost everyone will be using commons-logging because most servlet containers use it. So even if your webapp isn't explicitly using commons-logging it is probably available by default.

In these cases logging will be controlled by the config files of either java.util.logging or log4j. See the respective documentation for more details.

HttpServlet.log()

If you are using HttpServlet.log(), the following stanza controls DWR logging:

<init-param>
 <param-name>logLevel</param-name>
 <param-value>DEBUG</param-value>
</init-param>

The valid values are: FATAL, ERROR, WARN (the default), INFO and DEBUG.

 

 

Generally speaking you will only need one dwr.xml file and that will be in the default position: WEB-INF/dwr.xml. So you can leave this paramter out.

There are 3 reasons why you might wish to specify a different position for dwr.xml:

• You wish to keep dwr.xml with the files that it gives access to. In which case the section might have a param-value something like <param-value>WEB-INF/classes/com/yourco/dwr/dwr.xml</param-value>.
• You may have a large number of remoted classes and wish to keep the definitions in separate files. In this case you will have the section above repeated several times each with a different param-name that begins 'config' and each pointing at a different file. DWR will read them all in turn.
• DWR can use J2EE URL security built into the servlet spec to give different groups of users access to different functions. You simply define more than one dwr servlet by repeating the stanza at the top of the page with different names, urls and permissions.

If you do wish to use it then the syntax is as follows:

<init-param>
  <param-name>config*****</param-name>
  <param-value>WEB-INF/dwr.xml</param-value>
  <description>What config file do we use?</description>
</init-param>

Where config***** means any param-name that begins with the string 'config'. This parameter can be specified as many times as required, however the param-name should be different for each.

An example configuration to use J2EE servlet security is as follows:

<servlet>
  <servlet-name>dwr-user-invoker</servlet-name>
  <servlet-class>uk.ltd.getahead.dwr.DWRServlet</servlet-class>
  <init-param>
    <param-name>config-user</param-name>
    <param-value>WEB-INF/dwr-user.xml</param-value>
  </init-param>
</servlet>
<servlet>
  <servlet-name>dwr-admin-invoker</servlet-name>
  <servlet-class>uk.ltd.getahead.dwr.DWRServlet</servlet-class>
  <init-param>
    <param-name>config-admin</param-name>
    <param-value>WEB-INF/dwr-admin.xml</param-value>
  </init-param>
</servlet>
<servlet-mapping>
  <servlet-name>dwr-admin-invoker</servlet-name>
  <url-pattern>/dwradmin/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
  <servlet-name>dwr-user-invoker</servlet-name>
  <url-pattern>/dwruser/*</url-pattern>
</servlet-mapping>

<security-constraint>
  <display-name>dwr-admin</display-name>
  <web-resource-collection>
    <web-resource-name>dwr-admin-collection</web-resource-name>
    <url-pattern>/dwradmin/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>admin</role-name>
  </auth-constraint>
</security-constraint>
<security-constraint>
  <display-name>dwr-user</display-name>
  <web-resource-collection>
    <web-resource-name>dwr-user-collection</web-resource-name>
    <url-pattern>/dwruser/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>user</role-name>
  </auth-constraint>
</security-constraint>

Using Plug-ins
Most of the guts of DWR is pluggable so it is possible to alter the 
functionallity of DWR by replacing default classes. You can override the default 
implementations by including an <init-param> that specifies 
the interface to replace in the param-name and the replacement implementation in 
the param-value.
The plug-in points are:
 
 
uk.ltd.getahead.dwr.AccessControl 
uk.ltd.getahead.dwr.Configuration 
uk.ltd.getahead.dwr.ConverterManager 
uk.ltd.getahead.dwr.CreatorManager 
uk.ltd.getahead.dwr.Processor 
uk.ltd.getahead.dwr.ExecutionContext 
The default implementations of these plug-in points are all in the 
uk.ltd.getahead.dwr.impl package.
 
 
Using debug/test mode
You put DWR into debug/test mode by adding the following parameter:
<init-param>
  <param-name>debug</param-name>
  <param-value>true</param-value>
</init-param>

DWR will generate test pages for each of the allowed classes (see dwr.xml
below) in debug mode. These can be very useful in seeing what DWR can do and how
it works. This mode can also alert you to problems like javascript reserved word
clashes or overloading problems. 
However this mode should not be used in
live deployment as it could give an attacker a lot of information about the
services that you export. If you have designed your website properly then this
extra information will not help an attacker exploit your website however it is
generally wise not to give anyone a route map to exploit any mistakes you might
have made. 
DWR is provided 'as is', without any warranty, so the security of
your website is your responsibility. Please take care to keep it secure.