Mailing-List: contact commits-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: svn commit: r1431334 - in
 /cxf/branches/2.7.x-fixes/distribution/src/main/release/samples:
 jaxws_dispatch_provider/README.txt ws_rm/README.txt
Date: Thu, 10 Jan 2013 13:14:59 -0000
To: commits@cxf.apache.org
From: coheigea@apache.org
Message-Id: <20130110131459.7173D23888EA@eris.apache.org>

Author: coheigea
Date: Thu Jan 10 13:14:59 2013
New Revision: 1431334

URL: http://svn.apache.org/viewvc?rev=1431334&view=rev
Log:
Merged revisions 1431315 via  git cherry-pick from
https://svn.apache.org/repos/asf/cxf/trunk

........
  r1431315 | coheigea | 2013-01-10 12:16:15 +0000 (Thu, 10 Jan 2013) | 2 lines

  Sample README cleanup

........

Modified:
    cxf/branches/2.7.x-fixes/distribution/src/main/release/samples/jaxws_dispatch_provider/README.txt
    cxf/branches/2.7.x-fixes/distribution/src/main/release/samples/ws_rm/README.txt

Modified: cxf/branches/2.7.x-fixes/distribution/src/main/release/samples/jaxws_dispatch_provider/README.txt
URL: http://svn.apache.org/viewvc/cxf/branches/2.7.x-fixes/distribution/src/main/release/samples/jaxws_dispatch_provider/README.txt?rev=1431334&r1=1431333&r2=1431334&view=diff
==============================================================================
--- cxf/branches/2.7.x-fixes/distribution/src/main/release/samples/jaxws_dispatch_provider/README.txt (original)
+++ cxf/branches/2.7.x-fixes/distribution/src/main/release/samples/jaxws_dispatch_provider/README.txt Thu Jan 10 13:14:59 2013
@@ -4,13 +4,12 @@ JAX-WS Dispatch/Provider Demo 
 The demo demonstrates the use of JAX-WS Dispatch and Provider interface.
 The client side Dispatch instance invokes upon an endpoint using a JAX-WS 
 Provider implementor. There are three different invocations from the client. 
-The first uses the SOAPMessage data in MESSAGE mode. The second uses the DOMSource 
-data in MESSAGE mode. The third uses the DOMSource in PAYLOAD mode. The three 
-different messages are constructed by reading in the XML files found in the 
-src/demo/hwDispatch/client directory.
+The first uses the SOAPMessage data in MESSAGE mode. The second uses the
+DOMSource data in MESSAGE mode. The third uses the DOMSource in PAYLOAD mode.
+The three different messages are constructed by reading in the XML files found
+in the src/demo/hwDispatch/client directory.
 
-Please review the README in the samples directory before
-continuing.
+Please review the README in the samples directory before continuing.
 
 Building and running the demo using Maven
 ---------------------------------------

Modified: cxf/branches/2.7.x-fixes/distribution/src/main/release/samples/ws_rm/README.txt
URL: http://svn.apache.org/viewvc/cxf/branches/2.7.x-fixes/distribution/src/main/release/samples/ws_rm/README.txt?rev=1431334&r1=1431333&r2=1431334&view=diff
==============================================================================
--- cxf/branches/2.7.x-fixes/distribution/src/main/release/samples/ws_rm/README.txt (original)
+++ cxf/branches/2.7.x-fixes/distribution/src/main/release/samples/ws_rm/README.txt Thu Jan 10 13:14:59 2013
@@ -4,44 +4,44 @@ WS-RM Demo
 This demo shows how WS-ReliableMessaging support in Apache CXF may be enabled.  
 
 The client and server both apply the reliableMessaging feature to the bus.
-This ensures installation of the WS-RM interceptors,
-comprising logical interceptors (RMInInterceptor/RMOutInterceptor)
-responsible for managing the reliability properties of the current message, and a
-protocol interceptor (RMSoapInterceptor) responsible for encoding/decoding
-these properties as SOAP Headers.
-
-As WS-RM is dependent on WS-Addressing, the demo uses 
-the same approach as the ws_addressing sample to enable this
-functionality. However, you may notice that the WS-Addressing
-namespace URI is different in this case (i.e.
+This ensures installation of the WS-RM interceptors, comprising logical
+interceptors (RMInInterceptor/RMOutInterceptor) responsible for managing the
+reliability properties of the current message, and a protocol interceptor
+(RMSoapInterceptor) responsible for encoding/decoding these properties as SOAP
+Headers.
+
+As WS-RM is dependent on WS-Addressing, the demo uses the same approach as the
+ws_addressing sample to enable this functionality. However, you may notice
+that the WS-Addressing namespace URI is different in this case (i.e.
 http://schemas.xmlsoap.org/ws/2004/08/addressing as opposed to
-http://www.w3.org/2005/08/addressing). This is because the WS-RM
-specification is still based on an older version of WS-Addressing.
+http://www.w3.org/2005/08/addressing). This is because the WS-RM specification
+is still based on an older version of WS-Addressing.
 
-The logging feature is used to log the inbound and outbound
-SOAP messages and display these to the console. Notice the usage of 
-out-of-band RM protocol messages (CreateSequence and CreateSequenceResponse)
-and the WS-RM headers in application-level messages (Sequence,
-SequenceAcknowledgement, AckRequested etc.)  
-
-Finally, the MessageLossSimulator interceptor is installed
-on the client-side to simulate message loss by discarding every second
-application level message. This simulated unreliability allows the retransmission
-of unacknowledged messages to be observed.
-
-This demo also illustrates usage of the decoupled HTTP transport, whereby
-a separate server->client HTTP connection is used to deliver responses
-to (application or RM protocol) requests and server side originated 
-standalone acknowledgments.
-The "partial response" referred to in the log output is the payload of
-the HTTP 202 Accepted response sent on the back-channel of the original 
+The logging feature is used to log the inbound and outbound SOAP messages and
+display these to the console. Notice the usage of out-of-band RM protocol
+messages (CreateSequence and CreateSequenceResponse) and the WS-RM headers in
+application-level messages (Sequence, SequenceAcknowledgement, AckRequested
+etc.)  
+
+Finally, the MessageLossSimulator interceptor is installed on the client-side
+to simulate message loss by discarding every second application level message.
+This simulated unreliability allows the retransmission of unacknowledged
+messages to be observed.
+
+This demo also illustrates usage of the decoupled HTTP transport, whereby a
+separate server->client HTTP connection is used to deliver responses to
+(application or RM protocol) requests and server side originated standalone
+acknowledgments.
+
+The "partial response" referred to in the log output is the payload of the
+HTTP 202 Accepted response sent on the back-channel of the original 
 client->server connection. 
 
 In all other respects this demo is based on the basic hello_world sample,
-illustrating that WS-Addressing usage is independent of the application.
-One notable addition to the familiar hello_world WSDL is the usage
-of the <wsaw:UsingAddressing> extension element to indicate the
-WS-Addressing support is enabled for the service endpoint.
+illustrating that WS-Addressing usage is independent of the application. One
+notable addition to the familiar hello_world WSDL is the usage of the
+<wsaw:UsingAddressing> extension element to indicate the WS-Addressing support
+is enabled for the service endpoint.
 
 Please review the README in the samples directory before continuing.