axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cha...@apache.org
Subject svn commit: r507481 - in /webservices/axis2/trunk/java/xdocs/1_1: mail-transport.html migration.html modules.html
Date Wed, 14 Feb 2007 10:50:33 GMT
Author: chatra
Date: Wed Feb 14 02:50:32 2007
New Revision: 507481

URL: http://svn.apache.org/viewvc?view=rev&rev=507481
Log:
reviewed and committing patch in AXIS2-2173

Modified:
    webservices/axis2/trunk/java/xdocs/1_1/mail-transport.html
    webservices/axis2/trunk/java/xdocs/1_1/migration.html
    webservices/axis2/trunk/java/xdocs/1_1/modules.html

Modified: webservices/axis2/trunk/java/xdocs/1_1/mail-transport.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/mail-transport.html?view=diff&rev=507481&r1=507480&r2=507481
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/mail-transport.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/mail-transport.html Wed Feb 14 02:50:32 2007
@@ -3,19 +3,21 @@
 <head>
   <meta http-equiv="content-type" content="">
   <title>Invoking a service using a mail</title>
-  <link href="../css/axis-docs.css" rel="stylesheet" type="text/css" media="all" />
+  <link href="../css/axis-docs.css" rel="stylesheet" type="text/css"
+  media="all">
 </head>
 
 <body>
 <h1>Invoking a Service Using a Mail Transport</h1>
 
-<p>This document basically explains how to invoke a service through Mail
-transports. Content for this document has been listed as follows,</p>
+<p>This document explains how to invoke a service through Mail transports.
+</p>
 
 <p><i>Send your feedback or questions 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
-href="http://ws.apache.org/axis2/mail-lists.html">here.</a></p>
+subject with [Axis2]. You can also <a
+href="http://ws.apache.org/axis2/mail-lists.html">subscribe</a> to the mailig
+list.</p>
 
 <h2>Content</h2>
 <ul>
@@ -29,41 +31,47 @@
 
 <h2>Prologue</h2>
 
-<p>Most of Web services that we interact with are synchronous and
+<p>Most of the Web services that we interact with are synchronous and
 request-response in nature. However, we see that the synchronous
 request-response type of interaction is only a part of the messaging
 scenarios we encounter in real life. Asynchronous messaging is very important
-in constructing loosely coupled systems. Take for instance a chain of stores,
-at the end of the day all the stores all over can send a mail to the central
-system telling it what that days business activity was and in the morning
-when the store opens there will be a reply to that mail with new instructions
-and updates. It is a lot like the way the old business worked but with a
-modern touch. Similarly Axis2 mail transport can be used to implement
+in constructing loosely coupled systems. Take for instance a chain of stores.
+At the end of the day, all the stores can send a mail to the central system
+telling it about that day's business activities, and when the store opens in
+the morning, there will be a reply to that mail with new instructions and
+updates. It is a lot like the way old businesses worked, but with a modern
+touch. Similarly, the Axis2 mail transport can be used to implement
 asynchronous messaging through mail.</p>
 <a name="intro"></a>
 
 <h2>Introduction</h2>
 
-<p>To start you will first need to go through the <a
-href="mail-configuration.html" target="_blank">Mail Transport
-Configuration</a> document. It will provide the user with the first hand experience in setting up the mail transports to co-exists with Axis2.</p>
+<p>First, you need to go through the <a href="mail-configuration.html"
+target="_blank">Mail Transport Configuration</a> document. It provides first
+hand experience in setting up the mail transports to co-exist with Axis2.</p>
 
-<p>Broadly speaking there are 3 ways of calling a service through mail.</p>
+<p>Broadly speaking, there are three ways of calling a service through
+mail.</p>
 
 <blockquote>
-  1. Using the simple mail server included in Axis2(not recommended in production).<br>
+  1. Using the simple mail server included in Axis2 (not recommended in
+  production).<br>
   2. Using a generic mail server.<br>
   3. Using mailets.<br>
 </blockquote>
 
-<p>Options 1 and 2 are fairly simple and easy to implement, whereas
-option 3 is somewhat harder.The mailet scenario however does provide a more
-robust and useful solution in a production environment.</p>
-
-<p>It is very easy to start learning the workings of mail transports with the aid of Simple Mail Server that provides with Axis2. Once you get the hang of the Axis2 related issues then you can move on to tackle the mail beast. Please do note that the Simple Mail Server that provides with Axis2 is not graded for production use.</p>
+<p>Options 1 and 2 are fairly simple and easy to implement, whereas option 3
+is somewhat harder. The mailet scenario however does provide a more robust
+and useful solution in a production environment.</p>
+
+<p>It is very easy to start learning the workings of mail transports with the
+aid of the Simple Mail Server that is provided with Axis2. Once you get the
+hang of Axis2 related issues, then you can move on to tackle the mail beast.
+Please do note that the Simple Mail Server provided with Axis2 is not graded
+for production use.</p>
 <a name="axis2"></a>
 
-<h2>1. Using Simple Mail Server Included in Axis2</h2>
+<h2>1. Using the Simple Mail Server Included in Axis2</h2>
 
 <p>The SMTP/POP server that we have included has the ability to function as a
 standalone SMTP/POP server and also has the ability to work as a mailet. All
@@ -72,9 +80,9 @@
 changed by doing a simple edit of the filter class
 org.apache.axis2.transport.mail.server.Sorter.</p>
 
-<p>Now that we have the environment set up, let us start pumping out some
-code to get the mail functionality off the ground. First we'll have a look at
-it from the mail server side. <br>
+<p>Now that we have the environment set up, we can use the code below to get
+the mail functionality started. First we'll have a look at it from the mail
+server side. <br>
 </p>
 <source><pre>        // Start the mail server using the default configurations.
         ConfigurationContext configContext = UtilsMailServer.start();
@@ -95,12 +103,12 @@
                 .getName(), operationName);
         serverConfigContext.getAxisConfiguration().addService(service);</pre>
 </source>
-<p>This code sets up your Axis2 server working through mail, with a single
-service. If you need to have a look under the hood check out the MailServer
-and UtilsMailServer classes.</p>
+<p>This code sets up your Axis2 server which uses a single service to work
+through the mail. If you want to have a look under the hood, check out the
+MailServer and UtilsMailServer classes.</p>
 
-<p>Moving onto the client side have a look at the code listing below. It will
-call the axisService that was setup on the previous code listing.</p>
+<p>Moving onto the client side, have a look at the code listing below. It
+will call the axisService that was setup in the previous code listing.</p>
 <source><pre>        ConfigurationContext configContext = UtilsMailServer
                 .createClientConfigurationContext();
         AxisService service = new AxisService(serviceName.getLocalPart());
@@ -114,7 +122,7 @@
         service.addOperation(axisOperation);
         configContext.getAxisConfiguration().addService(service);
         ServiceContext serviceContext = new ServiceGroupContext(configContext,
-        		(AxisServiceGroup) service.getParent()).getServiceContext(service);
+                        (AxisServiceGroup) service.getParent()).getServiceContext(service);
 
         Options options = new Options();
         options.setTo(targetEPR);
@@ -150,7 +158,7 @@
         while (!finish) {
             Thread.sleep(1000);
             index++;
-            if (index > 10) {
+            if (index &gt; 10) {
                 throw new AxisFault(
                         "Server was shutdown as the async response is taking too long to complete.");
             }
@@ -158,23 +166,22 @@
 
     }</pre>
 </source>
-<p>This will call the service that was setup on the server and will poll the
-mail server till the response is received.Please do note that serviceName and operationName need to be QNames.</p>
-
+<p>This will call the service that was setup on the server, and will poll the
+mail server until the response is received. Please note that the serviceName
+and operationName need to be QNames.</p>
 <a name="generic"></a>
 
 <h2>2. Using a Generic Mail Server</h2>
 
-<p>First you need two email accounts that works with POP/SMTP. One will act
-as a server and the other will act as the client. For the time being we will
+<p>First you need two email accounts that work with POP/SMTP. One will act as
+a server and the other will act as the client. For the time being, we will
 use server@somewhere.org and client@somewhere.org as the server and the
-client email addresses. Now that we have the email addresses you will have to
-set up the client and the server with Mail Transport <a
-href="mail-configuration.html"
-target="_blank">configuration document</a>.</p>
+client email addresses. Now that we have the email addresses, you will have
+to set up the client and the server using the Mail Transport <a
+href="mail-configuration.html" target="_blank">configuration document</a>.</p>
 
-<p>When calling the generic mail server the client side code will remain the
-same and there will be some modification to the server-side code.</p>
+<p>When you call the generic mail server, the client side code will remain
+the same and there will be some modification to the server-side code.</p>
 
 <p></p>
 <source><pre>        // Create a configuration context. This will also load the details about the mail
@@ -204,7 +211,6 @@
 <!--a name="mailet"></a>
 
 <h3>3. Calling Axis2 Through a Mailet</h3-->
-
 
 <p></p>
 </body>

Modified: webservices/axis2/trunk/java/xdocs/1_1/migration.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/migration.html?view=diff&rev=507481&r1=507480&r2=507481
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/migration.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/migration.html Wed Feb 14 02:50:32 2007
@@ -1,22 +1,25 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
 <head>
+  <meta http-equiv="content-type" content="">
   <title>Migrating from Axis 1.x</title>
-  <link href="../css/axis-docs.css" rel="stylesheet" type="text/css" media="all" />
+  <link href="../css/axis-docs.css" rel="stylesheet" type="text/css"
+  media="all">
 </head>
 
 <body lang="en">
-<h1>Migrating from Apache Axis 1.x to Axis 2</h1>
+<h1>Migrating from Apache Axis 1.x to Axis2</h1>
 
-<p>For all those users who are familiar with Axis2 1.x series will be
-assisted through this document to switch to Axis2 series. We begin by listing
-the improvements in Axis2 in comparison with Axis1. This is followed by
+<p>For all those users who are familiar with Axis 1.x series will be assisted
+through this document to switch to Axis2 series. We begin by listing the
+improvements in Axis2 in comparison with Axis1. This is followed by
 guidelines for the migration.</p>
 
 <p><i>Send your feedback or questions to: <a
 href="mailto:axis-dev@ws.apache.org">axis-dev@ws.apache.org</a></i>. Prefix
-subject with [Axis2]. To subscribe to the mailing list see <a
-href="http://ws.apache.org/axis2/mail-lists.html">here.</a></p>
+subject with [Axis2]. You can also <a
+href="http://ws.apache.org/axis2/mail-lists.html">subscribe</a> to the
+mailing list.</p>
 
 <h2>Content</h2>
 <ul>
@@ -32,34 +35,35 @@
 
 <h2>Compatibility</h2>
 
-<p>Axis1.x and Axis2 have been evolved from different architectures.</p>
+<p>Axis1.x and Axis2 have evolved from different architectures.</p>
 
 <p><strong>Speed</strong> - Axis2 is based on StAX API, which gives greater
 speed than SAX event based parsing that has been used in Axis1.x.</p>
 
-<p><strong>Stability</strong> - Axis2 has fixed phases and for extensions an
-area of user defined phases. This allows far more stability and flexibility
-than Axis1.x.</p>
+<p><strong>Stability</strong> - Axis2 has fixed phases as well as
+user-defined phases for extensions. This allows far more stability as well as
+flexibility than Axis1.x.</p>
 
 <p><strong>Transport framework</strong> - Simple abstraction in the designing
 of transports (i.e., senders and listeners for SOAP over various protocols
 such as SMTP, etc), allows far more flexibility and the core of the engine is
 completely transport-independent.</p>
 
-<p><strong>WSDL support</strong> - Axis2 supports version 1.1 and 2.0, which
-allows creating stubs and skeletons, to manipulate the web services arena.</p>
-
-<p><strong>Component - oriented architecture</strong> - This is merely
-through archives (.mar and .aar) . Easily reusable components such as
-handlers, modules allow patterns processing for your applications, or to
-distribution to partners. Axis2 is more concerned on the "Module" concept
-rather the "Handler" concept. Modules contain handlers that have been ordered
-through the phase rules. These are ordered to specific service(s).</p>
+<p><strong>WSDL support</strong> - Axis2 supports versions 1.1 and 2.0, which
+allow you to create stubs and skeletons to manipulate the web services
+arena.</p>
+
+<p><strong>Component - oriented architecture</strong> - The components are
+.mar and .aar archives . Easily reusable components such as handlers and
+modules allow pattern processing for your applications or distribution to
+partners. Axis2 is more concerned on the "Module" concept rather the
+"Handler" concept. Modules contain handlers that have been ordered through
+the phase rules. These are ordered to specific service(s).</p>
 <a name="start"></a>
 
 <h2>Getting Started</h2>
 
-<p>Lets look at a simple example of echoing at client API.</p>
+<p>Let's look at a simple example of echoing at client API.</p>
 
 <p><b>Axis 1.x</b></p>
 <pre>import ...
@@ -103,35 +107,35 @@
 }</pre>
 
 <p>It has been clearly depicted that the invocation in Axis2 is dealt with
-SOAP body element itself. Here the invocation is synchronous but Axis2 can
-handle asynchronous invocations as well. The "payload" variable above
-contains the SOAP body element which should go in the soap envelope.</p>
-
-<p>Once the service is called through the stub in Axis2, "payload" is
-according to the data binding framework that will be used. So the extra work
-of "payload" will be vanished.</p>
-
-<p>Apart from synchronous invocation, Axis2 supports asynchronous invocation
-through sendReceiveNonblocking(). Synchronous/Asynchronous invocations can
-handle both single/double HTTP connections.</p>
+the SOAP body element itself. Here the invocation is synchronous, but Axis2
+can handle asynchronous invocations as well. The "payload" variable above
+contains the SOAP body element which should go in the SOAP envelope.</p>
+
+<p>Once the service is called through the stub in Axis2, the "payload" will
+be according to the data binding framework that will be used. So the extra
+work of "payload" will vanish.</p>
+
+<p>Apart from synchronous invocation, Axis2 also supports asynchronous
+invocation through sendReceiveNonblocking(). Synchronous/Asynchronous
+invocations can handle both single and double HTTP connections.</p>
 
 <p>With this advanced architecture, Axis2 is capable of handling megabytes of
-requests and responses, which is far from what Axis1.x was capable of.</p>
+requests and responses, which is far from the capabilities of Axis1.x.</p>
 <a name="custom_deployment"></a>
 
-<h2>Custom Deployment of Services, Handlers and Modules</h2>
+<h2>Custom Deployment of Services, Handlers, and Modules</h2>
 
 <p>In Axis 1.x, the deployment of services was via WSDD, which in my opinion
 was highly cumbersome. Service deployment in Axis2 is straight forward and
 dynamic. Dynamic behavior is from the "Administrator" facility given by the
-development in the server side. It's just a matter of creating the .aar file,
+development in the server side. It's just a matter of creating the .aar file
 and deploying it. More details regarding this is given in the Axis2 user
 guide.</p>
 
-<p>Axis2 is far from the "Handler concept" and is more into the "Module
-concept". Abstractly speaking, the module concept is a collection of handlers
-with rules of governing which modules are created as .mar files. It has
-module.xml, which is the brain behind manipulating the handlers.</p>
+<p>Axis2 has moved away from the "Handler concept" and is more into the
+"Module concept". Abstractly speaking, the module concept is a collection of
+handlers with rules that govern which modules are created as .mar files. It
+has module.xml, which is the brain behind manipulating the handlers.</p>
 
 <p>When a service is called through a handler, it is just a matter of giving
 a reference to the module that includes the handler in the services.xml
@@ -140,12 +144,12 @@
 <p>Services are hot deployable in Axis2, but modules are not. This is one
 feature which is unique to Axis2.</p>
 
-<p>Lets take a detailed look at what it takes to migrate the Axis 1.x
+<p>Let's take a detailed look at what it takes to migrate the Axis 1.x
 handlers to the Axis 2 modules via the "SOAP Monitor". The SOAP monitor is
-really a combination of three components: An applet which displays responses
-/ requests, a servlet which binds to a default port of 5001 and connects to
-the applet, and a handler chain used to intercept the soap messages. Here
-we'll focus on the handler.</p>
+really a combination of three components: An applet which displays
+responses/requests, a servlet which binds to a default port of 5001 and
+connects to the applet, and a handler chain used to intercept the SOAP
+messages. Here we'll focus on the handler.</p>
 
 <p><b>Axis 1.x required two WSDD's to use the SOAP Monitor. First, the SOAP
 Monitor Handler itself:</b></p>
@@ -217,11 +221,12 @@
     &lt;/INfaultflow&gt;
 &lt;/module&gt;</pre>
 
-<p>The SOAPMonitorModule referenced above simply implements
-org.apache.axis2.modules.Module and is used for any additional tasks needed
-to initialize the module and shutdown the module. In this case nothing is
-needed and the implemented interface methods have blank bodies. Furthermore,
-the 'soapmonitorPhase' will be used later below in the axis2.xml .</p>
+<p>The SOAPMonitorModule referenced above simply implements the
+org.apache.axis2.modules.Module, and is used for any additional tasks needed
+to initialize the module and shutdown the module. In this situation, nothing
+is needed and the implemented interface methods have blank bodies.
+Furthermore, the 'soapmonitorPhase' will be used later (below) in the
+axis2.xml .</p>
 
 <p><b>Axis 1.x the SOAPMonitorHandler has the class signature as:</b></p>
 <pre>public class SOAPMonitorHandler extends BasicHandler</pre>
@@ -229,7 +234,7 @@
 <p><b>Axis 2 the SOAPMonitorHandler has the class signature as:</b></p>
 <pre>public class SOAPMonitorHandler extends AbstractHandler </pre>
 
-<p><b>In axis2, you need to reference the module that contains the handler
+<p><b>In Axis2, you need to reference the module that contains the handler
 chain that you want to use inside your services.xml:</b></p>
 <pre>&lt;service name="ExampleService"&gt;
     &lt;module ref="soapmonitor"/&gt;
@@ -242,12 +247,12 @@
     &lt;/operation&gt;
 &lt;/service&gt;</pre>
 
-<p><b>Finally, axis2 requires you to make some changes to axis2.xml. Start by
+<p><b>Finally, Axis2 requires you to make some changes to axis2.xml. Start by
 adding a global module:</b></p>
 <pre>    &lt;module ref="soapmonitor"/&gt;</pre>
 
-<p><b>Then define your phase orders for 'soapmonitorPhase' referenced in the
-module.xml :</b></p>
+<p><b>Then define your phase orders for the 'soapmonitorPhase' referenced in
+the module.xml :</b></p>
 <pre>    &lt;phaseOrder type="inflow"&gt;
         &lt;!--  Global Phases       --&gt;
         &lt;phase name="TransportIn"/&gt;
@@ -307,16 +312,16 @@
         &lt;!--   Global phases   --&gt;
     &lt;/phaseOrder&gt;</pre>
 
-<p>See the user guide for more info on axis2 modules.</p>
+<p>See the user guide for more information on Axis2 modules.</p>
 <a name="transports"></a>
 
 <h2>Transports for HTTP Connection</h2>
 
-<p>Axis2 comes with two  CommonsHTTPTransportSender which is based on
+<p>Axis2 comes with the CommonsHTTPTransportSender which is based on
 commons-httpclient.</p>
 
 <p>It should be noted that axis2.xml should be configured to call the commons
-transports, with the statement,</p>
+transports with the statement,</p>
 <pre>...
 &lt;transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender"&gt; 
    &lt;parameter name="PROTOCOL" locked="false"&gt;HTTP/1.1&lt;/parameter&gt; 
@@ -327,7 +332,7 @@
 
 <h2>Data Binding Support</h2>
 
-<p>ADB is used to provide data binding support. In Axis2, xml is manipulated
+<p>ADB is used to provide data binding support. In Axis2, XML is manipulated
 via AXIOM, which is based on the StAX API. XML gives full schema support.
 Thus, serialization and de-serialization of XML is handled in Axis2 via the
 xml-data binding framework.</p>
@@ -335,9 +340,9 @@
 <p>Below is an example of migrating an WSDL based Axis 1.x Web Service to
 Axis2.</p>
 
-<p>First, lets take a look at a simple document / literal style WSDL used in
+<p>First, let's take a look at a simple document/literal style WSDL used in
 an Axis 1.x Web Service. This example assumes the name simple.wsdl for the
-wsdl below:</p>
+WSDL below:</p>
 <pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
 
 &lt;definitions name="SimpleService" targetNamespace="http://simpleNS" xmlns:tns="http://simpleNS" 
@@ -395,7 +400,7 @@
       &lt;soap:address location="http://localhost:8080/axis/services/SimpleEndpointPort"/&gt;&lt;/port&gt;&lt;/service&gt;&lt;/definitions&gt;</pre>
 
 <p>The next step is to run WSDL2Java on the wsdl. For axis 1.x, this example
-uses the following ant task:</p>
+uses the following Ant task:</p>
 <pre>&lt;target name="wsdl2java" description="axis 1.x"&gt;
        &lt;delete dir="output" /&gt;
        &lt;mkdir dir="output" /&gt;
@@ -409,7 +414,7 @@
        &lt;/axis-wsdl2java&gt;
    &lt;/target&gt;</pre>
 
-<p>The axis 1.x ant task above takes the simple.wsdl under the directory
+<p>The Axis 1.x Ant task above takes the simple.wsdl under the directory
 'wsdl' , and from that creates files under the directory 'output'. The files
 created are shown below:</p>
 <pre>output/
@@ -426,14 +431,14 @@
 output/simpleNS/deploy.wsdd
 output/simpleNS/undeploy.wsdd</pre>
 
-<p>Now lets run WSDL2Java with Axis2. In this example, the only change to
-simple.wsdl required for axis2 is that 'soap:address location' be changed
+<p>Now let's run WSDL2Java with Axis2. In this example, the only change to
+simple.wsdl required for Axis2 is that 'soap:address location' be changed
 to:</p>
 <pre>&lt;soap:address location="http://localhost:8080/axis2/services/SimpleEndpoint"/&gt;&lt;/port&gt;&lt;/service&gt;&lt;/definitions&gt;</pre>
 
-<p>In Axis2 the default databinding uses ADB. However, xmlbeans and jaxme are
-also supported. This example uses xmlbeans. For Axis2, our example uses the
-following ant task:</p>
+<p>In Axis2, the default databinding uses ADB. However, XMLBeans and JaxMe
+are also supported. This example uses XMLBeans. For Axis2, our example uses
+the following Ant task:</p>
 <pre>&lt;target name="wsdl2java"&gt;
       &lt;delete dir="output" /&gt;
       &lt;java classname="org.apache.axis2.wsdl.WSDL2Java" fork="true"&gt;
@@ -461,18 +466,18 @@
 
   &lt;/target&gt;</pre>
 
-<p>For an explanation of the Axis2 WSDL2Java ant task and its options, see
+<p>For an explanation of the Axis2 WSDL2Java Ant task and its options, see
 the <a href="../tools/1_1/CodegenToolReference.html">CodegenToolReference
 Guide.</a></p>
 
-<p>A feature of xmlbeans is that there is one class file created with
-WSDL2java, and a series of xsb files. These must be referenced when
-compiling, and as the example shows these files are moved to a build
+<p>A feature of XMLBeans is that there is one class file created with
+WSDL2java, and a series of .xsb files. They must be referenced when
+compiling, and as the example shows, these files are moved to a build
 directory.</p>
 
-<p>The Axis2 WSDL2Java example also takes the simple.wsdl which is under the
-directory 'wsdl' and from that creates files under the directory 'output'.
-The relevant non-xmlbean files created are shown below:</p>
+<p>The Axis2 WSDL2Java example also takes the simple.wsdl, which is under the
+directory 'wsdl', and creates files under the directory 'output'. The
+relevant non-xmlbean files created are shown below:</p>
 <pre>output/resources/services.xml
 output/src/org/simple
 output/src/org/simple/endpoint
@@ -495,7 +500,7 @@
 them. See the Axis2 user guide for an explanation about services.xml</p>
 
 <p>Now we're ready to code. We'll start with Axis 1.x on the service side. To
-implement the business logic we'll change
+implement the business logic, we'll change
 simpleNS/SimpleEndpointBindingImpl.java from:</p>
 <pre class="code">package simpleNS;
 
@@ -523,14 +528,14 @@
 }</pre>
 
 <p>In Axis 1.x, the next step is to compile the classes and put them in the
-Axis.war, and then run the admin client with the generated deploy.wsdd.
-You'll then look at the happy axis page to verify the service is installed
-correctly.</p>
+Axis.war, and then run the admin client with the generated deploy.wsdd. You
+then look at the happy axis page to verify that the service has been
+installed correctly.</p>
 
-<p>Now lets code Axis2. In Axis 1.x, while the ant task shown in the example
+<p>Now let's code Axis2. In Axis 1.x, while the Ant task shown in the example
 created a skeleton, a peek inside shows that the skeleton calls the binding
-implementation class. In Axis2 we work with the skeleton directly. To
-implement the business logic in the Axis2 generated classes we'll change
+implementation class. In Axis2, we work with the skeleton directly. To
+implement the business logic in the generated Axis2 classes, we'll change
 org/simple/endpoint/SimpleEndpointSkeleton.java from:</p>
 <pre class="code">package org.simple.endpoint;
     /**
@@ -588,8 +593,8 @@
 
 <p>In Axis2, the next step is to compile the classes, put them along with the
 generated services.xml in an AAR, and then hot deploy the AAR by placing it
-in the Axis2.war under WEB-INF/services . Point a browser to
-http://localhost:8080/axis2/listServices , and you should see the service
+in the Axis2.war under WEB-INF/services. Point a browser to
+http://localhost:8080/axis2/listServices, and you should see the service
 'SimpleService' ready for action. See the Axis2 user guide for more info.</p>
 
 <p>The last step is the client. Our Axis 1.x client for this example is:</p>
@@ -654,14 +659,15 @@
 }</pre>
 
 <p>Axis2 clients also have asynchronous options via a Callback and
-alternatively 'Fire and forget'. See the user guide for more details.</p>
+alternatively a 'Fire and forget'. See the user guide for more details.</p>
 <a name="best"></a>
 
 <h2>Best Usage</h2>
 
 <p>Axis1.x and Axis2 have different ways of seeing the SOAP stack. So the
-best way to migrate is to follow the <a href="userguide.html">User's Guide</a> and the <a href="Axis2ArchitectureGuide.html">Architecture Guide</a> of
-Axis2 properly. Axis2 is very much straight forward and friendly to use than
-it's predecessor.</p>
+best way to migrate is to follow the <a href="userguide.html">User's
+Guide</a> and the <a href="Axis2ArchitectureGuide.html">Architecture
+Guide</a> of Axis2 properly. Axis2 is very straight forward and friendly to
+use than its predecessor.</p>
 </body>
 </html>

Modified: webservices/axis2/trunk/java/xdocs/1_1/modules.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/modules.html?view=diff&rev=507481&r1=507480&r2=507481
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/modules.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/modules.html Wed Feb 14 02:50:32 2007
@@ -2,40 +2,47 @@
 <head>
   <meta http-equiv="content-type" content="">
   <title>Writing your Own Axis2 Module</title>
-  <link href="../css/axis-docs.css" rel="stylesheet" type="text/css" media="all" />
+  <link href="../css/axis-docs.css" rel="stylesheet" type="text/css"
+  media="all">
 </head>
 
 <body dir="ltr" lang="en-US">
-
 <a name="Modules"></a>
-<h1></a>Writing your Own Axis2 Module</h1>
 
-<p>Axis2 provides extended support for modules (See <a
+<h1>Writing Your Own Axis2 Module</h1>
+
+<p>Axis2 provides extended support for modules (See the <a
 href="Axis2ArchitectureGuide.html" target="_blank">Architecture Guide</a> for
 more details about modules in Axis2). Let's create a custom module and deploy
-it to MyService which we created earlier.</p>
+it to MyService, which we created earlier.</p>
 
 <p><i>Send your feedback or questions 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
-href="http://ws.apache.org/axis2/mail-lists.html">here.</a></p>
+subject with [Axis2]. You can also <a
+href="http://ws.apache.org/axis2/mail-lists.html">subscribe</a> to the
+mailing lists.</p>
 
 <h2>Content List</h2>
 <ul>
-  <li><a href="#MyService_with_a_Logging_Module">MyService with a Logging Module</a></li>
-  <ul>
-      <li><a href="#Step1_:_LoggingModule_Class">Step1 : LoggingModule Class</a></li>
+  <li><a href="#MyService_with_a_Logging_Module">MyService with a Logging
+    Module</a>
+    <ul>
+      <li><a href="#Step1_:_LoggingModule_Class">Step1 : LoggingModule
+        Class</a></li>
       <li><a href="#Step2_:_LogHandler">Step2 : LogHandler</a></li>
       <li><a href="#Step3_:_module_xml">Step3 : module.xml</a></li>
-      <li><a href="#Step_4:_Modify_the_&#34;axis2_xml&#34;">Step 4: Modify the "axis2.xml"</a></li>
-      <li><a href="#Step5_:_Modify_the_&#34;services_xml&#34;">Step5 : Modify the "services.xml</a></li>
+      <li><a href="#Step_4:_Modify_the_&quot;axis2_xml&quot;">Step4: Modify
+        the "axis2.xml"</a></li>
+      <li><a href="#Step5_:_Modify_the_&quot;services_xml&quot;">Step5 :
+        Modify the "services.xml</a></li>
       <li><a href="#Step6_:_Packaging">Step6 : Packaging</a></li>
-      <li><a href="#Step7_:_Deploy_the_Module_in_Axis2">Step7 : Deploy the Module in Axis2</a></li>
-  </ul>
+      <li><a href="#Step7_:_Deploy_the_Module_in_Axis2">Step7 : Deploy the
+        Module in Axis2</a></li>
+    </ul>
+  </li>
 </ul>
 
-
-<p>Following steps show the actions that need to be performed to deploy a
+<p>The following steps show the actions that need to be performed to deploy a
 custom module for a given Web service:</p>
 <ol>
   <li><p style="margin-bottom: 0in">Create the Module Implementation</p>
@@ -55,21 +62,21 @@
   <li><p>Deploy the module in Axis2</p>
   </li>
 </ol>
-
 <a name="MyService_with_a_Logging_Module"></a>
+
 <h3>MyService with a Logging Module</h3>
 
-<p>Let's write a simple logging module for our sample located at
+<p>Let's write a simple logging module for our sample located at the
 <b>"samples\userguide\src"</b> directory of the binary distribution. This
 module contains one handler that just logs the message that is passed through
-it. Axis2 uses ".mar" (Module Archive) to deploy modules in Axis2. Following
-diagram shows the file structure inside which needs to be there in the ".mar"
-archive. Let's create all these and see how it works.</p>
+it. Axis2 uses ".mar" (Module Archive) to deploy modules in Axis2. The
+following diagram shows the file structure inside which needs to be there in
+the ".mar" archive. Let's create all these and see how it works.</p>
 
 <p><img src="images/userguide/ModuleView.jpg" name="Graphic5" align="bottom"
 border="0"></p>
-
 <a name="Step1_:_LoggingModule_Class"></a>
+
 <h4>Step1 : LoggingModule Class</h4>
 
 <p>LoggingModule is the implementation class of the Axis2 module. Axis2
@@ -81,21 +88,20 @@
 public void engageNotify(AxisDescription axisDescription) throws AxisFault;
 public String[] getPolicyNamespaces() throws AxisFault;
 public void applyPolicy(Policy policy, AxisDescription axisDescription) throws AxisFault ;
-public boolean canSupportAssertion(Assertion assertion) ;
-</pre>
-
-<p>Firt three methods can be used to control the module initialization and the
-termination , and the next three methods are used to perform policy related stuff
-With the input parameter AxisConfiguration, the user is provided
-with the complete configuration hierarchy. This can be used to fine-tune the
-module behavior by the module writers. For the simple logging service we can
-keep these methods blank in our implementation class.</p>
+public boolean canSupportAssertion(Assertion assertion) ;</pre>
 
+<p>The first three methods can be used to control the module initialization
+and the termination, and the next three methods are used to perform policy
+related operations. With the input parameter AxisConfiguration, the user is
+provided with the complete configuration hierarchy. This can be used to
+fine-tune the module behavior by the module writers. For a simple logging
+service, we can keep these methods blank in our implementation class.</p>
 <a name="Step2_:_LogHandler"></a>
+
 <h4>Step2 : LogHandler</h4>
 
 <p>A module in Axis2 can contain, one or more handlers that perform various
-SOAP header processing at different phases. (See<a
+SOAP header processing at different phases. (See the<a
 href="Axis2ArchitectureGuide.html#incomingsoap" target="_blank"> Architecture
 Guide</a> for more information on phases). To write a handler one should
 implement <a
@@ -104,11 +110,11 @@
 href="http://svn.apache.org/viewcvs.cgi/webservices/axis2/trunk/java/modules/core/src/org/apache/axis2/handlers/AbstractHandler.java?rev=396788&amp;view=log">org.apache.axis2.handlers.AbstractHandler</a>
 provides an abstract implementation of the Handler interface.</p>
 
-<p>For the logging module we will write a handler with the following methods.
-"public void invoke(MessageContext ctx);" is the method that is called by
-Axis2 engine when the control is passed to the handler. "public void
-revoke(MessageContext ctx);" is called when the handlers are revoked by the
-Axis2 engine.</p>
+<p>For the logging module, we will write a handler with the following
+methods. "public void invoke(MessageContext ctx);" is the method that is
+called by the Axis2 engine when the control is passed to the handler. "public
+void revoke(MessageContext ctx);" is called when the handlers are revoked by
+the Axis2 engine.</p>
 <pre>public class LogHandler extends AbstractHandler implements Handler {
     private static final Log log = LogFactory.getLog(LogHandler.class);
     private String name;
@@ -130,15 +136,15 @@
         this.name = name;
     }
 }</pre>
-
 <a name="Step3_:_module_xml"></a>
+
 <h4>Step3 : module.xml</h4>
 
 <p>"module.xml" contains the deployment configurations for a particular
-module. It contains details such as Implementation class of the module (in
-this example it is the "LoggingModule" class and various handlers that will
-run in different phases). "module.xml" for the logging module will be as
-follows:</p>
+module. It contains details such as the Implementation class of the module
+(in this example it is the "LoggingModule" class and various handlers that
+will run in different phases). The "module.xml" for the logging module will
+be as follows:</p>
 <pre>&lt;module name="logging" class="userguide.loggingmodule.LoggingModule "&gt;
    &lt;inflow&gt;
         &lt;handler name="InFlowLogHandler" class="userguide.loggingmodule.LogHandler"&gt;
@@ -165,7 +171,7 @@
    &lt;/INfaultflow&gt;
 &lt;/module&gt;</pre>
 
-<p>As you can see there are four flows defined in this "module.xml"</p>
+<p>As you can see, there are four flows defined in the "module.xml"</p>
 <ol>
   <li>inflow - Represents the handler chain that will run when a message is
     coming in. </li>
@@ -173,21 +179,21 @@
     that will run when the message is going out. </p>
   </li>
   <li><p style="margin-bottom: 0in">Outfaultflow - Represents the handler
-    chain that will run when there is a fault and the fault is going out</p>
+    chain that will run when there is a fault, and the fault is going out.</p>
   </li>
   <li><p>INfaultflow - Represents the handler chain that will run when there
-    is a fault and the fault is coming in </p>
+    is a fault, and the fault is coming in. </p>
   </li>
 </ol>
 
-<p>Following set of tags describe the name of the handler, handler class and
-the phase in which this handler is going to run. "InFlowLogHandler" is the
-name given for the particular instance of this handler class. The value of
-class attribute is the actual implementation class for this handler. Since we
-are writing logging handler, we can reuse the same handler in all these
-phases. However this may not be the same for all the modules. "&lt;order
-phase="loggingPhase" /&gt;" describes the phase in which this handler
-runs.</p>
+<p>The following set of tags describe the name of the handler, handler class,
+and the phase in which this handler is going to run. "InFlowLogHandler" is
+the name given for the particular instance of this handler class. The value
+of the class attribute is the actual implementation class for this handler.
+Since we are writing a logging handler, we can reuse the same handler in all
+these phases. However, this may not be the same for all the modules.
+"&lt;order phase="loggingPhase" /&gt;" describes the phase in which this
+handler runs.</p>
 <pre>&lt;handler name="InFlowLogHandler" class="userguide.loggingmodule.LogHandler"&gt;
 &lt;order phase="loggingPhase" /&gt;
 &lt;/handler&gt;</pre>
@@ -195,17 +201,18 @@
 <p>To learn more about Phase rules, check out the article <a
 href="http://www.developer.com/java/web/article.php/3529321"
 target="_blank">Axis2 Execution Framework</a></p>
-
 <a name="Step_4:_Modify_the_&#34;axis2_xml&#34;"></a>
+
 <h4>Step 4: Modify the "axis2.xml"</h4>
 
-<p>In this handler, the phase "loggingPhase", is defined by the module
-writer. It is not a pre-defined handler phase, hence the module writer should
-introduce it to the "axis2.xml" (NOT the services.xml) so that the Axis2
-engine knows where to place the handler in different "flows" ( inFlow,
-outFlow, etc.). Following xml lines show the respective changes made to the
-"axis2.xml" in order to deploy this logging module in the Axis2 engine. This
-is an extract of the phase section of "axis2.xml".</p>
+<p>In this handler, the "loggingPhase", is defined by the module writer. It
+is not a pre-defined handler phase, hence the module writer should introduce
+it to the "axis2.xml" (NOT the services.xml) so that the Axis2 engine knows
+where to place the handler in different "flows" (inFlow, outFlow, etc.). The
+following XML lines show the respective changes made to the "axis2.xml" in
+order to deploy the logging module in the Axis2 engine. This is an extract of
+the phase section of "axis2.xml".</p>
+
 <p><pre>&lt;!-- ================================================= --&gt;
 &lt;!-- Phases --&gt;
 &lt;!-- ================================================= --&gt;
@@ -242,7 +249,7 @@
         &lt;!--  System pre defined phases       --&gt;
         &lt;!--   After Postdispatch phase module author or service author can add any phase he wants      --&gt;
         &lt;phase name="OperationInPhase"/&gt;
-		&lt;phase name="<span style="color: rgb(36, 193, 19);">loggingPhase</span>"/&gt;
+                &lt;phase name="<span style="color: rgb(36, 193, 19);">loggingPhase</span>"/&gt;
     &lt;/phaseOrder&gt;
     &lt;phaseOrder type="outflow"&gt;
         &lt;!--      user can add his own phases to this area  --&gt;
@@ -271,24 +278,25 @@
 flows, hence that phase will be called in all the message flows in the
 engine. Since our module is associated with this phase, the LogHandler inside
 the module will now be executed in this phase.</p>
-
 <a name="Step5_:_Modify_the_&#34;services_xml&#34;"></a>
+
 <h4>Step5 : Modify the "services.xml"</h4>
 
-<p>Up to this point we have created the required classes and configuration
-descriptions for the logging module and by changing the "axis2.xml" we have
+<p>Up to this point, we have created the required classes and configuration
+descriptions for the logging module, and by changing the "axis2.xml" we
 created the required phases for the logging module.</p>
 
 <p>Next step is to "<b>engage</b>" (use) this module in one of our services.
 For this, let's use the same Web service that we have used throughout the
 user's guide- MyService. However, since we need to modify the "services.xml"
 of MyService in order to engage this module, we use a separate Web service,
-but with the similar operations.</p>
+but with similar operations.</p>
 
 <p>The code for this service can be found in the
 "<strong>Axis2_HOME/samples/userguide/src/userguide/example2</strong>"
 directory. The simple changes that we have done to "services.xml' are shown
 in green in the following lines of xml.</p>
+
 <p><pre>&lt;service name="<span style="color: rgb(36, 193, 19);">MyServiceWithModule</span>"&gt;
     &lt;description&gt;
     This is a sample Web service with a logging module engaged.
@@ -303,49 +311,52 @@
     &lt;/operation&gt;
 &lt;/service&gt;</pre></p>
 
-<p>In this example we have changed the service name (the implementation class
-is very similar to what we have used earlier although it is in a different
-package). In addition we have added the line <b>"&lt;module
+<p>In this example, we have changed the service name (the implementation
+class is very similar to what we have used earlier, although it is in a
+different package). In addition we have added the line <b>"&lt;module
 ref="logging"/&gt;"</b> to "services.xml". This informs the Axis2 engine that
 the module "logging" should be engaged for this service. The handler inside
 the module will be executed in their respective phases as described by the
 "module.xml".</p>
-
 <a name="Step6_:_Packaging"></a>
-<p><b>Step6 : Packaging</b></p>
 
-<p>Before deploying the module we need to create the ".mar" file for this
-module. This can be done, using the "jar" command and then renaming the
-created jar file. Or you can find the "logging.mar" that is already created
-for you in the "<strong>Axis2_HOME/samples/userguide</strong>" directory.</p>
+<h4>Step6 : Packaging</h4>
 
+<p>Before deploying the module, we need to create the ".mar" file for this
+module. This can be done, using the "jar" command and then renaming the
+created .jar file. Else, you can find the "logging.mar" that has already been
+created in the "<strong>Axis2_HOME/samples/userguide</strong>" directory.</p>
 <a name="Step7_:_Deploy_the_Module_in_Axis2"></a>
+
 <h4>Step7 : Deploy the Module in Axis2</h4>
 
-<p>Deploying a module in Axis2 require the user to create a directory with
+<p>Deploying a module in Axis2 requires the user to create a directory with
 the name "modules" in the "webapps/axis2/WEB-INF" directory of their servlet
-container and then copying the ".mar" file to that directory. So let's first
-create the "modules" directory and drop the "logging.mar" in to this
+container, and then copying the ".mar" file to that directory. So let's first
+create the "modules" directory and drop the "logging.mar" into this
 directory.</p>
 
 <p>Although the required changes to the "services.xml" is very little, we
 have created a separate service archive (MyServiceWithModule.aar) for users
-to deploy and see.</p>
+to deploy the service..</p>
 
-<p>Deploy this service using the same steps used in <a href="adv-userguide.html#Step5_Deploy_web_service">'Step 4: Deploy Web Service'</a> sub section in '<a href="userguide.html#ws_codegen">Writing a New Service using Codegeneration</a>', and copy the
-"logging.mar" file to the "modules" directory.</p>
-<p>Then run 'ant run.client.servicewithmodule' from <strong>axis2home/samples/userguide directory</strong></p>
+<p>Deploy this service using the same steps used in the <a
+href="adv-userguide.html#Step5_Deploy_web_service">'Step 4: Deploy Web
+Service'</a> sub section in '<a href="userguide.html#ws_codegen">Writing a
+New Service using Codegeneration</a>', and copy the "logging.mar" file to the
+"modules" directory.</p>
 
+<p>Then run 'ant run.client.servicewithmodule' from
+<strong>axis2home/samples/userguide directory</strong></p>
 
-<p>Note: To see logs, the user needs to modify the "log4j.properties" to log
-INFO. The property file is located in
+<p>Note: To see the logs, the user needs to modify the "log4j.properties" to
+log INFO. The property file is located in
 "<strong>webapps/axis2/WEB-INF/classes</strong>" of your servlet container.
 Change the line "log4j.rootCategory= ERROR, LOGFILE" to
 "log4j.rootCategory=INFO, ERROR, LOGFILE".</p>
 
-<p><font size="4"><b>Note (on samples):</b></font> All samples mentioned in
-the user's guide are located at <b>"samples\userguide\src"</b> directory of
-the binary distribution.</p>
-
+<p><font size="2"><b>Note (on samples):</b></font> All the samples mentioned
+in the user's guide are located at the <b>
+"samples\userguide\src"</b> directory of the binary distribution.</p>
 </body>
 </html>



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-cvs-help@ws.apache.org


Mime
View raw message