[jboss-cvs] JBossAS SVN: r72165 - projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Mon Apr 14 07:34:29 EDT 2008


Author: skittoli at redhat.com
Date: 2008-04-14 07:34:28 -0400 (Mon, 14 Apr 2008)
New Revision: 72165

Modified:
   projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/J2EE_EJBs_On_JBOSS.xml
   projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/Naming.xml
   projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/The_CMP_Engine.xml
Log:
updated docs-typos etc

Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/J2EE_EJBs_On_JBOSS.xml
===================================================================
--- projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/J2EE_EJBs_On_JBOSS.xml	2008-04-14 11:23:53 UTC (rev 72164)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/J2EE_EJBs_On_JBOSS.xml	2008-04-14 11:34:28 UTC (rev 72165)
@@ -158,7 +158,7 @@
 			</listitem>
 			<listitem>
 				<para>
-					<emphasis role="bold">org.jboss.invocation.InvokerInterceptor</emphasis>: encapsulates the dispatch of the method invocation to the transport specific invoker. It knows if the client is executing in the same VM as the server and will optimally route the invocation to a by reference invoker in this situation. When the client is external to the server VM, this interceptor delegates the invocation to the transport invoker associated with the invocation context. In the case of the <xref linkend="The_EJB_Client_Side_View-The_client_interceptors_from_the_Standard_Stateless_SessionBean_configuration." /> configuration, this would be the invoker stub associated with the <literal>jboss:service=invoker,type=jrmp</literal>, the <literal>JRMPInvoker</literal> service.
+					<emphasis role="bold">org.jboss.invocation.InvokerInterceptor</emphasis>: encapsulates the dispatch of the method invocation to the transport specific invoker. It knows if the client is executing in the same VM as the server and will optimally route the invocation to a reference invoker in this situation. When the client is external to the server VM, this interceptor delegates the invocation to the transport invoker associated with the invocation context. In the case of the <xref linkend="The_EJB_Client_Side_View-The_client_interceptors_from_the_Standard_Stateless_SessionBean_configuration." /> configuration, this would be the invoker stub associated with the <literal>jboss:service=invoker,type=jrmp</literal>, the <literal>JRMPInvoker</literal> service.
 				</para>
 				<para>
 					<emphasis role="bold">org.jboss.invocation.MarshallingInvokerInterceptor</emphasis>: extends the <literal>InvokerInterceptor</literal> to not optimize in-VM invocations. This is used to force <literal>call-by-value</literal> semantics for method calls.
@@ -168,7 +168,7 @@
 		<section id="The_EJB_Client_Side_View-Specifying_the_EJB_Proxy_Configuration">
 			<title>Specifying the EJB Proxy Configuration</title>
 			<para>
-				To specify the EJB invocation transport and the client proxy interceptor stack, you need to define an <literal>invoker-proxy-binding</literal> in either the EJB JAR <literal>META-INF/jboss.xml descriptor</literal>, or the server <literal>standardjboss.xml</literal> descriptor. There are several default <literal>invoker-proxy-bindings</literal> defined in the <literal>standardjboss.xml</literal> descriptor for the various default EJB container configurations and the standard RMI/JRMP and RMI/IIOP transport protocols. The current default proxy configurations are:
+				To specify the EJB invocation transport and the client proxy interceptor stack, you need to define an <literal>invoker-proxy-binding</literal> in either the EJB JAR <literal>META-INF/jboss.xml</literal>  descriptor, or the server <literal>standardjboss.xml</literal> descriptor. There are several default <literal>invoker-proxy-bindings</literal> defined in the <literal>standardjboss.xml</literal> descriptor for the various default EJB container configurations and the standard RMI/JRMP and RMI/IIOP transport protocols. The current default proxy configurations are:
 			</para>
 			<itemizedlist>
 				<listitem>
@@ -984,7 +984,7 @@
 				<section id="Container_configuration_information-insert_after_ejb_post_create">
 					<title>insert-after-ejb-post-create</title>
 					<para>
-						This is another entity bean optimization which cause the database insert command for a new entity bean to be delayed until the <literal>ejbPostCreate</literal> method is called. This allows normal CMP fields as well as CMR fields to be set in a single insert, instead of the default insert followed by an update, which allows removes the requirement for relation ship fields to allow null values.
+						This is another entity bean optimization which cause the database insert command for a new entity bean to be delayed until the <literal>ejbPostCreate</literal> method is called. This allows normal CMP fields as well as CMR fields to be set in a single insert, instead of the default insert followed by an update, which removes the requirement for relationship fields to allow null values.
 					</para>
 				</section>
 				
@@ -1169,7 +1169,7 @@
 						</listitem>
 						<listitem>
 							<para>
-								<emphasis role="bold">org.jboss.ejb.plugins.lock.SimpleReadWriteEJBLock</emphasis>: This lock allows multiple read locks concurrently. Once a writer has requested the lock, future read-lock requests whose transactions do not already have the read lock will block until all writers are done; then all the waiting readers will concurrently go (depending on the reentrant setting / methodLock). A reader who promotes gets first crack at the write lock, ahead of other waiting writers. If there is already a reader that is promoting, we throw an inconsistent read exception. Of course, writers have to wait for all read-locks to release before taking the write lock.
+								<emphasis role="bold">org.jboss.ejb.plugins.lock.SimpleReadWriteEJBLock</emphasis>: This lock allows multiple read locks concurrently. Once a writer has requested the lock, future read-lock requests whose transactions do not already have the read lock will be blocked until all writers are done; then all the waiting readers will concurrently go (depending on the reentrant setting / methodLock). A reader who promotes gets first priority for the write lock, ahead of other waiting writers. If there is already a reader that is promoting, an inconsistent read exception will be thrown. Of course, writers have to wait for all read-locks to release before taking the write lock.
 							</para>
 						</listitem>
 						<listitem>

Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/Naming.xml
===================================================================
--- projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/Naming.xml	2008-04-14 11:23:53 UTC (rev 72164)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/Naming.xml	2008-04-14 11:34:28 UTC (rev 72165)
@@ -585,7 +585,7 @@
 				</listitem>
 				<listitem>
 					<para>
-						The JSSE security provider must be installed in order for SSL to work. This can be done either by installing the JSSE jars as an extension package, or programatically. We use the programatic approach in the example since this is less intrusive. Line 18 of the <literal>ExClient</literal> code demonstrates how this is done.
+						The JSSE security provider must be installed in order for SSL to work. This can be done either by installing the JSSE jars as an extension package, or programatically. We use the programmatic approach in the example since this is less intrusive. Line 18 of the <literal>ExClient</literal> code demonstrates how this is done.
 					</para>
 				</listitem>
 				<listitem>

Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/The_CMP_Engine.xml
===================================================================
--- projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/The_CMP_Engine.xml	2008-04-14 11:23:53 UTC (rev 72164)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/The_CMP_Engine.xml	2008-04-14 11:34:28 UTC (rev 72165)
@@ -1461,7 +1461,7 @@
 		<section id="Queries-Overriding_the_EJB_QL_to_SQL_Mapping">
 			<title>Overriding the EJB-QL to SQL Mapping</title>
 			<para>
-				The EJB-QL query can be overridden in the <literal>jbosscmp-jdbc.xml</literal> file. The finder or select is still required to have an EJB-QL declaration, but the <literal>ejb-ql</literal> element can be left empty. Currently the SQL can be overridden with JBossQL, DynamicQL, DeclaredSQL or a BMP style custom <literal>ejbFind</literal> method. All EJB-QL overrides are non-standard extensions to the EJB specification, so use of these extensions will limit portability of your application. All of the EJB-QL overrides, except for BMP custom finders, are declared using a <literal>query</literal> element in the jbosscmp-jdbc.xml file. Tthe content model is shown in <xref linkend="Overriding_the_EJB_QL_to_SQL_Mapping-The_jbosscmp_jdbc_query_element_content_model" />.
+				The EJB-QL query can be overridden in the <literal>jbosscmp-jdbc.xml</literal> file. The finder or select is still required to have an EJB-QL declaration, but the <literal>ejb-ql</literal> element can be left empty. Currently the SQL can be overridden with JBossQL, DynamicQL, DeclaredSQL or a BMP style custom <literal>ejbFind</literal> method. All EJB-QL overrides are non-standard extensions to the EJB specification, so use of these extensions will limit portability of your application. All of the EJB-QL overrides, except for BMP custom finders, are declared using a <literal>query</literal> element in the jbosscmp-jdbc.xml file. The content model is shown in <xref linkend="Overriding_the_EJB_QL_to_SQL_Mapping-The_jbosscmp_jdbc_query_element_content_model" />.
 			</para>
 			<figure id="Overriding_the_EJB_QL_to_SQL_Mapping-The_jbosscmp_jdbc_query_element_content_model">
 				<title>The jbosscmp-jdbc query element content model</title>




More information about the jboss-cvs-commits mailing list