axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Repp <Ja...@Ingeniux.com>
Subject Patch for user-guide.html
Date Wed, 12 Dec 2001 23:11:16 GMT
Changed all references to Wsdl2Java to WSDL2Java to match latest changes.

Index: user-guide.html
===================================================================
RCS file: /home/cvspublic/xml-axis/java/docs/user-guide.html,v
retrieving revision 1.28
diff -u -r1.28 user-guide.html
--- user-guide.html	2001/12/04 19:47:54	1.28
+++ user-guide.html	2001/12/12 23:08:56
@@ -90,7 +90,7 @@
   <li>Automatic two-way conversions between Java "List" collections and
SOAP Arrays 
   <li>Providers for RPC and message based SOAP services 
   <li>Automatic WSDL generation from deployed services
-  <li>Wsdl2java tool for building Java proxies and skeletons from WSDL
documents
+  <li>WSDL2Java tool for building Java proxies and skeletons from WSDL
documents
   <li>Preliminary security extensions, which can integrate with Servlet 2.2
security/roles
   <li>An EJB provider for accessing EJB's as Web Services
   <li>HTTP servlet-based transport 
@@ -120,7 +120,7 @@
 <h3>Handlers and the Message Path in Axis</h3>
 <p>Put simply, Axis is all about processing Messages. When the central Axis
processing 
   logic runs, a series of <b>Handlers</b> are each invoked in order. The
particular 
-  oder is determined by two factors - deployment configuration and whether
the 
+  order is determined by two factors - deployment configuration and whether
the 
   engine is a client or a server. The object which is passed to each
Handler invocation 
   is a <b>MessageContext</b>. A MessageContext is a structure which
contains several 
   important parts: 1) a &quot;request&quot; message, 2) a
&quot;response&quot; 
@@ -563,7 +563,7 @@
 <p>Axis supports WSDL in two ways: first, when you deploy a service in
Axis, users 
   may then access your service's URL with a standard web browser and by
appending 
   &quot;?WSDL&quot; to the end of the URL, they will obtain an
automatically-generated 
-  WSDL document which describes your service. Second, we provide a
&quot;Wsdl2java&quot; 
+  WSDL document which describes your service. Second, we provide a
&quot;WSDL2Java&quot; 
   tool which will build Java proxies and skeletons for services with WSDL
descriptions. 
   Both of these techniques are explained in more detail below.</p>
 <h3>WSDL generation for deployed services</h3>
@@ -579,11 +579,11 @@
   the WSDL-generation URL to your online partners, and they'll be able to
use 
   it to access your service with toolkits like .NET, SOAP::Lite, or any
other 
   software which supports using WSDL.</p>
-<h3>Building stubs and skeletons with Wsdl2java</h3>
-<p>You'll find the Axis WSDL -&gt; Java tool in
&quot;org.apache.axis.wsdl.Wsdl2java&quot;. 
+<h3>Building stubs and skeletons with WSDL2Java</h3>
+<p>You'll find the Axis WSDL -&gt; Java tool in
&quot;org.apache.axis.wsdl.WSDL2Java&quot;. 
   The basic invocation form looks like this:</p>
 <div class="example">
-  <pre>% java org.apache.axis.wsdl.Wsdl2java <i>(url-to-wsdl-file)</i>
+  <pre>% java org.apache.axis.wsdl.WSDL2Java <i>(url-to-wsdl-file)</i>
 </pre>
 </div>
 <h4>Stubs - making Web Service access transparent from the client side</h4>
@@ -597,11 +597,11 @@
 <p>You can try an example, assuming you've deployed the service in <a
href="#descriptors">example 
   3</a> above and have your Axis server up and running. Type the following
at 
   the command line:</p>
-<pre>% java org.apache.axis.wsdl.Wsdl2java
http://localhost:8080/axis/services/MyService?wsdl</pre>
+<pre>% java org.apache.axis.wsdl.WSDL2Java
http://localhost:8080/axis/services/MyService?wsdl</pre>
 <p>You can add the &quot;--verbose&quot; option right before the URL if you
want 
   some more feedback on what the tool is up to. This will generate stub
code, 
   which we'll describe.</p>
-<p>Wsdl2java generates a few classes; here's a rundown of what they are and
how 
+<p>WSDL2Java generates a few classes; here's a rundown of what they are and
how 
   to use them:</p>
 <ul>
   <li>There will be an interface for each referenced PortType in the WSDL.
These 
@@ -643,9 +643,9 @@
   you might want to join a digital marketplace which requires you to make
your 
   inventory available via a particular Web Service interface.</p>
 <p>To make skeleton classes, you just specify the &quot;--skeleton&quot;
option 
-  to Wsdl2java. For instance, if we wanted to replicate the service in the
last 
+  to WSDL2Java. For instance, if we wanted to replicate the service in the
last 
   example, we'd type:</p>
-<pre>% java org.apache.axis.wsdl.Wsdl2java --skeleton
http://localhost:8080/axis/services/MyService?wsdl</pre>
+<pre>% java org.apache.axis.wsdl.WSDL2Java --skeleton
http://localhost:8080/axis/services/MyService?wsdl</pre>
 <p>There are a couple of classes produced by the skeleton generator, so
let's 
   take a look at them:</p>
 <ul>
@@ -664,21 +664,21 @@
 <p>WSDL files can contain (or reference) XML Schema describing the data
types 
   used by particular operations. As we've seen, Axis needs to do some work
to 
   map schema types to Java types, and this remains true whether we code the
Java 
-  by hand or generate it with a tool. When you use Wsdl2java to generate
either 
+  by hand or generate it with a tool. When you use WSDL2Java to generate
either 
   stubs or skeletons for operations which contain complex types, you will
notice 
   that Java classes corresponding to the XML data types are also generated.
For 
   the stub, the code inside the stub handles setting up the type mapping in
Axis 
   - and for the skeleton, the type mappings are included in the generated
&quot;deploy.wsdd&quot; 
   file. </p>
 <h5>Holders</h5>
-<p>You'll notice that for each data class that Wsdl2java generates, there
is a 
+<p>You'll notice that for each data class that WSDL2Java generates, there
is a 
   corresponding &quot;Holder&quot; class - for instance a class called
&quot;MyDataType&quot; 
   would also get a companion class &quot;MyDataTypeHolder&quot;. These
classes 
   exist so that we have a reasonably clean mapping for WSDL's in/out and
out parameters 
   in Java. See the examples for more details.</p>
-<h4>Wsdl2java details</h4>
-Wsdl2java has a number of options, some of which have already been
detailed.
-<p>Usage:&nbsp; java org.apache.axis.wsdl.Wsdl2java [options] WSDL-URI
+<h4>WSDL2Java details</h4>
+WSDL2Java has a number of options, some of which have already been
detailed.
+<p>Usage:&nbsp; java org.apache.axis.wsdl.WSDL2Java [options] WSDL-URI
 <br>Options:
 <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -h, --help
 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;
@@ -735,11 +735,11 @@
 namespace mapping.&nbsp; For example, if there is a namespace in the WSDL
 document called "urn:AddressFetcher2", and you want files generated from
 the objects within this namespace to reside in the package samples.addr,
-you would provide the following option to Wsdl2java:
+you would provide the following option to WSDL2Java:
 <pre>--NStoPkg urn:AddressFetcher2=samples.addr</pre>
 If there are a number of namespaces in the WSDL document, listing a mapping
 for them all could become tedious.&nbsp; To help keep the command line
-terse, Wsdl2java will also look for mappings in a file called
NStoPkg.properties
+terse, WSDL2Java will also look for mappings in a file called
NStoPkg.properties
 residing in the default package (ie., no package).&nbsp; The entries in
 this file are of the same form as the arguments to the --NStoPkg command
 line option.&nbsp; For example, instead of providing the command line
option

Mime
View raw message