svn commit: r1664721 - in /jmeter/trunk/xdocs: nightly.xml usermanual/component_reference.xml

[fs...@apache.org]

Author: fschumacher
Date: Fri Mar  6 21:07:14 2015
New Revision: 1664721

URL: http://svn.apache.org/r1664721
Log:
Small markup cleanup in docs.

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

Modified: jmeter/trunk/xdocs/nightly.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/nightly.xml?rev=1664721&r1=1664720&r2=1664721&view=diff
==============================================================================
--- jmeter/trunk/xdocs/nightly.xml (original)
+++ jmeter/trunk/xdocs/nightly.xml Fri Mar  6 21:07:14 2015
@@ -32,9 +32,7 @@
     <br/>
     They are intended for use by developers and others wishing to help with resolving JMeter bugs.
     </p>
-    <p>
-    <span style="font-size : x-large"><b>These builds should not be used in production.</b></span>
-    </p>
+    <note><b>These builds should not be used in production.</b></note>
     <h2>Where are the nightly builds?</h2>
     <p>JMeter CI builds are currently run by Jenkins and Buildbot</p>
     <p>These are located at:
@@ -70,11 +68,11 @@ Unpack all the archives into the <b>same
 </p>
 
 <h2>Warning - please note!</h2>
-<p>
+<note>
     <span style="font-size : large">
     <b>The nightly builds may or may not work properly - or at all.</b>
     </span>
-</p>
+</note>
 <p>
     If there is a problem with a particular version, 
     it may be worth reporting this on the JMeter-dev mailing list and/or trying again in a day or two.

Modified: jmeter/trunk/xdocs/usermanual/component_reference.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/component_reference.xml?rev=1664721&r1=1664720&r2=1664721&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/component_reference.xml (original)
+++ jmeter/trunk/xdocs/usermanual/component_reference.xml Fri Mar  6 21:07:14 2015
@@ -1021,17 +1021,15 @@ are two interfaces you have to implement
 HTTPSampler. The servername, port and get images are set by AccessLogSampler. Next,
 the parser is called with integer 1, telling it to parse one entry. After that,
 HTTPSampler.sample() is called to make the request.
-<code>
-<pre>
-            samp = (HTTPSampler) GENERATOR.generateRequest();
-            samp.setDomain(this.getDomain());
-            samp.setPort(this.getPort());
-            samp.setImageParser(this.isImageParser());
-            PARSER.parse(1);
-            res = samp.sample();
-            res.setSampleLabel(samp.toString());
-</pre>
-</code>
+<source>
+samp = (HTTPSampler) GENERATOR.generateRequest();
+samp.setDomain(this.getDomain());
+samp.setPort(this.getPort());
+samp.setImageParser(this.isImageParser());
+PARSER.parse(1);
+res = samp.sample();
+res.setSampleLabel(samp.toString());
+</source>
 The required methods in LogParser are:
 <ul>
 <li>setGenerator(Generator)</li>
@@ -1687,42 +1685,51 @@ completed, so the net effect was similar
 The current implementation supports standard Junit convention and extensions. It also
 includes extensions like oneTimeSetUp and oneTimeTearDown. The sampler works like the
 JavaSampler with some differences.
-<br></br>1. rather than use Jmeter's test interface, it scans the jar files for classes extending junit's TestCase class. That includes any class or subclass.
-<br></br>2. Junit test jar files should be placed in jmeter/lib/junit instead of /lib directory.
-In versions of JMeter after 2.3.1, you can also use the "user.classpath" property to specify where to look for TestCase classes. 
-<br></br>3. Junit sampler does not use name/value pairs for configuration like the JavaSampler. The sampler assumes setUp and tearDown will configure the test correctly.
-<br></br>4. The sampler measures the elapsed time only for the test method and does not include setUp and tearDown.
-<br></br>5. Each time the test method is called, Jmeter will pass the result to the listeners.
-<br></br>6. Support for oneTimeSetUp and oneTimeTearDown is done as a method. Since Jmeter is multi-threaded, we cannot call oneTimeSetUp/oneTimeTearDown the same way Maven does it.
-<br></br>7. The sampler reports unexpected exceptions as errors.
+<ul>
+<li>rather than use Jmeter's test interface, it scans the jar files for classes extending junit's TestCase class. That includes any class or subclass.</li>
+<li>Junit test jar files should be placed in jmeter/lib/junit instead of /lib directory.
+In versions of JMeter after 2.3.1, you can also use the "user.classpath" property to specify where to look for TestCase classes.</li>
+<li>Junit sampler does not use name/value pairs for configuration like the JavaSampler. The sampler assumes setUp and tearDown will configure the test correctly.</li>
+<li>The sampler measures the elapsed time only for the test method and does not include setUp and tearDown.</li>
+<li>Each time the test method is called, Jmeter will pass the result to the listeners.</li>
+<li>Support for oneTimeSetUp and oneTimeTearDown is done as a method. Since Jmeter is multi-threaded, we cannot call oneTimeSetUp/oneTimeTearDown the same way Maven does it.</li>
+<li>The sampler reports unexpected exceptions as errors.
 There are some important differences between standard JUnit test runners and JMeter's
 implementation. Rather than make a new instance of the class for each test, JMeter
 creates 1 instance per sampler and reuses it.
-This can be changed with checkbox "Create a new instance per sample".<br></br>
-The current implementation of the sampler will try to create an instance using the string constructor first. If the test class does not declare a string constructor, the sampler will look for an empty constructor. Example below:&lt;br>
-&lt;br>
-Empty Constructor:&lt;br>
-public class myTestCase {&lt;br>
-  public myTestCase() {}&lt;br>
-}&lt;br>
-&lt;br>
-String Constructor:&lt;br>
-public class myTestCase {&lt;br>
-  public myTestCase(String text) {&lt;br>
-    super(text);&lt;br>
-  }&lt;br>
-}&lt;br>
-By default, Jmeter will provide some default values for the success/failure code and message. Users should define a set of unique success and failure codes and use them uniformly across all tests.&lt;br>
-General Guidelines<br></br>
+This can be changed with checkbox "Create a new instance per sample".</li>
+</ul>
+The current implementation of the sampler will try to create an instance using the string constructor first. If the test class does not declare a string constructor, the sampler will look for an empty constructor. Example below:
+<example title="Junit Constructors" anchor="junit_constructor_example">
+Empty Constructor:
+<pre>
+public class myTestCase {
+  public myTestCase() {}
+}
+</pre>
+String Constructor:
+<pre>
+public class myTestCase {
+  public myTestCase(String text) {
+    super(text);
+  }
+}
+</pre>
+</example>
+By default, Jmeter will provide some default values for the success/failure code and message. Users should define a set of unique success and failure codes and use them uniformly across all tests.
+<note>
+<h3>General Guidelines</h3>
 If you use setUp and tearDown, make sure the methods are declared public. If you do not, the test may not run properly.
 <br></br>
-Here are some general guidelines for writing Junit tests so they work well with Jmeter. Since Jmeter runs multi-threaded, it is important to keep certain things in mind.&lt;br>
-&lt;br>
-1. Write the setUp and tearDown methods so they are thread safe. This generally means avoid using static memebers.&lt;br>
-2. Make the test methods discrete units of work and not long sequences of actions. By keeping the test method to a descrete operation, it makes it easier to combine test methods to create new test plans.&lt;br>
-3. Avoid making test methods depend on each other. Since Jmeter allows arbitrary sequencing of test methods, the runtime behavior is different than the default Junit behavior.&lt;br>
-4. If a test method is configurable, be careful about where the properties are stored. Reading the properties from the Jar file is recommended.&lt;br>
-5. Each sampler creates an instance of the test class, so write your test so the setup happens in oneTimeSetUp and oneTimeTearDown.
+Here are some general guidelines for writing Junit tests so they work well with Jmeter. Since Jmeter runs multi-threaded, it is important to keep certain things in mind.
+<ul>
+<li>Write the setUp and tearDown methods so they are thread safe. This generally means avoid using static memebers.</li>
+<li>Make the test methods discrete units of work and not long sequences of actions. By keeping the test method to a descrete operation, it makes it easier to combine test methods to create new test plans.</li>
+<li>Avoid making test methods depend on each other. Since Jmeter allows arbitrary sequencing of test methods, the runtime behavior is different than the default Junit behavior.</li>
+<li>If a test method is configurable, be careful about where the properties are stored. Reading the properties from the Jar file is recommended.</li>
+<li>Each sampler creates an instance of the test class, so write your test so the setup happens in oneTimeSetUp and oneTimeTearDown.</li>
+</ul>
+</note>
 </description>
 <properties>
   <property name="Name" required="">Descriptive name for this element that is shown in the tree.</property>