This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/activemq-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new d0e401a50 Automatic Site Publish by Buildbot
d0e401a50 is described below
commit d0e401a504b52b491ef45f99db0673b41badc1bf
Author: buildbot <[email protected]>
AuthorDate: Tue Oct 18 06:23:17 2022 +0000
Automatic Site Publish by Buildbot
---
output/58-migration-guide.html | 53 +++++++++---
output/static-transport-reference.html | 82 +++++++++---------
output/uri-protocols.html | 153 ++++++++++++++++-----------------
3 files changed, 156 insertions(+), 132 deletions(-)
diff --git a/output/58-migration-guide.html b/output/58-migration-guide.html
index 5d47ae39a..ec100d379 100644
--- a/output/58-migration-guide.html
+++ b/output/58-migration-guide.html
@@ -99,20 +99,49 @@
<ol>
<li>New modules may effect your maven pom dependencies<br />
<code class="language-plaintext highlighter-rouge">activemq-core</code> has
been replaced with <code class="language-plaintext
highlighter-rouge">activemq-client</code> and <code class="language-plaintext
highlighter-rouge">activemq-broker</code>. The various message stores have
their own activemq-xx-store module. The uber module <code
class="language-plaintext highlighter-rouge">activemq-all</code> remains.</li>
- <li>
- <p>Changed JMX Mbean ObjectNames will effect scripts or tools that
directly reference Mbean names<br />
+ <li>Changed JMX Mbean ObjectNames will effect scripts or tools that directly
reference Mbean names<br />
All mbeans now share the type=Broker attribute, which gives them containment.
In this way, consumers hang off of destinations, which hang off the broker.<br
/>
-The different Mbean types are identified by the presence of specific
identifiers in their ObjectNames. The mapping from old to new ObjectName is as
follows:</p>
+The different Mbean types are identified by the presence of specific
identifiers in their ObjectNames. The mapping from old to new ObjectName is as
follows:</li>
+</ol>
- <div class="language-plaintext highlighter-rouge"><div
class="highlight"><pre class="highlight"><code>Type|Old Name|New Name
----|---|---
-Broker|Type=Broker|type=Broker
-Destination|Type=Queue\|Topic,Destination=<destination
identifier>|type=Broker,destinationType=Queue\|Topic,destinationName=<destination
identifier>
-Connector|Type=Connector|type=Broker,connector=clientConnectors
-NetworkConnector|Type=NetworkConnector|type=Broker,connector=networkConnectors
-Connection|Type=Connection|type=Broker,connector=*,connectionViewType=remoteAddress\|clientId
-</code></pre></div> </div>
- </li>
+<table>
+ <thead>
+ <tr>
+ <th>Type</th>
+ <th>Old Name</th>
+ <th>New Name</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>Broker</td>
+ <td>Type=Broker</td>
+ <td>type=Broker</td>
+ </tr>
+ <tr>
+ <td>Destination</td>
+ <td>Type=Queue|Topic,Destination=<destination
identifier=""></destination></td>
+ <td>type=Broker,destinationType=Queue|Topic,destinationName=<destination
identifier=""></destination></td>
+ </tr>
+ <tr>
+ <td>Connector</td>
+ <td>Type=Connector</td>
+ <td>type=Broker,connector=clientConnectors</td>
+ </tr>
+ <tr>
+ <td>NetworkConnector</td>
+ <td>Type=NetworkConnector</td>
+ <td>type=Broker,connector=networkConnectors</td>
+ </tr>
+ <tr>
+ <td>Connection</td>
+ <td>Type=Connection</td>
+
<td>type=Broker,connector=*,connectionViewType=remoteAddress|clientId</td>
+ </tr>
+ </tbody>
+</table>
+
+<ol>
<li>OSGi integration has changed. The full details are at <a
href="osgi-integration.html">OSGi Integration</a>. In summary:
<ol>
<li>There is a single uber OSGI bundle</li>
diff --git a/output/static-transport-reference.html
b/output/static-transport-reference.html
index 81f2e98f4..680fce9ae 100644
--- a/output/static-transport-reference.html
+++ b/output/static-transport-reference.html
@@ -108,47 +108,47 @@
<h5 id="options">Options</h5>
-<p>Option Name</p>
-
-<p>Default Value</p>
-
-<p>Description</p>
-
-<p>initialReconnectDelay</p>
-
-<p>10</p>
-
-<p>How long to wait before the first reconnect attempt (in ms)</p>
-
-<p>maxReconnectDelay</p>
-
-<p>30000</p>
-
-<p>The maximum amount of time we ever wait between reconnect attempts (in
ms)</p>
-
-<p>useExponentialBackOff</p>
-
-<p>true</p>
-
-<p>Should an exponential backoff be used btween reconnect attempts</p>
-
-<p>backOffMultiplier</p>
-
-<p>2</p>
-
-<p>The exponent used in the exponential backoff attempts</p>
-
-<p>maxReconnectAttempts</p>
-
-<p>0</p>
-
-<p>If not 0, then this is the maximum number of reconnect attempts before an
error is sent back to the client</p>
-
-<p>minConnectTime</p>
-
-<p>500</p>
-
-<p>If a connaction fails faster than this amount of time then it is considered
a connection failure</p>
+<table>
+ <thead>
+ <tr>
+ <th>Option Name</th>
+ <th>Default Value</th>
+ <th>Description</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>initialReconnectDelay</td>
+ <td>10</td>
+ <td>How long to wait before the first reconnect attempt (in ms)</td>
+ </tr>
+ <tr>
+ <td>maxReconnectDelay</td>
+ <td>30000</td>
+ <td>The maximum amount of time we ever wait between reconnect attempts
(in ms)</td>
+ </tr>
+ <tr>
+ <td>useExponentialBackOff</td>
+ <td>true</td>
+ <td>Should an exponential backoff be used btween reconnect attempts</td>
+ </tr>
+ <tr>
+ <td>backOffMultiplier</td>
+ <td>2</td>
+ <td>The exponent used in the exponential backoff attempts</td>
+ </tr>
+ <tr>
+ <td>maxReconnectAttempts</td>
+ <td>0</td>
+ <td>If not 0, then this is the maximum number of reconnect attempts
before an error is sent back to the client</td>
+ </tr>
+ <tr>
+ <td>minConnectTime</td>
+ <td>500</td>
+ <td>If a connaction fails faster than this amount of time then it is
considered a connection failure</td>
+ </tr>
+ </tbody>
+</table>
<h5 id="notes">Notes</h5>
diff --git a/output/uri-protocols.html b/output/uri-protocols.html
index 993f320c3..7bb53ee84 100644
--- a/output/uri-protocols.html
+++ b/output/uri-protocols.html
@@ -105,85 +105,80 @@ Connection connection = factory.createConnection();</p>
<h2 id="protocol-summary">Protocol Summary</h2>
-<p>Protocol</p>
-
-<p>Example</p>
-
-<p>Description</p>
-
-<p>Server?</p>
-
-<p>VM</p>
-
-<p>vm://host:port</p>
-
-<p>Client connect to each other within the same JVM. This does use an
asynchronous channel and a separate worker thread. You can enable sync sending
using a query parameter, such as</p>
-
-<p>vm://localhost?async=false</p>
-
-<p>Yes</p>
-
-<p>TCP</p>
-
-<p>tcp://host:port</p>
-
-<p>Client connects to the broker at the given URL</p>
-
-<p>Yes</p>
-
-<p>SSL</p>
-
-<p>ssl://host:port</p>
-
-<p>Client connects to the broker at the given URL</p>
-
-<p>Yes</p>
-
-<p>Failover</p>
-
-<p>failover:(Uri1,Uri2,Uri3,…,UriN)</p>
-
-<p>Provides a list of possible URIs to connect to and one is randomly chosen.
If the connection fails then the transport auto-reconnects to a different
one</p>
-
-<p>Peer</p>
-
-<p>peer://serviceName</p>
-
-<p>Creates a pure peer to peer network of nodes of a given service name. In
peer mode there is no server, nodes just automatically connect and make a peer
network. The serviceName allows you to keep networks apart from each other,
such as development, testing, UAT and production.</p>
-
-<p>Discovery</p>
-
-<p>discovery://host:port</p>
-
-<p>Uses <a href="discovery">Discovery</a> to connect to an available broker of
the correct channel name. If multiple brokers can be found then one is chosen
at random. If the connection fails then another broker is chosen, if
available</p>
-
-<p>Zeroconf</p>
-
-<p>zeroconf:_activemq.broker.development.</p>
-
-<p>Uses <a href="zeroconf">Zeroconf</a> to connect to an available broker of
the correct Zeroconf service name. If multiple brokers can be found then one is
chosen at random. If the connection fails then another broker is chosen, if
available</p>
-
-<p>HTTP</p>
-
-<p>http://host:port</p>
-
-<p>Client connects to the broker using HTTP tunnelling, with XML payloads
suitable for going through firewalls</p>
-
-<p>Yes</p>
-
-<p>UDP</p>
-
-<p>udp://host:port</p>
-
-<p>Client connects to the broker at the given URL</p>
-
-<p>multicast</p>
-
-<p>multicast://host:port</p>
-
-<p>No server, though only works for pub/sub. A pure peer based network where
all traffic is multicasted around and filtering is performed on the client.</p>
-
-<p>The <em>Server?</em> column above indiciates whether or not a protocol can
be used in an ActiveMQ broker transport connector. All of the above protocols
can be used in a JMS client to connect to the messaging fabric; only those
protocols indicated can be used in a broker-side transport connector.</p>
+<table>
+ <thead>
+ <tr>
+ <th>Protocol</th>
+ <th>Example</th>
+ <th>Description</th>
+ <th>Server?</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>VM</td>
+ <td>vm://host:port</td>
+ <td>Client connect to each other within the same JVM. This does use an
asynchronous channel and a separate worker thread. You can enable sync sending
using a query parameter, such as vm://localhost?async=false</td>
+ <td>Yes</td>
+ </tr>
+ <tr>
+ <td>TCP</td>
+ <td>tcp://host:port</td>
+ <td>Client connects to the broker at the given URL</td>
+ <td>Yes</td>
+ </tr>
+ <tr>
+ <td>SSL</td>
+ <td>ssl://host:port</td>
+ <td>Client connects to the broker at the given URL</td>
+ <td>Yes</td>
+ </tr>
+ <tr>
+ <td>Failover</td>
+ <td>failover:(Uri1,Uri2,Uri3,…,UriN)</td>
+ <td>Provides a list of possible URIs to connect to and one is randomly
chosen. If the connection fails then the transport auto-reconnects to a
different one</td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>Peer</td>
+ <td>peer://serviceName</td>
+ <td>Creates a pure peer to peer network of nodes of a given service
name. In peer mode there is no server, nodes just automatically connect and
make a peer network. The serviceName allows you to keep networks apart from
each other, such as development, testing, UAT and production.</td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>Discovery</td>
+ <td>discovery://host:port</td>
+ <td>Uses <a href="discovery">Discovery</a> to connect to an available
broker of the correct channel name. If multiple brokers can be found then one
is chosen at random. If the connection fails then another broker is chosen, if
available</td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>Zeroconf</td>
+ <td>zeroconf:_activemq.broker.development.</td>
+ <td>Uses <a href="zeroconf">Zeroconf</a> to connect to an available
broker of the correct Zeroconf service name. If multiple brokers can be found
then one is chosen at random. If the connection fails then another broker is
chosen, if available</td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>HTTP</td>
+ <td>http://host:port</td>
+ <td>Client connects to the broker using HTTP tunnelling, with XML
payloads suitable for going through firewalls</td>
+ <td>Yes</td>
+ </tr>
+ <tr>
+ <td>UDP</td>
+ <td>udp://host:port</td>
+ <td>Client connects to the broker at the given URL</td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>multicast</td>
+ <td>multicast://host:port</td>
+ <td>No server, though only works for pub/sub. A pure peer based network
where all traffic is multicasted around and filtering is performed on the
client.</td>
+ <td> </td>
+ </tr>
+ </tbody>
+</table>
+
+<p>The <em>Server</em> column above indicates whether a protocol can be used
in an ActiveMQ broker transport connector. All of the above protocols can be
used in a JMS client to connect to the messaging fabric; only those protocols
indicated can be used in a broker-side transport connector.</p>
<p>When connecting to an ActiveMQ broker, this could reside locally inside
your JVM or be remote on another machine somewhere. If you want to enable the
deployment of the ActiveMQ inside your JVM you can enable the useEmbeddedBroker
property on the <a
href="http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html";>ActiveMQConnectionFactory</a>.</p>
