Axis2 User's Guide

Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 5483 invoked from network); 28 Sep 2006 11:09:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Sep 2006 11:09:08 -0000 Received: (qmail 40494 invoked by uid 500); 28 Sep 2006 11:09:06 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 40405 invoked by uid 500); 28 Sep 2006 11:09:06 -0000 Mailing-List: contact axis-cvs-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-cvs@ws.apache.org Received: (qmail 40394 invoked by uid 500); 28 Sep 2006 11:09:06 -0000 Delivered-To: apmail-ws-axis2-cvs@ws.apache.org Received: (qmail 40391 invoked by uid 99); 28 Sep 2006 11:09:06 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Sep 2006 04:09:06 -0700 X-ASF-Spam-Status: No, hits=-9.4 required=5.0 tests=ALL_TRUSTED,NO_REAL_NAME Received: from [140.211.166.113] ([140.211.166.113:57612] helo=eris.apache.org) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id 72/BF-05478-24DAB154 for ; Thu, 28 Sep 2006 04:08:50 -0700 Received: by eris.apache.org (Postfix, from userid 65534) id 2E29F1A981A; Thu, 28 Sep 2006 04:08:37 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r450805 - in /webservices/axis2/trunk/java/xdocs/1_1: userguide4.html userguide5.html Date: Thu, 28 Sep 2006 11:08:36 -0000 To: axis2-cvs@ws.apache.org From: chatra@apache.org X-Mailer: svnmailer-1.1.0 Message-Id: <20060928110837.2E29F1A981A@eris.apache.org> X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Author: chatra Date: Thu Sep 28 04:08:36 2006 New Revision: 450805 URL: http://svn.apache.org/viewvc?view=rev&rev=450805 Log: completed review. Thanks hasmin Modified: webservices/axis2/trunk/java/xdocs/1_1/userguide4.html webservices/axis2/trunk/java/xdocs/1_1/userguide5.html 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=450805&r1=450804&r2=450805 ============================================================================== --- webservices/axis2/trunk/java/xdocs/1_1/userguide4.html (original) +++ webservices/axis2/trunk/java/xdocs/1_1/userguide4.html Thu Sep 28 04:08:36 2006 @@ -1,326 +1,326 @@ - - - - - Axis2 User's Guide - - - -

Axis2 User's Guide

- -

User Feedback: axis-user@ws.apache.org. Prefix -subject with [Axis2]. To subscribe to mailing list see here.

- -

Pages: Content, 1, 2, 3, 4, 5

- -

Note (on samples): All samples mentioned in -the user's guide are located at "samples\userguide\src" directory of -the binary distribution.

- -

Modules

- -

Axis2 provides an extended support for modules (See Architecture Guide for -more details about modules in Axis2). Let's create a custom module and deploy -it to the MyService which we created earlier. Following steps show the -actions that need to be performed to deploy a custom module for a given Web -service:

Create the Module Implementation
-
Create the Handlers
-
Create the module.xml
-
Modify the "axis2.xml" (if you need - custom phases)
-
Modify the "services.xml" to engage - modules at the deployment time.
-
Package in a ".mar" (Module Archive)
-
Deploy the module in Axis2
-

- -

MyService with a Logging -Module

- -

Let's write a simple logging module for our sample. 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 that needs to be there in the ".mar" archive. Let's -create all these and see how it works.

- -

Step1 : LoggingModule Class

- -

LoggingModule is the implementation class of the Axis2 module. Axis2 -modules should implement the "org.apache.axis2.modules.Module" -interface with the following methods.

public void init(ConfigurationContext configContext, AxisModule module) throws AxisFault;//Initialize the module
-public void shutdown(AxisConfiguration axisSystem) throws AxisFault;//End of module processing
-public void engageNotify(AxisDescription axisDescription) throws AxisFault;

- -

These methods can be used to control the module initialization and the -termination. With the input parameter AxisConfiguration, 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.

- -

Step2 : LogHandler

- -

A module in Axis2 can contain, one or more handlers that perform various -SOAP header processing at different phases. (See Architecture Guide -for more information about phases). To write a handler one should implement -org.apache.axis2.engine.Handler. -But for convenience, org.apache.axis2.handlers.AbstractHandler -provides an abstract implementation of the Handler interface. 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.

public class LogHandler extends AbstractHandler implements Handler {
-    private Log log = LogFactory.getLog(getClass());
-    private QName name;
-
-    public QName getName() {
-        return name;
-    }
-
-    public void invoke(MessageContext msgContext) throws AxisFault {
-        log.info(msgContext.getEnvelope().toString());
-    }
-
-    public void setName(QName name) {
-        this.name = name;
-    }
-}

- -

Step3 : module.xml

- -

"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:

<module name="logging" class="userguide.loggingmodule.LoggingModule ">
-   <inflow>
-        <handler name="InFlowLogHandler" class="userguide.loggingmodule.LogHandler">
-        <order phase="loggingPhase" />
-        </handler>
-   </inflow>
-
-   <outflow>
-        <handler name="OutFlowLogHandler" class="userguide.loggingmodule.LogHandler">
-        <order phase="loggingPhase"/>
-        </handler>
-   </outflow>
-
-   <Outfaultflow>
-        <handler name="FaultOutFlowLogHandler" class="userguide.loggingmodule.LogHandler">
-        <order phase="loggingPhase"/>
-        </handler>
-   </Outfaultflow>
-
-   <INfaultflow>
-        <handler name="FaultInFlowLogHandler" class="userguide.loggingmodule.LogHandler">
-        <order phase="loggingPhase"/>
-        </handler>
-   </INfaultflow>
-</module>

- -

As it can be seen there are four flows defined in this "module.xml"

inflow - Represents the handler chain that will run when a message is - coming in.
outflow - Represents the handler chain - that will run when the message is going out.
-
Outfaultflow - Represents the handler - chain that will run when there is a fault and the fault is going out
-
INfaultflow - Represents the handler chain that will run when there - is a fault and the fault is coming in
-

- -

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. "<order -phase="loggingPhase" />" describes the phase in which this handler -runs.

<handler name="InFlowLogHandler" class="userguide.loggingmodule.LogHandler">
-<order phase="loggingPhase" />
-</handler>

- -

To learn more on Phase rules, click on here

- -

Step 4: Modify the -"axis2.xml"

- -

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 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 Axis2 engine. This is -an extract of the phase section of the "axis2.xml".

<!-- ================================================= -->
-<!-- Phases -->
-<!-- ================================================= -->
-
-<phaseOrder type="inflow">
-        <!--  System pre defined phases       -->
-        <phase name="TransportIn"/>
-        <phase name="PreDispatch"/>
-        <phase name="Dispatch" class="org.apache.axis2.engine.DispatchPhase">
-            <handler name="AddressingBasedDispatcher"
-                     class="org.apache.axis2.engine.AddressingBasedDispatcher">
-                <order phase="Dispatch"/>
-            </handler>
-
-            <handler name="RequestURIBasedDispatcher"
-                     class="org.apache.axis2.engine.RequestURIBasedDispatcher">
-                <order phase="Dispatch"/>
-            </handler>
-
-            <handler name="SOAPActionBasedDispatcher"
-                     class="org.apache.axis2.engine.SOAPActionBasedDispatcher">
-                <order phase="Dispatch"/>
-            </handler>
-
-            <handler name="SOAPMessageBodyBasedDispatcher"
-                     class="org.apache.axis2.engine.SOAPMessageBodyBasedDispatcher">
-                <order phase="Dispatch"/>
-            </handler>
-            <handler name="InstanceDispatcher"
-                     class="org.apache.axis2.engine.InstanceDispatcher">
-                <order phase="PostDispatch"/>
-            </handler>
-        </phase>
-        <!--  System pre defined phases       -->
-        <!--   After Postdispatch phase module author or service author can add any phase he wants      -->
-        <phase name="OperationInPhase"/>
-        <phase name="loggingPhase"/>
-    </phaseOrder>
-    <phaseOrder type="outflow">
-        <!--      user can add his own phases to this area  -->
-        <phase name="OperationOutPhase"/>
-        <phase name="loggingPhase"/>
-        <!--system predefined phases-->
-        <!--these phases will run irrespective of the service-->
-        <phase name="PolicyDetermination"/>
-        <phase name="MessageOut"/>
-    </phaseOrder/>
-    <phaseOrder type="INfaultflow">
-        <!--      user can add his own phases to this area  -->
-        <phase name="OperationInFaultPhase"/>
-        <phase name="loggingPhase"/>
-    </phaseOrder>
-    <phaseOrder type="Outfaultflow">
-        <!--      user can add his own phases to this area  -->
-        <phase name="OperationOutFaultPhase"/>
-        <phase name="loggingPhase"/>
-        <phase name="PolicyDetermination"/>
-        <phase name="MessageOut"/>
-    </phaseOrder>
-

- -

Shown in green, the custom phase "loggingPhase" is placed in all the -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 now will be executed in this phase.

- -

Step5 : Modify the -"services.xml"

- -

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 -created the required phases for the logging module. Next step is to -"engage" (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. The code for this service can be found in the -"Axis2Home/samples/userguide/src/userguide/example2" directory. The simple -changes that we have done to "services.xml' are shown in green in the -following lines of xml.

<service name="MyServiceWithModule">
-    <description>
-    This is a sample Web service with a logging module engaged.
-    </description>
-    <module ref="logging"/>
-    <parameter name="ServiceClass" locked="xsd:false">userguide.example2.MyService</parameter>
-    <operation name="echo">
-    <messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
-    </operation>
-    <operation name="ping">
-    <messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
-    </operation>
-</service>

- -

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 "<module -ref="logging"/>" 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".

- -

Step6 : Packaging

- -

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 "Axis2Home/samples/userguide" directory.

- -

Step7 : Deploy the Module in -Axis2

- -

Deploying a module in Axis2 require 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 -directory.

- -

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. Deploy this service using the same steps that you used -to deploy "MyService" and copy the "logging.mar" file to the "modules" -directory. Then run using the "TestWebServiceWithModuleClient.bat" or -"TestWebServiceWithModuleClient.sh" in the -"Axis2Home/samples/userguide/src/userguide/clients/bin" directory.

- -

Note: To see the logs, the user needs to modify the "log4j.properties" to -log INFO. The property file is located in "webapps\axis2\WEB-INF\classes" of -your servlet container. Change the line "log4j.rootCategory= ERROR, LOGFILE" -to "log4j.rootCategory=INFO, ERROR, LOGFILE".

- -

-Previous | Next

- -

Pages: Content, 1, 2, 3, 4, 5

- - + + + + + Axis2 User's Guide + + + +

Axis2 User's Guide

+ +

User Feedback: axis-user@ws.apache.org. Prefix +subject with [Axis2]. To subscribe to mailing list see here.

+ +

Pages: Content, 1, 2, 3, 4, 5

+ +

Note (on samples): All samples mentioned in +the user's guide are located at "samples\userguide\src" directory of +the binary distribution.

+ +

Modules

+ +

Axis2 provides extended support for modules (See Architecture Guide for +more details about modules in Axis2). Let's create a custom module and deploy +it to MyService which we created earlier. Following steps show the actions +that need to be performed to deploy a custom module for a given Web +service:

Create the Module Implementation
+
Create the Handlers
+
Create the module.xml
+
Modify the "axis2.xml" (if you need + custom phases)
+
Modify the "services.xml" to engage + modules at the deployment time.
+
Package in a ".mar" (Module Archive)
+
Deploy the module in Axis2
+

+ +

MyService with a Logging +Module

+ +

Let's write a simple logging module for our sample. 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.

+ +

Step1 : LoggingModule Class

+ +

LoggingModule is the implementation class of the Axis2 module. Axis2 +modules should implement the "org.apache.axis2.modules.Module" +interface with the following methods.

public void init(ConfigurationContext configContext, AxisModule module) throws AxisFault;//Initialize the module
+public void shutdown(AxisConfiguration axisSystem) throws AxisFault;//End of module processing
+public void engageNotify(AxisDescription axisDescription) throws AxisFault;

+ +

These methods can be used to control the module initialization and the +termination. 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.

+ +

Step2 : LogHandler

+ +

A module in Axis2 can contain, one or more handlers that perform various +SOAP header processing at different phases. (See Architecture Guide +for more information about phases). To write a handler one should implement +org.apache.axis2.engine.Handler. +But for convenience, org.apache.axis2.handlers.AbstractHandler +provides an abstract implementation of the Handler interface. 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.

public class LogHandler extends AbstractHandler implements Handler {
+    private Log log = LogFactory.getLog(getClass());
+    private QName name;
+
+    public QName getName() {
+        return name;
+    }
+
+    public void invoke(MessageContext msgContext) throws AxisFault {
+        log.info(msgContext.getEnvelope().toString());
+    }
+
+    public void setName(QName name) {
+        this.name = name;
+    }
+}

+ +

Step3 : module.xml

+ +

"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:

<module name="logging" class="userguide.loggingmodule.LoggingModule ">
+   <inflow>
+        <handler name="InFlowLogHandler" class="userguide.loggingmodule.LogHandler">
+        <order phase="loggingPhase" />
+        </handler>
+   </inflow>
+
+   <outflow>
+        <handler name="OutFlowLogHandler" class="userguide.loggingmodule.LogHandler">
+        <order phase="loggingPhase"/>
+        </handler>
+   </outflow>
+
+   <Outfaultflow>
+        <handler name="FaultOutFlowLogHandler" class="userguide.loggingmodule.LogHandler">
+        <order phase="loggingPhase"/>
+        </handler>
+   </Outfaultflow>
+
+   <INfaultflow>
+        <handler name="FaultInFlowLogHandler" class="userguide.loggingmodule.LogHandler">
+        <order phase="loggingPhase"/>
+        </handler>
+   </INfaultflow>
+</module>

+ +

As you can see there are four flows defined in this "module.xml"

inflow - Represents the handler chain that will run when a message is + coming in.
outflow - Represents the handler chain + that will run when the message is going out.
+
Outfaultflow - Represents the handler + chain that will run when there is a fault and the fault is going out
+
INfaultflow - Represents the handler chain that will run when there + is a fault and the fault is coming in
+

+ +

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. "<order +phase="loggingPhase" />" describes the phase in which this handler +runs.

<handler name="InFlowLogHandler" class="userguide.loggingmodule.LogHandler">
+<order phase="loggingPhase" />
+</handler>

+ +

To learn more about Phase rules, see here

+ +

Step 4: Modify the +"axis2.xml"

+ +

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".

<!-- ================================================= -->
+<!-- Phases -->
+<!-- ================================================= -->
+
+<phaseOrder type="inflow">
+        <!--  System pre defined phases       -->
+        <phase name="TransportIn"/>
+        <phase name="PreDispatch"/>
+        <phase name="Dispatch" class="org.apache.axis2.engine.DispatchPhase">
+            <handler name="AddressingBasedDispatcher"
+                     class="org.apache.axis2.engine.AddressingBasedDispatcher">
+                <order phase="Dispatch"/>
+            </handler>
+
+            <handler name="RequestURIBasedDispatcher"
+                     class="org.apache.axis2.engine.RequestURIBasedDispatcher">
+                <order phase="Dispatch"/>
+            </handler>
+
+            <handler name="SOAPActionBasedDispatcher"
+                     class="org.apache.axis2.engine.SOAPActionBasedDispatcher">
+                <order phase="Dispatch"/>
+            </handler>
+
+            <handler name="SOAPMessageBodyBasedDispatcher"
+                     class="org.apache.axis2.engine.SOAPMessageBodyBasedDispatcher">
+                <order phase="Dispatch"/>
+            </handler>
+            <handler name="InstanceDispatcher"
+                     class="org.apache.axis2.engine.InstanceDispatcher">
+                <order phase="PostDispatch"/>
+            </handler>
+        </phase>
+        <!--  System pre defined phases       -->
+        <!--   After Postdispatch phase module author or service author can add any phase he wants      -->
+        <phase name="OperationInPhase"/>
+        <phase name="loggingPhase"/>
+    </phaseOrder>
+    <phaseOrder type="outflow">
+        <!--      user can add his own phases to this area  -->
+        <phase name="OperationOutPhase"/>
+        <phase name="loggingPhase"/>
+        <!--system predefined phases-->
+        <!--these phases will run irrespective of the service-->
+        <phase name="PolicyDetermination"/>
+        <phase name="MessageOut"/>
+    </phaseOrder/>
+    <phaseOrder type="INfaultflow">
+        <!--      user can add his own phases to this area  -->
+        <phase name="OperationInFaultPhase"/>
+        <phase name="loggingPhase"/>
+    </phaseOrder>
+    <phaseOrder type="Outfaultflow">
+        <!--      user can add his own phases to this area  -->
+        <phase name="OperationOutFaultPhase"/>
+        <phase name="loggingPhase"/>
+        <phase name="PolicyDetermination"/>
+        <phase name="MessageOut"/>
+    </phaseOrder>
+

+ +

Shown in green, the custom phase "loggingPhase" is placed in all the +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.

+ +

Step5 : Modify the +"services.xml"

+ +

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 +created the required phases for the logging module. Next step is to +"engage" (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. The code for this service can be found in the +"Axis2Home/samples/userguide/src/userguide/example2" directory. The simple +changes that we have done to "services.xml' are shown in green in the +following lines of xml.

<service name="MyServiceWithModule">
+    <description>
+    This is a sample Web service with a logging module engaged.
+    </description>
+    <module ref="logging"/>
+    <parameter name="ServiceClass" locked="xsd:false">userguide.example2.MyService</parameter>
+    <operation name="echo">
+    <messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
+    </operation>
+    <operation name="ping">
+    <messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
+    </operation>
+</service>

+ +

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 "<module +ref="logging"/>" 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".

+ +

Step6 : Packaging

+ +

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 "Axis2Home/samples/userguide" directory.

+ +

Step7 : Deploy the Module in +Axis2

+ +

Deploying a module in Axis2 require 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 +directory.

+ +

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. Deploy this service using the same steps that you used +to deploy "MyService" and copy the "logging.mar" file to the "modules" +directory. Then run using the "TestWebServiceWithModuleClient.bat" or +"TestWebServiceWithModuleClient.sh" in the +"Axis2Home/samples/userguide/src/userguide/clients/bin" directory.

+ +

Note: To see logs, the user needs to modify the "log4j.properties" to log +INFO. The property file is located in "webapps\axis2\WEB-INF\classes" of your +servlet container. Change the line "log4j.rootCategory= ERROR, LOGFILE" to +"log4j.rootCategory=INFO, ERROR, LOGFILE".

+ +

+Previous | Next

+ +

Pages: Content, 1, 2, 3, 4, 5

+ + 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=450805&r1=450804&r2=450805 ============================================================================== --- webservices/axis2/trunk/java/xdocs/1_1/userguide5.html (original) +++ webservices/axis2/trunk/java/xdocs/1_1/userguide5.html Thu Sep 28 04:08:36 2006 @@ -1,85 +1,84 @@ - - - - - Axis2 User's Guide - - - -

Axis2 User's Guide

- -

User Feedback: axis-user@ws.apache.org. Prefix -subject with [Axis2]. To subscribe to mailing list see here.

- -

Pages: Content, 1, 2, 3, 4, 5

- -

Note (on samples): All samples mentioned in -the user's guide are located at "samples\userguide\src" directory of -the binary distribution.

- -

Other Samples

- -

To show the power of usage of Axis2, three standard samples are shipped -with the binary distribution. These are meant to interact with outside Web -services and prove the capabilities of the Axis2 system.

- -

The included samples are

Google spell checker sample
Google search sample
-
Amazon queuing sample
-

- -

A simple introduction to each of the above samples are given below. Each -sample contains it's own help document that speaks about the usage and the -advanced operations of that particular sample.

- -

The most obvious place to look for the samples are the binary -distribution. All these samples are included in the samples directory in the -binary distribution. The shell scripts and the batch files are in fact -written to use the binary distribution's root directory as the home in order -to find the libraries.

- -

The alternate method is to build the samples from source. Moving to the -modules/samples and running maven will create the samples in the -target/samples directory. However if the samples need to be started using the -shell scripts (or the batch files) then the AXIS2_HOME environment need to be -set.( the "guessed" AXIS2_HOME would not be correct in this case)

- -

Google Spell Checker Sample

- -

This includes a spell checker program that uses the Google spell checking -service. It demonstrates the blocking and non-blocking modes of calling the -service. This sample can be found at the samples\googleSpellcheck directory -of the dist and can be easily started using either the batch file or the -shell script.

- -

Google Search Sample

- -

This includes a search program that uses the familiar Google search over -the SOAP API. It utilizes the non-blocking mode of the client API. This -sample can be found at the samples\googleSearch directory of the dist and can -be easily started using either the batch file or the shell script.

- -

Amazon Queuing Service

- -

Amazon queuing service sample shows how to use the Amazon queuing service. -It has two user interfaces , one to enqueue and the other to dequeue. This -sample is included in the samples\amazonQS directory of the dist with the -required batch/shell scripts to run the sample.

- -

-Previous Page

- -

Pages: Content, 1, 2, 3, 4, 5

- - + + + + + Axis2 User's Guide + + + +

Axis2 User's Guide

+ +

User Feedback: axis-user@ws.apache.org. Prefix +subject with [Axis2]. To subscribe to mailing list see here.

+ +

Pages: Content, 1, 2, 3, 4, 5

+ +

Note (on samples): All samples mentioned in +the user's guide are located at "samples\userguide\src" directory of +the binary distribution.

+ +

Other Samples

+ +

To show you the power of using Axis2, three standard samples are shipped +with the binary distribution. These are meant to interact with external Web +services and prove the capabilities of the Axis2 system.

+ +

The samples included are

Google spell checker sample
Google search sample
+
Amazon queuing sample
+

+ +

A simple introduction to each of the above samples are given below. Each +sample contains it's own help document that talks about the usage and the +advanced operations of that particular sample.

+ +

All of the above samples are included in the samples directory in the +binary distribution. The shell scripts and the batch files are in fact +written to use the binary distribution's root directory as the home in order +to find the libraries.

+ +

The alternate method is to build the samples from the source. Moving them +to modules/samples and running maven will create the samples in the +target/samples directory. However if the samples need to be started using the +shell scripts (or the batch files) then the AXIS2_HOME environment needs to +be set.( the "guessed" AXIS2_HOME would not be correct in this case)

+ +

Google Spell Checker Sample

+ +

This includes a spell checker program that uses the Google spell checking +service. It demonstrates the blocking and non-blocking modes of calling the +service. This sample can be found at the samples\googleSpellcheck directory +of the dist and can be easily started using either the batch file or the +shell script.

+ +

Google Search Sample

+ +

This includes a search program that uses the familiar Google search over +the SOAP API. It utilizes the non-blocking mode of the client API. This +sample can be found at the samples\googleSearch directory of the dist and can +be easily started using either the batch file or the shell script.

+ +

Amazon Queuing Service

+ +

Amazon queuing service sample shows how to use the Amazon queuing service. +It has two user interfaces , one to enqueue and the other to dequeue. This +sample is included in the samples\amazonQS directory of the dist with the +required batch/shell scripts to run the sample.

+ +

+Previous Page

+ +

Pages: Content, 1, 2, 3, 4, 5

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