[jboss-cvs] JBoss Messaging SVN: r6739 - in trunk: docs/user-manual/en/modules and 8 other directories.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue May 12 06:54:14 EDT 2009
Author: timfox
Date: 2009-05-12 06:54:14 -0400 (Tue, 12 May 2009)
New Revision: 6739
Modified:
trunk/docs/user-manual/en/diagrams/architecture-diagrams.odg
trunk/docs/user-manual/en/modules/architecture.xml
trunk/docs/user-manual/en/modules/using-core.xml
trunk/docs/user-manual/en/modules/using-jms.xml
trunk/docs/user-manual/en/modules/using-server.xml
trunk/src/bin/run.bat
trunk/src/bin/run.sh
trunk/src/config/stand-alone/non-clustered/jbm-standalone-beans.xml
trunk/src/main/org/jboss/messaging/core/config/impl/ConfigurationImpl.java
trunk/src/main/org/jboss/messaging/core/management/impl/ManagementServiceImpl.java
trunk/src/main/org/jboss/messaging/core/management/impl/ReplicationOperationInvokerImpl.java
trunk/src/schemas/jbm-configuration.xsd
trunk/tests/config/ConfigurationTest-defaults.xml
trunk/tests/jms-tests/src/org/jboss/test/messaging/jms/ConnectionTest.java
trunk/tests/src/org/jboss/messaging/tests/integration/cluster/failover/FailBackupServerTest.java
Log:
some tweaks + docs
Modified: trunk/docs/user-manual/en/diagrams/architecture-diagrams.odg
===================================================================
(Binary files differ)
Modified: trunk/docs/user-manual/en/modules/architecture.xml
===================================================================
--- trunk/docs/user-manual/en/modules/architecture.xml 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/docs/user-manual/en/modules/architecture.xml 2009-05-12 10:54:14 UTC (rev 6739)
@@ -42,7 +42,9 @@
<para>The server always just deals with core API interactions.</para>
<para>A schematic illustrating this relationship is shown in figure 3.1 below:</para>
<para/>
- <para><inlinegraphic fileref="images/architecture1.jpg" align="center"/></para>
+ <para>
+ <graphic fileref="../images/architecture1.jpg" align="center"/>
+ </para>
<para>Figure 3.1 shows two user applications interacting with a JBoss Mesaging server. User
Application 1 is using the JMS API, while User Application 2 is using the core client
API directly.</para>
@@ -66,7 +68,7 @@
<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
systems or mail systems.</para>
- <para>Problem the most common use of an MDB is to consume messages from a JMS messaging
+ <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>
@@ -77,24 +79,48 @@
is always recommended that this is done via the 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.</para>
- <para>Diagram</para>
+ 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>
+ <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
+ session or entiry beans and Message Driven beans go through the adaptor and not directly
+ to JBoss Messaging.</para>
+ <para>The large arrow with the prohibited sign shows an EJB session bean talking directly to
+ the JBoss Messaging server. This is not recommended as you'll most likely end up
+ creating a new connection and session every time you want to interact from the EJB,
+ which is an anti-pattern.</para>
+ <para/>
+ <para>
+ <graphic fileref="../images/architecture2.jpg"/>
+ </para>
</section>
<section>
<title>JBoss Messaging stand-alone server</title>
<para>JBoss Messaging can also be deployed as a stand-alone server. This means a fully
independent messaging server not dependent on a JEE application server.</para>
<para>The standard stand-alone messaging server configuration comprises a core messaging
- server, plus a JMS server manager service which allows JMS connection factorys, Queues
- and Topics to be deployed from xml configuration on the server side, and also a JNDI
- service.</para>
- <para>We choose to include these in the standard stand-alone config since JMS and JNDI are
- often requirements in many deployments. If JNDI or JMS is not required then these
- services can easily be disabled in the configuration.</para>
+ 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>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>
<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>
- <para>The stand-alone server architecture is shown in figure X<inlinegraphic
- fileref="../diagrams/architecture-diagram3.jpg"/></para>
+ <para>[TODO] need to add mbean server, jndi server etc to diagram</para>
+ <para>The stand-alone server architecture is shown in figure 3.3 below:</para>
+ <para/>
+ <para>
+ <graphic fileref="../images/architecture3.jpg"/>
+ </para>
</section>
</chapter>
Modified: trunk/docs/user-manual/en/modules/using-core.xml
===================================================================
--- trunk/docs/user-manual/en/modules/using-core.xml 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/docs/user-manual/en/modules/using-core.xml 2009-05-12 10:54:14 UTC (rev 6739)
@@ -1,11 +1,41 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="using-core">
<title>Using Core</title>
- <para>Blah</para>
+ <para>JBoss Messaging core is a completely JMS agnostic messaging system with its own core API.</para>
+ <para>If you don't want to use JMS you can use the core API directly. The core API provides all the functionality of JMS but without
+ much of the complications. It also provides features that are not normally available using JMS.</para>
<section>
- <title>Simple Core Example</title>
+ <title>Core Messaging Concepts</title>
+ <para>Some of the core messaging concepts are similar to JMS concepts, but Core messaging concepts differ in some ways.</para>
+ <para>In core, there is no concept of a Topic, Topic is a JMS only term. Instead, in core, we just deal with <emphasis>addresses</emphasis>
+ and <emphasis>queues</emphasis>.</para>
+ <para>Queues can de durable, meaning they survive a server crash or restart, as long as the messages in them are durable. Non durable queues
+ do not survive a server restart or crash even if the messages they contain are durable.</para>
+ <para>Queues can also be temporary, meaning they are automatically deleted when the client connection is closed, if they are not explicitly
+ deleted before that.</para>
+ <para>Messages can durable or non durable. Durable messages in a durable queue will survive a server crash or restart. Non durable messages
+ will never survive a server crash or restart.</para>
+ <para>Clients use <literal>ClientSessionFactory</literal> instances to create <literal>ClientSession</literal> instances. <literal>ClientSessionFactory</literal>
+ instances know how to connect to the server to create sessions.</para>
+ <para>Clients create <literal>ClientProducer</literal> instances on <literal>ClientSession</literal> instances so they can send
+ messages.</para>
+ <para>Messages are sent to <literal>addresses</literal>. When the message arrives on the server the server routes it to zero or more
+ queues depending on the address. Many queues can be bound to a particular address on the server. The server will route the message
+ to all queues bound to that address.</para>
+ <para>For example, a JMS topic would implemented by a single address to which many queues are bound. Each queue represents a subscription of the topic. A JMS
+ Queue would be implemented as a single address to which one queue is bound - that queue represents the JMS queue.</para>
+ <para>Queues can be bound with an optional filter expression. If a filter expression is supplied then the server will only route messages
+ who match that filter expression to any queues bound to the address.</para>
+ <para>Clients use <literal>ClientConsumer</literal> instances to consume messages from a queue. Core Messaging supports both synchronous
+ and asynchronous message consumption semantics. <literal>ClientConsumer</literal> instances can be configured with an optional
+ filter expression and will only consume messages which match that expression.</para>
+ <para>Core Messaging also fully supports both local and XA transactional semantics.</para>
+ </section>
+ <section>
+ <title>A simpe example of using Core</title>
<para></para>
</section>
+
</chapter>
Modified: trunk/docs/user-manual/en/modules/using-jms.xml
===================================================================
--- trunk/docs/user-manual/en/modules/using-jms.xml 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/docs/user-manual/en/modules/using-jms.xml 2009-05-12 10:54:14 UTC (rev 6739)
@@ -1,22 +1,150 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="using-jms">
<title>Using JMS</title>
- <para>blah</para>
+ <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>
+ <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>
+ <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>
<section>
- <title>JMS Configuration</title>
+ <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 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 restart or crash. We also want to predeploy the
+ queue, i.e. specifiy the queue in the server JMS config so it's created automatically without us having to explicitly create it
+ from the client.</para>
<para></para>
</section>
+
<section>
- <title>Deploying JMS Administered Objects</title>
- <para></para>
- </section>
+ <title>JMS Server Configuration</title>
+ <para>The file <literal>jbm-jms.xml</literal> on the server classpath contains any JMS Queue, Topic and ConnectionFactory instances
+ that we wish to pre-deploy into the JNDI server so we can look them up.</para>
+ <para>A JMS ConnectionFactory object is used by the client to make connections to the server. It knows the location of the server
+ it is connecting to, as well as many other configuration parameters. In most cases the defaults will be acceptable.</para>
+ <para>We'll deploy a single JMS Queue and a single JMS Connection Factory instance on the server for this example but there
+ are no limits to the number of Queues, Topics and Connection Factory instances you can deploy from the file. Here's our config:</para>
+ <programlisting>
+<configuration xmlns="urn:jboss:messaging"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="urn:jboss:messaging ../schemas/jbm-jms.xsd ">
+
+ <connection-factory name="ConnectionFactory">
+ <connector-ref connector-name="netty"/>
+ <entries>
+ <entry name="ConnectionFactory"/>
+ </entries>
+ </connection-factory>
+
+ <queue name="OrderQueue">
+ <entry name="queues/OrderQueue"/>
+ </queue>
+
+</configuration>
+ </programlisting>
+ <para>We deploy one ConnectionFactory called <literal>ConnectionFactory</literal> and bind it in just one place in JNDI as given by
+ the <literal>entry</literal> element. ConnectionFactory instances can be bound in many places in JNDI if you require.
+ </para>
+ <para>Note that the JMS connection factory references a <literal>connector</literal> called <literal>netty</literal>. This is
+ a reference to a connector object deployed in the main core configuration file <literal>jbm-configuration.xml</literal> which
+ defines the transport and parameters used to actually connect to the server.</para>
+ </section>
<section>
- <title>Using JNDI</title>
- <para></para>
+ <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>
+ <para>For talking to the JBoss JNDI Server, the jndi properties will look something like this:</para>
+ <programlisting>
+java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
+java.naming.provider.url=jnp://myhost:1099
+java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
+ </programlisting>
+ <para>Where <literal>myhost</literal> is the hostname or IP address of the JNDI server. 1099 is the port used by the JNDI server
+ and may vary depending on how you have configured your JNDI server.</para>
+ <para>In the default standalone configuration, JNDI server ports are configured in the <literal>jbm-jboss-beans.xml</literal>
+ file where the JNDIServer bean is confgured, here's a snippet from the file:</para>
+ <programlisting>
+<bean name="JNDIServer" class="org.jnp.server.Main">
+ <property name="namingInfo">
+ <inject bean="Naming"/>
+ </property>
+ <property name="port">1099</property>
+ <property name="bindAddress">localhost</property>
+ <property name="rmiPort">1098</property>
+ <property name="rmiBindAddress">localhost</property>
+</bean>
+ </programlisting>
+ <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>
</section>
<section>
- <title>Directly instantiating JMS Administered Objects</title>
- <para></para>
+ <title>The code</title>
+ <para>Here's the code for the example:</para>
+ <para>First we'll create a JNDI initial context from which to lookup our JMS objects:</para>
+ <programlisting>InitialContect ic = new InitialContext();</programlisting>
+ <para>Now we'll look up the connection factory:</para>
+ <programlisting>ConnectionFactory cf = (ConnectionFactory)ic.lookup("/ConnectionFactory");</programlisting>
+ <para>And look up the Queue:</para>
+ <programlisting>Queue orderQueue = (Queue)ic.lookup("/queues/OrderQueue");</programlisting>
+ <para>Next we create a JMS connection using the connection factory:</para>
+ <programlisting>Connection connection = cf.createConnection();</programlisting>
+ <para>And we create a non transacted JMS Session, with AUTO_ACKNOWLEDGE acknowledge mode:</para>
+ <programlisting>Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);</programlisting>
+ <para>We create a MessageProducer that will send orders to the queue:</para>
+ <programlisting>MessageProducer producer = session.createProducer(orderQueue);</programlisting>
+ <para>And we create a MessageConsumer which will consume orders from the queue:</para>
+ <programlisting>MessageConsumer consumer = session.createConsumer(orderQueue);</programlisting>
+ <para>We make sure we start the connection, or delivery won't occur on it:</para>
+ <programlisting>connection.start();</programlisting>
+ <para>We create a simple TextMessage and send it:</para>
+ <programlisting>TextMessage message = session.createTextMessage("This is an order");
+producer.send(message);</programlisting>
+ <para>And we consume the message:</para>
+ <programlisting>TextMessage receivedMessage = (TextMessage)consumer.receive();
+System.out.println("Got order: " + receivedMessage.getText());
+ </programlisting>
+ <para>It's as simple as that. For a wide range of working JMS examples please see the examples directory in the distribution.</para>
+ </section>
+ <section>
+ <title>Directly instantiating JMS Queue, Topic and ConnectionFactory instances without using JNDI</title>
+ <para>Although it's a very common JMS usage pattern to lookup JMS <emphasis>Administered Objects</emphasis> (that's
+ JMS Queues, Topics and Connection Factories) from JNDI, in some cases a JNDI server is not available and you still want to
+ use JMS, or you just think "Why do I need JNDI? Why can't I just instantiate these objects directly?"</para>
+ <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>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>
+ <programlisting>
+TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName());
+ConnectionFactory cf = new JBossConnectionFactory();
+ </programlisting>
+ <para>We create the JMS Queue Object directly:</para>
+ <programlisting>Queue orderQueue = new JBossQueue("OrderQueue");</programlisting>
+ <para>Next we create a JMS connection using the connection factory:</para>
+ <programlisting>Connection connection = cf.createConnection();</programlisting>
+ <para>And we create a non transacted JMS Session, with AUTO_ACKNOWLEDGE acknowledge mode:</para>
+ <programlisting>Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);</programlisting>
+ <para>We create a MessageProducer that will send orders to the queue:</para>
+ <programlisting>MessageProducer producer = session.createProducer(orderQueue);</programlisting>
+ <para>And we create a MessageConsumer which will consume orders from the queue:</para>
+ <programlisting>MessageConsumer consumer = session.createConsumer(orderQueue);</programlisting>
+ <para>We make sure we start the connection, or delivery won't occur on it:</para>
+ <programlisting>connection.start();</programlisting>
+ <para>We create a simple TextMessage and send it:</para>
+ <programlisting>TextMessage message = session.createTextMessage("This is an order");
+ producer.send(message);</programlisting>
+ <para>And we consume the message:</para>
+ <programlisting>TextMessage receivedMessage = (TextMessage)consumer.receive();
+ System.out.println("Got order: " + receivedMessage.getText());
+ </programlisting>
+
</section>
</chapter>
Modified: trunk/docs/user-manual/en/modules/using-server.xml
===================================================================
--- trunk/docs/user-manual/en/modules/using-server.xml 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/docs/user-manual/en/modules/using-server.xml 2009-05-12 10:54:14 UTC (rev 6739)
@@ -1,24 +1,275 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="using-server">
<title>Using the Server</title>
- <para>blah</para>
+ <para>In this chapter you'll get familiar with the JBoss Messaging server.</para>
+ <para>We'll show where it is, how to start and stop it, and we'll describe the directory layout
+ and what all the files are and what they do.</para>
+ <para>For the remainder of this chapter when we talk about the JBoss Messaging server we mean
+ 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>
<section>
- <title>Server directoy layout</title>
- <para></para>
+ <title>Starting and Stopping the standalone server</title>
+ <para>In the distribution you will find a directory called <literal>bin</literal>.</para>
+ <para><literal>cd</literal> into that directory and you'll find a unix/linux script called
+ <literal>run.sh</literal> and a windows batch file called <literal
+ >run.bat</literal></para>
+ <para>To run on Unix/Linux type <literal>./run.sh</literal></para>
+ <para>To run on Windows type <literal>run.bat</literal></para>
+ <para>This scripts are very simple and basically just set-up the classpath and some JVM
+ parameters, and call the JBM bootstrap class as the Main class. The bootstrap is special
+ JBoss Microcontainer class which causes the JBoss Microcontainer to start-up.</para>
+ <para>Please note that JBoss Messaging requires a Java 5 or later JDK to run. We recommend
+ running on Java 6.</para>
</section>
<section>
- <title>Configuration files</title>
- <para></para>
+ <title>Server JVM settings</title>
+ <para>The run scripts <literal>run.sh</literal> and <literal>run.bat</literal> set some JVM
+ settings for tuning running on Java 6 and choosing the garbage collection policy. We
+ recommend using a parallel garbage collection algorithm to smooth out latency and
+ minmises large GC pauses.</para>
+ <para>By default JBoss Messaging runs in a maximum of 1GB of RAM. To increase the memory
+ settings change the <literal>-Xms</literal> and <literal>-Xmx</literal> memory settings
+ as you would for any Java program.</para>
+ <para>If you wish to add any more JVM arguments or tune the existing ones, the run scripts
+ are the place to do it.</para>
</section>
<section>
- <title>Starting and stopping the server</title>
- <para></para>
+ <title>Server classpath</title>
+ <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
+ 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>
+ <itemizedlist>
+ <listitem>
+ <para>Non clustered stand-alone.</para>
+ </listitem>
+ <listitem>
+ <para>Clustered stand-alone</para>
+ </listitem>
+ <listitem>
+ <para>Non clustered in JBoss Application Server</para>
+ </listitem>
+ <listitem>
+ <para>Clustered in JBoss Application Server</para>
+ </listitem>
+ </itemizedlist>
+ <para>You can of course create your own configuration and specify any configuration
+ directory when running the run script.</para>
+ <para>Just make sure the directory is on the classpath and JBoss Messaging will search there
+ when starting up.</para>
+ <para>The run scripts also add the location for the various XML schema definition files (xsd
+ files) used by JBoss Messaging to describe its configuration files. By default these are
+ located in <literal>schemas</literal> directory from the root of the
+ distribution.</para>
</section>
<section>
- <title>Server JVM settings</title>
- <para></para>
+ <title>System properties</title>
+ <para>JBoss Messaging also takes a couple of Java system properties on the command line for
+ configuring logging properties</para>
+ <para>JBoss Messaging uses JDK logging to minmise dependencies on other logging systems. JDK
+ logging can then be configured to delegate to some other framework, e.g. log4j if that's
+ what you prefer.</para>
+ <para>For more information on configuring logging, please see the section configuring
+ logging</para>
</section>
-
-
-
+ <section>
+ <title>Configuration files</title>
+ <para>The configuration directory is specified on the classpath in the run scripts <literal
+ >run.sh</literal> and <literal>run.bat</literal> This directory can contain the
+ following files.</para>
+ <itemizedlist>
+ <listitem>
+ <para><literal>jbm-jboss-beans.xml</literal>. This is the JBoss Microcontainer beans
+ file which instructs it what beans to create and what dependencies to enforce
+ between them. Remember that JBoss Messaging is just a set of POJOs. In the
+ stand-alone server, it's the JBoss Microcontainer which instantiates these POJOs
+ and enforces dependencies between them and other beans. Please see the <xref
+ linkend="usingserver.mainconfig"/> section for more information on this
+ file.</para>
+ </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>
+ </listitem>
+ <listitem>
+ <para><literal>jbm-queues.xml</literal>. This file contains pre-defined queues,
+ queue settings and security settings. The file is optional - all this
+ configuration can also live in <literal>jbm-configuration.xml</literal>. In
+ fact, the default configuration sets do not have a <literal
+ >jbm.queues.xml</literal> file. The purpose of allowing queues to be
+ 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>
+ </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>
+ </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>
+ </listitem>
+ <listitem>
+ <para><literal>logging.properties</literal></para>
+ </listitem>
+ <listitem>
+ <para><literal>log4j.xml</literal></para>
+ </listitem>
+ </itemizedlist>
+ </section>
+ <section>
+ <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>
+ <para>Also when running JBoss Messaging in JBoss Application Server, a beans file is also
+ required since JBoss Application Server version 5 or later is basically just an instance
+ of JBoss Microcontainer with various different services running in it.</para>
+ <para>The beans file is what tells JBoss Microcontainer which POJOs to instantiate and what
+ their dependencies are. The beans files used when running in JBoss Messaging stand-alone
+ and when running in JBoss Application Server are slightly different, mainly due to the
+ security manager being used.</para>
+ <para>Let's take a look at an example beans file from the stand-alone server:</para>
+ <para>
+ <programlisting>
+ <?xml version="1.0" encoding="UTF-8"?>
+
+ <deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+ <bean name="Naming" class="org.jnp.server.NamingBeanImpl"/>
+
+ <!-- JNDI server. Disable this if you don't want JNDI -->
+ <bean name="JNDIServer" class="org.jnp.server.Main">
+ <property name="namingInfo">
+ <inject bean="Naming"/>
+ </property>
+ <property name="port">1099</property>
+ <property name="bindAddress">localhost</property>
+ <property name="rmiPort">1098</property>
+ <property name="rmiBindAddress">localhost</property>
+ </bean>
+
+ <!-- MBean server -->
+ <bean name="MBeanServer" class="javax.management.MBeanServer">
+ <constructor factoryClass="java.lang.management.ManagementFactory"
+ factoryMethod="getPlatformMBeanServer"/>
+ </bean>
+
+ <!-- The core configuration -->
+ <bean name="Configuration" class="org.jboss.messaging.core.config.impl.FileConfiguration">
+ </bean>
+
+ <!-- The security manager -->
+ <bean name="JBMSecurityManager" class="org.jboss.messaging.core.security.impl.JBMSecurityManagerImpl">
+ <start ignored="true"/>
+ <stop ignored="true"/>
+ </bean>
+
+ <!-- The core server -->
+ <bean name="MessagingServer" class="org.jboss.messaging.core.server.impl.MessagingServerImpl">
+ <start ignored="true"/>
+ <stop ignored="true"/>
+ <constructor>
+ <parameter>
+ <inject bean="Configuration"/>
+ </parameter>
+ <parameter>
+ <inject bean="MBeanServer"/>
+ </parameter>
+ <parameter>
+ <inject bean="JBMSecurityManager"/>
+ </parameter>
+ </constructor>
+ </bean>
+
+ <!-- The JMS server -->
+ <bean name="JMSServerManager" class="org.jboss.messaging.jms.server.impl.JMSServerManagerImpl">
+ <constructor>
+ <parameter>
+ <inject bean="MessagingServer"/>
+ </parameter>
+ </constructor>
+ </bean>
+
+ </deployment>
+
+ </programlisting>
+ </para>
+ <para>We can see that, as well as the core JBoss Messaging server, the stand-alone server
+ instantiates various different POJOs, lets look at them in turn:</para>
+ <itemizedlist>
+ <listitem>
+ <para>JNDIServer</para>
+ <para>Many clients like to look up JMS Objects from JNDI so we provide a JNDI server
+ for them to do that. If you don't need JNDI this can be commented out or
+ removed.</para>
+ </listitem>
+ <listitem>
+ <para>MBeanServer</para>
+ <para>In order to provide a JMX management interface a JMS MBean server is necessary
+ in which to register the management objects. Normally this is just the default
+ platform MBean Server available in the JVM instance. If you don't want to
+ provide a JMX management interface this can be commented out or removed.</para>
+ </listitem>
+ <listitem>
+ <para>Configuration</para>
+ <para>The messaging server is configured with a Configuration object. In the default
+ stand-alone set-up it uses a FileConfiguration object which knows to read
+ configuration information from the file system. In different configurations such
+ as embedded you might want to provide configuration information from somewhere
+ else.</para>
+ </listitem>
+ <listitem>
+ <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
+ configure to use the JBoss AS security manager for tight integration with JBoss
+ AS security.</para>
+ </listitem>
+ <listitem>
+ <para>MessagingServer</para>
+ <para>This is the JMS agnostic core server. It's where 99% of the magic
+ happens</para>
+ </listitem>
+ <listitem>
+ <para>JMSServerManager</para>
+ <para>This deploys any JMS Objects such as JMS Queues, Topics and ConnectionFactory
+ instances from <literal>jbm-jms.xml</literal> files on the disk. It also
+ provides a simple management API for manipulating JMS Objects. On the whole it
+ just translates and delegates its work to the core server. If you don't need to
+ deploy JMS Queues, Topics and ConnectionFactorys from server side config and
+ don't require the JMS management interface this can be disabled.</para>
+ </listitem>
+ </itemizedlist>
+ </section>
+ <section id="usingserver.mainconfig">
+ <title>The main configuration file.</title>
+ <para>The configuration for the JBoss Messaging core server is contained in <literal
+ >jbm-configuration.xml</literal>. This is what the FileConfiguration bean uses to
+ configure the messaging server.</para>
+ <para>There are many attributes which which you can configure JBoss Messaging. In most cases
+ the defaults will do fine, in fact every attribute can be defaulted which means a file
+ with a single empty <literal>configuration</literal> element is a valid configuration
+ file.</para>
+ <para>We'll take a look at an example <literal>jbm-configuration.xml</literal> file where
+ all attributes have been specified, and we'll give a brief explanation of each with a
+ link to the appropriate section for its related concepts.</para>
+ <para>Note that in any real example you'd rarely have to explicitly specify each attribute
+ value.</para>
+ <para>TODO jbm configuration file and explanation.</para>
+ </section>
</chapter>
Modified: trunk/src/bin/run.bat
===================================================================
--- trunk/src/bin/run.bat 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/src/bin/run.bat 2009-05-12 10:54:14 UTC (rev 6739)
@@ -3,7 +3,7 @@
set JBM_HOME=..
set CONFIG_DIR=%JBM_HOME%\config\stand-alone\non-clustered
set CLASSPATH=%CONFIG_DIR%;%JBM_HOME%\schemas\
-set JVM_ARGS=-XX:+UseParallelGC -Xms512M -Xmx1024M -Djava.util.logging.config.file=%CONFIG_DIR%\logging.properties -Dorg.jboss.logging.Logger.pluginClass=org.jboss.messaging.core.logging.JBMLoggerPlugin -Djava.library.path=.
+set JVM_ARGS=-XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M -Xmx1024M -Djava.util.logging.config.file=%CONFIG_DIR%\logging.properties -Dorg.jboss.logging.Logger.pluginClass=org.jboss.messaging.core.logging.JBMLoggerPlugin -Djava.library.path=.
REM export JVM_ARGS="-Xmx512M -Djava.util.logging.config.file=%CONFIG_DIR%\config\logging.properties -Dorg.jboss.logging.Logger.pluginClass=org.jboss.messaging.core.logging.JBMLoggerPlugin -Djava.library.path=. -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
for /R ..\lib %%A in (*.jar) do (
SET CLASSPATH=!CLASSPATH!;%%A
Modified: trunk/src/bin/run.sh
===================================================================
--- trunk/src/bin/run.sh 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/src/bin/run.sh 2009-05-12 10:54:14 UTC (rev 6739)
@@ -6,7 +6,7 @@
if [ a"$2" = a ]; then FILENAME=jbm-standalone-beans.xml; else FILENAME="$2"; fi
export CLASSPATH=$CONFIG_DIR:$JBM_HOME/schemas/
-export JVM_ARGS="-XX:+UseParallelGC -Xms512M -Xmx1024M -Djava.util.logging.config.file=$CONFIG_DIR/logging.properties -Dorg.jboss.logging.Logger.pluginClass=org.jboss.messaging.integration.logging.JBMLoggerPlugin -Djava.library.path=."
+export JVM_ARGS="-XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M -Xmx1024M -Djava.util.logging.config.file=$CONFIG_DIR/logging.properties -Dorg.jboss.logging.Logger.pluginClass=org.jboss.messaging.integration.logging.JBMLoggerPlugin -Djava.library.path=."
#export JVM_ARGS="-Xmx512M -Djava.util.logging.config.file=$CONFIG_DIR/logging.properties -Dorg.jboss.logging.Logger.pluginClass=org.jboss.messaging.integration.logging.JBMLoggerPlugin -Djava.library.path=. -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
for i in `ls $JBM_HOME/lib/*.jar`; do
Modified: trunk/src/config/stand-alone/non-clustered/jbm-standalone-beans.xml
===================================================================
--- trunk/src/config/stand-alone/non-clustered/jbm-standalone-beans.xml 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/src/config/stand-alone/non-clustered/jbm-standalone-beans.xml 2009-05-12 10:54:14 UTC (rev 6739)
@@ -33,7 +33,7 @@
<!-- The core server -->
<bean name="MessagingServer" class="org.jboss.messaging.core.server.impl.MessagingServerImpl">
- <start ignored="true"/>
+ <start ignored="true"/>
<stop ignored="true"/>
<constructor>
<parameter>
Modified: trunk/src/main/org/jboss/messaging/core/config/impl/ConfigurationImpl.java
===================================================================
--- trunk/src/main/org/jboss/messaging/core/config/impl/ConfigurationImpl.java 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/src/main/org/jboss/messaging/core/config/impl/ConfigurationImpl.java 2009-05-12 10:54:14 UTC (rev 6739)
@@ -77,8 +77,6 @@
public static final String DEFAULT_PAGING_DIR = "data/paging";
- public static final int DEFAULT_PAGE_MAX_THREADS = 10;
-
public static final int DEFAULT_PAGE_WATERMARK_SIZE = 10 * 1024 * 1024;
public static final long DEFAULT_PAGE_MAX_GLOBAL_SIZE = -1;
@@ -95,11 +93,11 @@
public static final int DEFAULT_JOURNAL_FILE_SIZE = 10485760;
- public static final int DEFAULT_JOURNAL_MIN_FILES = 10;
+ public static final int DEFAULT_JOURNAL_MIN_FILES = 2;
public static final int DEFAULT_JOURNAL_MAX_AIO = 5000;
- public static final int DEFAULT_JOURNAL_REUSE_BUFFER_SIZE = -1;
+ public static final int DEFAULT_JOURNAL_REUSE_BUFFER_SIZE = 1024;
public static final boolean DEFAULT_WILDCARD_ROUTING_ENABLED = true;
Modified: trunk/src/main/org/jboss/messaging/core/management/impl/ManagementServiceImpl.java
===================================================================
--- trunk/src/main/org/jboss/messaging/core/management/impl/ManagementServiceImpl.java 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/src/main/org/jboss/messaging/core/management/impl/ManagementServiceImpl.java 2009-05-12 10:54:14 UTC (rev 6739)
@@ -512,11 +512,6 @@
return managementClusterPassword;
}
- public long getManagementRequestTimeout()
- {
- return managementRequestTimeout;
- }
-
public ReplicationOperationInvoker getReplicationOperationInvoker()
{
return replicationInvoker;
Modified: trunk/src/main/org/jboss/messaging/core/management/impl/ReplicationOperationInvokerImpl.java
===================================================================
--- trunk/src/main/org/jboss/messaging/core/management/impl/ReplicationOperationInvokerImpl.java 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/src/main/org/jboss/messaging/core/management/impl/ReplicationOperationInvokerImpl.java 2009-05-12 10:54:14 UTC (rev 6739)
@@ -24,8 +24,6 @@
import static org.jboss.messaging.core.security.impl.SecurityStoreImpl.CLUSTER_ADMIN_USER;
-import javax.management.ObjectName;
-
import org.jboss.messaging.core.client.ClientMessage;
import org.jboss.messaging.core.client.ClientRequestor;
import org.jboss.messaging.core.client.ClientSession;
Modified: trunk/src/schemas/jbm-configuration.xsd
===================================================================
--- trunk/src/schemas/jbm-configuration.xsd 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/src/schemas/jbm-configuration.xsd 2009-05-12 10:54:14 UTC (rev 6739)
@@ -126,7 +126,7 @@
</xsd:sequence>
</xsd:complexType>
</xsd:element>
- <xsd:element name="acceptors" maxOccurs="1" minOccurs="1">
+ <xsd:element name="acceptors" maxOccurs="1" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="acceptor" type="acceptorType"
Modified: trunk/tests/config/ConfigurationTest-defaults.xml
===================================================================
--- trunk/tests/config/ConfigurationTest-defaults.xml 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/tests/config/ConfigurationTest-defaults.xml 2009-05-12 10:54:14 UTC (rev 6739)
@@ -1,11 +1,5 @@
<deployment xmlns="urn:jboss:messaging" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:messaging ../../src/schemas/jbm-configuration.xsd ">
<configuration>
- <!-- just use all the defaults -->
- <!-- we must declare at least one acceptor to have a valid configuration -->
- <acceptors>
- <acceptor>
- <factory-class>org.jboss.messaging.core.remoting.impl.invm.InVMAcceptorFactory</factory-class>
- </acceptor>
- </acceptors>
+ <!-- just use all the defaults -->
</configuration>
</deployment>
\ No newline at end of file
Modified: trunk/tests/jms-tests/src/org/jboss/test/messaging/jms/ConnectionTest.java
===================================================================
--- trunk/tests/jms-tests/src/org/jboss/test/messaging/jms/ConnectionTest.java 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/tests/jms-tests/src/org/jboss/test/messaging/jms/ConnectionTest.java 2009-05-12 10:54:14 UTC (rev 6739)
@@ -274,12 +274,12 @@
* This needs to be run remotely to see the exception
*/
-// This test is currently commented out until we fix netty issue https://jira.jboss.org/jira/browse/JBMESSAGING-1618
+ // This test is currently commented out until we fix netty issue https://jira.jboss.org/jira/browse/JBMESSAGING-1618
// public void testConnectionListenerBug() throws Exception
// {
-// for (int i = 0; i < 1000; i++)
+// for (int i = 0; i < 10000; i++)
// {
-// log.info("********************************************");
+// //log.info("******************************************** it " + i);
//
// Connection conn = cf.createConnection();
//
@@ -287,12 +287,7 @@
//
// conn.setExceptionListener(listener);
//
-// conn.close();
-//
-// //The problem with this test is I would need to capture the output and search
-// //for NullPointerException!!!
-//
-// //Thread.sleep(100);
+// conn.close();
// }
// }
Modified: trunk/tests/src/org/jboss/messaging/tests/integration/cluster/failover/FailBackupServerTest.java
===================================================================
--- trunk/tests/src/org/jboss/messaging/tests/integration/cluster/failover/FailBackupServerTest.java 2009-05-12 09:25:13 UTC (rev 6738)
+++ trunk/tests/src/org/jboss/messaging/tests/integration/cluster/failover/FailBackupServerTest.java 2009-05-12 10:54:14 UTC (rev 6739)
@@ -80,7 +80,7 @@
public void testFailBackup() throws Exception
{
- for (int j = 0; j < 5; j++)
+ for (int j = 0; j < 1000; j++)
{
ClientSessionFactoryInternal sf1 = new ClientSessionFactoryImpl(new TransportConfiguration("org.jboss.messaging.core.remoting.impl.invm.InVMConnectorFactory"),
new TransportConfiguration("org.jboss.messaging.core.remoting.impl.invm.InVMConnectorFactory",
More information about the jboss-cvs-commits
mailing list