svn commit: r1683748 - /jmeter/trunk/xdocs/usermanual/component_reference.xml

[fs...@apache.org]

Author: fschumacher
Date: Fri Jun  5 13:28:10 2015
New Revision: 1683748

URL: http://svn.apache.org/r1683748
Log:
Markup changes. Usage of code-tags and definition lists.

Modified:
    jmeter/trunk/xdocs/usermanual/component_reference.xml

Modified: jmeter/trunk/xdocs/usermanual/component_reference.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/component_reference.xml?rev=1683748&r1=1683747&r2=1683748&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/component_reference.xml (original)
+++ jmeter/trunk/xdocs/usermanual/component_reference.xml Fri Jun  5 13:28:10 2015
@@ -1561,9 +1561,9 @@ The following table shows some values wh
     </description>
 <properties>
   <property name="Name" required="">Descriptive name for this element that is shown in the tree.</property>
-  <property name="use JNDI properties file" required="Yes">use jndi.properties. 
-  Note that the file must be on the classpath - e.g. by updating the user.classpath JMeter property.
-  If this option is not selected, JMeter uses the "JNDI Initial Context Factory" and "Provider URL" fields
+  <property name="use JNDI properties file" required="Yes">use <code>jndi.properties</code>. 
+  Note that the file must be on the classpath - e.g. by updating the <code>user.classpath</code> JMeter property.
+  If this option is not selected, JMeter uses the "<code>JNDI Initial Context Factory</code>" and "<code>Provider URL</code>" fields
   to create the connection.
   </property>
   <property name="JNDI Initial Context Factory" required="No">Name of the context factory</property>
@@ -1572,44 +1572,44 @@ The following table shows some values wh
   <property name="Durable Subscription ID" required="No">The ID to use for a durable subscription. On first 
   use the respective queue will automatically be generated by the JMS provider if it does not exist yet.</property>
   <property name="Client ID" required="No">The Client ID to use when you you use a durable subscription. 
-  Be sure to add a variable like ${__threadNum} when you have more than one Thread.</property>
+  Be sure to add a variable like <code>${__threadNum}</code> when you have more than one Thread.</property>
   <property name="JMS Selector" required="No">Message Selector as defined by JMS specification to extract only 
   messages that respect the Selector condition. Syntax uses subpart of SQL 92.</property>
-  <property name="Setup" required="Yes">The destination setup type. With At startup, the destination name is static (i.e. always same name during the test), with Each sample, the destination name is dynamic and is evaluate at each sample (i.e. the destination name may be a variable)</property>
+  <property name="Setup" required="Yes">The destination setup type. With <code>At startup</code>, the destination name is static (i.e. always same name during the test), with <code>Each sample</code>, the destination name is dynamic and is evaluate at each sample (i.e. the destination name may be a variable)</property>
   <property name="Authentication" required="Yes">Authentication requirement for the JMS provider</property>
   <property name="User" required="No">User Name</property>
   <property name="Password" required="No">Password (N.B. this is stored unencrypted in the test plan)</property>
   <property name="Number of samples to aggregate" required="Yes">number of samples to aggregate</property>
   <property name="Read response" required="Yes">should the sampler read the response. If not, only the response length is returned.</property>
-  <property name="Timeout" required="Yes">Specify the timeout to be applied, in milliseconds. 0=none. 
+  <property name="Timeout" required="Yes">Specify the timeout to be applied, in milliseconds. <code>0</code>=none. 
   This is the overall aggregate timeout, not per sample.</property>
   <property name="Client" required="Yes">Which client implementation to use.
   Both of them create connections which can read messages. However they use a different strategy, as described below:
-  <ul>
-  <li>MessageConsumer.receive() - calls receive() for every requested message. 
+  <dl>
+  <dt><code>MessageConsumer.receive()</code></dt><dd>calls <code>receive()</code> for every requested message. 
   Retains the connection between samples, but does not fetch messages unless the sampler is active.
   This is best suited to Queue subscriptions. 
-  </li>
-  <li>MessageListener.onMessage() - establishes a Listener that stores all incoming messages on a queue. 
+  </dd>
+  <dt><code>MessageListener.onMessage()</code></dt><dd>establishes a Listener that stores all incoming messages on a queue. 
   The listener remains active after the sampler completes.
-  This is best suited to Topic subscriptions.</li>
-  </ul>
+  This is best suited to Topic subscriptions.</dd>
+  </dl>
   </property>
   <property name="Stop between samples?" required="Yes">
-  If selected, then JMeter calls Connection.stop() at the end of each sample (and calls start() before each sample).
+  If selected, then JMeter calls <code>Connection.stop()</code> at the end of each sample (and calls <code>start()</code> before each sample).
   This may be useful in some cases where multiple samples/threads have connections to the same queue.
-  If not selected, JMeter calls Connection.start() at the start of the thread, and does not call stop() until the end of the thread.
+  If not selected, JMeter calls <code>Connection.start()</code> at the start of the thread, and does not call <code>stop()</code> until the end of the thread.
   </property>
   <property name="Separator" required="No">
   Separator used to separate messages when there is more than one (related to setting Number of samples to aggregate).
-  Note that \n, \r, \t are accepted.
+  Note that <code>\n</code>, <code>\r</code>, <code>\t</code> are accepted.
   </property>
 </properties>
-<p>
-<b>NOTE:</b> JMeter 2.3.4 and earlier used a different strategy for the MessageConsumer.receive() client. 
+<note>
+<b>NOTE:</b> JMeter 2.3.4 and earlier used a different strategy for the <code>MessageConsumer.receive()</code> client. 
 Previously this started a background thread which polled for messages. This thread continued when the sampler
-completed, so the net effect was similar to the MessageListener.onMessage() strategy.
-</p>
+completed, so the net effect was similar to the <code>MessageListener.onMessage()</code> strategy.
+</note>
 </component>
 
 <component name="JMS Point-to-Point" index="&sect-num;.1.15"  width="882" height="804" screenshot="jms/JMS_Point-to-Point.png">