You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@tomee.apache.org by bu...@apache.org on 2015/04/20 11:30:24 UTC
svn commit: r948378 - in /websites/staging/tomee/trunk: cgi-bin/ content/
content/deployment-id.html
Author: buildbot
Date: Mon Apr 20 09:30:24 2015
New Revision: 948378
Log:
Staging update by buildbot for tomee
Modified:
websites/staging/tomee/trunk/cgi-bin/ (props changed)
websites/staging/tomee/trunk/content/ (props changed)
websites/staging/tomee/trunk/content/deployment-id.html
Propchange: websites/staging/tomee/trunk/cgi-bin/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Mon Apr 20 09:30:24 2015
@@ -1 +1 @@
-1673978
+1674771
Propchange: websites/staging/tomee/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Mon Apr 20 09:30:24 2015
@@ -1 +1 @@
-1673978
+1674771
Modified: websites/staging/tomee/trunk/content/deployment-id.html
==============================================================================
--- websites/staging/tomee/trunk/content/deployment-id.html (original)
+++ websites/staging/tomee/trunk/content/deployment-id.html Mon Apr 20 09:30:24 2015
@@ -175,7 +175,7 @@ modification.</p>
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
@@ -191,7 +191,7 @@ difference.</p>
<p>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.</p>
@@ -216,8 +216,8 @@ In other words, be very careful with the
<h2>In the container system</h2>
-<p>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
+<p>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.</p>
@@ -234,9 +234,9 @@ machine. For this reason, it often refer
<p>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.</p>
@@ -286,7 +286,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.</p>
<p>Just as before, clients can lookup beans from the Remote Server using the