[jboss-cvs] JBossAS SVN: r91135 - projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Sun Jul 12 21:10:59 EDT 2009
Author: irooskov at redhat.com
Date: 2009-07-12 21:10:58 -0400 (Sun, 12 Jul 2009)
New Revision: 91135
Modified:
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Architecture.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Cache.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HASingleton.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/EJB3.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/FAQ.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/General_Configuration.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Introduction.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Messaging.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Pooling.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Security.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Virtual_Deployment_Framework.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/What_This_Book_Covers.xml
Log:
updated with the removal of reference to AS and replaced with reference to EAP
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -6,11 +6,11 @@
<xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="What_This_Book_Covers.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="About_JBoss.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+<!-- <xi:include href="About_JBoss.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> -->
<xi:include href="Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<part id="JBoss_AS_Infrastructure" label="I">
- <title>JBoss AS Infrastructure</title>
+ <title>JBoss Enterprise Application Platform Infrastructure</title>
<xi:include href="Architecture.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
@@ -19,7 +19,7 @@
<part id="Application_Configuration" label="II">
- <title>JBoss Application Server 5 Configuration</title>
+ <title>JBoss Enterprise Application Platform 5 Configuration</title>
<xi:include href="Deploy.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<!--<xi:include href="General_Configuration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />-->
<xi:include href="Microcontainer.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -3,24 +3,24 @@
]>
<chapter id="alternative_DBs">
- <title>Use Alternative Databases with JBoss AS</title>
+ <title>Use Alternative Databases with JBoss Enterprise Application Platform</title>
<section>
<title>How to Use Alternative Databases</title>
<para>
<indexterm><primary>Configuration</primary><secondary>databases</secondary></indexterm>
-JBoss utilizes the Hypersonic database as its default database. While this is good for development and prototyping, you or your company will probably require another database to be used for production. This chapter covers configuring JBoss AS to use alternative databases. We cover the procedures for all officially supported databases on the JBoss Application Server. They include: MySQL 5.0, PostgreSQL 8.1, Oracle 9i and 10g R2, DB2 7.2 and 8, Sybase ASE 12.5, as well as MS SQL 2005.
+JBoss utilizes the Hypersonic database as its default database. While this is good for development and prototyping, you or your company will probably require another database to be used for production. This chapter covers configuring JBoss Enterprise Application Platform to use alternative databases. We cover the procedures for all officially supported databases on the JBoss Application Server. They include: MySQL 5.0, PostgreSQL 8.1, Oracle 9i and 10g R2, DB2 7.2 and 8, Sybase ASE 12.5, as well as MS SQL 2005.
</para>
- <para>Please note that in this chapter, we explain how to use alternative databases to support all services in JBoss AS. This includes all the system level services such as EJB and JMS. For individual applications (e.g., WAR or EAR) deployed in JBoss AS, you can still use any backend database by setting up the appropriate data source connection. </para>
+ <para>Please note that in this chapter, we explain how to use alternative databases to support all services in JBoss Enterprise Application Platform. This includes all the system level services such as EJB and JMS. For individual applications (e.g., WAR or EAR) deployed in JBoss Enterprise Application Platform, you can still use any backend database by setting up the appropriate data source connection. </para>
- <para>We assume that you have already installed the external database server, and have it running. You should create an empty database named <literal>jboss</literal>, accessible via the username / password pair <literal>jbossuser / jbosspass</literal>. The <literal>jboss</literal> database is used to store JBoss AS internal data -- JBoss AS will automatically create tables and data in it.</para>
+ <para>We assume that you have already installed the external database server, and have it running. You should create an empty database named <literal>jboss</literal>, accessible via the username / password pair <literal>jbossuser / jbosspass</literal>. The <literal>jboss</literal> database is used to store JBoss Enterprise Application Platform internal data -- JBoss Enterprise Application Platform will automatically create tables and data in it.</para>
</section>
<section>
<title>Install JDBC Drivers</title>
- <para>For the JBoss Application Server and our applications to use the external database, we also need to install the database's JDBC driver. The JDBC driver is a JAR file, which you'll need to copy into your JBoss AS's <literal><JBoss_Home>/server/all/lib</literal> directory. Replace <literal>all</literal> with the server configuration you are using if needed. This file is loaded when JBoss starts up. So if you have the JBoss AS running, you'll need to shut down and restart. The availability of JDBC drivers for different databases are as follows.
+ <para>For the JBoss Application Server and our applications to use the external database, we also need to install the database's JDBC driver. The JDBC driver is a JAR file, which you'll need to copy into your JBoss Enterprise Application Platform's <literal><JBoss_Home>/server/all/lib</literal> directory. Replace <literal>all</literal> with the server configuration you are using if needed. This file is loaded when JBoss starts up. So if you have the JBoss Enterprise Application Platform running, you'll need to shut down and restart. The availability of JDBC drivers for different databases are as follows.
</para>
@@ -415,7 +415,7 @@
<section>
<title>Creating a DataSource for the External Database</title>
- <para>JBoss AS connects to relational databases via datasources. These datasource definitions can be found in the <literal><JBoss_Home>/server/all/deploy</literal> directory. The datasource definitions are deployable just like WAR and EAR files. The datasource files can be recognized by looking for the XML files that end in <literal>*-ds.xml</literal>.</para>
+ <para>JBoss Enterprise Application Platform connects to relational databases via datasources. These datasource definitions can be found in the <literal><JBoss_Home>/server/all/deploy</literal> directory. The datasource definitions are deployable just like WAR and EAR files. The datasource files can be recognized by looking for the XML files that end in <literal>*-ds.xml</literal>.</para>
<note><title>Datasource definition files</title>
<para>The datasource definition files for all supported external databases can be found in the <literal><JBoss_Home>/docs/examples/jca</literal> directory.</para>
@@ -498,7 +498,7 @@
<para>
<emphasis><xa-resource-timeout></emphasis> - the number of seconds passed to
<screen>XAResource.setTranasctionTimeout()</screen>
- when not zero. This feature is available on JBoss AS 4.0.3 and above.
+ when not zero. This feature is available on JBoss Enterprise Application Platform 4.0.3 and above.
</para>
</section>
@@ -620,7 +620,7 @@
<section>
<title>Change Database for the JMS Services</title>
- <para>The JMS service in the JBoss AS uses relational databases to persist its messages. For improved performance, we should change the JMS service to take advantage of the external database. To do that, we need to replace the file <literal><JBoss_Home>/server/all/deploy/jms-singleton/hsqldb-jdbc2-service.xml</literal> with a file in <literal><JBoss_Home>/docs/examples/jms/</literal> depending on your external database. Notice that if you are using the <literal>default</literal> server profile, the file path is <literal><JBoss_Home>/server/default/deploy/jms/hsqldb-jdbc2-service.xml</literal>.</para>
+ <para>The JMS service in the JBoss Enterprise Application Platform uses relational databases to persist its messages. For improved performance, we should change the JMS service to take advantage of the external database. To do that, we need to replace the file <literal><JBoss_Home>/server/all/deploy/jms-singleton/hsqldb-jdbc2-service.xml</literal> with a file in <literal><JBoss_Home>/docs/examples/jms/</literal> depending on your external database. Notice that if you are using the <literal>default</literal> server profile, the file path is <literal><JBoss_Home>/server/default/deploy/jms/hsqldb-jdbc2-service.xml</literal>.</para>
<itemizedlist>
<listitem><para>MySQL: <literal>mysql-jdbc2-service.xml</literal></para></listitem>
@@ -641,7 +641,7 @@
<section>
<title>Support Foreign Keys in CMP Services</title>
- <para>Next, we need to go change the <literal><JBoss_Home>/server/all/conf/standardjbosscmp-jdbc.xml</literal> file so that the <literal>fk-constraint</literal> property is <literal>true</literal>. That is needed for all external databases we support on the JBoss Application Server. This file configures the database connection settings for the EJB2 CMP beans deployed in the JBoss AS.</para>
+ <para>Next, we need to go change the <literal><JBoss_Home>/server/all/conf/standardjbosscmp-jdbc.xml</literal> file so that the <literal>fk-constraint</literal> property is <literal>true</literal>. That is needed for all external databases we support on the JBoss Application Server. This file configures the database connection settings for the EJB2 CMP beans deployed in the JBoss Enterprise Application Platform.</para>
<programlisting role="XML"><fk-constraint>true</fk-constraint></programlisting>
@@ -650,7 +650,7 @@
<section>
<title>Specify Database Dialect for Java Persistence API</title>
- <para>The Java Persistence API (JPA) entity manager can save EJB3 entity beans to any backend database. Hibernate provides the JPA implementation in JBoss AS. Hibernate has a dialect auto-detection mechanism that works for most databases including the dialects for databases referenced in this appendix which are listed below. If a specific dialect is needed for alternative databases, you can configure the database dialect in the <literal><JBoss_Home>/server/all/deploy/ejb3.deployer/META-INF/persistence.properties</literal> file. You need to un-comment the <literal>hibernate.dialect</literal> property and change its value to the following based on the database you setup. For a complete list of dialects, refer to the Hibernate Reference Guide, Chapter 3, Section 4.1 SQL Dialects.</para>
+ <para>The Java Persistence API (JPA) entity manager can save EJB3 entity beans to any backend database. Hibernate provides the JPA implementation in JBoss Enterprise Application Platform. Hibernate has a dialect auto-detection mechanism that works for most databases including the dialects for databases referenced in this appendix which are listed below. If a specific dialect is needed for alternative databases, you can configure the database dialect in the <literal><JBoss_Home>/server/all/deploy/ejb3.deployer/META-INF/persistence.properties</literal> file. You need to un-comment the <literal>hibernate.dialect</literal> property and change its value to the following based on the database you setup. For a complete list of dialects, refer to the Hibernate Reference Guide, Chapter 3, Section 4.1 SQL Dialects.</para>
<itemizedlist>
<listitem><para>Oracle 9i: org.hibernate.dialect.Oracle9iDialect</para></listitem>
@@ -680,7 +680,7 @@
</section>
<section>
- <title>Change Other JBoss AS Services to Use the External Database</title>
+ <title>Change Other JBoss Enterprise Application Platform Services to Use the External Database</title>
<para>Besides JMS, CMP, and JPA, we still need to hook up the rest of JBoss services with the external database. There are two ways to do it. One is easy but inflexible. The other is flexible but requires more steps. Now, let's discuss those two approaches respectively.</para>
@@ -722,7 +722,7 @@
<para>Changing the external datasource to <literal>DefaultDS</literal> is convenient. But if you have applications that assume the <literal>DefaultDS</literal> always points to the factory-default HSQL DB, that approach could break your application. Also, changing <literal>DefaultDS</literal> destination forces all JBoss services to use the external database. What if you want to use the external database only on some services?</para>
- <para>A safer and more flexible way to hook up JBoss AS services with the external datasource is to manually change the <literal>DefaultDS</literal> in all standard JBoss services to the datasource JNDI name defined in your <literal>*-ds.xml</literal> file (e.g., the <literal>MySqlDS</literal> in <literal>mysql-ds.xml</literal> etc.). Below is a complete list of files that contain <literal>DefaultDS</literal>. You can update them all to use the external database on all JBoss services or update some of them to use different combination of datasources for different services.</para>
+ <para>A safer and more flexible way to hook up JBoss Enterprise Application Platform services with the external datasource is to manually change the <literal>DefaultDS</literal> in all standard JBoss services to the datasource JNDI name defined in your <literal>*-ds.xml</literal> file (e.g., the <literal>MySqlDS</literal> in <literal>mysql-ds.xml</literal> etc.). Below is a complete list of files that contain <literal>DefaultDS</literal>. You can update them all to use the external database on all JBoss services or update some of them to use different combination of datasources for different services.</para>
<itemizedlist>
<listitem><para><literal><JBoss_Home>/server/all/conf/login-config.xml</literal>: This file is used in Java EE container managed security services.</para></listitem>
@@ -754,9 +754,9 @@
<section>
<title>A Special Note About Oracle DataBases</title>
- <para>In our setup discussed in this chapter, we rely on the JBoss AS to automatically create needed tables in the external database upon server startup. That works most of the time. But for databases like Oracle, there might be some minor issues if you try to use the same database server to back more than one JBoss AS instance.</para>
+ <para>In our setup discussed in this chapter, we rely on the JBoss Enterprise Application Platform to automatically create needed tables in the external database upon server startup. That works most of the time. But for databases like Oracle, there might be some minor issues if you try to use the same database server to back more than one JBoss Enterprise Application Platform instance.</para>
- <para>The Oracle database creates tables of the form <literal>schemaname.tablename</literal>. The <literal>TIMERS</literal> and <literal>HILOSEQUENCES</literal> tables needed by JBoss AS would not get created on a schema if the table already exists on a different schema. To work around this issue, you need to edit the <literal><JBoss_Home>/server/all/deploy/ejb-deployer.xml</literal> file to change the table name from <literal>TIMERS</literal> to something like <literal>schemaname2.tablename</literal>.</para>
+ <para>The Oracle database creates tables of the form <literal>schemaname.tablename</literal>. The <literal>TIMERS</literal> and <literal>HILOSEQUENCES</literal> tables needed by JBoss Enterprise Application Platform would not get created on a schema if the table already exists on a different schema. To work around this issue, you need to edit the <literal><JBoss_Home>/server/all/deploy/ejb-deployer.xml</literal> file to change the table name from <literal>TIMERS</literal> to something like <literal>schemaname2.tablename</literal>.</para>
<programlisting role="XML"><mbean code="org.jboss.ejb.txtimer.DatabasePersistencePolicy"
name="jboss.ejb:service=EJBTimerService,persistencePolicy=database">
@@ -1039,7 +1039,7 @@
</itemizedlist>
<para>
- From JBoss AS 3.2.6 and above, <literal>track-statements</literal> has a new option:
+ From JBoss Enterprise Application Platform 3.2.6 and above, <literal>track-statements</literal> has a new option:
</para>
<programlisting role="XML"><track-statements>nowarn</track-statements</programlisting>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Architecture.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Architecture.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Architecture.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -2,10 +2,10 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
]>
-<chapter id="JBoss_AS5_Architecture">
- <title>JBoss Application Server 5 architecture</title>
+<chapter id="JBoss_Enterprise_Application_Platform_5_Architecture">
+ <title>JBoss Enterprise Application Platform 5 architecture</title>
<para>
- <indexterm><primary>JBossAS</primary><secondary>architecture</secondary></indexterm>
+ <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>architecture</secondary></indexterm>
The following diagram illustrates an overview of the JBoss.org community projects including the JBoss Appplication Server and its components.
<inlinemediaobject>
<imageobject>
@@ -17,7 +17,7 @@
<para>
The directory structure of JBoss 5 resembles that of the 4.x series with some notable differences:
<screen>
-<![CDATA[-<JBOSS_HOME>/ - the path to your JBoss AS installation.
+<![CDATA[-<JBOSS_HOME>/ - the path to your JBoss Enterprise Application Platform installation.
|-- bin - contains start scripts and run.jar
|-- client - client jars
|-- common - static jars shared across server configuration
@@ -153,12 +153,12 @@
</para>
<sect1 id="Architecture_Server_Bootstrap">
- <title>The JBoss AS Bootstrap</title>
- <indexterm><primary>JBossAS</primary><secondary>bootstrap</secondary></indexterm>
- <para>The JBossAS 5 bootstrap is similar to the JBossAS 4.x and earlier versions in that the org.jboss.Main entry point loads an org.jboss.system.server.Server implementation. In JBossAS 4.x this was a JMX based microkernel. In JBossAS 5 this is a JBoss Microcontainer.
+ <title>The JBoss Enterprise Application Platform Bootstrap</title>
+ <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>bootstrap</secondary></indexterm>
+ <para>The JBoss Enterprise Application Platform 5 bootstrap is similar to the JBoss Enterprise Application Platform 4.x and earlier versions in that the org.jboss.Main entry point loads an org.jboss.system.server.Server implementation. In JBoss Enterprise Application Platform 4.x this was a JMX based microkernel. In JBoss Enterprise Application Platform 5 this is a JBoss Microcontainer.
</para>
- <indexterm><primary>JBossAS</primary><secondary>Server interface implementation</secondary></indexterm>
- <para>The default JBossAS 5 org.jboss.system.server.Server implementation is org.jboss.bootstrap.microcontainer.ServerImpl. This implementation is an extension of the kernel basic bootstrap that boots the MC from the bootstrap beans declared in {jboss.server.config.url}/bootstrap.xml descriptors using a BasicXMLDeployer. In addition, the ServerImpl registers install callbacks for any beans that implement the org.jboss.bootstrap.spi.Bootstrap interface. The bootstrap/profile*.xml configurations include a ProfileServiceBootstrap bean that implements the Bootstrap interface.
+ <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>Server interface implementation</secondary></indexterm>
+ <para>The default JBoss Enterprise Application Platform 5 org.jboss.system.server.Server implementation is org.jboss.bootstrap.microcontainer.ServerImpl. This implementation is an extension of the kernel basic bootstrap that boots the MC from the bootstrap beans declared in {jboss.server.config.url}/bootstrap.xml descriptors using a BasicXMLDeployer. In addition, the ServerImpl registers install callbacks for any beans that implement the org.jboss.bootstrap.spi.Bootstrap interface. The bootstrap/profile*.xml configurations include a ProfileServiceBootstrap bean that implements the Bootstrap interface.
</para>
<indexterm><primary>ProfileService</primary><secondary>bootstrap</secondary></indexterm>
<para>The org.jboss.system.server.profileservice.ProfileServiceBootstrap is an implementation of the org.jboss.bootstrap.spi.Bootstrap interface that loads the deployments associated with the current profile. The {profile-name} is the name of the profile being loaded and corresponds to the server -c command line argument. The default {profile-name} is "default". The deployers, deploy</para>
@@ -166,7 +166,7 @@
<sect1 id="Architecture_Hotdeployment">
<title>Hot Deployment</title>
<indexterm><primary>Hot deployment</primary><secondary>implementation</secondary></indexterm>
- <para>Hot deployment in JBossAS 5 is controlled by the Profile implementations associated with the ProfileService. The HDScanner bean deployed via the deploy/hdscanner-jboss-beans.xml MC deployment, queries the profile service for changes in application directory contents and redeploys updated content, undeploys removed content, and adds new deployment content to the current profile via the ProfileService. </para>
+ <para>Hot deployment in JBoss Enterprise Application Platform 5 is controlled by the Profile implementations associated with the ProfileService. The HDScanner bean deployed via the deploy/hdscanner-jboss-beans.xml MC deployment, queries the profile service for changes in application directory contents and redeploys updated content, undeploys removed content, and adds new deployment content to the current profile via the ProfileService. </para>
<indexterm><primary>Hot deployment</primary><secondary>disabling</secondary></indexterm>
<para>Disabling hot deployment simply entails removing the hdscanner-jboss-beans.xml deployment.</para>
</sect1>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -5,15 +5,15 @@
<bookinfo id="JBoss_Application_Server">
<title>Administration And Configuration Guide</title>
- <edition>5</edition>
+ <edition>1</edition>
<issuenum>1</issuenum>
<pubsnumber>1</pubsnumber>
<productname>JBoss Enterprise Application Platform</productname>
- <productnumber>5</productnumber>
- <pubdate>, 2009</pubdate>
+ <productnumber>5.0</productnumber>
+<!-- <pubdate>, 2009</pubdate> -->
<abstract>
<para>
- This book is a guide to the administration and configuration of JBoss Enterprise Application Platform 5.
+ This book is a guide to the administration and configuration of JBoss Enterprise Application Platform 5.0.
</para>
</abstract>
<corpauthor>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Cache.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Cache.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Cache.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -28,7 +28,7 @@
</listitem>
</orderedlist>
<para>Pojo Cache has a complete and separate set of documentation, including a user guide, FAQ and tutorial and as such, Pojo Cache is not discussed further in this book. </para>
- <para>Pojo Cache deployment in the JBoss AS5 is discussed more in <xref linkend="pojocachedeployment"/></para>
+ <para>Pojo Cache deployment in the JBoss Enterprise Application Platform5 is discussed more in <xref linkend="pojocachedeployment"/></para>
</section>
<section><title>Summary of Features</title>
<para>JBoss Cache offers a simple and straightforward API, where data (simple Java objects) can be placed in the cache and, based on configuration options selected, this data may be one or all of: </para>
@@ -67,7 +67,7 @@
<section>
<title>Running JBoss Cache in the JBoss Application server</title>
<para>
- <indexterm><primary>JBossAS</primary><secondary>running JBoss Cache with JBossAS</secondary></indexterm>
+ <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>running JBoss Cache with JBoss Enterprise Application Platform</secondary></indexterm>
JBoss Cache uses JGroups as a transport layer. More information on JGroups can be found on <xref linkend="jgroups"/>
</para>
@@ -199,9 +199,9 @@
</entry>
</row></tbody></tgroup>
</table>
-<note><title></title><para>For JBoss AS 4.0.3SP1 (and earlier) to run with JBoss Cache 1.4.0.x you need to add jboss-serialization.jar to JBOSS_HOME/server/all/lib </para></note>
+<note><title></title><para>For JBoss Enterprise Application Platform 4.0.3SP1 (and earlier) to run with JBoss Cache 1.4.0.x you need to add jboss-serialization.jar to JBOSS_HOME/server/all/lib </para></note>
-<note><title></title><para>Upgrading to these JBoss Cache versions within JBoss AS 4.0.x requires JGroups to be upgraded to 2.2.9 or higher</para></note>-->
+<note><title></title><para>Upgrading to these JBoss Cache versions within JBoss Enterprise Application Platform 4.0.x requires JGroups to be upgraded to 2.2.9 or higher</para></note>-->
<para>
@@ -588,7 +588,7 @@
<screen><command><JBOSS_HOME>/bin/./run.sh -c all</command></screen>
All required jars will be on the classpath. Otherwise, you will need to ensure jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like <filename>JdbmCacheLoader</filename>. The simplest way to do this is to copy the jars from the JBoss Cache distribution's <filename>lib</filename> directory to the server configurations <emphasis>all</emphasis> <filename>lib</filename> directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR. </para>
- <para>It is possible to deploy a JBoss Cache 2.0 instance in JBoss AS 4.x (at least in 4.2.0.GA; other AS releases are completely untested). However, the significant API changes between the JBoss Cache 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on JBoss Cache will work with JBoss Cache 2.x. Also, be aware that usage of JBoss Cache 2.x in AS 4.x is not something the JBoss Cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.) </para>
+ <para>It is possible to deploy a JBoss Cache 2.0 instance in JBoss Enterprise Application Platform 4.x (at least in 4.2.0.GA; other AS releases are completely untested). However, the significant API changes between the JBoss Cache 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on JBoss Cache will work with JBoss Cache 2.x. Also, be aware that usage of JBoss Cache 2.x in AS 4.x is not something the JBoss Cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.) </para>
<para>Note in the <ulink url="http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#sample_xml_file">http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#sample_xml_file</ulink> the value of the mbean element's code attribute: org.jboss.cache.jmx.CacheJmxWrapper . This is the class JBoss Cache uses to handle JMX integration; the Cache itself does not expose an MBean interface. See the <ulink url="http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#jmx.mbeans">JBoss Cache MBeans section</ulink> for more on the CacheJmxWrapper . </para>
<para>Once your cache is deployed, in order to use it with an in-VM client such as a servlet, a JMX proxy can be used to get a reference to the cache: </para>
<para>
@@ -619,15 +619,15 @@
Simply instantiate a PojoCacheFactory and invoke one of the overloaded createCache methods shown in the API Overview.
</para>
</section>
- <section><title>JMX-Based Deployment in JBoss AS (JBoss AS 5.x and 4.x)</title>
+ <section><title>JMX-Based Deployment in JBoss Enterprise Application Platform (JBoss Enterprise Application Platform 5.x and 4.x)</title>
<para>
- If PojoCache is run in JBoss AS then your cache can be deployed as an MBean simply by copying a standard cache configuration file to the server's deploy directory. The standard format of PojoCache's standard XML configuration file (as shown in the Appendix) is the same as a JBoss AS MBean deployment descriptor, so the AS's SAR Deployer has no trouble handling it. Also, you don't have to place the configuration file directly in deploy; you can package it along with other services or JEE components in a SAR or EAR.
+ If PojoCache is run in JBoss Enterprise Application Platform then your cache can be deployed as an MBean simply by copying a standard cache configuration file to the server's deploy directory. The standard format of PojoCache's standard XML configuration file (as shown in the Appendix) is the same as a JBoss Enterprise Application Platform MBean deployment descriptor, so the AS's SAR Deployer has no trouble handling it. Also, you don't have to place the configuration file directly in deploy; you can package it along with other services or JEE components in a SAR or EAR.
</para>
<para>
In AS 5, if you're using a server config based on the standard all config, then that's all you need to do; all required jars will be on the classpath. Otherwise, you will need to ensure pojocache.jar, jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like JdbmCacheLoader. The simplest way to do this is to copy the jars from the PojoCache distribution's lib directory to the server config's lib directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR.
</para>
<para>
- It is possible, to deploy a POJO Cache 2.0 instance in JBoss AS 4.x However, the significant API changes between the 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on the 1.x API will work with PojoCache 2.x. Also, be aware that usage of PojoCache 2.x in AS 4.x is not something the cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.)
+ It is possible, to deploy a POJO Cache 2.0 instance in JBoss Enterprise Application Platform 4.x However, the significant API changes between the 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on the 1.x API will work with PojoCache 2.x. Also, be aware that usage of PojoCache 2.x in AS 4.x is not something the cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.)
</para>
<para>
Note in the example the value of the mbean element's code attribute: org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper. This is the class JBoss Cache uses to handle JMX integration; the PojoCache itself does not expose an MBean interface. See the JBoss Cache MBeans section for more on the PojoCacheJmxWrapper.
@@ -654,12 +654,12 @@
Once the proxy to the PojoCacheJmxWrapper is obtained, the getPojoCache() will return a reference to the PojoCache itself.
</para>
</section>
-<section><title>Via JBoss Microcontainer (JBoss AS 5.x)</title>
+<section><title>Via JBoss Microcontainer (JBoss Enterprise Application Platform 5.x)</title>
<para>
- Beginning with AS 5, JBoss AS also supports deployment of POJO services via deployment of a file whose name ends with -beans.xml. A POJO service is one whose implementation is via a "Plain Old Java Object", meaning a simple java bean that isn't required to implement any special interfaces or extend any particular superclass. A PojoCache is a POJO service, and all the components in a Configuration are also POJOS, so deploying a cache in this way is a natural step.
+ Beginning with AS 5, JBoss Enterprise Application Platform also supports deployment of POJO services via deployment of a file whose name ends with -beans.xml. A POJO service is one whose implementation is via a "Plain Old Java Object", meaning a simple java bean that isn't required to implement any special interfaces or extend any particular superclass. A PojoCache is a POJO service, and all the components in a Configuration are also POJOS, so deploying a cache in this way is a natural step.
</para>
<para>
- Deployment of the cache is done using the JBoss Microcontainer that forms the core of JBoss AS. JBoss Microcontainer is a sophisticated IOC framework (similar to Spring). A -beans.xml file is basically a descriptor that tells the IOC framework how to assemble the various beans that make up a POJO service.
+ Deployment of the cache is done using the JBoss Microcontainer that forms the core of JBoss Enterprise Application Platform. JBoss Microcontainer is a sophisticated IOC framework (similar to Spring). A -beans.xml file is basically a descriptor that tells the IOC framework how to assemble the various beans that make up a POJO service.
</para>
<para>
The rules for how to deploy the file, how to package it, how to ensure the required jars are on the classpath, etc. are the same as for a JMX-based deployment.
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -3,13 +3,13 @@
<chapter id="clustering-blocks.chapt">
<title>Clustering Building Blocks</title>
- <para>The clustering features in JBoss AS are built on top of lower level
+ <para>The clustering features in JBoss Enterprise Application Platform are built on top of lower level
libraries that provide much of the core functionality. <xref linkend="clustering-as-arch.fig"/>
shows the main pieces:
</para>
<figure id="clustering-as-arch.fig">
- <title>The JBoss AS clustering architecture</title>
+ <title>The JBoss Enterprise Application Platform clustering architecture</title>
<mediaobject>
<imageobject>
<imagedata align="center" fileref="images/clustering-as-arch.png" />
@@ -19,22 +19,22 @@
<para><emphasis role="bold">JGroups</emphasis> is a toolkit for reliable
point-to-point and point-to-multipoint communication. JGroups is used for
- all clustering-related communications between nodes in a JBoss AS cluster.
- <!-- See <xref linkend="clustering-blocks-jgroups"/> for more on how JBoss AS
+ all clustering-related communications between nodes in a JBoss Enterprise Application Platform cluster.
+ <!-- See <xref linkend="clustering-blocks-jgroups"/> for more on how JBoss Enterprise Application Platform
uses JGroups.--></para>
<para><emphasis role="bold">JBoss Cache</emphasis> is a highly flexible
- clustered transactional caching library. Many AS clustering services
+ clustered transactional caching library. Many Enterprise Application Platform clustering services
need to cache some state in memory while 1) ensuring for high availability
purposes that a backup copy of that state is available on another node
if it can't otherwise be recreated (e.g. the contents of a web session)
and 2) ensuring that the data cached on each node in the cluster is consistent.
- JBoss Cache handles these concerns for most JBoss AS clustered services.
+ JBoss Cache handles these concerns for most JBoss Enterprise Application Platform clustered services.
JBoss Cache uses JGroups to handle its group communication requirements.
<emphasis role="bold">POJO Cache</emphasis> is an extension of the
- core JBoss Cache that JBoss AS uses to support fine-grained replication
+ core JBoss Cache that JBoss Enterprise Application Platform uses to support fine-grained replication
of clustered web session state. See <xref linkend="clustering-blocks-jbc"/>
- for more on how JBoss AS uses JBoss Cache and POJO Cache.</para>
+ for more on how JBoss Enterprise Application Platform uses JBoss Cache and POJO Cache.</para>
<para><emphasis role="bold">HAPartition</emphasis> is an adapter on top
of a JGroups channel that allows multiple services to use the channel.
@@ -68,7 +68,7 @@
<title>The HAPartition Service</title>
<para>
HAPartition is a general purpose service used for a variety of tasks
- in AS clustering. At its core, it is an abstraction built on top of
+ in Enterprise Application Platform clustering. At its core, it is an abstraction built on top of
a JGroups Channel that provides support for making/receiving RPC
invocations on/from one or more cluster members. HAPartition also
supports a distributed registry of which clustering services are
@@ -83,7 +83,7 @@
- <para>The following example shows the <literal>HAPartition</literal> MBean definition packaged with the standard JBoss AS distribution.
+ <para>The following example shows the <literal>HAPartition</literal> MBean definition packaged with the standard JBoss Enterprise Application Platform distribution.
So, if you simply start JBoss servers with their default clustering settings on a local network, you
would get a default cluster named <literal>DefaultPartition</literal> that includes all server
instances as its nodes.</para>
@@ -155,9 +155,9 @@
The <literal>DistributedReplicantManager</literal> (DRM) service is a component
of the HAPartition service made available to HAPartition
users via the <literal>HAPartition.getDistributedReplicantManager()</literal>
- method. Generally speaking, JBoss AS users will not directly make
+ method. Generally speaking, JBoss Enterprise Application Platform users will not directly make
use of the DRM; we discuss it here as an aid to those who want a
- deeper understanding of how AS clustering internals work.</para>
+ deeper understanding of how Enterprise Application Platform clustering internals work.</para>
<para>
The DRM is a distributed registry that allows HAPartition users to
register objects under a given key, making available to callersthe
@@ -165,7 +165,7 @@
he cluster. The DRM also provides a notification mechanism so interested
listeners can be notified when the contents of the registry changes.
</para>
- <para>There are two main usages for the DRM in JBoss AS:</para>
+ <para>There are two main usages for the DRM in JBoss Enterprise Application Platform:</para>
<itemizedlist>
<listitem>
@@ -236,7 +236,7 @@
JBoss Cache is a fully featured distributed cache framework that can be
used in any application server environment or standalone. JBoss Cache
provides the underlying distributed caching support used by many of the
- standard clustered services in a JBoss AS cluster, including:
+ standard clustered services in a JBoss Enterprise Application Platform cluster, including:
<itemizedlist>
<listitem><para>Replication of clustered webapp sessions.</para></listitem>
<listitem><para>Replication of clustered EJB3 Stateful Session beans.</para></listitem>
@@ -252,13 +252,13 @@
<xref linkend="jbosscache.chapt"/> for more on this.</para>
<section id="clustering-blocks-jbc-cachemanager">
- <title>The JBoss AS CacheManager Service</title>
- <para>Many of the standard clustered services in JBoss AS use JBoss
+ <title>The JBoss Enterprise Application Platform CacheManager Service</title>
+ <para>Many of the standard clustered services in JBoss Enterprise Application Platform use JBoss
Cache to maintain consistent state across the cluster. Different
services (e.g. web session clustering or second level caching of
JPA/Hibernate entities) use different JBoss Cache instances, with
each cache configured to meet the needs of the service that uses it.
- In AS 4, each of these caches was independently deployed in the
+ In Enterprise Application Platform 4, each of these caches was independently deployed in the
<literal>deploy/</literal> directory, which had a number of disadvantages:
<itemizedlist>
<listitem><para>Caches that end user applications
@@ -289,7 +289,7 @@
<section id="clustering-blocks-jbc-cachemanager-stdconfigs">
<title>Standard Cache Configurations</title>
- <para>The following standard JBoss Cache configurations ship with JBoss AS 5.
+ <para>The following standard JBoss Cache configurations ship with JBoss Enterprise Application Platform 5.
You can add others to suit your needs, or edit these configurations
to adjust cache behavior. Additions or changes are done by editing
the <literal>deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml</literal>
@@ -444,11 +444,11 @@
different name. Aliasing is useful for sharing caches between
services whose configuration may specify different cache config
names. It's also useful for supporting legacy EJB3 application
- configurations ported over from AS 4.</para>
+ configurations ported over from Enterprise Application Platform 4.</para>
<para>Aliases can be configured by editing the "CacheManager"
bean in the <literal>jboss-cache-manager-jboss-beans.xml</literal>
file. The following redacted config shows the standard aliases in
- AS 5.0.0.GA:</para>
+ Enterprise Application Server 5.0.0:</para>
<programlisting><![CDATA[
<bean name="CacheManager" class="org.jboss.ha.cachemanager.CacheManager">
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -15,26 +15,26 @@
<title>Cluster Definition</title>
<para>
A cluster is a set of nodes that communicate with each other and work
- toward a common goal. In a JBoss Application Server cluster (also known
- as a “partition”), a node is an JBoss Application Server instance.
+ toward a common goal. In a JBoss Enterprise Application Platform cluster (also known
+ as a “partition”), a node is an JBoss Enterprise Application Platform instance.
Communication between the nodes is handled by the JGroups group communication
library, with a JGroups Channel providing the core functionality of tracking
who is in the cluster and reliably exchanging messages between the cluster
members. JGroups channels with the same configuration and name have the
ability to dynamically discover each other and form a group. This is why
- simply executing “run -c all” on two AS instances on the same network is
- enough for them to form a cluster – each AS starts a Channel (actually,
+ simply executing “run -c all” on two Enterprise Application Platform instances on the same network is
+ enough for them to form a cluster – each Enterprise Application Platform starts a Channel (actually,
several) with the same default configuration, so they dynamically discover
each other and form a cluster. Nodes can be dynamically added to or removed
from clusters at any time, simply by starting or stopping a Channel with a
configuration and name that matches the other cluster members.
- In summary, a JBoss cluster is a set of AS server instances each of which
+ In summary, a JBoss cluster is a set of Enterprise Application Platform server instances each of which
is running an identically configured and named JGroups Channel.
</para>
<para>
- On the same AS instance, different services can create their own Channel.
- In a default 5.0.x AS, four different services create channels – the web
+ On the same Enterprise Application Platform instance, different services can create their own Channel.
+ In a default 5.0.x Enterprise Application Platform, four different services create channels – the web
session replication service, the EJB3 SFSB replication service, the EJB3
entity caching service, and a core general purpose clustering service known
as HAPartition. In order to differentiate these channels, each must have a
@@ -42,7 +42,7 @@
other channels.
</para>
<para>
- So, if you go to two AS 5.0.x instances and execute <literal>run -c all</literal>,
+ So, if you go to two Enterprise Application Platform 5.0.x instances and execute <literal>run -c all</literal>,
the channels will discover each other and you'll have a conceptual
<literal>cluster</literal>. It's easy to think of this as a two node
cluster, but it's important to understand that you really have 4 channels,
@@ -53,7 +53,7 @@
<xref linkend="clustering-Partition.fig"/> shows an example network of JBoss
server instances divided into three clusters, with the third cluster only
having one node. This sort of topology can be set up simply by configuring
- the AS instances such that within a set of nodes meant to form a cluster the
+ the Enterprise Application Platform instances such that within a set of nodes meant to form a cluster the
Channel configurations and names match while they differ from any other
channels on the same network. </para>
<figure id="clustering-Partition.fig">
@@ -69,7 +69,7 @@
The section on “JGroups Configuration” and on “Isolating JGroups Channels”
covers in detail how to configure Channels such that desired peers find
each other and unwanted peers do not. As mentioned above, by default JBoss
- AS uses four separate JGroups Channels. These can be divided into two
+ Enterprise Application Platform uses four separate JGroups Channels. These can be divided into two
broad categories: the Channel used by the general purpose HAPartition
service, and three Channels created by JBoss Cache for special purpose
caching and cluster wide state replication.
@@ -82,7 +82,7 @@
MBean on each node is of great importance to system administrators. But for
most application developers, you are probably more concerned about the cluster
architecture from a client application's point of view. Two basic clustering
- architectures are used with JBoss AS: client-side interceptors (a.k.a smart
+ architectures are used with JBoss Enterprise Application Platform: client-side interceptors (a.k.a smart
proxies or stubs) and external load balancers. Which architecture your
application will use will depend on what type of client you have.
</para>
@@ -140,10 +140,10 @@
to certain communication protocols (e.g., the HTTP protocol). In this
case, an external load balancer is required to process all requests and
dispatch them to server nodes in the cluster. The client only needs to know
- how to contact the load balancer; it has no knowledge of the JBoss AS
+ how to contact the load balancer; it has no knowledge of the JBoss Enterprise Application Platform
instances behind the load balancer. The load balancer is logically part
of the cluster, but we refer to it as “external” because it is not running
- in the same process as either the client or any of the JBoss AS instances.
+ in the same process as either the client or any of the JBoss Enterprise Application Platform instances.
It can be implemented either in software or hardware. There are many
vendors of hardware load balancers; the mod_jk Apache module is an excellent
example of a software load balancer. An external load balancer implements
@@ -171,7 +171,7 @@
<section id="clustering-concepts-balancepolicy">
<title>Load-Balancing Policies</title>
<para>
- Both the JBoss client-side interceptor (stub) and load balancer use load balancing policies to determine which server node to which node a new request should be sent. In this section, let's go over the load balancing policies available in JBoss AS.
+ Both the JBoss client-side interceptor (stub) and load balancer use load balancing policies to determine which server node to which node a new request should be sent. In this section, let's go over the load balancing policies available in JBoss Enterprise Application Platform.
</para>
<section id="clustering-concepts-balancepolicy-30">
<title>Client-side interceptor architecture</title>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -29,7 +29,7 @@
<section>
<title>HASingleton Deployment Options</title>
<para>
- The JBoss Application Server (AS) provides support for a number of
+ The JBoss Enterprise Application Platform provides support for a number of
strategies for helping you deploy clustered singleton services. In
this section we will explore the different strategies. All of the
strategies are built on top of the HAPartition service described
@@ -51,7 +51,7 @@
directory instead of in <literal>deploy</literal>. The
<literal>deploy-hasingleton</literal> directory does not lie under
deploy or farm, so its contents are not automatically deployed
- when an AS instance starts. Instead, deploying the contents of this
+ when an Enterprise Application Platform instance starts. Instead, deploying the contents of this
directory is the responsibility of a special service, the
<literal>jboss.ha:service=HASingletonDeployer</literal>
MBean (which itself is deployed via the
@@ -293,7 +293,7 @@
The various clustered singleton management strategies all depend on the fact that each node in the cluster can independently react to changes in cluster membership and correctly decide whether it is now the “master node”. How is this done?
</para>
<para>
- Prior to JBoss AS 4.2.0, the methodology for this was fixed and simple.
+ <!-- Prior to JBoss Enterprise Application Platform 4.2.0, the methodology for this was fixed and simple. -->
For each member of the cluster, the HAPartition mbean maintains an attribute called the CurrentView, which is basically an ordered list of the current members of the cluster.
As nodes join and leave the cluster, JGroups ensures that each surviving member of the cluster gets an updated view.
You can see the current view by going into the JMX console, and looking at the CurrentView attribute in the <literal>jboss:service=DefaultPartition</literal> mbean.
@@ -380,7 +380,7 @@
<para>The Farm Service previously available in JBoss 4.x is not available
in JBoss 5.0 as it was incompatible with the new Profile Service at
- the core of the AS. A new Profile Service-based replacement for the
+ the core of the Enterprise Application Platform. A new Profile Service-based replacement for the
Farm Service will be added in a future release.</para>
<!--
<para>The easiest way to deploy an application into the cluster is to use the farming service. That is
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -407,7 +407,7 @@
<para>
Clustering stateful session beans is more complex than clustering their stateless counterparts
since JBoss needs to manage the state information. The state of all stateful session beans are
- replicated and synchronized across the cluster each time the state of a bean changes. The JBoss AS
+ replicated and synchronized across the cluster each time the state of a bean changes. The JBoss Enterprise Application Platform
uses the <literal>HASessionState</literal> MBean to manage distributed session states for clustered
EJB 2.x stateful session beans. In this section, we cover both the session bean configuration and
the <literal>HASessionState</literal> MBean configuration.
@@ -467,7 +467,7 @@
replicates the bean when the method returns <literal>true</literal>. If the bean has not been
modified (or not enough to require replication, depending on your own preferences), you can
return <literal>false</literal> and the replication would not occur. This feature is available
- on JBoss AS 3.0.1+ only.
+ on JBoss Enterprise Application Platform 3.0.1+ only.
</para>
</section>
<section>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -4,7 +4,7 @@
<chapter id="clustering-entity">
<title>Clustered Entity EJBs</title>
<para>
- In a JBoss AS cluster, entity bean instance caches need to be kept in sync across all nodes.
+ In a JBoss Enterprise Application Platform cluster, entity bean instance caches need to be kept in sync across all nodes.
If an entity bean provides remote services, the service methods need to be load balanced as well.
</para>
@@ -50,7 +50,7 @@
The Hibernate setup used for the JBoss EJB 3.0 implementation uses JBoss Cache as its underlying second-level cache implementation.
</para>
<para>
- Configuration of a the second-level cache is done via your EJB3 deployment's persistence.xml.
+ Configuration of a the second-level cache is done via your EJB3 deployment's <filename>persistence.xml</filename>.
</para>
<para>
e.g.
@@ -404,7 +404,7 @@
See the Hibernate and EJB3 documentation for more on how to use EJB3 queries and on how to instruct EJB3 to cache queries.
</para>
<para>
- By default, Hibernate stores query results in JBoss Cache in a region named {region_prefix}/org/hibernate/cache/StandardQueryCache. Based on this, you can set up separate eviction handling for your query results. So, if the region prefix were set to myprefix in persistence.xml, you could, for example, create this sort of eviction handling:
+ By default, Hibernate stores query results in JBoss Cache in a region named {region_prefix}/org/hibernate/cache/StandardQueryCache. Based on this, you can set up separate eviction handling for your query results. So, if the region prefix were set to myprefix in <filename>persistence.xml</filename>, you could, for example, create this sort of eviction handling:
</para>
<programlisting><![CDATA[
<server>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HASingleton.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HASingleton.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HASingleton.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -30,7 +30,7 @@
<section>
<title>Deployment Options</title>
<para>
- The JBoss Application Server (AS) provides support for a number of
+ The JBoss Enterprise Application Platform provides support for a number of
strategies for helping you deploy clustered singleton services. In
this section we will explore the different strategies. All of the
strategies are built on top of the HAPartition service described
@@ -177,7 +177,7 @@
</server>
]]></programlisting>
- <para>Voila! A clustered singleton service.</para>
+ <para>A clustered singleton service.</para>
<para>
The obvious downside to this approach is it only works for
MBeans. Upsides are that the above example can be placed in
@@ -294,7 +294,7 @@
The various clustered singleton management strategies all depend on the fact that each node in the cluster can independently react to changes in cluster membership and correctly decide whether it is now the “master node”. How is this done?
</para>
<para>
- Prior to JBoss AS 4.2.0, the methodology for this was fixed and simple.
+ <!-- Prior to JBoss AS 4.2.0, the methodology for this was fixed and simple. -->
For each member of the cluster, the HAPartition mbean maintains an attribute called the CurrentView, which is basically an ordered list of the current members of the cluster.
As nodes join and leave the cluster, JGroups ensures that each surviving member of the cluster gets an updated view.
You can see the current view by going into the JMX console, and looking at the CurrentView attribute in the <literal>jboss:service=DefaultPartition</literal> mbean.
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -268,7 +268,7 @@
</section>
<section id="clustering-http-state">
<title>Configuring HTTP session state replication</title>
- <para>The preceding discussion has been focused on using mod_jk as a load balancer. The content of the remainder our discussion of clustering HTTP services in JBoss AS applies no matter what load balancer is used.
+ <para>The preceding discussion has been focused on using mod_jk as a load balancer. The content of the remainder our discussion of clustering HTTP services in JBoss Enterprise Application Platform applies no matter what load balancer is used.
</para>
<para>In <xref linkend="clustering-http-nodes"/>, we covered how to use sticky sessions to make sure that a client in a session always hits the same server node in order to maintain the session state. However, sticky sessions by themselves are not an ideal solution. If a node goes down, all its session data is lost. A better and more reliable solution is to replicate session data across the nodes in the cluster. This way, the client can hit any server node and obtain the same session state.</para>
@@ -276,11 +276,11 @@
<para>The <literal>jboss.cache:service=TomcatClusteringCache</literal> MBean makes use of JBoss Cache to
provide HTTP session replication services to the JBoss Tomcat cluster. This MBean is defined in the <literal>deploy/jboss-web-cluster.sar/META-INF/jboss-service.xml file</literal>.</para>
<note>
- <para>Before AS 4.2.0, the location of the HTTP session cache configuration file was <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. Prior to AS 4.0.4 CR2, the file was named <literal>deploy/tc5-cluster-service.xml</literal>. </para>
+ <para>Before JBoss Enterprise Application Platform 4.2.0, the location of the HTTP session cache configuration file was <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. <!-- Prior to Enterprise Application Platform 4.0.4 CR2, the file was named <literal>deploy/tc5-cluster-service.xml</literal>. --></para>
</note>
<para>Below is a typical <literal>deploy/jbossweb-cluster.sar/META-INF/jboss-service.xml</literal> file. The
configuration attributes in the <literal>TomcatClusteringCache</literal> MBean are very similar to
- those in the JBoss AS cache configuration.<!--<xref linkend="jbosscache-cache"/>.--></para>
+ those in the JBoss Enterprise Application Platform cache configuration.<!--<xref linkend="jbosscache-cache"/>.--></para>
<programlisting>
<mbean code="org.jboss.cache.aop.TreeCacheAop"
name="jboss.cache:service=TomcatClusteringCache">
@@ -315,7 +315,7 @@
</mbean>
</programlisting>
- <para>Note that the value of the mbean element's code attribute is org.jboss.cache.aop.TreeCacheAop, which is different from the other JBoss Cache Mbeans used in JBoss AS. This is because FIELD granularity HTTP session replication (covered below) needs the added features of the <literal>TreeCacheAop</literal> (a.k.a. <literal>PojoCache</literal>) class.
+ <para>Note that the value of the mbean element's code attribute is org.jboss.cache.aop.TreeCacheAop, which is different from the other JBoss Cache Mbeans used in JBoss Enterprise Application Platform. This is because FIELD granularity HTTP session replication (covered below) needs the added features of the <literal>TreeCacheAop</literal> (a.k.a. <literal>PojoCache</literal>) class.
</para>
<para>The details of all the configuration options for a TreeCache MBean are covered in the JBoss Cache documentation. Below, we will just discuss several attributes that are most relevant to the HTTP cluster session replication.</para>
@@ -454,7 +454,7 @@
]]></programlisting>
<para>There will be no need to annotate <literal>Student</literal>. It will be annotated automatically because it is a sub-class of <literal>Person</literal>.
-Jboss AS 4.2 requires JDK 5 at runtime, but some users may still need to build their projects using JDK 1.4. In this case, annotating classes can be done via JDK 1.4 style annotations embedded in JavaDocs. For example:
+ Jboss Enterprise Application Platform 4.2 requires JDK 5 at runtime, but some users may still need to build their projects using JDK 1.4. In this case, annotating classes can be done via JDK 1.4 style annotations embedded in JavaDocs. For example:
</para>
@@ -503,7 +503,7 @@
You can see a complete example on how to build, deploy, and validate a FIELD-level replicated web application from this page: <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=Http_session_field_level_example"/>. The example bundles the pre- and post-compile tools so you do not need to download JBoss AOP separately.
</para>
</note>
- <para>When you deploy the web application into JBoss AS, make sure that the following configurations are
+ <para>When you deploy the web application into JBoss Enterprise Application Platform, make sure that the following configurations are
correct:</para>
<itemizedlist>
<listitem>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Introduction.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -17,7 +17,7 @@
</para>
<para>
- The JBoss Application Server (AS) comes with clustering support out of
+ The JBoss Enterprise Application Platform comes with clustering support out of
the box, as part of the <literal>all</literal> configuration. The
<literal>all</literal> configuration includes support for the following:
@@ -67,7 +67,7 @@
<listitem>
<para>Deploying a service or application on multiple nodes in the
cluster but having it active on only one (but at least one)
- node, a.k.a. an "HA Singleton".</para>
+ node is called a <emphasis>HA Singleton</emphasis>.</para>
</listitem>
</itemizedlist>
@@ -75,22 +75,22 @@
<para>
In this <emphasis>Clustering Guide</emphasis> we aim to provide you with
- an in depth understanding of how to use JBoss AS's clustering features.
+ an in depth understanding of how to use JBoss Enterprise Application Platform's clustering features.
In this first part of the guide, the goal is to provide some basic "Quick Start"
- steps to encourage you to start experimenting with JBoss AS Clustering,
+ steps to encourage you to start experimenting with JBoss Enterprise Application Platform Clustering,
and then to provide some background information that will allow you to
- understand how JBoss AS Clustering works. The next part of the
+ understand how JBoss Enterprise Application Platform Clustering works. The next part of the
guide then explains in detail how to use these features to cluster
your JEE services. Finally, we provide some more details about advanced
configuration of JGroups and JBoss Cache, the core technologies that
- underlie JBoss AS Clustering.
+ underlie JBoss Enterprise Application Platform Clustering.
</para>
<section id="clustering-quickstart">
<title>Quick Start Guide</title>
<para>
The goal of this section is to give you the minimum information
- needed to let you get started experimenting with JBoss AS Clustering.
+ needed to let you get started experimenting with JBoss Enterprise Application Platform Clustering.
Most of the areas touched on in this section are covered in much greater
detail later in this guide.
</para>
@@ -98,19 +98,19 @@
<section id="clustering-quickstart-setup">
<title>Initial Preparation</title>
- <para>Preparing a set of servers to act as a JBoss AS cluster
+ <para>Preparing a set of servers to act as a JBoss Enterprise Application Platform cluster
involves a few simple steps:</para>
<itemizedlist>
<listitem>
- <para><emphasis role="bold">Install JBoss AS on all your servers.</emphasis>
+ <para><emphasis role="bold">Install JBoss Enterprise Application Platform on all your servers.</emphasis>
In its simplest form, this is just a matter of unzipping the JBoss
download onto the filesystem on each server. <!-- See the
<emphasis>Administration and Configuration Guide</emphasis> for
full details.--></para>
<para id="clustering-prep-dualconfig">If you want to run multiple
- JBoss AS instances on a single server, you can either install the
+ JBoss Enterprise Application Platform instances on a single server, you can either install the
full JBoss distribution onto multiple locations on your filesystem,
or you can simply make copies of the <literal>all</literal>
configuration. For example, assuming the root of the JBoss distribution
@@ -133,7 +133,7 @@
<listitem>
<para><emphasis role="bold">Ensure multicast is working.</emphasis>
- By default JBoss AS uses UDP multicast for most intra-cluster
+ By default JBoss Enterprise Application Platform uses UDP multicast for most intra-cluster
communications. Make sure each server's networking configuration
supports multicast and that multicast support is enabled for any
switches or routers between your servers. If you are planning to
@@ -145,8 +145,8 @@
</para>
<note>
- <para>JBoss AS clustering does not require the use of UDP multicast;
- the AS can also be reconfigured to use TCP unicast for intra-cluster
+ <para>JBoss Enterprise Application Platform clustering does not require the use of UDP multicast;
+ the Enterprise Application Platform can also be reconfigured to use TCP unicast for intra-cluster
communication.</para>
</note>
</listitem>
@@ -166,13 +166,13 @@
<para>Beyond the above required steps, the following two optional steps are
recommended to help ensure that your cluster is properly isolated
- from other JBoss AS clusters that may be running on your network:</para>
+ from other JBoss Enterprise Application Platform clusters that may be running on your network:</para>
<itemizedlist>
<listitem>
<para id="clustering-prep-clustername">
<emphasis role="bold">Pick a unique name for your cluster.</emphasis>
- The default name for a JBoss AS cluster is "DefaultPartition". Come
+ The default name for a JBoss Enterprise Application Platform cluster is "DefaultPartition". Come
up with a different name for each cluster in your environment, e.g.
"QAPartition" or "BobsDevPartition". The use of "Partition" is not
required; it's just a semi-convention. As a small aid to performance
@@ -185,7 +185,7 @@
<listitem>
<para id="clustering-prep-mcastaddr">
<emphasis role="bold">Pick a unique multicast address for your cluster.</emphasis>
- By default JBoss AS uses UDP multicast for most intra-cluster
+ By default JBoss Enterprise Application Platform uses UDP multicast for most intra-cluster
communication. Pick a different multicast address for each cluster
you run. Generally a good multicast address is of the form
<literal>239.255.x.y</literal>. See
@@ -203,7 +203,7 @@
</section>
<section id="clustering-quickstart-launching">
- <title>Launching a JBoss AS Cluster</title>
+ <title>Launching a JBoss Enterprise Application Platform Cluster</title>
<para>The simplest way to start a JBoss server cluster is to start
several JBoss instances on the same local network, using the
<literal>-c all</literal> command line option for each instance. Those
@@ -268,7 +268,7 @@
<literal>192.168.0.102</literal> addresses assigned, and that the two
JBoss instances use the same addresses and ServerPeerIDs as in
Scenario 1. The difference from Scenario 1 is we need to be sure
- each AS instance has its own work area. So, instead of using
+ each Enterprise Application Platform instance has its own work area. So, instead of using
the <literal>all</literal> config, we are going to use the
<literal>node1</literal> and <literal>node2</literal> configs we
copied from <literal>all</literal> in
@@ -338,12 +338,12 @@
</itemizedlist>
<para>That's it; that's all it takes to get a cluster of JBoss
- AS servers up and running.</para>
+ Enterprise Application Platform servers up and running.</para>
</section>
<section id="clustering-quickstart-http">
<title>Web Application Clustering Quick Start</title>
- <para>JBoss AS supports clustered web sessions, where a backup
+ <para>JBoss Enterprise Application Platform supports clustered web sessions, where a backup
copy of each user's <literal>HttpSession</literal> state is stored
on one or more nodes in the cluster. In case the primary node
handling the session fails or is shut down, any other node in the
@@ -356,9 +356,9 @@
<itemizedlist>
<listitem><para><emphasis role="bold">Configuring an External
Load Balancer</emphasis>. Web applications require an external
- load balancer to balance HTTP requests across the cluster of JBoss AS
+ load balancer to balance HTTP requests across the cluster of JBoss Enterprise Application Platform
instances (see <xref linkend="clustering-concepts-arch-balancer"/>
- for more on why that is). JBoss AS itself doesn't act as an HTTP load
+ for more on why that is). JBoss Enterprise Application Platform itself doesn't act as an HTTP load
balancer. So, you will need to set up a hardware or software
load balancer. There are many possible load balancer choices,
so how to configure one is really beyond the scope of a Quick Start.
@@ -382,7 +382,7 @@
</web-app></programlisting>
- <para>Simply doing that is enough to get the default JBoss AS
+<para>Simply doing that is enough to get the default JBoss Enterprise Application Platform
web session clustering behavior, which is appropriate for most
applications. See <xref linkend="clustering-http-state"/> for
more advanced configuration options.</para>
@@ -393,7 +393,7 @@
<section id="clustering-quickstart-ejbsessions">
<title>EJB Session Bean Clustering Quick Start</title>
- <para>JBoss AS supports clustered EJB session beans, whereby
+ <para>JBoss Enterprise Application Platform supports clustered EJB session beans, whereby
requests for a bean are balanced across the cluster. For
stateful beans a backup copy of bean state is maintained on one
or more cluster nodes, providing high availability in case the
@@ -436,7 +436,7 @@
<section id="clustering-quickstart-ejb3entities">
<title>Entity Clustering Quick Start</title>
- <para>One of the big improvements in the clustering area in JBoss AS 5
+ <para>One of the big improvements in the clustering area in JBoss Enterprise Application Platform 5
is the use of the new Hibernate/JBoss Cache integration for second level
entity caching that was introduced in Hibernate 3.3. In the JPA/Hibernate
context, a second level cache refers to a cache whose contents are
@@ -446,12 +446,12 @@
with second level caching enabled and disabled to see whether
it has a beneficial impact on your particular application.</para>
- <para>If you use more than one JBoss AS instance to run your
+ <para>If you use more than one JBoss Enterprise Application Platform instance to run your
JPA/Hibernate application and you use second level caching, you must
use a cluster-aware cache. Otherwise a cache on server A will still
hold out-of-date data after activity on server B updates some entities.</para>
- <para>JBoss AS provides a cluster-aware second level cache based on JBoss Cache.
- To tell JBoss AS's standard Hibernate-based JPA provider to enable
+ <para>JBoss Enterprise Application Platform provides a cluster-aware second level cache based on JBoss Cache.
+ To tell JBoss Enterprise Application Platform's standard Hibernate-based JPA provider to enable
second level caching with JBoss Cache, configure your
<literal>persistence.xml</literal> as follows:</para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -4,24 +4,24 @@
<chapter id="jbosscache.chapt">
<title>JBoss Cache Configuration and Deployment</title>
<para>JBoss Cache provides the underlying distributed caching support used
- by many of the standard clustered services in a JBoss AS cluster. You can
+ by many of the standard clustered services in a JBoss Enterprise Application Platform cluster. You can
also deploy JBoss Cache in your own application to handle custom caching
requirements. In this chapter we provide some background on the main
configuration options available with JBoss Cache, with an emphasis on
how those options relate to the JBoss Cache usage by the standard clustered
- services the AS provides. We then discuss the different options available
- for deploying a custom cache in the AS.
+ services the Enterprise Application Platform provides. We then discuss the different options available
+ for deploying a custom cache in the Enterprise Application Platform.
</para>
<para>Users considering deploying JBoss Cache for direct use by their own
application are strongly encouraged to read the JBoss Cache
documentation available at http://www.jboss.org/jbosscache.</para>
<para>See also <xref linkend="clustering-blocks-jbc"/> for information on
- how the standard JBoss AS clustered services use JBoss Cache.</para>
+ how the standard JBoss Enterprise Application Platform clustered services use JBoss Cache.</para>
<section id="jbosscache-configuration">
<title>Key JBoss Cache Configuration Options</title>
- <para>JBoss AS ships with a reasonable set of default JBoss Cache
+ <para>JBoss Enterprise Application Platform ships with a reasonable set of default JBoss Cache
configurations that are suitable for the standard clustered service
use cases (e.g. web session replication or JPA/Hibernate caching).
Most applications that involve the standard
@@ -36,8 +36,8 @@
<para>Most JBoss Cache configuration examples in this section use the
JBoss Microcontainer schema for building up an <literal>org.jboss.cache.config.Configuration</literal>
object graph from XML. JBoss Cache has its own custom XML schema, but
- the standard JBoss AS CacheManager service uses the JBoss Microcontainer
- schema to be consistent with most other internal AS services.</para>
+ the standard JBoss Enterprise Application Platform CacheManager service uses the JBoss Microcontainer
+ schema to be consistent with most other internal Enterprise Application Platform services.</para>
<para>Before getting into the key configuration options, let's have a
look at the most likely place that a user would encounter them.</para>
@@ -45,7 +45,7 @@
<section id="jbosscache-configuration-cachemanager">
<title>Editing the CacheManager Configuration</title>
<para>As discussed in <xref linkend="clustering-blocks-jbc-cachemanager"/>,
- the standard JBoss AS clustered services use the CacheManager service
+ the standard JBoss Enterprise Application Platform clustered services use the CacheManager service
as a factory for JBoss Cache instances. So, cache configuration changes
are likely to involve edits to the CacheManager service.</para>
@@ -133,13 +133,13 @@
of child Java Beans for some of the more complex sub-configurations
(i.e. cache loading, eviction, buddy replication). Rather than
delegating this task of XML parsing/Java Bean creation to JBC, we
- let the AS's microcontainer do it directly. This has the advantage
+ let the Enterprise Application Platform's microcontainer do it directly. This has the advantage
of making the microcontainer aware of the configuration beans, which
- in later AS 5.x releases will be helpful in allowing external
+ in later Enterprise Application Platform 5.x releases will be helpful in allowing external
management tools to manage the JBC configurations.</para>
<para>The configuration format should be fairly self-explanatory if
- you look at the standard configurations the AS ships; they include
+ you look at the standard configurations the Enterprise Application Platform ships; they include
all the major elements. The types and properties of the various java
beans that make up a JBoss Cache configuration can be seen in the
JBoss Cache javadocs. Here is a fairly complete example:</para>
@@ -385,7 +385,7 @@
<para>Integration with a transaction manager is accomplished by
setting the <literal>transactionManagerLookupClass</literal> configuration
attribute; this specifies the fully qualified class name of a class JBoss Cache
- can use to find the local transaction manager. Inside JBoss AS, this
+ can use to find the local transaction manager. Inside JBoss Enterprise Application Platform, this
attribute would have one of two values:</para>
<itemizedlist>
@@ -402,7 +402,7 @@
that ships with JBoss Cache called the <literal>BatchModeTransactionManager</literal>.
This transaction manager is not a true JTA transaction manager and
should not be used for anything other than JBoss Cache. Its usage
- in JBoss AS is to get most of the benefits of JBoss Cache's transactional
+ in JBoss Enterprise Application Platform is to get most of the benefits of JBoss Cache's transactional
behavior for the session replication use cases, but without getting
tangled up with end user transactions that may run during a request.
</para>
@@ -458,11 +458,11 @@
reads.</para>
<para>Generally MVCC is a better choice than PESSIMISTIC, which is
deprecated as of JBoss Cache 3.0. But, for the session caching usage
- in JBoss AS 5.0.0, PESSIMISTIC is still the default. This is largely
- because 1) for the session use case there are generally not concurrent
+ in JBoss Enterprise Application Platform 5.0.0, PESSIMISTIC is still the default. This is largely
+ because for the session use case there are generally not concurrent
threads accessing the same cache location, so the benefits of MVCC
- are not as great, and 2) the AS development team wanted to continue
- to evaluate MVCC in the session use case before moving to it as the default.</para>
+ are not as great. <!--, and 2) the Enterprise Application Platform development team wanted to continue
+ to evaluate MVCC in the session use case before moving to it as the default.--></para>
</listitem>
<listitem>
<para><emphasis role="bold">OPTIMISTIC</emphasis> locking seeks to
@@ -500,8 +500,8 @@
<title>JGroups Integration</title>
<para>Each JBoss Cache instance internally uses a JGroups <literal>Channel</literal>
- to handle group communications. Inside JBoss AS, we strongly recommend
- that you use the AS's JGroups Channel Factory service <!--(see
+ to handle group communications. Inside JBoss Enterprise Application Platform, we strongly recommend
+ that you use the Enterprise Application Platform's JGroups Channel Factory service <!--(see
<xref linkend="clustering-blocks-jgroups-channelfactory"/>)--> as the
source for your cache's <literal>Channel</literal>. In this section
we discuss how to configure your cache to get it's channel from
@@ -575,7 +575,7 @@
http://www.jboss.org/jbossclustering/docs/hibernate-jbosscache-guide-3.pdf.
For web session caches, eviction should not be configured; the
distributable session manager handles eviction itself. For EJB 3
- SFSB caches, stick with the eviction configuration in the AS's standard
+ SFSB caches, stick with the eviction configuration in the Enterprise Application Platform's standard
<literal>sfsb-cache</literal> configuration (see
<xref linkend="clustering-blocks-jbc-cachemanager"/>). The EJB container
will configure eviction itself using the values included in each bean's
@@ -617,7 +617,7 @@
Cache Loader passivaton.</para>
<para>In most cases you don't need to do anything to alter the cache
loader configurations for the standard web session and SFSB caches;
- the standard JBoss AS configurations should suit your needs. The
+ the standard JBoss Enterprise Application Platform configurations should suit your needs. The
following is a bit more detail in case you're interested or want to
change from the defaults.</para>
@@ -676,7 +676,7 @@
<listitem><para><emphasis role="bold">location</emphasis> property for
FileCacheLoaderConfig defines the root node of the filesystem tree where
passivated sessions should be stored. The default is to store them in
- your JBoss AS configuration's <literal>data</literal> directory.</para></listitem>
+ your JBoss Enterprise Application Platform configuration's <literal>data</literal> directory.</para></listitem>
<listitem><para><emphasis role="bold">async</emphasis> MUST be
<literal>false</literal> to ensure passivated sessions are promptly
written to the persistent store.</para></listitem>
@@ -798,7 +798,7 @@
<title>Deploying Your Own JBoss Cache Instance</title>
<para>It's quite common for users to deploy their own instances of
- JBoss Cache inside JBoss AS for custom use by their applications.
+ JBoss Cache inside JBoss Enterprise Application Platform for custom use by their applications.
In this section we describe the various ways caches can be
deployed.</para>
@@ -806,7 +806,7 @@
<title>Deployment Via the CacheManager Service</title>
<para>The standard JBoss clustered services that use JBoss Cache
- obtain a reference to their cache from the AS's CacheManager service
+ obtain a reference to their cache from the Enterprise Application Platform's CacheManager service
(see <xref linkend="clustering-blocks-jbc-cachemanager"/>). End
user applications can do the same thing; here's how.</para>
@@ -874,7 +874,7 @@
}]]></programlisting>
</listitem>
<listitem><para><emphasis role="bold">CacheManagerLocator</emphasis></para>
- <para>JBoss AS also provides a service locator object that can
+ <para>JBoss Enterprise Application Platform also provides a service locator object that can
be used to access the CacheManager.</para>
<programlisting><![CDATA[
@@ -887,7 +887,7 @@
public void start() throws Exception {
CacheManagerLocator locator = CacheManagerLocator.getCacheManagerLocator();
// Locator accepts as param a set of JNDI properties to help in lookup;
- // this isn't necessary inside the AS
+ // this isn't necessary inside the Enterprise Application Platform
cacheManager = locator.getCacheManager(null);
}
}]]></programlisting>
@@ -1009,7 +1009,7 @@
<title>Deployment Via a <literal>-jboss-beans.xml</literal> File</title>
<para>Much like it can deploy MBean services described with a
- <literal>-service.xml</literal>, JBoss AS 5 can also deploy services
+ <literal>-service.xml</literal>, JBoss Enterprise Application Platform 5 can also deploy services
that consist of Plain Old Java Objects (POJOs) if the POJOs are described
using the JBoss Microcontainer schema in a <literal>-jboss-beans.xml</literal>
file. You create such a file and deploy it, either directly in the
@@ -1081,7 +1081,7 @@
<literal>TransactionManager</literal> and a JGroups <literal>ChannelFactory</literal>
that are visible to the microcontainer are dependency injected into the
<literal>RuntimeConfig</literal>. The assumption here is that in some
- other deployment descriptor in the AS, the referenced beans have already
+ other deployment descriptor in the Enterprise Application Platform, the referenced beans have already
been described.</para>
<para>Using the configuration above, the "ExampleCache" cache will not
@@ -1122,7 +1122,7 @@
a JBoss Cache class that provides an MBean interface for a cache.
Adding an <annotation> element binds the JBoss Microcontainer
<literal>@JMX</literal> annotation to the bean; that in turn results
- in JBoss AS registering the bean in JXM as part of the deployment process.
+ in JBoss Enterprise Application Platform registering the bean in JXM as part of the deployment process.
</para>
<para>The actual underlying <literal>org.jboss.cache.Cache</literal> instance
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -7,10 +7,10 @@
<indexterm><primary>Clustering</primary><secondary>JBossCache and JGroups Services</secondary></indexterm>
JGroups and JBossCache provide the underlying communication, node replication and caching services, for
- JBoss AS clusters. Those services are configured as MBeans. There is a set of JBossCache and JGroups MBeans
+ JBoss Enterprise Application Platform clusters. Those services are configured as MBeans. There is a set of JBossCache and JGroups MBeans
for each type of clustering applications (e.g., the Stateful Session EJBs, HTTP session replication etc.).
</para>
- <para>The JBoss AS ships with a reasonable set of default JGroups and JBossCache MBean configurations. Most
+ <para>The JBoss Enterprise Application Platform ships with a reasonable set of default JGroups and JBossCache MBean configurations. Most
applications just work out of the box with the default MBean configurations. You only need to tweak them
when you are deploying an application that has special network or performance requirements.</para>
@@ -1054,7 +1054,7 @@
First, it's important to understand that the value set in any bind_addr element in an XML configuration file will be ignored by JGroups if it finds that system property jgroups.bind_addr (or a deprecated earlier name for the same thing, <literal>bind.address</literal>) has been set. The system property trumps XML. If JBoss AS is started with the -b (a.k.a. --host) switch, the AS will set <literal>jgroups.bind_addr</literal> to the specified value.
</para>
<para>
- Beginning with AS 4.2.0, for security reasons the AS will bind most services to localhost if -b is not set. The effect of this is that in most cases users are going to be setting -b and thus jgroups.bind_addr is going to be set and any XML setting will be ignored.
+ Beginning with Enterprise Application Platform 4.2.0, for security reasons the Enterprise Application Platform will bind most services to localhost if -b is not set. The effect of this is that in most cases users are going to be setting -b and thus jgroups.bind_addr is going to be set and any XML setting will be ignored.
</para>
<para>
So, what are <emphasis>best practices</emphasis> for managing how JGroups binds to interfaces?
@@ -1105,7 +1105,7 @@
<section><title>Isolating JGroups Channels</title>
<para>
- Within JBoss AS, there are a number of services that independently create JGroups channels -- 3 different JBoss Cache services (used for HttpSession replication, EJB3 SFSB replication and EJB3 entity replication) along with the general purpose clustering service called HAPartition that underlies most other JBossHA services.
+ Within JBoss Enterprise Application Platform, there are a number of services that independently create JGroups channels -- 3 different JBoss Cache services (used for HttpSession replication, EJB3 SFSB replication and EJB3 entity replication) along with the general purpose clustering service called HAPartition that underlies most other JBossHA services.
</para>
<para>
It is critical that these channels only communicate with their intended peers; not with the channels used by other services and not with channels for the same service opened on machines not meant to be part of the group. Nodes improperly communicating with each other is one of the most common issues users have with JBoss AS clustering.
@@ -1133,7 +1133,7 @@
The group name for a JGroups channel is configured via the service that starts the channel. Unfortunately, different services use different attribute names for configuring this. For HAPartition and related services configured in the deploy/cluster-service.xml file, this is configured via a PartitionName attribute. For JBoss Cache services, the name of the attribute is ClusterName.
</para>
<para>
- Starting with JBoss AS 4.0.4, for the HAPartition and all the standard JBoss Cache services, we make it easy for you to create unique groups names simply by using the -g (a.k.a. –partition) switch when starting JBoss:
+ For the HAPartition and all the standard JBoss Cache services, we make it easy for you to create unique groups names simply by using the -g (a.k.a. –partition) switch when starting JBoss:
<screen>./run.sh -g QAPartition -b 192.168.1.100 -c all</screen>
This switch sets the jboss.partition.name system property, which is used as a component in the configuration of the group name in all the standard clustering configuration files. For example,
<screen><![CDATA[<attribute name="ClusterName">Tomcat-${jboss.partition.name:Cluster}</attribute>]]></screen>
@@ -1146,7 +1146,7 @@
<para>
The -u (a.k.a. --udp) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard AS services.
<screen><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c all]]></screen>
- This switch sets the jboss.partition.udpGroup system property, which you can see referenced in all of the standard protocol stack configs in JBoss AS:
+This switch sets the jboss.partition.udpGroup system property, which you can see referenced in all of the standard protocol stack configs in JBoss Enterprise Application Platform:
</para>
<programlisting><![CDATA[<Config>
@@ -1154,7 +1154,7 @@
....]]>
</programlisting>
<para>
- Unfortunately, setting the multicast ports is not so simple. As described above, by default there are four separate JGroups channels in the standard JBoss AS all configuration, and each should be given a unique port. There are no command line switches to set these, but the standard configuration files do use system properties to set them. So, they can be configured from the command line by using -D. For example,
+ Unfortunately, setting the multicast ports is not so simple. As described above, by default there are four separate JGroups channels in the standard JBoss Enterprise Application Platform all configuration, and each should be given a unique port. There are no command line switches to set these, but the standard configuration files do use system properties to set them. So, they can be configured from the command line by using -D. For example,
</para>
<programlisting>
/run.sh -u 230.1.2.3 -g QAPartition -Djboss.hapartition.mcast_port=12345 -Djboss.webpartition.mcast_port=23456 -Djboss.ejb3entitypartition.mcast_port=34567 -Djboss.ejb3sfsbpartition.mcast_port=45678 -b 192.168.1.100 -c all
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -4,7 +4,7 @@
<chapter id="jgroups.chapt">
<title>JGroups Services</title>
<para>JGroups provides the underlying group communication support for
- JBoss AS clusters. JBoss AS ships with a reasonable set of default JGroups
+ JBoss Enterprise Application Platform clusters. JBoss Enterprise Application Platform ships with a reasonable set of default JGroups
configurations. Most applications just work out of the box with the
default configurations. You only need to tweak them when you are
deploying an application that has special network or performance requirements.</para>
@@ -1044,10 +1044,10 @@
In the Transport Protocols section above, we briefly touched on how the interface to which JGroups will bind sockets is configured. Let's get into this topic in more depth:
</para>
<para>
- First, it's important to understand that the value set in any bind_addr element in an XML configuration file will be ignored by JGroups if it finds that system property jgroups.bind_addr (or a deprecated earlier name for the same thing, <literal>bind.address</literal>) has been set. The system property trumps XML. If JBoss AS is started with the -b (a.k.a. --host) switch, the AS will set <literal>jgroups.bind_addr</literal> to the specified value.
+ First, it's important to understand that the value set in any bind_addr element in an XML configuration file will be ignored by JGroups if it finds that system property jgroups.bind_addr (or a deprecated earlier name for the same thing, <literal>bind.address</literal>) has been set. The system property trumps XML. If JBoss Enterprise Application Platform is started with the -b (a.k.a. --host) switch, the Enterprise Application Platform will set <literal>jgroups.bind_addr</literal> to the specified value.
</para>
<para>
- Beginning with AS 4.2.0, for security reasons the AS will bind most services to localhost if -b is not set. The effect of this is that in most cases users are going to be setting -b and thus jgroups.bind_addr is going to be set and any XML setting will be ignored.
+ Beginning with Enterprise Application Platform 4.2.0, for security reasons the Enterprise Application Platform will bind most services to localhost if -b is not set. The effect of this is that in most cases users are going to be setting -b and thus jgroups.bind_addr is going to be set and any XML setting will be ignored.
</para>
<para>
So, what are <emphasis>best practices</emphasis> for managing how JGroups binds to interfaces?
@@ -1098,16 +1098,16 @@
<section id="clustering-jgroups-isolation"><title>Isolating JGroups Channels</title>
<para>
- Within JBoss AS, there are a number of services that independently create JGroups channels -- 3 different JBoss Cache services (used for HttpSession replication, EJB3 SFSB replication and EJB3 entity replication) along with the general purpose clustering service called HAPartition that underlies most other JBossHA services.
+ Within JBoss Enterprise Application Platform, there are a number of services that independently create JGroups channels -- 3 different JBoss Cache services (used for HttpSession replication, EJB3 SFSB replication and EJB3 entity replication) along with the general purpose clustering service called HAPartition that underlies most other JBossHA services.
</para>
<para>
- It is critical that these channels only communicate with their intended peers; not with the channels used by other services and not with channels for the same service opened on machines not meant to be part of the group. Nodes improperly communicating with each other is one of the most common issues users have with JBoss AS clustering.
+ It is critical that these channels only communicate with their intended peers; not with the channels used by other services and not with channels for the same service opened on machines not meant to be part of the group. Nodes improperly communicating with each other is one of the most common issues users have with JBoss Enterprise Application Platform clustering.
</para>
<para>
Whom a JGroups channel will communicate with is defined by its group name, multicast address, and multicast port, so isolating JGroups channels comes down to ensuring different channels use different values for the group name, multicast address and multicast port.
</para>
<para>
- To isolate JGroups channels for different services on the same set of AS instances from each other, you MUST change the group name and the multicast port. In other words, each channel must have its own set of values.
+ To isolate JGroups channels for different services on the same set of Enterprise Application Platform instances from each other, you MUST change the group name and the multicast port. In other words, each channel must have its own set of values.
</para>
<para>
For example, say we have a production cluster of 3 machines, each of which has an HAPartition deployed along with a JBoss Cache used for web session clustering. The HAPartition channels should not communicate with the JBoss Cache channels. They should use a different group name and multicast port. They can use the same multicast address, although they don't need to.
@@ -1125,7 +1125,7 @@
The group name for a JGroups channel is configured via the service that starts the channel. Unfortunately, different services use different attribute names for configuring this. For HAPartition and related services configured in the deploy/cluster-service.xml file, this is configured via a PartitionName attribute. For JBoss Cache services, the name of the attribute is ClusterName.
</para>
<para>
- Starting with JBoss AS 4.0.4, for the HAPartition and all the standard JBoss Cache services, we make it easy for you to create unique groups names simply by using the -g (a.k.a. –partition) switch when starting JBoss:
+ The HAPartition and all the standard JBoss Cache services, make it easy for you to create unique groups names simply by using the -g (a.k.a. –partition) switch when starting JBoss:
<screen>./run.sh -g QAPartition -b 192.168.1.100 -c all</screen>
This switch sets the jboss.partition.name system property, which is used as a component in the configuration of the group name in all the standard clustering configuration files. For example,
<screen><![CDATA[<attribute name="ClusterName">Tomcat-${jboss.partition.name:Cluster}</attribute>]]></screen>
@@ -1136,9 +1136,9 @@
<section><title>Changing the multicast address and port</title>
<para>
- The -u (a.k.a. --udp) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard AS services.
+ The -u (a.k.a. --udp) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard Enterprise Application Platform services.
<screen><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c all]]></screen>
- This switch sets the jboss.partition.udpGroup system property, which you can see referenced in all of the standard protocol stack configs in JBoss AS:
+This switch sets the jboss.partition.udpGroup system property, which you can see referenced in all of the standard protocol stack configs in JBoss Enterprise Application Platform:
</para>
<programlisting><![CDATA[<Config>
@@ -1146,7 +1146,7 @@
....]]>
</programlisting>
<para>
- Unfortunately, setting the multicast ports is not so simple. As described above, by default there are four separate JGroups channels in the standard JBoss AS all configuration, and each should be given a unique port. There are no command line switches to set these, but the standard configuration files do use system properties to set them. So, they can be configured from the command line by using -D. For example,
+ Unfortunately, setting the multicast ports is not so simple. As described above, by default there are four separate JGroups channels in the standard JBoss Enterprise Application Platform all configuration, and each should be given a unique port. There are no command line switches to set these, but the standard configuration files do use system properties to set them. So, they can be configured from the command line by using -D. For example,
</para>
<programlisting>
/run.sh -u 230.1.2.3 -g QAPartition -Djboss.hapartition.mcast_port=12345 -Djboss.webpartition.mcast_port=23456 -Djboss.ejb3entitypartition.mcast_port=34567 -Djboss.ejb3sfsbpartition.mcast_port=45678 -b 192.168.1.100 -c all
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -11,14 +11,14 @@
<listitem>
<para>
Transparent failover of naming operations. If an HA-JNDI naming
- Context is connected to the HA-JNDI service on a particular JBoss AS
+ Context is connected to the HA-JNDI service on a particular JBoss Enterprise Application Platform
instance, and that service fails or is shut down, the HA-JNDI client
- can transparently fail over to another AS instance.
+ can transparently fail over to another Enterprise Application Platform instance.
</para>
</listitem>
<listitem>
<para>
- Load balancing of naming operations. An HA-JNDI naming Context will
+ Load balancing of naming operations. A HA-JNDI naming Context will
automatically load balance its requests across all the HA-JNDI
servers in the cluster.
</para>
@@ -219,7 +219,7 @@
<para>Configuring a client to use HA-JNDI is a matter of ensuring the
correct set of naming environment properties are available when a new
<literal>InitialContext</literal> is created. How this is done varies
- depending on whether the client is running inside JBoss AS itself or
+ depending on whether the client is running inside JBoss Enterprise Application Platform itself or
is in another VM.</para>
@@ -243,13 +243,13 @@
By default this service listens on the interface named via the
<literal>jboss.bind.address</literal> system property, which itself is set to
whatever value you assign to the <literal>-b</literal> command line option when
-you start JBoss AS (or <literal>localhost</literal> if not specified). The above
+you start JBoss Enterprise Application Platform (or <literal>localhost</literal> if not specified). The above
code shows an example of accessing this property.
</para>
<para>
However, this does not work in all cases, especially when running several
- JBoss AS instances on the same machine and bound to the same IP address, but
+ JBoss Enterprise Application Platform instances on the same machine and bound to the same IP address, but
configured to use different ports. A safer method is to not specify the
Context.PROVIDER_URL but instead allow the <literal>InitialContext</literal>
to statically find the in-VM HA-JNDI by specifying the <literal>jnp.partitionName</literal>
@@ -266,13 +266,13 @@
<para>This example uses the <literal>jboss.partition.name</literal> system
property to identify the partition with which the HA-JNDI service works. This
system property is set to whatever value you assign to the <literal>-g</literal>
-command line option when you start JBoss AS (or <literal>DefaultPartition</literal>
+command line option when you start JBoss Enterprise Application Platform (or <literal>DefaultPartition</literal>
if not specified).
</para>
<para>
Do not attempt to simplify things by placing a <literal>jndi.properties</literal>
- file in your deployment or by editing the AS's <literal>conf/jndi.properties</literal>
+ file in your deployment or by editing the Enterprise Application Platform's <literal>conf/jndi.properties</literal>
file. Doing either will almost certainly break things for your application
and quite possibly across the application server. If you want to externalize
your client configuration, one approach is to deploy a properties file not
@@ -329,7 +329,7 @@
<para>The <literal>${jboss.bind.address}</literal> syntax used above tells JBoss
to use the value of the <literal>jboss.bind.address</literal> system property
when determining the URL. That system property is itself set to whatever value
- you assign to the <literal>-b</literal> command line option when you start JBoss AS.
+ you assign to the <literal>-b</literal> command line option when you start JBoss Enterprise Application Platform.
</para>
</section>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -5,12 +5,12 @@
<chapter id="Deployment">
<title>Deployment</title>
- <para>Deploying applications on JBoss AS is very easy. You just need to copy the application into the JBOSS_HOME/server/default/deploy directory. You can replace default with different server profiles such as all or minimal. We will cover those later in this chapter. JBoss AS constantly scans the deploy directory to pick up new applications or any changes to existing applications. So, you can "hot deploy" application on the fly while JBoss AS is still running.</para>
+ <para>Deploying applications on JBoss Enterprise Application Platform is very easy. You just need to copy the application into the JBOSS_HOME/server/default/deploy directory. You can replace default with different server profiles such as all or minimal. We will cover those later in this chapter. JBoss Enterprise Application Platform constantly scans the deploy directory to pick up new applications or any changes to existing applications. So, you can "hot deploy" application on the fly while JBoss Enterprise Application Platform is still running.</para>
<section id="Deployable_Application_Types">
<title>Deployable Application Types</title>
- <para>With JBossAS 4.x and earlier, a deployer existed to handle a specified deployment type and that was the only deployer that would process the deployment. In JBossAS 5, multiple deployers typically transform the metadata associated with a deployment until its processed by a deployer that creates a runtime component from the metadata. The old deployment type notion based on suffix is a weaker notion. Instead, the deployment has to contain a descriptor that causes the component metadata to be added to the deployment. The types of deployments for which deployers exists by default in JBoss AS include:</para>
+ <para>With JBoss Enterprise Application Platform 4.x and earlier, a deployer existed to handle a specified deployment type and that was the only deployer that would process the deployment. In JBoss Enterprise Application Platform 5, multiple deployers typically transform the metadata associated with a deployment until its processed by a deployer that creates a runtime component from the metadata. The old deployment type notion based on suffix is a weaker notion. Instead, the deployment has to contain a descriptor that causes the component metadata to be added to the deployment. The types of deployments for which deployers exists by default in Enterprise Application Platform include:</para>
<itemizedlist>
<listitem>
@@ -25,16 +25,16 @@
<listitem>
<indexterm><primary>JBoss Microcontainer</primary><secondary>beans deployment type</secondary></indexterm>
- <para>The JBoss Microcontainer (MC) beans archive (typical suffixes include, .beans, .deployer) packages a POJO deployment in a JAR file with a META-INF/jboss-beans.xml descriptor. This format is commonly used by the JBossAS component deployers.</para></listitem>
+ <para>The JBoss Microcontainer (MC) beans archive (typical suffixes include, .beans, .deployer) packages a POJO deployment in a JAR file with a META-INF/jboss-beans.xml descriptor. This format is commonly used by the JBoss Enterprise Application Platform component deployers.</para></listitem>
<listitem>
<indexterm><primary>SAR</primary><see>Service Archive</see></indexterm>
<indexterm><primary>Service Archive</primary><secondary>deployment type</secondary></indexterm>
- <para>The SAR application archive (e.g., myservice.sar) packages a JBoss service in a JAR file. It is mostly used by JBossAS internal services that have not been updated to support MC beans style deployments.</para></listitem>
+ <para>The SAR application archive (e.g., myservice.sar) packages a JBoss service in a JAR file. It is mostly used by JBoss Enterprise Application Platform internal services that have not been updated to support MC beans style deployments.</para></listitem>
<listitem>
<indexterm><primary>DataSource</primary><secondary>deployment type</secondary></indexterm>
- <para>The *-ds.xml file defines connections to external databases. The data source can then be reused by all applications and services in JBoss AS via the internal JNDI.</para></listitem>
+ <para>The *-ds.xml file defines connections to external databases. The data source can then be reused by all applications and services in JBoss Enterprise Application Platform via the internal JNDI.</para></listitem>
<listitem>
<indexterm><primary>JBoss Microcontainer</primary><secondary>*-jboss-beans.xml deployment type</secondary></indexterm>
@@ -43,16 +43,16 @@
<listitem>
<indexterm><primary>Service Archive</primary><secondary>*-service.xml deployment type</secondary></indexterm>
- <para>You can deploy *-service.xml files with MBean service definitions. If you have the appropriate JAR files available in the deploy or lib directories, the MBeans specified in the XML files will be started. This is the way you deploy many JBoss AS internal services that have not been updated to support POJO style deployment, such as the JMS queues.</para></listitem>
+ <para>You can deploy *-service.xml files with MBean service definitions. If you have the appropriate JAR files available in the deploy or lib directories, the MBeans specified in the XML files will be started. This is the way you deploy many JBoss Enterprise Application Platform internal services that have not been updated to support POJO style deployment, such as the JMS queues.</para></listitem>
- <listitem><para>You can also deploy JAR files containing EJBs or other service objects directly in JBoss AS. The list of suffixes that are recognized as JAR files is specified in the conf/bootstrap/deployers.xml JARStructure bean constructor set.</para></listitem>
+<listitem><para>You can also deploy JAR files containing EJBs or other service objects directly in JBoss Enterprise Application Platform. The list of suffixes that are recognized as JAR files is specified in the conf/bootstrap/deployers.xml JARStructure bean constructor set.</para></listitem>
</itemizedlist>
<note>
<title>Exploded Deployment</title>
<indexterm><primary>Exploded Deployment</primary></indexterm>
- <para>The WAR, EAR, MC beans and SAR deployment packages are really just JAR files with special XML deployment descriptors in directories like META-INF and WEB-INF. JBoss AS allows you to deploy those archives as expanded directories instead of JAR files. That allows you to make changes to web pages etc on the fly without re-deploying the entire application. If you do need to re-deploy the exploded directory without re-start the server, you can just "touch" the deployment descriptors (e.g., the WEB-INF/web.xml in a WAR and the META-INF/application.xml in an EAR) to update their timestamps.</para>
+ <para>The WAR, EAR, MC beans and SAR deployment packages are really just JAR files with special XML deployment descriptors in directories like META-INF and WEB-INF. JBoss Enterprise Application Platform allows you to deploy those archives as expanded directories instead of JAR files. That allows you to make changes to web pages etc on the fly without re-deploying the entire application. If you do need to re-deploy the exploded directory without re-start the server, you can just "touch" the deployment descriptors (e.g., the WEB-INF/web.xml in a WAR and the META-INF/application.xml in an EAR) to update their timestamps.</para>
</note>
</section>
@@ -62,13 +62,13 @@
<indexterm><primary>Server Configuration</primary><see>Server Profile</see></indexterm>
<indexterm><primary>Server Profile</primary><secondary>definition</secondary></indexterm>
- <para>The JBoss Application Server ships with five server profiles. You can choose which configuration to start by passing the -c parameter to the server startup script. For instance, command run.sh -c all would start the server in the all profile. Each profile is contained in a directory named <literal> JBOSS_HOME/server/[profile name]/</literal>. You can look into each server profile's directory to see the services, applications, and libraries included in the profile.</para>
+ <para>The JBoss Enterprise Application Platform ships with five server profiles. You can choose which configuration to start by passing the -c parameter to the server startup script. For instance, command run.sh -c all would start the server in the all profile. Each profile is contained in a directory named <literal> JBOSS_HOME/server/[profile name]/</literal>. You can look into each server profile's directory to see the services, applications, and libraries included in the profile.</para>
<note><para>The exact contents of the server/[profile name] directory depends on the profile service implementation and is subject to change as the management layer and embedded server evolve.</para></note>
<itemizedlist>
<listitem>
<indexterm><primary>Profiles</primary><secondary>minimal</secondary></indexterm>
- <para>The minimal profile starts the core server container without any of the enterprise services. It is a good starting point if you want to build a customized version of JBoss AS that only contains the services you need.</para></listitem>
+ <para>The minimal profile starts the core server container without any of the enterprise services. It is a good starting point if you want to build a customized version of JBoss Enterprise Application Platform that only contains the services you need.</para></listitem>
<listitem>
<indexterm><primary>Profiles</primary><secondary>default</secondary></indexterm>
<para>The default profile is the mostly common used profile for application developers. It supports the standard Java EE 5.0 programming APIs (e.g., Annotations, JPA, and EJB3).</para></listitem>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/EJB3.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/EJB3.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/EJB3.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -10,11 +10,11 @@
<indexterm><primary>EJB3</primary><see>Enterprise Applications with EJB3 Services</see></indexterm>
EJB3 (Enterprise Java Bean 3.0) provides the core component model for Java EE 5 applications. An EJB3 bean is a managed component that is automatically wired to take advantage of all services the Java EE 5 server container provides, such as transaction, security, persistence, naming, dependency injection, etc. The managed component allows developers to focus on the business logic, and leave the cross-cutting concerns to the container as configurations. As an application developer, you need not create or destroy the components yourself. You only need to ask for an EJB3 bean from the Java EE container by its name, and then you can call its methods with all configured container services applied. You can get access to an EJB3 bean from either inside or outside of the Java EE container. </para>
- <para>JBoss AS 5 supports EJB3 out of the box. Note that JBoss AS 4.2 is a J2EE server, so it does not support the full EJB3 feature set. </para>
+<para>JBoss Enterprise Application Platform 5 supports EJB3 out of the box. Note that JBoss Enterprise Application Platform 4.2 is a J2EE server, so it does not support the full EJB3 feature set. </para>
<para>The details of the EJB3 component programming model is beyond the scope of this guide. Most EJB3 interfaces and annotations are part of the Java EE 5 standard and hence they are the same for all Java EE 5 compliant application servers. Interested readers should refer to the EJB3 specification or numerous EJB3 books to learn more about EJB3 programming.</para>
- <para>In this chapter, we only cover EJB3 configuration issues that are specific to the JBoss AS. For instance, we discuss the JNDI naming conventions for EJB3 components inside the JBoss AS, the optional configurations for the Hibernate persistence engine for entity beans, as well as custom options in the JBoss EJB3 deployer.</para>
+ <para>In this chapter, we only cover EJB3 configuration issues that are specific to the JBoss Enterprise Application Platform. For instance, we discuss the JNDI naming conventions for EJB3 components inside the JBoss Enterprise Application Platform, the optional configurations for the Hibernate persistence engine for entity beans, as well as custom options in the JBoss EJB3 deployer.</para>
<section id="EJB3_Services-Session_Beans">
<title>Session Beans</title>
@@ -87,7 +87,7 @@
<note>
<title>Injecting EJB3 Beans into the Web Tier</title>
- <para>Java EE 5 allows you to inject EJB3 bean instances directly into the web application via annotations without explicit JNDI lookup. This behavior is not yet supported in JBoss AS 4.2. However, the JBoss Enterprise Platform provides an integration framework called JBoss Seam. JBoss Seam brings EJB3 / JSF integration to new heights far beyond what Java EE 5 provides. Please see more details in the JBoss Seam reference guide bundled with the platform.</para>
+ <para>Java EE 5 allows you to inject EJB3 bean instances directly into the web application via annotations without explicit JNDI lookup. This behavior is not yet supported in JBoss Enterprise Application Platform 4.2. However, the JBoss Enterprise Platform provides an integration framework called JBoss Seam. JBoss Seam brings EJB3 / JSF integration to new heights far beyond what Java EE 5 provides. Please see more details in the JBoss Seam reference guide bundled with the platform.</para>
</note>
</section>
@@ -214,7 +214,7 @@
<para>The EntityManager API is great, but how does the server know which database it is supposed to save / update / query the entity objects? How do we configure the underlying object-relational-mapping engine and cache for better performance and trouble shooting? The persistence.xml file gives you complete flexibility to configure the EntityManager.</para>
- <para>The persistence.xml file is a standard configuration file in JPA. It has to be included in the META-INF directory inside the JAR file that contains the entity beans. The persistence.xml file must define a persistence-unit with a unique name in the current scoped classloader. The provider attribute specifies the underlying implementation of the JPA EntityManager. In JBoss AS, the default and only supported / recommended JPA provider is Hibernate. The jta-data-source points to the JNDI name of the database this persistence unit maps to. The java:/DefaultDS here points to the HSQL DB embedded in the JBoss AS. Please refer to <xref linkend="alternative_DBs"/> on how to setup alternative databases for JBoss AS.</para>
+ <para>The persistence.xml file is a standard configuration file in JPA. It has to be included in the META-INF directory inside the JAR file that contains the entity beans. The persistence.xml file must define a persistence-unit with a unique name in the current scoped classloader. The provider attribute specifies the underlying implementation of the JPA EntityManager. In JBoss Enterprise Application Platform, the default and only supported / recommended JPA provider is Hibernate. The jta-data-source points to the JNDI name of the database this persistence unit maps to. The java:/DefaultDS here points to the HSQL DB embedded in the JBoss Enterprise Application Platform. Please refer to <xref linkend="alternative_DBs"/> on how to setup alternative databases for JBoss AS.</para>
<programlisting>
<![CDATA[
@@ -236,7 +236,7 @@
<para>However, if you deploy your EAR application in its own scoped classloader and have only one persistence-unit defined in the whole application, you can omit the "name" on @PersistenceContext. See later in this chapter for EAR packaging and deployment.</para>
</note>
- <para>The properties element in the persistence.xml can contain any configuration properties for the underlying persistence provider. Since JBoss AS uses Hibernate as the EJB3 persistence provider, you can pass in any Hibernate options here. Please refer to the Hibernate and Hibernate EntityManager documentation for more details. Here we will just give an example to set the SQL dialect of the persistence engine to HSQL, and to create tables from the entity beans when the application starts and drop those tables when the application stops.</para>
+ <para>The properties element in the persistence.xml can contain any configuration properties for the underlying persistence provider. Since JBoss Enterprise Application Platform uses Hibernate as the EJB3 persistence provider, you can pass in any Hibernate options here. Please refer to the Hibernate and Hibernate EntityManager documentation for more details. Here we will just give an example to set the SQL dialect of the persistence engine to HSQL, and to create tables from the entity beans when the application starts and drop those tables when the application stops.</para>
<programlisting>
<![CDATA[
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/FAQ.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/FAQ.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/FAQ.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -14,7 +14,7 @@
</para>
</listitem>
<listitem>
- <para>You have <track-connection-by-tx/> in your oracle-xa-ds.xml (not necessarily for JBoss-5.x where it is enabled by default and the element is deprecated).
+ <para>You have <track-connection-by-tx/> in your oracle-xa-ds.xml (not necessarily for JBoss Enterprise Application Platform 5.x where it is enabled by default and the element is deprecated).
</para>
</listitem>
<listitem>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/General_Configuration.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/General_Configuration.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/General_Configuration.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -5,7 +5,7 @@
<title>General Configuration</title>
<para>
<indexterm><primary>Configuration</primary><secondary>general</secondary></indexterm>
-This chapter covers general configuration issues for the JBoss Application Server.
+This chapter covers general configuration issues for the JBoss Enterprise Application Platform.
</para>
@@ -15,12 +15,12 @@
</para>
</section>
-<section><title>Hosting multiple domains with your JBoss Application Server</title>
+<section><title>Hosting multiple domains with your JBoss Enterprise Application Platform</title>
<para>
This section discusses how you can use your application server to host multiple applications for multiple domains.
</para>
<para>
-In this section we use a scenario where a company has three domains with the DNS server pointing to the JBoss AS server:
+ In this section we use a scenario where a company has three domains with the DNS server pointing to the JBoss Enterprise Application Platform server:
<orderedlist>
<listitem>
<para>www.domainA11.net</para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Introduction.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Introduction.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Introduction.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -2,17 +2,16 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
]>
-<chapter id="JBoss_AS5_Introduction">
+<chapter id="JBoss_Enterprise_Application_Platform_5_Introduction">
<title>Introduction</title>
<para>
- <indexterm><primary>JBossAS</primary><secondary>microcontainer</secondary></indexterm>
- JBoss Application Server 5 is built on top of the new JBoss Microcontainer.
+ <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>microcontainer</secondary></indexterm>
+ JBoss Enterprise Application Platform 5 is built on top of the new JBoss Microcontainer.
The JBoss Microcontainer is a lightweight container that supports direct deployment, configuration and lifecycle of plain old Java objects (POJOs).
- <indexterm><primary>JBossAS</primary><secondary>JMX Microkernel</secondary></indexterm>
+ <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>JMX Microkernel</secondary></indexterm>
The JBoss Microcontainer project is standalone and replaces the JBoss JMX Microkernel used in the 3.x and 4.x JBoss Application Servers.
Project goals include:
</para>
-
<para>
<itemizedlist>
<listitem>
@@ -43,17 +42,17 @@
</itemizedlist>
The JBoss Microcontainer integrates nicely with the JBoss Aspect
- Oriented Programming framework (JBoss AOP). JBoss AOP is discussed in <xref linkend="jboss_aop"/> Support for JMX in JBossAS 5 remains strong and MBean services written against the old Microkernel are expected to work.
+ Oriented Programming framework (JBoss AOP). JBoss AOP is discussed in <xref linkend="jboss_aop"/> Support for JMX in JBoss Enterprise Application Platform 5 remains strong and MBean services written against the old Microkernel are expected to work.
</para>
<para>
- JBoss AS5 is designed around the advanced concept of a Virtual Deployment
+ JBoss Enterprise Application Platform 5 is designed around the advanced concept of a Virtual Deployment
Framework (VDF).
- The JBossAS 5 Virtual Deployment Framework (VDF) takes the aspect oriented design of many of the earlier JBoss containers and applies it to the deployment layer. It is also based on the POJO microntainer rather than JMX as in previous releases. More information about the Virtual Deployment Framework (VDF) can be found in <xref linkend="virtual_deployment_framework"/>.
+ The JBoss Enterprise Application Platform 5 Virtual Deployment Framework (VDF) takes the aspect oriented design of many of the earlier JBoss containers and applies it to the deployment layer. It is also based on the POJO microntainer rather than JMX as in previous releases. More information about the Virtual Deployment Framework (VDF) can be found in <xref linkend="virtual_deployment_framework"/>.
</para>
<para>
- A sample Java EE 5 application that can be run on top of JBoss 5.0.0.GA and above which demonstrates many interesting technologies is the Seam Booking Application available on <ulink url="http://seamframework.org/Documentation/RunningSeamExamplesWithJBossApplicationServer5"/>. This application makes use of the following technologies running on JBoss AS5:
+ A sample Java EE 5 application that can be run on top of JBoss Enterprise Application Platform 5.0.0.GA and above which demonstrates many interesting technologies is the Seam Booking Application available on <ulink url="http://seamframework.org/Documentation/RunningSeamExamplesWithJBossApplicationServer5"/>. This application makes use of the following technologies running on JBoss Enterprise Application Platform 5:
<itemizedlist>
<listitem>
@@ -100,16 +99,16 @@
</para>
<para>
- Many key features of JBoss AS5 are provided by integrating other standalone JBoss projects which include: -
+ Many key features of JBoss Enterprise Application Platform 5 are provided by integrating other standalone JBoss projects which include: -
<itemizedlist>
<listitem>
<para>
- JBoss EJB3 included with JBoss 5 provides the implementation of the latest revision of the Enterprise Java Beans (EJB) specification. EJB 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0's goals are to simplify development, facilitate a test driven approach, and focus more on writing plain old java objects (POJOs) rather than coding against complex EJB APIs.
+ JBoss EJB3 included with JBoss Enterprise Application Platform 5 provides the implementation of the latest revision of the Enterprise Java Beans (EJB) specification. EJB 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0's goals are to simplify development, facilitate a test driven approach, and focus more on writing plain old java objects (POJOs) rather than coding against complex EJB APIs.
</para>
</listitem>
<listitem>
<para>
- JBoss Messaging is a high performance JMS provider in the JBoss Enterprise Middleware Stack (JEMS), included with JBoss 5 as the default messaging provider. It is also the backbone of the JBoss ESB infrastructure. JBoss Messaging is a complete rewrite of JBossMQ, which is the default JMS provider for the JBoss AS 4.x series.
+ JBoss Messaging is a high performance JMS provider in the JBoss Enterprise Middleware Stack (JEMS), included with JBoss Enterprise Application Platform 5 as the default messaging provider. It is also the backbone of the JBoss ESB infrastructure. JBoss Messaging is a complete rewrite of JBossMQ, which is the default JMS provider for the JBoss Enterprise Application Platform 4.x series.
</para>
</listitem>
<listitem>
@@ -119,26 +118,26 @@
</listitem>
<listitem>
<para>
- JBossWS 2 is the web services stack for JBoss 5 providing Java EE compatible web services, JAXWS-2.0.
+ JBossWS 2 is the web services stack for JBoss Enterprise Application Platform 5 providing Java EE compatible web services, JAXWS-2.0.
</para>
</listitem>
<listitem>
<para>
- JBoss Transactions is the default transaction manager for JBoss 5. JBoss Transactions is founded on industry proven technology and 18 year history as a leader in distributed transactions, and is one of the most interoperable implementations available.
+ JBoss Transactions is the default transaction manager for JBoss Enterprise Application Platform 5. JBoss Transactions is founded on industry proven technology and 18 year history as a leader in distributed transactions, and is one of the most interoperable implementations available.
</para>
</listitem>
<listitem>
<para>
- JBoss Web is the Web container in JBoss 5, an implementation based on Apache Tomcat that includes the Apache Portable Runtime (APR) and Tomcat native technologies to achieve scalability and performance characteristics that match and exceed the Apache Http server.
+ JBoss Web is the Web container in JBoss Enterprise Application Platform 5, an implementation based on Apache Tomcat that includes the Apache Portable Runtime (APR) and Tomcat native technologies to achieve scalability and performance characteristics that match and exceed the Apache Http server.
</para>
</listitem>
</itemizedlist>
- JBoss AS5 includes numerous features and bug fixes, many of them carried over upstream from the JBoss AS4.x codebase. See the Detailed Release Notes section for the full details.
+JBoss Enterprise Application Platform 5 includes numerous features and bug fixes, many of them carried over from the JBoss Enterprise Application Platform 4.x codebase. See the Detailed Release Notes section for the full details.
</para>
<section id="JBossAS_Use_Cases">
- <title>JBoss Application Server Use Cases</title>
+ <title>JBoss Enterprise Application Platform Use Cases</title>
<para>
<itemizedlist>
<listitem>
@@ -153,7 +152,7 @@
</listitem>
<listitem>
<para>
- Simple web applications with JSPs/Servlets upgrade to jboss As with tomcat embedded.
+ Simple web applications with JSPs/Servlets upgrade to JBoss Enterprise Application Server with tomcat embedded.
</para>
</listitem>
<listitem>
@@ -175,7 +174,7 @@
</para>
</section>
- <section id="Community_EAP_Diffs">
+<!-- <section id="Community_EAP_Diffs">
<title>JBossAS Community Version vs EAP</title>
<subtitle>What is the difference between the community JBoss Application Server and the JBoss Enterprise Application Platform?</subtitle>
<para>
@@ -244,10 +243,10 @@
</section>
- <section id="JBossAS5_Compatibility_Issues">
+ <section id="JBoss_Enterprise_Application_Platform_5_Compatibility_Issues">
<title>JBoss Application Server 5 Compatibility Issues</title>
<para>
- The following are current compatibility issues for JBoss AS5:
+ The following are current compatibility issues for JBoss Enterprise Application Platform 5:
</para>
<section id="Java6_Notes">
<title>Java 6 Notes</title>
@@ -294,9 +293,9 @@
<section>
<title>Other JBossAS </title>
<para>The ClassPathExtension MBean has been replaced with a VFS classloader definition, see JBAS-5446.</para>
- <para>The old JMX-based ServiceBindingManager has been replaced by a POJO-based ServiceBindingManager, see <ulink url="http://www.jboss.org/community/docs/DOC-9038">AS5ServiceBindingManager Wiki</ulink>.</para>
+ <para>The old JMX-based ServiceBindingManager has been replaced by a POJO-based ServiceBindingManager, see <ulink url="http://www.jboss.org/community/docs/DOC-9038">Enterprise Application Platform 5ServiceBindingManager Wiki</ulink>.</para>
<para>The Farm service from 4.x has been removed, and replaced with a HASingletonDeploymentScanner that integrates with the ProfileService.</para>
- <para>JBoss 5 is stricter when it comes to verifying/deploying JavaEE artifacts. EJB3 deployments that run in AS 4.2 may fail in AS5. We have tried to keep the validation messages as accurate as possible in order to help you modify your deployment descriptors/annotations to be in-line with the JavaEE 5 requirements.</para>
+ <para>JBoss 5 is stricter when it comes to verifying/deploying JavaEE artifacts. EJB3 deployments that run in AS 4.2 may fail in Enterprise Application Platform 5. We have tried to keep the validation messages as accurate as possible in order to help you modify your deployment descriptors/annotations to be in-line with the JavaEE 5 requirements.</para>
<para>A new jboss.server.log.threshold system property can be used to control the log/server.log threshold. It defaults to DEBUG.</para>
<para>The default conf/jboss-log4j.xml configuration now includes the thread name for entries in log/server.log (JBAS-5274).</para>
<para>The transaction manager configuration has moved from conf/jboss-service.xml to deploy/transaction-service.xml.</para>
@@ -311,7 +310,7 @@
<para>Total replication (rather than buddy replication) is the default setting for session replication (JBAS-5085).</para>
<para>Loopback is now set to true for all JGroups UDP stacks (JBAS-5323).</para>
</section>
- </section>
+ </section> -->
</chapter>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -6,7 +6,7 @@
<para>
<indexterm><primary>JGroups</primary><secondary>multicast communication toolkit</secondary></indexterm>
- JBoss AS clustering is built on JGroups - a toolkit for reliable multicast communication between AS server nodes on an existing computer network. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup.
+ JBoss AS clustering is built on JGroups - a toolkit for reliable multicast communication between Enterprise Application Platform nodes on an existing computer network. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup.
</para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Messaging.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Messaging.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Messaging.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -6,7 +6,7 @@
<para>
<indexterm><primary>JBoss Messaging</primary><secondary>about</secondary></indexterm>
<indexterm><primary>JMS</primary><see>JBoss Messaging</see></indexterm>
-JBoss Messaging is the new enterprise messaging system from JBoss. It is a complete rewrite of JBossMQ, the legacy JBoss JMS provider. It is the default JMS provider on JBoss AS 5. Production support is already available through JBoss EAP 4.3, and we offer developer support for JBoss 4.2.x.</para>
+JBoss Messaging is the new enterprise messaging system from JBoss. It is a complete rewrite of JBossMQ, the legacy JBoss JMS provider. It is the default JMS provider on JBoss Enterprise Application Platform 5. <!-- Production support is already available through JBoss EAP 4.3, and we offer developer support for JBoss 4.2.x. --></para>
<para>JBoss Messaging is a high Performance JMS 1.1 compliant implementation integrated with JBoss Transactions. It also offers:
<itemizedlist>
<listitem>
@@ -31,8 +31,8 @@
</listitem>
</itemizedlist>
</para>
-<para>
- JBoss Messaging will be the default JMS provider in later versions of JBoss Enterprise Application Platform, and JBoss Service Integration Platform. It is also the default JMS provider in JBoss Application Server 5, and is the default JMS provider for JBoss ESB.</para>
+<!--<para>
+ JBoss Messaging will be the default JMS provider in later versions of JBoss Enterprise Application Platform, and JBoss Service Integration Platform. It is also the default JMS provider in JBoss Application Server 5, and is the default JMS provider for JBoss ESB.</para> -->
<para>JBoss Messaging is an integral part of Red Hat's strategy for messaging.</para>
<para>Compared with JBossMQ, JBoss Messaging offers improved performance in both single node and clustered environments.</para>
<para>JBoss Messaging also features a much better modular architecture that will allow us to add more features in the future.</para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -4,7 +4,7 @@
<chapter><title>Microcontainer</title>
<indexterm><primary>MC</primary><see>JBoss Microcontainer</see></indexterm>
-<para>JBossAS 5.0 uses the microcontainer to integrate enterprise services together with a Servlet/JSP container, EJB container, deployers and management utilities in order to provide a standard Java EE environment. If you need additional services then you can simply deploy these on top of Java EE to provide the functionality you need. Likewise you are free to remove any services that you don't need simply by changing the configuration. You can even use the microcontainer to do this in other environments such as Tomcat and GlassFish since you can plug in different classloading models during the service deployment phase.</para>
+<para>JBoss Enterprise Application Platform 5.0 uses the microcontainer to integrate enterprise services together with a Servlet/JSP container, EJB container, deployers and management utilities in order to provide a standard Java EE environment. If you need additional services then you can simply deploy these on top of Java EE to provide the functionality you need. Likewise you are free to remove any services that you don't need simply by changing the configuration. You can even use the microcontainer to do this in other environments such as Tomcat and GlassFish since you can plug in different classloading models during the service deployment phase.</para>
<para>Since JBoss Microcontainer is very lightweight and deals with POJOs, it can also be used to deploy services into a Java ME runtime environment. This opens up new possibilities for mobile applications that can now take advantage of enterprise services without requiring a full JEE application server. </para>
<para>In common with other lightweight containers JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML depending on where the information is best located. Finally unit testing is made extremely simple thanks to a helper class that extends JUnit to setup the test environment, allowing you to access POJOs and services from your test methods using just a few lines of code.
</para>
@@ -107,7 +107,7 @@
<para>The main beans are:
<itemizedlist>
<listitem>
- <para><emphasis>ProfileService</emphasis> : this bean loads the deployments associated with the named server profile, "default", "all" or whatever name is passed in as the "-c" option to the server. Its an extension of the jboss-4.0.x and earlier notion of always looking to the filesystem <literal>server/name/conf/jboss-service.xml</literal> and <literal>server/name/deploy</literal> to load deployments.
+ <para><emphasis>ProfileService</emphasis> : this bean loads the deployments associated with the named server profile, "default", "all" or whatever name is passed in as the "-c" option to the server. Its an extension of the JBoss Enterprise Application Platform 4.0.x and earlier notion of always looking to the filesystem <literal>server/name/conf/jboss-service.xml</literal> and <literal>server/name/deploy</literal> to load deployments.
</para>
</listitem>
<listitem>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -2,14 +2,14 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
]>
<chapter id="performance_tuning">
- <title>JBoss AS 5 Performance Tuning</title>
+ <title>JBoss Enterprise Application Platform 5 Performance Tuning</title>
<section id="Tuning_Introduction">
<title>Introduction</title>
<para>
- <indexterm><primary>JBoss AS 5 Performance Tuning</primary><secondary>performance</secondary></indexterm>
- <indexterm><primary>Performance</primary><secondary>JBoss AS 5 Performance Tuning</secondary></indexterm>
- <indexterm><primary>JBossAS</primary><secondary>performance tuning</secondary></indexterm>
+ <indexterm><primary>JBoss Enterprise Application Platform 5 Performance Tuning</primary><secondary>performance</secondary></indexterm>
+ <indexterm><primary>Performance</primary><secondary>JBoss Enterprise Application Platform 5 Performance Tuning</secondary></indexterm>
+ <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>performance tuning</secondary></indexterm>
Developing applications and deploying them to an application server does not guarantee best performance without performance tuning of the applications and server.
Performance tuning involves ensuring your application does not consume resources unnecessarily while ensures best performance of the applications and application server.
</para>
@@ -25,7 +25,7 @@
<section id="Hardware_Tuning">
<title>Hardware tuning</title>
<para>
- To develop a suitable hardware configuration that suits the performance of your applications on the JBoss Application server, you need to understand the impact the selected hardware configuration may have on other applications and overall operating system performance.
+ To develop a suitable hardware configuration that suits the performance of your applications on the JBoss Enterprise Application Platform, you need to understand the impact the selected hardware configuration may have on other applications and overall operating system performance.
</para>
<para>
To understand hardware performance tuning issues, it is also very critical to understand the hardware architecture of your system.
@@ -179,12 +179,12 @@
<section id="JBAS_Tuning">
<title>Tuning JBoss Application Server</title>
<para>
- Before tuning the JBoss Application Server, please ensure that you are familiar with its components outlined in the introduction section of this book. You should also be familiar with any particular services your application may use on the application server and tune them to improve performance. It is also important to establish optimal database connections used by your applications and set these on the application server. This section discusses these among other JBoss Application Server performance tuning topics.
+ Before tuning the JBoss Enterprise Application Platform, please ensure that you are familiar with its components outlined in the introduction section of this book. You should also be familiar with any particular services your application may use on the application server and tune them to improve performance. It is also important to establish optimal database connections used by your applications and set these on the application server. This section discusses these among other JBoss Application Server performance tuning topics.
</para>
<section id="Memory_Usage_Tuning"><title>Memory usage</title>
<para>
- Memory usage of Java applications including the JBoss Application Server is dictated by the heap space allocated. You could therefore as an example, reduce 1GB heap space you currently have allocated to 800MB to save space.
+ Memory usage of Java applications including the JBoss Enterprise Application Platform is dictated by the heap space allocated. You could therefore as an example, reduce 1GB heap space you currently have allocated to 800MB to save space.
</para>
<para>
There are several instances where the Java Virtual Machine (JVM) may report <literal>OutOfMemoryError</literal> even when it is not really out of its available memory. The JVM may report an out of memory error when it is really out of memory or when only a segment or generation of the heap space is exhausted as most modern JVM's divide the heap space into generations/segments. Another example could be inability of the operating system (occurs on Linux/Unix systems)to create new threads for the JVM.
@@ -235,10 +235,10 @@
Resource limits set by your operating system may also set limits on your database management system. A database administrator can analyse a database and identify performance bottlenecks through taking the above factors into consideration and adjusting the necessary database management system parameters such as writing dirty buffers to disk, checkpoints and log file rotations. In some instances hardware upgrades may also be necessary to improve database performance.
</para>
<para>
- Database connections can be costly to establish and manage. Applications that create new connections to the database with every transaction or query and then close that connection add a great deal of overhead. Having a very small connection pool will also throttle the applications as the JBoss application server by default queues the request for a default of 30,000 milliseconds (30 seconds) before cancellation and throwing an exception.
+ Database connections can be costly to establish and manage. Applications that create new connections to the database with every transaction or query and then close that connection add a great deal of overhead. Having a very small connection pool will also throttle the applications as the JBoss Enterprise Application Platform by default queues the request for a default of 30,000 milliseconds (30 seconds) before cancellation and throwing an exception.
</para>
<para>
- We recommend reliance on data source definitions you can setup in the deploy directory of the JBoss application server and utilizing the connection pool settings. Connection pooling in the JBoss application server allows you to easily monitor your connection usage from the JMX console to determine proper sizing. Your database management system may also shipped with tools that allow you to monitor connections.
+ We recommend reliance on data source definitions you can setup in the deploy directory of the JBoss Enterprise Application Platform and utilizing the connection pool settings. Connection pooling in the JBoss Enterprise Application Platform allows you to easily monitor your connection usage from the JMX console to determine proper sizing. Your database management system may also shipped with tools that allow you to monitor connections.
</para>
<para>
Depending on the databases implemented, please ensure you create a data source file in the deploy directory of your configuration as shown below:
@@ -381,7 +381,7 @@
Other key configurations required for performance tuning of your application server include the <filename><JBoss_Home>/server/<your_configuration>/deployers/jbossweb.deployer/server.xml</filename> file that sets your HTTP requests pool.
</para>
<para>
- JBoss AS 5 has a robust thread pooling, that should be sized appropriately.
+ JBoss Enterprise Application Platform 5 has a robust thread pooling, that should be sized appropriately.
The server has a <filename>jboss-service.xml</filename> file in the <filename><JBoss_Home>/server/<your_configuration>/conf</filename> directory that defines the system thread pool.
There is a setting that defines the behavior if there isn't a thread available in the pool for execution. The default is to allow the calling thread to execute the task. You can monitor the queue depth of the system thread pool through the JMX Console, and determine from that if you need to make the pool larger.
</para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Pooling.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Pooling.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Pooling.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -118,7 +118,7 @@
</para>
<note><title>Note</title>
-<para>This is the only supported behaviour for <emphasis>"local"</emphasis> transactions. This element is deprecated in JBoss-5.x where transaction stickiness is enabled by default. XA users can explicitly enable interleaving with <interleaving/> element.</para>
+<para>This is the only supported behaviour for <emphasis>"local"</emphasis> transactions. This element is deprecated in JBoss Enterprise Application Platform 5 where transaction stickiness is enabled by default. XA users can explicitly enable interleaving with <interleaving/> element.</para>
</note>
</section>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -9,7 +9,7 @@
The main objective of JBoss Remoting is to provide a single API for most network based invocations and related service that uses pluggable transports and data marshallers. The JBoss Remoting API provides the ability for making synchronous and asynchronous remote calls, push and pull callbacks, and automatic discovery of remoting servers. The intention is to allow for the addition of different transports to fit different needs, yet still maintain the same API for making the remote invocations and only requiring configuration changes, not code changes, to fit these different needs.
</para>
<para>
- JBossRemoting is a standalone project but is included in the recent releases of the JBoss Application Server including AS5 and can be run as a service within the container as well. This chapter discusses the JBoss Remoting service configurations.
+ JBossRemoting is a standalone project but is included in the this release of the JBoss Enterprise Application Platform and can be run as a service within the container as well. This chapter discusses the JBoss Remoting service configurations.
</para>
<section><title>Summary of JBoss Remoting Features</title>
@@ -154,7 +154,7 @@
</section>
<section>
- <title>JBoss Remoting Configuration in the JBoss Application Server</title>
+ <title>JBoss Remoting Configuration in the JBoss Enterprise Application Platform</title>
<para>
As indicated earlier in this chapter, JBoss Remoting manages synchronous and asynchronous remote calls, push and pull callbacks, and automatic discovery of remoting servers. You can configure JBoss Remoting through the JBoss Messaging service configuration file <filename>JBOSS_HOME/server/<your_configuration>/deploy/messaging/remoting-service.xml</filename>.
</para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Security.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Security.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Security.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -4,11 +4,11 @@
<chapter id="security">
<title>Security</title>
<indexterm><primary>Security</primary><secondary>JBossAS</secondary></indexterm>
- <indexterm><primary>JBossAS</primary><secondary>Security</secondary></indexterm>
+ <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>Security</secondary></indexterm>
<para>The JBoss security framework default implementation is based on JAAS. It implements standard J2EE authentication and authorization but also supports extended security models with <ulink url="http://wiki.jboss.org/wiki/Edit.jsp?page=SecurityProxy">SecurityProxy?</ulink> and <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=SecurityAssociation">SecurityAssociation</ulink> implementations. </para>
<para>JAAS based implementation enables pluggable authentication modules (PAMs) which is a way to integrate with existing authentication frameworks in your enterprise. </para>
-<section><title>Changes affecting Security in JBoss 5.x</title>
+<section><title>Changes affecting Security in JBoss Enterprise Application Platform 5</title>
<section><title>Web Layer</title>
<para>
@@ -86,7 +86,7 @@
</para>
</section>
-<section><title>Securing a Web Application in JBoss AS</title>
+<section><title>Securing a Web Application in JBoss Enterprise Application Platform</title>
<para>
Securing web resources basically involves setting some stuff in the web deployment descriptor, and in jboss-web.xml. You also have to do a little prep work to the server itself to configure a security domain for JBoss SX. These instructions assume that you have JBoss AS installed, and you have a server instance created with at least Tomcat included. The "default" instance is a good choice here. The variable ${JBOSS_HOME} refers to the location you extracted/installed JBoss AS to, and ${server_configuration} corresponds to the name of the server instance you are configuring for security. The first part of these instructions refers to setting up JBoss SX for security, and the second part deals with setting up the web application for security using basic authentication. You can access the instructions in the following section.
</para>
@@ -99,7 +99,7 @@
<para>
Open the <filename> ${JBOSS_HOME}/server/${server_configuration}/conf/login-config.xml</filename> file.
- This file sets up the configuration for the security domains available to applications running in the server. The file already has a few domains in there for some example/default resources, so you might want to look to those for inspiration. JBoss SX uses JAAS for the underlying security infrastructure, and JAAS uses a class called a "login module" to interact with a security store for authenticating credentials. This file basically hooks up a security domain (just a name really) to a JAAS login module. JBoss AS comes packed with a few different login modules which you can find more information about on the JBoss SX wiki page at JBossSX.</para>
+ This file sets up the configuration for the security domains available to applications running in the server. The file already has a few domains in there for some example/default resources, so you might want to look to those for inspiration. JBoss SX uses JAAS for the underlying security infrastructure, and JAAS uses a class called a "login module" to interact with a security store for authenticating credentials. This file basically hooks up a security domain (just a name really) to a JAAS login module. JBoss Enterprise Application Platform comes packed with a few different login modules which you can find more information about on the JBoss SX wiki page at JBossSX.</para>
</listitem>
<listitem>
<para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -4,7 +4,7 @@
<chapter id="transaction"><title>JBoss Transactions</title>
<para>
- <indexterm><primary>JBossAS</primary><secondary>transactions</secondary></indexterm>
+ <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>transactions</secondary></indexterm>
<indexterm><primary>JBoss Transactions</primary></indexterm>
JBoss Transactions runs in the <emphasis>all</emphasis> server configurations or customized configurations based on the <emphasis>all</emphasis> configuration. </para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Virtual_Deployment_Framework.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Virtual_Deployment_Framework.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Virtual_Deployment_Framework.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -7,7 +7,7 @@
<para>
<indexterm><primary>JBoss5 Virtual Deployment Framework</primary><secondary>virtual deployment framework</secondary></indexterm>
<indexterm><primary>Virtual Deployment Framework</primary><see>JBoss5 Virtual Deployment Framework</see></indexterm>
- As indicated in <xref linkend="JBoss_AS5_Introduction"/> the JBoss Application Server 5 is designed around the advanced concept of a Virtual Deployment Framework (VDF). This chapter discusses the JBoss5 Virtual Deployment Framework further. The following UML diagram illustrates an overview of the key JBoss5 Deployment Framework classes.
+ As indicated in <xref linkend="JBoss_Enterprise_Application_Platform_5_Introduction"/> the JBoss Enterprise Application Platform 5 is designed around the advanced concept of a Virtual Deployment Framework (VDF). This chapter discusses the JBoss5 Virtual Deployment Framework further. The following UML diagram illustrates an overview of the key JBoss5 Deployment Framework classes.
<figure id="JBoss5_virtual_deployment_framework_diagram">
<title>The JBoss5 Deployment Framework Classes</title>
@@ -537,7 +537,7 @@
</listitem>
<listitem>
<para>
- VirtualFile : the api for a file in the deployment.
+ VirtualFile : the API for a file in the deployment.
</para>
</listitem>
</itemizedlist>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -16,10 +16,10 @@
A web service is essentially a software application that supports interaction of applications over a computer network or the world wide web. Web services usually interact via XML documents that map to an object, computer program, business process or database. To communicate, an application sends a message in XML document format to a web service which sends this message to the respective programs. Responses may be received based on requirements and the web service receives and sends them in XML document format to the required program or applications. Web services can be used in many ways examples include supply chain information management and business integration among a multitude of other applications.
</para>
<para>
- JBossWS is a web service framework developed as part of the JBoss Application Server. It implements the JAX-WS specification that defines a programming model and run-time architecture for implementing web services in Java, targeted at the Java Platform, Enterprise Edition 5 (Java EE 5).
+ JBossWS is a web service framework developed as part of the JBoss Enterprise Application Platform. It implements the JAX-WS specification that defines a programming model and run-time architecture for implementing web services in Java, targeted at the Java Platform, Enterprise Edition 5 (Java EE 5).
</para>
<para>
- JBossWS integrates with most current JBoss Application Server releases as well as earlier ones, that did implement the J2EE 1.4 specifications. Even though JAX-RPC, the web service specification for J2EE 1.4, is still supported JBossWS does put a clear focus on JAX-WS.
+ JBossWS integrates with most current JBoss Enterprise Application Platform releases as well as earlier ones, that did implement the J2EE 1.4 specifications. Even though JAX-RPC, the web service specification for J2EE 1.4, is still supported JBossWS does put a clear focus on JAX-WS.
</para>
<section><title>Who needs web services?</title>
<para>
@@ -55,7 +55,7 @@
<section><title>Jboss Web services Attachment support with XOP (XML-binary Optimized Packaging) and SwA</title>
<para>
- JBoss-WS4EE relied on a deprecated attachments technology called SwA (SOAP with Attachments). SwA required soap/encoding which is disallowed by the WS-I Basic Profile. JBossWS provides support for WS-I AP 1.0, and MTOM instead. There will be no API change for users, however, since this is an updated protocol you will not be able to transfer attachments between older versions of JBoss AS and JBoss AS 4.0.4 or above.
+ JBoss-WS4EE relied on a deprecated attachments technology called SwA (SOAP with Attachments). SwA required soap/encoding which is disallowed by the WS-I Basic Profile. JBossWS provides support for WS-I AP 1.0, and MTOM instead. <!--There will be no API change for users, however, since this is an updated protocol you will not be able to transfer attachments between older versions of JBoss AS and JBoss AS 4.0.4 or above.-->
</para>
<para>
WS-I Attachment Profile 1.0 defines mechanism to reference MIME attachment parts using swaRef. In this mechanism the content of XML element of type wsi:swaRef is sent as MIME attachment and the element inside SOAP Body holds the reference to this attachment in the CID URI scheme as defined by RFC 2111.
@@ -729,7 +729,7 @@
<para>
<emphasis role="bold">WebServiceRef Customization</emphasis>
</para>
- <para>In jboss-5.0.x we offer a number of overrides and extensions to the WebServiceRef annotation. These include</para>
+ <para>In Jboss Enterprise Application Platform 5.0 we offer a number of overrides and extensions to the WebServiceRef annotation. These include</para>
<itemizedlist>
<listitem>
<para> define the port that should be used to resolve a container-managed port</para>
@@ -1296,7 +1296,7 @@
</note>
</para>
- <para>Let's create a POJO endpoint for deployment on JBoss AS. A simple web.xml needs to be created:</para>
+ <para>Let's create a POJO endpoint for deployment on JBoss Enterprise Application Platform. A simple web.xml needs to be created:</para>
<programlisting role="XML">
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/What_This_Book_Covers.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/What_This_Book_Covers.xml 2009-07-12 23:14:26 UTC (rev 91134)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/What_This_Book_Covers.xml 2009-07-13 01:10:58 UTC (rev 91135)
@@ -4,7 +4,7 @@
<preface id="What_this_Book_Covers"><title>What this Book Covers</title>
<para>
- The primary focus of this book is the presentation of the standard JBossAS 5.0 architecture components from both the perspective of their configuration and architecture. As a user of a standard JBoss distribution you will be given an understanding of how to configure the standard components. Note that this book is not an introduction to JavaEE or how to use JavaEE in applications. It focuses on the internal details of the JBoss server architecture and how our implementation of a given JavaEE container can be configured and extended.
+ The primary focus of this book is the presentation of the standard JBoss Enterprise Application Platform 5.0 architecture components from both the perspective of their configuration and architecture. As a user of a standard JBoss distribution you will be given an understanding of how to configure the standard components. Note that this book is not an introduction to JavaEE or how to use JavaEE in applications. It focuses on the internal details of the JBoss server architecture and how our implementation of a given JavaEE container can be configured and extended.
</para>
<para>
As a JBoss developer, you will be given a good understanding of the architecture and integration of the standard components to enable you to extend or replace the standard components for your infrastructure needs. We also show you how to obtain the JBoss source code, along with how to build and debug the JBoss server.
More information about the jboss-cvs-commits
mailing list