You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by ch...@apache.org on 2006/09/24 12:02:54 UTC
svn commit: r449384 - /webservices/axis2/trunk/java/xdocs/1_1/
Author: chatra
Date: Sun Sep 24 03:02:52 2006
New Revision: 449384
URL: http://svn.apache.org/viewvc?view=rev&rev=449384
Log:
Updated version number and added new docs to index.html
Modified:
webservices/axis2/trunk/java/xdocs/1_1/Axis2-rpc-support.html
webservices/axis2/trunk/java/xdocs/1_1/Axis2ArchitectureGuide.html
webservices/axis2/trunk/java/xdocs/1_1/WS_policy.html
webservices/axis2/trunk/java/xdocs/1_1/index.html
webservices/axis2/trunk/java/xdocs/1_1/installationguide.html
webservices/axis2/trunk/java/xdocs/1_1/rest-ws.html
webservices/axis2/trunk/java/xdocs/1_1/spring.html
webservices/axis2/trunk/java/xdocs/1_1/tcp-transport.html
webservices/axis2/trunk/java/xdocs/1_1/transport_howto.html
webservices/axis2/trunk/java/xdocs/1_1/userguide.html
webservices/axis2/trunk/java/xdocs/1_1/userguide1.html
webservices/axis2/trunk/java/xdocs/1_1/userguide2.html
webservices/axis2/trunk/java/xdocs/1_1/userguide3.html
webservices/axis2/trunk/java/xdocs/1_1/userguide4.html
webservices/axis2/trunk/java/xdocs/1_1/userguide5.html
webservices/axis2/trunk/java/xdocs/1_1/webadminguide.html
Modified: webservices/axis2/trunk/java/xdocs/1_1/Axis2-rpc-support.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/Axis2-rpc-support.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/Axis2-rpc-support.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/Axis2-rpc-support.html Sun Sep 24 03:02:52 2006
@@ -1,261 +1,266 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-<meta name="generator" content=
-"HTML Tidy for Windows (vers 14 February 2006), see www.w3.org" />
-<title>Axis2 RPC Support</title>
-</head>
-<body>
-<h1>Axis2 RPC Support</h1>
-<h2>Introduction</h2>
-<p>Axis2 RPC support may seem somewhat tricky and confusing at the
-first glance. However Axis2 RPC strategy is based on a well defined
-set of rules and once the details are in place, it becomes clear as
-day. This document aims to drill down to the details of this
-strategy and fills up most of the fairly unknown bits and pieces.
-Note that Axis2 currently does not support the rpc/encoded style
-fully. It's main support is for the rpc/lit style.</p>
-<p>We will discuss the Axis2 RPC strategy in steps</p>
-<h2>Step 1 - Converting RPC style WSDL's into Doc/Lit style
-WSDL</h2>
-<p>This is probably the most confusing part of rpc strategy. Since
-the Axis2 code generator is based on pure doc/lit style , the first
-step of the code generation process is to generate a wrapper
-schema. This wrapper generation can be easily explained by using an
-example.</p>
-<p>Take the following piece of WSDL</p>
-<pre>
- .....
- < message name="requestMessage">
- <part name="part1" type="xs:string"/>
- <part name="part2" type="xs:int"/>
- </message>
- <message name="responseMessage">
- <part name="part1" type="xs:string"/>
- </message>
- <portType name="echoPortType">
- <operation name="echo">
- <input message="y:requestMessage"/>
- <output message="y:responseMessage"/>
- </operation>
- </portType>
- <binding name="echoBinding" type="y:echoPortType">
- <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
- <operation name="echo">
- <soap:operation soapAction="echo"/>
- <input>
- <soap:body use="literal"/>
- </input>
- <output>
- <soap:body use="literal"/>
- </output>
- </operation>
- </binding>
-.....
-
-</pre>
-<p>The binding says its got to be rpc/lit and in this case the
-message parts need wrapping in the following order.</p>
-<ol>
-<li>The first element needs to have the operation name as the local
-name and the operation namespace ( which happens to be the
-namespace of the porttype - in this case the targetnamespace of the
-WSDL)</li>
-<li>The children of this element are non namespace qualified
-elements with the part names as local names (refered to as
-<strong>part element</strong>)</li>
-<li>In case the part refers to a standard type like the example
-WSDL, the content of the part element would be of that type. If the
-part refers to a complex type defined in the schema the content of
-the part element becomes of that type. Having an element reference
-in the part when the binding is rpc is invalid.</li>
-</ol>
-<p>For example the input wire message for the echo operation
-mentioned in the above WSDL fragment would look like this</p>
-<pre>
- <op:<strong>echo</strong> xmlns:op="porttype namespace">
- <<strong>part1</strong>>Hello World</part1>
- <<strong>part2</strong>>123</part2>
- </op:echo>
-</pre>
-<p>Note the element names in bold. The first one is the operation
-name, the second and third are part names. It can be seen that it
-is quite possible to generate a schema, representing this structure
-and then treat the whole service as pure doc/lit service. In this
-case following is the piece of schema generated to make this rpc to
-doc conversion. Note that in this case the wire message stays
-unchanged. It is only a different WSDL authoring style</p>
-<pre>
- <xs:element name="echo">
- <xs:complexType>
- <xs:sequence>
- <xs:element name="part1" type="xs:string" />
- <xs:element name="part2" type="xs:int" />
- </xs:sequence>
- </xs:complexType>
- </xs:element>
-</pre>
-<p>What the Axis2 code generator does is exactly this. By looking
-at the binding style, it generates a wrapper schema in places
-required before handing over the Axis* hierarchy to the code
-generator engine.In every case (even when the schema needs to be
-unwrapped) this wrapping part will take place!</p>
-<h2>Step 2 - Unwrapping the Schema</h2>
-<p>If the schema needs to be unwrapped then that brings up a few
-issues mainly because the only thing that the emitters rely on when
-generating code is a mapping table!</p>
-<ol>
-<li>When the schema is unwrapped where would that unwrapping
-information stay ?
-<p>Good question - It needs to be a store that keeps the
-information seperated. Hmm.. What can we use here ? Why, the Axis *
-hierarchy! it has nicely seperated information holders and a
-parameter store that can hold a information bean</p>
-</li>
-<li>How do we maintain uniqueness among message part names ?
-<p>Another Good question - part names are only unique across a
-message and not globally. But due to the fact that we have a global
-mapping table we need a way to differentiate between parts of
-different messages. The technique used here is to generate a QName
-that has the operation name as a namespace and a suffix (like
-_input) appended to the local name</p>
-</li>
-</ol>
-<p>Given these solutions the first step in unwrapping is to walk
-the schema and figure out the unwrappable items. The key player of
-the unwrapping process is the unwrapping extension. What it does is
-to walk a given schema andfigure out the unwrappable parts if there
-are any.</p>
-<p>The current unwrapper looks for the following patterns and fails
-if it is not found!</p>
-<pre>
-< element >
- < complexType >
- < sequence >
- < element />
- < /sequence >
- < /complexType >
- < /element >
-
-</pre>
-<p>Once this pattern is detected the unwrapper details will be
-added to the relevant AxisMessage component</p>
-<h2>Step 3 - Populate type information</h2>
-<p>The next step is to populate the type information for the parts.
-This has to be explicitly done by the data binding extensions and
-currently the ADB and XMLbeans extensions populate the relavant
-AxisMessage by looking up their generated type systems. This type
-information goes into the AxisMessage inside a
-MessagePartInformationHolder instance.</p>
-<p>The following code fragement from the ADB extension shows how
-the AxisMessages get populated with the relevant type information.
-The code is almost the same for the XMLBeans extension.Note the
-items in bold</p>
-<pre>
- if (message.getParameter(Constants.UNWRAPPED_KEY) != null) {
- XmlSchemaType schemaType = message.getSchemaElement().getSchemaType();
- if (schemaType instanceof XmlSchemaComplexType) {
- XmlSchemaComplexType cmplxType = (XmlSchemaComplexType) schemaType;
- XmlSchemaParticle particle = cmplxType.getParticle();
- if (particle instanceof XmlSchemaSequence) {
- XmlSchemaObjectCollection items =
- ((XmlSchemaSequence) particle).getItems();
- for (Iterator i = items.getIterator(); i.hasNext();) {
- Object item = i.next();
- if (item instanceof XmlSchemaElement) {
- XmlSchemaElement xmlSchemaElement = (XmlSchemaElement) item;
- XmlSchemaType eltSchemaType = xmlSchemaElement.getSchemaType();
- if (eltSchemaType != null) {
- <strong>populateClassName(eltSchemaType,mapper,opName,xmlSchemaElement.getName());</strong>
- } else if (xmlSchemaElement.getSchemaTypeName() != null) {
- eltSchemaType = findSchemaType(schemaMap,
- xmlSchemaElement.getSchemaTypeName());
- if (eltSchemaType!=null){
- populateClassName(eltSchemaType,mapper,opName,xmlSchemaElement.getName());
- }
- }
- }
- }
- }
- }
- }
-</pre>
-<p>The populateClassName looks like this</p>
-<pre>
- private static void populateClassName(XmlSchemaType eltSchemaType,
- TypeMapper typeMap,
- String opName,
- String partName) {
- Map metaInfoMap = eltSchemaType.getMetaInfoMap();
- if (metaInfoMap != null) {
- <strong>String className = (String) metaInfoMap.
- get(SchemaConstants.SchemaCompilerInfoHolder.CLASSNAME_KEY);
- QName partQName = WSDLUtil.getPartQName(opName,
- WSDLConstants.INPUT_PART_QNAME_SUFFIX,
- partName);
- typeMap.addTypeMappingName(partQName,className);</strong>
- if (Boolean.TRUE.equals(
- metaInfoMap.get(SchemaConstants.
- SchemaCompilerInfoHolder.CLASSNAME_PRIMITVE_KEY))){
- //this type is primitive - add that to the type mapper status
- //for now lets add a boolean
- typeMap.addTypeMappingStatus(partQName,Boolean.TRUE);
- }
-
- }
- }
-</pre>
-<h2>Step 4 - Generate code with unwrapped parameters</h2>
-<p>The next step is generating the actual code. The
-AxisServiceBasedMultiLanguageEmitter has a method that generates
-the XML model for the input parameters and that method includes the
-relevant part parameters inside the relavant top level input
-parameter element</p>
-<p>The relevant part of the XML model looks like this. Note that
-this intermediate XML model is the one that is parsed against the
-Stylesheets to generate the code</p>
-<pre>
-<input>
- <param name="param4" type="com.example.www.ServiceNameStub.Echo" shorttype="Echo" value="null" location="body" opname="echo">
- <param name="param5" type="java.lang.String" shorttype="String" value="null" location="body" opname="echo" partname="Part1"
- primitive="yes"/>
- <param name="param6" type="int" shorttype="int" value="0" location="body" opname="echo" partname="Part2" primitive="yes"/>
- </param>
-</input>
-</pre>
-<p>The next part is upto the template to handle. Basically the
-template looks after the generation of multiple parameters into the
-method signatures and the then the generating of the relavant
-serialization and deserialization code for the parameters!</p>
-<h2>Bringing the Parameters Together and Exploding Them</h2>
-<p>This is a somewhat contraversial area. The current Axis2 code
-generator does the wapping and unwrapping at the object level and
-not the XML level. In short the exploded parameters are only a
-conveneince and the that explosion does not run down to the XML
-level. The following example of generated source code makes this
-clear</p>
-<pre>
- private org.apache.axiom.soap.SOAPEnvelope toEnvelope(
- org.apache.axiom.soap.SOAPFactory factory, java.lang.String param1,
- int param2, boolean optimizeContent) {
- <strong>com.example.www.ServiceNameStub.Echo wrappedType = new com.example.www.ServiceNameStub.Echo();
- wrappedType.setPart1(param1);
- wrappedType.setPart2(param2);</strong>
- rg.apache.axiom.soap.SOAPEnvelope emptyEnvelope = factory.getDefaultEnvelope();
- emptyEnvelope.getBody().addChild(wrappedType.getOMElement(
- com.example.www.ServiceNameStub.Echo.MY_QNAME, factory));
-
- return emptyEnvelope;
-}
-</pre>
-<p>Note the lines in bold. The wrapped class will anyway be
-instantiated and used at the end but what the user sees is
-different. Exploding the parameters happens in a similar way!</p>
-<h2>Conclusion</h2>
-<p>Axis2 RPC support is a sort of misty area but it is based on a
-well defined set of rules. It is not <em>that</em> misty after
-all</p>
-<hr />
-</body>
-</html>
+<?xml version="1.0" encoding=""?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+ <meta http-equiv="content-type" content="" />
+ <title>Axis2 RPC Support</title>
+</head>
+
+<body>
+<h1>Axis2 RPC Support</h1>
+
+<p>This documents talks about the Axis2's Remote Procedure Calls support in
+easy to understand implementation steps. </p>
+
+<h2>Introduction</h2>
+
+<p>Axis2 Remote Procedure Calls (RPC) support may seem somewhat tricky and
+confusing at the first glance. However Axis2 RPC strategy is based on a well
+defined set of rules and once the details are in place, it becomes clear as
+day. This document aims to drill down to the details of this strategy and
+fills up most of the fairly unknown bits and pieces. Note that Axis2
+currently does not support the rpc/encoded style fully. It's main support is
+for the rpc/lit style.</p>
+
+<p>We will discuss the Axis2 RPC strategy in steps</p>
+
+<h2>Step 1 - Converting RPC style WSDL's into Doc/Lit style WSDL</h2>
+
+<p>This is probably the most confusing part of rpc strategy. Since the Axis2
+code generator is based on pure doc/lit style , the first step of the code
+generation process is to generate a wrapper schema. This wrapper generation
+can be easily explained by using an example.</p>
+
+<p>Take the following piece of WSDL</p>
+<pre> .....
+ < message name="requestMessage">
+ <part name="part1" type="xs:string"/>
+ <part name="part2" type="xs:int"/>
+ </message>
+ <message name="responseMessage">
+ <part name="part1" type="xs:string"/>
+ </message>
+ <portType name="echoPortType">
+ <operation name="echo">
+ <input message="y:requestMessage"/>
+ <output message="y:responseMessage"/>
+ </operation>
+ </portType>
+ <binding name="echoBinding" type="y:echoPortType">
+ <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
+ <operation name="echo">
+ <soap:operation soapAction="echo"/>
+ <input>
+ <soap:body use="literal"/>
+ </input>
+ <output>
+ <soap:body use="literal"/>
+ </output>
+ </operation>
+ </binding>
+.....</pre>
+
+<p>The binding says its got to be rpc/lit and in this case the message parts
+need wrapping in the following order.</p>
+<ol>
+ <li>The first element needs to have the operation name as the local name
+ and the operation namespace ( which happens to be the namespace of the
+ porttype - in this case the targetnamespace of the WSDL)</li>
+ <li>The children of this element are non namespace qualified elements with
+ the part names as local names (refered to as <strong>part
+ element</strong>)</li>
+ <li>In case the part refers to a standard type like the example WSDL, the
+ content of the part element would be of that type. If the part refers to
+ a complex type defined in the schema the content of the part element
+ becomes of that type. Having an element reference in the part when the
+ binding is rpc is invalid.</li>
+</ol>
+
+<p>For example the input wire message for the echo operation mentioned in the
+above WSDL fragment would look like this</p>
+<pre> <op:<strong>echo</strong> xmlns:op="porttype namespace">
+ <<strong>part1</strong>>Hello World</part1>
+ <<strong>part2</strong>>123</part2>
+ </op:echo></pre>
+
+<p>Note the element names in bold. The first one is the operation name, the
+second and third are part names. It can be seen that it is quite possible to
+generate a schema, representing this structure and then treat the whole
+service as pure doc/lit service. In this case following is the piece of
+schema generated to make this rpc to doc conversion. Note that in this case
+the wire message stays unchanged. It is only a different WSDL authoring
+style</p>
+<pre> <xs:element name="echo">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:element name="part1" type="xs:string" />
+ <xs:element name="part2" type="xs:int" />
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element></pre>
+
+<p>What the Axis2 code generator does is exactly this. By looking at the
+binding style, it generates a wrapper schema in places required before
+handing over the Axis* hierarchy to the code generator engine.In every case
+(even when the schema needs to be unwrapped) this wrapping part will take
+place!</p>
+
+<h2>Step 2 - Unwrapping the Schema</h2>
+
+<p>If the schema needs to be unwrapped then that brings up a few issues
+mainly because the only thing that the emitters rely on when generating code
+is a mapping table!</p>
+<ol>
+ <li>When the schema is unwrapped where would that unwrapping information
+ stay ?
+ <p>Good question - It needs to be a store that keeps the information
+ seperated. Hmm.. What can we use here ? Why, the Axis * hierarchy! it has
+ nicely seperated information holders and a parameter store that can hold
+ a information bean</p>
+ </li>
+ <li>How do we maintain uniqueness among message part names ?
+ <p>Another Good question - part names are only unique across a message
+ and not globally. But due to the fact that we have a global mapping table
+ we need a way to differentiate between parts of different messages. The
+ technique used here is to generate a QName that has the operation name as
+ a namespace and a suffix (like _input) appended to the local name</p>
+ </li>
+</ol>
+
+<p>Given these solutions the first step in unwrapping is to walk the schema
+and figure out the unwrappable items. The key player of the unwrapping
+process is the unwrapping extension. What it does is to walk a given schema
+andfigure out the unwrappable parts if there are any.</p>
+
+<p>The current unwrapper looks for the following patterns and fails if it is
+not found!</p>
+<pre>< element >
+ < complexType >
+ < sequence >
+ < element />
+ < /sequence >
+ < /complexType >
+ < /element >
+ </pre>
+
+<p>Once this pattern is detected the unwrapper details will be added to the
+relevant AxisMessage component</p>
+
+<h2>Step 3 - Populate type information</h2>
+
+<p>The next step is to populate the type information for the parts. This has
+to be explicitly done by the data binding extensions and currently the ADB
+and XMLbeans extensions populate the relavant AxisMessage by looking up their
+generated type systems. This type information goes into the AxisMessage
+inside a MessagePartInformationHolder instance.</p>
+
+<p>The following code fragement from the ADB extension shows how the
+AxisMessages get populated with the relevant type information. The code is
+almost the same for the XMLBeans extension.Note the items in bold</p>
+<pre> if (message.getParameter(Constants.UNWRAPPED_KEY) != null) {
+ XmlSchemaType schemaType = message.getSchemaElement().getSchemaType();
+ if (schemaType instanceof XmlSchemaComplexType) {
+ XmlSchemaComplexType cmplxType = (XmlSchemaComplexType) schemaType;
+ XmlSchemaParticle particle = cmplxType.getParticle();
+ if (particle instanceof XmlSchemaSequence) {
+ XmlSchemaObjectCollection items =
+ ((XmlSchemaSequence) particle).getItems();
+ for (Iterator i = items.getIterator(); i.hasNext();) {
+ Object item = i.next();
+ if (item instanceof XmlSchemaElement) {
+ XmlSchemaElement xmlSchemaElement = (XmlSchemaElement) item;
+ XmlSchemaType eltSchemaType = xmlSchemaElement.getSchemaType();
+ if (eltSchemaType != null) {
+ <strong>populateClassName(eltSchemaType,mapper,opName,xmlSchemaElement.getName());</strong>
+ } else if (xmlSchemaElement.getSchemaTypeName() != null) {
+ eltSchemaType = findSchemaType(schemaMap,
+ xmlSchemaElement.getSchemaTypeName());
+ if (eltSchemaType!=null){
+ populateClassName(eltSchemaType,mapper,opName,xmlSchemaElement.getName());
+ }
+ }
+ }
+ }
+ }
+ }
+ }</pre>
+
+<p>The populateClassName looks like this</p>
+<pre> private static void populateClassName(XmlSchemaType eltSchemaType,
+ TypeMapper typeMap,
+ String opName,
+ String partName) {
+ Map metaInfoMap = eltSchemaType.getMetaInfoMap();
+ if (metaInfoMap != null) {
+ <strong>String className = (String) metaInfoMap.
+ get(SchemaConstants.SchemaCompilerInfoHolder.CLASSNAME_KEY);
+ QName partQName = WSDLUtil.getPartQName(opName,
+ WSDLConstants.INPUT_PART_QNAME_SUFFIX,
+ partName);
+ typeMap.addTypeMappingName(partQName,className);</strong>
+ if (Boolean.TRUE.equals(
+ metaInfoMap.get(SchemaConstants.
+ SchemaCompilerInfoHolder.CLASSNAME_PRIMITVE_KEY))){
+ //this type is primitive - add that to the type mapper status
+ //for now lets add a boolean
+ typeMap.addTypeMappingStatus(partQName,Boolean.TRUE);
+ }
+
+ }
+ }</pre>
+
+<h2>Step 4 - Generate code with unwrapped parameters</h2>
+
+<p>The next step is generating the actual code. The
+AxisServiceBasedMultiLanguageEmitter has a method that generates the XML
+model for the input parameters and that method includes the relevant part
+parameters inside the relavant top level input parameter element</p>
+
+<p>The relevant part of the XML model looks like this. Note that this
+intermediate XML model is the one that is parsed against the Stylesheets to
+generate the code</p>
+<pre><input>
+ <param name="param4" type="com.example.www.ServiceNameStub.Echo" shorttype="Echo" value="null" location="body" opname="echo">
+ <param name="param5" type="java.lang.String" shorttype="String" value="null" location="body" opname="echo" partname="Part1"
+ primitive="yes"/>
+ <param name="param6" type="int" shorttype="int" value="0" location="body" opname="echo" partname="Part2" primitive="yes"/>
+ </param>
+</input></pre>
+
+<p>The next part is upto the template to handle. Basically the template looks
+after the generation of multiple parameters into the method signatures and
+the then the generating of the relavant serialization and deserialization
+code for the parameters!</p>
+
+<h2>Bringing the Parameters Together and Exploding Them</h2>
+
+<p>This is a somewhat contraversial area. The current Axis2 code generator
+does the wapping and unwrapping at the object level and not the XML level. In
+short the exploded parameters are only a conveneince and the that explosion
+does not run down to the XML level. The following example of generated source
+code makes this clear</p>
+<pre> private org.apache.axiom.soap.SOAPEnvelope toEnvelope(
+ org.apache.axiom.soap.SOAPFactory factory, java.lang.String param1,
+ int param2, boolean optimizeContent) {
+ <strong>com.example.www.ServiceNameStub.Echo wrappedType = new com.example.www.ServiceNameStub.Echo();
+ wrappedType.setPart1(param1);
+ wrappedType.setPart2(param2);</strong>
+ rg.apache.axiom.soap.SOAPEnvelope emptyEnvelope = factory.getDefaultEnvelope();
+ emptyEnvelope.getBody().addChild(wrappedType.getOMElement(
+ com.example.www.ServiceNameStub.Echo.MY_QNAME, factory));
+
+ return emptyEnvelope;
+}</pre>
+
+<p>Note the lines in bold. The wrapped class will anyway be instantiated and
+used at the end but what the user sees is different. Exploding the parameters
+happens in a similar way!</p>
+
+<h2>Conclusion</h2>
+
+<p>Axis2 RPC support is a sort of misty area but it is based on a well
+defined set of rules. It is not <em>that</em> misty after all</p>
+<hr />
+</body>
+</html>
Modified: webservices/axis2/trunk/java/xdocs/1_1/Axis2ArchitectureGuide.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/Axis2ArchitectureGuide.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/Axis2ArchitectureGuide.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/Axis2ArchitectureGuide.html Sun Sep 24 03:02:52 2006
@@ -9,8 +9,6 @@
<body lang="en-US" dir="ltr">
<h1 align="center">Apache Axis2 Architecture Guide</h1>
-<p><i>-Axis2 Version 1.0</i></p>
-
<p>This document will give an introduction to Axis2's modular architecture
with explanations on every module.</p>
@@ -409,10 +407,10 @@
message by looking at various transport headers, add data into message
context etc.</li>
<li><strong>Pre-Dispatch Phase</strong>- The main functionality of the
- handlers in this phase is to populate message context in order to do
- the dispatching. As an example, processing of addressing headers of the
- SOAP message happen in this phase.Addressing handlers extract information
- and put them in to the message context.</li>
+ handlers in this phase is to populate message context in order to do the
+ dispatching. As an example, processing of addressing headers of the SOAP
+ message happen in this phase.Addressing handlers extract information and
+ put them in to the message context.</li>
<li><strong>Dispatch Phase</strong> - The Dispatchers run in this phase and
tries to find the correct service and operation this particular message
is destined to.<br>
@@ -719,7 +717,6 @@
data bound object and serialize from data bound object to AXIOM. For example,
if the WSDL has an operation called "echoString", once the code is generated
the following methods will be generated inside the relevant classes.</p>
-
<pre>public static
org.apache.axiom.om.OMElementtoOM(org.soapinterop.xsd.EchoStringParamDocument
param)// This method will handle the serialization.
@@ -727,6 +724,5 @@
public static org.apache.xmlbeans.XmlObject
fromOM(org.apache.axis2.om.OMElement param, java.lang.Class type) //This
method will handle the de-serialization.</pre>
-
</body>
</html>
Modified: webservices/axis2/trunk/java/xdocs/1_1/WS_policy.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/WS_policy.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/WS_policy.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/WS_policy.html Sun Sep 24 03:02:52 2006
@@ -10,8 +10,6 @@
<body lang="en">
<h1 align="center">Web Services Policy Support In Axis2</h1>
-<p><em>-Axis2 version 1.0</em></p>
-
<p>This document will give you an introduction to the role of Web services
policy in Axis2.</p>
Modified: webservices/axis2/trunk/java/xdocs/1_1/index.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/index.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/index.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/index.html Sun Sep 24 03:02:52 2006
@@ -90,8 +90,9 @@
Wiki</a></td>
<td></td>
</tr>
- <tr>
- <td><a href="Axis2ArchitectureGuide.html">Axis2 Architecture Guide</a></td>
+ <tr>
+ <td><a href="Axis2ArchitectureGuide.html">Axis2 Architecture
+ Guide</a></td>
<td>Introduction to Axis2's modular architecture</td>
</tr>
<tr>
@@ -107,6 +108,11 @@
<td>Introduction on Representational State Transfer</td>
</tr>
<tr>
+ <td><a href="Axis2-rpc-support.html">Axis2 RPC Support</a></td>
+ <td>This documents talks about the Axis2's Remote Procedure Calls
+ support in easy to understand implementation steps</td>
+ </tr>
+ <tr>
<td><a href="mtom-guide.html">MTOM Guide -Sending Binary Data with
SOAP</a></td>
<td>Describes sending binary data using SOAP Message Transmission
@@ -252,9 +258,8 @@
<td>Deepal Jayasinghe</td>
</tr>
<tr>
- <td><a
- href="http://www.wso2.net/kb/67">Setting
- up Apache Axis2 in eclipse IDE</a></td>
+ <td><a href="http://www.wso2.net/kb/67">Setting up Apache Axis2 in
+ eclipse IDE</a></td>
<td>Ruchith Fernando</td>
</tr>
<tr>
@@ -276,8 +281,9 @@
<td>Tyler Anderson</td>
</tr>
<tr>
- <td><a href="http://www.developer.com/java/ent/article.php/3606466">The Axis2 Transport Framework</a></td>
- <td>Deepal Jayasinghe</td>
+ <td><a href="http://www.developer.com/java/ent/article.php/3606466">The
+ Axis2 Transport Framework</a></td>
+ <td>Deepal Jayasinghe</td>
</tr>
</tbody>
</table>
Modified: webservices/axis2/trunk/java/xdocs/1_1/installationguide.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/installationguide.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/installationguide.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/installationguide.html Sun Sep 24 03:02:52 2006
@@ -9,8 +9,6 @@
<body lang="en">
<h1 align="center">Apache Axis2 Installation Guide</h1>
-<p><i>-Axis2 Version 1.0</i></p>
-
<p>This document will give you information on Axis2 distribution packages,
system prerequisites & setting up environment variables and tools
followed by detailed instructions on installation methods.</p>
@@ -53,7 +51,7 @@
servlet container. Axis2 is distributed under the Apache License, version
2.0. You can download Axis2 <a
href="http://ws.apache.org/axis2/download.cgi">here</a>. Latest release of
-Axis2 is version 1.0.</p>
+Axis2 is version 1.1.</p>
<table width="940" border="1" cellpadding="1">
<tbody>
@@ -66,10 +64,10 @@
<td>Minimal Distribution - Binary</td>
<td>This distribution is aimed at advanced users who will be embedding
Axis2. It will contain the minimal runtime required to act as a Web
- service client and/or a server (axis2-kernel-1.0.jar will contain
+ service client and/or a server (axis2-kernel-1.1.jar will contain
compiled versions of common and core modules.)</td>
<td><ul>
- <li>axis2-kernel-1.0.jar, axis2-adb-1.0.jar</li>
+ <li>axis2-kernel-1.1.jar, axis2-adb-1.1.jar</li>
<li>third party distributable libraries</li>
<li>README.TXT and release-notes.html</li>
</ul>
@@ -102,7 +100,7 @@
<li>all the content of minimal-binary distribution</li>
<li>Contents of codegen and doom modules</li>
<li>Samples</li>
- <li>addressing-1.0.mar</li>
+ <li>addressing-1.1.mar</li>
</ul>
</td>
</tr>
@@ -321,6 +319,7 @@
For Axis2 this will be the <webapps>/axis2/WEB-INF/services
directory. Once a service is uploaded it will be installed instantly.</p>
<a name="hot_deployment"></a>
+
<p>Since Axis2 supports <strong>hot deployment</strong> one can drop the
service jar directly through the file system to the above mentioned
services directory.It will also cause the service to be automatically
Modified: webservices/axis2/trunk/java/xdocs/1_1/rest-ws.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/rest-ws.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/rest-ws.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/rest-ws.html Sun Sep 24 03:02:52 2006
@@ -5,10 +5,10 @@
</head>
<body lang="en">
-<h1>RESTful Web services Support</h1>
+<h1>RESTful Web Services Support</h1>
<p>This document presents introduction on REST and REST with HTTP POST &
-GET. </p>
+GET.</p>
<h2>Content</h2>
<ul>
@@ -54,16 +54,13 @@
<p>On sending a message out, the fact that the message is RESTful or not, can
be decided from the client API.<br>
- Set a property in the client api.<br>
- <source>
- <pre>...
+Set a property in the client api.<br>
+<source></p>
+<pre>...
Options options = new Options();
options.setProperty(Constants.Configuration.ENABLE_REST, Constants.VALUE_TRUE);
...</pre>
- </source>
-</p>
-
-<a name="sample"></a>
+</source><a name="sample"></a>
<h3>Sample REST - HTTP POST Client</h3>
Modified: webservices/axis2/trunk/java/xdocs/1_1/spring.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/spring.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/spring.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/spring.html Sun Sep 24 03:02:52 2006
@@ -6,10 +6,13 @@
</head>
<body>
+<h1>Axis2 Intergration With The Spring Framework</h1>
+
+<p>This document is a guide on how to use Axis2 with the Spring Framework</p>
+
<h2>Content</h2>
<ul>
- <li><a href="#1">Introduction</a>
- </li>
+ <li><a href="#1">Introduction</a></li>
<li><a href="#2">Configuring Axis2 to be Spring aware</a>
<ul>
<li><a href="#21">Programming Model</a></li>
@@ -22,27 +25,30 @@
<li><a href="#261">The Spring inside an AAR layout</a></li>
<li><a href="#262">The Spring inside an AAR init class</a></li>
</ul>
+ </li>
</ul>
</li>
+</ul>
<a name="1"></a>
<h2>Introduction</h2>
-<p>The idea behind Axis2 and Spring integration is that Axis2 simply needs to
-have Spring supply one of its pre-loaded beans to the Axis2 Message Receiver
-defined in the AAR services.xml . While Axis2 typically uses reflection to instantiate
-the ServiceClass defined in the services.xml that the Message Receiver will use,
-alternatively one can define a ServiceObjectSupplier that will have supply the Object.
-This guide will show how to use two seperate ServiceObjectSupplier classes that are
-part of the Axis2 standard distribution: One for use with a servlet container, and one
-without. Once configured, the web service itself acts like any other Spring wired bean.
-No further spring configuration is necessary. These Spring beans can be loaded any way
-desired, as Axis2 has no configuration file dependencies from Spring. Spring versions
-1.2.6 and 1.2.8 have been tested, but probably any version would work as only core
-functionality is required.</p>
-
-<p>This guide assumes some basic knowledge of Axis2. See the userguide for more info.</p>
+<p>The idea behind Axis2 and Spring integration is that Axis2 simply needs to
+have Spring supply one of its pre-loaded beans to the Axis2 Message Receiver
+defined in the AAR services.xml . While Axis2 typically uses reflection to
+instantiate the ServiceClass defined in the services.xml that the Message
+Receiver will use, alternatively one can define a ServiceObjectSupplier that
+will have supply the Object. This guide will show how to use two seperate
+ServiceObjectSupplier classes that are part of the Axis2 standard
+distribution: One for use with a servlet container, and one without. Once
+configured, the web service itself acts like any other Spring wired bean. No
+further spring configuration is necessary. These Spring beans can be loaded
+any way desired, as Axis2 has no configuration file dependencies from Spring.
+Spring versions 1.2.6 and 1.2.8 have been tested, but probably any version
+would work as only core functionality is required.</p>
+<p>This guide assumes some basic knowledge of Axis2. See the userguide for
+more info.</p>
<a name="2"></a>
<h2>Configuring Axis2 to be Spring aware</h2>
@@ -50,17 +56,18 @@
<h3>Programming Model</h3>
-<p>From an Axis2 standpoint, two needed hooks are to be placed into the AAR services.xml:
-The ServiceObjectSupplier that hooks Axis2 and Spring together, and the name of Spring bean
-that Axis2 will use as the service. All Message Receivers are currently supported, as would be
-any Message Receiver that extends org.apache.axis2.receivers.AbstractMessageReceiver . </p>
-
+<p>From an Axis2 standpoint, two needed hooks are to be placed into the AAR
+services.xml: The ServiceObjectSupplier that hooks Axis2 and Spring together,
+and the name of Spring bean that Axis2 will use as the service. All Message
+Receivers are currently supported, as would be any Message Receiver that
+extends org.apache.axis2.receivers.AbstractMessageReceiver .</p>
<a name="22"></a>
<h3>Simple Spring config example</h3>
-<p>For the purpose of this example, and for no other reason besides simplicity, we'll
-configure Spring via a WAR file's web.xml. Lets add a context-param and a listener:</p>
+<p>For the purpose of this example, and for no other reason besides
+simplicity, we'll configure Spring via a WAR file's web.xml. Lets add a
+context-param and a listener:</p>
<pre><listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
@@ -69,14 +76,15 @@
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param></pre>
-<p>Next we will show two examples of Spring's /WEB-INF/applicationContext.xml referenced in the web.xml listener - one with a servlet container, and one without. </p>
-
+<p>Next we will show two examples of Spring's /WEB-INF/applicationContext.xml
+referenced in the web.xml listener - one with a servlet container, and one
+without.</p>
<a name="23"></a>
<h3>Inside a Servlet Container</h3>
-<p>This 'inside a servlet container' example applicationContext.xml should be familair to any Spring user: </p>
-
+<p>This 'inside a servlet container' example applicationContext.xml should be
+familair to any Spring user:</p>
<pre> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
@@ -91,12 +99,11 @@
<bean id="myBean" class="spring.MyBeanImpl">
<property name="val" value="Spring, emerge thyself" />
</bean>
-</beans>
-</pre>
-
-<p>If the service is running in a Servlet Container, ie, Axis2 will be able to get a hold of
-ServletContext, the services.xml for the example would be using SpringServletContextObjectSupplier such as: </p>
+</beans></pre>
+<p>If the service is running in a Servlet Container, ie, Axis2 will be able
+to get a hold of ServletContext, the services.xml for the example would be
+using SpringServletContextObjectSupplier such as:</p>
<pre> <service name="SpringAwareService">
<description>
simple spring example
@@ -108,18 +115,18 @@
</operation>
</service> </pre>
-<p>While the above example uses RawXMLINOutMessageReceiver as its messageReceiver class,
-all Message Receivers are currently supported, as would be
-any Message Receiver that extends org.apache.axis2.receivers.AbstractMessageReceiver . </p>
-
+<p>While the above example uses RawXMLINOutMessageReceiver as its
+messageReceiver class, all Message Receivers are currently supported, as
+would be any Message Receiver that extends
+org.apache.axis2.receivers.AbstractMessageReceiver .</p>
<a name="24"></a>
<h3>Outside a Servlet Container</h3>
-<p> In the case Axis2 can't get a ServletContext, you have the option of defining a bean that takes
-advantage of Spring's internal abilities (ApplicationContextAware interface, specifically) to
-provide an Application Context to Axis2, with a bean ref 'applicationContext' :
-
+<p>In the case Axis2 can't get a ServletContext, you have the option of
+defining a bean that takes advantage of Spring's internal abilities
+(ApplicationContextAware interface, specifically) to provide an Application
+Context to Axis2, with a bean ref 'applicationContext' :</p>
<pre><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
@@ -142,9 +149,9 @@
</bean>
</beans></pre>
-<p>If the service is _NOT_ running in a Servlet Container, ie, Axis2 will _NOT_ be able to get a hold of
-ServletContext, the services.xml for the example would be using SpringAppContextAwareObjectSupplier such as: </p>
-
+<p>If the service is _NOT_ running in a Servlet Container, ie, Axis2 will
+_NOT_ be able to get a hold of ServletContext, the services.xml for the
+example would be using SpringAppContextAwareObjectSupplier such as:</p>
<pre> <service name="SpringAwareService">
<description>
simple spring example
@@ -156,13 +163,14 @@
</operation>
</service> </pre>
-<p>While the above example uses RawXMLINOutMessageReceiver as its messageReceiver class,
-all Message Receivers are currently supported, as would be
-any Message Receiver that extends org.apache.axis2.receivers.AbstractMessageReceiver . </p>
-
-<p>In a non-servlet container environment, one way you could load the applicationContext.xml file
-is in a place that will be run once, upon start-up, execute: </p>
-
+<p>While the above example uses RawXMLINOutMessageReceiver as its
+messageReceiver class, all Message Receivers are currently supported, as
+would be any Message Receiver that extends
+org.apache.axis2.receivers.AbstractMessageReceiver .</p>
+
+<p>In a non-servlet container environment, one way you could load the
+applicationContext.xml file is in a place that will be run once, upon
+start-up, execute:</p>
<pre>import org.springframework.context.support.ClassPathXmlApplicationContext;
public void createSpringAppCtx(ClassLoader cl)
@@ -173,15 +181,14 @@
"spring/applicationContext.xml"}, false);
ctx.setClassLoader(cl);
ctx.refresh();</pre>
- }
-
-<a name="25"></a>
+} <a name="25"></a>
<h3>Putting it all together</h3>
-<p>From here, its just standard Axis2 coding, only now the service has Spring wiring
-capabilities. The implementation is the same whether using either SpringServletContextObjectSupplier or
-SpringAppContextAwareObjectSupplier. The service is below: </p>
+<p>From here, its just standard Axis2 coding, only now the service has Spring
+wiring capabilities. The implementation is the same whether using either
+SpringServletContextObjectSupplier or SpringAppContextAwareObjectSupplier.
+The service is below:</p>
<pre>package spring;
import org.apache.axiom.om.OMAbstractFactory;
@@ -213,9 +220,9 @@
}
} </pre>
-<p>For those new to Spring, one of the ideas is that you program to an Interface, and the
-implementation is pluggable. This idea is referenced in the Spring config file above. Below is
-the interface: </p>
+<p>For those new to Spring, one of the ideas is that you program to an
+Interface, and the implementation is pluggable. This idea is referenced in
+the Spring config file above. Below is the interface:</p>
<pre>package spring;
/** Interface for Spring aware Bean */
@@ -223,7 +230,7 @@
String emerge();
}</pre>
-<p>Here's the implementation: </p>
+<p>Here's the implementation:</p>
<pre>/** Spring wired implementation */
public class MyBeanImpl implements MyBean {
@@ -238,7 +245,8 @@
}
}</pre>
-<p>Lastly here's the client - not really necessary for the example, other than for completeness:</p>
+<p>Lastly here's the client - not really necessary for the example, other
+than for completeness:</p>
<pre>package client;
import java.io.StringWriter;
@@ -295,30 +303,29 @@
}
}
} </pre>
-<p>To run this example, make sure you have the axis2-spring*.jar that comes from the axis2-std-*-bin distro
-in the server side WEB-INF/lib, as well as the appropriate Spring jar - most will use the full spring.jar,
-but the minimun requirements are spring-core, spring-beans, spring-context and spring-web. Running the
-client, you should see this output:</p>
-<pre>
-Response: <example1:string xmlns:example1="http://springExample.org/example1"
- xmlns:tns="http://ws.apache.org/axis2">Spring, emerge thyself</example1:string>
-</pre>
+<p>To run this example, make sure you have the axis2-spring*.jar that comes
+from the axis2-std-*-bin distro in the server side WEB-INF/lib, as well as
+the appropriate Spring jar - most will use the full spring.jar, but the
+minimun requirements are spring-core, spring-beans, spring-context and
+spring-web. Running the client, you should see this output:</p>
+<pre>Response: <example1:string xmlns:example1="http://springExample.org/example1"
+ xmlns:tns="http://ws.apache.org/axis2">Spring, emerge thyself</example1:string></pre>
<a name="26"></a>
<h3>Spring inside an AAR</h3>
-<p>Frequently Axis2 users wish to run Spring inside the AAR. Here we show you how. There are four things
-to be aware of here: (A) You need to configure Spring to use the Axis2 Service Classloader. (B) Its up to you
-to load Spring, though we give an example below. (C) For reasons such as classloader isolation the
-SpringAppContextAwareObjectSupplier is the best choice. (D) The springframework jar and axis2-spring-*.jar will
-be placed inside the AAR under the lib directory.</p>
-
+<p>Frequently Axis2 users wish to run Spring inside the AAR. Here we show you
+how. There are four things to be aware of here: (A) You need to configure
+Spring to use the Axis2 Service Classloader. (B) Its up to you to load
+Spring, though we give an example below. (C) For reasons such as classloader
+isolation the SpringAppContextAwareObjectSupplier is the best choice. (D) The
+springframework jar and axis2-spring-*.jar will be placed inside the AAR
+under the lib directory.</p>
<ul>
<li><strong><a name="261"></a>The Spring inside an AAR layout</strong></li>
</ul>
-<source><pre>
-./springExample.aar
+<source><pre>./springExample.aar
./META-INF
./META-INF/MANIFEST.MF
./META-INF/services.xml
@@ -330,18 +337,19 @@
./spring/MyBean.class
./spring/MyBeanImpl.class
./spring/SpringAwareService.class
-./spring/SpringInit.class
-</pre>
-</source>
-
-<ul>
- <li><strong><a name="262"></a>The Spring inside an AAR init class</strong></li>
+./spring/SpringInit.class</pre>
+</source><ul>
+ <li><strong><a name="262"></a>The Spring inside an AAR init
+ class</strong></li>
</ul>
-<p>One way to initialize Spring is to use the org.apache.axis2.engine.Service. IMPORTANT: this interface at the
-time of this writing is being discussed for refactoring. We'll update the Spring docs ASAP, just be aware that
-this interface name perhaps will change, though the functionality will be probably be in place somewhere. The
-important part for us is the startUp() method and setting Spring to use the Service classloader: </p>
+<p>One way to initialize Spring is to use the
+org.apache.axis2.engine.Service. IMPORTANT: this interface at the time of
+this writing is being discussed for refactoring. We'll update the Spring docs
+ASAP, just be aware that this interface name perhaps will change, though the
+functionality will be probably be in place somewhere. The important part for
+us is the startUp() method and setting Spring to use the Service
+classloader:</p>
<source><pre>package spring;
import org.apache.axiom.om.OMElement;
@@ -356,9 +364,9 @@
import org.apache.commons.logging.LogFactory;
public class SpringInit implements Service {
-
+
private static Log logger = LogFactory
- .getLog(SpringInit .class);
+ .getLog(SpringInit .class);
// The web service
public OMElement springInit(OMElement ignore) {
@@ -395,10 +403,9 @@
}
}</pre>
</source>
-
-<p>Here's the services.xml that now includes SpringInit and the needed load-on-startup parameter. </p>
-<source><pre>
-<serviceGroup>
+<p>Here's the services.xml that now includes SpringInit and the needed
+load-on-startup parameter.</p>
+<source><pre><serviceGroup>
<service name="SpringInit">
<description>
This is a spring sample Web Service with two operations.
@@ -419,8 +426,6 @@
<messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</operation>
</service>
-</serviceGroup>
-</pre>
-</source>
-</body>
+</serviceGroup></pre>
+</source></body>
</html>
Modified: webservices/axis2/trunk/java/xdocs/1_1/tcp-transport.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/tcp-transport.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/tcp-transport.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/tcp-transport.html Sun Sep 24 03:02:52 2006
@@ -40,7 +40,7 @@
<ol>
<li>Use the name space URI of the first child element of SOAPBody.
(SOAPMessageBodyBasedDispatcher)</li>
- <li>Enable the WS-Addressing. In the case of 1.0 release addressing is
+ <li>Enable the WS-Addressing. In the case of 1.1 release addressing is
default (SOAPActionBasedDispatcher)</li>
</ol>
Modified: webservices/axis2/trunk/java/xdocs/1_1/transport_howto.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/transport_howto.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/transport_howto.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/transport_howto.html Sun Sep 24 03:02:52 2006
@@ -1,218 +1,218 @@
-<html>
-<head>
- <meta http-equiv="content-type" content="">
- <title></title>
-</head>
-
-<body>
-<h1>How to write your own Axis2 transport</h1>
-
-<h2>Prologue</h2>
-
-<p>To stop you from reinventing the wheel I will quickly list the transports
-that are already supported in Axis2 with a small description before we get
-started.</p>
-
-<p></p>
-<ul>
- <li><b>HTTP</b> - In the HTTP transport, the transport Listener is a
- Servlet or a Simple HTTP server provided by Axis2. The transport Sender
- uses sockets to connect and send the SOAP Message. Currently we have the
- commons-httpclient based HTTP Transport sender as the default
- transport.</li>
- <li><b>TCP</b> This is the most simple transport, but needs addressing
- support to be functional.</li>
- <li><b>SMTP</b> This can work off a single email account or a mailserver.
- The Mail Transport Receiver is a tread that checks for emails in fixed
- time intervals.</li>
-</ul>
-
-<p>To understand the rest of this document you will need some understanding
-of the Architecture of Axis2. Therefor if you are not familiar with the
-Architecture of Axis2 you will have to first read the <a
-href="Axis2ArchitectureGuide.html">Axis2 Architecture Guide</a> before you
-read any further.</p>
-
-<h2>Introduction</h2>
-
-<p>Broadly speaking a transport inside Axis2 can be classified as a way of
-getting a messages that arrive though some channel into the Axis2 engine. The
-core of Axis2 is transport independent. All data that is transport specific
-is striped out of the incoming message and inserted into the MessageContext
-and on the outgoing message all transport specific information like headers
-are added and sent.</p>
-
-<p>To write your own transport you will need to primarily write two classes,
-one is the TransportSender and the other is the TransportReceiver. To
-register a transport with Axis2 you will need to put two entries in the
-axis2.xml file. One for the transport receiver and the other for the
-transport sender. We will walk though the process of adding the entries in
-the relevent sections.</p>
-
-<h2>Transport Receiver</h2>
-
-<p>Any message that is comming into Axis2 needs to go though a transport
-receiver. All information about how the message is received at the Axis2
-server from the wire [or by snail mail for that matter:)] is isolated inside
-the transport receiver. It extracts the data that is coming on the wire and
-transforms it into a state that the Axis2 server understands.</p>
-
-<p>So now that we have some background information about how transports work
-inside Axis2 with out further delay why don't we dive into some coding and
-start building out own transport.</p>
-
-<p></p>
-
-<p>To get things stared you will first need to extend from the
-org.apache.Axis2.transport.TransportListener class and write you own
-transport listener. To create an engine to process the MessageContext we need
-a configuration context. The following code fragment will do this. This
-should ideally be only done once for the lifetime of the Transport
-receiver.</p>
-
-<p><source></p>
-<pre>try {
- //Create a factory
- ConfigurationContextFactory factory = new ConfigurationContextFactory();
- //Use the factory and an Axis2 repository to create a new Configuration Context
- configurationContext = ConfigurationContextFactory.createConfigurationContextFromFileSystem(repository_directory,
-axis2xmllocation);
-} catch (Exception e) {
- log.info(e.getMessage());
-}</pre>
-</source>
-<p>Now we need some kind of a listener to listen to the requests that come
-in. This you will need to implement according to the transport that you are
-trying to build. After a message is received at the receiver you can use the
-following code to process the request and then forward the message context to
-the engine using thing the engine.receive(msgContext) method.{Following code
-snippet extracted from MailListener as an example}</p>
-<source><pre>AxisEngine engine = new AxisEngine(configurationContext);
-MessageContext msgContext = null;
-// create and initialize a message context
-try {
- TransportInDescription transportIn =
- reg.getAxisConfiguration().getTransportIn(new QName(Constants.TRANSPORT_NAME));
- TransportOutDescription transportOut =
- reg.getAxisConfiguration().getTransportOut(new QName(Constants.TRANSPORT_NAME));
- if (transportIn != null && transportOut != null) {
- //create Message Context
- msgContext = new MessageContext(configurationContext, transportIn, transportOut);
- msgContext.setServerSide(true);
- msgContext.setProperty(MailSrvConstants.CONTENT_TYPE, message.getContentType());
- msgContext.setProperty(MessageContext.CHARACTER_SET_ENCODING, message.getEncoding());
-
- String soapAction = message.getSOAPActionHeader();
- msgContext.setWSAAction(soapAction);
- msgContext.setSoapAction(soapAction);
-
- // Here we are trying to set the reply to if it is present in the transport information.
- msgContext.setReplyTo(new EndpointReference(message.getReplyTo());
-
- //Create the SOAP Message -- This code in from the mail transport and will change depending
- //on how the data is handled in each transport.
- ByteArrayInputStream bais = new ByteArrayInputStream(message.getContent().toString().getBytes());
- XMLStreamReader reader = XMLInputFactory.newInstance().createXMLStreamReader(bais);
-
- String soapNamespaceURI = "";
- if(message.getContentType().indexOf(SOAP12Constants.SOAP_12_CONTENT_TYPE) > -1){
- soapNamespaceURI = SOAP12Constants.SOAP_ENVELOPE_NAMESPACE_URI;
- }else if(message.getContentType().indexOf(SOAP11Constants.SOAP_11_CONTENT_TYPE) > -1){
- soapNamespaceURI = SOAP11Constants.SOAP_ENVELOPE_NAMESPACE_URI;
- }
-
- StAXBuilder builder = new StAXSOAPModelBuilder(reader, soapNamespaceURI);
-
- SOAPEnvelope envelope = (SOAPEnvelope) builder.getDocumentElement();
- msgContext.setEnvelope(envelope);
- if (envelope.getBody().hasFault()) {
- engine.receiveFault(msgContext);
- } else {
- engine.receive(msgContext);
- }
- } else {
- throw new AxisFault(Messages.getMessage("unknownTransport",Constants.TRANSPORT_NAME));
- }
-
-} catch (Exception e) {
- try {
- if (msgContext != null) {
- MessageContext faultContext = engine.createFaultMessageContext(msgContext, e);
- engine.sendFault(faultContext);
- } else {
- log.error(e);
- }
- } catch (AxisFault e1) {
- log.error(e);
- }
-}</pre>
-</source>
-<p>Now we have the coding in place and we need to let Axis2 know about our
-new transport receiver. How we do this is by addind an entry into the
-axis2.xml file. If you need to pass any properties for the transport to
-operate it can also be done through the axis2.xml file.</p>
-<source><pre> <transportReceiver name="TRANSPORT_NAME" class="org.apache.Axis2.transport.TRANSPORT_NAME.TRANSPORT_LISTNER_CLASS">
- <parameter name="PROPERTY_NAME" locked="false">PROPERTY_VALUE</parameter>
- <parameter name="PROPERTY_NAME_2" locked="false">PROPERTY_VALUE_2</parameter>
- </transportReceiver>
- </pre>
-</source>
-<p>Using a code fragment like
-Utils.getParameterValue(transportOut.getParameter(MailSrvConstants.SMTP_USER))
-we can extract the parameters that we insert into the axis2.xml file.</p>
-
-<p>So as you can see getting a new transport receiver up and running is a
-task that requires very little effort.</p>
-
-<h2>Transport Sender</h2>
-
-<p>Any message that is to be sent out from Axis2 is sent through the
-Transport Sender. The Transport Sender needs to be extended from the
-org.apache.Axis2.transport.AbstractTransportSender class.</p>
-
-<p>The following bit of code from the abstract transport sender will call the
-Transport Sender that you wrote.</p>
-<source><pre>// If an EPR is present then the message is going on a diffrent channel.
-if (epr != null) {
- out = openTheConnection(epr, msgContext);
- OutputStream newOut = startSendWithToAddress(msgContext, out);
- if (newOut != null) {
- out = newOut;
- }
- writeMessage(msgContext, out);
- finalizeSendWithToAddress(msgContext, out);
- } else {
- out = (OutputStream) msgContext.getProperty(MessageContext.TRANSPORT_OUT);
- if (out != null) {
- startSendWithOutputStreamFromIncomingConnection(msgContext, out);
- writeMessage(msgContext, out);
- finalizeSendWithOutputStreamFromIncomingConnection(msgContext, out);
- } else {
- throw new AxisFault(
- "Both the TO and Property MessageContext.TRANSPORT_WRITER is Null, No way to send response.");
- }
-}</pre>
-</source>
-<p>So depending on whether your transport is using the same channel to send
-the responce or using a different channel you will need to implement a
-sub-set of the methods from the abstract class.</p>
-
-<p>After implementing the necessary methods you can let Axis2 know about your
-new transport sender by adding an entry to the axis2.xml file like you did
-for the Transport Receiver.</p>
-<source><pre> <transportSender name="TRANSPORT_NAME" class="org.apache.Axis2.transport.TRANSPORT_NAME.TRANSPORT_SENDER_CLASS">
- <parameter name="PROPERTY_NAME" locked="false">PROPERTY_VALUE</parameter>
- <parameter name="PROPERTY_NAME_2" locked="false">PROPERTY_VALUE_2</parameter>
- </transportSender>
- </pre>
-</source>
-<p>Have a look at org.apache.Axis2.transport.mail.MailTransportSender for a
-very simple Transport Sender. Also have a look at
-org.apache.Axis2.transport.http.CommonsHTTPTransportSender which is used to
-send HTTP responses.</p>
-
-<p>Once we have written our transport receiver and our transport sender, and
-inserted the needed entries into the axis2.xml file we are done. It is as
-simple as that. :-)</p>
-</body>
-</html>
+<html>
+<head>
+ <meta http-equiv="content-type" content="">
+ <title></title>
+</head>
+
+<body>
+<h1>How To Write Your Own Axis2 Transport</h1>
+
+<h2>Prologue</h2>
+
+<p>To stop you from reinventing the wheel I will quickly list the transports
+that are already supported in Axis2 with a small description before we get
+started.</p>
+
+<p></p>
+<ul>
+ <li><b>HTTP</b> - In the HTTP transport, the transport Listener is a
+ Servlet or a Simple HTTP server provided by Axis2. The transport Sender
+ uses sockets to connect and send the SOAP Message. Currently we have the
+ commons-httpclient based HTTP Transport sender as the default
+ transport.</li>
+ <li><b>TCP</b> This is the most simple transport, but needs addressing
+ support to be functional.</li>
+ <li><b>SMTP</b> This can work off a single email account or a mailserver.
+ The Mail Transport Receiver is a tread that checks for emails in fixed
+ time intervals.</li>
+</ul>
+
+<p>To understand the rest of this document you will need some understanding
+of the Architecture of Axis2. Therefor if you are not familiar with the
+Architecture of Axis2 you will have to first read the <a
+href="Axis2ArchitectureGuide.html">Axis2 Architecture Guide</a> before you
+read any further.</p>
+
+<h2>Introduction</h2>
+
+<p>Broadly speaking a transport inside Axis2 can be classified as a way of
+getting a messages that arrive though some channel into the Axis2 engine. The
+core of Axis2 is transport independent. All data that is transport specific
+is striped out of the incoming message and inserted into the MessageContext
+and on the outgoing message all transport specific information like headers
+are added and sent.</p>
+
+<p>To write your own transport you will need to primarily write two classes,
+one is the TransportSender and the other is the TransportReceiver. To
+register a transport with Axis2 you will need to put two entries in the
+axis2.xml file. One for the transport receiver and the other for the
+transport sender. We will walk though the process of adding the entries in
+the relevent sections.</p>
+
+<h2>Transport Receiver</h2>
+
+<p>Any message that is comming into Axis2 needs to go though a transport
+receiver. All information about how the message is received at the Axis2
+server from the wire [or by snail mail for that matter:)] is isolated inside
+the transport receiver. It extracts the data that is coming on the wire and
+transforms it into a state that the Axis2 server understands.</p>
+
+<p>So now that we have some background information about how transports work
+inside Axis2 with out further delay why don't we dive into some coding and
+start building out own transport.</p>
+
+<p></p>
+
+<p>To get things stared you will first need to extend from the
+org.apache.Axis2.transport.TransportListener class and write you own
+transport listener. To create an engine to process the MessageContext we need
+a configuration context. The following code fragment will do this. This
+should ideally be only done once for the lifetime of the Transport
+receiver.</p>
+
+<p><source></p>
+<pre>try {
+ //Create a factory
+ ConfigurationContextFactory factory = new ConfigurationContextFactory();
+ //Use the factory and an Axis2 repository to create a new Configuration Context
+ configurationContext = ConfigurationContextFactory.createConfigurationContextFromFileSystem(repository_directory,
+axis2xmllocation);
+} catch (Exception e) {
+ log.info(e.getMessage());
+}</pre>
+</source>
+<p>Now we need some kind of a listener to listen to the requests that come
+in. This you will need to implement according to the transport that you are
+trying to build. After a message is received at the receiver you can use the
+following code to process the request and then forward the message context to
+the engine using thing the engine.receive(msgContext) method.{Following code
+snippet extracted from MailListener as an example}</p>
+<source><pre>AxisEngine engine = new AxisEngine(configurationContext);
+MessageContext msgContext = null;
+// create and initialize a message context
+try {
+ TransportInDescription transportIn =
+ reg.getAxisConfiguration().getTransportIn(new QName(Constants.TRANSPORT_NAME));
+ TransportOutDescription transportOut =
+ reg.getAxisConfiguration().getTransportOut(new QName(Constants.TRANSPORT_NAME));
+ if (transportIn != null && transportOut != null) {
+ //create Message Context
+ msgContext = new MessageContext(configurationContext, transportIn, transportOut);
+ msgContext.setServerSide(true);
+ msgContext.setProperty(MailSrvConstants.CONTENT_TYPE, message.getContentType());
+ msgContext.setProperty(MessageContext.CHARACTER_SET_ENCODING, message.getEncoding());
+
+ String soapAction = message.getSOAPActionHeader();
+ msgContext.setWSAAction(soapAction);
+ msgContext.setSoapAction(soapAction);
+
+ // Here we are trying to set the reply to if it is present in the transport information.
+ msgContext.setReplyTo(new EndpointReference(message.getReplyTo());
+
+ //Create the SOAP Message -- This code in from the mail transport and will change depending
+ //on how the data is handled in each transport.
+ ByteArrayInputStream bais = new ByteArrayInputStream(message.getContent().toString().getBytes());
+ XMLStreamReader reader = XMLInputFactory.newInstance().createXMLStreamReader(bais);
+
+ String soapNamespaceURI = "";
+ if(message.getContentType().indexOf(SOAP12Constants.SOAP_12_CONTENT_TYPE) > -1){
+ soapNamespaceURI = SOAP12Constants.SOAP_ENVELOPE_NAMESPACE_URI;
+ }else if(message.getContentType().indexOf(SOAP11Constants.SOAP_11_CONTENT_TYPE) > -1){
+ soapNamespaceURI = SOAP11Constants.SOAP_ENVELOPE_NAMESPACE_URI;
+ }
+
+ StAXBuilder builder = new StAXSOAPModelBuilder(reader, soapNamespaceURI);
+
+ SOAPEnvelope envelope = (SOAPEnvelope) builder.getDocumentElement();
+ msgContext.setEnvelope(envelope);
+ if (envelope.getBody().hasFault()) {
+ engine.receiveFault(msgContext);
+ } else {
+ engine.receive(msgContext);
+ }
+ } else {
+ throw new AxisFault(Messages.getMessage("unknownTransport",Constants.TRANSPORT_NAME));
+ }
+
+} catch (Exception e) {
+ try {
+ if (msgContext != null) {
+ MessageContext faultContext = engine.createFaultMessageContext(msgContext, e);
+ engine.sendFault(faultContext);
+ } else {
+ log.error(e);
+ }
+ } catch (AxisFault e1) {
+ log.error(e);
+ }
+}</pre>
+</source>
+<p>Now we have the coding in place and we need to let Axis2 know about our
+new transport receiver. How we do this is by addind an entry into the
+axis2.xml file. If you need to pass any properties for the transport to
+operate it can also be done through the axis2.xml file.</p>
+<source><pre> <transportReceiver name="TRANSPORT_NAME" class="org.apache.Axis2.transport.TRANSPORT_NAME.TRANSPORT_LISTNER_CLASS">
+ <parameter name="PROPERTY_NAME" locked="false">PROPERTY_VALUE</parameter>
+ <parameter name="PROPERTY_NAME_2" locked="false">PROPERTY_VALUE_2</parameter>
+ </transportReceiver>
+ </pre>
+</source>
+<p>Using a code fragment like
+Utils.getParameterValue(transportOut.getParameter(MailSrvConstants.SMTP_USER))
+we can extract the parameters that we insert into the axis2.xml file.</p>
+
+<p>So as you can see getting a new transport receiver up and running is a
+task that requires very little effort.</p>
+
+<h2>Transport Sender</h2>
+
+<p>Any message that is to be sent out from Axis2 is sent through the
+Transport Sender. The Transport Sender needs to be extended from the
+org.apache.Axis2.transport.AbstractTransportSender class.</p>
+
+<p>The following bit of code from the abstract transport sender will call the
+Transport Sender that you wrote.</p>
+<source><pre>// If an EPR is present then the message is going on a diffrent channel.
+if (epr != null) {
+ out = openTheConnection(epr, msgContext);
+ OutputStream newOut = startSendWithToAddress(msgContext, out);
+ if (newOut != null) {
+ out = newOut;
+ }
+ writeMessage(msgContext, out);
+ finalizeSendWithToAddress(msgContext, out);
+ } else {
+ out = (OutputStream) msgContext.getProperty(MessageContext.TRANSPORT_OUT);
+ if (out != null) {
+ startSendWithOutputStreamFromIncomingConnection(msgContext, out);
+ writeMessage(msgContext, out);
+ finalizeSendWithOutputStreamFromIncomingConnection(msgContext, out);
+ } else {
+ throw new AxisFault(
+ "Both the TO and Property MessageContext.TRANSPORT_WRITER is Null, No way to send response.");
+ }
+}</pre>
+</source>
+<p>So depending on whether your transport is using the same channel to send
+the responce or using a different channel you will need to implement a
+sub-set of the methods from the abstract class.</p>
+
+<p>After implementing the necessary methods you can let Axis2 know about your
+new transport sender by adding an entry to the axis2.xml file like you did
+for the Transport Receiver.</p>
+<source><pre> <transportSender name="TRANSPORT_NAME" class="org.apache.Axis2.transport.TRANSPORT_NAME.TRANSPORT_SENDER_CLASS">
+ <parameter name="PROPERTY_NAME" locked="false">PROPERTY_VALUE</parameter>
+ <parameter name="PROPERTY_NAME_2" locked="false">PROPERTY_VALUE_2</parameter>
+ </transportSender>
+ </pre>
+</source>
+<p>Have a look at org.apache.Axis2.transport.mail.MailTransportSender for a
+very simple Transport Sender. Also have a look at
+org.apache.Axis2.transport.http.CommonsHTTPTransportSender which is used to
+send HTTP responses.</p>
+
+<p>Once we have written our transport receiver and our transport sender, and
+inserted the needed entries into the axis2.xml file we are done. It is as
+simple as that. :-)</p>
+</body>
+</html>
Modified: webservices/axis2/trunk/java/xdocs/1_1/userguide.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/userguide.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/userguide.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/userguide.html Sun Sep 24 03:02:52 2006
@@ -9,8 +9,6 @@
<h1 align="center"><a name="_Toc96697849" id="_Toc96697849">Apache</a> Axis2
User's Guide</h1>
-<p><i>-Axis2 version 1.0</i></p>
-
<p>This document describes how to write Web Services and Web Service client
using Axis2. It also describes how to write a custom module and engaging it
within a Web Service. Samples shipped with the binary distribution of Axis2,
@@ -161,11 +159,10 @@
Transport</a></li>
<li><a href="http-transport.html" target="_blank">HTTP
Transports</a></li>
- <li><a href="jms-transport.html" target="_blank">JMS
- Transports</a></li>
+ <li><a href="jms-transport.html" target="_blank">JMS Transports</a></li>
<li><a href="mtom-guide.html" target="_blank">MTOM with Axis2</a></li>
- <li><a href="../modules/wss4j/1_0/security-module.html" target="_blank">Securing SOAP
- Messages with Apache Rampart</a></li>
+ <li><a href="../modules/wss4j/1_0/security-module.html"
+ target="_blank">Securing SOAP Messages with Apache Rampart</a></li>
</ul>
</li>
</ul>
Modified: webservices/axis2/trunk/java/xdocs/1_1/userguide1.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/userguide1.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/userguide1.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/userguide1.html Sun Sep 24 03:02:52 2006
@@ -8,8 +8,6 @@
<body lang="en-US" dir="ltr">
<h4><a name="Axis2_User's_Guide">Axis2 User's Guide</a></h4>
-<p><i>Version 1.0</i></p>
-
<p><i>User Feedback: <a
href="mailto:axis-user@ws.apache.org">axis-user@ws.apache.org</a></i>. Prefix
subject with [Axis2]. To subscribe to mailing list see <a
Modified: webservices/axis2/trunk/java/xdocs/1_1/userguide2.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/userguide2.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/userguide2.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/userguide2.html Sun Sep 24 03:02:52 2006
@@ -9,8 +9,6 @@
<body lang="en-US" dir="ltr">
<h4><a name="Axis2_User's_Guide">Axis2 User's Guide</a></h4>
-<p><i>-Axis2 version 1.0</i></p>
-
<p><i>User Feedback: <a
href="mailto:axis-user@ws.apache.org">axis-user@ws.apache.org</a></i>. Prefix
subject with [Axis2]. To subscribe to mailing list see <a
Modified: webservices/axis2/trunk/java/xdocs/1_1/userguide3.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/userguide3.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/userguide3.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/userguide3.html Sun Sep 24 03:02:52 2006
@@ -9,8 +9,6 @@
<body lang="en-US" dir="ltr">
<h4><a name="Axis2_User's_Guide">Axis2 User's Guide</a></h4>
-<p><i>-Axis2 version 1.0</i></p>
-
<p><i>User Feedback: <a
href="mailto:axis-user@ws.apache.org">axis-user@ws.apache.org</a></i>. Prefix
subject with [Axis2]. To subscribe to mailing list see <a
Modified: webservices/axis2/trunk/java/xdocs/1_1/userguide4.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/userguide4.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/userguide4.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/userguide4.html Sun Sep 24 03:02:52 2006
@@ -9,8 +9,6 @@
<body lang="en-US" dir="ltr">
<h4><a name="Axis2_User's_Guide">Axis2 User's Guide</a></h4>
-<p><i>-Axis2 version 1.0</i></p>
-
<p><i>User Feedback: <a
href="mailto:axis-user@ws.apache.org">axis-user@ws.apache.org</a></i>. Prefix
subject with [Axis2]. To subscribe to mailing list see <a
Modified: webservices/axis2/trunk/java/xdocs/1_1/userguide5.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/userguide5.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/userguide5.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/userguide5.html Sun Sep 24 03:02:52 2006
@@ -9,8 +9,6 @@
<body lang="en-US" dir="ltr">
<h4><a name="Axis2_User's_Guide">Axis2 User's Guide</a></h4>
-<p><i>-Axis2 version 1.0</i></p>
-
<p><i>User Feedback: <a
href="mailto:axis-user@ws.apache.org">axis-user@ws.apache.org</a></i>. Prefix
subject with [Axis2]. To subscribe to mailing list see <a
Modified: webservices/axis2/trunk/java/xdocs/1_1/webadminguide.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/webadminguide.html?view=diff&rev=449384&r1=449383&r2=449384
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/webadminguide.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/webadminguide.html Sun Sep 24 03:02:52 2006
@@ -9,11 +9,10 @@
<body lang="en">
<h1 align="center">Apache Axis2 Web Administrator's Guide</h1>
-<p><i>-Axis2 Version 1.0</i></p>
-
<p>This document will give you detailed instructions on administration
console of Axis2 Web application. Axis2 Administration is all about
configuring Axis2 at the run time and the configuration will be transient.</p>
+
<p><i>Send your feedback to: <a
href="mailto:axis-dev@ws.apache.org">axis-dev@ws.apache.org</a></i>. Prefix
subject with [Axis2]. To subscribe to mailing list see <a
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-cvs-help@ws.apache.org