<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Axis Reference Guide</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<link href="axis.css" rel="stylesheet" type="text/css">
</head>
<body>
<h1 align="center"><img height="96" src="images/axis.jpg" width="176"></h1>
<h1>Axis Reference Guide</h1>
<i>1.2 Version</i>
<br>
<i>Feedback: <a href="mailto:axis-dev@ws.apache.org">axis-dev@ws.apache.org</a></i>
<h3>Table of Contents</h3>
<ul>
<li><a href="#Tools">Tools Reference</a></li>
<ul>
<li><a href="#WSDL2Java">WSDL2Java</a></li>
<li><a href="#Java2WSDL">Java2WSDL</a></li>
<li><a href="#Java2WSDL">Java2WSDL</a></li>
</ul>
<li><a href="#Deployment">Deployment (WSDD) Reference</a></li>
<li><a href="#global_configuration">Global Axis Configuration</a></li>
<li><a href="#individual_service">Individual Service Configuration</a></li>
<li><a href="#axis_logging">Axis Logging Configuration</a></li>
<li><a href="#axis_components">Pre-Configured Axis Components
Reference</a></li>
</ul>
<h2> <a name="Tools"></a>Tools Reference</h2>
<h3><a name="WSDL2Java"></a>WSDL2Java Reference</h3>
<p>Usage: java org.apache.axis.wsdl.WSDL2Java [options] WSDL-URI <br>
Options: <br>
-h, --help <br>
print this message and exit <br>
-v, --verbose <br>
print informational messages <br>
-n, --noImports <br>
only generate code for the immediate WSDL document <br>
-O, --timeout
<argument> <br>
timeout in seconds (default is 45, specify -1 to disable) <br>
-D, --Debug <br>
print debug information <br>
-W, --noWrapped<br>
turn off support for "wrapped" document/literal<br>
-s, --server-side <br>
emit server-side bindings for web service <br>
-S, --skeletonDeploy
<argument> <br>
deploy skeleton (true) or implementation (false) in deploy.wsdd. <br>
Default is false. Assumes --server-side. <br>
-N, --NStoPkg
<argument>=<value> <br>
mapping of namespace to package <br>
-f, --fileNStoPkg
<argument> <br>
file of NStoPkg mappings (default NStoPkg.properties) <br>
-p, --package
<argument> <br>
override all namespace to package mappings, use this package <br>
name instead <br>
-o, --output
<argument> <br>
output directory for emitted files <br>
-d, --deployScope
<argument> <br>
add scope to deploy.xml: "Application", "Request", "Session" <br>
-t, --testCase <br>
emit junit testcase class for web service <br>
-a, --all <br>
generate code for all elements, even unreferenced ones <br>
-T, --typeMappingVersion <br>
indicate 1.1 or 1.2. The default is 1.1 (SOAP 1.1 JAX-RPC compliant.
1.2 indicates SOAP 1.1 encoded.) <br>
-F, --factory
<argument> <br>
name of a custom class that implements GeneratorFactory interface
(for extending Java generation functions)<br>
-i, --nsInclude
<namespace><br>
namescape to specifically include in the generated code (defaults to
all namespaces unless specifically excluded with the -x option)<br>
-x, --nsExclude
<namespace><br>
namespace to specifically exclude from the generated code (defaults to
none excluded until first namespace included with -i option)<br>
-p, --property
<name>=<value><br>
name and value of a property for use by the custom GeneratorFactory<br>
-H, --helperGen <br>
emits separate Helper classes for meta data <br>
-U, --user <argument> <br>
username to access the WSDL-URI <br>
-P, --password
<argument> <br>
password to access the WSDL-URI <br>
-c, --implementationClassName
<argument> <br>
use this as the implementation class <br>
-w, --wrapArrays
<br>
Prefer generating JavaBean classes like "ArrayOfString" for certain schema array patterns (default is to use String []) <br>
</p>
<h4> -h, --help</h4>
Print the usage statement and exit
<h4> -v, --verbose</h4>
See what the tool is generating as it is generating it.
<h4> -n, --noImports</h4>
Only generate code for the WSDL document that appears on the command
line. The default behaviour is to generate files for all WSDL
documents, the immediate one and all imported ones.
<h4> -O, --timeout</h4>
Timeout in seconds. The default is 45. Use -1 to disable the timeout.
<h4> -D, --Debug</h4>
Print debug information, which currently is WSDL2Java's symbol table.
Note that this is only printed after the symbol table is complete, ie.,
after the WSDL is parsed successfully.
<h4>-W, --noWrapped</h4>
This turns off the special treatment of what is called "wrapped"
document/literal
style operations. By default, WSDL2Java will recognize the
following
conditions:<br>
<ul>
<li>If an input message has is a single part.</li>
<li>The part is an element.</li>
<li>The element has the same name as the operation</li>
<li>The element's complex type has no attributes<br>
</li>
</ul>
When it sees this, WSDL2Java will 'unwrap' the top level element, and
treat each of the components of the element as arguments to the
operation. This type of WSDL is the default for Microsoft .NET web
services, which wrap up RPC style arguments in this top level schema
element.
<h4> -s, --server-side</h4>
Emit the server-side bindings for the web service:
<ul>
<li> a skeleton class named <bindingName>Skeleton. This
may or may not be emitted (see -S, --skeletonDeploy).</li>
<li> an implementation template class named
<bindingName>Impl. Note that, if this class already exists,
then it is not emitted.</li>
<li> deploy.wsdd</li>
<li> undeploy.wsdd</li>
</ul>
<h4> -S, --skeletonDeploy <argument></h4>
Deploy either the skeleton (true) or the implementation (false) in
deploy.wsdd. In other words, for "true" the service clause in the
deploy.wsdd file will look something like:
<pre class="example"><service name="AddressBook" provider="java:RPC"><br> <parameter name="className" value="samples.addr.AddressBookSOAPBindingSkeleton"/><br> ...<br></service></pre>
<p>and for "false" it would look like: </p>
<pre class="example"><service name="AddressBook" provider="java:RPC"><br> <parameter name="className" value="samples.addr.AddressBookSOAPBindingImpl"/><br> ...<br></service></pre>
<p>The default for this option is false. When you use this
option, the --server-side option is assumed, so you don't have to
explicitly specify --server-side as well. </p>
<h4> -N, --NStoPkg <argument>=<value></h4>
By default, package names are generated from the namespace strings in
the WSDL document in a magical manner (typically, if the namespace is
of the form "http://x.y.com" or "urn:x.y.com" the corresponding package
will be "com.y.x"). If this magic is not what you want, you can
provide your own mapping using the --NStoPkg argument, which can be
repeated as often as necessary, once for each unique namespace
mapping. For example, if there is a namespace in the WSDL
document called "urn:AddressFetcher2", and you want files generated
from the objects within this namespace to reside in the package
samples.addr, you would provide the following option to WSDL2Java:
<pre>--NStoPkg urn:AddressFetcher2=samples.addr</pre>
(Note that if you use the short option tag, "-N", then there must not
be a space between "-N" and the namespace.) <br>
<h4> -f, --fileNStoPkg <argument></h4>
If there are a number of namespaces in the WSDL document, listing a
mapping for them all could become tedious. To help keep the
command line terse, WSDL2Java will also look for mappings in a
properties file. By default, this file is named
"NStoPkg.properties" and it must reside in the default package (ie., no
package). But you can explicitly provide your own file using the
--fileNStoPkg option.
<p>The entries in this file are of the same form as the arguments to
the --NStoPkg command line option. For example, instead of
providing the command line option as above, we could provide the same
information in NStoPkg.properties: </p>
<pre>urn\:AddressFetcher2=samples.addr</pre>
(Note that the colon must be escaped in the properties file.)
<p>If an entry for a given mapping exists both on the command line and
in the properties file, the command line entry takes precedence. </p>
<h4> -p, --package <argument></h4>
This is a shorthand option to map all namespaces in a WSDL document to
the same Java package name. This can be useful, but
dangerous. You must make sure that you understand the effects of
doing this. For instance there may be multiple types with the
same name in different namespaces. It is an error to use the
--NStoPkg switch and --package at the same time.
<h4> -o, --output <argument></h4>
The root directory for all emitted files.
<h4> -d, --deployScope <argument></h4>
Add scope to deploy.wsdd: "Application", "Request", or "Session".
If this option does not appear, no scope tag appears in deploy.wsdd,
which the Axis runtime defaults to "Request".
<h4> -t, --testCase</h4>
Generate a client-side JUnit test case. This test case can stand
on its own, but it doesn't really do anything except pass default
values (null for objects, 0 or false for primitive types). Like
the generated implementation file, the generated test case file could
be considered a template that you may fill in.
<h4> -a, --all</h4>
Generate code for all elements, even unreferenced ones. By
default, WSDL2Java only generates code for those elements in the WSDL
file that are referenced.
<p>A note about what it means to be referenced. We cannot simply
say: start with the services, generate all bindings referenced by
the service, generated all portTypes referenced by the referenced
bindings, etc. What if we're generating code from a WSDL file
that only contains portTypes, messages, and types? If WSDL2Java
used service as an anchor, and there's no service in the file, then
nothing will be generated. So the anchor is the lowest element
that exists in the WSDL file in the order: <br>
</p>
<ol>
<li>types </li>
<li>portTypes </li>
<li>bindings </li>
<li>services </li>
</ol>
<p>For example, if a WSDL file only contained types, then all the
listed types would be generated. But if a WSDL file contained
types and a portType, then that portType will be generated and only
those types that are referenced by that portType.
</p>
<p>Note that the anchor is searched for in the WSDL file appearing on
the command line, <b>not</b> in imported WSDL files. This allows one
WSDL file to import constructs defined in another WSDL file without the
nuisance of having all the imported WSDL file's constructs generated.
</p>
<h4> -T, --typeMappingVersion <argument></h4>
Indicate 1.1 or 1.2. The default is 1.2 (SOAP 1.2 JAX-RPC
compliant).
<h4> -F, --factory <argument></h4>
Used to extend the functionality of the WSDL2Java emitter. The argument
is the name of a class which extends JavaWriterFactory.
<h4> -H, --helperGen</h4>
Emits separate Helper classes for meta data.
<h4> -U, --user <argument></h4>
This username is used in resolving the WSDL-URI provided as the input
to WSDL2Java. If the URI contains a username, this will override
the command line switch. An example of a URL with a username and
password is: <code>http://user:password@hostname:port/path/to/service?WSDL</code><br>
<h4> -P, --password <argument></h4>
This password is used in resolving the WSDL-URI provided as the input
to WSDL2Java. If the URI contains a password, this will override
the command line switch. <br>
<h4> -c, --implementationClassName <argument></h4>
<p>Set the name of the implementation class.Especially useful when
exporting an existing class as a web service using java2wsdl
followed by wsdl2java. If you are using the skeleton deploy option you must make sure, after generation,
that your implementation class implements the port type name interface generated
by wsdl2java. You should also make sure that all your exported methods throws
java.lang.RemoteException.
</p>
<h4> -w, --wrapArrays</h4>
<p>When processing a schema like this:</p>
<pre>
<element name="array">
<complexType>
<sequence>
<element name="item" type="xs:string"/>
</sequence>
</complexType>
</element>
</pre>
The default behavior (as of Axis 1.2 final) is to map this XML construct to a Java String array (String[]). If you would rather a specific JavaBean class (i.e. ArrayOfString) be generated for these types of schemas, you may specify the -w or --wrapArrays option.
</p>
<br>
<h3><a name="Java2WSDL"></a>Java2WSDL Reference</h3>
<p>Here is the help message generated from the current tool: </p>
<p><font color="#993366">
<pre>
Java2WSDL emitter
Usage: java org.apache.axis.wsdl.Java2WSDL [options] class-of-portType
Options:
-h, --help
print this message and exit
-I, --input <argument>
input WSDL filename
-o, --output <argument>
output WSDL filename
-l, --location <argument>
service location url
-P, --portTypeName <argument>
portType name (obtained from class-of-portType if not specified)
-b, --bindingName <argument>
binding name (--servicePortName value + "SOAPBinding" if not
specified)
-S, --serviceElementName <argument>
service element name (defaults to --servicePortName value +
"Service")
-s, --servicePortName <argument>
service port name (obtained from --location if not specified)
-n, --namespace <argument>
target namespace
-p, --PkgtoNS <argument>=<value>
package=namespace, name value pairs
-m, --methods <argument>
space or comma separated list of methods to export
-a, --all
look for allowed methods in inherited class
-w, --outputWsdlMode <argument>
output WSDL mode: All, Interface, Implementation
-L, --locationImport <argument>
location of interface wsdl
-N, --namespaceImpl <argument>
target namespace for implementation wsdl
-O, --outputImpl <argument>
output Implementation WSDL filename, setting this causes
--outputWsdlMode to be ignored
-i, --implClass <argument>
optional class that contains implementation of methods in
class-of-portType. The debug information in the class is used
to obtain the method parameter names, which are used to set
the WSDL part names.
-x, --exclude <argument>
space or comma separated list of methods not to export
-c, --stopClasses <argument>
space or comma separated list of class names which will stop
inheritance search if --all switch is given
-T, --typeMappingVersion <argument>
indicate 1.1 or 1.2. The default is 1.1 (SOAP 1.1 JAX-RPC
compliant 1.2 indicates SOAP 1.1 encoded.)
-A, --soapAction <argument>
value of the operation's soapAction field. Values are DEFAULT,
OPERATION or NONE. OPERATION forces soapAction to the name
of the operation. DEFAULT causes the soapAction to be set
according to the operation's meta data (usually ""). NONE
forces the soapAction to "". The default is DEFAULT.
-y, --style <argument>
The style of binding in the WSDL, either DOCUMENT, RPC, or WRAPPED.
-u, --use <argument>
The use of items in the binding, either LITERAL or ENCODED
-e, --extraClasses <argument>
A space or comma separated list of class names to be added to
the type section.
-C, --importSchema
A file or URL to an XML Schema that should be physically
imported into the generated WSDL
-X, --classpath
additional classpath elements
Details:
portType element name= <--portTypeName value> OR <class-of-portType name>
binding element name= <--bindingName value> OR <--servicePortName value>Soap
Binding
service element name= <--serviceElementName value> OR <--portTypeName value>
Service
port element name= <--servicePortName value>
address location = <--location value>
</pre>
</font>
<br>
</p>
<p><b>-h , --help</b> <br>
Prints the help message. </p>
<p><b>-I, --input <WSDL file></b> <br>
Optional parameter that indicates the name of the input wsdl file. The
output wsdl file will contain everything from the input wsdl file plus
the new constructs. If a new construct is already present in the input
wsdl file, it is not added. This option is useful for constructing a
wsdl file with multiple ports, bindings, or portTypes.
</p>
<p><b>-o, --output <WSDL file></b> <br>
Indicates the name of the output WSDL file. If not specified, a
suitable default WSDL file is written into the current directory. </p>
<p><b>-l, --location <location></b> <br>
Indicates the url of the location of the service. The name after
the last slash or backslash is the name of the service port (unless
overridden by the -s option). The service port address location
attribute is assigned the specified value. </p>
<p><b>-P, --portTypeName <name></b> <br>
Indicates the name to use use for the portType element. If not
specified, the class-of-portType name is used. </p>
<p><b>-b, --bindingName <name></b> <br>
Indicates the name to use use for the binding element. If not
specified, the value of the --servicePortName + "SoapBinding" is used. </p>
<p><b>-S, --serviceElementName <name></b> <br>
Indicates the name of the service element. If not specified, the
service element is the <portTypeName>Service. </p>
<p><b>-s, --servicePortName <name></b> <br>
Indicates the name of the service port. If not specified, the
service port name is derived from the --location value. </p>
<p><b>-n, --namespace <target namespace></b> <br>
Indicates the name of the target namespace of the WSDL. </p>
<p><b>-p, --PkgToNS <package> <namespace></b> <br>
Indicates the mapping of a package to a namespace. If a package
is encountered that does not have a namespace, the Java2WSDL emitter
will generate a suitable namespace name. This option may be
specified multiple times. </p>
<p><b>-m, --methods <arguments></b> <br>
If this option is specified, only the indicated methods in your
interface class will be exported into the WSDL file. The methods
list must be comma separated. If not specified, all methods
declared in the interface class will be exported into the WSDL file. </p>
<p><b>-a, --all</b> <br>
If this option is specified, the Java2WSDL parser will look into
extended classes to determine the list of methods to export into the
WSDL file. </p>
<p><b>-w, --outputWSDLMode <mode></b> <br>
Indicates the kind of WSDL to generate. Accepted values are: </p>
<ul>
<li> All --- (default) Generates wsld containing both interface and
implementation WSDL constructs.</li>
<li> Interface --- Generates a WSDL containing the interface
constructs (no service element).</li>
<li> Implementation -- Generates a WSDL containing the
implementation. The interface WSDL is imported via the -L option.</li>
</ul>
<b>-L, --locationImport <url></b> <br>
Used to indicate the location of the interface WSDL when generating an
implementation WSDL.
<p><b>-N, --namespaceImpl <namespace></b> <br>
Namespace of the implementation WSDL. </p>
<p><b>-O, --outputImpl <WSDL file></b> <br>
Use this option to indicate the name of the output implementation WSDL
file. If specified, Java2WSDL will produce interface and
implementation WSDL files. If this option is used, the -w option
is ignored. </p>
<p><b>-i, --implClass <impl-class></b> <br>
Sometimes extra information is available in the implementation class
file. Use this option to specify the implementation class. </p>
<p><b>-x, --exclude <list></b> <br>
List of methods to not exclude from the wsdl file. </p>
<p><b>-c, --stopClasses <list></b> <br>
List of classes which stop the Java2WSDL inheritance search. </p>
<p><b>-T, --typeMappingVersion <version></b> <br>
Choose the default type mapping registry to use. Either 1.1 or 1.2.</p>
<p><b>-A, --soapAction <argument></b> <br>
The value of the operations soapAction field. Values are DEFAULT,
OPERATION or NONE. OPERATION forces soapAction to the name of the
operation. DEFAULT causes the soapAction to be set according to the
operation's meta data (usually ""). NONE forces the soapAction to "".
The default is DEFAULT.
</p>
<p><b>-y, --style <argument></b> <br>
The style of the WSDL document: RPC, DOCUMENT or WRAPPED. The default
is RPC. If RPC is specified, an rpc wsdl is generated. If DOCUMENT is
specified, a document wsdl is generated. If WRAPPED is specified, a
document/literal wsdl is generated using the wrapped approach. Wrapped
style forces the use attribute to be literal.
</p>
<p><b>-u, --use <argument></b><br>
The use of the WSDL document: LITERAL or ENCODED. If LITERAL is
specified, the XML Schema defines the representation of the XML for the
request. If ENCODED is specified, SOAP encoding is specified in the
generated WSDL. </p>
<p><b>-e, --extraClasses <argument></b><br>
Specify a space or comma seperated list of class names which should be
included in the <b>types</b> section of the WSDL document. This is
useful in the case where your service interface references a base class
and you would like your WSDL to contain XML Schema type defintions for
these other classes. The -extraClasses option can be specified
duplicate times. Each specification results in the additional classes
being added to the list.
</p>
<p> <strong>-C, --importSchema</strong><br>
A file or URL to an XML Schema that should be physically imported into the generated WSDL</p>
<p><br>
<strong>-X, --classpath</strong><br>
Additional classpath elements</p>
<p> </p>
<h2><a name="Deployment"></a>Deployment (WSDD) Reference</h2>
Note : all the elements referred to in this section are in the WSDD namespace,
namely "http://xml.apache.org/axis/wsdd/".
<dl>
<dt><b><font face="Courier New, Courier, mono"><deployment></font></b></dt>
<dd>The root element of the deployment document which tells the Axis engine
that this is a deployment. A deployment document may represent EITHER a complete
engine configuration OR a set of components to deploy into an active engine.</dd>
<dt><br>
<b><font face="Courier New, Courier, mono"><GlobalConfiguration></font></b></dt>
<dd>This element is used to control the engine-wide configuration of Axis. It
may contain several subelements:
<ul>
<li><b><parameter></b> : This is used to set options on the Axis engine
- see the <a href="#global_configuration">Global Axis Configuration</a>
section below for more details. Any number of <strong><parameter></strong>
elements may appear.</li>
<li><strong><role></strong> : This is used to set a SOAP actor/role
URI which the engine will recognize. This allows SOAP headers targeted
at that role to be successfully processed by the engine. Any number of
<strong><role></strong> elements may appear.</li>
<li><strong><requestFlow></strong> : This is used to configure global
request Handlers, which will be invoked before the actual service on every
request.</li>
</ul>
</dd>
<dd>
<ul>
<li><strong><responseFlow></strong> : This is used to configure global
response Handlers, which will be invoked after the actual service on every
request.</li>
</ul>
</dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><requestFlow [name="</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">"] [type="</font></b><font
face="Courier New, Courier, mono"><i>type</i></font><b><font
face="Courier New, Courier, mono">"] ></font></b></dt>
<dd>This is used to configure handlers in request flow. You may put any number of <strong><handler></strong> or
<strong><chain></strong> elements (see below) inside the <strong><requestFlow></strong>,
but there may only be one <strong><requestFlow></strong>.</dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><responseFlow [name="</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">"] [type="</font></b><font
face="Courier New, Courier, mono"><i>type</i></font><b><font
face="Courier New, Courier, mono">"] ></font></b></dt>
<dd>This is used to configure handlers in response flow. You may put any number of <strong><handler></strong> or
<strong><chain></strong> elements (see below) inside the <strong><responseFlow></strong>,
but there may only be one <strong><responseFlow></strong>.</dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><undeployment></font></b></dt>
<dd>The root element of the deployment document which tells Axis that this is
an undeployment.</dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><handler [name="</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">"] type="</font></b><font
face="Courier New, Courier, mono"><i>type</i></font><b><font
face="Courier New, Courier, mono">"></font></b></dt>
<dd>Belongs at the top level inside a <b><deployment></b> or <b><undeployment></b>,
or inside a <b><chain></b>, <b><requestFlow></b>, or <b><responseFlow></b>.
Defines a Handler, and indicates the type of the handler. "Type" is either
the name of another previously defined Handler, or a QName of the form "<b>java:<i>class.name</i></b>".
The optional "name" attribute allows you to refer to this Handler definition
in other parts of the deployment. May contain an arbitrary number of <b><font
face="Courier New, Courier, mono"><parameter name="</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">" value="</font></b><font
face="Courier New, Courier, mono"><i>value</i></font><b><font
face="Courier New, Courier, mono">"></font></b> elements, each of which will
supply a parameter to the deployed Handler.</dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><service name="</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">" provider="</font></b><font
face="Courier New, Courier, mono"><i>provider</i></font><b><font
face="Courier New, Courier, mono">" ></font></b></dt>
<dd>Deploys/undeploys an Axis Service. This is the most complex WSDD tag, so
we're going to spend a little time on it.<br>
<br>
<b>Options</b> may be specified as follows : <code><b><parameter name="</b>name<b>"
value="</b>value<b>"/></b></code>, and common ones include:<br>
<br>
<ul>
<li><b>className</b> : the backend implementation class<br>
</li>
<li><b>allowedMethods</b> : Each provider can determine which methods are
allowed to be exposed as web services. <br>
To summaries for Axis supplied providers:<br>
<p><u>Java RPC Provider</u> (provider="java:RPC") by default all public
methods specified by the class in the className option, including any
inherited methods are available as web services.<br>
For more details regarding the Java Provider please see <b>WHERE???</b>.
</p>
<p><u>Java MsgProvder</u> (provider="java:MSG")
<!-- Glen to provide details -->
</p>
<p>In order to further restrict the above methods, the <b>allowedMethods</b>
option may be used to specify in a space delimited list the names of
only those methods which are allowed as web services. It is also possible
to specify for this option the value <b>"*"</b> which is functionally
equivalent to not specify the option at all. Also, it is worth mentioning
that the <b>operation</b> element is used to further define the methods
being offered, but it does not affect which methods are made available.
</p>
<p><i>Note, while this is true for Axis supplied providers, it is implementation
dependent on each individual provider. Please review your providers
documentation on how or if it supports this option.</i> </p>
<p> <b><u>Note, Exposing any web service has security implications.</u><br>
</b>As a best practices guide it is <u>highly</u> recommend when offering
a web service in un secure environment to restrict allowed methods to
only those required for the service being offered. And, for those that
are made available, to <b>fully</b> understand their function and how
they may access and expose your systems's resources. </p>
<p> </p>
</li>
<li><b>allowedRoles</b> : comma-separated list of roles allowed to access
this service. (Note that these are security roles, as opposed to SOAP
roles. Security roles control access, SOAP roles control which SOAP headers
are processed.)</li>
<li><b>extraClasses</b> : Specify a space or comma seperated list of class
names which should be included in the <b>types</b> section of the WSDL document.
This is useful in the case where your service interface references a base class
and you would like your WSDL to contain XML Schema type defintions for these other classes.
</li>
</ul>
<p> If you wish to define handlers which should be invoked either before or
after the service's provider, you may do so with the <b><requestFlow></b>
and the <b><responseFlow></b> subelements. Either of those elements
may be specified inside the <b><service></b> element, and their semantics
are identical to the <b><chain></b> element described below - in other
words, they may contain <b><handler></b> and <b><chain</b>>
elements which will be invoked in the order they are specified.</p>
<p>To control the <a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soaproles">roles</a>
that should be recognized by your service Handlers, you can specify any
number of <b><role></b> elements inside the service declaration.</p>
Example:<br>
<pre>
<service name="test">
<parameter name="className" value="test.Implementation"/>
<parameter name="allowedMethods" value="*"/>
<namespace>http://testservice/</namespace>
<role>http://testservice/MyRole</role>
<requestFlow> <!-- Run these before processing the request -->
<handler type="java:MyHandlerClass"/>\
<handler type="somethingIDefinedPreviously"/>
</requestFlow>
</service>
</pre>
Metadata may be specified about particular operations in your service by using
the <operation> tag inside a service. This enables you to map the java
parameter names of a method to particular XML names, to specify the parameter
modes for your parameters, and to map particular XML names to particular operations.<br>
<br>
<operation name="method"><br>
</operation> <br>
</dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><chain name="</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">"</font></b><b><font
face="Courier New, Courier, mono">><br>
<<i>subelement</i>/>...<br>
</chain> </font></b></dt>
<dd>Defines a chain. Each <i>handler</i> (i.e. deployed handler name) in the
list will be invoked() in turn when the chain is invoked. This enables you
to build up "modules" of commonly used functionality. The subelements inside
chains may be <<b>handler</b>>s or <<b>chain</b>>s. <handler>s
inside a <chain> may either be defined in terms of their Java class:<br>
<pre><chain name="myChain"><br> <handler type="java:org.apache.axis.handlers.LogHandler"/><br></chain></pre>
or may refer to previously defined <handlers>, with the "type" of the
handler referring to the name of the other handler definition:<br>
<pre><handler name="logger" type="java:org.apache.axis.handlers.LogHandler"/><br><chain name="myChain"/><br> <handler type="logger"/><br></chain></pre>
</dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><transport name="</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">"></font></b></dt>
<dd>Defines a transport on the server side. Server transports are invoked when
an incoming request arrives. A server transport may define <b><requestFlow></b>
and/or <b><responseFlow></b> elements to specify handlers/chains which
should be invoked during the request (i.e. incoming message) or response (i.e.
outgoing message) portion of processing (this function works just like the
<b><service></b> element above). Typically handlers in the transport
request/response flows implement transport-specific functionality, such as
parsing protocol headers, etc.</dd>
<br>
<br>
<dd>For any kind of transport (though usually this relates to HTTP transports),
users may allow Axis servlets to perform arbitrary actions (by means of a
"plug-in") when specific query strings are passed to the servlet (see the
section <a
href="developers-guide.html#Axis%20Servlet%20Query%20String%20Plug-ins">Axis
Servlet Query String Plug-ins</a> in the <a
href="developers-guide.html">Axis Developer's Guide</a> for more information
on what this means and how to create a plug-in). When the name of a query
string handler class is known, users can enable it by adding an appropriate
<b><parameter></b> element in the Axis server configuration's <b><transport></b>
element. An example configuration might look like the following:<br>
<br>
<code> <transport name="http"><br>
<parameter name="useDefaultQueryStrings" value="false" /><br>
<parameter name="qs.name" value="class.name" /><br>
</transport><br>
</code><br>
In this example, the query string that the Axis servlet should respond to
is <i>?name</i> and the class that it should invoke when this query string
is encountered is named <code>class.name</code>. The <code>name</code> attribute
of the <b><parameter></b> element must start with the string "qs." to
indicate that this <b><parameter></b> element defines a query string
handler. The <code>value</code> attribute must point to the name of a class
implementing the <code>org.apache.axis.transport.http.QSHandler</code> interface.
By default, Axis provides for three Axis servlet query string handlers (<i>?list</i>,
<i>?method</i>, and <i>?wsdl</i>). See the Axis server configuration file
for their definitions. If the user wishes not to use these default query string
handlers (as in the example), a <b><parameter></b> element with a <code>name</code>
attribute equal to "useDefaultQueryStrings" should have its <code>value</code>
attribute set to <code>false</code>. By default it is set to <code>true</code>
and the element is not necessary if the user wishes to have this default behavior.
</dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><transport name="</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">" pivot="</font></b><font
face="Courier New, Courier, mono"><i>handler type</i><b>"</b></font><b><font
face="Courier New, Courier, mono"> ></font></b></dt>
<dd>Defines a transport on the client side, which is invoked when sending a
SOAP message. The "pivot" attribute specifies a Handler to be used as the
actual sender for this transport (for example, the HTTPSender). Request and
response flows may be specified as in server-side transports to do processing
on the request (i.e. outgoing message) or response (i.e. incoming message).</dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><typeMapping qname="</font></b><font
face="Courier New, Courier, mono"><i>ns:localName</i></font><b><font
face="Courier New, Courier, mono">" classname="</font></b><font
face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">" serializer="</font></b><font
face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">" deserializer="</font></b><font
face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">"/></font></b></dt>
<dd>Each typeMapping maps an XML qualified name to/from a Java class, using
a specified Serializer and Deserializer. </dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><beanMapping qname="</font></b><font
face="Courier New, Courier, mono"><i>ns:localName</i></font><b><font
face="Courier New, Courier, mono">" classname="</font></b><font
face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">"</font></b><b><font
face="Courier New, Courier, mono">></font></b></dt>
<dd><b></b>A simplified type mapping, which uses pre-defined serializers/deserializers
to encode/decode JavaBeans. The class named by "classname" must follow the
JavaBean standard pattern of get/set accessors.</dd>
<dt> </dt>
<dt><b><font face="Courier New, Courier, mono"><documentation></font></b></dt>
<dd>Can be used inside a <b><service></b>, an <b><operation></b>
or an operation <b><parameter></b>. The content of the element is arbitrary
text which will be put in the generated wsdl inside a wsdl:document element.<br>
<br>
Example:<br>
<code><operation name="echoString" ><br>
<documentation>This operation echoes a string</documentation><br>
<parameter name="param"><br>
<documentation>a string</documentation><br>
</parameter><br>
</operation> </code> </dd>
</dl>
<p> </p>
<h2><a name="global_configuration">Global Axis Configuration</a></h2>
The server is configured (by default) by
values in the
server-config.wsdd file, though a dedicated Axis user can write their
own configuration handler, and so store configuration data in an LDAP
server, database, remote web service, etc. Consult the source on
details
as to how to do that. You can also add options to the web.xml file and
have them picked up automatically. We don't encourage that as it is
nice
to keep configuration stuff in one place.
<p>In the server-config file, there is
a global configuration section,
which supports parameter name/value pairs as nested elements. Here are
the options that we currently document, though there may be more
(consult the source, as usual). </p>
<pre>
<globalConfiguration>
<parameter name="adminPassword" value="admin"/>
<parameter name="axis.servicesPath" value="/services/"/>
<parameter name="attachments.Directory" value="c:\temp\attachments"/>
<parameter name="sendMultiRefs" value="true"/>
<parameter name="sendXsiTypes" value="true"/>
<parameter name="attachments.implementation" value="org.apache.axis.attachments.AttachmentsImpl"/>
<parameter name="sendXMLDeclaration" value="true"/>
<parameter name="enable2DArrayEncoding" value="true"/>
<parameter name="dotNetSoapEncFix" value="false"/>
</globalConfiguration>
</pre>
<table>
<tbody>
<tr>
<td><b>adminPassword</b></td>
<td>Adminstrator password, as used by AdminService. </td>
</tr>
<tr>
<td><b>attachments.Directory</b></td>
<td>The directory where attachments end up. This should be in the
syntax appropriate for the target platform. </td>
</tr>
<tr>
<td><b>attachments.implementation</b></td>
<td> Name of class that implements attachments support. Default
is <tt>org.apache.axis.attachments.AttachmentsImpl</tt> </td>
</tr>
<tr>
<td><b>axis.enableListQuery</b></td>
<td>Flag to enable the "list the WSDD" feature. Set to false by
default, because listing the current system config can expose
information (such as the adminservice password) that one does not want
widely avaialable. </td>
</tr>
<tr>
<td><b>axis.disableServiceList</b></td>
<td>Flag to disable the list of services feature. Set to false by
default, which enables the list of services by the AxisServlet when a GET
request is performed on the servlet root.</td>
</tr>
<tr>
<td><b>axis.servicesPath</b></td>
<td>Path to the Axis servlet. This should be the same as the services
servlet-mapping defined in web.xml. Used for displaying
the list of services. Default is "/services/".</td>
</tr>>
<tr>
<td><b>axis.Compiler</b></td>
<td>Compiler adapter classname for JWS compilation. Default is <tt>org.apache.axis.components.compiler.Javac</tt>;
change this to <tt>org.apache.axis.components.compiler.Jikes</tt> to
invoke jikes instead. </td>
</tr>
<tr>
<td><b>axis.development.system</b></td>
<td>Flag to switch the system from <i>production</i> (false) to <i>development</i>
(true). A development system gives out stack traces and other
information that production boxes should not. </td>
</tr>
<tr>
<td><b>axis.xmlEncoding</b></td>
<td>Encoding used for XML messages -either UTF-8 (default) or
UTF-16</td>
</tr>
<tr>
<td><b>axis.engineConfigClass</b></td>
<td>Name of a class that provides Axis configuration. Implement a
new class implementing <tt>EngineConfiguration</tt> and name it here
to use alternate configuration mechanisms. </td>
</tr>
<tr>
<td><b>axis.jws.servletClassDir</b></td>
<td>Path to where compiled JWS pages are placed. </td>
</tr>
<tr>
<td><b>axis.sendMinimizedElements</b></td>
<td>Flag to turn on support for a when .NET1.0 can't correctly
handle some bits of XML <a
href="http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17021"> that
it should. </a> The flag defaults to true; if some .NET clients are
failing to handle a Web Service returning an empty array inside another
object, set this flag to <i>false</i>. </td>
</tr>
<tr>
<td><b>enable2DArrayEncoding</b></td>
<td>Set this to "true" to turn 2D array encoding on; this
encoding is incompatible with .NET 1.0: default="false". </td>
</tr>
<tr>
<td><b>sendMultiRefs</b></td>
<td>true/false flag to control whether multirefs are sent or not.
</td>
</tr>
<tr>
<td><b>sendXMLDeclaration</b></td>
<td>true/false flag to control whether the <?xml?>
declaration is sent in messages </td>
</tr>
<tr>
<td><b>sendXsiTypes</b></td>
<td>true/false flag to enable/disable sending the type of every
value sent over the wire. Defaults to true. </td>
</tr>
<tr>
<td><strong>SingleSOAPVersion</strong></td>
<td>When set to either "1.1" or "1.2", this configures the engine
to only accept the specified SOAP version. Attempts to connect to the
engine using another version will result in a fault.</td>
</tr>
<tr>
<td><b>use-servlet-security</b></td>
<td>Set this flag to hand authentication off to the servlet
container. </td>
</tr>
<tr>
<td><b>dotNetSoapEncFix</b></td>
<td>Set this flag to true to turn on a preference for the XML Schema (xsd) types in the
Axis engine. This improved interop with .NET. In particular, .NET seems to have problems
accepting SOAP encoded types (soapenc) in arrays. Due to bugs in the Axis 1.1 type mapping
system, Axis generally perferred the schema types. Axis 1.2 now correctly uses the SOAP
encoded types when it is using SOAP encoding for a service. See JAX-RPC 1.1, section 4.2.1.
Note: You can also set this flag by setting the static property on the TypeMappingImpl class:
<pre>TypeMappingImpl.dotnet_soapenc_bugfix = true;</pre>
</td>
</tr>
<!-- end table -->
</tbody>
</table>
<h2><a name="individual_service">Individual Service Configuration</a></h2>
<p>Here is a service element with examples of the current set of options you can set. More may exists (consult the source, as usual).</p>
<pre>
<service name="MyServiceName"
provider="java:RPC"
style="rpc|document|wrapped"
use="encoded|literal"
streaming="off|on"
attachment="MIME|DIME|NONE">
<parameter name="className" value="org.apache.mystuff.MyService"/>
<parameter name="allowedMethods" value="method1 method2 method3"/>
<parameter name="wsdlTargetNamespace" value="http://mystuff.apache.org/MyService"/>
<parameter name="wsdlServiceElement" value="MyService"/>
<parameter name="wsdlServicePort" value="MyServicePort"/>
<parameter name="wsdlPortType" value="MyPort"/>
<parameter name="wsdlSoapActionMode" value="NONE|DEFAULT|OPERATION"/>
<parameter name="SingleSOAPVersion" value="1.1|1.2/>
<documentation>Service level info</documentation>
<endpointURL>http://example.com:5050/my/custom/url/to/service</endpointURL>
<wsdlFile>/path/to/wsdl/file</wsdlFile>
<namespace>http://my.namespace.com/myservice</namespace>
<handlerInfoChain>handlerChainName</handlerInfoChain>
<operation ... />
<typeMapping ... />
<beanMapping ... />
</service></pre>
<h3>Service Element Attributes</h3>
<h4>name</h4>
The name of the service.
<h4>provider</h4>
The provider for the service. The recognized providers are: java:RPC, java:MSG,
java:EJB, java:COM, java:BSF, java:CORBA, java:RMI and "Handler"
where <tt>xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"</tt>. The RPC provider supports
both rpc/encoded, document/literal and wrapped/literal services. the MSG provider supports the
'fixed signature' service which takes XML in and returns XML our directly. The other providers must be
built in to Axis. See the code in org.apache.axis.providers.
<h4>style</h4>
The style of the service.
"rpc" uses the RPC style of wrapping the parts of the message an element that has the same name
as the operation.
"document" style means the messages in and out of the service are exactly as
they are describe by the XML Schema in the WSDL.
"wrapped" is a subset of the document style. The arguments to the operation are wrapped up in and
element that has the same name as the operation. This is the style of service .NET generates by
default. The generated WSDL specifies document style (and literal use) but Axis will 'unwrapped'
the parts of the message for the Axis service at the back end.
<h4>use</h4>
This can be either "encoded" or "literal". Encoded means the SOAP 1.1 "Section 5 Encoding" is used to
encode the data structures returned by the service and incoming XML is decoded using the same rules.
Literal use means no such encoding is performed.
<h4>streaming</h4>
Valid values are "on" or "off". This turns on or off the streaming mode of the XML deserializer.
The default is currently off. Certain Axis functionality may not function properly if this is turned
on. Use with caution.
<h4>attachment</h4>
Valied values are "MIME" for SOAP with attachements (SwA), "DIME" for DIME support and "NONE" for no attachement
support at all. The default mode of Axis is to use MIME attachements (SwA).
<h3>Elements allowed in the Service element</h3>
<h4><wsdlFile></h4>
<p>The path to a WSDL File; can be an absolute path or a
resource that axis.jar can load. Useful to export your custom WSDL
file. When specify a path to a resource, place a forward slash to start
at the beginning of the classpath (e.g "/org/someone/res/mywsdl.wsdl").
How does Axis know whether to return a file or resource? It looks for a
file first, if that is missing a resource is returned. </p>
<h4><documentation></h4>
<p>Documentation text that will get inserted in to the document element of the WSDL for the service</p>
<h4><endpointURL></h4>
<p>Specify the endpoint URL of the service, which will override the transport level URL
created by the Axis servlet. This is usefull if you have a proxy handling requests
and you need the endpoint URL to reflect a different hostname than the one Axis is
executing on.</p>
<h4><namespace></h4>
<p>Specify the default namespace for the service.</p>
<h4><handlerInfoChain></h4>
<p>Specify the JAX RPC handler chain for this service.</p>
<p>In addition, as described above, the <B><requestFlow></B> and/or <B><responseFlow></B> elements are also allowed in the service element.</p>
<p>
<h3>Service Level Parameters</h3>
The following parameters can be set on a service wide basis using the <parameter> tag. There may be more than those documented here, but this list should be almost complete.
<p>
<table cellpadding="2">
<tbody>
<tr>
<td><strong>className</strong></td>
<td>The fully qualified name of the implemenation class of the service.<br>
</td>
</tr>
<tr>
<td><strong>allowedMethods</strong></td>
<td>A space or comma seperated list of method names, or "*" for all methods in the service class.
If this parameter isn't specified, all methods ("*") is the default.
</td>
</tr>
<tr>
<td><strong>wsdlPortType</strong></td>
<td>The name of the portType element in the generated WSDL for the service.</td>
</tr>
<tr>
<td><strong>wsdlServiceElement</strong></td>
<td>The name of the Service element in the generated WSDL for the service.</td>
</tr>
<tr>
<td><strong>wsdlServicePort</strong></td>
<td>The name of the port in the generated WSDL for the service.</td>
</tr>
<tr>
<td><strong>wsdlTargetNamespace</strong></td>
<td>The target namespace in the generated WSDL for the service.</td>
</tr>
<tr>
<td><strong>wsdlInputSchema</strong></td>
<td>A comma separated list of of input Schema for the generated WSDL for the service.</td>
</tr>
<tr>
<td><strong>wsdlSoapActionMode</strong></td>
<td>Values are DEFAULT, OPERATION or NONE.
OPERATION forces soapAction to the name of the operation.
DEFAULT causes the soapAction to be set according to the
operations meta data, specifically the soapAction attribute of the operation
in the deployment information.
NONE forces the soapAction to "". The default is DEFAULT.</td>
</tr>
<tr>
<td><strong>SingleSOAPVersion</strong></td>
<td>When set to either "1.1" or "1.2", this configures a service
to only accept the specified SOAP version. Attempts to connect to the
service using another version will result in a fault.</td>
</tr>
</tbody>
</table>
<h2><a name="individual_operations">Individual Operation Configuration</a></h2>
<p>Here is an <tt><operation></tt> element with examples of the current set of options you can set. More may exists (consult the source, as usual).</p>
<pre>
<operation name="GetQuote"
qname="operNS:GetQuote"
returnQName="GetQuoteResult"
returnType="xsd:float"
soapAction=""
returnHeader="true|false">
<documentation>Operation level documentation here</documentation>
<parameter name="ticker" type="tns:string"/>
<fault name="InvalidTickerFaultMessage"
qname="tickerSymbol"
class="test.wsdl.faults.InvalidTickerFaultMessage"
type="xsd:string"/>
<br></operation>
</pre>
<p>The example above omits the XML Namespace declarations (xmlns:foo="http://my.namespace/") that could appear
in each of the elements for the namespaces used.</p>
<h3>Operation Attributes</h3>
<h4>name</h4>
The name of the operation. This would generally match the name of the function in your service implementation.
<h4>qname</h4>
The Qualified Name of the top level element for this operation. This is how Axis maps operations for document/literal services,
which do not have the operation name in the QName of the XML element on the wire.
<h4>returnQName</h4>
The Qualified Name of the XML element that is returned from this operation.
<h4>returnType</h4>
The Qualified Name of the return type.
<h4>returnHeader</h4>
If true, the return value of the operation is contained in a header.
<h4>soapAction</h4>
The value of the SOAPAction attribute for this operation in the WSDL generated for this service.
<h3>Elements allowed in the Operation Element</h3>
<h4><documentation></h4>
Documentation text that will get inserted in to the document element of the WSDL for the operation.
<h4><parameter></h4>
<p>Defines a parameter for the operation. Valid attributes are:</p>
<table>
<tr><td><strong>name</strong></td>
<td>The name of the parameter.</td></tr>
<tr><td><strong>qname</strong></td>
<td>The QName of the parameter, used in preference to name.</td>
</tr>
<tr><td><strong>mode</strong></td>
<td>The mode of the parameter. One of "in", "out" or "inout".</td></tr>
<tr><td><strong>inHeader</strong></td>
<td>If "true", this parameter is an input header.</td></tr>
<tr><td><strong>outHeader</strong></td>
<td>If "true", this parameter is an output header.</td></tr>
<tr><td><strong>type</strong></td>
<td>The QName of the type of the parameter.</td></tr>
</table>
<p>
<strong>NOTE:</strong> A <tt><documentation></tt> element may appear as a child of parameter.
</p>
<h4><fault></h4>
Defines the type information for each fault that the operation may throw.
Valid attributes are:</p>
<table>
<tr><td><strong>name</strong></td>
<td>The name of the fault.</td></tr>
<tr><td><strong>qname</strong></td>
<td>The QName of the fault.</td>
</tr>
<tr><td><strong>class</strong></td>
<td>The Java class that represents this fault.</td></tr>
<tr><td><strong>type</strong></td>
<td>The QName of the type that represents the data for this fault.</td></tr>
</table>
<h2><a name="axis_logging">Axis Logging Configuration</a></h2>
Axis uses the Jakarta Projects's
<a href="http://jakarta.apache.org/commons/logging.html">commons-logging API</a>,
as implemented in <tt>commons-logging.jar</tt> to implement logging
throughout the code. Normally
this library routes the logging to the Log4j library, provided that an
implementation of log4j is on the classpath of the server or client.
The
commons-logging API can also bind to Avalon, <tt>System.out</tt> or
the Java1.4
logger. The JavaDocs for the library explain the process for selecting
a logger,
which can be done via a system property or a properties file in the
classpath.
<p>Log4J can be configured using the file log4j.properties in the
classpath; later
versions also support an XML configuration. Axis includes a
preconfigured
log4j.properties file in <tt>axis.jar</tt>. While this is adequate for
basic use,
any complex project will want to modify their own version of the file.
Here is
what to do </p>
<ol>
<li>Open up axis.jar in a zipfile viewer and remove log4j.properties
from the jar
</li>
<li>Or, when building your own copy of axis.jar, set the Ant property
<tt>exclude.log4j.configuration</tt> to keep the properties file
out the JAR.
</li>
<li>Create your own log4J.properties file, and include it in <tt>WEB-INF/classes</tt>
(server-side), in your main application JAR file client side.
</li>
<li>Edit this log4J properties file to your hearts content. Server
side,
setting up rolling logs with fancy html output is convenient, though
once you
start clustering the back end servers that ceases to be as usuable.
Log4J power tools,
such as 'chainsaw', are the secret here.
</li>
</ol>
<h3>Log Categories</h3>
Axis classes that log information create their own per-class log, each
of which
may output information at different levels. For example, the main entry
point
servlet has a log called <tt>org.apache.axis.transport.http.AxisServlet</tt>,
the AxisEngine is <tt>org.apache.axis.AxisEngine</tt>, and so on.
There are
also special logs for special categories.
<p>
<table border="0">
<tbody>
<tr>
<td valign="top"><tt>org.apache.axis.TIME</tt></td>
<td>A log that records the time to execute incoming messages,
splitting up into preamble, invoke, post and send times. These are only
logged at debug level.
</td>
</tr>
<tr>
<td valign="top"><tt>org.apache.axis.EXCEPTIONS</tt></td>
<td>Exceptions that are sent back over the wire. AxisFaults,
which are normally created in 'healthy' operation, are logged at debug
level. Other Exceptions are logged at the Info level, as they are more
indicative of server side trouble.
</td>
</tr>
<tr>
<td valign="top"><tt>org.apache.axis.enterprise</tt></td>
<td>''Enterprise'' level stuff, which generally means stuff that
an enterprise product might want to track, but in a simple environment
(like the Axis build) would be nothing more than a nuisance. </td>
</tr>
</tbody>
</table>
<a name="axis_components">
</a></p>
<h2><a name="axis_components">Pre-Configured Axis Components Reference</a></h2>
<h3><a name="axis_components">On the server:</a></h3>
<dl>
<dt><a name="axis_components"><b>SimpleSessionHandler</b> </a></dt>
<dd><a name="axis_components">uses SOAP headers to do simple session
management </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>LogHandler</b> </a></dt>
<dd><a name="axis_components">The LogHandler will simply log a
message to a logger when it gets invoked. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>SoapMonitorHandler</b> </a></dt>
<dd><a name="axis_components">Provides the hook into the message
pipeline sending the SOAP request and response messages to the
SoapMonitor utility. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>DebugHandler</b> </a></dt>
<dd><a name="axis_components">Example handler that demonstrates
dynamically setting the debug level based on a the value of a soap
header element. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>ErrorHandler</b> </a></dt>
<dd><a name="axis_components">Example handler that throws an
AxisFault to stop request/response flow processing. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>EchoHandler</b> </a></dt>
<dd><a name="axis_components">The EchoHandler copies the request
message into the response message. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>HTTPAuth</b> </a></dt>
<dd><a name="axis_components">The HTTPAuthHandler takes HTTP-specific
authentication information (right now, just Basic authentication) and
turns it into generic MessageContext properties for username and
password </a></dd>
<dt><a name="axis_components"><b>SimpleAuthenticationHandler</b> </a></dt>
<dd><a name="axis_components">The SimpleAuthentication handler passes
a MessageContext to a SecurityProvider (see org.apache.axis.security)
to authenticate the user using whatever information the
SecurityProvider wants (right now, just the username and password). </a></dd>
<dt><a name="axis_components"><b>SimpleAuthorizationHandler</b> </a></dt>
<dd><a name="axis_components">This handler, typically deployed
alongside the SimpleAuthenticationHandler (a chain called "authChecks"
is predefined for just this combination), checks to make sure that the
currently authenticated user satisfies one of the allowed roles for the
target service. Throws a Fault if access is denied. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>MD5AttachHandler</b> </a></dt>
<dd><a name="axis_components">Undocumented, uncalled, untested
handler that generates an MD5 hash of attachment information and adds
the value as an attribute in the soap body. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>URLMapper</b> </a></dt>
<dd><a name="axis_components">The URLMapper, an HTTP-specific
handler, usually goes on HTTP transport chains (it is deployed by
default). It serves to do service dispatch based on URL - for instance,
this is the Handler which allows URLs like
http://localhost:8080/axis/services/MyService?wsdl to work. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>RPCProvider</b> </a></dt>
<dd><a name="axis_components">The RPCProvider is the pivot point for
all RPC services. It accepts the following options: <br>
<b><i>className</i></b> = the class of the backend object to invoke<br>
<b><i>methodName</i></b> = a space-separated list of methods which
are exported as web services. The special value "*" matches all public
methods in the class. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>MsgProvider</b> </a></dt>
<dd><a name="axis_components">The MsgProvider is the pivot point for
all messaging services. It accepts the following options: <br>
</a></dd>
<dd><a name="axis_components"><b><i>className</i></b> = the class of
the backend object to invoke<br>
<b><i>methodName</i></b> = a space-separated list of methods which
are exported as web services. The special value "*" matches all public
methods in the class. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>JWSHandler</b> </a></dt>
<dd><a name="axis_components">Performs drop-in deployment magic. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>JAXRPCHandler</b> </a></dt>
<dd><a name="axis_components">Wrapper around JAX-RPC compliant
handlers that exposes an Axis handler interface to the engine. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>LocalResponder</b> </a></dt>
<dd><a name="axis_components">The LocalResponder is a Handler whose
job in life is to serialize the response message coming back from a
local invocation into a String. It is by default on the server's local
transport response chain, and it ensures that serializing the message
into String form happens in the context of the server's type mappings.
</a></dd>
</dl>
<h3><a name="axis_components">On the client:</a></h3>
<dl>
<dt><a name="axis_components"><b>SimpleSessionHandler</b> </a></dt>
<dd><a name="axis_components">uses SOAP headers to do simple session
management </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>JAXRPCHandler</b> </a></dt>
<dd><a name="axis_components">Wrapper around JAX-RPC compliant
handlers that exposes an Axis handler interface to the engine. </a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>HTTPSender</b> </a></dt>
<dd><a name="axis_components">A Handler which sends the request
message to a remote server via HTTP, and collects the response message.
</a></dd>
<dt><a name="axis_components"> </a></dt>
<dt><a name="axis_components"><b>LocalSender</b> </a></dt>
<dd><a name="axis_components">A Handler which sends the request
message to a "local" AxisServer, which will process it and return a
response message. This is extremely useful for testing, and is by
default mapped to the "local:" transport. So, for instance, you can
test the AdminClient by doing something like this:<br>
</a>
<pre><a name="axis_components">% java org.apache.axis.client.AdminClient -llocal:// list</a></pre>
<a name="axis_components"> </a></dd>
<dt><br>
</dt>
</dl>
</body>
</html>
