User: mulder
Date: 00/09/19 07:28:37
Modified: manual adv_config.html config.html deploying.html
developing.html index.html install.html jms.html
warning.html
Log:
Add deploying section, and all I know about SpyderMQ (not much)
Revision Changes Path
1.4 +1 -1 jbossweb/manual/adv_config.html
Index: adv_config.html
===================================================================
RCS file: /products/cvs/ejboss/jbossweb/manual/adv_config.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- adv_config.html 2000/09/16 12:34:16 1.3
+++ adv_config.html 2000/09/19 14:28:35 1.4
@@ -8,7 +8,7 @@
<p>This section describes the configuration changes you might need
to make to support your application. It is still not
comprehensive, though. The final authority on what's possible
- is the <a HREF="dtds">DTD Section</a> in the Appendix.</p>
+ is the <a HREF="dtds.html">DTD Section</a> in the Appendix.</p>
<h2><a NAME="datasources">Data Sources</a></h2>
<p>One of the most common requirements is to create one or more
1.3 +3 -2 jbossweb/manual/config.html
Index: config.html
===================================================================
RCS file: /products/cvs/ejboss/jbossweb/manual/config.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- config.html 2000/09/15 00:59:54 1.2
+++ config.html 2000/09/19 14:28:35 1.3
@@ -39,8 +39,9 @@
classpath. Again, this should only be used for libraries which
need to be available to all EJBs; there are alternatives for
libraries that should be available to individual EJB JARs
- (see <a HREF="BROKENLINK">The Manifest File</a> in the
- Deploying section).</p>
+ (see <a HREF="deploying.html#manifest">The Manifest File</a> in
+ the <a HREF="deploying.html">Deploying EJBs in jBoss</a>
+ section).</p>
<h3><a NAME="ejbs">EJBs</a></h3>
<p>EJB JARs you want to deploy go in the <strong>deploy</strong>
1.2 +270 -0 jbossweb/manual/deploying.html
Index: deploying.html
===================================================================
RCS file: /products/cvs/ejboss/jbossweb/manual/deploying.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- deploying.html 2000/09/14 18:28:35 1.1
+++ deploying.html 2000/09/19 14:28:35 1.2
@@ -5,5 +5,275 @@
</head>
<body>
<h1 ALIGN="CENTER">jBoss 2.0: Deploying EJBs in jBoss</h1>
+ <p>In order to make an EJB available through jBoss, you need to
+ package it into a JAR file, and then put that JAR file in the
+ <strong>deploy</strong> directory. This section has the details
+ on what needs to go into the JAR file, how to prepare it, what to
+ do if something goes wrong, and some advanced deployment
+ topics.</p>
+
+ <h2><a NAME="preparing">Preparing Your EJB JAR</a></h2>
+ <p>The first question you need to answer is how you want to
+ package multiple EJBs. You can package them all separately,
+ with one JAR file per bean, or you can package them all
+ together, with one JAR file per "application." Both approaches
+ have their advantages.</p>
+ <p>If you package all your beans together, any EJB-EJB references
+ will perform faster since the server gathers them all together
+ into one application. You'll save a little work on the
+ configuration since there are a number of settings that you
+ must make once per JAR. The packaging process is simpler since
+ you just include all your classes in one JAR. But if you unload
+ one bean, you unload them all. Additionally, you cannot deploy
+ individual beans within one EJB JAR - when you deploy the JAR, all
+ EJBs in the JAR are deployed.</p>
+ <p>The advantage to packaging everything separately is that you have
+ finer-grained control; You can update individual EJBs while
+ leaving the rest running. But this is definitely more complex to
+ configure and deploy.</p>
+
+ <h3><a NAME="classes">Required Classes</a></h3>
+ <p>The JAR file for an EJB requires all the EJB classes and
+ interfaces, plus any other required classes that are not available
+ on the server classpath. Any JARs or ZIPs in the
+ <strong>lib</strong> or <strong>lib/ext</strong> directories
+ are available on the server classpath. But other EJB JARs are
+ <em>not</em> available on the server classpath. So if your EJB
+ uses any helper or utility classes, those are probably required.
+ If your EJB uses another EJB <em>that is not packaged in the same
+ JAR</em>, then you need to package the Home and Remote interfaces
+ (and Primary Key, for entities) of the other EJB in the current
+ JAR. You do not need the implementation class for the other EJB,
+ or any helper or utility classes it uses, unless they are used in
+ the home or remote interfaces or primary key class.</p>
+
+ <h3><a NAME="descriptors">Deployment Descriptors</a></h3>
+ <p>In addition to the EJB classes, you need one or more deployment
+ descriptors. In previous versions of the EJB specification, this
+ was often a serialized Java class, with other vendor-specific
+ files or classes. In the EJB 1.1 specification, the EJB
+ deployment descriptor is an XML file. Any vendor-specific
+ extensions may use any format, but in the case of jBoss, they are
+ also XML files. So to deploy in jBoss, you need the one standard
+ EJB 1.1 deployment descriptor, and then up to two other
+ jBoss-specific XML deployment descriptors, depending on the
+ type of EJB and the features it will use.</p>
+ <p>The three possible deployment descriptors are described next.
+ If you need specific details, you can refer to the
+ <a HREF="dtds.html">DTDs</a> section in the Appendix.</p>
+
+
+ <h4><a NAME="ejb11">The EJB 1.1 Deployment Descriptor</a></h4>
+ <p>The EJB 1.1 Deployment Descriptor (<code>ejb-jar.xml</code>)
+ declares your EJBs. It indicates what the various classes are
+ (home + remote interfaces, primary key, implementation class). It
+ defines any environment settings, EJB references, and data source
+ references. It defines security and transaction settings for each
+ bean or method. It gives each bean a name, which becomes the
+ default JNDI name for the bean. For each CMP Entity Bean, it lists
+ which fields are container-managed persistent fields. All of this
+ information should be the same no matter what EJB server you
+ deploy in.</p>
+
+ <h4><a NAME="jboss">The jBoss Deployment Descriptor</a></h4>
+ <p>The jBoss Deployment Descriptor (<code>jboss.xml</code>) is
+ optional. There are default settings, and you only need to
+ include this file if you want to override the defaults. Further,
+ you only need to include any sections within this file that
+ differ from the defaults, so you do not need a new complete
+ configuration file for every JAR.</p>
+ <p>The jBoss deployment descriptor handle the following
+ settings:</p>
+ <ul>
+ <li>The JNDI name for the EJBs in the JAR</li>
+ <li>Any data sources or other resources used by the EJBs in the
+ JAR</li>
+ <li>The RMI configuration for each EJB in the JAR, which
+ determines the client JDK version compatibility</li>
+ <li>The instance pool characteristics for each EJB in the JAR</li>
+ <li>The transaction manager for each EJB in the JAR</li>
+ <li>The persistence manager for each CMP Entity Bean in the
+ JAR</li>
+ <li>Whether to optimize calls between beans in the same JAR
+ for additional performance</li>
+ <li>Whether to log information on every bean invocation</li>
+ </ul>
+ <p>The structure of this file is broken into container
+ configurations, resource managers, and EJB declarations. All the
+ settings above except the JNDI name and data sources are
+ configured once in a named "container configuration". Then any
+ EJBs declare which container configuration they use, so you can
+ easily use the same configuration for a number of EJBs within the
+ same JAR.</p>
+ <p>You can also set up resource managers for the JAR. The most
+ common resource manager type is JDBC, though there are others
+ available. These resource managers are visible to all EJBs in
+ the JAR, though you must also indicate in the EJB declaration
+ section which EJBs use which resource managers. With JDBC
+ resources, you link the JNDI name of the database pool or pools
+ you set up in the configuration section (see
+ <a HREF="adv_config.html#datasources">Data Sources</a>) to a
+ resource manager name.</p>
+ <p>In the EJB declaration section, you indicate which container
+ configuration each EJB uses. You may also override the default
+ JNDI name for the bean. If you defined any EJB references in the
+ EJB 1.1 deployment descriptor, you define here what the JNDI name
+ of the referenced bean is, so those references can be resolved.
+ If you defined any data source references in the EJB 1.1
+ deployment descriptor, you link the data source reference name
+ from the EJB 1.1 deployment descriptor to a resource manager you
+ configured above for the JAR.</p>
+
+ <h4><a NAME="jaws">The JAWS Deployment Descriptor</a></h4>
+ <p>The JAWS Deployment Descriptor (<code>jaws.xml</code>) is used
+ by the default jBoss Container-Managed Persistence engine. So
+ this file is only used for CMP Entity Beans. Again, there are
+ default settings, and you only need to include this file if you
+ want to override the defaults. Further, you only need to include
+ any sections within this file that differ from the defaults, so
+ you do not need a new complete configuration file for every
+ JAR.</p>
+
+ <p>The JAWS deployment descriptor handles the following
+ settings:</p>
+ <ul>
+ <li>The table to use for each CMP bean</li>
+ <li>The column that each CMP field corresponds to</li>
+ <li>The database product you are using, and how to map
+ JDBC types to native database types</li>
+ <li>Whether the table should be created when the bean is
+ deployed</li>
+ <li>Whether the table should be dropped when the bean is
+ undeployed</li>
+ <li>Whether updates should include only the changed
+ columns or all columns</li>
+ <li>Whether the EJBs should be treated as read-only</li>
+ </ul>
+ <p>The JAWS deployment descriptor is split into two sections.
+ In the first, you provide JDBC to SQL type mappings for your
+ DBMS. In the second, you provide the EJB-specific configuration
+ for each CMP Entity Bean that uses JAWS.</p>
+
+ <h4><a NAME="ejx">Editing Deployment Descriptors with EJX</a></h4>
+ <p>jBoss includes a graphical tool to edit deployment descriptors,
+ called EJX (Enterprise Java XML-editor). You can edit all three
+ types of deployment descriptors with EJX. EJX can either read
+ and write XML files on disk, or read and write XML files in an
+ EJB JAR. We recommend that you package all the required class
+ files into a JAR, and edit the deployment descriptors there, so
+ EJX can validate your entries against the available classes.</p>
+ <p>After you have created your deployment descriptors, you may want
+ to extract them from the JAR so subsequent builds can use the
+ existing deployment descriptors instead of forcing you to go
+ through the entire editing process again. If you only have minor
+ changes to make later, you can edit the file on disk using EJX, or
+ if you're comfortable with XML you can just edit them by hand.</p>
+ <p>You may also want to browse the <a HREF="ejx.html">EJX
+ Walkthrough</a> in the Appendix for a step-by-step overview of
+ creating deployment descriptors in EJX.</p>
+
+ <h4><a NAME="byhand">Editing Deployment Descriptors By Hand</a></h4>
+ <p>If you have an XML editor or text editor, you can simply compose
+ the required deployment descriptors by hand. It's often helpful
+ to get a start in EJX and then tweak the output files as
+ necessary, but you can use whichever method you're most
+ comfortable with. You should refer to the
+ <a HREF="dtds.html">DTDs Section</a> of the Appendix for the
+ exact syntax for deployment descriptors.</p>
+
+ <h3><a NAME="manifest">The Manifest File</a></h3>
+ <p>You don't typically need a custom manifest file for an EJB 1.1
+ JAR. The JAR tool will create a manifest for you, if you don't
+ provide one yourself. One case where you may want a manifest
+ file is to add other JARs to your classpath. You may choose to
+ package utility classes in a separate JAR rather than including
+ them in all the necessary EJB JARs, and adding that separate JAR
+ to the classpath in the manifest file would be the best way to
+ accomplish that.</p>
+
+ <h2><a NAME="deploying">Deploying Your EJB JAR</a></h2>
+ <p>Deploying an EJB JAR in jBoss is simple. Once you have packaged
+ the classes and deployment descriptors in a JAR, copy that JAR to
+ the <strong>deploy</strong> directory. If jBoss is running, it
+ will deploy the JAR automatically. If not, it will deploy the
+ JAR the next time you start it. You can use the management
+ interface (see <a HREF="managing.html">Managing a Live jBoss
+ Server</a>) to manually deploy JARs from different locations, but
+ copying the JARs to the deploy directory is the recommended way to
+ deploy. No matter how you deploy, all the EJBs in an EJB JAR are
+ deployed when you deploy the JAR - you cannot select specific EJBs
+ within the JAR to deploy.</p>
+
+ <h2><a NAME="failures">Deployment Failures</a></h2>
+ <p>There are a number of reasons a deployment might fail, but the
+ most common include leaving required classes out of a JAR, making
+ mistakes in the deployment descriptors, and using the wrong JNDI
+ names in your beans. If the tips here do not help you resolve
+ your deployment problem, see the
+ <a HREF="trouble.html">Troubleshooting</a> section.</p>
+
+ <h3><a NAME="files">Strange File Names</a></h3>
+ <p>You may notice that the jBoss server refers to an EJB JAR by a
+ cryptic name. The reason is the jBoss does not want to lock files
+ in the deployment directory and prevent you from updating them, so
+ it makes copies in a temporary directory with cryptic names. This
+ is not the cause of a deployment failure.</p>
+
+ <h3><a NAME="verifier">Verifying EJBs During Deployment</a></h3>
+ <p>If your EJB JAR fails to deploy, the first thing to do is to turn
+ on the verifier and try again. The verifier will run a number of
+ tests on each EJB in an EJB JAR before the JAR is deployed. No
+ matter what the results of the verification are, the deployer will
+ attempt to deploy the EJBs, but the verifier may give you helpful
+ error messages ahead of time. To enable the verifier, edit the
+ <code>jboss.jcml</code> file in the <strong>conf</strong>
+ directory. Look for a section like the following:</p>
+<pre>
+ <mbean name="EJB:service=ContainerFactory">
+ <attribute name="VerifyDeployments"><b>false</b></attribute>
+ </mbean>
+</pre>
+ <p>If there is no such section, simply add it. In either case,
+ make sure the attribute value is set to <code>true</code> to
+ enable the verifier.</p>
+
+ <h3><a NAME="jndi">JNDI Problems</a></h3>
+ <p>If your bean gets NamingExceptions, that indicates a JNDI
+ problem. Typically, this means the bean implementation used an
+ invalid JNDI name when it looked up an environment setting, a data
+ source, or another EJB. Review the naming syntax in the
+ <a HREF="developing.html">Writing EJBs</a> section, for
+ <a HREF="developing.html#env">Environment Settings</a>,
+ <a HREF="developing.html#data">Data Sources</a>, or
+ <a HREF="developing.html#ejbs">EJBs</a>. Remember that your
+ EJBs should not attempt to look up any of those unless they have
+ been declared and named in the <code>ejb-jar.xml</code> file (see
+ <a HREF="#ejb11">The EJB 1.1 Deployment Descriptor</a>). Also,
+ note that you must define the target data source or EJB in the
+ <code>jboss.xml</code> file (see
+ <a HREF="#jboss">The jBoss Deployment Descriptor</a>).</p>
+
+ <h2><a NAME="undeploy">Undeploying EJBs</a></h2>
+ <p>To undeploy an EJB, delete the EJB JAR file in the
+ <strong>deploy</strong> directory. You can also undeploy JARs
+ using the management interface, and that is the only option if
+ you manually deployed a JAR in a different location (see
+ <a HREF="managing.html">Managing a Live jBoss Server</a>).</p>
+
+ <h2><a NAME="redeploy">Redeploying Existing EJBs</a></h2>
+ <p>To redeploy an EJB, copy a new EJB JAR file to the
+ <strong>deploy</strong> directory, replacing the old one. The
+ EJBs in the JAR will automatically be undeployed and the new
+ versions deployed. You can also undeploy JARs using the
+ management interface, and that is the only option if you manually
+ deployed a JAR in a different location (see
+ <a HREF="managing.html">Managing a Live jBoss Server</a>).</p>
+
+ <h2><a NAME="hot">Hot Deployment</a></h2>
+ <p>jBoss always hot deploys and EJB JARs copied into the
+ <strong>deploy</strong> directory, so there are not special
+ procedures for hot deployment. If you want a strictly manual
+ deploy and undeploy process, use the management interface (see
+ <a HREF="managing.html">Managing a Live jBoss Server</a>).</p>
</body>
</html>
1.3 +28 -24 jbossweb/manual/developing.html
Index: developing.html
===================================================================
RCS file: /products/cvs/ejboss/jbossweb/manual/developing.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- developing.html 2000/09/16 18:54:34 1.2
+++ developing.html 2000/09/19 14:28:36 1.3
@@ -145,10 +145,11 @@
finders, you have two options.</p>
<p>First, you can declare them in your home interface and then
create finder definitions in your JAWS deployment descriptor
- (see <a HREF="BROKENLINK">The JAWS Deployment Descriptor</a>).
- This is suitable for queries that only involve the table your
- entity bean is stored in: effectively, you can write the WHERE
- clause of a SQL query, but the FROM clause is fixed.</p>
+ (see <a HREF="deploying.html#jaws">The JAWS Deployment
+ Descriptor</a>). This is suitable for queries that only involve
+ the table your entity bean is stored in: effectively, you can
+ write the WHERE clause of a SQL query, but the FROM clause is
+ fixed.</p>
<p>Second, you can implement the finders yourself, even if the rest
of your bean uses CMP. This is best for complex queries that
require other tables. Any time you implement a finder yourself
@@ -190,7 +191,8 @@
share between clients, to reduce the memory usage of the server
as a whole. To change the pooling characteristics of a session
bean, you need to change the deployment descriptor (see
- <a HREF="BROKENLINK">The jBoss Deployment Descriptor</a>).</p>
+ <a HREF="deploying.html#jboss">The jBoss Deployment
+ Descriptor</a>).</p>
<h2><a NAME="env">Using Environment Settings</a></h2>
<p>If you need to pass configuration information to your beans, you
@@ -198,9 +200,10 @@
name and type, and code your bean accordingly. Then when you go
to deploy the bean, you specify environment settings in the
deployment descriptor (see
- <a HREF="BROKENLINK">The EJB 1.1 Deployment Descriptor</a>). In
- this manner you can deploy one bean multiple times with different
- settings, change the settings between servers, etc.</p>
+ <a HREF="deploying.html#ejb11">The EJB 1.1 Deployment
+ Descriptor</a>). In this manner you can deploy one bean multiple
+ times with different settings, change the settings between
+ servers, etc.</p>
<p>To access an environment setting in an EJB (any type, entity,
session, etc.), you get the value out of JNDI. You can't
generally do this in the bean constructor, so you should do it in
@@ -218,13 +221,14 @@
<h2><a NAME="data">Using Data Sources</a></h2>
<p>Like Environment Settings, data source are configured in the
deployment descriptor (see
- <a HREF="BROKENLINK">The EJB 1.1 Deployment Descriptor</a>).
- They are also stored under the <code>java:comp/env</code>
- namespace. The EJB specification recommends that you begin the
- name of your data source with "<code>jdbc/</code>", but that is
- not required. jBoss will <em>not</em> automatically add the
- <code>jdbc/</code> prefix; you must include it in the name of your
- Data Source if you want it to be there.</p>
+ <a HREF="deploying.html#ejb11">The EJB 1.1 Deployment
+ Descriptor</a>). They are also stored under the
+ <code>java:comp/env</code> namespace. The EJB specification
+ recommends that you begin the name of your data source with
+ "<code>jdbc/</code>", but that is not required. jBoss will
+ <em>not</em> automatically add the <code>jdbc/</code> prefix; you
+ must include it in the name of your Data Source if you want it to
+ be there.</p>
<p>For example, let's say you configured a data source called
<code>jdbc/OracleDB</code> in your deployment descriptor. The
bean would access it using code like the example below. Note that
@@ -259,12 +263,12 @@
deployed on the same server and you think you could access them
directly, it's better to configure an EJB reference in your
deployment descriptor (see
- <a HREF="BROKENLINK">The EJB 1.1 Deployment Descriptor</a>).
- The EJB specification recommends that you begin the name of your
- EJB reference with "<code>ejb/</code>", but that is not required.
- jBoss will <em>not</em> automatically add the <code>ejb/</code>
- prefix; you must include it in the name of your EJB reference if
- you want it to be there.</p>
+ <a HREF="deploying.html#ejb11">The EJB 1.1 Deployment
+ Descriptor</a>). The EJB specification recommends that you begin
+ the name of your EJB reference with "<code>ejb/</code>", but that
+ is not required. jBoss will <em>not</em> automatically add the
+ <code>ejb/</code> prefix; you must include it in the name of your
+ EJB reference if you want it to be there.</p>
<p>For example, let's say you want the current EJB to use another
bean known as UtilityBean. That bean may be located in JNDI under
the name <code>Utility</code>, but you set up an EJB reference for
@@ -288,9 +292,9 @@
In this case, you can let jBoss handle everything. You specify
the transaction settings for each bean method in the deployment
descriptor (see
- <a HREF="BROKENLINK">The EJB 1.1 Deployment Descriptor</a>). In
- this case jBoss handles creating, committing, and rolling back
- transactions.</p>
+ <a HREF="deploying.html#ejb11">The EJB 1.1 Deployment
+ Descriptor</a>). In this case jBoss handles creating, committing,
+ and rolling back transactions.</p>
<p>The other two options, bean-demarcated transactions and
client-demarcated transactions, are closeley related. In these
cases, you must manually handle creating, committing, and rolling
1.7 +20 -20 jbossweb/manual/index.html
Index: index.html
===================================================================
RCS file: /products/cvs/ejboss/jbossweb/manual/index.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- index.html 2000/09/16 18:54:34 1.6
+++ index.html 2000/09/19 14:28:36 1.7
@@ -75,27 +75,27 @@
<p CLASS="tc2"><a CLASS="plain" HREF="developing.html#ejbs">Using Other
EJBs</a></p>
<p CLASS="tc2"><a CLASS="plain"
HREF="developing.html#trans">Transactions</a></p>
<p CLASS="tc1"><a CLASS="plain" HREF="deploying.html">Deploying EJBs in
jBoss</a></p>
- <p CLASS="tc2">Preparing Your EJB JAR</p>
- <p CLASS="tc3">Required Classes</p>
- <p CLASS="tc3">Deployment Descriptors</p>
- <p CLASS="tc4">About Deployment Descriptors</p>
- <p CLASS="tc5">The EJB 1.1 Deployment Descriptor</p>
- <p CLASS="tc5">The jBoss Deployment Descriptor</p>
- <p CLASS="tc5">The JAWS Deployment Descriptor</p>
- <p CLASS="tc4">Using EJX to Edit Deployment Descriptors</p>
- <p CLASS="tc4">Editing Deployment Descriptors By Hand</p>
- <p CLASS="tc3">The Manifest File</p>
- <p CLASS="tc2">Deploying Your EJB JAR</p>
- <p CLASS="tc2">Deployment Failures</p>
- <p CLASS="tc3">Strange File Names</p>
- <p CLASS="tc3">Verifying EJBs During Deployment</p>
- <p CLASS="tc3">JNDI Problems</p>
- <p CLASS="tc2">Undeploying EJBs</p>
- <p CLASS="tc2">Redeploying Existing EJBs</p>
- <p CLASS="tc2">Hot Deployment</p>
+ <p CLASS="tc2"><a CLASS="plain" HREF="deploying.html#preparing">Preparing
Your EJB JAR</a></p>
+ <p CLASS="tc3"><a CLASS="plain" HREF="deploying.html#classes">Required
Classes</a></p>
+ <p CLASS="tc3"><a CLASS="plain"
HREF="deploying.html#descriptors">Deployment Descriptors</a></p>
+ <p CLASS="tc4"><a CLASS="plain" HREF="deploying.html#ejb11">The EJB 1.1
Deployment Descriptor</a></p>
+ <p CLASS="tc4"><a CLASS="plain" HREF="deploying.html#jboss">The jBoss
Deployment Descriptor</a></p>
+ <p CLASS="tc4"><a CLASS="plain" HREF="deploying.html#jaws">The JAWS
Deployment Descriptor</a></p>
+ <p CLASS="tc4"><a CLASS="plain" HREF="deploying.html#ejx">Editing
Deployment Descriptors with EJX</a></p>
+ <p CLASS="tc4"><a CLASS="plain" HREF="deploying.html#byhand">Editing
Deployment Descriptors By Hand</a></p>
+ <p CLASS="tc3"><a CLASS="plain" HREF="deploying.html#manifest">The
Manifest File</a></p>
+ <p CLASS="tc2"><a CLASS="plain" HREF="deploying.html#deploying">Deploying
Your EJB JAR</a></p>
+ <p CLASS="tc2"><a CLASS="plain" HREF="deploying.html#failures">Deployment
Failures</a></p>
+ <p CLASS="tc3"><a CLASS="plain" HREF="deploying.html#files">Strange File
Names</a></p>
+ <p CLASS="tc3"><a CLASS="plain" HREF="deploying.html#verifier">Verifying
EJBs During Deployment</a></p>
+ <p CLASS="tc3"><a CLASS="plain" HREF="deploying.html#jndi">JNDI
Problems</a></p>
+ <p CLASS="tc2"><a CLASS="plain" HREF="deploying.html#undeploy">Undeploying
EJBs</a></p>
+ <p CLASS="tc2"><a CLASS="plain" HREF="deploying.html#redeploy">Redeploying
Existing EJBs</a></p>
+ <p CLASS="tc2"><a CLASS="plain" HREF="deploying.html#hot">Hot
Deployment</a></p>
<p CLASS="tc1"><a CLASS="plain" HREF="jms.html">JMS in jBoss</a></p>
- <p CLASS="tc2">About SpyderMQ</p>
- <p CLASS="tc2">Using SpyderMQ</p>
+ <p CLASS="tc2"><a CLASS="plain" HREF="jms.html#about">About SpyderMQ</a></p>
+ <p CLASS="tc2"><a CLASS="plain" HREF="jms.html#install">Installing
SpyderMQ</a></p>
+ <p CLASS="tc2"><a CLASS="plain" HREF="jms.html#using">Using SpyderMQ</a></p>
<p CLASS="tc1"><a CLASS="plain" HREF="managing.html">Managing a Live jBoss
Server</a></p>
<p CLASS="tc2">Web Administration</p>
<p CLASS="tc2">JMX Client Administration</p>
1.3 +3 -3 jbossweb/manual/install.html
Index: install.html
===================================================================
RCS file: /products/cvs/ejboss/jbossweb/manual/install.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- install.html 2000/09/14 21:46:20 1.2
+++ install.html 2000/09/19 14:28:36 1.3
@@ -13,9 +13,9 @@
<p>If you want to run jBoss under JDK 1.2.2, you must presently
override the default container invoker setting in the jboss.xml
file for each of your EJB JARs
- (see <a HREF="BROKENLINK">The jBoss Deployment Descriptor</a>).
- In a future release, you will be able to change the default
- container invoker setting instead.</p>
+ (see <a HREF="deploying.html#jboss">The jBoss Deployment
+ Descriptor</a>). In a future release, you will be able to change
+ the default container invoker setting instead.</p>
<p>The only feature that will not work under JDK 1.2 is the
graceful server shutdown from the jBoss console. Under JDK 1.3,
if you hit Ctrl-C at the console, the server will shut down
1.2 +43 -0 jbossweb/manual/jms.html
Index: jms.html
===================================================================
RCS file: /products/cvs/ejboss/jbossweb/manual/jms.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- jms.html 2000/09/14 18:28:37 1.1
+++ jms.html 2000/09/19 14:28:36 1.2
@@ -5,5 +5,48 @@
</head>
<body>
<h1 ALIGN="CENTER">jBoss 2.0: JMS in jBoss</h1>
+ <p>The implementation of JMS that ships with jBoss is SpyderMQ.</p>
+
+ <h2><a NAME="about">About SpyderMQ</a></h2>
+ <p><i>This section is forthcoming</i></p>
+
+ <h2><a NAME="install">Installing SpyderMQ</a></h2>
+ <p>SpyderMQ is included with the jBoss distribution. To active it
+ in your jBoss server, you must include it in your
+ <code>jboss.conf</code> file. Look for a section like this:</p>
+<pre>
+<!--
+ -- Uncomment this to add SpyderMQ support. Be sure to set your 'SPYDERMQ_HOME'
+ -- environment variable before starting JBoss. You'll also need to copy the
+ -- spyderMQ.properties file from your SpyderMQ installation to you JBoss
+ -- installation conf dir.
+ -- MLET CODE = "org.jboss.spydermq.SpyderMQService" ARCHIVE="jboss.jar"
CODEBASE="../lib/ext/">
+ -- /MLET>
+ -->
+</pre>
+ <p>To uncomment this section, remove the <code>--</code> from the
+ beginning of the last two lines, add a < symbol, and move the
+ end comment tag so you get something like this: </p>
+<pre>
+<!--
+ -- Comment this to remove SpyderMQ support. Be sure to set your 'SPYDERMQ_HOME'
+ -- environment variable before starting JBoss. You'll also need to copy the
+ -- spyderMQ.properties file from your SpyderMQ installation to you JBoss
+ -- installation conf dir.
+ -->
+ <MLET CODE = "org.jboss.spydermq.SpyderMQService" ARCHIVE="jboss.jar"
CODEBASE="../lib/ext/">
+ </MLET>
+</pre>
+ <p>Additionally, as noted in the comment, you must set the
+ <code>SPYDERMQ_HOME</code> environment variable. The best place
+ to do this is usually the script that starts jBoss -
+ <code>run.bat</code> (Windows) or <code>run.sh</code> (UNIX) in
+ the <strong>bin</strong> directory. There is a default
+ <code>spyderMQ.properties</code> file in the jBoss
+ <strong>conf</strong> directory, but you may want to customize
+ that or replace it with a customized version.</p>
+
+ <h2><a NAME="using">Using SpyderMQ</a></h2>
+ <p><i>This section is forthcoming</i></p>
</body>
</html>
1.7 +4 -2 jbossweb/manual/warning.html
Index: warning.html
===================================================================
RCS file: /products/cvs/ejboss/jbossweb/manual/warning.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- warning.html 2000/09/16 18:54:34 1.6
+++ warning.html 2000/09/19 14:28:36 1.7
@@ -71,12 +71,14 @@
</li>
<li>Deploying EJBs in jBoss
<ul>
- <li>This section must be written</li>
+ <li>Need detail on non-JDBC resource managers</li>
</ul>
</li>
<li>JMS in jBoss
<ul>
- <li>This section must be written</li>
+ <li>What would you use JMS for?</li>
+ <li>How do you access JMS? Through JNDI?</li>
+ <li>Is SpyderMQ part of the default jBoss distribution?</li>
</ul>
</li>
<li>Managing a Live jBoss Server
