Author: simonetripodi
Date: Fri Jul 27 07:35:50 2012
New Revision: 1366301
URL: http://svn.apache.org/viewvc?rev=1366301&view=rev
Log:
[FUNCTOR-23] aggregator.xml generates broken JavaDoc links - patch provided by
Liviu Tudor
Modified:
commons/proper/functor/trunk/src/changes/changes.xml
commons/proper/functor/trunk/src/site/xdoc/aggregator.xml
Modified: commons/proper/functor/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/commons/proper/functor/trunk/src/changes/changes.xml?rev=1366301&r1=1366300&r2=1366301&view=diff
==============================================================================
--- commons/proper/functor/trunk/src/changes/changes.xml (original)
+++ commons/proper/functor/trunk/src/changes/changes.xml Fri Jul 27 07:35:50
2012
@@ -23,6 +23,9 @@
</properties>
<body>
<release version="1.0" date="2012-??-??" description="First release.">
+ <action dev="simonetripodi" issue="FUNCTOR-23" due-to="Liviu Tudor">
+ aggregator.xml generates broken JavaDoc links
+ </action>
<action dev="kinow" issue="FUNCTOR-22">
Generify ComparableComparator.
</action>
Modified: commons/proper/functor/trunk/src/site/xdoc/aggregator.xml
URL:
http://svn.apache.org/viewvc/commons/proper/functor/trunk/src/site/xdoc/aggregator.xml?rev=1366301&r1=1366300&r2=1366301&view=diff
==============================================================================
--- commons/proper/functor/trunk/src/site/xdoc/aggregator.xml (original)
+++ commons/proper/functor/trunk/src/site/xdoc/aggregator.xml Fri Jul 27
07:35:50 2012
@@ -15,6 +15,10 @@ WITHOUT WARRANTIES OR CONDITIONS OF ANY
See the License for the specific language governing permissions and
limitations under the License.
-->
+<!--
+See https://jira.codehaus.org/browse/MSITE-646, the links to JavaDoc methods
have to
+have the hash URL-escaped.
+-->
<document>
<properties>
<title>Aggregator</title>
@@ -48,7 +52,7 @@ limitations under the License.
</p>
<p>
The framework allows for any <code>List</code>-based implementation to
be plugged in, by
- implementing <a
href="apidocs/org/apache/commons/functor/aggregator/AbstractListBackedAggregator.html#createList()">createList()</a>,
+ implementing <a
href="apidocs/org/apache/commons/functor/aggregator/AbstractListBackedAggregator.html%23createList()">createList()</a>,
however, there is also an <code>ArrayList</code>-based implementation
provided in
<a
href="apidocs/org/apache/commons/functor/aggregator/ArrayListBackedAggregator.html">ArrayListBackedAggregator</a>
which can be used out-of-the-box.
@@ -57,17 +61,17 @@ limitations under the License.
While the <i>store</i> implementation stores the data in a list, the
<i>nostore</i> one
stores just a single object -- every time data is fed into the
<code>Aggregator</code>,
the data stored in this object and the data
- <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html#add(T)">passed
in</a>
+ <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html%23add(T)">passed
in</a>
are "aggregated" there and then using the supplied
<a
href="apidocs/org/apache/commons/functor/BinaryFunction.html">formula</a> and
the result of this operation
is stored back in the object this implementation uses to store data.
</p>
<p>
This has the implication that unlike the list-backed storage
implementation (where the
- result of aggregating the data is not known until <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html#evaluate()">evaluate()</a>
+ result of aggregating the data is not known until <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html%23evaluate()">evaluate()</a>
is called), with the <i>nostore</i> implementation the result is known
(and saved back) at
any moment. This arguably makes this class "faster", however this
comes at the cost of a
- slower <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html#add(T)">add()</a>
+ slower <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html%23add(T)">add()</a>
operation, as the aggregation formula is applied. Also, let's remind
ourselves that not all
formulas can be implemented using the <i>nostore</i> implementation
(see above).
</p>
@@ -92,9 +96,9 @@ limitations under the License.
<a
href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html">AbstractTimedAggregator</a>
offers support to start a timer internally to do that. The class
offers a <i>listener</i>
mechanism where classes can register to receive <a
href="apidocs/org/apache/commons/functor/aggregator/TimedAggregatorListener.html">timer
notifications</a> (if timer support was configured) and after all listeners
have been
- notified the aggregator is <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html#reset()">reset</a>.
+ notified the aggregator is <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html%23reset()">reset</a>.
The result of
- <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html#evaluate()">evaluate()</a>
+ <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html%23evaluate()">evaluate()</a>
(the result of aggregating data) is passed in to the listeners. This
allows for an object
to simply register itself as a timer listener to the aggregator and
only react to the
timer notifications (e.g. write the result to a file for offline
analysis etc) while the
@@ -104,7 +108,7 @@ limitations under the License.
When the data is being flushed/reset, a
<a
href="apidocs/org/apache/commons/functor/aggregator/TimedAggregatorListener.html">TimedAggregatorListener</a>
can be registered to receive a notification. The notification is sent
<b>after</b> the data is reset.
- Prior to resetting the data, <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html#evaluate()">evaluate()</a>
+ Prior to resetting the data, <a
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html%23evaluate()">evaluate()</a>
is called, and the result of the evaluation is sent to the listener.
</p>
<p>
@@ -119,7 +123,7 @@ limitations under the License.
<p>
<ul>
<li><b>Using a per-instance timer</b> : by default, when using
the
- <a
href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html#AbstractTimedAggregator(long)">1
+ <a
href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html%23AbstractTimedAggregator(long)">1
parameter constructor</a> with a value > 0, the aggregator
will create a
<code>Timer</code> object internally and schedule the regular
task of resetting the
aggregator under this <code>Timer</code>. While this helps
preventing memory leaks
@@ -133,18 +137,18 @@ limitations under the License.
href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html#MAIN_TIMER">static
timer instance</a> which can be shared amongst all instances of
this class, if using
<a
-
href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html#AbstractTimedAggregator(long,
boolean)">the
+
href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html%23AbstractTimedAggregator(long,
boolean)">the
constructor with 2 params</a>. When doing so, each such instance
will schedule its
regular reset task against this timer. While this reduces the
memory footprint and
threading on the system, it can lead to memory leaks if this is
not handled correctly.
Therefore please make sure you invoke <a
-
href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html#stop()">stop()</a>
+
href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html%23stop()">stop()</a>
on such aggregators when finished working with them.</li>
</ul>
</p>
<p>
It is recommended you always invoke <a
-
href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html#stop()">stop()</a>
+
href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html%23stop()">stop()</a>
at the end of the lifecycle of an aggregator -- regardless of timer
support (shared /
per instance) or not -- in particular calling <code>stop()</code> on
an aggregator with
no timer support has no effect, however doing so ensures code
uniformity and cleanliness.
@@ -268,7 +272,7 @@ public class AggregatorTesting implement
<p>This has the advantage of a lower memory footprint as well (see
above). If your healthcheck
indicator is based on the maximum transaction time over a 5 seconds
interval, then you simply
- replace the <a
href="apidocs/org/apache/commons/functor/aggregator/AbstractNoStoreAggregator.html#getAggregationFunction()">aggregation
+ replace the <a
href="apidocs/org/apache/commons/functor/aggregator/AbstractNoStoreAggregator.html%23getAggregationFunction()">aggregation
function</a> with a max value implementation:
</p>
@@ -282,10 +286,10 @@ public class AggregatorTesting implement
<p>Or you can simply roll out your own code -- if using the
<i>nostore</i> implementation,
all you need to do is implement a
<a
href="apidocs/org/apache/commons/functor/BinaryFunction.html">BinaryFunction</a>
and pass
- it to the <a
href="apidocs/org/apache/commons/functor/aggregator/AbstractNoStoreAggregator.html#AbstractNoStoreAggregator(org.apache.commons.functor.BinaryFunction)">Aggregator
+ it to the <a
href="apidocs/org/apache/commons/functor/aggregator/AbstractNoStoreAggregator.html%23AbstractNoStoreAggregator(org.apache.commons.functor.BinaryFunction)">Aggregator
constructor</a>. This function will receive the already-stored
aggregated value as the first parameter, and data just passed in (via <a
-
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html#add(T)">add()</a>)
as the
+
href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html%23add(T)">add()</a>)
as the
second parameter; the result of this function will be stored back in the
aggregator.
</p>
<p>
