Signatures in dwr.xml

The signatures section is used to enable resolution of the types stored in Collections when specific generic types are not being used. For example in the following code DWR has no way to know what it should cast the incoming data to:

public class Check
{
  public List<?> setLotteryResults(List<?> whatDoIContain)
  {
      ...
  }
}

However, if the method signature was changed to:

public class Check
{
  public List<Integer> setLotteryResults(List<Integer> whatDoIContain)
  {
      ...
  }
}

DWR uses the generic type to cast the incoming data. This is possible because DWR 3.x requires Java 1.5 or greater - because of this DWR signatures are largely obsolete.

If you still need Signatures

The signatures section allows us to hint to DWR what types should be used. The format will be obvious to anyone that has an understanding of generic types under JDK5:

<signatures>
  <![CDATA[
  import java.util.List;
  import com.example.Check;
  Check.setLotteryResults(List<Integer> nos);
  ]]>
</signatures>

Nested Generic Definitions

The signatures element does not currently support nested generic defintions. So for example the following will not work:

<signatures>
  <![CDATA[
  import java.util.List;
  import java.util.Map ;
  Check.setConditions(Map<String, Map<String, String>>);
  ]]>
</signatures>

While the parser is updated to support nested generic definitions, you can use the following trick: In the absence of other type information, DWR assumes that a parameter will be a String. So the above example can be written:

<signatures>
  <![CDATA[
  import java.util.List;
  import java.util.Map ;
  Check.setConditions(Map<String, Map>);
  ]]>
</signatures>