[jboss-cvs] JBoss Messaging SVN: r7003 - trunk/docs/user-manual/en.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri May 22 08:04:34 EDT 2009
Author: timfox
Date: 2009-05-22 08:04:34 -0400 (Fri, 22 May 2009)
New Revision: 7003
Modified:
trunk/docs/user-manual/en/architecture.xml
trunk/docs/user-manual/en/messaging-concepts.xml
trunk/docs/user-manual/en/using-jms.xml
trunk/docs/user-manual/en/using-server.xml
Log:
proof reading changes
Modified: trunk/docs/user-manual/en/architecture.xml
===================================================================
--- trunk/docs/user-manual/en/architecture.xml 2009-05-22 11:49:07 UTC (rev 7002)
+++ trunk/docs/user-manual/en/architecture.xml 2009-05-22 12:04:34 UTC (rev 7003)
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="architecture">
<title>Architecture</title>
- <para>In this section we will discuss the JBoss Messaging high level architecture and
- concepts.</para>
+ <para>In this section we will give an overview of the JBoss Messaging high level
+ architecture.</para>
<section>
<title>Core Architecture</title>
<para>JBoss Messaging core is designed simply as set of Plain Old Java Objects
@@ -11,7 +11,8 @@
fact, JBoss Messaging core has <emphasis role="italic">zero</emphasis> dependencies on
any jars other than the standard JDK classes!</para>
<para>This allows JBoss Messaging to be easily embedded in your own project, or instantiated
- in any dependency injection framework such as JBoss Microcontainer or Spring.</para>
+ in any dependency injection framework such as JBoss Microcontainer, Spring or Google
+ Guice.</para>
<para>A JBoss Messaging server has its own high performance persistent journal, which it
uses for message and other persistence.</para>
<para>Using a high performance journal allows outrageous persistence message performance,
@@ -27,12 +28,12 @@
JMS.</para>
</listitem>
<listitem>
- <para>JMS client API. The standard JMS classes are available at the client
+ <para>JMS client API. The standard JMS API is available at the client
side.</para>
</listitem>
</orderedlist>
</para>
- <para>JMS semantics are implemented in a thin JMS facade layer on the client side.</para>
+ <para>JMS semantics are implemented by a thin JMS facade layer on the client side.</para>
<para>The JBoss Messaging server does not speak JMS and in fact does not know anything about
JMS, it's a protocol agnostic messaging server designed to be used with multiple
different protocols.</para>
@@ -56,8 +57,8 @@
application that requires messaging functionality internally but you don't want to
expose that as a messaging server you can directly instantiate and embed messaging
servers in your own application.</para>
- <para>Here's a real code example demonstrating just how easy that is:</para>
- <para><code> Server server = new MessagingServer(); </code></para>
+ <para>For more information on embedding JBoss Messaging see the chapter on <xref
+ linkend="embedding-jbm">embedding</xref>.</para>
</section>
<section>
<title>JBoss Messaging integrated with a JEE application server</title>
@@ -65,22 +66,23 @@
adaptor which enables it to be integrated easily into any JEE compliant application
server or servlet engine.</para>
<para>JEE application servers provide Message Driven Beans (MDBs), which are a special type
- of Enterprise Java Beans (EJBs) which can process messages from sources such as JMS
+ of Enterprise Java Beans (EJBs) that can process messages from sources such as JMS
systems or mail systems.</para>
<para>Probably the most common use of an MDB is to consume messages from a JMS messaging
system.</para>
<para>According to the JEE specification, a JEE application server uses a JCA adapter to
integrate with a JMS messaging system so it can consume messages for MDBs.</para>
- <para>The JCA adapter is not only used by the JEE application server for <emphasis
+ <para>Howvever, the JCA adapter is not only used by the JEE application server for <emphasis
role="italic">consuming</emphasis> messages via MDBs, it is also used when sending
message to the JMS messaging system e.g. from inside an EJB or servlet.</para>
<para>When integrating with a JMS messaging system from inside a JEE application server it
- is always recommended that this is done via the JCA adaptor.</para>
+ is always recommended that this is done via a JCA adaptor.</para>
<para>The application server's JCA service provides extra functionality such as connection
pooling and automatic transaction enlistment, which are desirable when using messaging,
say, from inside an EJB. It is possible to talk to a JMS messaging system directly from
an EJB, MDB or servlet without going through a JCA adapter, but this is not recommended
- since you will not be able to take advantage of the JCA features.</para>
+ since you will not be able to take advantage of the JCA features, such as caching of JMS
+ sessions, which can result in poor performance.</para>
<para>Figure 3.2 belows shows a JEE application server integrating with a JBoss Messaging
server via the JBoss Messaging JCA adaptor. Note that all communication between EJB
sessions or entity beans and Message Driven beans go through the adaptor and not
@@ -92,6 +94,8 @@
<para>
<graphic fileref="images/architecture2.jpg"/>
</para>
+ <para>For more information on using the JCA adaptor, please see the chatper on <xref
+ linkend="appserver-integration">application server integration</xref>.</para>
</section>
<section>
<title>JBoss Messaging stand-alone server</title>
@@ -99,18 +103,19 @@
independent messaging server not dependent on a JEE application server.</para>
<para>The standard stand-alone messaging server configuration comprises a core messaging
server, a JMS service and a JNDI service.</para>
- <para>The role of the JMS Service is to deploy any JMS Queues, Topics and ConnectionFactorys
- from any server side jbm-jms.xml config files. It also provides a simple management API
- for creating and destroying Queues, Topics and ConnectionFactorys which can be accessed
- via JMX or the connection. It is a separate service to the JBoss Messaging core server,
- since the core server is JMS agnostic. If you don't want to deploy any JMS Queues,
- Topics and ConnectionFactorys via server side xml config and don't require a JMS
- management API on the server side then you can disable this service.</para>
+ <para>The role of the JMS Service is to deploy any JMS Queues, Topics and ConnectionFactory
+ instances from any server side <literal>jbm-jms.xml</literal> config files. It also
+ provides a simple management API for creating and destroying Queues, Topics and
+ ConnectionFactory instances which can be accessed via JMX or the connection. It is a
+ separate service to the JBoss Messaging core server, since the core server is JMS
+ agnostic. If you don't want to deploy any JMS Queues, Topics and ConnectionFactory
+ instances via server side xml config and don't require a JMS management API on the
+ server side then you can disable this service.</para>
<para>We also include a JNDI server since JNDI is a common requirement when using JMS to
- lookup Queues, Topics and ConnectionFactorys. If you do not require JNDI then this
- service can be disabled. JBoss Messaging allows you to programmatically create JMS and
- Core objects directly on the client side as opposed to looking them up from JNDI, so a
- JNDI server is not always a requirement.</para>
+ lookup Queues, Topics and ConnectionFactory instances. If you do not require JNDI then
+ this service can also be disabled. JBoss Messaging allows you to programmatically create
+ JMS and core objects directly on the client side as opposed to looking them up from
+ JNDI, so a JNDI server is not always a requirement.</para>
<para>The stand-alone server configuration uses JBoss Microcontainer to instantiate and
enforce dependencies between the components. JBoss Microcontainer is a very lightweight
POJO bootstrapper.</para>
@@ -118,5 +123,7 @@
<para>
<graphic fileref="images/architecture3.jpg"/>
</para>
+ <para>For more information on serve configuration files see the chapter <xref linkend="">using the server</xref>.
+ </para>
</section>
</chapter>
Modified: trunk/docs/user-manual/en/messaging-concepts.xml
===================================================================
--- trunk/docs/user-manual/en/messaging-concepts.xml 2009-05-22 11:49:07 UTC (rev 7002)
+++ trunk/docs/user-manual/en/messaging-concepts.xml 2009-05-22 12:04:34 UTC (rev 7003)
@@ -5,40 +5,44 @@
url="http://en.wikipedia.org/wiki/Message_oriented_middleware">Message Oriented
Middleware</ulink> , we'll just call them messaging systems in the remainder of this
book.</para>
- <para>We'll first prevent a brief overview of what kind of things messaging systems do and and
+ <para>We'll first present a brief overview of what kind of things messaging systems do and and
where they're useful, and the kind of concepts you'll hear about in the messaging
world.</para>
<para>If you're already familiar with what a messaging system is and what it's capable of, then
you can skip this chapter.</para>
- <para>Messaging systems allow you to loosely couple heteregenous systems together, whilst
- typically providing reliability, transactions, and many other features.</para>
- <para>Unlike systems based on a <ulink url="http://en.wikipedia.org/wiki/Remote_procedure_call"
- >Remote Procedure Call</ulink> (RPC) pattern, messaging systems primarily use an
- asynchronous message passing pattern with no tight relationship between requests and
- responses. Most messaging systems also support a request-response mode but this is not a
- primary feature of messaging systems.</para>
- <para>Designing systems to be asynchronous from end-to-end allows you to really take advantage
- of your hardware resources, minimising the amount of threads blocking on IO operations, and
- to use your network bandwidth to its full capacity. With an RPC approach you have to wait
- for a response for each request you make so are limited by the network round trip time, or
- <emphasis role="italic">latency</emphasis> of your network. With an asynchronous system
- you can pipeline flows of messages in different directions, so are limited by the network
- <emphasis role="italic">bandwidth</emphasis> not the latency. This typically allows you
- to create much higher performance applications.</para>
- <para>Messaging systems decouple the senders of messages from the consumers of messages. The
- senders and consumers of messages are completely independent and know nothing of each other.
- This allows you to create flexible, loosely coupled systems.</para>
- <para>Often, large enterprises use a messaging system to implement a message bus which loosely
- couples heterogeneous systems together. Message buses often form the core of an <ulink
- url="http://en.wikipedia.org/wiki/Enterprise_service_bus">Enterprise Service
- Bus</ulink>. (ESB). Using a message bus to couple disparate systems can allow the system to
- grow and adapt. It also allows more flexibility add new systems or retire old ones since
- they don't have brittle dependencies on each other.</para>
<section>
+ <title>Messaging Concepts</title>
+ <para>Messaging systems allow you to loosely couple heteregenous systems together, whilst
+ typically providing reliability, transactions, and many other features.</para>
+ <para>Unlike systems based on a <ulink
+ url="http://en.wikipedia.org/wiki/Remote_procedure_call">Remote Procedure
+ Call</ulink> (RPC) pattern, messaging systems primarily use an asynchronous message
+ passing pattern with no tight relationship between requests and responses. Most
+ messaging systems also support a request-response mode but this is not a primary feature
+ of messaging systems.</para>
+ <para>Designing systems to be asynchronous from end-to-end allows you to really take
+ advantage of your hardware resources, minimising the amount of threads blocking on IO
+ operations, and to use your network bandwidth to its full capacity. With an RPC approach
+ you have to wait for a response for each request you make so are limited by the network
+ round trip time, or <emphasis role="italic">latency</emphasis> of your network. With an
+ asynchronous system you can pipeline flows of messages in different directions, so are
+ limited by the network <emphasis role="italic">bandwidth</emphasis> not the latency.
+ This typically allows you to create much higher performance applications.</para>
+ <para>Messaging systems decouple the senders of messages from the consumers of messages. The
+ senders and consumers of messages are completely independent and know nothing of each
+ other. This allows you to create flexible, loosely coupled systems.</para>
+ <para>Often, large enterprises use a messaging system to implement a message bus which
+ loosely couples heterogeneous systems together. Message buses often form the core of an
+ <ulink url="http://en.wikipedia.org/wiki/Enterprise_service_bus">Enterprise Service
+ Bus</ulink>. (ESB). Using a message bus to de-couple disparate systems can allow the
+ system to grow and adapt. It also allows more flexibility add new systems or retire old
+ ones since they don't have brittle dependencies on each other.</para>
+ </section>
+ <section>
<title>Messaging styles</title>
- <para>Messaging systems normally support two main styles of asynchronous messaging;<ulink
- url="http://en.wikipedia.org/wiki/Message_queue"> message queue</ulink> (also known
- as <emphasis role="italic">point-to-point messaging</emphasis>) and <ulink
+ <para>Messaging systems normally support two main styles of asynchronous messaging; <ulink
+ url="http://en.wikipedia.org/wiki/Message_queue"> message queue</ulink> messaging
+ (also known as <emphasis role="italic">point-to-point messaging</emphasis>) and <ulink
url="http://en.wikipedia.org/wiki/Publish_subscribe">publish subscribe</ulink>
messaging. We'll summarise them briefly here:</para>
<section>
@@ -62,7 +66,7 @@
to the order queue. There are many front end ordering systems which send orders to
the order queue. When a message arrives on the queue it is persisted - this ensures
that if the server crashes the order is not lost. There are many consumers on the
- order queue - each representing an instance of an order processing component - this
+ order queue - each representing an instance of an order processing component - these
can be on different physical machines but consuming from the same queue. The
messaging system delivers each message to one and only one of the ordering
processing components. Different messages can be processed by order processors, but
@@ -79,8 +83,8 @@
<section>
<title>The Publish-Subscribe Pattern</title>
<para>With publish-subscribe messaging many senders can send messages to an entity on
- the server, often called a <emphasis role="italic">topic</emphasis>, e.g. in the JMS
- world.</para>
+ the server, often called a <emphasis role="italic">topic</emphasis> (e.g. in the JMS
+ world).</para>
<para>There can be many subscriptions on a topic, each subscription receives a copy of
<emphasis role="italic">each</emphasis> message sent to the topic. This differs
from the message queue pattern where each message is only consumed by a single
@@ -99,7 +103,7 @@
<title>Delivery guarantees</title>
<para>A key feature of most messaging systems is <emphasis role="italic">reliable
messaging</emphasis>. With reliable messaging the server gives a guarantee that the
- message will be delivered once and only once to each consumer of a queue or each
+ message will be delivered once and only once to each consumer of a queue or each durable
subscription of a topic, even in the event of system failure. This is crucial for many
businesses, you don't want your orders fulfilled more than once or your orders to be
lost.</para>
@@ -167,9 +171,9 @@
different programming languages.</para>
<para>JBoss Messaging can be used by any STOMP client when using the <ulink
url="http://stomp.codehaus.org/StompConnect">StompConnect</ulink> broker which
- translates STOMP protocol to the JMS API.</para>
+ translates the STOMP protocol to the JMS API.</para>
<para>JBoss Messaging will be shortly implementing the STOMP protocol on the boker, thus
- avoiding the usage of StompConnect.</para>
+ avoiding having to use StompConnect.</para>
</section>
<section>
<title>AMQP</title>
@@ -183,9 +187,10 @@
<title>REST</title>
<para><ulink url="http://en.wikipedia.org/wiki/Representational_State_Transfer"
>REST</ulink> approaches to messaging are showing a lot interest recently. With
- a REST approach messaging resources are manipulated as resources, typically using a
- simple set of operations on those resources, e.g. PUT, POST, GET etc. REST
- approaches to messaging often use HTTP as their underlying protocol.</para>
+ a REST approach messaging resources are manipulated as resources defined by a URI
+ and typically using a simple set of operations on those resources, e.g. PUT, POST,
+ GET etc. REST approaches to messaging often use HTTP as their underlying
+ protocol.</para>
<para>The advantage of a REST approach with HTTP is in its simplicity and the fact the
internet is already tuned to deal with HTTP optimally.</para>
<para>JBoss Messaging will shortly be implementing REST.</para>
@@ -193,8 +198,8 @@
</section>
<section>
<title>High Availability</title>
- <para>High Availability (HA) means that the system should remain operation after failure of
- one or more of the servers. The degree of support for HA varies between various
+ <para>High Availability (HA) means that the system should remain operational after failure
+ of one or more of the servers. The degree of support for HA varies between various
messaging systems.</para>
<para>Some messaging systems require you to deal with server side failure by writing some
client side code which gets called on event of server failure, and in which you are
@@ -203,6 +208,8 @@
any special client side code to deal with failure. On failover JBoss Messaging will
automatically fail over your client connections to another server, and your client
sessions can continue as if nothing happened.</para>
+ <para>For more information on HA, please see the <xref linkend="ha">HA</xref>
+ section.</para>
</section>
<section>
<title>Clusters</title>
@@ -211,52 +218,30 @@
consuming messages to be spread over many servers. This allows your system to be able
scale horizontally by adding new servers to the cluster.</para>
<para>Degrees of support for clusters varies between messaging systems, with some systems
- having fairly basic clusters where the cluster members being hardly aware of each
+ having fairly basic clusters with the cluster members being hardly aware of each
other.</para>
<para>JBoss Messaging provides very configurable state of the art clustering where messages
can be intelligently load balanced between the servers in the cluster, according to the
number of consumers on each node, and whether they are ready for messages.</para>
<para>JBoss Messaging also has the ability to automatically redistribute messages between
nodes of a cluster to prevent starvation on any particular node.</para>
- <para>For full details on clustering please the clustering section.</para>
+ <para>For full details on clustering please the chapter on <xref linkend="clusters"
+ >clusters</xref>.</para>
</section>
<section>
<title>Bridges and routing</title>
<para>Some messaging systems allow isolated clusters or single nodes to be bridged together,
- typically over unreliable connections like a Wide Area Network (WAN).</para>
+ typically over unreliable connections like a wide area network (WAN).</para>
<para>A bridge normally consumes from a queue on one server and forwards messages to another
queue on a different server. Bridges cope with unreliable connections, automatically
reconnecting when the connections becomes available again.</para>
<para>JBoss Messaging bridges can be configured with filter expressions to only forward
- certain messages, and transformation can be hooked in.</para>
+ certain messages, and transformation can also be hooked in.</para>
<para>JBoss Messaging also allows routing between queues to be configured in server side
configuration. This allows complex routing networks to be set up forwarding or copying
messages from one destination to another, forming a global network of interconnected
brokers.</para>
+ <para>See the relevant chapters for more information on <xref linkend="core-bridges"
+ >bridges</xref> and <xref linkend="diverts">diverts</xref>.</para>
</section>
- <section>
- <title>Other messaging system functionality</title>
- <para>Here's a quick run through of other features and terms you might hear in the context
- of messaging systems:</para>
- <itemizedlist>
- <listitem>
- <para>Message expiry</para>
- <para>You can set a Time to Live (TTL) on a message. If you do this then if the
- messaging system has not delivered the message by the time TTL comes then the
- message will be discarded or possibly sent to a configurable other
- destination.</para>
- </listitem>
- <listitem>
- <para>Message redelivery</para>
- <para>Messages that have been delivered to a consumer and ultimately cancelled, i.e.
- the consumer received the message but didn't acknowledge it before closing, can
- be redelivered with some pre configured semantics.</para>
- </listitem>
- <listitem>
- <para>Message Scheduling</para>
- <para>When sending a message it is possible to schedule when the message will
- actually get delivered to a consumer.</para>
- </listitem>
- </itemizedlist>
- </section>
</chapter>
Modified: trunk/docs/user-manual/en/using-jms.xml
===================================================================
--- trunk/docs/user-manual/en/using-jms.xml 2009-05-22 11:49:07 UTC (rev 7002)
+++ trunk/docs/user-manual/en/using-jms.xml 2009-05-22 12:04:34 UTC (rev 7003)
@@ -4,11 +4,13 @@
<para>Although JBoss Messaging provides a JMS agnostic messaging API, many users will be more
comfortable using JMS.</para>
<para>JMS is a very popular API standard for messaging, and most messaging systems provide a JMS
- API. If you are completely new to JMS we suggest you following the Sun JMS tutorial [link] -
- a full JMS tutorial is out of scope for this guide.</para>
+ API. If you are completely new to JMS we suggest you following the<ulink
+ url="http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/jms_tutorialTOC.html"> Sun
+ JMS tutorial</ulink> - a full JMS tutorial is out of scope for this guide.</para>
<para>JBoss Messaging also ships with a wide range of examples, many of which demonstrate JMS
API usage. A good place to start would be to play around with the simple JMS Queue and Topic
- example, but we also provide examples for many other parts of the JMS API.</para>
+ example, but we also provide examples for many other parts of the JMS API. A full
+ description of the examples is available <xref linkend="examples">here</xref>.</para>
<para>In this section we'll go through the main steps in configuring the server for JMS and
creating a simple JMS program. We'll also show how to configure and use JNDI, and also how
to use JMS with JBoss Messaging without using any JNDI.</para>
@@ -16,9 +18,9 @@
<title>A simple ordering system</title>
<para>For this chapter we're going to use a very simple ordering system as our example. It's
a somewhat contrived example because of its extreme simplicity, but it serves to
- demonstrates the very basics of setting up and using JMS.</para>
- <para>We will have a single JMS Queue <literal>OrderQueue</literal>, and we will have a
- single <literal>MessageProducer</literal> sending an order message to the queue and a
+ demonstrate the very basics of setting up and using JMS.</para>
+ <para>We will have a single JMS Queue called <literal>OrderQueue</literal>, and we will have
+ a single <literal>MessageProducer</literal> sending an order message to the queue and a
single <literal>MessageConsumer</literal> consuming the order message from the
queue.</para>
<para>The queue will be a <literal>durable</literal> queue, i.e. it will survive a server
@@ -69,10 +71,11 @@
<title>JNDI configuration</title>
<para>When using JNDI from the client side you need to specify a set of JNDI properties
which tell the JNDI client where to locate the JNDI server, amongst other things. These
- are often specified in a file jndi.properties on the client classpath, or you can
- specify them directly when creating the JNDI initial context. A full JNDI tutorial is
- outside the scope of this document, please see the Sun JNDI tutorial for more
- information on how to use JNDI. [LINK]</para>
+ are often specified in a file called <literal>jndi.properties</literal> on the client
+ classpath, or you can specify them directly when creating the JNDI initial context. A
+ full JNDI tutorial is outside the scope of this document, please see the <ulink
+ url="http://java.sun.com/products/jndi/tutorial/TOC.html">Sun JNDI tutorial</ulink>
+ for more information on how to use JNDI.</para>
<para>For talking to the JBoss JNDI Server, the jndi properties will look something like
this:</para>
<programlisting>
@@ -99,8 +102,8 @@
</programlisting>
<note>
<para>If you want your JNDI server to be available to non local clients make sure you
- change it's bind address to something other than
- <literal>localhost</literal>!</para>
+ change it's bind address to something other than <literal
+ >localhost</literal>!</para>
</note>
</section>
<section>
@@ -142,10 +145,13 @@
<para>With JBoss Messaging you can do exactly that. JBoss Messaging supports the direct
instantiation of JMS Queue, Topic and Connection Factory instances, so you don't have to
use JNDI at all.</para>
- <para>For a full working example of direct instantiation please see the JMS examples.</para>
+ <para>For a full working example of direct instantiation please see the JMS <xref
+ linkend="examples">examples</xref>.</para>
<para>Here's our simple example, rewritten to not use JNDI at all:</para>
<para>We create the JMS ConnectionFactory object directly, note we need to provide
- connection params and specify which transport we are using:</para>
+ connection params and specify which transport we are using, for more information on
+ connectors please see the section on <xref linkend="configuring-transports">configuring
+ transports</xref>.</para>
<programlisting>
TransportConfiguration transportConfiguration =
new TransportConfiguration(NettyConnectorFactory.class.getName());
Modified: trunk/docs/user-manual/en/using-server.xml
===================================================================
--- trunk/docs/user-manual/en/using-server.xml 2009-05-22 11:49:07 UTC (rev 7002)
+++ trunk/docs/user-manual/en/using-server.xml 2009-05-22 12:04:34 UTC (rev 7003)
@@ -8,7 +8,7 @@
the JBoss Messaging standalone server, in its default configuration with a JMS Service and
JNDI service enabled.</para>
<para>When running embedded in JBoss Application Server the layout may be slightly different but
- by and large will be the same.</para>
+ by-and-large will be the same.</para>
<section>
<title>Starting and Stopping the standalone server</title>
<para>In the distribution you will find a directory called <literal>bin</literal>.</para>
@@ -41,12 +41,12 @@
</section>
<section>
<title>Server runtime</title>
- <para>JBoss Messaging looks for its configuration files on the Java classpath</para>
+ <para>JBoss Messaging looks for its configuration files on the Java classpath.</para>
<para>The scripts <literal>run.sh</literal> and <literal>run.bat</literal> specify the
classpath when calling Java to run the server.</para>
<para>In the distribution, the run scripts will add the non clustered configuration
directory to the classpath. This is a directory which contains a set of configuration
- files for running the JBoss Messaging sever in a basic non-clustered configuration. In
+ files for running the JBoss Messaging server in a basic non-clustered configuration. In
the distribution this directory is <literal>config/stand-alone/non-clustered/</literal>
from the root of the distribution.</para>
<para>The distribution contains several standard configuration sets for running:</para>
@@ -96,7 +96,8 @@
</listitem>
<listitem>
<para><literal>jbm-configuration.xml</literal>. This is the main JBoss Messaging
- configuration file. We'll describe it fully in section [LINK]</para>
+ configuration file. All the parameters in this file are described <xref
+ linkend="configuration-index">here</xref>.</para>
</listitem>
<listitem>
<para><literal>jbm-queues.xml</literal>. This file contains pre-defined queues,
@@ -107,25 +108,27 @@
configured in these files is to allow you to manage your queue configuration
over many files instead of being forced to maintain it in a single file. There
can be many <literal>jbm-queues.xml</literal> files on the classpath. All will
- be loaded if found.. This file is described in full here [LINK]</para>
+ be loaded if found.</para>
</listitem>
<listitem>
<para><literal>jbm-users.xml</literal> JBoss Messaging ships with a security manager
impementation which obtains user credentials from the <literal
>jbm-users.xml</literal> file. This file contains user, password and role
- information. For more information on security please see the section
- [LINK]</para>
+ information. For more information on security please see the chapter on <xref
+ linkend="security">security</xref>.</para>
</listitem>
<listitem>
<para><literal>jbm-jms.xml</literal> The distro configuration by default includes a
server side JMS service which mainly deploys JMS Queues, Topics and
ConnectionFactorys from this file into JNDI. If you're not using JMS, or you
don't need to deploy JMS objects on the server side, then you don't need this
- file.</para>
+ file. For more information on using JMS, please see the <xref
+ linkend="using-jms">using JMS</xref> chapter.</para>
</listitem>
<listitem>
<para><literal>logging.properties</literal> This is used to configure the logging
- handlers used by the Java logger.</para>
+ handlers used by the Java logger. For more information on configuring logging
+ please see <xref linkend="logging">this chapter</xref>.</para>
</listitem>
<listitem>
<para><literal>log4j.xml</literal> This is the Log4j configuration if the Log4j
@@ -155,10 +158,11 @@
<section id="server.microcontainer.configuration">
<title>JBoss Microcontainer Beans File</title>
<para>The stand-alone server is basically a set of POJOs which are instantiated by the light
- weight JBoss Microcontainer engine. [LINK]</para>
+ weight<ulink url="http://www.jboss.org/jbossmc/"> JBoss Microcontainer
+ </ulink>engine.</para>
<note>
<para>A beans file is also needed when the server is deployed in the JBoss Application
- Server although this will deploy a slightly different set of objects since the
+ Server but this will deploy a slightly different set of objects since the
Application Server will already have things like security etc deployed.</para>
</note>
<para>Let's take a look at an example beans file from the stand-alone server:</para>
@@ -254,9 +258,9 @@
<para>Security Manager. The security manager used by the messaging server is
pluggable. The default one used just reads user-role information from the
<literal>jbm-users.xml</literal> file on disk. However it can be replaced by
- a JAAS security manager, or when running inside JBoss Application Server it is
- configured to use the JBoss AS security manager for tight integration with JBoss
- AS security.</para>
+ a JAAS security manager, or when running inside JBoss Application Server it can
+ be configured to use the JBoss AS security manager for tight integration with
+ JBoss AS security.</para>
</listitem>
<listitem>
<para>MessagingServer</para>
More information about the jboss-cvs-commits
mailing list