[jboss-cvs] JBossAS SVN: r101638 - projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Mon Mar 1 00:00:28 EST 2010


Author: laubai
Date: 2010-03-01 00:00:26 -0500 (Mon, 01 Mar 2010)
New Revision: 101638

Modified:
   projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml
   projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml
   projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml
   projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml
   projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml
   projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml
   projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml
   projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Revision_History.xml
Log:
Added fixes for JBPAPP-3361.

Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml	2010-03-01 03:09:19 UTC (rev 101637)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml	2010-03-01 05:00:26 UTC (rev 101638)
@@ -868,21 +868,7 @@
       </para>
       <para>
           To change the JNDI name, just open the <filename>*-ds.xml</filename> file for your external database, and change the value of the <varname>jndi-name</varname> property to <literal>DefaultDS</literal>. For instance, in <filename>mysql-ds.xml</filename>, you would change <literal>MySqlDS</literal> to <literal>DefaultDS</literal> and so on. You will need to remove the <filename>$JBOSS_HOME/server/$PROFILE/deploy/hsqldb-ds.xml</filename> file after you are done to avoid duplicated <literal>DefaultDS</literal> definition.
-      </para>
-      <para>
-          In the <filename>messaging/$DATABASE-persistence-service.xml</filename> file, you should also change the datasource name in the <literal>depends</literal> tag for the <classname>PersistenceManagers</classname> MBean to <literal>DefaultDS</literal>. For instance, for <filename>mysql-persistence-service.xml</filename> file, we change the <literal>MySqlDS</literal> to <literal>DefaultDS</literal>.
-          
-      </para>
-      
-<programlisting role="XML"><![CDATA[
-...
-
-<mbean code="org.jboss.messaging.core.jmx.JDBCPersistenceManagerService" name="jboss.messaging:service=PersistenceManager" xmbean-dd="xmdesc/JDBCPersistenceManager-xmbean.xml">
-        
-<depends>jboss.jca:service=DataSourceBinding,name=DefaultDS</depends>
-]]>
-</programlisting>
-      
+      </para>      
     </section>
     
     <section>
@@ -909,7 +895,7 @@
 </section>
   
   <section>
-    <title>A Special Note About Oracle DataBases</title>
+    <title>A Special Note About Oracle Databases</title>
     
     <para>In our setup discussed in this chapter, we rely on the JBoss Enterprise Web 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 Web Platform instance.</para>
     

Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml	2010-03-01 03:09:19 UTC (rev 101637)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Book_Info.xml	2010-03-01 05:00:26 UTC (rev 101638)
@@ -7,7 +7,7 @@
 	<subtitle>for JBoss Enterprise Web Platform 5.0</subtitle>	
 	<edition>1</edition>
 	<issuenum>1</issuenum>
-	<pubsnumber>1.9</pubsnumber>
+	<pubsnumber>2.0</pubsnumber>
 	<productname>JBoss Enterprise Web Platform</productname>
 	<productnumber>5.0</productnumber>
 <!--	<pubdate>, 2009</pubdate> -->

Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml	2010-03-01 03:09:19 UTC (rev 101637)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml	2010-03-01 05:00:26 UTC (rev 101638)
@@ -55,9 +55,7 @@
        more details on HAPartition.</para>
        
        <para>The other higher level clustering services make use of JBoss Cache
-       or HAPartition, or, in the case of HA-JNDI, both. The exception to this
-       is JBoss Messaging's clustering features, which interact with JGroups 
-       directly.</para>
+       or HAPartition, or, in the case of HA-JNDI, both.</para>
        
        <section id="clustering-blocks-jgroups">
          <title>Group Communication with JGroups</title>
@@ -76,13 +74,13 @@
 	 </para>
 	         
 	 <para>
-		 By default, UDP multicast is used by all JGroups channels used by the Enterprise Web Platform, except for a single TCP-based channel used by JBoss Messaging.
+		 By default, UDP multicast is used by all JGroups channels used by the Enterprise Web Platform.
 	 </para>
          
         <section id="clustering-blocks-jgroups-channelfactory">
            <title>The Channel Factory Service</title>
 	   <para>
-		   A significant difference in JBoss Enterprise Web Platform 5 compared to previous releases is that the JGroups channels needed by clustering services (for example, a channel used by a distributed <classname>HttpSession</classname> cache) are no longer configured in detail as part of the consuming service's configuration, and are no longer directly instantiated by the consuming service. Instead, a new <classname>ChannelFactory</classname> service is used as a registry for named channel configurations and as a factory for <classname>Channel</classname> instances. A service that needs a channel requests the channel from the <classname>ChannelFactory</classname>, passing in the name of the desired configuration.
+		   It is important to note that the JGroups channels needed by clustering services (for example, a channel used by a distributed <classname>HttpSession</classname> cache) are not configured in detail as part of the consuming service's configuration, and are not directly instantiated by the consuming service. Instead, a new <classname>ChannelFactory</classname> service is used as a registry for named channel configurations and as a factory for <classname>Channel</classname> instances. A service that needs a channel requests the channel from the <classname>ChannelFactory</classname>, passing in the name of the desired configuration.
 	   </para>
 	               
 	   <para>
@@ -168,11 +166,10 @@
           </variablelist>
 		                </section>
 	             </section>
-<!--hajime-->
              <section id="clustering-blocks-jgroups-sharedtransport">
 	               <title>The JGroups Shared Transport</title>
-	               <para>As the number of JGroups-based clustering services running in 
-		               the Enterprise Web Platform has risen over the years, the need to share the resources 
+	               <para>As the number of JGroups-based clustering services has 
+                    risen over the years, the need to share the resources 
 		               (particularly sockets and threads) used by these channels became 
 		               a glaring problem. A pristine Enterprise Web Platform 5 <literal>production</literal>
 		               configuration will connect four JGroups channels during startup, and a total of 
@@ -248,21 +245,10 @@
 	          services (for example, 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. 
-            Previously, each of these caches was independently deployed in <filename>deploy</filename>
-            directory, which had a number of disadvantages:
             </para>
-	          <itemizedlist>
-	          <listitem><para>Different cache types were created regardless of whether they
-            were required by a particular application, and used a resource-expensive
-            JGroups channel in the process.</para></listitem>
-             <listitem><para>Caches are internal details of the services that 
-             use them. They shouldn't be first-class deployments.</para></listitem>
-             <listitem><para>Services would find their cache via JMX lookups. This
-              is not the purpose for which JMX is intended.</para></listitem>
-	          </itemizedlist>
 	          
-	          <para>In JBoss Enterprise Web Platform 5, the scattered cache deployments have been replaced 
-	          with a new <classname>CacheManager</classname> service, deployed via the 
+	          <para>In JBoss Enterprise Web Platform 5, the scattered cache deployments use the
+            <classname>CacheManager</classname> service, deployed via the 
             <filename>$JBOSS_HOME/server/$PROFILE/deploy/cluster/jboss-cache-manager.sar</filename>. 
 	          The <classname>CacheManager</classname> is a factory and registry for JBoss Cache instances. 
 	          It is configured with a set of named JBoss Cache configurations. 
@@ -739,20 +725,6 @@
 					      &#8212; which nodes have the service deployed.</para>
 			      </section>
 			      
-			      <section id="clustering-hapartition-distributedstate">
-				      <title>DistributedState Service</title>
-				      <para>
-					      The <classname>DistributedState</classname> service is a legacy component 
-					      of the <classname>HAPartition</classname> service made available to HAPartition
-					      users via the <methodname>HAPartition.getDistributedState()</methodname>
-					      method. This service provides coordinated management of arbitary
-					      application state around the cluster. Support is provided only for backwards
-                compatibility; new applications should use JBoss Cache instead.
-				      </para>
-				      <para>In JBoss Enterprise Web Platform 5 the <classname>DistributedState</classname> service 
-					      delegates to an underlying JBoss Cache instance.</para>
-			      </section>
-			      
 			      <section id="clustering-hapartition-customsvcs">
 				      <title>Custom Use of HAPartition</title>
 				      

Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml	2010-03-01 03:09:19 UTC (rev 101637)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml	2010-03-01 05:00:26 UTC (rev 101638)
@@ -130,7 +130,7 @@
 	  <para>
 		  The HTTP-based JBoss services do not require the client to download 
         anything. The client (for example, a web browser) sends in requests and receives 
-        responses directly over the wire using the HTTP protocol). In this
+        responses directly over the wire using 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 Enterprise Web Platform 

Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml	2010-03-01 03:09:19 UTC (rev 101637)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_EJBs.xml	2010-03-01 05:00:26 UTC (rev 101638)
@@ -3,6 +3,16 @@
 
 <chapter id="clustering-session">
   <title>Clustered Session EJBs</title>
+  <important>
+    <title>Remote EJB connectivity is Not Supported</title>
+    <para>
+      JBoss Enterprise Web Platform does not support remote EJB connectivity. Further, 
+      other EJB support will be removed in versions of JBoss Enterprise Web Platform
+      based on JBoss Application Server 6.
+      If you require this functionality, use JBoss Enterprise Application Platform.
+    </para>
+  </important>
+
   <para>
     Session EJBs provide remote invocation services. They are clustered based 
     on the client-side interceptor architecture. The client application for a 
@@ -456,9 +466,14 @@
     </section>
   </section>
 
-
   <section id="clustering-session-slsb21">
     <title>Stateless Session Bean in EJB 2.x</title>
+    <important>
+      <title>EJB 2.x is not supported</title>
+      <para>EJB 2.x is included, but not supported, in JBoss Enterprise Web Platform, 
+            and may not be available in future versions.</para>
+    </important>
+
     <para>
       To make an EJB 2.x bean clustered, you need to modify its <filename>jboss.xml</filename>
       descriptor to contain a <literal><![CDATA[<clustered>]]></literal> tag.
@@ -517,6 +532,12 @@
 
   <section id="clustering-session-sfsb21">
     <title>Stateful Session Bean in EJB 2.x</title>
+    <important>
+      <title>EJB 2.x is not supported</title>
+      <para>EJB 2.x is included, but not supported, in JBoss Enterprise Web Platform, 
+            and may not be available in future versions.</para>
+    </important>
+
     <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

Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml	2010-03-01 03:09:19 UTC (rev 101637)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Entity_EJBs.xml	2010-03-01 05:00:26 UTC (rev 101638)
@@ -3,6 +3,16 @@
 
 <chapter id="clustering-entity">
   <title>Clustered Entity EJBs</title>
+  <important>
+    <title>Remote EJB connectivity is Not Supported</title>
+    <para>
+      JBoss Enterprise Web Platform does not support remote EJB connectivity. Further, 
+      other EJB support will be removed in versions of JBoss Enterprise Web Platform
+      based on JBoss Application Server 6.
+      If you require this functionality, use JBoss Enterprise Application Platform.
+    </para>
+  </important>
+
   <para>
 	  In a JBoss Enterprise Web 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.
@@ -564,10 +574,15 @@
   
   <section id="clustering-entity-21">
     <title>Entity Bean in EJB 2.x</title>
+    <important>
+      <title>EJB 2.x is not supported</title>
+      <para>EJB 2.x is included, but not supported, in JBoss Enterprise Web Platform, 
+            and may not be available in future versions.</para>
+    </important>
     <para>
       First of all, it is worth noting that clustering 2.x entity beans is a bad thing to do.
       Its exposes elements that generally are too fine grained for use as remote objects to clustered remote objects and introduces data synchronization problems that are non-trivial.
-      Do NOT use EJB 2.x entity bean clustering unless you fit into the special case situation of read-only, or one read-write node with read-only nodes synchronized with the cache invalidation services.
+      Do NOT use EJB 2.x entity bean clustering unless you fit into the special case situation of read-only<!--, or one read-write node with read-only nodes synchronized with the cache invalidation services-->.
     </para>
 
     <para>

Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml	2010-03-01 03:09:19 UTC (rev 101637)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml	2010-03-01 05:00:26 UTC (rev 101638)
@@ -399,7 +399,7 @@
       <section id="clustering-http-app">
         <title>Enabling session replication in your application</title>
         <para>To enable replication of your web application you must tag the 
-        application as distributable in the <filename>web.xml</filename> descriptor. 
+        application as <literal>distributable</literal> in the <filename>web.xml</filename> descriptor. 
         Here's an example:</para>
         <programlisting><![CDATA[
 <?xml version="1.0"?> 
@@ -409,7 +409,7 @@
                               http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" 
           version="2.4">
           
-    <emphasis role="bold"><distributable/></emphasis>
+    <distributable/>
     
 </web-app>
 ]]></programlisting>
@@ -919,19 +919,7 @@
 ]]></programlisting>
 	
 <para>There is no need to annotate <literal>Student</literal>. POJO Cache will recognize it as @Replicable because it is a sub-class of <literal>Person</literal>.</para>
-<para>JBoss Enterprise Web Platform 5 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>
 
-<programlisting>/**
- * Represents a street address.
- * @org.jboss.cache.pojo.annotation.Replicable
- */
-public class Address 
-{
-...
-}
-</programlisting>
-
 <para>
 	Once you have annotated your classes, you will need to perform a pre-processing 
   step to bytecode enhance your classes for use by POJO Cache. You need to use the 
@@ -1022,7 +1010,7 @@
 	<para>
 		To enable clustered single sign-on, you must add the <classname>ClusteredSingleSignOn</classname> 
 		valve to the appropriate <literal>Host</literal> elements of the 
-		<literal>JBOSS_HOME/server/all/deploy/jbossweb.sar/server.xml</literal> file. 
+		<literal>JBOSS_HOME/server/production/deploy/jbossweb.sar/server.xml</literal> file. 
 		The valve element is already included in the standard file; you just need
 		to uncomment it. The valve configuration is shown here: 
 	</para>

Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Revision_History.xml	2010-03-01 03:09:19 UTC (rev 101637)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Revision_History.xml	2010-03-01 05:00:26 UTC (rev 101638)
@@ -8,7 +8,7 @@
          <simpara>
                 <revhistory>
                         <revision>
-                                <revnumber>2.9</revnumber>
+                                <revnumber>3.0</revnumber>
                                 <date>Thu Feb 25 2010</date>
                                 <author>
                                         <firstname>Laura</firstname>




More information about the jboss-cvs-commits mailing list