You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by bu...@apache.org on 2011/12/18 18:58:13 UTC
svn commit: r800472 - in /websites/staging/openejb/trunk/content:
examples-trunk/simple-cdi-interceptor/README.html singleton-example.html
Author: buildbot
Date: Sun Dec 18 17:58:12 2011
New Revision: 800472
Log:
Staging update by buildbot
Modified:
websites/staging/openejb/trunk/content/examples-trunk/simple-cdi-interceptor/README.html
websites/staging/openejb/trunk/content/singleton-example.html
Modified: websites/staging/openejb/trunk/content/examples-trunk/simple-cdi-interceptor/README.html
==============================================================================
--- websites/staging/openejb/trunk/content/examples-trunk/simple-cdi-interceptor/README.html (original)
+++ websites/staging/openejb/trunk/content/examples-trunk/simple-cdi-interceptor/README.html Sun Dec 18 17:58:12 2011
@@ -102,9 +102,7 @@ public void aMethod(){...}
@Target({ TYPE, METHOD })
@Retention(RUNTIME)
public @interface Log {</div>
-</pre>
-
-<p></code></p>
+</code></pre>
<p>Sure, you haven't missed the @InterceptorBinding annotation above ! Now that our custom annotation is created, lets attach it (or to use a better term for it, "bind it" )
to an interceptor. </p>
@@ -121,9 +119,7 @@ public class LoggingInterceptor {
//or logger.info statement
return ctx.proceed();
</div>}
-</pre>
-
-<p></code></p>
+</code></pre>
<p>Now the @Log annotation we created is bound to this interceptor.</p>
@@ -163,16 +159,6 @@ But we'll see that in another example on
<p>Fire up the test, and we should see a 'Entering method: getMoviesList' printed in the console.</p>
-<h1>Code</h1>
-
-<h4>Java files</h4>
-
-<p>${javas}</p>
-
-<h5>Resource files</h5>
-
-<p>${resources} </p>
-
<h1>Download</h1>
<p><a href="${zip}">Download as zip</a> </p>
Modified: websites/staging/openejb/trunk/content/singleton-example.html
==============================================================================
--- websites/staging/openejb/trunk/content/singleton-example.html (original)
+++ websites/staging/openejb/trunk/content/singleton-example.html Sun Dec 18 17:58:12 2011
@@ -126,14 +126,11 @@ public class PropertyRegistryBean implem
return (String) properties.remove(key);
}
</div>
-</pre>
-
-<p></code></p>
+</code></pre>
-<div class="container">
-ComponentRegistryBean
+<p>ComponentRegistryBean</p>
-Here we see a bean that uses the Container-Managed Concurrency option, the default. With @ConcurrencyManagement(CONTAINER) the container controls whether multi-threaded access should be allowed to the bean (@Lock(READ)) or if single-threaded access should be enforced (@Lock(WRITE)).
+<p>Here we see a bean that uses the Container-Managed Concurrency option, the default. With @ConcurrencyManagement(CONTAINER) the container controls whether multi-threaded access should be allowed to the bean (@Lock(READ)) or if single-threaded access should be enforced (@Lock(WRITE)).</p>
<pre><code>
import static javax.ejb.LockType.READ;
@@ -170,20 +167,23 @@ public class ComponentRegistryBean imple
}
</div>
</code></pre>
-Unless specified explicitly on the bean class or a method, the default @Lock value is @Lock(WRITE). The code above uses the @Lock(READ) annotation on bean class to change the default so that multi-threaded access is granted by default. We then only need to apply the @Lock(WRITE) annotation to the methods that modify the state of the bean.
-Essentially @Lock(READ) allows multithreaded access to the Singleton bean instance unless someone is invoking an @Lock(WRITE) method. With @Lock(WRITE), the thread invoking the bean will be guaranteed to have exclusive access to the Singleton bean instance for the duration of its invocation. This combination allows the bean instance to use data types that are not normally thread safe. Great care must still be used, though.
+<p>Unless specified explicitly on the bean class or a method, the default @Lock value is @Lock(WRITE). The code above uses the @Lock(READ) annotation on bean class to change the default so that multi-threaded access is granted by default. We then only need to apply the @Lock(WRITE) annotation to the methods that modify the state of the bean.</p>
-In the example we see ComponentRegistryBean using a java.util.HashMap which is not synchronized. To make this ok we do three things:
+<p>Essentially @Lock(READ) allows multithreaded access to the Singleton bean instance unless someone is invoking an @Lock(WRITE) method. With @Lock(WRITE), the thread invoking the bean will be guaranteed to have exclusive access to the Singleton bean instance for the duration of its invocation. This combination allows the bean instance to use data types that are not normally thread safe. Great care must still be used, though.</p>
- 1. Encapsulation. We don't expose the HashMap instance directly; including its iterators, key set, value set or entry set.
- 2. We use @Lock(WRITE) on the methods that mutate the map such as the put() and remove() methods.
- 3. We use @Lock(READ) on the get() and values() methods as they do not change the map state and are guaranteed not to be called at the same as any of the @Lock(WRITE) methods, so we know the state of the HashMap is no being mutated and therefore safe for reading.
+<p>In the example we see ComponentRegistryBean using a java.util.HashMap which is not synchronized. To make this ok we do three things:</p>
-The end result is that the threading model for this bean will switch from multi-threaded access to single-threaded access dynamically as needed depending on the which methods are being invoked. This gives Singletons a bit of an advantage over Servlets for processing multi-threaded requests.
+<ol>
+<li>Encapsulation. We don't expose the HashMap instance directly; including its iterators, key set, value set or entry set.</li>
+<li>We use @Lock(WRITE) on the methods that mutate the map such as the put() and remove() methods.</li>
+<li>We use @Lock(READ) on the get() and values() methods as they do not change the map state and are guaranteed not to be called at the same as any of the @Lock(WRITE) methods, so we know the state of the HashMap is no being mutated and therefore safe for reading.</li>
+</ol>
-See the Singleton Beans page for more advanced details on Container-Managed Concurrency.
-Test Case
+<p>The end result is that the threading model for this bean will switch from multi-threaded access to single-threaded access dynamically as needed depending on the which methods are being invoked. This gives Singletons a bit of an advantage over Servlets for processing multi-threaded requests.</p>
+
+<p>See the Singleton Beans page for more advanced details on Container-Managed Concurrency.
+Test Case</p>
<pre><code>
public class ComponentRegistryBeanTest extends TestCase {
@@ -203,18 +203,18 @@ public class ComponentRegistryBeanTest e
Date actualDate = one.getComponent(Date.class);
assertSame(expectedDate, actualDate);
</div>}
-</pre></code>
+</code></pre>
-#Running
+<h1>Running</h1>
-Running the example is fairly simple. In the "simple-singleton" directory run:
+<p>Running the example is fairly simple. In the "simple-singleton" directory run:</p>
-$ mvn clean install
+<p>$ mvn clean install</p>
-Which should create output like the following.
+<p>Which should create output like the following.</p>
+<h1>Tests</h1>
-#Tests
<pre><code>
Running org.superbiz.registry.ComponentRegistryBeanTest
Apache OpenEJB 3.1-SNAPSHOT build: 20080820-09:53
@@ -242,8 +242,9 @@ Tests run: 1, Failures: 0, Errors: 0, Sk
Results :
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
-</pre></code>
-</div>
+</code></pre>
+
+<p></div></p>