RAT (Release Audit Tool) results

The following document contains the results of RAT (Release Audit Tool).

*****************************************************
Summary
-------
Notes: 1
Binaries: 5
Archives: 0
Standards: 18

Apache Licensed: 0
Generated Documents: 0

JavaDocs are generated and so license header is optional
Generated files do not required license headers

18 Unknown Licenses

*******************************

Archives (+ indicates readable, $ unreadable): 

 
*****************************************************
  Files with AL headers will be marked L
  Binary files (which do not require AL headers) will be marked B
  Compressed archives will be marked A
  Notices, licenses etc will be marked N
  N     LICENSE.txt
 !????? pom.xml
 !????? src/changes/changes.xml
 !????? src/main/assembly/bin.xml
 !????? src/main/assembly/src.xml
 !????? src/site/apt/advanced.apt
 !????? src/site/apt/client.apt
 !????? src/site/apt/contributing.apt
 !????? src/site/apt/download.apt
 !????? src/site/apt/extensions.apt
 !????? src/site/apt/index.apt
 !????? src/site/apt/introspection.apt
 !????? src/site/apt/links.apt
 !????? src/site/apt/server.apt
 !????? src/site/apt/ssl.apt
 !????? src/site/apt/types.apt
 !????? src/site/fml/faq.fml
 !????? src/site/site.xml
 !????? src/site/xdoc/changes.xml
  B     src/site/xdoc/images/feather.gif
  B     src/site/xdoc/images/group-logo.gif
  B     src/site/xdoc/images/project-logo.jpg
  B     src/site/xdoc/images/xml-logo.gif
  B     src/site/xdoc/images/xmlrpc-logo.gif
 
 *****************************************************
 Printing headers for files without AL header...
 
 
 =======================================================================
 ==pom.xml
 =======================================================================
 <?xml version="1.0" encoding="UTF-8"?>
<project
    xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <parent>
      <groupId>org.apache</groupId>
      <artifactId>apache</artifactId>
      <version>4</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.apache.xmlrpc</groupId>
    <artifactId>xmlrpc</artifactId>
    <name>Apache XML-RPC</name>
    <version>3.1</version>
    <description>
        Apache XML-RPC is a Java implementation of XML-RPC, a popular protocol that uses XML over HTTP to
        implement remote procedure calls. Compared to SOAP, or JAX-RPC, it is stable, much simpler and easier to handle.
        Version 3 of Apache XML-RPC introduces several important vendor extensions over the original XML-RPC
        specification.
    </description>
    <packaging>pom</packaging>
    <modules>
      <module>common</module>
      <module>client</module>
      <module>server</module>
      <module>tests</module>
    </modules>
    <url>http://ws.apache.org/xmlrpc/</url>
    <issueManagement>
        <system>jira</system>
        <url>http://issues.apache.org/jira/BrowseProject.jspa?pid=10465</url>
    </issueManagement>
    <ciManagement>
      <system>Gump</system>
      <url>http://vmgump.apache.org/gump/public/ws-xmlrpc/xmlrpc/index.html</url>
    </ciManagement>
    <inceptionYear>2001</inceptionYear>
    <mailingLists>
      <mailingList>
        <name>XML-RPC Developers</name>
        <subscribe>xmlrpc-dev-subscribe@ws.apache.org</subscribe>
        <unsubscribe>xmlrpc-dev-unsubscribe@ws.apache.org</unsubscribe>
        <post>xmlrpc-dev@ws.apache.org</post>
        <archive>http://mail-archives.apache.org/mod_mbox/ws-xmlrpc-dev/</archive>
        <otherArchives>
          <otherArchive>http://marc.theaimsgroup.com/?l=xmlrpc-dev</otherArchive>
        </otherArchives>
      </mailingList>
      <mailingList>

 =======================================================================
 ==src/changes/changes.xml
 =======================================================================
 <document>
  <properties>
    <title>Changes in Apache XML-RPC</title>
  </properties>
  <body>
    <release version="3.1" date="2007-Aug-31">
      <action dev="jochen" type="add">
        Introduced the "enabledForExceptions" property.
      </action>
      <action dev="jochen" type="add">
        Added support for void methods, if extensions are turned on.
      </action>
      <action dev="jochen" type="add" issue="XMLRPC-118" due-to="Perry Nguyen"
          due-to-email="pfnguyen@hanhuy.com">
        Added PropertyHandlerMapping.load(ClassLoader, Map).
      </action>
      <action dev="jochen" type="add" issue="XMLRPC-117" due-to="Jimisola Laursen"
          due-to-email="jimisola@jimisola.com">
        The authentication handler, type converter and requestprocessor factories
        are now configurable as properties of the XmlRpcServlet.
      </action>
      <action dev="jochen" type="add" issue="XMLRPC-116" due-to="Jimisola Laursen"
          due-to-email="jimisola@jimisola.com">
        Atomic properties of XmlRpcServer are now configurable as init parameters
        in the XmlRpcServlet.
      </action>
      <action dev="jochen" type="fix">
        Reworked the WebServer/ThreadPool framework in order to ensure a clean
        shutdown.
      </action>
      <action dev="jochen" type="fix" issue="XMLRPC-124" due-to="Jimisola Laursen"
          due-to-email="jimisola@jimisola.com">
		The configuration framework, as introduced by XMLRPC-116, was applicable
		to the configuration only, and not to the XmlRpcServlet, or the
		XmlRpcServletServer.
      </action>
      <action dev="jochen" type="add">
        Introduced the method AbstractReflectiveHandlerMapping.isHandlerMethod().
        This should allow users to prevent remote invocation of certain methods,
        for example initialization stuff.
      </action>
      <action dev="jochen" type="add" issue="XMLRPC-126"
          due-to="Eugene Prokopiev" due-to-email="prokopiev@stc.donpac.ru">
        The ClientFactory is now able to use a custom name for the remote
        handler. So far, it was always using the interface name.
      </action>
      <action dev="jochen" type="add" issue="XMLRPC-127">
        It is now possible to have other objects than strings as
        map keys.
      </action>

 =======================================================================
 ==src/main/assembly/bin.xml
 =======================================================================
 <assembly>
  <id>bin</id>
  <formats>
    <format>tar.gz</format>
  </formats>
  <includeSiteDirectory>true</includeSiteDirectory>
  <fileSets>
    <fileSet>
      <includes>
		<include>LICENSE.txt</include>
      </includes>
    </fileSet>
    <fileSet>
      <directory>common/target</directory>
      <outputDirectory>/lib</outputDirectory>
      <includes>
        <include>*.jar</include>
      </includes>
    </fileSet>
    <fileSet>
      <directory>client/target</directory>
      <outputDirectory>/lib</outputDirectory>
      <includes>
        <include>*.jar</include>
      </includes>
    </fileSet>
    <fileSet>
      <directory>server/target</directory>
      <outputDirectory>/lib</outputDirectory>
      <includes>
        <include>*.jar</include>
      </includes>
    </fileSet>
    <fileSet>
      <directory>tests/target/dependency</directory>
      <outputDirectory>/lib</outputDirectory>
      <includes>
        <include>commons-logging-*.jar</include>
        <include>ws-commons-util-*.jar</include>
      </includes>
    </fileSet>
  </fileSets>
</assembly>

 =======================================================================
 ==src/main/assembly/src.xml
 =======================================================================
 <assembly>
  <id>src</id>
  <formats>
    <format>tar.gz</format>
  </formats>
  <fileSets>
    <fileSet>
      <includes>
		<include>LICENSE.txt</include>
		<include>pom.xml</include>
		<include>.cvsignore</include>
		<include>common/**/*</include>
		<include>client/**/*</include>
		<include>server/**/*</include>
		<include>src/**/*</include>
		<include>tests/**/*</include>
      </includes>
      <excludes>
		<exclude>common/target</exclude>
		<exclude>client/target</exclude>
		<exclude>server/target</exclude>
		<exclude>tests/target</exclude>
		<exclude>common/target/**/*</exclude>
		<exclude>client/target/**/*</exclude>
		<exclude>server/target/**/*</exclude>
		<exclude>tests/target/**/*</exclude>
      </excludes>
    </fileSet>
    <fileSet>
      <directory>src</directory>
    </fileSet>
  </fileSets>
</assembly>

 =======================================================================
 ==src/site/apt/advanced.apt
 =======================================================================
            ---------------------------
           Advanced Programming Topics
           ---------------------------

  This page describes some advanced topics.

Dynamic proxies

  Dynamic proxies are an extremely comfortable way of Client programming.
  Basically, the idea is as follows: All request processors on the server
  side are splitted into interface and implementation. The interfaces are
  shared between client and server, typically within some common jar file.
  Now, rather than using the
  {{{apidocs/org/apache/xmlrpc/client/XmlRpcClient.html}XmlRpcClient}}
  directly,
  the programmer creates an instance of
  {{{apidocs/org/apache/xmlrpc/client/util/ClientFactory.html}ClientFactory}},
  which is configured with an
  {{{apidocs/org/apache/xmlrpc/client/XmlRpcClient.html}XmlRpcClient}}.

  The {{{apidocs/org/apache/xmlrpc/client/util/ClientFactory.html}factory}}
  can take an interface as input and returns an implementation,
  which internally calls the server by using the
  {{{apidocs/org/apache/xmlrpc/client/XmlRpcClient.html}XmlRpcClient}}.

  Perhaps some code shows more than words. First of all, let's create
  a request processor interface.

-----------------------------------------------------------------------------------
    package com.foo;

    public interface Adder {
      public int add(int pNum1, int pNum2);
    }
-----------------------------------------------------------------------------------

  The server contains the request processors implementation:

-----------------------------------------------------------------------------------
    package com.foo;

    public class AdderImpl implements Adder {
      public int add(int pNum1, int pNum2) {
        return pNum1 + pNum2;
      }
    }
-----------------------------------------------------------------------------------

  And here is how the client would use this:


 =======================================================================
 ==src/site/apt/client.apt
 =======================================================================
            -------------------------
           The Apache XML-RPC Client
           -------------------------

The XmlRpcClient

  Before talking to an XML-RPC server, you need an instance of
  {{{apidocs/org/apache/xmlrpc/client/XmlRpcClient.html}XmlRpcClient}}.

  The XmlRpcClient is a stateless, thread safe object. The clients
  configuration occurs by setting the following objects:

*------------------+--------------------------------------------------------------+
| Name             | Description                                                  |
*------------------+--------------------------------------------------------------+
| ClientConfig     | This object is an instance of                                |
|                  | {{{apidocs/org/apache/xmlrpc/client/XmlRpcClientConfig.html} |
|                  | XmlRpcClientConfig}}. It has a lot of atomic properties,     |
|                  | that specify details like server URL, credentials, character |
|                  | set, and the like.                                           |
*------------------+--------------------------------------------------------------+
| TransportFactory | The task of the transport factory is to create an object,    |
|                  | which uses the client configuration for talking to the       |
|                  | server. For example, there is a transport factory, which     |
|                  | uses the java.net classes. Another example is a transport    |
|                  | factory based on the Jakarta Commons Http Client. However,   |
|                  | transport factories don't need to use HTTP: An excellent     |
|                  | example is the local transport factory, which talks to an    |
|                  | embedded server. This last factory is, of course, very       |
|                  | useful for debugging.                                        |
*------------------+--------------------------------------------------------------+
| XmlWriterFactory | The XmlWriter is an object, which creates XML for you.       |
|                  | Typically, you do not need to care for this object, because  |
|                  | the defaults should be fine. However, it is useful, if you   |
|                  | need a special XML syntax.                                   |
*------------------+--------------------------------------------------------------+

  So, let's have a look at a first example:

-----------------------------------------------------------------------------------
    import org.apache.xmlrpc.client.XmlRpcClient;
    import org.apache.xmlrpc.client.XmlRpcClientConfigImpl;

    XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
    config.setServerURL(new URL("http://127.0.0.1:8080/xmlrpc"));
    XmlRpcClient client = new XmlRpcClient();
    client.setConfig(config);
    Object[] params = new Object[]{new Integer(33), new Integer(9)};
    Integer result = (Integer) client.execute("Calculator.add", params);
-----------------------------------------------------------------------------------

 =======================================================================
 ==src/site/apt/contributing.apt
 =======================================================================
                          ------------
                         Contributing
                         ------------

Contributing

  A great {{{http://jakarta.apache.org/site/contributing.html}description}}
  of contributing to Apache XML-RPC is available from the Jakarta
  project.

Submitting Patches

  The preferred patch format is unidiff. The best way to generate a patch
  is by checking out the sources, applying your changes and running

---------------------------------------------------------------------------------
    svn diff
---------------------------------------------------------------------------------

  Emails containing patches should be sent to the mailing list
  xmlrpc-dev@ws.apache.org, and prefix their subject lines with <<[PATCH]>>.
  Patches are also accepted via the
  {{{http://issues.apache.org/jira/browse/XMLRPC}issue tracker}}.
  The Jakarta project provides a description of
  {{{http://jakarta.apache.org/site/source.html}life with ASF source code}}
  -- look for the <<Patches>> section.

 =======================================================================
 ==src/site/apt/download.apt
 =======================================================================
                  ---------
                 Downloads
                 ---------

Downloading Apache XML-RPC

  You can download the current version of Apache XML-RPC from
  {{{http://www.apache.org/dyn/closer.cgi/ws/xmlrpc/}
  distribution directory}}.

  Alternatively, you can get the latest code snapshot via
  {{{http://svn.apache.org/repos/asf/webservices/xmlrpc/trunk}Subversion}}.

  Information on how to build and use the software is included in the
  package.

 =======================================================================
 ==src/site/apt/extensions.apt
 =======================================================================
            --------------------------------
           Apache XML-RPC Vendor Extensions
           --------------------------------

Introduction

  The {{{http://www.xmlrpc.com/spec}XML-RPC specification}} has been
  published in 1999. In the past 6 years, it was subject to some
  minor corrections. Some things have been made clearer. However, it
  hasn't really changed or evolved. Dave Winer, the XML-RPC specifications
  author, has always rejected any suggestions in that direction. Of course,
  he did so with a good reason: One of XML-RPC's major targets was
  portability over arbitrary platforms and programming languages. Clearly,
  this target has been met and any further development would mean putting
  this at risk. 

  On the other hand, this is most unfortunate: Obeying the specification
  means accepting really serious limitations. For example, one cannot even
  use all of Java's primitive data types, although nowadays they have
  equivalents in almost any programming language. Possibly even more
  important is the requirement to send a content-length header: HTTP/1.1
  and its chunk encoding are the definite standard in 2005 for both HTTP
  clients and servers. Consequently, the content-length header is, at
  best, superfluos. Of course, having an additional header wouldn't be
  too much of a problem. But calculating the header value enforces, that
  request and response are written to byte arrays, before actually sending
  them. This is both slow and memory consuming.

  Version 3 of Apache XML-RPC is a compromise: By default it
  still meets the specification. However, you <<may>> enable additional
  features, called vendor extensions. Of course, these features only work,
  if you have a streaming version of Apache XML-RPC on both sides. In
  practice, it occurs very frequently, that both sides are controlled by
  the same people. Besides, the vendor extensions are documented very
  clearly here: Adding these features to an existing XML-RPC library
  would mean almost no effort, so possibly someone does. You'r welcome.

  But the purpose of this document is more than documentation: It is also
  to receive feedback and discuss the extensions specification and
  implementation. Nothing is fixed, and everything can be changed.

Enabling extensions

  Vendor extensions cannot be used, unless they are explicitly enabled.
  In some cases, you have to enable specific features, for example
  request compression. But in all cases, you need to enable the use
  of vendor extensions at all, because that is the step, where you
  knowingly say: "I know, I am now in violation of the original XML-RPC
  specification."


 =======================================================================
 ==src/site/apt/index.apt
 =======================================================================
            --------------
           Apache XML-RPC
           --------------

About Apache XML-RPC

  Apache XML-RPC is a Java implementation of
  {{{http://www.xmlrpc.com/}XML-RPC}}, a popular protocol that
  uses XML over HTTP to implement remote procedure calls.

  Version 3 of Apache XML-RPC is still compliant to the
  {{{http://www.xmlrpc.com/spec}XML-RPC specification}}.
  However, the user may enable several vendor extensions
  are available, that greatly extend the power of XML-RPC:

  * All primitive Java types are supported, including long,
    byte, short, and double.

  * Calendar objects are supported. In particular, timezone
    settings, and milliseconds may be sent.

  * DOM nodes, or JAXB objects, can be transmitted. So are
    objects implementing the java.io.Serializable interface.

  * Both server and client can operate in a streaming mode,
    which preserves resources much better than the default
    mode, which is based on large internal byte arrays.

 =======================================================================
 ==src/site/apt/introspection.apt
 =======================================================================
            ---------------------------
           Advanced Programming Topics
           ---------------------------

    Apache XML-RPC supports XML-RPC introspection, as specified by
    {{{http://scripts.incutio.com/xmlrpc/introspection.html}
    http://scripts.incutio.com/xmlrpc/introspection.html}}. This
    page describes how to configure the XML-RPC server for
    introspection.

What is introspection?

    Introspection is the servers ability to provide metadata
    to the client. The client may ask "What method names does
    the server offer?", "How do I invoke method 'foo'?", or
    "Can you give me help on method 'foo'?".

    The client does so by invoking the special methods
    "system.listMethods", "system.methodSignature" and
    "system.methodHelp". These are described in detail in the
    non-official specification for XML-RPC introspection, which
    you'll find at
    {{{http://scripts.incutio.com/xmlrpc/introspection.html}
    http://scripts.incutio.com/xmlrpc/introspection.html}}.

How do I configure the server for introspection?

    The server requires a special mapping. Basically, you simply add
    a "system" handler, which is implemented by the class
    <<<XmlRpcSystemImpl>>>. Here's how you would do that in the
    <<<XmlRpcServlet>>>:

---------------------------------------------------------
    public class MyXmlRpcServlet extends XmlRpcServlet {
		protected XmlRpcHandlerMapping newXmlRpcHandlerMapping()
		        throws XmlRpcException {
			PropertyHandlerMapping mapping =
			    (PropertyHandlerMapping) newXmlRpcHandlerMapping();
			XmlRpcSystemImpl.addSystemHandler(mapping);
		}
    }
---------------------------------------------------------

    Quite similar, you would override a protected method, if you
    prefer using the <<<WebServer>>> class:

---------------------------------------------------------
    public class MyWebServer extends WebServer {
        public MyWebServer(int pPort) {
            super(pPort);

 =======================================================================
 ==src/site/apt/links.apt
 =======================================================================
            --------------------------------
           External Links
           --------------------------------

  Below you'll find some links to external sources, that deal with
  Apache XML-RPC.

Specifications

  * The {{{http://www.xmlrpc.com/spec}XML-RPC specification}}

Examples and Tutorials

  * A simple, yet complete example of using the XmlRpcServlet by 
    {{{http://www.petrovic.org/blog/?p=127}Mark Petrovic}}
  * An example of initializing handlers by using so-called
    persistent objects, written by
    {{{http://blog.buttermountain.co.uk/2006/11/06/accessing-persistent-objects-with-apache-ws-xmlrpc-30-a-documented-example/}Iain Bullard}}.

 =======================================================================
 ==src/site/apt/server.apt
 =======================================================================
            -------------------------
           The Apache XML-RPC Server
           -------------------------


Server-side XML-RPC

  If you have read and understood the previous document about the
  {{{./client.html}Apache XML-RPC client}}, then the server isn't too
  much news.

  First of all, there is an object, called the XmlRpcServer. This objects
  purpose is to receive and execute XML-RPC calls by the clients. The
  XmlRpcServer <<can>> be embedded into a servlet container, or another
  HTTP server (for example, the minimal web server, that comes with
  XML-RPC), but it doesn't need to. Take the local transport as an
  example: In that case the XML-RPC server is simply embedded into the
  client application.

  Like the XmlRpcClient, the XmlRpcServer needs a configuration, which
  is given by the XmlRpcServerConfigImpl object.

The XML-RPC Servlet

  The easiest way to create an XML-RPC Server is the XmlRpcServlet, which
  has an automatically embedded instance of XmlRpcServer. This servlet allows
  you to create a server within 10 minutes or so:

    [[1]] Create a class, or a set of classes, which are implementing
          the remote procedure calls. Here's an example of such a class:

-----------------------------------------------------------------------------------
    package org.apache.xmlrpc.demo;
    public class Calculator {
		public int add(int i1, int i2) {
			return i1 + i2;
		}
		public int subtract(int i1, int i2) {
			return i1 - i2;
		}
    }
-----------------------------------------------------------------------------------

          This class has two public, non-static methods, which should
          be available to the clients.

    [[2]] Create a property file, which contains at least one property.
          The property name is arbitrary, and the property value is the
          fully qualified name of the Calculator class. For example, like
          that:

 =======================================================================
 ==src/site/apt/ssl.apt
 =======================================================================
            ---------
           Using SSL
           ---------

  This page describes how to configure a client for using SSL (aka https).
  Server configuration is out of this documents scope, because it clearly
  depends on the webserver. We refer, for example, to the 
  {{{http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html} Tomcat SSL HowTo}}
  or to the FAQ entry on
  {{{http://docs.codehaus.org/display/JETTY/How+to+configure+SSL} SSL with Jetty}}.

Background

  Client configuration for SSL is not as simple as one might expect. This
  is surprising, because using SSL with a browser is as simple as typing in
  an https URL into the browsers input field.

  Thus, the first thing to keep in mind: Never start with Apache XML-RPC as
  a client. It is much better to create a simple static page and point your
  browser to the static pages URL. If you get this working, then you may
  assume that all remaining problems rest with the client.

  If you did that, you may have noticed, that the browser brings up a
  warning, that your web server is "not trusted". This is typically the
  case, if you did not buy a certificate: For the case of simplicity,
  developers are typically creating a so-called "self-signed certificate".

  And that's exactly your most likely problem: Like pressing the browsers
  button to "Accept the certificate" (temporarily or permanently), you've
  got to tell your Java client, that you want to accept the certificate.

Choose the right URL

  Typically, your server may be accessible with multiple URL's. For example,
  on my machine the following URL's will all reach the same servlet:

    https://mcjwi.eur.ad.sag/xmlrpc
    https://localhost/xmlrpc
    https://127.0.0.1/xmlrpc

  Unfortunately, at most one will work in the most cases. The question is:
  How do I choose the right one?

  The answer is given by the certificate field CN. For example, my self
  certified key looks like this:

    Owner: CN=mcjwi.eur.ad.sag, OU=-, O=-, L=-, ST=-, C=-
    Issuer: CN=mcjwi.eur.ad.sag, OU=-, O=-, L=-, ST=-, C=-

  Note, that you've got to pick a proper CN when generating the certificate!

 =======================================================================
 ==src/site/apt/types.apt
 =======================================================================
            ------------------
           XML-RPC Data Types
           ------------------

Data Types

  The {{{http://www.xmlrpc.com/spec}XML-RPC specification}} defines the following
  available data types:

*--------------------+--------------------+-------------------------------------+
| Java Type          | XML Tag Name       | Description                         |
*--------------------+--------------------+-------------------------------------+
| Integer            | <i4>, or           | A 32-bit, signed, and non-null,     |
|                    | <int>              | integer value.                      |
*--------------------+--------------------+-------------------------------------+
| Boolean            | <boolean>          | A non-null, boolean value (0, or    |
|                    |                    | 1).                                 |
*--------------------+--------------------+-------------------------------------+
| String             | <string>           | A string, non-null.                 |
*--------------------+--------------------+-------------------------------------+
| Double             | <double>           | A signed, non-null, double          |
|                    |                    | precision, floating point number.   |
|                    |                    | (64 bit)                            |
*--------------------+--------------------+-------------------------------------+
| java.util.Date     | <dateTime.iso8601> | A pseudo ISO8601 timestamp, like    |
|                    |                    | 19980717T14:08:55. However,         |
|                    |                    | compared to a true ISO8601 value,   |
|                    |                    | milliseconds, and time zone         |
|                    |                    | informations are missing.           |
*--------------------+--------------------+-------------------------------------+
| byte[]             | <base64>           | A base64 encoded byte array.        |
*--------------------+--------------------+-------------------------------------+
| java.util.Map      | <struct>           | A key value pair. The keys are      |
|                    |                    | strings. The values may be any      |
|                    |                    | valid data type, including another  |
|                    |                    | map.                                |
*--------------------+--------------------+-------------------------------------+
| Object[]           | <array>            | An array of objects. The array      |
| java.util.List     |                    | elements may be any valid data      |
|                    |                    | type, including another array.      |
*--------------------+--------------------+-------------------------------------+

  If the property <<<enabledForExtensions>>> is set, then additional data
  types become valid. (Both client and server do support this property.)

*----------------------+--------------------+-------------------------------------+
| Java Type            | XML Tag Name       | Description                         |
*----------------------+--------------------+-------------------------------------+
| None                 | <ex:nil>           | A typeless null value.              |
*----------------------+--------------------+-------------------------------------+

 =======================================================================
 ==src/site/fml/faq.fml
 =======================================================================
 <faqs title="FAQ">
  <part id="client">
    <faq id="arrays">
      <question>Why do I receive a ClassCastException, if the server returns an array?</question>
      <answer>
        <p>The problem is typically caused by code like the following:</p>
        <source><![CDATA[
    Integer[] result = (Integer[])server.execute("Server.foo", param);
        ]]></source>
        <p>The problem is in the fact, that the XML-RPC response tells
          the client, that the server returns an array. It doesn't tell
          what type the array has. In other words, the client will
          always receive an object array. The workaround is to use
          code like the following:</p>
        <source><![CDATA[
    Object[] result = (Integer[])server.execute("Server.foo", param);
    for (int i = 0;  i < result.length;  i++) {
        Integer num = (Integer) result[i];
        ...
    }
        ]]></source>

      </answer> 
    </faq>
 
    <faq id="compression_request">
      <question>How do I enable request compression?</question>
      <answer>
        <p>That's simple: Set the properties "enabledForExtensions"
          and "gzipCompressing". That said, note the following
          hints:</p>
        <ul>
          <li>Setting these properties will only work, if the XML-RPC
            server is aware of request compression. Compression is a
            violation of the XML-RPC specification, so typically the
            server will refuse the request, unless it is an Apache
            XML-RPC server with version 2 or later. (Apache XML-RPC 2
            supports request compression, although it was officially
            designed to be strictly compliant to the XML-RPC specification.
            However, noone was aware, that compression violates the
            specification. :-)</li>
          <li>Compressing the request doesn't mean that the response
            will also be compressed. You need to request response
            compression to achieve that.</li>
          <li>Additionally, be aware of the following: Compression
            depends on HTTP/1.1 features. In particular, you must
            not use the LiteHttpTransport.</li>
        </ul>
      </answer>
    </faq>

 =======================================================================
 ==src/site/site.xml
 =======================================================================
 <project name="ws-xmlrpc">
  <bannerLeft>
    <name>Apache XML-RPC</name>
    <src>http://ws.apache.org/xmlrpc/images/xmlrpc-logo.gif</src>
    <href>http://ws.apache.org/xmlrpc/</href>
  </bannerLeft>
  <body>
    <links>
      <item name="Apache" href="http://www.apache.org/"/>
      <item name="Webservices" href="http://ws.apache.org/"/>
      <item name="XML-RPC" href="http://ws.apache.org/xmlrpc/"/>
    </links>

    <menu name="XML-RPC">
      <item name="Overview"            href="/index.html"/>
      <item name="Client Classes"      href="/client.html"/>
      <item name="Server Side XML-RPC" href="/server.html"/>
      <item name="Vendor Extensions"   href="/extensions.html"/>
      <item name="SSL"                 href="/ssl.html"/>
      <item name="Introspection"       href="/introspection.html"/>
      <item name="Advanced Techniques" href="/advanced.html"/>
      <item name="XML-RPC Types"       href="/types.html"/>
      <item name="Download"            href="/download.html"/>
      <item name="FAQ"                 href="/faq.html"/>
      <item name="Contributing"        href="/contributing.html"/>
      <item name="XML-RPC 2"           href="http://ws.apache.org/xmlrpc/xmlrpc2"/>
      <item name="Links"               href="/links.html"/>
    </menu>

    ${reports}

  </body></project>

 =======================================================================
 ==src/site/xdoc/changes.xml
 =======================================================================
 <?xml version="1.0"?>
<document>
  <properties>
    <title>Changes</title>
    <author email="sgoeschl@apache.org">Siegfried Goeschl</author>
  </properties>

  <body>
    <release version="2.x-streaming-dev">
      <action dev="jochen">
        Complete rewrite with vendor extensions.
      </action>
    </release>
    <release version="2.0-beta" date="2005-Apr-27">
      <action dev="sgoeschl" type="fix">
        Fixed broken ANT build after upgrading to commons-codec-1.3.jar
      </action>          
      <action dev="sgoeschl" type="update">
        Upgrading to commons-codec-1.3.jar
      </action>          
      <action dev="hgomez" type="update">
        Upgrading to Apache Licence 2.0
      </action>    
      <action dev="hgomez" type="update">
        CommonsXmlRpcTransport support gzip compression for request and reply 
      </action>    
      <action dev="sgoeschl" type="update">
        Rewrote the xdocs/changes.xml to be used with the Maven build        
      </action>    
      <action dev="sgoeschl" type="update">
        Removed the dependency of fesi-1.1.5.jar since it is not used
        with the current Ant/Maven build
      </action>    
      <action dev="sgoeschl" type="update">
        Updated the Maven build to run nicely with Maven 1.0.2
      </action>    
      <action dev="sgoeschl" type="update">
        Updated the ANT build to download dependend JARs automagically
      </action>    
    </release>
  </body>
</document>