svn commit: r1674771 - /tomee/site/trunk/content/deployment-id.mdtext

[an...@apache.org]

Author: andygumbrecht
Date: Mon Apr 20 09:28:21 2015
New Revision: 1674771

URL: http://svn.apache.org/r1674771
Log:
CMS commit to tomee by andygumbrecht

Modified:
    tomee/site/trunk/content/deployment-id.mdtext

Modified: tomee/site/trunk/content/deployment-id.mdtext
URL: http://svn.apache.org/viewvc/tomee/site/trunk/content/deployment-id.mdtext?rev=1674771&r1=1674770&r2=1674771&view=diff
==============================================================================
--- tomee/site/trunk/content/deployment-id.mdtext (original)
+++ tomee/site/trunk/content/deployment-id.mdtext Mon Apr 20 09:28:21 2015
@@ -1,4 +1,5 @@
 Title: Deployment ID
+
 <a name="DeploymentID-WhatisaDeploymentID?"></a>
 # What is a Deployment ID?
 
@@ -28,7 +29,7 @@ Let's consider this, what happens if two
 that contains a bean with the <ejb-name> PurchaseOrder? Both are completely
 different in terms functionality and are different beans in every other
 respect. The EJB spec says, this is fine, ejb-names only have to unique
-within the jar and that jar's ejb-jar.xml file. It's redictulous to excpect
+within the jar and that jar's ejb-jar.xml file. It's ridiculous to expect
 EJB Providers to call each other up and ask, "Are you already using the
 name 'PurchaseOrder' in your jar?" Remember that the EJB specification was
 designed so that enterprise beans could be create, packaged, and sold by
@@ -43,7 +44,7 @@ difference.
 
 OpenEJB solves this with the OpenEJB-specific deployment id. By requiring
 that each bean deployed into OpenEJB has a unique name, we can guarantee
-that we are always refering to the right bean at all times. Futhermore, it
+that we are always referring to the right bean at all times. Furthermore, it
 allows you to deploy different versions of the same package several times
 in the same container system, each time giving the beans new deployment
 ids.
@@ -65,8 +66,8 @@ In other words, be very careful with the
 <a name="DeploymentID-Inthecontainersystem"></a>
 ## In the container system
 
-In the container system, the deployment id is used to undex the bean in a
-system-wide registry. This registry is refered to on every call made in the
+In the container system, the deployment id is used to index the bean in a
+system-wide registry. This registry is refereed to on every call made in the
 container system. Being able to safely hash and cache bean information by
 id is a must. This stresses the importance of unique ids for every bean
 deployed in OpenEJB.
@@ -82,9 +83,9 @@ machine. For this reason, it often refer
 For bean to bean communications, the Local Server must create a JNDI
 namespace (JNDI ENC) for each bean as defined by the bean's <env-entry>,
 <ejb-ref>, and <resource-ref> elements of the bean's ejb-jar.xml file.
-Every bean litterally gets its very own JNDI namespace. When a bean makes a
+Every bean literally gets its very own JNDI namespace. When a bean makes a
 JNDI call, the Local Server intercepts this call and uses the deployment id
-of the calling bean to retreive that bean's private JNDI namespace from the
+of the calling bean to retrieve that bean's private JNDI namespace from the
 container system's index. The Local Server then carries out the lookup on
 that bean's namespace.
 
@@ -133,7 +134,7 @@ does. The difference being that the Remo
 outside the container system and outside the virtual machine. So, all
 clients from the perspective of the Remote Server are non-bean clients. As
 a result, the Remote Server only has the one public, global JNDI namespace.
-Just as in the Local Server, the names in this namespacse consist of the
+Just as in the Local Server, the names in this namespace consist of the
 deployment ids of the beans in the container system.
 
 Just as before, clients can lookup beans from the Remote Server using the