You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cxf.apache.org by bu...@apache.org on 2012/12/19 16:48:02 UTC

svn commit: r843093 - in /websites/production/cxf/content: cache/docs.pageCache docs/developing-a-consumer.html

Author: buildbot
Date: Wed Dec 19 15:48:02 2012
New Revision: 843093

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/developing-a-consumer.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/developing-a-consumer.html
==============================================================================
--- websites/production/cxf/content/docs/developing-a-consumer.html (original)
+++ websites/production/cxf/content/docs/developing-a-consumer.html Wed Dec 19 15:48:02 2012
@@ -367,7 +367,7 @@ asynchronous invocation model.</li></ul>
 
 <p>The <tt>ServiceName</tt> class defines the following methods:</p>
 <ul><li>Constructor methods - the following forms of constructor are defined:
-	<ul><li><tt><em>ServiceName</em>(URL <em>wsdlLocation</em>, QName <em>serviceName</em>)</tt> constructs a service object based on the data in the <em>serviceName</em> service in the WSDL contract that is obtainable from <em>wsdlLocation</em>.</li><li><tt><em>ServiceName</em>()</tt> is the default constructor, which constructs a service object based on the service name and WSDL contract that were provided at the time the stub code was generated (for example, when running the CeltiXfire wsdl2java command). Using this constructor presupposes that the WSDL contract remains available at its original location.</li></ul>
+	<ul><li><tt><em>ServiceName</em>(URL <em>wsdlLocation</em>, QName <em>serviceName</em>)</tt> constructs a service object based on the data in the <em>serviceName</em> service in the WSDL contract that is obtainable from <em>wsdlLocation</em>.</li><li><tt><em>ServiceName</em>()</tt> is the default constructor, which constructs a service object based on the service name and WSDL contract that were provided at the time the stub code was generated (for example, when running the CXF wsdl2java command). Using this constructor presupposes that the WSDL contract remains available at its original location.</li></ul>
 	</li><li><tt>get_PortName_()</tt> methods - for every <em>PortName</em> port defined on the <em>ServiceName</em> service, CXF generates a corresponding <tt>get_PortName_()</tt> method in Java. Therefore, a <tt>wsdl:service</tt> element that defines multiple ports will generate a service class with multiple <tt>get_PortName_()</tt> methods.</li></ul>
 
 
@@ -475,7 +475,7 @@ asynchronous invocation model.</li></ul>
 }
 </pre>
 </div></div>
-<p>The <tt>Client.main()</tt> function proceeds as follows:&lt;/para&gt;</p>
+<p>The <tt>Client.main()</tt> function proceeds as follows:</p>
 <ol><li>The CXF runtime is implicitly initialized - that is, provided the CXF runtime classes are loaded. Hence, there is no need to call a special function in order to initialize CXF.</li><li>The client expects a single string argument that gives the location of the WSDL contract for HelloWorld. The WSDL location is stored in <tt>wsdlURL</tt>.</li><li>A new port object (which enables you to access the remote server endpoint) is created in two steps, as shown in the following code fragment:
 <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
 <pre class="code-java">SOAPService ss = <span class="code-keyword">new</span> SOAPService(wsdlURL, SERVICE_NAME);
@@ -488,7 +488,7 @@ Greeter port = ss.getSoapPort();</pre>
 
 <p>You can use JAX-WS contexts to customize the properties of a client proxy. In particular, contexts can be used to modify connection properties and to send data in protocol headers. For example, you could use contexts to add a SOAP header, either to a request message or to a response message. The following types of context are supported on the client side:</p>
 
-<ul><li><b>Request context</b> - on the client side, the request context enables you to set properties that affect outbound messages. Request context properties are applied to a specific port instance and, once set, the properties affect every subsequent operation invocation made on the port, until such time as a property is explicitly cleared. For example, you might use a request context  property to set a connection timeout or to initialize data for sending in a header.&lt;/para&gt;</li><li><b>Response context</b> - on the client side, you can access the response context to read the property values set by the inbound message from the last operation invocation. Response context properties are reset after every operation invocation. For example, you might access a response context property to read header information received from the last inbound message.</li></ul>
+<ul><li><b>Request context</b> - on the client side, the request context enables you to set properties that affect outbound messages. Request context properties are applied to a specific port instance and, once set, the properties affect every subsequent operation invocation made on the port, until such time as a property is explicitly cleared. For example, you might use a request context  property to set a connection timeout or to initialize data for sending in a header.</li><li><b>Response context</b> - on the client side, you can access the response context to read the property values set by the inbound message from the last operation invocation. Response context properties are reset after every operation invocation. For example, you might access a response context property to read header information received from the last inbound message.</li></ul>
 
 
 <h4><a shape="rect" name="DevelopingaConsumer-Settingarequestcontext"></a>Setting a request context</h4>
@@ -639,7 +639,7 @@ PropertyType propValue = (PropertyType) 
 </pre>
 </div></div>
 
-<p>&lt;para&gt;Where <em>AffectedWSDLContract</em> specifies the URL of the WSDL contract that is affected by this binding declaration. The <em>AffectedNode</em> is an XPath value that specifies which node (or nodes) from the WSDL contract are affected by this binding declaration. You can set <em>AffectedNode</em> to <tt>wsdl:definitions</tt>, if you want the entire WSDL contract to be affected. The {jaxws:enableAsyncMapping}} element is set to <tt>true</tt> to enable the asynchronous invocation feature.</p>
+<p>Where <em>AffectedWSDLContract</em> specifies the URL of the WSDL contract that is affected by this binding declaration. The <em>AffectedNode</em> is an XPath value that specifies which node (or nodes) from the WSDL contract are affected by this binding declaration. You can set <em>AffectedNode</em> to <tt>wsdl:definitions</tt>, if you want the entire WSDL contract to be affected. The {jaxws:enableAsyncMapping}} element is set to <tt>true</tt> to enable the asynchronous invocation feature.</p>
 
 <p>For example, if you want to generate asynchronous methods only for the <tt>GreeterAsync</tt> port type, you could specify <tt>&lt;bindings node="wsdl:definitions/wsdl:portType<span class="error">[@name='GreeterAsync']</span>"&gt;</tt> in the preceding binding declaration.</p>