[jboss-cvs] JBossAS SVN: r83262 - in projects/ejb3/trunk/docs/tutorial: asynch and 26 other directories.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Jan 22 05:07:11 EST 2009
Author: jaikiran
Date: 2009-01-22 05:07:10 -0500 (Thu, 22 Jan 2009)
New Revision: 83262
Removed:
projects/ejb3/trunk/docs/tutorial/asynch/asynch.html
projects/ejb3/trunk/docs/tutorial/asynch/asynch.wiki
projects/ejb3/trunk/docs/tutorial/blob/blob.html
projects/ejb3/trunk/docs/tutorial/blob/blob.wiki
projects/ejb3/trunk/docs/tutorial/callbacks/callbacks.html
projects/ejb3/trunk/docs/tutorial/callbacks/callbacks.wiki
projects/ejb3/trunk/docs/tutorial/composite/composite.html
projects/ejb3/trunk/docs/tutorial/composite/composite.wiki
projects/ejb3/trunk/docs/tutorial/consumer/consumer.html
projects/ejb3/trunk/docs/tutorial/consumer/consumer.wiki
projects/ejb3/trunk/docs/tutorial/consumer_deployment_descriptor/consumer.html
projects/ejb3/trunk/docs/tutorial/consumer_deployment_descriptor/consumer.wiki
projects/ejb3/trunk/docs/tutorial/ejb21_client_adaptors/ejb21_client_adaptors.html
projects/ejb3/trunk/docs/tutorial/ejb21_client_adaptors/ejb21_client_adaptors.wiki
projects/ejb3/trunk/docs/tutorial/embeddable/dependent.html
projects/ejb3/trunk/docs/tutorial/embeddable/dependent.wiki
projects/ejb3/trunk/docs/tutorial/entity/entity.html
projects/ejb3/trunk/docs/tutorial/entity/entity.wiki
projects/ejb3/trunk/docs/tutorial/extended_pc/extended.html
projects/ejb3/trunk/docs/tutorial/extended_pc/extended.wiki
projects/ejb3/trunk/docs/tutorial/injection/injection.html
projects/ejb3/trunk/docs/tutorial/injection/injection.wiki
projects/ejb3/trunk/docs/tutorial/interceptor/interceptor.html
projects/ejb3/trunk/docs/tutorial/interceptor/interceptor.wiki
projects/ejb3/trunk/docs/tutorial/jndibinding/jndi.html
projects/ejb3/trunk/docs/tutorial/jndibinding/jndi.wiki
projects/ejb3/trunk/docs/tutorial/joininheritance/join.html
projects/ejb3/trunk/docs/tutorial/joininheritance/join.wiki
projects/ejb3/trunk/docs/tutorial/mdb/mdb.html
projects/ejb3/trunk/docs/tutorial/mdb/mdb.wiki
projects/ejb3/trunk/docs/tutorial/mdb_deployment_descriptor/mdb.html
projects/ejb3/trunk/docs/tutorial/mdb_deployment_descriptor/mdb.wiki
projects/ejb3/trunk/docs/tutorial/merge/merge.html
projects/ejb3/trunk/docs/tutorial/merge/merge.wiki
projects/ejb3/trunk/docs/tutorial/relationships/relationships.html
projects/ejb3/trunk/docs/tutorial/relationships/relationships.wiki
projects/ejb3/trunk/docs/tutorial/resource_ref/jboss_rr.wiki
projects/ejb3/trunk/docs/tutorial/secondary/secondary.html
projects/ejb3/trunk/docs/tutorial/secondary/secondary.wiki
projects/ejb3/trunk/docs/tutorial/security/security.html
projects/ejb3/trunk/docs/tutorial/security/security.wiki
projects/ejb3/trunk/docs/tutorial/singleinheritance/single.html
projects/ejb3/trunk/docs/tutorial/singleinheritance/single.wiki
projects/ejb3/trunk/docs/tutorial/stateful/stateful.html
projects/ejb3/trunk/docs/tutorial/stateful/stateful.wiki
projects/ejb3/trunk/docs/tutorial/stateful_deployment_descriptor/stateful.html
projects/ejb3/trunk/docs/tutorial/stateful_deployment_descriptor/stateful.wiki
projects/ejb3/trunk/docs/tutorial/stateless/stateless.html
projects/ejb3/trunk/docs/tutorial/stateless/stateless.wiki
projects/ejb3/trunk/docs/tutorial/stateless_deployment_descriptor/stateless.html
projects/ejb3/trunk/docs/tutorial/stateless_deployment_descriptor/stateless.wiki
projects/ejb3/trunk/docs/tutorial/timer/timer.html
projects/ejb3/trunk/docs/tutorial/timer/timer.wiki
Modified:
projects/ejb3/trunk/docs/tutorial/pom.xml
Log:
1) Updating parent pom to include remaining tutorials2) Removed unused .html and .wiki files from tutorials
Deleted: projects/ejb3/trunk/docs/tutorial/asynch/asynch.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/asynch/asynch.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/asynch/asynch.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,81 +0,0 @@
-<html>
-<body>
-<p>
-<h2> Asynchronous calls</h2>
-
-</p><p>
-A JBoss extension to EJB 3.0 is that from the remote or local interface of a stateful session bean, stateless session bean or service bean you can obtain an asynchronous proxy. Methods called on the asynchronous proxy will be executed asynchronously, and the results can be obtained later on.
-</p><p>
-<h3>Example simple ServicePOJO</h3>
-
-Take a look at <a href="src/org/jboss/tutorial/asynch/bean/Echo.java">Echo.java</a> and <a href="src/org/jboss/tutorial/asynch/bean/EchoRemote.java">EchoRemote.java</a>. They define a normal stateless session bean with a remote interface, nothing special. Now take a look at <a href="src/org/jboss/tutorial/asynch/client/Client.java">Client.java</a>. It shows an example of asynchronous calls on a remote interface. We will walk through what it does here. The following lines just obtain the remote interface of the bean and call a method following the standard synchronous usage pattern
-<pre>
- InitialContext ctx = new InitialContext();
- Echo echo = (Echo)ctx.lookup(org.jboss.tutorial.asynch.bean.Echo.class.getName());
- System.out.println("-------- Synchronous call");
- String ret = echo.echo("normal call");
- System.out.println(ret);
-</pre>
-</p><p>
-Next we obtain the asynchronous proxy and make a call via that. The method will be invoked asynchronously
-</p><p>
-<pre>
- Echo asynchEcho = Asynch.getAsynchronousProxy(echo);
- System.out.println("-------- Asynchronous call");
- ret = asynchEcho.echo("asynchronous call");
- System.out.println("Direct return of async invocation is: " + ret);
-</pre>
-</p><p>
-As shown, you obtain the asynchronous proxy by calling <tt>org.jboss.ejb3.asynchronous.Asynch.getAsynchronousProxy()</tt> . All methods invoked on this proxy are invoked asynchronously, and the returned value will always be null (or 0 in the case of numeric primitive types). In this example, the echo() method called has low overhead, but imagine if this was a method that took a long time. In this case it would be good to be able to go ahead with some other tasks. In Client.java, we make another call on the normal remote interface while "waiting" for the asynchronous call.
-</p><p>
-<pre>
- System.out.println("-------- Synchronous call");
- ret = echo.echo("normal call 2");
- System.out.println(ret);
-</pre>
-</p><p>
-Now that we have finished everything we want to do while waiting for the asynchronus call to complete, we cast the asynchronus proxy to <tt>AsynchProvider</tt> and get hold of the <tt>Future</tt> contained.
-</p><p>
-<pre>
- System.out.println("-------- Result of Asynchronous call");
- AsynchProvider provider = (AsynchProvider)asynchEcho;
- Future future = provider.getFuture();
-</pre>
-</p><p>
-Next we make sure that the asynchronus invocation has completed, and get the return value of the asynchronus invocation.
-<pre>
- System.out.println("Waiting for asynbch invocation to complete");
- while (!future.isDone())
- {
- Thread.sleep(100);
- }
- ret = (String)future.get();
- System.out.println(ret);
-</pre>
-</p><p>
-</p><p>
-<h3>Building and running</h3>
-
-To build and run the example, make sure you have ejb3.deployer installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-</p><p>
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-Buildfile: build.xml
-
-run:
- [java] -------- Synchronous call
- [java] normal call
- [java] -------- Asynchronous call
- [java] Direct return of async invocation is: null
- [java] -------- Synchronous call
- [java] normal call 2
- [java] -------- Result of Asynchronous call
- [java] Waiting for asynbch invocation to complete
- [java] asynchronous call
-</pre>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/asynch/asynch.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/asynch/asynch.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/asynch/asynch.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,72 +0,0 @@
-!!! Asynchronous calls
-
-A JBoss extension to EJB 3.0 is that from the remote or local interface of a stateful session bean, stateless session bean or service bean you can obtain an asynchronous proxy. Methods called on the asynchronous proxy will be executed asynchronously, and the results can be obtained later on.
-
-!!Example simple ServicePOJO
-Take a look at [Echo.java|src/org/jboss/tutorial/asynch/bean/Echo.java] and [EchoRemote.java|src/org/jboss/tutorial/asynch/bean/EchoRemote.java]. They define a normal stateless session bean with a remote interface, nothing special. Now take a look at [Client.java|src/org/jboss/tutorial/asynch/client/Client.java]. It shows an example of asynchronous calls on a remote interface. We will walk through what it does here. The following lines just obtain the remote interface of the bean and call a method following the standard synchronous usage pattern
-{{{
- InitialContext ctx = new InitialContext();
- Echo echo = (Echo)ctx.lookup(org.jboss.tutorial.asynch.bean.Echo.class.getName());
- System.out.println("-------- Synchronous call");
- String ret = echo.echo("normal call");
- System.out.println(ret);
-}}}
-
-Next we obtain the asynchronous proxy and make a call via that. The method will be invoked asynchronously
-
-{{{
- Echo asynchEcho = Asynch.getAsynchronousProxy(echo);
- System.out.println("-------- Asynchronous call");
- ret = asynchEcho.echo("asynchronous call");
- System.out.println("Direct return of async invocation is: " + ret);
-}}}
-
-As shown, you obtain the asynchronous proxy by calling {{org.jboss.ejb3.asynchronous.Asynch.getAsynchronousProxy()}} . All methods invoked on this proxy are invoked asynchronously, and the returned value will always be null (or 0 in the case of numeric primitive types). In this example, the echo() method called has low overhead, but imagine if this was a method that took a long time. In this case it would be good to be able to go ahead with some other tasks. In Client.java, we make another call on the normal remote interface while "waiting" for the asynchronous call.
-
-{{{
- System.out.println("-------- Synchronous call");
- ret = echo.echo("normal call 2");
- System.out.println(ret);
-}}}
-
-Now that we have finished everything we want to do while waiting for the asynchronus call to complete, we cast the asynchronus proxy to {{AsynchProvider}} and get hold of the {{Future}} contained.
-
-{{{
- System.out.println("-------- Result of Asynchronous call");
- AsynchProvider provider = (AsynchProvider)asynchEcho;
- Future future = provider.getFuture();
-}}}
-
-Next we make sure that the asynchronus invocation has completed, and get the return value of the asynchronus invocation.
-{{{
- System.out.println("Waiting for asynbch invocation to complete");
- while (!future.isDone())
- {
- Thread.sleep(100);
- }
- ret = (String)future.get();
- System.out.println(ret);
-}}}
-
-
-!!Building and running
-To build and run the example, make sure you have ejb3.deployer installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-Buildfile: build.xml
-
-run:
- [java] -------- Synchronous call
- [java] normal call
- [java] -------- Asynchronous call
- [java] Direct return of async invocation is: null
- [java] -------- Synchronous call
- [java] normal call 2
- [java] -------- Result of Asynchronous call
- [java] Waiting for asynbch invocation to complete
- [java] asynchronous call
-}}}
Deleted: projects/ejb3/trunk/docs/tutorial/blob/blob.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/blob/blob.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/blob/blob.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,153 +0,0 @@
-<html>
-<body>
-<p>
-<h2>java.sql.Blob and Clob support</h2>
-
-The EJB 3.0 specification has support for Blob and Clob types. The specification allows you to map the following types to
-an entity property:
-<ul>
-<li><tt>java.sql.Blob</tt></li>
-<li> <tt>java.sql.Clob</tt></li>
-<li> any Serializable Object</li>
-<li> <pre>byte[], Byte[]</pre></li>
-<li> <pre>char[], String, Character[] </pre></li>
-</ul>
-</p><p>
-To use this feature just need to use the <tt>@javax.persistence.Lob</tt> annotation.
-The <tt>Lob</tt> annotation is an
-encapsulation of what type of lob you want. Below is an example of defining fields in an entity that are blobs or clobs.
-</p><p>
-<pre>
- at Entity
-public class BlobEntity implements Serializable
-{
- private long id;
- private Blob blobby;
- private Clob clobby;
-
- @Id @GeneratedValue(strategy=GenerationType.IDENTITY)
- public long getId()
- {
- return id;
- }
-
- public void setId(long id)
- {
- this.id = id;
- }
-
- @Lob @Basic(fetch = FetchType.EAGER)
- public Blob getBlobby()
- {
- return blobby;
- }
-
- public void setBlobby(Blob blobby)
- {
- this.blobby = blobby;
- }
-
- @Lob @Basic(fetch = FetchType.EAGER)
- public Clob getClobby()
- {
- return clobby;
- }
-
- public void setClobby(Clob clobby)
- {
- this.clobby = clobby;
- }
-
-
-}
-</pre>
-</p><p>
-<h4>Working with Blobs and Clobs</h4>
-
-Open up <a href="src/org/jboss/tutorial/blob/bean/LobTesterBean.java">LobTesterBean</a> and look for the <tt>create()</tt> method. JBoss EJB3
-is built on top of the Hibernate persistence engine. Hibernate has some helper methods for creating blobs and clobs that <tt>LobTesterBean</tt>
-uses.
-</p><p>
-<b>Blob Creation</b>
-<table border="1">
-<tr><td><pre>org.hibernate.Hibernate.createBlob(byte[] bytes)</pre></td><td></td></tr>
-<tr><td><pre>org.hibernate.Hibernate.createBlob(InputStream stream, int length)</pre></td><td></td></tr>
-<tr><td><pre>org.hibernate.Hibernate.createBlob(InputStream stream)</pre></td><td></td></tr>
-</table>
-</p><p>
-</p><p>
-<b>Clob Creation</b>
-<table border="1">
-<tr><td><pre>org.hibernate.Hibernate.createClob(String string)</pre></td><td></td></tr>
-<tr><td><pre>org.hibernate.Hibernate.createClob(Reader reader, int length)</pre></td><td></td></tr>
-</table>
-</p><p>
-Blobs and clobs must only be accessed within a transaction. Blobs and clobs are also not serializable or detachable.
-</p><p>
-<h4>Mapping Strings/<pre>byte[]</pre> to Clob/Blob</h4>
-
-This is pretty easy, just look at BlobEntity2.java
-</p><p>
-<pre>
- at Entity
-public class BlobEntity2 implements Serializable
-{
- private long id;
- private byte[] blobby;
- private String clobby;
-
- @Id @GeneratedValue(strategy=GenerationType.AUTO)
- public long getId()
- {
- return id;
- }
-
- public void setId(long id)
- {
- this.id = id;
- }
-
- @Lob @Basic(fetch = FetchType.EAGER)
- public byte[] getBlobby()
- {
- return blobby;
- }
-
- public void setBlobby(byte[] blobby)
- {
- this.blobby = blobby;
- }
-
- @Lob @Basic(fetch = FetchType.EAGER)
- public String getClobby()
- {
- return clobby;
- }
-
- public void setClobby(String clobby)
- {
- this.clobby = clobby;
- }
-
-
-}
-</pre>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-</pre>
-</p><p>
-<h4>View the tables and rows</h4>
-
-You can view the tables created by JBoss by going to the <a href="http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB">Hypersonic SQL service</a>, scrolling down to the <tt>startDatabaseManager</tt> button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/blob/blob.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/blob/blob.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/blob/blob.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,136 +0,0 @@
-!!!java.sql.Blob and Clob support
-The EJB 3.0 specification has support for Blob and Clob types. The specification allows you to map the following types to
-an entity property:
-*{{java.sql.Blob}}
-* {{java.sql.Clob}}
-* any Serializable Object
-* {{{byte[], Byte[]}}}
-* {{{char[], String, Character[] }}}
-
-To use this feature just need to use the {{@javax.persistence.Lob}} annotation.
-The {{Lob}} annotation is an
-encapsulation of what type of lob you want. Below is an example of defining fields in an entity that are blobs or clobs.
-
-{{{
- at Entity
-public class BlobEntity implements Serializable
-{
- private long id;
- private Blob blobby;
- private Clob clobby;
-
- @Id @GeneratedValue(strategy=GenerationType.IDENTITY)
- public long getId()
- {
- return id;
- }
-
- public void setId(long id)
- {
- this.id = id;
- }
-
- @Lob @Basic(fetch = FetchType.EAGER)
- public Blob getBlobby()
- {
- return blobby;
- }
-
- public void setBlobby(Blob blobby)
- {
- this.blobby = blobby;
- }
-
- @Lob @Basic(fetch = FetchType.EAGER)
- public Clob getClobby()
- {
- return clobby;
- }
-
- public void setClobby(Clob clobby)
- {
- this.clobby = clobby;
- }
-
-
-}
-}}}
-
-!Working with Blobs and Clobs
-Open up [LobTesterBean|src/org/jboss/tutorial/blob/bean/LobTesterBean.java] and look for the {{create()}} method. JBoss EJB3
-is built on top of the Hibernate persistence engine. Hibernate has some helper methods for creating blobs and clobs that {{LobTesterBean}}
-uses.
-
-__Blob Creation__
-|{{{org.hibernate.Hibernate.createBlob(byte[] bytes)}}}|
-|{{{org.hibernate.Hibernate.createBlob(InputStream stream, int length)}}}|
-|{{{org.hibernate.Hibernate.createBlob(InputStream stream)}}}|
-
-
-__Clob Creation__
-|{{{org.hibernate.Hibernate.createClob(String string)}}}|
-|{{{org.hibernate.Hibernate.createClob(Reader reader, int length)}}}|
-
-Blobs and clobs must only be accessed within a transaction. Blobs and clobs are also not serializable or detachable.
-
-!Mapping Strings/{{{byte[]}}} to Clob/Blob
-This is pretty easy, just look at BlobEntity2.java
-
-{{{
- at Entity
-public class BlobEntity2 implements Serializable
-{
- private long id;
- private byte[] blobby;
- private String clobby;
-
- @Id @GeneratedValue(strategy=GenerationType.AUTO)
- public long getId()
- {
- return id;
- }
-
- public void setId(long id)
- {
- this.id = id;
- }
-
- @Lob @Basic(fetch = FetchType.EAGER)
- public byte[] getBlobby()
- {
- return blobby;
- }
-
- public void setBlobby(byte[] blobby)
- {
- this.blobby = blobby;
- }
-
- @Lob @Basic(fetch = FetchType.EAGER)
- public String getClobby()
- {
- return clobby;
- }
-
- public void setClobby(String clobby)
- {
- this.clobby = clobby;
- }
-
-
-}
-}}}
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-}}}
-
-!View the tables and rows
-You can view the tables created by JBoss by going to the [Hypersonic SQL service|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB], scrolling down to the {{startDatabaseManager}} button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-
Deleted: projects/ejb3/trunk/docs/tutorial/callbacks/callbacks.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/callbacks/callbacks.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/callbacks/callbacks.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,191 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Callbacks and Callback Handlers</h2>
-
-</p><p>
-The EJB 3.0 specification defines some callbacks, and allows you to handle these by implementing your own callback handlers.
-The callbacks defined for each bean are shown below:
-</p><p>
-<h3>Stateless session bean callbacks</h3>
-
-<ul>
-<li> <tt>PostConstruct</tt> - is invoked when the bean is first created, after any dependency injection is done.</li>
-<li> <tt>PreDestroy</tt> - is invoked when the bean is removed from the pool or destroyed.</li>
-</ul>
-</p><p>
-<h3>Message-driven bean callbacks</h3>
-
-<ul>
-<li> <tt>PostConstruct</tt> - is invoked when the bean is first created, after any dependency injection is done.</li>
-<li> <tt>PreDestroy</tt> - is invoked when the bean is removed from the pool or destroyed.</li>
-</ul>
-</p><p>
-<h3>Stateful session bean callbacks</h3>
-
-<ul>
-<li> <tt>PostConstruct</tt> - is invoked when the bean is first created, after any dependency injection is done.</li>
-<li> <tt>PreDestroy</tt> - is invoked when the bean is removed from the pool or destroyed. It will happen before any <tt>@Remove</tt> annotated method is invoked.</li>
-<li> <tt>PostActivate</tt> - is invoked when</li>
-<li> <tt>PrePassivate</tt> -</li>
-</ul>
-</p><p>
-<h3>Entity bean callbacks</h3>
-
-<ul>
-<li> <tt>PrePersist</tt> - Is invoked right before the entity is created in the database. Will cascade to all entities to which this operation is cascaded.</li>
-<li> <tt>PostPersist</tt> - Is invoked right after the entity is created in the database. Will cascade to all entities to which this operation is cascaded.</li>
-<li> <tt>PreRemove</tt> - Is invoked right before the entity is deleted in the database. Will cascade to all entities to which this operation is cascaded.</li>
-<li> <tt>PostRemove</tt> - Is invoked right after the entity is deleted in the database. Will cascade to all entities to which this operation is cascaded.</li>
-<li> <tt>PreUpdate</tt> - Takes place right before the database is updated.</li>
-<li> <tt>PostUpdate</tt> - Takes place immediately after the database has been updated.</li>
-<li> <tt>PostLoad</tt> - Takes place right after data has been loaded from the database and associated with the entity</li>
-</ul>
-</p><p>
-The callbacks are not compulsory, and you can define the ones you want to handle.
-</p><p>
-<h3>Using callbacks on the bean class</h3>
-
-You use the callbacks listed above by either annotating methods in the bean class. The annotations live in the <tt>javax.ejb</tt> package so for example <tt>PostConstruct</tt> would be <tt>javax.ejb.PostConstruct</tt>. You can call the methods what you like, but their method signature must return a void and take no arguments. Look at the <a href="src/org/jboss/tutorial/callback/bean/CustomerDAOBean.java">CustomerDAOBean</a> stateless session bean and you will see that the <tt>preDestroyCallback()</tt> method has been annotated with <tt>@javax.ejb.PreDestroy</tt>. For session/message-driven beans, just like for <a href="../interceptor/interceptor.html">Interceptors</a>, if the bean class extends another class any callback annotated methods on the super class will be invoked first.
-</p><p>
-</p><p>
-<h3>Entity listeners for entity beans</h3>
-
-You can also separate out the callbacks for entity beans into a separate EntityListener class. Take a look at the <a href="src/org/jboss/tutorial/callback/bean/Customer.java">Customer</a> entity bean, and you will see that the class has been annotated with
-<pre>@javax.persistence.EntityListener("org.jboss.tutorial.callback.bean.CustomerCallbackListener")</pre> This specifies that the <tt>org.jboss.tutorial.callback.bean.CustomerCallbackListener</tt> class should be used as the callback listener class for the bean. Now open <a href="src/org/jboss/tutorial/callback/bean/CustomerCallbackListener.java">CustomerCallbackListener</a> and you will see that the class annotates the callback methods in the same way as when defining callbacks on the bean class itself. However, one <b>important difference</b> is that callback methods defined in a listener class must take a single argument, which will be the bean we are working with. The parameter must be of type <tt>java.lang.Object</tt>, or the actual bean type.
-</p><p>
-<h3>Interceptors for session/message-driven beans</h3>
-
-Callbacks for session beans can also be put into a separate class, configured as an interceptor <a href="../interceptor/interceptor.html">Interceptors</a>. This means that your interceptors can initialise themselves when constructed. The lifecycle methods in an interceptor must have the following signature:
-</p><p>
-<pre>
- Object <any method name>(InvocationContext)
-</pre>
-</p><p>
-<a href="src/org/jboss/tutorial/callback/bean/CustomerDAOBean.java">CustomerDAOBean</a> specifies that it wants to use an external interceptor.
-<pre>
- at Stateless
- at Remote(CustomerDAO.class)
- at Interceptors({LifecycleInterceptor.class})
-public class CustomerDAOBean implements CustomerDAO
-{
- ...
-}
-</pre>
-</p><p>
-and <a href="src/org/jboss/tutorial/callback/bean/LifecycleInterceptor.java">LifecycleInterceptor</a> has a <tt>@PostConstruct</tt> annotated method. As shown, each interceptor lifecycle method must call <tt>proceed</tt> on the InvocationContext to invoke the next interceptor.
-</p><p>
-Interceptors may contain both the <tt>@AroundInvoke</tt> methods for intercepting business methods, and lifecycle methods. If you want to configure lifecycle methods for your interceptors with xml, you will need to do this in the <tt>interceptor</tt> section of ejb-jar.xml, and the keywords are <tt>post-construct-method</tt>, <tt>post-activate-method</tt>, <tt>pre-passivate-method</tt> and <tt>pre-destry-method</tt>. For example
-</p><p>
-<pre>
-<ejb-jar>
- <interceptors>
- <interceptor>
- <interceptor-class>org.acme.SomeInterceptor</interceptor-class>
- <around-invoke-method>
- <method-name>interceptorMethod</method-name>
- </around-invoke-method>
- <post-construct-method>
- <method-name>sendCancelMessage</method-name>
- </post-construct-method>
- <pre-destroy-method>
- <method-name>sendCancelMessage</method-name>
- </pre-destroy-method>
- </interceptor>
- </interceptors>
-</ejb-jar>
-</pre>
-</p><p>
-Interceptor methods for handling lifecycle events follow exactly the same ordering and inheritance rules as business method interceptor methods, and an interceptor instance follows the lifecycle of the bean instance it is bound to.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Create Bill Burke and Monica Smith
- [java] log4j:WARN No appenders could be found for logger (org.jboss.remoting.Client).
- [java] log4j:WARN Please initialize the log4j system properly.
- [java] Bill and Monica get married
- [java] Get all the Burkes
- [java] There are now 2 Burkes
- [java] Bill and Monica are moving abroad
-</pre>
-</p><p>
-In the jboss console window you should see:
-<pre>
-20:06:05,596 INFO [STDOUT] LifecycleInterceptor postConstruct
-20:06:05,596 INFO [STDOUT] PostConstruct - Have EntityManager: true
-20:06:05,596 INFO [STDOUT] -- CustomerDAOBean.create()
-20:06:05,596 INFO [STDOUT] doPrePersist: About to create Customer: Bill Burke
-20:06:05,596 INFO [STDOUT] doPostPersist: Created Customer: Bill Burke
-20:06:05,617 INFO [STDOUT] -- CustomerDAOBean.create()
-20:06:05,617 INFO [STDOUT] doPrePersist: About to create Customer: Monica Smith
-20:06:05,617 INFO [STDOUT] doPostPersist: Created Customer: Monica Smith
-20:06:05,617 INFO [STDOUT] -- CustomerDAOBean.find()
-20:06:05,627 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Smith
-20:06:05,627 INFO [STDOUT] -- CustomerDAOBean.merge()
-20:06:05,637 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Smith
-20:06:05,637 INFO [STDOUT] doPreUpdate: About to update Customer: Monica Burke
-20:06:05,657 INFO [STDOUT] doPostUpdate: Updated Customer: Monica Burke
-20:06:05,667 INFO [STDOUT] -- CustomerDAOBean.findByLastName(id)
-20:06:05,677 INFO [STDOUT] doPostLoad: Loaded Customer: Bill Burke
-20:06:05,677 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Burke
-20:06:05,687 INFO [STDOUT] -- CustomerDAOBean.delete()
-20:06:05,687 INFO [STDOUT] doPreRemove: About to delete Customer: Bill Burke
-20:06:05,687 INFO [STDOUT] doPreRemove: About to delete Customer: Monica Burke
-20:06:05,687 INFO [STDOUT] doPostRemove: Deleted Customer: Bill Burke
-20:06:05,697 INFO [STDOUT] doPostRemove: Deleted Customer: Monica Burke
-</pre>
-</p><p>
-Now if you open up JBOSS_HOME/server/all/deploy/ejb3.deployer/META-INF/hibernate.properties and add the following line
-</p><p>
-<pre>
-hibernate.show_sql=true
-</pre>
-</p><p>
-and restart JBoss before running the example again, the output should be:
-<pre>
-20:22:10,013 INFO [STDOUT] PostConstruct - Have EntityManager: true
-20:22:10,033 INFO [STDOUT] -- CustomerDAOBean.create()
-20:22:10,103 INFO [STDOUT] doPrePersist: About to create Customer: Bill Burke
-20:22:10,123 INFO [STDOUT] Hibernate: insert into CUSTOMER (STATE, FIRST, LAST, STREET, CITY, ZIP, id) values (?, ?, ?, ?, ?, ?, null)
-20:22:10,133 INFO [STDOUT] Hibernate: call identity()
-20:22:10,143 INFO [STDOUT] doPostPersist: Created Customer: Bill Burke
-20:22:10,194 INFO [STDOUT] -- CustomerDAOBean.create()
-20:22:10,194 INFO [STDOUT] doPrePersist: About to create Customer: Monica Smith
-20:22:10,194 INFO [STDOUT] Hibernate: insert into CUSTOMER (STATE, FIRST, LAST, STREET, CITY, ZIP, id) values (?, ?, ?, ?, ?, ?, null)
-20:22:10,194 INFO [STDOUT] Hibernate: call identity()
-20:22:10,194 INFO [STDOUT] doPostPersist: Created Customer: Monica Smith
-20:22:10,264 INFO [STDOUT] -- CustomerDAOBean.find()
-20:22:10,274 INFO [STDOUT] Hibernate: select customer0_.id as id0_, customer0_.STATE as STATE0_0_, customer0_.FIRST as FIRST0_0_, customer0_.LAST as LAST0_0_, customer0_.STREET as STREET0_0_, customer0_.CITY as CITY0_0_, customer0_.ZIP as ZIP0_0_ from CUSTOMER customer0_ where customer0_.id=?
-20:22:10,284 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Smith
-20:22:10,294 INFO [STDOUT] -- CustomerDAOBean.merge()
-20:22:10,304 INFO [STDOUT] Hibernate: select customer0_.id as id0_, customer0_.STATE as STATE0_0_, customer0_.FIRST as FIRST0_0_, customer0_.LAST as LAST0_0_, customer0_.STREET as STREET0_0_, customer0_.CITY as CITY0_0_, customer0_.ZIP as ZIP0_0_ from CUSTOMER customer0_ where customer0_.id=?
-20:22:10,304 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Smith
-20:22:10,304 INFO [STDOUT] doPreUpdate: About to update Customer: Monica Burke
-20:22:10,314 INFO [STDOUT] Hibernate: update CUSTOMER set STATE=?, FIRST=?, LAST=?, STREET=?, CITY=?, ZIP=? where id=?
-20:22:10,314 INFO [STDOUT] doPostUpdate: Updated Customer: Monica Burke
-20:22:10,324 INFO [STDOUT] -- CustomerDAOBean.findByLastName(id)
-20:22:10,604 INFO [STDOUT] Hibernate: select customer0_.id as id, customer0_.STATE as STATE0_, customer0_.FIRST as FIRST0_, customer0_.LAST as LAST0_
-, customer0_.STREET as STREET0_, customer0_.CITY as CITY0_, customer0_.ZIP as ZIP0_ from CUSTOMER customer0_ where (customer0_.LAST=? )
-20:22:10,604 INFO [STDOUT] doPostLoad: Loaded Customer: Bill Burke
-20:22:10,604 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Burke
-20:22:10,624 INFO [STDOUT] -- CustomerDAOBean.delete()
-20:22:10,634 INFO [STDOUT] doPreRemove: About to delete Customer: Bill Burke
-20:22:10,644 INFO [STDOUT] doPreRemove: About to delete Customer: Monica Burke
-20:22:10,644 INFO [STDOUT] Hibernate: delete from CUSTOMER where id=?
-20:22:10,644 INFO [STDOUT] doPostRemove: Deleted Customer: Bill Burke
-20:22:10,644 INFO [STDOUT] Hibernate: delete from CUSTOMER where id=?
-20:22:10,644 INFO [STDOUT] doPostRemove: Deleted Customer: Monica Burke
-</pre>
-</p><p>
-Thus you can see how the callbacks on the entity bean wrap the interaction with the database.
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/callbacks/callbacks.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/callbacks/callbacks.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/callbacks/callbacks.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,168 +0,0 @@
-!!!Callbacks and Callback Handlers
-
-The EJB 3.0 specification defines some callbacks, and allows you to handle these by implementing your own callback handlers.
-The callbacks defined for each bean are shown below:
-
-!!Stateless session bean callbacks
-* {{PostConstruct}} - is invoked when the bean is first created, after any dependency injection is done.
-* {{PreDestroy}} - is invoked when the bean is removed from the pool or destroyed.
-
-!!Message-driven bean callbacks
-* {{PostConstruct}} - is invoked when the bean is first created, after any dependency injection is done.
-* {{PreDestroy}} - is invoked when the bean is removed from the pool or destroyed.
-
-!!Stateful session bean callbacks
-* {{PostConstruct}} - is invoked when the bean is first created, after any dependency injection is done.
-* {{PreDestroy}} - is invoked when the bean is removed from the pool or destroyed. It will happen before any {{@Remove}} annotated method is invoked.
-* {{PostActivate}} - is invoked when
-* {{PrePassivate}} -
-
-!!Entity bean callbacks
-* {{PrePersist}} - Is invoked right before the entity is created in the database. Will cascade to all entities to which this operation is cascaded.
-* {{PostPersist}} - Is invoked right after the entity is created in the database. Will cascade to all entities to which this operation is cascaded.
-* {{PreRemove}} - Is invoked right before the entity is deleted in the database. Will cascade to all entities to which this operation is cascaded.
-* {{PostRemove}} - Is invoked right after the entity is deleted in the database. Will cascade to all entities to which this operation is cascaded.
-* {{PreUpdate}} - Takes place right before the database is updated.
-* {{PostUpdate}} - Takes place immediately after the database has been updated.
-* {{PostLoad}} - Takes place right after data has been loaded from the database and associated with the entity
-
-The callbacks are not compulsory, and you can define the ones you want to handle.
-
-!!Using callbacks on the bean class
-You use the callbacks listed above by either annotating methods in the bean class. The annotations live in the {{javax.ejb}} package so for example {{PostConstruct}} would be {{javax.ejb.PostConstruct}}. You can call the methods what you like, but their method signature must return a void and take no arguments. Look at the [CustomerDAOBean|src/org/jboss/tutorial/callback/bean/CustomerDAOBean.java] stateless session bean and you will see that the {{preDestroyCallback()}} method has been annotated with {{@javax.ejb.PreDestroy}}. For session/message-driven beans, just like for [Interceptors|../interceptor/interceptor.html], if the bean class extends another class any callback annotated methods on the super class will be invoked first.
-
-
-!!Entity listeners for entity beans
-You can also separate out the callbacks for entity beans into a separate EntityListener class. Take a look at the [Customer|src/org/jboss/tutorial/callback/bean/Customer.java] entity bean, and you will see that the class has been annotated with
-{{{@javax.persistence.EntityListener("org.jboss.tutorial.callback.bean.CustomerCallbackListener")}}} This specifies that the {{org.jboss.tutorial.callback.bean.CustomerCallbackListener}} class should be used as the callback listener class for the bean. Now open [CustomerCallbackListener|src/org/jboss/tutorial/callback/bean/CustomerCallbackListener.java] and you will see that the class annotates the callback methods in the same way as when defining callbacks on the bean class itself. However, one __important difference__ is that callback methods defined in a listener class must take a single argument, which will be the bean we are working with. The parameter must be of type {{java.lang.Object}}, or the actual bean type.
-
-!!Interceptors for session/message-driven beans
-Callbacks for session beans can also be put into a separate class, configured as an interceptor [Interceptors|../interceptor/interceptor.html]. This means that your interceptors can initialise themselves when constructed. The lifecycle methods in an interceptor must have the following signature:
-
-{{{
- Object <any method name>(InvocationContext)
-}}}
-
-[CustomerDAOBean|src/org/jboss/tutorial/callback/bean/CustomerDAOBean.java] specifies that it wants to use an external interceptor.
-{{{
- at Stateless
- at Remote(CustomerDAO.class)
- at Interceptors({LifecycleInterceptor.class})
-public class CustomerDAOBean implements CustomerDAO
-{
- ...
-}
-}}}
-
-and [LifecycleInterceptor|src/org/jboss/tutorial/callback/bean/LifecycleInterceptor.java] has a {{@PostConstruct}} annotated method. As shown, each interceptor lifecycle method must call {{proceed}} on the InvocationContext to invoke the next interceptor.
-
-Interceptors may contain both the {{@AroundInvoke}} methods for intercepting business methods, and lifecycle methods. If you want to configure lifecycle methods for your interceptors with xml, you will need to do this in the {{interceptor}} section of ejb-jar.xml, and the keywords are {{post-construct-method}}, {{post-activate-method}}, {{pre-passivate-method}} and {{pre-destry-method}}. For example
-
-{{{
-<ejb-jar>
- <interceptors>
- <interceptor>
- <interceptor-class>org.acme.SomeInterceptor</interceptor-class>
- <around-invoke-method>
- <method-name>interceptorMethod</method-name>
- </around-invoke-method>
- <post-construct-method>
- <method-name>sendCancelMessage</method-name>
- </post-construct-method>
- <pre-destroy-method>
- <method-name>sendCancelMessage</method-name>
- </pre-destroy-method>
- </interceptor>
- </interceptors>
-</ejb-jar>
-}}}
-
-Interceptor methods for handling lifecycle events follow exactly the same ordering and inheritance rules as business method interceptor methods, and an interceptor instance follows the lifecycle of the bean instance it is bound to.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Create Bill Burke and Monica Smith
- [java] log4j:WARN No appenders could be found for logger (org.jboss.remoting.Client).
- [java] log4j:WARN Please initialize the log4j system properly.
- [java] Bill and Monica get married
- [java] Get all the Burkes
- [java] There are now 2 Burkes
- [java] Bill and Monica are moving abroad
-}}}
-
-In the jboss console window you should see:
-{{{
-20:06:05,596 INFO [STDOUT] LifecycleInterceptor postConstruct
-20:06:05,596 INFO [STDOUT] PostConstruct - Have EntityManager: true
-20:06:05,596 INFO [STDOUT] -- CustomerDAOBean.create()
-20:06:05,596 INFO [STDOUT] doPrePersist: About to create Customer: Bill Burke
-20:06:05,596 INFO [STDOUT] doPostPersist: Created Customer: Bill Burke
-20:06:05,617 INFO [STDOUT] -- CustomerDAOBean.create()
-20:06:05,617 INFO [STDOUT] doPrePersist: About to create Customer: Monica Smith
-20:06:05,617 INFO [STDOUT] doPostPersist: Created Customer: Monica Smith
-20:06:05,617 INFO [STDOUT] -- CustomerDAOBean.find()
-20:06:05,627 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Smith
-20:06:05,627 INFO [STDOUT] -- CustomerDAOBean.merge()
-20:06:05,637 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Smith
-20:06:05,637 INFO [STDOUT] doPreUpdate: About to update Customer: Monica Burke
-20:06:05,657 INFO [STDOUT] doPostUpdate: Updated Customer: Monica Burke
-20:06:05,667 INFO [STDOUT] -- CustomerDAOBean.findByLastName(id)
-20:06:05,677 INFO [STDOUT] doPostLoad: Loaded Customer: Bill Burke
-20:06:05,677 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Burke
-20:06:05,687 INFO [STDOUT] -- CustomerDAOBean.delete()
-20:06:05,687 INFO [STDOUT] doPreRemove: About to delete Customer: Bill Burke
-20:06:05,687 INFO [STDOUT] doPreRemove: About to delete Customer: Monica Burke
-20:06:05,687 INFO [STDOUT] doPostRemove: Deleted Customer: Bill Burke
-20:06:05,697 INFO [STDOUT] doPostRemove: Deleted Customer: Monica Burke
-}}}
-
-Now if you open up JBOSS_HOME/server/all/deploy/ejb3.deployer/META-INF/hibernate.properties and add the following line
-
-{{{
-hibernate.show_sql=true
-}}}
-
-and restart JBoss before running the example again, the output should be:
-{{{
-20:22:10,013 INFO [STDOUT] PostConstruct - Have EntityManager: true
-20:22:10,033 INFO [STDOUT] -- CustomerDAOBean.create()
-20:22:10,103 INFO [STDOUT] doPrePersist: About to create Customer: Bill Burke
-20:22:10,123 INFO [STDOUT] Hibernate: insert into CUSTOMER (STATE, FIRST, LAST, STREET, CITY, ZIP, id) values (?, ?, ?, ?, ?, ?, null)
-20:22:10,133 INFO [STDOUT] Hibernate: call identity()
-20:22:10,143 INFO [STDOUT] doPostPersist: Created Customer: Bill Burke
-20:22:10,194 INFO [STDOUT] -- CustomerDAOBean.create()
-20:22:10,194 INFO [STDOUT] doPrePersist: About to create Customer: Monica Smith
-20:22:10,194 INFO [STDOUT] Hibernate: insert into CUSTOMER (STATE, FIRST, LAST, STREET, CITY, ZIP, id) values (?, ?, ?, ?, ?, ?, null)
-20:22:10,194 INFO [STDOUT] Hibernate: call identity()
-20:22:10,194 INFO [STDOUT] doPostPersist: Created Customer: Monica Smith
-20:22:10,264 INFO [STDOUT] -- CustomerDAOBean.find()
-20:22:10,274 INFO [STDOUT] Hibernate: select customer0_.id as id0_, customer0_.STATE as STATE0_0_, customer0_.FIRST as FIRST0_0_, customer0_.LAST as LAST0_0_, customer0_.STREET as STREET0_0_, customer0_.CITY as CITY0_0_, customer0_.ZIP as ZIP0_0_ from CUSTOMER customer0_ where customer0_.id=?
-20:22:10,284 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Smith
-20:22:10,294 INFO [STDOUT] -- CustomerDAOBean.merge()
-20:22:10,304 INFO [STDOUT] Hibernate: select customer0_.id as id0_, customer0_.STATE as STATE0_0_, customer0_.FIRST as FIRST0_0_, customer0_.LAST as LAST0_0_, customer0_.STREET as STREET0_0_, customer0_.CITY as CITY0_0_, customer0_.ZIP as ZIP0_0_ from CUSTOMER customer0_ where customer0_.id=?
-20:22:10,304 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Smith
-20:22:10,304 INFO [STDOUT] doPreUpdate: About to update Customer: Monica Burke
-20:22:10,314 INFO [STDOUT] Hibernate: update CUSTOMER set STATE=?, FIRST=?, LAST=?, STREET=?, CITY=?, ZIP=? where id=?
-20:22:10,314 INFO [STDOUT] doPostUpdate: Updated Customer: Monica Burke
-20:22:10,324 INFO [STDOUT] -- CustomerDAOBean.findByLastName(id)
-20:22:10,604 INFO [STDOUT] Hibernate: select customer0_.id as id, customer0_.STATE as STATE0_, customer0_.FIRST as FIRST0_, customer0_.LAST as LAST0_
-, customer0_.STREET as STREET0_, customer0_.CITY as CITY0_, customer0_.ZIP as ZIP0_ from CUSTOMER customer0_ where (customer0_.LAST=? )
-20:22:10,604 INFO [STDOUT] doPostLoad: Loaded Customer: Bill Burke
-20:22:10,604 INFO [STDOUT] doPostLoad: Loaded Customer: Monica Burke
-20:22:10,624 INFO [STDOUT] -- CustomerDAOBean.delete()
-20:22:10,634 INFO [STDOUT] doPreRemove: About to delete Customer: Bill Burke
-20:22:10,644 INFO [STDOUT] doPreRemove: About to delete Customer: Monica Burke
-20:22:10,644 INFO [STDOUT] Hibernate: delete from CUSTOMER where id=?
-20:22:10,644 INFO [STDOUT] doPostRemove: Deleted Customer: Bill Burke
-20:22:10,644 INFO [STDOUT] Hibernate: delete from CUSTOMER where id=?
-20:22:10,644 INFO [STDOUT] doPostRemove: Deleted Customer: Monica Burke
-}}}
-
-Thus you can see how the callbacks on the entity bean wrap the interaction with the database.
Deleted: projects/ejb3/trunk/docs/tutorial/composite/composite.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/composite/composite.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/composite/composite.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,157 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Composite Primary Keys and Primary Key Classes</h2>
-
-The EJB 3.0 specification allows you to define a primary key class as a @Embeddable and use it as the primary key of your Entity bean. One or
-more properties can be used as members of the primary key for that particular table. This tutorial is an adaptation of the
-<i>relationships</i> tutorial. It adds a primary key class to Customer that holds both the <i>name</i> and <i>id</i> of the Customer.
-</p><p>
-<pre>
- at Embeddable
-public class CustomerPK implements java.io.Serializable
-{
- private long id;
- private String name;
-
-
- public CustomerPK()
- {
- }
-
- public CustomerPK(long id, String name)
- {
- this.id = id;
- this.name = name;
- }
-
- public long getId()
- {
- return id;
- }
-
- public void setId(long id)
- {
- this.id = id;
- }
-
- public String getName()
- {
- return name;
- }
-
- public void setName(String name)
- {
- this.name = name;
- }
-
- public int hashCode()
- {
- return (int) id + name.hashCode();
- }
-
- public boolean equals(Object obj)
- {
- if (obj == this) return true;
- if (!(obj instanceof CustomerPK)) return false;
- if (obj == null) return false;
- CustomerPK pk = (CustomerPK) obj;
- return pk.id == id && pk.name.equals(name);
- }
-}
-</pre>
-</p><p>
-<h4>Mapping the primary key class</h4>
-
-Open up <a href="src/org/jboss/tutorial/composite/bean/Customer.java">Customer</a> and look for the <tt>getPk()</tt> method. This
-defines the primary key class.
-</p><p>
-<pre>
- @EmbeddedId
- public CustomerPK getPk()
- {
- return pk;
- }
-</pre>
-</p><p>
-The <a href="src/org/jboss/tutorial/composite/bean/CustomerPK.java">CustomerPK</a> class is mapped to <a href="src/org/jboss/tutorial/composite/bean/Customer.java">Customer</a>
-just like any other embeddable object. The additional <tt>@EmbeddedId</tt> annotation specifies that it will be the primary key.
-NOTE: If you provide a primary key class, JBoss cannot autogenerate the key
-for you. You must allocate a CustomerPK class and instantiate it with your id and name when you create the Customer.
-</p><p>
-</p><p>
-<h4>Many To Many</h4>
-
-There is a mant to many relationship between <a href="src/org/jboss/tutorial/composite/bean/Customer.java">Customer</a> and <a href="src/org/jboss/tutorial/composite/bean/Flight.java">Flight</a>.
- In order to have a many to many relationship there needs to be a distinct join table that maps the many to many relationship. This is called an association table.
- You need to use the <tt>@JoinTable</tt> annotation to define this join table.
- The <tt>@JoinTable</tt> must be defined on both sides of the bi-directional relationship. Let's look at the Customer side of the relationship
-</p><p>
-<pre>
- @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.EAGER, mappedBy="customers")
- @JoinTable(name="flight_customer_table",
- joinColumns={@JoinColumn(name = "FLIGHT_ID")},
- inverseJoinColumns={@JoinColumn(name = "CUSTOMER_ID"), @JoinColumn(name = "CUSTOMER_NAME")})
- public Set<Flight> getFlights()
- {
- return flights;
- }
-</pre>
-</p><p>
-The <tt>mappedBy</tt> attribute specifies which side of the relationship is responsible for managing the relationship. If it is not set, then that side is responsible.
-So, for this example, the <tt>Flight</tt> Entity is responsible for managing the relation.
-In this example, we are specifying multiple <tt>inverseJoinColumns</tt> because Customer has a composite primary key.
-</p><p>
-Let's look at the other side of the relationship in Flight.
-</p><p>
-<pre>
- @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.EAGER)
- @JoinTable(name = "flight_customer_table",
- joinColumns = {@JoinColumn(name = "FLIGHT_ID")},
- inverseJoinColumns = {@JoinColumn(name = "CUSTOMER_ID"), @JoinColumn(name = "CUSTOMER_NAME")})
- public Set<Customer> getCustomers()
- {
- return customers;
- }
-</pre>
-</p><p>
-The <tt>Flight</tt> Entity must also define the <tt>@ManyToMany</tt> and <tt>@JoinTable</tt>.
-</p><p>
-The database associate table will look like this:
-</p><p>
-<pre>
- create table FLIGHT_CUSTOMER_TABLE (
- CUSTOMER_ID integer,
- CUSTOMER_NAME varchar,
- FLIGHT_ID integer
- );
-</pre>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-07 14:39:23,103 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Air France customers
- [java] Bill
- [java] Monica
- [java] USAir customers
- [java] Molly
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>View the tables and rows</h4>
-
-You can view the tables created by JBoss by going to the <a href="http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB">Hypersonic SQL service</a>, scrolling down to the <tt>startDatabaseManager</tt> button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/composite/composite.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/composite/composite.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/composite/composite.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,146 +0,0 @@
-!!!Composite Primary Keys and Primary Key Classes
-The EJB 3.0 specification allows you to define a primary key class as a @Embeddable and use it as the primary key of your Entity bean. One or
-more properties can be used as members of the primary key for that particular table. This tutorial is an adaptation of the
-''relationships'' tutorial. It adds a primary key class to Customer that holds both the ''name'' and ''id'' of the Customer.
-
-{{{
- at Embeddable
-public class CustomerPK implements java.io.Serializable
-{
- private long id;
- private String name;
-
-
- public CustomerPK()
- {
- }
-
- public CustomerPK(long id, String name)
- {
- this.id = id;
- this.name = name;
- }
-
- public long getId()
- {
- return id;
- }
-
- public void setId(long id)
- {
- this.id = id;
- }
-
- public String getName()
- {
- return name;
- }
-
- public void setName(String name)
- {
- this.name = name;
- }
-
- public int hashCode()
- {
- return (int) id + name.hashCode();
- }
-
- public boolean equals(Object obj)
- {
- if (obj == this) return true;
- if (!(obj instanceof CustomerPK)) return false;
- if (obj == null) return false;
- CustomerPK pk = (CustomerPK) obj;
- return pk.id == id && pk.name.equals(name);
- }
-}
-}}}
-
-!Mapping the primary key class
-Open up [Customer|src/org/jboss/tutorial/composite/bean/Customer.java] and look for the {{getPk()}} method. This
-defines the primary key class.
-
-{{{
- @EmbeddedId
- public CustomerPK getPk()
- {
- return pk;
- }
-}}}
-
-The [CustomerPK|src/org/jboss/tutorial/composite/bean/CustomerPK.java] class is mapped to [Customer|src/org/jboss/tutorial/composite/bean/Customer.java]
-just like any other embeddable object. The additional {{@EmbeddedId}} annotation specifies that it will be the primary key.
-NOTE: If you provide a primary key class, JBoss cannot autogenerate the key
-for you. You must allocate a CustomerPK class and instantiate it with your id and name when you create the Customer.
-
-
-!Many To Many
-There is a mant to many relationship between [Customer|src/org/jboss/tutorial/composite/bean/Customer.java] and [Flight|src/org/jboss/tutorial/composite/bean/Flight.java].
- In order to have a many to many relationship there needs to be a distinct join table that maps the many to many relationship. This is called an association table.
- You need to use the {{@JoinTable}} annotation to define this join table.
- The {{@JoinTable}} must be defined on both sides of the bi-directional relationship. Let's look at the Customer side of the relationship
-
-{{{
- @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.EAGER, mappedBy="customers")
- @JoinTable(name="flight_customer_table",
- joinColumns={@JoinColumn(name = "FLIGHT_ID")},
- inverseJoinColumns={@JoinColumn(name = "CUSTOMER_ID"), @JoinColumn(name = "CUSTOMER_NAME")})
- public Set<Flight> getFlights()
- {
- return flights;
- }
-}}}
-
-The {{mappedBy}} attribute specifies which side of the relationship is responsible for managing the relationship. If it is not set, then that side is responsible.
-So, for this example, the {{Flight}} Entity is responsible for managing the relation.
-In this example, we are specifying multiple {{inverseJoinColumns}} because Customer has a composite primary key.
-
-Let's look at the other side of the relationship in Flight.
-
-{{{
- @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.EAGER)
- @JoinTable(name = "flight_customer_table",
- joinColumns = {@JoinColumn(name = "FLIGHT_ID")},
- inverseJoinColumns = {@JoinColumn(name = "CUSTOMER_ID"), @JoinColumn(name = "CUSTOMER_NAME")})
- public Set<Customer> getCustomers()
- {
- return customers;
- }
-}}}
-
-The {{Flight}} Entity must also define the {{@ManyToMany}} and {{@JoinTable}}.
-
-The database associate table will look like this:
-
-{{{
- create table FLIGHT_CUSTOMER_TABLE (
- CUSTOMER_ID integer,
- CUSTOMER_NAME varchar,
- FLIGHT_ID integer
- );
-}}}
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-07 14:39:23,103 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Air France customers
- [java] Bill
- [java] Monica
- [java] USAir customers
- [java] Molly
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!View the tables and rows
-You can view the tables created by JBoss by going to the [Hypersonic SQL service|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB], scrolling down to the {{startDatabaseManager}} button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-
Deleted: projects/ejb3/trunk/docs/tutorial/consumer/consumer.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/consumer/consumer.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/consumer/consumer.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,220 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Message Driven POJOs</h2>
-
-</p><p>
-We are prototyping some possible extensions to MDBs to see if we can make things a little easier for development. The idea is to give a message consumer (an MDB) a typed interface that message producers can send messages through. Both the publisher and subscriber would be typed interfaces.
-</p><p>
-<h3>The model</h3>
-
-Message Driven POJOs will have the same model as Stateless/Stateful beans. There is a bean class tagged as @Consumer that must implement one or more @Producer interfaces. Just as a stateless bean is tagged as @Stateless and implements one or more @Remote or @Local interfaces.
-</p><p>
-It might be best to look at a full example. One is available in our <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/">testsuite</a>
-</p><p>
-<pre>
-package org.jboss.annotation.ejb;
-
- at Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME)
-public @interface Consumer
-{
- String name() default "";
-
- TransactionManagementType transactionManagement() default TransactionManagementType.CONTAINER;
-
- ActivationConfigProperty[] activationConfig() default {};
-}
-</pre>
-</p><p>
- at Consumer looks exactly like @MessageDriven of the EJB3 specification and is configured as such. Place @Consumer on a bean class. That bean class implements interfaces tagged as @Producer.
-</p><p>
-<pre>
-package org.jboss.annotation.Producer;
-
- at Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME)
-public @interface Producer
-{
- String connectionFactory() default "";
- boolean transacted() default false;
- int acknowledgeMode() default 1; // autoacknowledge
-}
-</pre>
-</p><p>
-For each @Producer interface the @Consumer implements, there will be a proxy that implements that @Producer registered in JNDI under the FQN of that @Producer interface.
-</p><p>
-<h3>Simple example</h3>
-
-</p><p>
-Let's do a simple example. First define the consumer:
-</p><p>
-<pre>
-import org.jboss.ejb3.mdb.Consumer;
-
- at Consumer(activationConfig =
- {
- @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
- @ActivationConfigProperty(propertyName="destination", propertyValue="queue/mdbtest")
- })
-public class QueueTestConsumer implements QueueTestRemote
-{
- public void method1(String msg, int num)
- {
- System.out.println("method1(" + msg + ", " + num + ")");
- }
-}
-</pre>
-</p><p>
-QueueTestConsumer is our bean class and defines the methods that can receive JMS messages. You see that it implements one interface, QueueTestRemote.
-</p><p>
-<pre>
-import org.jboss.annotation.ejb.Producer;
-
- at Producer
-public interface QueueTestRemote
-{
- public void method1(String msg, int num);
-}
-</pre>
-</p><p>
-This interface will be used by clients(JMS Publishers) to send messages to the consumer via JMS. Let's now take a look at the client (really the producer of the actual messages).
-</p><p>
-<pre>
-import org.jboss.ejb3.mdb.ProducerObject;
-import org.jboss.ejb3.mdb.ProducerManager;
-
-public static void main(String[] args) throws Exception
-{
- InitialContext ctx = new InitialContext();
- QueueTestRemote tester = (QueueTestRemote)ctx.lookup(QueueTestRemote.class.getName());
-
- ProducerObject po = (ProducerObject)tester;
- ProducerManager manager = po.getProducerManager();
-
- manager.connect(); // internally create a JMS connection
- try
- {
- tester.method1("hello world", 55);
- }
- finally
- {
- manager.close(); // clean up the JMS connection
- }
-}
-</pre>
-</p><p>
-When the @Consumer is deployed by the EJB3 container, it looks for all of its @Producer interfaces and registers each one of them in JNDI under their FQN class name. The client code above looks up the QueueTestRemote interface in JNDI. Each producer implements the <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/main/org/jboss/ejb3/mdb/ProducerObject.java?rev=1.1&view=markup">ProducerObject</a> . The client typecasts the QueueTesterRemote to the ProducerObject. It then gets a <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/main/org/jboss/ejb3/mdb/ProducerManager.java?rev=1.1&view=markup">ProducerManager</a> that manages the JMS connection for this proxy. To start being able to send messages to the Queue, the client calls <tt>connect()</tt> on the manager. It then can successfully call methods on the <tt>tester</tt>. When it calls <tt>method1()</tt> this method call is converted into a JMS message and published to the Queue of th!
e Consumer. The consumer will receive the message and invoke its <tt>method1</tt> method.
-</p><p>
-<h3>@Producer default values</h3>
-
-The proxy registered in JNDI will know how to contact the JMS Queue/Topic to publish messages. You can specify explicitly through the <i>connnectionFactory</i> attribute of the annotation what the JMS ConnectionFactory JNDI name is, or you can rely on defaults.
-</p><p>
-</p><p>
-The default value is "ConnectionFactory" for the ConnectionFactory JNDI name.
-</p><p>
-If you additionally tag the producer as @ProducerLocal instead of @Producer, then "java:/ConnectionFactory" will be used.
-</p><p>
-<h3>@ProducerLocal</h3>
-
-If you tag a producer as @ProducerLocal, the proxy will lookup the connection factory via the default InitialContext when connect() is called. Otherwise, the ConnectFactory reference will be embedded directly within the proxy.
-</p><p>
-<h3>@MessageProperties</h3>
-
-</p><p>
-The methods defined in a Producer are turned into JMS messages. The default message properties are a Time To Live of 0, a Priority of 4, and a delivery mode of PERSISTENT. You can override these default values in a couple of ways.
-</p><p>
-<ul>
-<li> First you can use the @MessageProperties anntotation and tag the Producer class directly to override the values:</li>
-</ul>
-</p><p>
-<pre>
- at Producer
- at MessageProperties(delivery=DeliveryMode.NON_PERSISTENT, timeToLive=1000, priority=1)
-public interface QueueTestRemote
-{
- public void method1(String msg, int num);
-}
-</pre>
-</p><p>
-In this configuration, all method calls on QueueTestRemote will use the JMS message properties defined with the @MessageProperties annotation on the interface.
-</p><p>
-<ul>
-<li> Second, you can specify @MessageProperties on a per method basis.</li>
-</ul>
-<pre>
- at Producer
-public interface QueueTestRemote
-{
- public void method1(String msg, int num);
-
- @MessageProperties(delivery=DeliveryMode.NON_PERSISTENT, timeToLive=1000, priority=1)
- public void method2(String msg, int num);
-}
-</pre>
-</p><p>
-So, in the above example, <tt>method1()</tt> uses the default message properties, and <tt>method2()</tt> overrides the defaults via the @MessageProperties annotation attached to it.
-</p><p>
-<h3> Obtaining the current message</h3>
-
-Sometimes you may need to access the real JMS message. Maybe you need to obtain the replyTo destination or set an acknowledgement or something. You can
-obtain it by using the <tt>@org.jboss.annotation.ejb.CurrentMessage</tt> annotation.
-</p><p>
-<pre>
-
- @CurrentMessage private javax.jms.Message currentMessage;
-
-</pre>
-</p><p>
-This annotation will inject the current JMS message into your Consumer bean before your target method is invoked.
-</p><p>
-<h3>A Full Example</h3>
-
-A full example can be found in our <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/">testsuite</a>. The QueueTestConsumer defines 3 Producers. One is for remote invocations on the Queue <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/QueueTestRemote.java?rev=1.1&view=markup">QueueTestRemote.java</a>, another is for local invocations on the queue <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/QueueTestLocal.java?rev=1.1&view=markup">QueueTestLocal.java</a>, yet another is for using the JCA adapter to send messages transactionally through CMT <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/QueueTestXA.java?rev=1.1&view=markup">QueueTestXA.java</a>
-</p><p>
-The <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/unit/ConsumerUnitTestCase.java?rev=1.1&view=markup">test client</a> sends messages through the QueueTestRemote interface. It interacts with a <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/TestStatusBean.java?rev=1.1&view=markup">stateless bean</a> to test the local and XA producers.
-</p><p>
-</p><p>
-<h3>FEEDBACK NEEDED</h3>
-
-Please provide feedback to this proposed feature on our <a href="http://www.jboss.org/index.html?module=bb&op=viewtopic&t=60294">forum</a>. We would really like feedback on this feature.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-</pre>
-</p><p>
-Look in the console window to determine that the message was sent.
-</p><p>
-<pre>
-12:25:59,734 INFO [Ejb3Module] found EJB3 consumer bean: org.jboss.tutorial.consumer.bean.ExampleConsumerBean
-12:25:59,734 INFO [Ejb3Module] found EJB3 stateless session bean: org.jboss.tutorial.consumer.bean.TesterBean
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerRemote
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerLocal
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerXA
-12:25:59,812 INFO [ProxyDeployer] no declared remote bindings
-12:25:59,812 INFO [ProxyDeployer] there is remote interfaces
-12:25:59,812 INFO [ProxyDeployer] default remote binding has jndiName of org.jboss.tutorial.consumer.bean.Tester
-12:25:59,828 INFO [EJB3Deployer] Deployed: file[the deployment]
-12:26:09,000 INFO [STDOUT] method1(Remote method1 called, 1)
-12:26:09,015 INFO [STDOUT] method2: Remote method2 called
-12:26:09,015 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,015 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,109 INFO [STDOUT] method1(testLocal, 1)
-12:26:09,125 INFO [STDOUT] method2: testLocal2
-12:26:09,125 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,125 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,125 INFO [STDOUT] end TESTXA **
-12:26:09,140 INFO [STDOUT] method2: testXA2
-12:26:09,140 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,140 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,140 INFO [STDOUT] method1(testXA, 1)
-</pre>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/consumer/consumer.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/consumer/consumer.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/consumer/consumer.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,200 +0,0 @@
-!!!Message Driven POJOs
-
-We are prototyping some possible extensions to MDBs to see if we can make things a little easier for development. The idea is to give a message consumer (an MDB) a typed interface that message producers can send messages through. Both the publisher and subscriber would be typed interfaces.
-
-!!The model
-Message Driven POJOs will have the same model as Stateless/Stateful beans. There is a bean class tagged as @Consumer that must implement one or more @Producer interfaces. Just as a stateless bean is tagged as @Stateless and implements one or more @Remote or @Local interfaces.
-
-It might be best to look at a full example. One is available in our [testsuite|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/]
-
-{{{
-package org.jboss.annotation.ejb;
-
- at Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME)
-public @interface Consumer
-{
- String name() default "";
-
- TransactionManagementType transactionManagement() default TransactionManagementType.CONTAINER;
-
- ActivationConfigProperty[] activationConfig() default {};
-}
-}}}
-
- at Consumer looks exactly like @MessageDriven of the EJB3 specification and is configured as such. Place @Consumer on a bean class. That bean class implements interfaces tagged as @Producer.
-
-{{{
-package org.jboss.annotation.Producer;
-
- at Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME)
-public @interface Producer
-{
- String connectionFactory() default "";
- boolean transacted() default false;
- int acknowledgeMode() default 1; // autoacknowledge
-}
-}}}
-
-For each @Producer interface the @Consumer implements, there will be a proxy that implements that @Producer registered in JNDI under the FQN of that @Producer interface.
-
-!!Simple example
-
-Let's do a simple example. First define the consumer:
-
-{{{
-import org.jboss.ejb3.mdb.Consumer;
-
- at Consumer(activationConfig =
- {
- @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
- @ActivationConfigProperty(propertyName="destination", propertyValue="queue/mdbtest")
- })
-public class QueueTestConsumer implements QueueTestRemote
-{
- public void method1(String msg, int num)
- {
- System.out.println("method1(" + msg + ", " + num + ")");
- }
-}
-}}}
-
-QueueTestConsumer is our bean class and defines the methods that can receive JMS messages. You see that it implements one interface, QueueTestRemote.
-
-{{{
-import org.jboss.annotation.ejb.Producer;
-
- at Producer
-public interface QueueTestRemote
-{
- public void method1(String msg, int num);
-}
-}}}
-
-This interface will be used by clients(JMS Publishers) to send messages to the consumer via JMS. Let's now take a look at the client (really the producer of the actual messages).
-
-{{{
-import org.jboss.ejb3.mdb.ProducerObject;
-import org.jboss.ejb3.mdb.ProducerManager;
-
-public static void main(String[] args) throws Exception
-{
- InitialContext ctx = new InitialContext();
- QueueTestRemote tester = (QueueTestRemote)ctx.lookup(QueueTestRemote.class.getName());
-
- ProducerObject po = (ProducerObject)tester;
- ProducerManager manager = po.getProducerManager();
-
- manager.connect(); // internally create a JMS connection
- try
- {
- tester.method1("hello world", 55);
- }
- finally
- {
- manager.close(); // clean up the JMS connection
- }
-}
-}}}
-
-When the @Consumer is deployed by the EJB3 container, it looks for all of its @Producer interfaces and registers each one of them in JNDI under their FQN class name. The client code above looks up the QueueTestRemote interface in JNDI. Each producer implements the [ProducerObject|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/main/org/jboss/ejb3/mdb/ProducerObject.java?rev=1.1&view=markup] . The client typecasts the QueueTesterRemote to the ProducerObject. It then gets a [ProducerManager|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/main/org/jboss/ejb3/mdb/ProducerManager.java?rev=1.1&view=markup] that manages the JMS connection for this proxy. To start being able to send messages to the Queue, the client calls {{connect()}} on the manager. It then can successfully call methods on the {{tester}}. When it calls {{method1()}} this method call is converted into a JMS message and published to the Queue of the Consumer. The consumer will receive !
the message and invoke its {{method1}} method.
-
-!!@Producer default values
-The proxy registered in JNDI will know how to contact the JMS Queue/Topic to publish messages. You can specify explicitly through the ''connnectionFactory'' attribute of the annotation what the JMS ConnectionFactory JNDI name is, or you can rely on defaults.
-
-
-The default value is "ConnectionFactory" for the ConnectionFactory JNDI name.
-
-If you additionally tag the producer as @ProducerLocal instead of @Producer, then "java:/ConnectionFactory" will be used.
-
-!!@ProducerLocal
-If you tag a producer as @ProducerLocal, the proxy will lookup the connection factory via the default InitialContext when connect() is called. Otherwise, the ConnectFactory reference will be embedded directly within the proxy.
-
-!!@MessageProperties
-
-The methods defined in a Producer are turned into JMS messages. The default message properties are a Time To Live of 0, a Priority of 4, and a delivery mode of PERSISTENT. You can override these default values in a couple of ways.
-
-* First you can use the @MessageProperties anntotation and tag the Producer class directly to override the values:
-
-{{{
- at Producer
- at MessageProperties(delivery=DeliveryMode.NON_PERSISTENT, timeToLive=1000, priority=1)
-public interface QueueTestRemote
-{
- public void method1(String msg, int num);
-}
-}}}
-
-In this configuration, all method calls on QueueTestRemote will use the JMS message properties defined with the @MessageProperties annotation on the interface.
-
-* Second, you can specify @MessageProperties on a per method basis.
-{{{
- at Producer
-public interface QueueTestRemote
-{
- public void method1(String msg, int num);
-
- @MessageProperties(delivery=DeliveryMode.NON_PERSISTENT, timeToLive=1000, priority=1)
- public void method2(String msg, int num);
-}
-}}}
-
-So, in the above example, {{method1()}} uses the default message properties, and {{method2()}} overrides the defaults via the @MessageProperties annotation attached to it.
-
-!! Obtaining the current message
-Sometimes you may need to access the real JMS message. Maybe you need to obtain the replyTo destination or set an acknowledgement or something. You can
-obtain it by using the {{@org.jboss.annotation.ejb.CurrentMessage}} annotation.
-
-{{{
-
- @CurrentMessage private javax.jms.Message currentMessage;
-
-}}}
-
-This annotation will inject the current JMS message into your Consumer bean before your target method is invoked.
-
-!!A Full Example
-A full example can be found in our [testsuite|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/]. The QueueTestConsumer defines 3 Producers. One is for remote invocations on the Queue [QueueTestRemote.java|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/QueueTestRemote.java?rev=1.1&view=markup], another is for local invocations on the queue [QueueTestLocal.java|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/QueueTestLocal.java?rev=1.1&view=markup], yet another is for using the JCA adapter to send messages transactionally through CMT [QueueTestXA.java|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/QueueTestXA.java?rev=1.1&view=markup]
-
-The [test client|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/unit/ConsumerUnitTestCase.java?rev=1.1&view=markup] sends messages through the QueueTestRemote interface. It interacts with a [stateless bean|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/test/org/jboss/ejb3/test/consumer/TestStatusBean.java?rev=1.1&view=markup] to test the local and XA producers.
-
-
-!!FEEDBACK NEEDED
-Please provide feedback to this proposed feature on our [forum|http://www.jboss.org/index.html?module=bb&op=viewtopic&t=60294]. We would really like feedback on this feature.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-}}}
-
-Look in the console window to determine that the message was sent.
-
-{{{
-12:25:59,734 INFO [Ejb3Module] found EJB3 consumer bean: org.jboss.tutorial.consumer.bean.ExampleConsumerBean
-12:25:59,734 INFO [Ejb3Module] found EJB3 stateless session bean: org.jboss.tutorial.consumer.bean.TesterBean
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerRemote
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerLocal
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerXA
-12:25:59,812 INFO [ProxyDeployer] no declared remote bindings
-12:25:59,812 INFO [ProxyDeployer] there is remote interfaces
-12:25:59,812 INFO [ProxyDeployer] default remote binding has jndiName of org.jboss.tutorial.consumer.bean.Tester
-12:25:59,828 INFO [EJB3Deployer] Deployed: file[the deployment]
-12:26:09,000 INFO [STDOUT] method1(Remote method1 called, 1)
-12:26:09,015 INFO [STDOUT] method2: Remote method2 called
-12:26:09,015 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,015 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,109 INFO [STDOUT] method1(testLocal, 1)
-12:26:09,125 INFO [STDOUT] method2: testLocal2
-12:26:09,125 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,125 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,125 INFO [STDOUT] end TESTXA **
-12:26:09,140 INFO [STDOUT] method2: testXA2
-12:26:09,140 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,140 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,140 INFO [STDOUT] method1(testXA, 1)
-}}}
-
Deleted: projects/ejb3/trunk/docs/tutorial/consumer_deployment_descriptor/consumer.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/consumer_deployment_descriptor/consumer.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/consumer_deployment_descriptor/consumer.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,123 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Message Driven POJOs via the deployment descriptor</h2>
-
-</p><p>
-We are prototyping some possible extensions to MDBs to see if we can make things a little easier for development. The idea is to give a message consumer (an MDB) a typed interface that message producers can send messages through. Both the publisher and subscriber would be typed interfaces.
-</p><p>
-<h3>The model</h3>
-
-Message Driven POJOs will have the same model as Session beans. A Consumer can be configured via a combination of annotations and via the
-jboss.xml deployment descriptor. This tutorial describes configuration via a deployment descriptor. Take a look at <a href="META-INF/jboss.xml">jboss.xml</a>.
-There is a bean class tagged as <tt>consumer</tt> that must implement one or more Producer interfaces. Note the <tt>producer</tt> and <tt>local-producer</tt> tags.
-Just as a session bean is tagged as <tt>session</tt> and implements one or more <tt>remote</tt> or <tt>local</tt> interfaces.
-</p><p>
-It might be best to look at a full example.
-</p><p>
-For each <tt>producer</tt> interface the Consumer implements, there will be a proxy that implements that Producer interface registered in JNDI under the FQN of
- that Producer interface.
-</p><p>
-<h3>Simple example</h3>
-
-</p><p>
-Let's do a simple example. First define the consumer. Take a look at <a href="src/org/jboss/tutorial/consumer_deployment_descriptor/bean/ExampleConsumerBean.java">ExampleConsumerBean.java</a>.
-This is our bean class and defines the methods than can receive JMS messages. The bean class implements three interfaces which are configured as Producers in <tt>jboss.xml</tt>. These interfaces
-will be used by clients (JMS publishers) to send messages to the Consumer via JMS.Note that <a href="src/org/jboss/tutorial/consumer_deployment_descriptor/bean/ExampleProducerXA.java">ExampleProducerXA.java</a>
-is tagged with <tt>connection-factory</tt> to indicate the jndi name of the XA transaction factory.
-</p><p>
-<h3>The client</h3>
-
-</p><p>
-Let's now take a look at the client (really the producer of the actual messages) <a href="src/org/jboss/tutorial/consumer_deployment_descriptor/client/Client.java">Client.java</a>
-</p><p>
-When the Consumer is deployed by the EJB3 container, it looks for all of its Producer interfaces and registers each one of them in JNDI under their FQN class name. The client code above looks
-up the <a href="src/org/jboss/tutorial/consumer_deployment_descriptor/bean/ExampleProducerRemote.java">ExampleProducerRemote.java</a> interface in JNDI and accesses the local interfaces (
-<a href="src/org/jboss/tutorial/consumer_deployment_descriptor/bean/ExampleProducerLocal.java">ExampleProducerLocal.java</a>,
-<a href="src/org/jboss/tutorial/consumer_deployment_descriptor/bean/ExampleProducerXA.java">ExampleProducerXA.java</a>) through the Stateless Session bean
-<a href="src/org/jboss/tutorial/consumer_deployment_descriptor/bean/TesterBean.java"">TesterBean.java</a>.
-Each producer implements the <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/main/org/jboss/ejb3/mdb/ProducerObject.java?rev=1.1&view=markup">ProducerObject</a>.
-The client typecasts the <tt>ExampleProducerRemote</tt> to the ProducerObject.
-It then gets a <a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/main/org/jboss/ejb3/mdb/ProducerManager.java?rev=1.1&view=markup">ProducerManager</a> that manages the
-JMS connection for this proxy. To start being able to send messages to the Queue, the client calls <tt>connect()</tt> on the manager.
-It then can successfully call methods on the remote Producer. When it calls <tt>method1()</tt> this method call is converted into a JMS message and published to the Queue of the Consumer.
-The consumer will receive the message and invoke its <tt>method1</tt> method.
-</p><p>
-<h3>Producer default values</h3>
-
-</p><p>
-The proxy registered in JNDI will know how to contact the JMS Queue/Topic to publish messages. You can specify explicitly through the <tt>connnection-factory</tt> tag what the JMS
-ConnectionFactory JNDI name is, or you can rely on defaults.
-</p><p>
-The default value is "ConnectionFactory" for the ConnectionFactory JNDI name.
-</p><p>
-If you additionally tag the producer as <tt>local-producer</tt> instead of <tt>producer</tt>, then "java:/ConnectionFactory" will be used.
-</p><p>
-<h3>local-producer</h3>
-
-</p><p>
-If you tag a producer as <tt>local-producer</tt>, the proxy will lookup the connection factory via the default InitialContext when connect() is called. Otherwise, the ConnectFactory
-reference will be embedded directly within the proxy.
-</p><p>
-<h3>message-properties</h3>
-
-</p><p>
-The methods defined in a Producer are turned into JMS messages. The default message properties are a Time To Live of 0, a Priority of 4, and a delivery mode of PERSISTENT. You can override
-these default values using the <tt>message-properties</tt> tag. This tag can be specified per method or wildcarded for all methods in the Producer interface.
-</p><p>
-So, in the above example, <tt>method1()</tt> uses the default message properties, and <tt>method2()</tt> overrides the defaults via the <tt>message-properties</tt> tag.
-</p><p>
-<h3>Obtaining the current message</h3>
-
-</p><p>
-Sometimes you may need to access the real JMS message. Maybe you need to obtain the replyTo destination or set an acknowledgement or something. You can
-obtain it by using the <tt>current-message</tt> tag.
-</p><p>
-This tag will inject the current JMS message into your Consumer bean before your target method is invoked.
-</p><p>
-<h3>FEEDBACK NEEDED</h3>
-
-</p><p>
-Please provide feedback to this proposed feature on our <a href="http://www.jboss.org/index.html?module=bb&op=viewtopic&t=60294">forum</a>. We would really like feedback on this feature.
-</p><p>
-<h3>Building and Running</h3>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-</pre>
-</p><p>
-Look in the console window to determine that the message was sent.
-</p><p>
-<pre>
-12:25:59,734 INFO [Ejb3Module] found EJB3 consumer bean: org.jboss.tutorial.consumer.bean.ExampleConsumerBean
-12:25:59,734 INFO [Ejb3Module] found EJB3 stateless session bean: org.jboss.tutorial.consumer.bean.TesterBean
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerRemote
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerLocal
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerXA
-12:25:59,812 INFO [ProxyDeployer] no declared remote bindings
-12:25:59,812 INFO [ProxyDeployer] there is remote interfaces
-12:25:59,812 INFO [ProxyDeployer] default remote binding has jndiName of org.jboss.tutorial.consumer.bean.Tester
-12:25:59,828 INFO [EJB3Deployer] Deployed: file[the deployment]
-12:26:09,000 INFO [STDOUT] method1(Remote method1 called, 1)
-12:26:09,015 INFO [STDOUT] method2: Remote method2 called
-12:26:09,015 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,015 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,109 INFO [STDOUT] method1(testLocal, 1)
-12:26:09,125 INFO [STDOUT] method2: testLocal2
-12:26:09,125 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,125 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,125 INFO [STDOUT] end TESTXA **
-12:26:09,140 INFO [STDOUT] method2: testXA2
-12:26:09,140 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,140 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,140 INFO [STDOUT] method1(testXA, 1)
-</pre>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/consumer_deployment_descriptor/consumer.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/consumer_deployment_descriptor/consumer.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/consumer_deployment_descriptor/consumer.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,107 +0,0 @@
-!!!Message Driven POJOs via the deployment descriptor
-
-We are prototyping some possible extensions to MDBs to see if we can make things a little easier for development. The idea is to give a message consumer (an MDB) a typed interface that message producers can send messages through. Both the publisher and subscriber would be typed interfaces.
-
-!!The model
-Message Driven POJOs will have the same model as Session beans. A Consumer can be configured via a combination of annotations and via the
-jboss.xml deployment descriptor. This tutorial describes configuration via a deployment descriptor. Take a look at [jboss.xml|META-INF/jboss.xml].
-There is a bean class tagged as {{consumer}} that must implement one or more Producer interfaces. Note the {{producer}} and {{local-producer}} tags.
-Just as a session bean is tagged as {{session}} and implements one or more {{remote}} or {{local}} interfaces.
-
-It might be best to look at a full example.
-
-For each {{producer}} interface the Consumer implements, there will be a proxy that implements that Producer interface registered in JNDI under the FQN of
- that Producer interface.
-
-!!Simple example
-
-Let's do a simple example. First define the consumer. Take a look at [ExampleConsumerBean.java|src/org/jboss/tutorial/consumer_deployment_descriptor/bean/ExampleConsumerBean.java].
-This is our bean class and defines the methods than can receive JMS messages. The bean class implements three interfaces which are configured as Producers in {{jboss.xml}}. These interfaces
-will be used by clients (JMS publishers) to send messages to the Consumer via JMS.Note that [ExampleProducerXA.java|src/org/jboss/tutorial/consumer_deployment_descriptor/bean/ExampleProducerXA.java]
-is tagged with {{connection-factory}} to indicate the jndi name of the XA transaction factory.
-
-!!The client
-
-Let's now take a look at the client (really the producer of the actual messages) [Client.java|src/org/jboss/tutorial/consumer_deployment_descriptor/client/Client.java]
-
-When the Consumer is deployed by the EJB3 container, it looks for all of its Producer interfaces and registers each one of them in JNDI under their FQN class name. The client code above looks
-up the [ExampleProducerRemote.java|src/org/jboss/tutorial/consumer_deployment_descriptor/bean/ExampleProducerRemote.java] interface in JNDI and accesses the local interfaces (
-[ExampleProducerLocal.java|src/org/jboss/tutorial/consumer_deployment_descriptor/bean/ExampleProducerLocal.java],
-[ExampleProducerXA.java|src/org/jboss/tutorial/consumer_deployment_descriptor/bean/ExampleProducerXA.java]) through the Stateless Session bean
-[TesterBean.java|src/org/jboss/tutorial/consumer_deployment_descriptor/bean/TesterBean.java"].
-Each producer implements the [ProducerObject|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/main/org/jboss/ejb3/mdb/ProducerObject.java?rev=1.1&view=markup].
-The client typecasts the {{ExampleProducerRemote}} to the ProducerObject.
-It then gets a [ProducerManager|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/main/org/jboss/ejb3/mdb/ProducerManager.java?rev=1.1&view=markup] that manages the
-JMS connection for this proxy. To start being able to send messages to the Queue, the client calls {{connect()}} on the manager.
-It then can successfully call methods on the remote Producer. When it calls {{method1()}} this method call is converted into a JMS message and published to the Queue of the Consumer.
-The consumer will receive the message and invoke its {{method1}} method.
-
-!!Producer default values
-
-The proxy registered in JNDI will know how to contact the JMS Queue/Topic to publish messages. You can specify explicitly through the {{connnection-factory}} tag what the JMS
-ConnectionFactory JNDI name is, or you can rely on defaults.
-
-The default value is "ConnectionFactory" for the ConnectionFactory JNDI name.
-
-If you additionally tag the producer as {{local-producer}} instead of {{producer}}, then "java:/ConnectionFactory" will be used.
-
-!!local-producer
-
-If you tag a producer as {{local-producer}}, the proxy will lookup the connection factory via the default InitialContext when connect() is called. Otherwise, the ConnectFactory
-reference will be embedded directly within the proxy.
-
-!!message-properties
-
-The methods defined in a Producer are turned into JMS messages. The default message properties are a Time To Live of 0, a Priority of 4, and a delivery mode of PERSISTENT. You can override
-these default values using the {{message-properties}} tag. This tag can be specified per method or wildcarded for all methods in the Producer interface.
-
-So, in the above example, {{method1()}} uses the default message properties, and {{method2()}} overrides the defaults via the {{message-properties}} tag.
-
-!!Obtaining the current message
-
-Sometimes you may need to access the real JMS message. Maybe you need to obtain the replyTo destination or set an acknowledgement or something. You can
-obtain it by using the {{current-message}} tag.
-
-This tag will inject the current JMS message into your Consumer bean before your target method is invoked.
-
-!!FEEDBACK NEEDED
-
-Please provide feedback to this proposed feature on our [forum|http://www.jboss.org/index.html?module=bb&op=viewtopic&t=60294]. We would really like feedback on this feature.
-
-!!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-}}}
-
-Look in the console window to determine that the message was sent.
-
-{{{
-12:25:59,734 INFO [Ejb3Module] found EJB3 consumer bean: org.jboss.tutorial.consumer.bean.ExampleConsumerBean
-12:25:59,734 INFO [Ejb3Module] found EJB3 stateless session bean: org.jboss.tutorial.consumer.bean.TesterBean
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerRemote
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerLocal
-12:25:59,796 INFO [ConsumerContainer] Producer: org.jboss.tutorial.consumer.bean.ExampleProducerXA
-12:25:59,812 INFO [ProxyDeployer] no declared remote bindings
-12:25:59,812 INFO [ProxyDeployer] there is remote interfaces
-12:25:59,812 INFO [ProxyDeployer] default remote binding has jndiName of org.jboss.tutorial.consumer.bean.Tester
-12:25:59,828 INFO [EJB3Deployer] Deployed: file[the deployment]
-12:26:09,000 INFO [STDOUT] method1(Remote method1 called, 1)
-12:26:09,015 INFO [STDOUT] method2: Remote method2 called
-12:26:09,015 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,015 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,109 INFO [STDOUT] method1(testLocal, 1)
-12:26:09,125 INFO [STDOUT] method2: testLocal2
-12:26:09,125 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,125 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,125 INFO [STDOUT] end TESTXA **
-12:26:09,140 INFO [STDOUT] method2: testXA2
-12:26:09,140 INFO [STDOUT] method2 key/val: great:ejb3
-12:26:09,140 INFO [STDOUT] method2 key/val: hello:world
-12:26:09,140 INFO [STDOUT] method1(testXA, 1)
-}}}
-
Deleted: projects/ejb3/trunk/docs/tutorial/ejb21_client_adaptors/ejb21_client_adaptors.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/ejb21_client_adaptors/ejb21_client_adaptors.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/ejb21_client_adaptors/ejb21_client_adaptors.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,51 +0,0 @@
-<html>
-<body>
-<p>
-<h2>EJB 2.1 Client Adaptors</h2>
-
-EJB 3.0 is backward compatible to EJB 2.x clients and supports the use of local and remote home interfaces as well as
-initialization methods (e.g. ejbCreate()). This capability is configured through annotations and/or through deployment
-descriptors. Take a look at <a href="src/org/jboss/tutorial/ejb21_client_adaptors/bean/Session1Bean.java">Session1Bean.java</a>. Note
-that the class is annotated with <tt>@RemoteHome</tt> and the ejbCreate() method is annotated with <tt>@Init</tt>. The former
-annotation indicates that the bean provides a EJB 2.1 style home interface. The latter annotation indicates that when the create()
-method is invoked from the home interface, the bean is initialized via the ejbCreate method. Note that the initializion method name
-is not restricted to ejbCreate().
-</p><p>
-<a href="src/org/jboss/tutorial/ejb21_client_adaptors/bean/Session2Bean.java">Session2Bean.java</a> illustrates the use of a
-local home interface.
-</p><p>
-Similiarly, <a href="src/org/jboss/tutorial/ejb21_client_adaptors/bean/DeploymentDescriptorSession1Bean.java">DeploymentDescriptorSession1Bean.java</a> and
-<a href="src/org/jboss/tutorial/ejb21_client_adaptors/bean/DeploymentDescriptorSession2Bean.java">DeploymentDescriptorSession2Bean.java</a>
-mimic the behavior of the first two beans, but use deployment descriptors to indicate the home interface(s) and initialization method(s).
-</p><p>
-Take a look at <a href="META-INF/ejb-jar.xml">ejb-jar.xml</a>. Note the "home" and "local-home" tags that indicate the respective home interfaces.
-Also, note the "init-list" tag that indicates the initialization method(s) executed when beans are created via the home interface(s).
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Session1 init value is initialized
- [java] Session2 init value is initialized
- [java] DeploymentDescriptor Session1 init value is initialized
- [java] DeploymentDescriptor Session2 init value is initialized
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the CalculatorBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/ejb21_client_adaptors/ejb21_client_adaptors.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/ejb21_client_adaptors/ejb21_client_adaptors.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/ejb21_client_adaptors/ejb21_client_adaptors.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,42 +0,0 @@
-!!!EJB 2.1 Client Adaptors
-EJB 3.0 is backward compatible to EJB 2.x clients and supports the use of local and remote home interfaces as well as
-initialization methods (e.g. ejbCreate()). This capability is configured through annotations and/or through deployment
-descriptors. Take a look at [Session1Bean.java|src/org/jboss/tutorial/ejb21_client_adaptors/bean/Session1Bean.java]. Note
-that the class is annotated with {{@RemoteHome}} and the ejbCreate() method is annotated with {{@Init}}. The former
-annotation indicates that the bean provides a EJB 2.1 style home interface. The latter annotation indicates that when the create()
-method is invoked from the home interface, the bean is initialized via the ejbCreate method. Note that the initializion method name
-is not restricted to ejbCreate().
-
-[Session2Bean.java|src/org/jboss/tutorial/ejb21_client_adaptors/bean/Session2Bean.java] illustrates the use of a
-local home interface.
-
-Similiarly, [DeploymentDescriptorSession1Bean.java|src/org/jboss/tutorial/ejb21_client_adaptors/bean/DeploymentDescriptorSession1Bean.java] and
-[DeploymentDescriptorSession2Bean.java|src/org/jboss/tutorial/ejb21_client_adaptors/bean/DeploymentDescriptorSession2Bean.java]
-mimic the behavior of the first two beans, but use deployment descriptors to indicate the home interface(s) and initialization method(s).
-
-Take a look at [ejb-jar.xml|META-INF/ejb-jar.xml]. Note the "home" and "local-home" tags that indicate the respective home interfaces.
-Also, note the "init-list" tag that indicates the initialization method(s) executed when beans are created via the home interface(s).
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Session1 init value is initialized
- [java] Session2 init value is initialized
- [java] DeploymentDescriptor Session1 init value is initialized
- [java] DeploymentDescriptor Session2 init value is initialized
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the CalculatorBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/embeddable/dependent.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/embeddable/dependent.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/embeddable/dependent.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,69 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Embeddable Objects</h2>
-
-The EJB specification allows you to embed plain Java objects within your entity beans and map the properties of this embedded value object to columns within the entity's table.
-</p><p>
-The <a href="src/org/jboss/tutorial/dependent/bean/Customer.java">Customer</a> bean encapsulates the name of the customer in the <a href="src/org/jboss/tutorial/dependent/bean/Name.java">Name</a> value object.
-</p><p>
-The <a href="src/org/jboss/tutorial/dependent/bean/Name.java">Name</a> value object must be tagged with the <tt>@Embeddable</tt> annotation.
-</p><p>
-<pre>
- at Embeddable
-public class Name implements java.io.Serializable
-{
-}}
-</pre>
-</p><p>
-The properties of Name must then be mapped to columns within Customer's table.
-</p><p>
-<pre>
- @Embedded
- @AttributeOverrides({
- @AttributeOverride(name = "first", column = {@Column(name = "FIRST_NAME")}),
- @AttributeOverride(name = "last", column = {@Column(name = "LAST_NAME")})
- })
- public Name getName()
- {
- return name;
- }
-</pre>
-</p><p>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Create Bill Burke and Monica Smith
- [java] 2004-10-06 22:27:50,344 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Bill and Monica get married
- [java] Get all the Burkes
- [java] There are now 2 Burkes
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>View the tables and rows</h4>
-
-You can view the tables created by JBoss by going to the <a href="http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB">Hypersonic SQL service</a>, scrolling down to the <tt>startDatabaseManager</tt> button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/embeddable/dependent.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/embeddable/dependent.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/embeddable/dependent.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,59 +0,0 @@
-!!!Embeddable Objects
-The EJB specification allows you to embed plain Java objects within your entity beans and map the properties of this embedded value object to columns within the entity's table.
-
-The [Customer|src/org/jboss/tutorial/dependent/bean/Customer.java] bean encapsulates the name of the customer in the [Name|src/org/jboss/tutorial/dependent/bean/Name.java] value object.
-
-The [Name|src/org/jboss/tutorial/dependent/bean/Name.java] value object must be tagged with the {{@Embeddable}} annotation.
-
-{{{
- at Embeddable
-public class Name implements java.io.Serializable
-{
-}}
-}}}
-
-The properties of Name must then be mapped to columns within Customer's table.
-
-{{{
- @Embedded
- @AttributeOverrides({
- @AttributeOverride(name = "first", column = {@Column(name = "FIRST_NAME")}),
- @AttributeOverride(name = "last", column = {@Column(name = "LAST_NAME")})
- })
- public Name getName()
- {
- return name;
- }
-}}}
-
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Create Bill Burke and Monica Smith
- [java] 2004-10-06 22:27:50,344 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Bill and Monica get married
- [java] Get all the Burkes
- [java] There are now 2 Burkes
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!View the tables and rows
-You can view the tables created by JBoss by going to the [Hypersonic SQL service|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB], scrolling down to the {{startDatabaseManager}} button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-
-
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/entity/entity.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/entity/entity.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/entity/entity.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,124 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Entity Beans</h2>
-
-Entity Beans have been given a complete overhaul in EJB 3.0. Entity beans are plain Java objects that can be allocated with <tt>new</tt> and attached/detached/reattached to persistence storage. Entity beans are not remotable and must be access through the new <tt>javax.persistence.EntityManager</tt> service. JBoss's EJB 3.0 implementation is built on top of Hibernate.
-</p><p>
-<h4>O/R Mapping</h4>
-
-First let's look at the example implementation of two related Entity beans. <a href="src/org/jboss/tutorial/entity/bean/Order.java">Order</a> and <a href="src/org/jboss/tutorial/entity/bean/LineItem.java">LineItem</a>. These two beans form a one to many relationship and automatic table generation is used to generate the database tables.
-</p><p>
-The EJB container determines the persistent properties by looking for all getter/setter method pairs. By default, all getter/setter methods will be treated as persistence properties.
-</p><p>
-Defining an Entity is easy. First, tag the class as an <tt>@Entity</tt>. In the minimum, you must at least define a primary key field using the <tt>@Id</tt> annotation.
-</p><p>
-<pre>
- @Id @GeneratedValue
- public int getId()
- {
- return id;
- }
-</pre>
-</p><p>
-Annotations must be defined on the getter method. The above <tt>@Id</tt> annotation tells the container that <tt>id</tt> is the primary key property. The <tt>@GeneratedValue</tt>: that it should be automatically generated by the container.
-</p><p>
-Also, the create table name is specified using the <tt>@Table</tt> annotation
-</p><p>
-<pre>
- at Table(name = "PURCHASE_ORDER")
-</pre>
-</p><p>
-If the table name isn't specified it defaults to the bean name of the class. For instance, the LineItem EJB would be mapped to the LINEITEM table.
-</p><p>
-<h4>One to Many Relationship</h4>
-
-The Order bean also defines a one to many relationship.
-</p><p>
-<pre>
- @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy="order")
- public Collection<LineItem> getLineItems()
- {
- return lineItems;
- }
-</pre>
-</p><p>
-Generics must be used so that the container can determine the bean order is related to.
-</p><p>
-<tt>CascadeType.ALL</tt> specifies that when an Order is created, any LineItems held in the <tt>lineItems</tt> collection will be created as well (<tt>CascadeType.PERSIST</tt>). If the Order is delete from persistence storage, all related LineItems will be deleted (<tt>CascadeType.REMOVE</tt>). If an Order instance is reattached to persistence storage, any changes to the LineItems collection will be merged with persistence storage (<tt>CascadeType.MERGE</tt>).
-</p><p>
-<tt>FetchType.EAGER</tt> specifies that when the Order is loaded whether or not to prefetch the relationship as well. If you want the LineItems to be loaded on demand, then specify <tt>FetchType.LAZY</tt>.
-</p><p>
-The <tt>mappedBy</tt> attribute specifies that this is a bi-directional relationship that is managed by the order property
-on the LineItem entity bean.
-</p><p>
-<h4>Many to One Relationship</h4>
-
-LineItem completes the bi-directional between Order and LineItem.
-</p><p>
-<pre>
- @ManyToOne
- @JoinColumn(name = "order_id")
- public Order getOrder()
- {
- return order;
- }
-</pre>
-</p><p>
-The <tt>@JoinColumn</tt> specifies the foreign key column within the LineItem table.
-</p><p>
-<h4>EntityManager</h4>
-
-The <a href="src/org/jboss/tutorial/entity/bean/ShoppingCartBean.java">ShoppingCartBean</a> allocates and stores all instances of Orders and LineItems. If you look at the example you can see that ShoppingCart interacts with Order as a plain Java object. It allocates it with <tt>new</tt>. It can pass the Order back to the client. The <tt>checkout()</tt> method actually stores it with persistence storage by using the required EntityManager service.
-</p><p>
-The EntityManager service is injected using field injection and the <tt>@PersistenceContext</tt> annotation.
-</p><p>
-<pre>
- @PersistenceContext
- private EntityManager manager;
-</pre>
-</p><p>
-The EntityManager is central to EJB 3.0 as there are no homes. The EntityManager is used to do querying, creating, find by primary key, and removal of entity beans.
-</p><p>
-</p><p>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Buying 2 memory sticks
- [java] 2004-10-06 22:12:44,131 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Buying a laptop
- [java] Print cart:
- [java] Total: $3000.0
- [java] 2 Memory stick 1000.0
- [java] 1 Laptop 2000.0
- [java] Checkout
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>View the tables and rows</h4>
-
-You can view the tables created by JBoss by going to the <a href="http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB">Hypersonic SQL service</a>, scrolling down to the <tt>startDatabaseManager</tt> button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-</p><p>
-<h4>Jar structure</h4>
-
-Persistence archives must have a META-INF/persistence.xml file. They can be packaged along with EJB-JARs or by themselves in an EAR. They can also be packaged in a WAR as well, but JBoss doesn't support his yet.
-See the packaging tutorial for more detail. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/entity/entity.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/entity/entity.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/entity/entity.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,110 +0,0 @@
-!!!Entity Beans
-Entity Beans have been given a complete overhaul in EJB 3.0. Entity beans are plain Java objects that can be allocated with {{new}} and attached/detached/reattached to persistence storage. Entity beans are not remotable and must be access through the new {{javax.persistence.EntityManager}} service. JBoss's EJB 3.0 implementation is built on top of Hibernate.
-
-!O/R Mapping
-First let's look at the example implementation of two related Entity beans. [Order|src/org/jboss/tutorial/entity/bean/Order.java] and [LineItem|src/org/jboss/tutorial/entity/bean/LineItem.java]. These two beans form a one to many relationship and automatic table generation is used to generate the database tables.
-
-The EJB container determines the persistent properties by looking for all getter/setter method pairs. By default, all getter/setter methods will be treated as persistence properties.
-
-Defining an Entity is easy. First, tag the class as an {{@Entity}}. In the minimum, you must at least define a primary key field using the {{@Id}} annotation.
-
-{{{
- @Id @GeneratedValue
- public int getId()
- {
- return id;
- }
-}}}
-
-Annotations must be defined on the getter method. The above {{@Id}} annotation tells the container that {{id}} is the primary key property. The {{@GeneratedValue}}: that it should be automatically generated by the container.
-
-Also, the create table name is specified using the {{@Table}} annotation
-
-{{{
- at Table(name = "PURCHASE_ORDER")
-}}}
-
-If the table name isn't specified it defaults to the bean name of the class. For instance, the LineItem EJB would be mapped to the LINEITEM table.
-
-!One to Many Relationship
-The Order bean also defines a one to many relationship.
-
-{{{
- @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy="order")
- public Collection<LineItem> getLineItems()
- {
- return lineItems;
- }
-}}}
-
-Generics must be used so that the container can determine the bean order is related to.
-
-{{CascadeType.ALL}} specifies that when an Order is created, any LineItems held in the {{lineItems}} collection will be created as well ({{CascadeType.PERSIST}}). If the Order is delete from persistence storage, all related LineItems will be deleted ({{CascadeType.REMOVE}}). If an Order instance is reattached to persistence storage, any changes to the LineItems collection will be merged with persistence storage ({{CascadeType.MERGE}}).
-
-{{FetchType.EAGER}} specifies that when the Order is loaded whether or not to prefetch the relationship as well. If you want the LineItems to be loaded on demand, then specify {{FetchType.LAZY}}.
-
-The {{mappedBy}} attribute specifies that this is a bi-directional relationship that is managed by the order property
-on the LineItem entity bean.
-
-!Many to One Relationship
-LineItem completes the bi-directional between Order and LineItem.
-
-{{{
- @ManyToOne
- @JoinColumn(name = "order_id")
- public Order getOrder()
- {
- return order;
- }
-}}}
-
-The {{@JoinColumn}} specifies the foreign key column within the LineItem table.
-
-!EntityManager
-The [ShoppingCartBean|src/org/jboss/tutorial/entity/bean/ShoppingCartBean.java] allocates and stores all instances of Orders and LineItems. If you look at the example you can see that ShoppingCart interacts with Order as a plain Java object. It allocates it with {{new}}. It can pass the Order back to the client. The {{checkout()}} method actually stores it with persistence storage by using the required EntityManager service.
-
-The EntityManager service is injected using field injection and the {{@PersistenceContext}} annotation.
-
-{{{
- @PersistenceContext
- private EntityManager manager;
-}}}
-
-The EntityManager is central to EJB 3.0 as there are no homes. The EntityManager is used to do querying, creating, find by primary key, and removal of entity beans.
-
-
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Buying 2 memory sticks
- [java] 2004-10-06 22:12:44,131 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Buying a laptop
- [java] Print cart:
- [java] Total: $3000.0
- [java] 2 Memory stick 1000.0
- [java] 1 Laptop 2000.0
- [java] Checkout
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!View the tables and rows
-You can view the tables created by JBoss by going to the [Hypersonic SQL service|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB], scrolling down to the {{startDatabaseManager}} button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-
-!Jar structure
-Persistence archives must have a META-INF/persistence.xml file. They can be packaged along with EJB-JARs or by themselves in an EAR. They can also be packaged in a WAR as well, but JBoss doesn't support his yet.
-See the packaging tutorial for more detail. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-
-
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/extended_pc/extended.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/extended_pc/extended.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/extended_pc/extended.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,131 +0,0 @@
-<html>
-<body>
-<p>
-<h2> Extended Persistence Contexts</h2>
-
-</p><p>
-Usually, an EntityManager in JBoss EJB 3.0 lives and dies within a JTA transaction. Once the transaction is finished,
-all persistent objects are detached from the EntityManager and are no longer managed.
-Any local caching the EntityManager instance had done is lost. JBoss EJB 3.0 allows you to define long-living EntityManagers
-that live beyond the scope of a JTA transaction. This is called an Extended Persistence Context.
-</p><p>
-When you specify that an injected EntityManager is an extended persistence context, all object instances remain managed.
-Extended persistence contexts can only be used within Stateful session beans. Take a look at <a href="src/org/jboss/tutorial/extended/bean/ShoppingCartBean.java">ShoppingCartBean</a>.
-</p><p>
-<pre>
- at Stateful
- at Remote(ShoppingCart.class)
-public class ShoppingCartBean implements ShoppingCart
-{
- @PersistenceContext(type=PersistenceContextType.EXTENDED) EntityManager em;
-
- @EJB StatelessLocal stateless;
-
- private Customer customer;
-
- public long createCustomer()
- {
- customer = new Customer();
- customer.setName("William");
- em.persist(customer);
- return customer.getId();
- }
-
- public void update()
- {
- customer.setName("Bill");
- }
-...
-}
-</pre>
-</p><p>
-To inject an extended persistence context, you use the <tt>type()</tt> attribute and set it to <tt>EXTENDED</tt>. If you look at
-the <tt>createCustomer()</tt> method you notice that it is persisting a <tt>Customer</tt> object and storing a reference to that
-create object within a member variable of the stateful bean. When the update() method is called, you see that the customer's
-state is modified. Since the entity manager used is EXTENDED, the customer member variable remains managed by the entity
-manager and the modified state will be synchronized with the database.
-</p><p>
-<h4>Converations</h4>
-
-</p><p>
-An even more interesting use case is when you combine extended persistence contexts with non-transactional methods.
-If you interact with an extended persistence context outside of a transaction, the inserts, updates, and deletes
-will be queued until you access the persistence context within a transaction. This means that any persist(), merge(), or remove() method you call will not
-actually result in a JDBC execution and thus an update of the database until you manually call EntityManager.flush().
-</p><p>
-Why is this useful? Consider the usecase of a Setup Wizard on a website. The Wizard has seven steps, seven web pages to enter
-stuff in. It is extremely unwise to have a JTA transaction that spans multiple http requests, yet you do not want to commit
-anything to the database until all steps are complete. Your code can interact with the EntityManager as it wants and you
-do not have to worry about updates or writing a lot of gluecode in your application to do all the entity manager's work in the
-final step of the wizard. Efficient and highly performant. Because the managed persistent objects remain attached to the persistent context,
-all optmistic versioning checks can also be maintained within the application transaction. here's an example on how to do this.
-</p><p>
-<pre>
- at Stateful
- at Remote(ShoppingCart.class)
-public class ShoppingCartBean implements ShoppingCart
-{
- @PersistenceContext(type=PersistenceContextType.EXTENDED) EntityManager em;
-
- @EJB StatelessLocal stateless;
-
- private Customer customer;
-
- public long createCustomer()
- {
- customer = new Customer();
- customer.setName("William");
- em.persist(customer);
- return customer.getId();
- }
-
- @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
- public void never()
- {
- customer.setName("Bob");
- }
-
-
-
- @Remove
- public void checkout()
- {
- }
-}
-</pre>
-</p><p>
-Calling the never() method will update the managed customer object reference, but will not result in a database update until
-checkout() is called. The spec requires that any time you invoke a transactional method of a stateful bean,
-that the EntityManager join the transaction. Therefore, our never() update will be committed at the end of the checkout() method.
-</p><p>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-Buildfile: build.xml
-
-prepare:
-
-compile:
-
-ejbjar:
-
-run:
- [java] Created customer: William
- [java] Customer's name should still be William as pc was not yet flushed: Customer.getName() == William
- [java] Now that the pc has been flushed name should be 'Bob': Customer.getName() == Bob
- [java] Created customer: William
- [java] ShoppingCartBean.customer should stay managed because we're in an extended PC: Customer.getName() == Bill
- [java] Extended persistence contexts are propagated to nested EJB calls: Customer.getName() == Bill Jr.
-
-</pre>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/extended_pc/extended.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/extended_pc/extended.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/extended_pc/extended.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,122 +0,0 @@
-!!! Extended Persistence Contexts
-
-Usually, an EntityManager in JBoss EJB 3.0 lives and dies within a JTA transaction. Once the transaction is finished,
-all persistent objects are detached from the EntityManager and are no longer managed.
-Any local caching the EntityManager instance had done is lost. JBoss EJB 3.0 allows you to define long-living EntityManagers
-that live beyond the scope of a JTA transaction. This is called an Extended Persistence Context.
-
-When you specify that an injected EntityManager is an extended persistence context, all object instances remain managed.
-Extended persistence contexts can only be used within Stateful session beans. Take a look at [ShoppingCartBean|src/org/jboss/tutorial/extended/bean/ShoppingCartBean.java].
-
-{{{
- at Stateful
- at Remote(ShoppingCart.class)
-public class ShoppingCartBean implements ShoppingCart
-{
- @PersistenceContext(type=PersistenceContextType.EXTENDED) EntityManager em;
-
- @EJB StatelessLocal stateless;
-
- private Customer customer;
-
- public long createCustomer()
- {
- customer = new Customer();
- customer.setName("William");
- em.persist(customer);
- return customer.getId();
- }
-
- public void update()
- {
- customer.setName("Bill");
- }
-...
-}
-}}}
-
-To inject an extended persistence context, you use the {{type()}} attribute and set it to {{EXTENDED}}. If you look at
-the {{createCustomer()}} method you notice that it is persisting a {{Customer}} object and storing a reference to that
-create object within a member variable of the stateful bean. When the update() method is called, you see that the customer's
-state is modified. Since the entity manager used is EXTENDED, the customer member variable remains managed by the entity
-manager and the modified state will be synchronized with the database.
-
-!Converations
-
-An even more interesting use case is when you combine extended persistence contexts with non-transactional methods.
-If you interact with an extended persistence context outside of a transaction, the inserts, updates, and deletes
-will be queued until you access the persistence context within a transaction. This means that any persist(), merge(), or remove() method you call will not
-actually result in a JDBC execution and thus an update of the database until you manually call EntityManager.flush().
-
-Why is this useful? Consider the usecase of a Setup Wizard on a website. The Wizard has seven steps, seven web pages to enter
-stuff in. It is extremely unwise to have a JTA transaction that spans multiple http requests, yet you do not want to commit
-anything to the database until all steps are complete. Your code can interact with the EntityManager as it wants and you
-do not have to worry about updates or writing a lot of gluecode in your application to do all the entity manager's work in the
-final step of the wizard. Efficient and highly performant. Because the managed persistent objects remain attached to the persistent context,
-all optmistic versioning checks can also be maintained within the application transaction. here's an example on how to do this.
-
-{{{
- at Stateful
- at Remote(ShoppingCart.class)
-public class ShoppingCartBean implements ShoppingCart
-{
- @PersistenceContext(type=PersistenceContextType.EXTENDED) EntityManager em;
-
- @EJB StatelessLocal stateless;
-
- private Customer customer;
-
- public long createCustomer()
- {
- customer = new Customer();
- customer.setName("William");
- em.persist(customer);
- return customer.getId();
- }
-
- @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
- public void never()
- {
- customer.setName("Bob");
- }
-
-
-
- @Remove
- public void checkout()
- {
- }
-}
-}}}
-
-Calling the never() method will update the managed customer object reference, but will not result in a database update until
-checkout() is called. The spec requires that any time you invoke a transactional method of a stateful bean,
-that the EntityManager join the transaction. Therefore, our never() update will be committed at the end of the checkout() method.
-
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-Buildfile: build.xml
-
-prepare:
-
-compile:
-
-ejbjar:
-
-run:
- [java] Created customer: William
- [java] Customer's name should still be William as pc was not yet flushed: Customer.getName() == William
- [java] Now that the pc has been flushed name should be 'Bob': Customer.getName() == Bob
- [java] Created customer: William
- [java] ShoppingCartBean.customer should stay managed because we're in an extended PC: Customer.getName() == Bill
- [java] Extended persistence contexts are propagated to nested EJB calls: Customer.getName() == Bill Jr.
-
-}}}
-
Deleted: projects/ejb3/trunk/docs/tutorial/injection/injection.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/injection/injection.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/injection/injection.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,83 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Dependency Injection</h2>
-
-To facilitate test driven development, the EJB 3.0 specification allows you to use annotations to inject dependencies through annotations on fields or setter methods. Instead of complicated XML ejb-refs or resource refs, you can use the <tt>@EJB</tt> and <tt>@Resource</tt> annotations to set the value of a field or to call a setter method within your session bean with anything registered within JNDI. You can use the <tt>@EJB</tt> annotation to inject EJB references and <tt>@Resource</tt> to access datasources.
-</p><p>
-Open up <a href="src/org/jboss/tutorial/injection/bean/ShoppingCartBean.java">ShoppingCartBean.java</a>. ShoppingCartBean uses the Calculator stateless session EJB to do calculations. The example shows two ways to get access to the Calculator EJB. One is:
-</p><p>
-<pre>
- @EJB
- private Calculator calculator;
-</pre>
-</p><p>
-When the ShoppingCartBean instance is created, the EJB container will set the calculator field using the jndiName of that particular referenced EJB.
-</p><p>
-You are not limited to injecting dependencies on fields. You can also use @EJB on a setter method. The below example from ShoppingCartBean uses the <tt>@EJB</tt> annotation to inject the reference to the Calculator session bean:
-</p><p>
-<pre>
- private Calculator set;
-
- @EJB(beanName="org.jboss.tutorial.injection.bean.CalculatorBean")
- public void setCalculator(Calculator c)
- {
- set = c;
- }
-</pre>
-</p><p>
-The @javax.annotation.Resource annotation allows you to inject resources.
-</p><p>
-<pre>
-
- @Resource(mappedName="DefaultDS")
- private javax.sql.DataSource ds;
-</pre>
-</p><p>
-In JBoss, whenever the mappedName() attribute is specified (@Resource, @EJB), jboss will use that as the GLOBAL jndi name to look it up.
-</p><p>
-The @Resource annotation is used to inject these singletons as well.
-<pre>
- @Resource javax.ejb.SessionContext ctx;
- @Resource javax.ejb.TimerService timer;
- @Resource javax.ejb.UserTransaction ut;
-</pre>
-</p><p>
-<tt>@EJB</tt> and <tt>@Resource</tt> also create an entry within the JNDI ENC of the bean. So, the above @EJB injection will create an entry for the reference calculator bean under "java:comp.ejb3/env/ejb/calculator".
-Note, the ENC name <i>SHOULD</i> be "java:/comp/env", but the JBoss Application server is currently being refactored in this
-area, so an EJB3 specific namespace is being used.
-
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
-run:
- [java] Buying 1 memory stick
- [java] 2004-10-06 19:37:16,869 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Buying another memory stick
- [java] Buying a laptop
- [java] Print cart:
- [java] 2 Memory stick
- [java] 1 Laptop
- [java] Checkout
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the ShoppingCartBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/injection/injection.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/injection/injection.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/injection/injection.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,74 +0,0 @@
-!!!Dependency Injection
-To facilitate test driven development, the EJB 3.0 specification allows you to use annotations to inject dependencies through annotations on fields or setter methods. Instead of complicated XML ejb-refs or resource refs, you can use the {{@EJB}} and {{@Resource}} annotations to set the value of a field or to call a setter method within your session bean with anything registered within JNDI. You can use the {{@EJB}} annotation to inject EJB references and {{@Resource}} to access datasources.
-
-Open up [ShoppingCartBean.java|src/org/jboss/tutorial/injection/bean/ShoppingCartBean.java]. ShoppingCartBean uses the Calculator stateless session EJB to do calculations. The example shows two ways to get access to the Calculator EJB. One is:
-
-{{{
- @EJB
- private Calculator calculator;
-}}}
-
-When the ShoppingCartBean instance is created, the EJB container will set the calculator field using the jndiName of that particular referenced EJB.
-
-You are not limited to injecting dependencies on fields. You can also use @EJB on a setter method. The below example from ShoppingCartBean uses the {{@EJB}} annotation to inject the reference to the Calculator session bean:
-
-{{{
- private Calculator set;
-
- @EJB(beanName="org.jboss.tutorial.injection.bean.CalculatorBean")
- public void setCalculator(Calculator c)
- {
- set = c;
- }
-}}}
-
-The @javax.annotation.Resource annotation allows you to inject resources.
-
-{{{
-
- @Resource(mappedName="DefaultDS")
- private javax.sql.DataSource ds;
-}}}
-
-In JBoss, whenever the mappedName() attribute is specified (@Resource, @EJB), jboss will use that as the GLOBAL jndi name to look it up.
-
-The @Resource annotation is used to inject these singletons as well.
-{{{
- @Resource javax.ejb.SessionContext ctx;
- @Resource javax.ejb.TimerService timer;
- @Resource javax.ejb.UserTransaction ut;
-}}}
-
-{{@EJB}} and {{@Resource}} also create an entry within the JNDI ENC of the bean. So, the above @EJB injection will create an entry for the reference calculator bean under "java:comp.ejb3/env/ejb/calculator".
-Note, the ENC name ''SHOULD'' be "java:/comp/env", but the JBoss Application server is currently being refactored in this
-area, so an EJB3 specific namespace is being used.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
-run:
- [java] Buying 1 memory stick
- [java] 2004-10-06 19:37:16,869 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Buying another memory stick
- [java] Buying a laptop
- [java] Print cart:
- [java] 2 Memory stick
- [java] 1 Laptop
- [java] Checkout
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the ShoppingCartBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/interceptor/interceptor.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/interceptor/interceptor.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/interceptor/interceptor.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,607 +0,0 @@
-<html>
-<body>
-<p>
-<h2>EJB Interceptors</h2>
-
-The EJB 3.0 spec defines the ability to apply custom made interceptors to the business methods of your session and message driven beans (and of course to the JBoss @Service and @Consumer beans). EJB 3.0 interceptors take the form of methods annotated with the <tt>@javax.ejb.AroundInvoke</tt> annotation. These methods must have the following signature:
-</p><p>
-<pre>
- @javax.ejb.AroundInvoke
- public Object <Arbitrary method name>(javax.ejb.InvocationContext ctx) throws java.lang.Exception
-</pre>
-</p><p>
-You can either define an interceptor method in the bean class itself, or in separate classes. There can only be one interceptor method per class.
-</p><p>
-<h2>Interceptor method in bean class</h2>
-
-</p><p>
-Take a look at <a href="src/org/jboss/tutorial/interceptor/bean/EmailMDB.java">EmailMDB.java</a>. It contains this method:
-<pre>
- @AroundInvoke
- public Object mdbInterceptor(InvocationContext ctx) throws Exception
- {
- System.out.println("*** Intercepting call to EmailMDB.mdbInterceptor()");
- return ctx.proceed();
- }
-</pre>
-</p><p>
-This method will wrap the call to EmailMDB.onMessage(). The call to ctx.proceed() causes the next object in the chain of
-interceptors to get invoked. At the end of the chain of interceptors, the actual bean method gets called.
-</p><p>
-Similarly <a href="src/org/jboss/tutorial/interceptor/bean/EmailSystemBean.java">EmailSystemBean.java</a> has a method annotated with <tt>@AroundInvoke</tt>
-</p><p>
-<pre>
- @AroundInvoke
- public Object myBeanInterceptor(InvocationContext ctx) throws Exception
- {
- if (ctx.getMethod().getName().equals("emailLostPassword"))
- {
- System.out.println("*** EmailSystemBean.myBeanInterceptor - username: " + ctx.getParameters()[0]);
- }
-
- return ctx.proceed();
- }
-</pre>
-</p><p>
-<h2>External interceptors</h2>
-
-</p><p>
-The rest of this example will be looking at adding interceptors external to the bean class, more specifically to <tt>EmailSystemBean</tt>. Interceptors can be bound in three different ways
-<ul>
-<li>Default</li>
-<li>Class-level</li>
-<li>Method-level</li>
-</ul>
-</p><p>
-An external interceptor instance follows the lifecycle of the target bean instance.
-</p><p>
-</p><p>
-<h3>Default interceptors</h3>
-
-</p><p>
-We will see how class and method-level interceptors can be bound to a bean or a bean's method using annotations or xml. Default interceptors can only be bound via xml. A Default interceptor is an interceptor that is invoked whenever a business method is invoked on any bean within the deployment.
-</p><p>
-<a href="src/org/jboss/tutorial/interceptor/bean/DefaultInterceptor.java">DefaultInterceptor.java</a> defines an <tt>@AroundInvoke</tt> method with the required method signature.
-</p><p>
-<pre>
- @AroundInvoke
- public Object intercept(InvocationContext ctx) throws Exception
- {
- System.out.println("*** DefaultInterceptor intercepting " + ctx.getMethod().getName());
- try
- {
- return ctx.proceed();
- }
- finally
- {
- System.out.println("*** DefaultInterceptor exiting");
- }
- }
-</pre>
-</p><p>
-As mentioned, default interceptors can only be applied via xml.
-</p><p>
-In <a href="META-INF/ejb-jar.xml">ejb-jar.xml</a> we have the following:
-<pre>
- <assembly-descriptor>
- <!-- Default interceptor that will apply to all methods for all beans in deployment -->
- <interceptor-binding>
- <ejb-name>*</ejb-name>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.DefaultInterceptor</interceptor-class>
- </interceptor-binding>
- ...
- </assembly-descriptor>
-</pre>
-</p><p>
-Using <tt>*</tt> for the ejb-name says that <tt>DefaultInterceptor</tt> is a default interceptor, i.e. it should intercept all calls to all beans within the deployment unit. We could have added more <tt>interceptor-class</tt> entries to bind more interceptors, as shown here:
-<pre>
- <assembly-descriptor>
- <!-- Default interceptor that will apply to all methods for all beans in deployment -->
- <interceptor-binding>
- <ejb-name>*</ejb-name>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.DefaultInterceptor</interceptor-class>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.AnotherInterceptor</interceptor-class>
- </interceptor-binding>
- ...
- </assembly-descriptor>
-</pre>
-</p><p>
-In this case DefaultInterceptor would be invoked before AnotherInterceptor.
-</p><p>
-</p><p>
-<h3>Class-level interceptors</h3>
-
-</p><p>
-Class-level interceptors can be bound using xml or annotations.
-</p><p>
-<h4>Class-level using annotations</h4>
-
-</p><p>
-<a href="src/org/jboss/tutorial/interceptor/bean/EmailSystemBean.java">EmailSystemBean.java</a> has been
-annotated:
-</p><p>
-<pre>
- @Stateless
- @Interceptors ({TracingInterceptor.class})
- public class EmailSystemBean
- {
- ...
- }
-</pre>
-</p><p>
-This says that the <tt>@AroundInvoke</tt> annotated method of <a href="src/org/jboss/tutorial/interceptor/bean/TracingInterceptor.java">TracingInterceptor.java</a> should wrap all calls to <tt>EmailSystemBean</tt>'s business methods. The <tt>@Interceptors</tt> annotation can take an array of classes, so you can bind more than one class-level interceptor this way, e.g.
-</p><p>
-<pre>
- @Stateless
- @Interceptors ({TracingInterceptor.class, SomeInterceptor.class})
- public class EmailSystemBean
- {
- ...
- }
-</pre>
-</p><p>
-<h4>Class-level using xml</h4>
-
-</p><p>
-In <a href="META-INF/ejb-jar.xml">ejb-jar.xml</a> we have the following:
-<pre>
- <assembly-descriptor>
- ...
- <!-- Class interceptor that will apply to all methods for EmailSystemBean -->
- <interceptor-binding>
- <ejb-name>org.jboss.tutorial.interceptor.bean.EmailSystemBean</ejb-name>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.OtherInterceptor</interceptor-class>
- </interceptor-binding>
- ...
- </assembly-descriptor>
-</pre>
-</p><p>
-Note that here we are specifying the ejb-name of the bean we want to apply the interceptor to. Hence, the <tt>@AroundInvoke</tt> annotated method of <a href="src/org/jboss/tutorial/interceptor/bean/OtherInterceptor.java">OtherInterceptor.java</a> will wrap all calls to <tt>EmailSystemBean</tt>'s business methods.
-</p><p>
-<h3>Method-level interceptors</h3>
-
-</p><p>
-Just as we can define default and class-level interceptors, we can also bind an interceptor to a particular business method within a bean
-</p><p>
-<h4>Method-level using annotations</h4>
-
-</p><p>
-<a href="src/org/jboss/tutorial/interceptor/bean/EmailSystemBean.java">EmailSystemBean</a>'s <tt>sendBookingConfirmationMessage()</tt> method has been annotated with the @Interceptors annotation specifying
-interceptors that will intercept when this perticular method is invoked.
-</p><p>
-<pre>
- @Interceptors({AccountsConfirmInterceptor.class})
- public void sendBookingConfirmationMessage(long orderId)
- {
- ...
- }
-</pre>
-</p><p>
-Method-level interceptors are in addition to default and class-level interceptors, meaning that when we call <tt>EmailSystemBean.sendBookingConfirmationMessage()</tt> we get intercepted by
-<ul>
-<li>DefaultInterceptor (default)</li>
-<li>TracingInterceptor (class-level)</li>
-<li>OtherIntercetor (class-level)</li>
-<li><a href="src/org/jboss/tutorial/interceptor/bean/AccountsConfirmInterceptor.java">AccountsConfirmInterceptor</a> (method-level)</li>
-</ul>
-</p><p>
-An interceptor method can choose to abort an invocation, by not calling <tt>InvocationContext.proceed()</tt> as is done in <tt>AccountConfirmInterceptor</tt>'s interceptor method when a confirmation already exists.
-</p><p>
-<h4>Method-level using xml</h4>
-
-We can also bind interceptors to a single business method within a bean using xml. But first let's define an interceptor using xml. All the examples we have looked at so far have used the <tt>@AroundInvoke</tt> annotation to mark the interceptor methods.
-</p><p>
-In <a href="META-INF/ejb-jar.xml">ejb-jar.xml</a> we have the following:
-<pre>
- <interceptors>
- <interceptor>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</interceptor-class>
- <around-invoke-method>
- <method-name>sendCancelMessage</method-name>
- </around-invoke-method>
- ...
- </interceptors>
-</pre>
-</p><p>
-This tells us that the <tt>sendCancelMessage()</tt> method of <a href="src/org/jboss/tutorial/interceptor/bean/AccountsCancelInterceptor.java">AccountsCancelInterceptor</a> is the interceptor method of this interceptor class. (We will see what the other sub-elements of <tt>interceptor</tt> mean in the 'injection' section.
-</p><p>
-To bind interceptors to a particular method using xml, is much the same as how this was done for class-level interceptors apart from that we specify the <tt>method-name</tt> of the method we want to intercept. From our <a href="META-INF/ejb-jar.xml">ejb-jar.xml</a>:
-<pre>
- <assembly-descriptor>
- ...
- <!-- Method interceptor will apply to sendBookingCancellationMessage for EmailSystemBean -->
- <interceptor-binding>
- <ejb-name>org.jboss.tutorial.interceptor.bean.EmailSystemBean</ejb-name>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</interceptor-class>
- <method-name>sendBookingCancellationMessage</method-name>
- </interceptor-binding>
- </assembly-descriptor>
-</pre>
-</p><p>
-In the example just shown, if we had several business methods with the name, the interceptor would get applied to all of them. In the case of overloaded methods, we can further narrow down the method by specifying the method parameters, as in this example:
-<pre>
- <assembly-descriptor>
- ...
- <!-- Method interceptor will apply to sendBookingCancellationMessage for EmailSystemBean -->
- <interceptor-binding>
- <ejb-name>MyBean</ejb-name>
- <interceptor-class>SomeInterceptor</interceptor-class>
- <method-name>overLoadedMethod</method-name>
- <method-params>
- <method-param>int</method-param>
- <method-param>java.lang.String[][]</method-param>
- </method-params>
-
- </interceptor-binding>
- </assembly-descriptor>
-</pre>
-</p><p>
-If <tt>MyBean</tt> has several methods called <tt>overLoadedMethod</tt>, <tt>SomeInterceptor</tt> will only get applied to the one that matches the signature, i.e. <pre>overLoadedMethod(int, java.lang.String[][])</pre>
-</p><p>
-</p><p>
-<h2> Exclusion of default and class interceptors</h2>
-
-For some beans we may want to exclude the default interceptors configured for the deployment, and for some methods with in a bean class we may want to exclude the class interceptors for the bean (and/or the default interceptors)
-<h3>Annotations</h3>
-
-</p><p>
-The <tt>@javax.ejb.ExcludeDefaultInterceptors</tt> annotation can be applied to a bean class or a method. If applied to a bean class, default interceptors will not get invoked for any of that bean class's methods. If applied to a bean business method, default interceptors will not get invoked when calling that method.
-</p><p>
-The <tt>@javax.ejb.ExcludeClassInterceptors</tt> annotation can be applied to a bean method, and if used class-level interceptors will not get invoked when calling that method.
-</p><p>
-<a href="src/org/jboss/tutorial/interceptor/bean/EmailMDB.java">EmailMDB.java</a> defines
-<pre>
- @ExcludeDefaultInterceptors
- public class EmailMDB implements MessageListener
- {
- ...
- }
-</pre>
-so <tt>DefaultInterceptor</tt> is not invoked when invoking the <tt>EmailMDB.onMessage()</tt>
-</p><p>
-</p><p>
-<a href="src/org/jboss/tutorial/interceptor/bean/EmailSystemBean.java">EmailSystemBean</a>'s <tt>noop</tt> method is annotated with both <tt>@ExcludeClassInterceptors</tt> and <tt>@ExcludeDefaultInterceptors</tt> and so will not get intercepted by any of these.
-</p><p>
-</p><p>
-<pre>
- @ExcludeClassInterceptors
- @ExcludeDefaultInterceptors
- public void noop()
- {
- System.out.println("<In EmailSystemBean.noop business method");
- System.out.println("Exiting EmailSystemBean.noop business method>");
- }
-
-}}
-
-
-!!XML
-We can also exclude class and method-level interceptors within an {{interceptor-binding}} by specifying the {{exclude-class-interceptors}} and {{exclude-default-interceptors}} elements.
-{{{
- <assembly-descriptor>
- ...
- <interceptor-binding>
- <ejb-name>org.jboss.tutorial.interceptor.bean.EmailSystemBean</ejb-name>
- <exclude-class-interceptors/>
- <exclude-default-interceptors/>
- <method-name>noop2</method-name>
- </interceptor-binding>
- ...
- </assembly-descriptor>
-</pre>
-</p><p>
-<h2>Inheritance Ordering</h2>
-
-If an interceptor (or bean class) inherits from another class which has a method declared to be an interceptor method, the interceptor methods from the super class will be invoked first. However, if the interceptor method in the superclass has been overridden (regardless of if the overriding method is declared to be an interceptor method or not) it is not invoked.
-</p><p>
-Both <a href="src/org/jboss/tutorial/interceptor/bean/AccountsConfirmInterceptor.java">AccountsConfirmInterceptor</a> and <a href="src/org/jboss/tutorial/interceptor/bean/AccountsCancelInterceptor.java">AccountsCancelInterceptor</a>
-inherit from <a href="src/org/jboss/tutorial/interceptor/bean/AccountsInterceptor.java">AccountsInterceptor</a>.
-</p><p>
-AccountsInterceptor declares the following interceptor method:
-<pre>
- @AroundInvoke
- public Object intercept(InvocationContext ctx) throws Exception
- {
- System.out.println("*** AccountsInterceptor intercepting " + ctx.getMethod().getName());
- try
- {
- return ctx.proceed();
- }
- finally
- {
- System.out.println("*** AccountsInterceptor exiting");
- }
- }
-</pre>
-</p><p>
-This method is overridden by <tt>AccountsConfirmInterceptor</tt>, even though it is not <tt>AccountsConfirmInterceptor</tt>'s interceptor method:
-<pre>
-public class AccountsConfirmInterceptor extends AccountsInterceptor
-{
- ...
- public Object intercept(InvocationContext ctx) throws Exception
- {
- //overrides AccountsInterceptor.intercept() so that will not be invoked
- return null;
- }
-
-
- @AroundInvoke
- public Object sendConfirmMessage(InvocationContext ctx) throws Exception
- {
- ...
- }
-}
-
-</pre>
-</p><p>
-So when invoking <tt>AccountsConfirmInterceptor</tt>, we simply invoke its <tt>sendConfirmMessage()</tt> method. <tt>AccountsCancelInterceptor</tt>, on the other hand, does not override <tt>AccountsInterceptor.intercept()</tt>, so when invoking <tt>AccountsCancelInterceptor</tt>, we first get intercepted by <tt>AccountsInterceptor.intercept()</tt> followed by <tt>AccountsCancelInterceptor.sendCancelMessage()</tt>.
-</p><p>
-<h2>Injection</h2>
-
-<h3>Annotations</h3>
-
-Just like a bean class, an interceptor can be the target of <a href="../injection/injection.html">Dependency injection</a>. The format for how this works is the same, and the injection works off the same ENC as the bean to which the interceptor is bound.
-</p><p>
-<a href="src/org/jboss/tutorial/interceptor/bean/AccountsConfirmInterceptor.java">AccountsConfirmInterceptor</a> has dependency injection set up using annotations:
-</p><p>
-<pre>
-public class AccountsConfirmInterceptor extends AccountsInterceptor
-{
- @Resource(mappedName="java:ConnectionFactory")
- QueueConnectionFactory cf;
-
- @Resource(mappedName="queue/tutorial/accounts")
- Queue queue;
-
- @PersistenceContext
- EntityManager em;
-
- ...
-</pre>
-</p><p>
-Remember that interceptors follow the same lifecycle as the bean they are bound to. The interceptors are created at the same time as the bean instance is created, and dependecy injection occurs before the first business method is called. In the example just shown, the container;
-<ul>
-<li>looks up <tt>java:ConnectionFactory</tt>, binds it in the ENC and injects this into the field <tt>cf</tt></li>
-<li>looks up <tt>queue/tutorial/accounts</tt>, binds it in the ENC and injects this into the field <tt>queue</tt></li>
-<li>Obtains the default EntityManager injects this into the field <tt>em</tt></li>
-</ul>
-</p><p>
-<h3>XML</h3>
-
-Injection can also be configured via xml, using the traditional <tt>ejb-ref</tt>, <tt>ejb-local-ref</tt>, <tt>resource-ref</tt>, <tt>resource-env-ref</tt> etc. which bind the global names. The only difference from beans is that we put this into the <tt>interceptors</tt> element defining the interceptor.
-</p><p>
-<pre>
- <interceptors>
- <interceptor>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</interceptor-class>
- <around-invoke-method>
- <method-name>sendCancelMessage</method-name>
- </around-invoke-method>
- <resource-ref>
- <res-ref-name>jms/ConnFactory</res-ref-name>
- <res-type>javax.jms.QueueConnectionFactory</res-type>
- <res-auth>Container</res-auth>
- <mapped-name>java:/ConnectionFactory</mapped-name>
- <injection-target>
- <injection-target-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</injection-target-class>
- <injection-target-name>cf</injection-target-name>
- </injection-target>
- </resource-ref>
- <resource-env-ref>
- <resource-env-ref-name>accountsQueue</resource-env-ref-name>
- <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
- <res-auth>Container</res-auth>
- <mapped-name>queue/tutorial/accounts</mapped-name>
- <injection-target>
- <injection-target-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</injection-target-class>
- <injection-target-name>queue</injection-target-name>
- </injection-target>
- </resource-env-ref>
- </interceptor>
- </interceptors>
-</pre>
-</p><p>
-<ul>
-<li>the Container looks up <tt>java:/ConnectionFactory</tt> in JNDI and creates the <tt>java:comp/env/jms/ConnFactory</tt> entry in the beans ENC, and following bean creation it injects the connction factory into AccountsCancelInterceptor's cf field.</li>
-<li>the Container looks up <tt>queue/tutorial/accounts</tt> in JNDI and creates the <tt>java:comp/env/accountsQueue</tt> entry in the beans ENC, and following bean creation it injects the connction factory into AccountsCancelInterceptor's queue field.</li>
-</ul>
-</p><p>
-<h2>Interceptor Ordering</h2>
-
-</p><p>
-By default the ordering of interceptors when invoking a method are
-</p><p>
-<ul>
-<li>External interceptors</li>
-<ul>
-<li>Default interceptors, if present</li>
-<li>Class interceptors, if present</li>
-<li>Method interceptors, if present</li>
-</ul>
-<li>Bean class interceptor method</li>
-</ul>
-</p><p>
-Within each group (default, class, method) the order of the interceptors are from left to right as defined in the @Interceptors annotation, and then the xml interceptors.
-</p><p>
-<h3>Overriding interceptor ordering</h3>
-
-You can override the default sort order of the external interceptors by specifiying an <tt>interceptor-binding</tt> with an <tt>interceptor-order</tt> specifying the order of the interceptors
-<pre>
- <assembly-descriptor>
- ...
- <interceptor-binding>
- <ejb-name>org.jboss.tutorial.interceptor.bean.EmailSystemBean</ejb-name>
- <method-name>sendBookingCancellationMessage</method-name>
- <interceptor-order>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</interceptor-class>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.DefaultInterceptor</interceptor-class>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.OtherInterceptor</interceptor-class>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.TracingInterceptor</interceptor-class>
- </interceptor-order>
- </interceptor-binding>
- </assembly-descriptor>
-
-</pre>
-</p><p>
-So when invoking <tt>EmailSystemBean.sendBookingCancellationMessage</tt> we will get the following interception order, quite different from the default sort order
-<ul>
-<li>AccountsCancelInterceptor (method-level)</li>
-<li>DefaultInterceptor (default interceptor)</li>
-<li>OtherInterceptor (2nd class-level interceptor)</li>
-<li>TracingInterceptor(1st class-level interceptor)</li>
-</ul>
-</p><p>
-<h4>InvocationContext</h4>
-
-As you have seen the @AroundInvoke annotated interceptor methods all take a parameter of type <tt>javax.ejb.InvocationContext</tt>.
-The definition of InvocationContext is:
-<pre>
- package javax.ejb;
-
- public interface InvocationContext {
- public Object getBean();
- public java.lang.reflect.Method getMethod();
- public Object[] getParameters();
- public void setParameters(Object[] params);
- public java.util.Map getContextData();
- public Object proceed() throws Exception;
- }
-</pre>
-</p><p>
-<ul>
-<li><tt>getBean()</tt> - returns the bean instance on which we are calling a method</li>
-<li><tt>getMethod()</tt> - returns the method we are calling on the bean instance</li>
-<li><tt>getParameters()</tt> - returns the parameters for the method call</li>
-<li><tt>setParameters()</tt> - allows you to modify the parameters for the method call</li>
-<li><tt>getContextData</tt> - The EJB interceptions are stateless, but the same InvocationContext instance is used for each interceptor method in a chain. If you want to pass values between interceptor methods in the business method invocation you can store them in the Map retured by getContextData().</li>
-<li><tt>proceed</tt> - As discussed, invokes the next interceptor, or if we are in the last interceptor invokes the target bean method.</li>
-</ul>
-</p><p>
-In some case we might want access to the EJBContext, this can be injected into the interceptor instance using the <tt>@Resource</tt> annotation.The AroundInvoke methods share the JNDI name space of the bean for whose methods they are invoked and execute within the same transaction and security context as the business methods for which they are invoked.
-</p><p>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-</pre>
-</p><p>
-Look at the JBoss console window to see the output of the interceptions taking place, the EmailMDB and AccountsMDB might occur in slightly different places since they execute asynchronously
-</p><p>
-<pre>
-17:34:54,468 INFO [EJB3Deployer] Deployed: file:/C:/cygwin/home/Kabir/cvs/jboss-head/build/output/jboss-5.0.0alpha/server/all/dep
-loy/tutorial.jar
-</pre>
-</p><p>
-Calling EmailSystemBean.emailLostPassword()
-<pre>
-17:35:02,328 INFO [STDOUT] *** DefaultInterceptor intercepting emailLostPassword
-17:35:02,328 INFO [STDOUT] *** TracingInterceptor intercepting emailLostPassword
-17:35:02,328 INFO [STDOUT] *** OtherInterceptor intercepting emailLostPassword
-17:35:02,328 INFO [STDOUT] *** EmailSystemBean.myBeanInterceptor - username: whatever
-17:35:02,328 INFO [STDOUT] <In EmailSystemBean.emailLostPassword business method
-17:35:05,343 INFO [STDOUT] Message sent successfully to remote queue.
-17:35:05,343 INFO [STDOUT] Exiting EmailSystemBean.emailLostPassword business method>
-17:35:05,343 INFO [STDOUT] *** OtherInterceptor exiting
-17:35:05,343 INFO [STDOUT] *** TracingInterceptor invocation of org.jboss.tutorial.interceptor.bean.EmailSystemBean.emailLostPass
-word() took 3015ms
-17:35:05,375 INFO [STDOUT] *** EmailMDB.mdbInterceptor intercepting
-17:35:05,375 INFO [STDOUT]
-----------------
-EMailMDB - Got message, sending email
-----------------
-17:35:05,375 INFO [STDOUT] *** DefaultInterceptor exiting
-</pre>
-</p><p>
-Calling EmailSystemBean.sendBookingConfirmationMessage()
-<pre>
-17:35:07,421 INFO [STDOUT] *** DefaultInterceptor intercepting sendBookingConfirmationMessage
-17:35:07,421 INFO [STDOUT] *** TracingInterceptor intercepting sendBookingConfirmationMessage
-17:35:07,437 INFO [STDOUT] *** OtherInterceptor intercepting sendBookingConfirmationMessage
-17:35:07,437 INFO [STDOUT] *** AccountsConfirmInterceptor intercepting
-17:35:07,437 INFO [STDOUT] *** AccountsConfirmInterceptor - recording confirmation
-17:35:07,437 INFO [STDOUT] *** AccountsConfirmInterceptor - notifying accounts dept sendBookingConfirmationMessage
-17:35:07,437 INFO [STDOUT] <In EmailSystemBean.sendBookingConfirmationMessage business method
-17:35:07,453 INFO [STDOUT] *** DefaultInterceptor intercepting onMessage
-17:35:07,453 INFO [STDOUT]
-----------------
-AccountsMDB - Got message Confirming order 100
-----------------
-17:35:07,453 INFO [STDOUT] *** DefaultInterceptor exiting
-17:35:10,468 INFO [STDOUT] Message sent successfully to remote queue.
-17:35:10,468 INFO [STDOUT] Exiting EmailSystemBean.sendBookingConfirmationMessage business method>
-17:35:10,468 INFO [STDOUT] *** AccountsConfirmInterceptor exiting
-17:35:10,468 INFO [STDOUT] *** OtherInterceptor exiting
-17:35:10,468 INFO [STDOUT] *** TracingInterceptor invocation of org.jboss.tutorial.interceptor.bean.EmailSystemBean.sendBookingCo
-nfirmationMessage() took 3031ms
-17:35:10,468 INFO [STDOUT] *** DefaultInterceptor exiting
-17:35:10,468 INFO [STDOUT] *** EmailMDB.mdbInterceptor intercepting
-17:35:10,468 INFO [STDOUT]
-----------------
-EMailMDB - Got message, sending email
-----------------
-</pre>
-Calling EmailSystemBean.sendBookingConfirmationMessage(), this will be aborted
-<pre>
-17:35:12,484 INFO [STDOUT] *** DefaultInterceptor intercepting sendBookingConfirmationMessage
-17:35:12,484 INFO [STDOUT] *** TracingInterceptor intercepting sendBookingConfirmationMessage
-17:35:12,484 INFO [STDOUT] *** OtherInterceptor intercepting sendBookingConfirmationMessage
-17:35:12,484 INFO [STDOUT] *** AccountsConfirmInterceptor intercepting
-17:35:12,484 INFO [STDOUT] *** AccountsConfirmInterceptor - order has already been confirmed aborting
-17:35:12,500 INFO [STDOUT] *** AccountsConfirmInterceptor exiting
-17:35:12,500 INFO [STDOUT] *** OtherInterceptor exiting
-17:35:12,500 INFO [STDOUT] *** TracingInterceptor invocation of org.jboss.tutorial.interceptor.bean.EmailSystemBean.sendBookingCo
-nfirmationMessage() took 16ms
-17:35:12,500 INFO [STDOUT] *** DefaultInterceptor exiting
-</pre>
-Calling EmailSystemBean.sendBookingCancellationMessage(), this will be aborted
-<pre>
-17:35:14,500 INFO [STDOUT] *** AccountsInterceptor intercepting sendBookingCancellationMessage
-17:35:14,500 INFO [STDOUT] *** AccountsCancelInterceptor intercepting sendBookingCancellationMessage
-17:35:14,500 INFO [STDOUT] *** AccountsConfirmInterceptor - notifying accounts dept
-17:35:14,500 INFO [STDOUT] *** DefaultInterceptor intercepting sendBookingCancellationMessage
-17:35:14,515 INFO [STDOUT] *** OtherInterceptor intercepting sendBookingCancellationMessage
-17:35:14,515 INFO [STDOUT] *** TracingInterceptor intercepting sendBookingCancellationMessage
-17:35:14,515 INFO [STDOUT] <In EmailSystemBean.sendBookingCancellationMessage business method
-17:35:14,515 INFO [STDOUT] *** DefaultInterceptor intercepting onMessage
-17:35:14,515 INFO [STDOUT]
-----------------
-AccountsMDB - Got message Cancelling order 100
-----------------
-17:35:14,515 INFO [STDOUT] *** DefaultInterceptor exiting
-17:35:17,625 INFO [STDOUT] Message sent successfully to remote queue.
-17:35:17,625 INFO [STDOUT] Exiting EmailSystemBean.sendBookingCancellationMessage business method>
-17:35:17,625 INFO [STDOUT] *** TracingInterceptor invocation of org.jboss.tutorial.interceptor.bean.EmailSystemBean.sendBookingCa
-ncellationMessage() took 3110ms
-17:35:17,625 INFO [STDOUT] *** OtherInterceptor exiting
-17:35:17,625 INFO [STDOUT] *** DefaultInterceptor exiting
-17:35:17,625 INFO [STDOUT] *** AccountsCancelInterceptor exiting
-17:35:17,640 INFO [STDOUT] *** AccountsInterceptor exiting
-17:35:17,640 INFO [STDOUT] *** EmailMDB.mdbInterceptor intercepting
-17:35:17,640 INFO [STDOUT]
-----------------
-EMailMDB - Got message, sending email
-----------------
-</pre>
-Calling EmailSystemBean.noop()
-</p><p>
-<pre>
-17:35:19,640 INFO [STDOUT] <In EmailSystemBean.noop business method
-17:35:19,640 INFO [STDOUT] Exiting EmailSystemBean.noop business method>
-</pre>
-Calling EmailSystemBean.noop2()
-<pre>
-17:35:21,640 INFO [STDOUT] <In EmailSystemBean.noop2 business method
-17:35:21,640 INFO [STDOUT] Exiting EmailSystemBean.noop2 business method>
-</pre>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/interceptor/interceptor.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/interceptor/interceptor.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/interceptor/interceptor.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,565 +0,0 @@
-!!!!EJB Interceptors
-The EJB 3.0 spec defines the ability to apply custom made interceptors to the business methods of your session and message driven beans (and of course to the JBoss @Service and @Consumer beans). EJB 3.0 interceptors take the form of methods annotated with the {{@javax.ejb.AroundInvoke}} annotation. These methods must have the following signature:
-
-{{{
- @javax.ejb.AroundInvoke
- public Object <Arbitrary method name>(javax.ejb.InvocationContext ctx) throws java.lang.Exception
-}}}
-
-You can either define an interceptor method in the bean class itself, or in separate classes. There can only be one interceptor method per class.
-
-!!!Interceptor method in bean class
-
-Take a look at [EmailMDB.java|src/org/jboss/tutorial/interceptor/bean/EmailMDB.java]. It contains this method:
-{{{
- @AroundInvoke
- public Object mdbInterceptor(InvocationContext ctx) throws Exception
- {
- System.out.println("*** Intercepting call to EmailMDB.mdbInterceptor()");
- return ctx.proceed();
- }
-}}}
-
-This method will wrap the call to EmailMDB.onMessage(). The call to ctx.proceed() causes the next object in the chain of
-interceptors to get invoked. At the end of the chain of interceptors, the actual bean method gets called.
-
-Similarly [EmailSystemBean.java|src/org/jboss/tutorial/interceptor/bean/EmailSystemBean.java] has a method annotated with {{@AroundInvoke}}
-
-{{{
- @AroundInvoke
- public Object myBeanInterceptor(InvocationContext ctx) throws Exception
- {
- if (ctx.getMethod().getName().equals("emailLostPassword"))
- {
- System.out.println("*** EmailSystemBean.myBeanInterceptor - username: " + ctx.getParameters()[0]);
- }
-
- return ctx.proceed();
- }
-}}}
-
-!!!External interceptors
-
-The rest of this example will be looking at adding interceptors external to the bean class, more specifically to {{EmailSystemBean}}. Interceptors can be bound in three different ways
-*Default
-*Class-level
-*Method-level
-
-An external interceptor instance follows the lifecycle of the target bean instance.
-
-
-!!Default interceptors
-
-We will see how class and method-level interceptors can be bound to a bean or a bean's method using annotations or xml. Default interceptors can only be bound via xml. A Default interceptor is an interceptor that is invoked whenever a business method is invoked on any bean within the deployment.
-
-[DefaultInterceptor.java|src/org/jboss/tutorial/interceptor/bean/DefaultInterceptor.java] defines an {{@AroundInvoke}} method with the required method signature.
-
-{{{
- @AroundInvoke
- public Object intercept(InvocationContext ctx) throws Exception
- {
- System.out.println("*** DefaultInterceptor intercepting " + ctx.getMethod().getName());
- try
- {
- return ctx.proceed();
- }
- finally
- {
- System.out.println("*** DefaultInterceptor exiting");
- }
- }
-}}}
-
-As mentioned, default interceptors can only be applied via xml.
-
-In [ejb-jar.xml|META-INF/ejb-jar.xml] we have the following:
-{{{
- <assembly-descriptor>
- <!-- Default interceptor that will apply to all methods for all beans in deployment -->
- <interceptor-binding>
- <ejb-name>*</ejb-name>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.DefaultInterceptor</interceptor-class>
- </interceptor-binding>
- ...
- </assembly-descriptor>
-}}}
-
-Using {{*}} for the ejb-name says that {{DefaultInterceptor}} is a default interceptor, i.e. it should intercept all calls to all beans within the deployment unit. We could have added more {{interceptor-class}} entries to bind more interceptors, as shown here:
-{{{
- <assembly-descriptor>
- <!-- Default interceptor that will apply to all methods for all beans in deployment -->
- <interceptor-binding>
- <ejb-name>*</ejb-name>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.DefaultInterceptor</interceptor-class>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.AnotherInterceptor</interceptor-class>
- </interceptor-binding>
- ...
- </assembly-descriptor>
-}}}
-
-In this case DefaultInterceptor would be invoked before AnotherInterceptor.
-
-
-!!Class-level interceptors
-
-Class-level interceptors can be bound using xml or annotations.
-
-!Class-level using annotations
-
-[EmailSystemBean.java|src/org/jboss/tutorial/interceptor/bean/EmailSystemBean.java] has been
-annotated:
-
-{{{
- @Stateless
- @Interceptors ({TracingInterceptor.class})
- public class EmailSystemBean
- {
- ...
- }
-}}}
-
-This says that the {{@AroundInvoke}} annotated method of [TracingInterceptor.java|src/org/jboss/tutorial/interceptor/bean/TracingInterceptor.java] should wrap all calls to {{EmailSystemBean}}'s business methods. The {{@Interceptors}} annotation can take an array of classes, so you can bind more than one class-level interceptor this way, e.g.
-
-{{{
- @Stateless
- @Interceptors ({TracingInterceptor.class, SomeInterceptor.class})
- public class EmailSystemBean
- {
- ...
- }
-}}}
-
-!Class-level using xml
-
-In [ejb-jar.xml|META-INF/ejb-jar.xml] we have the following:
-{{{
- <assembly-descriptor>
- ...
- <!-- Class interceptor that will apply to all methods for EmailSystemBean -->
- <interceptor-binding>
- <ejb-name>org.jboss.tutorial.interceptor.bean.EmailSystemBean</ejb-name>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.OtherInterceptor</interceptor-class>
- </interceptor-binding>
- ...
- </assembly-descriptor>
-}}}
-
-Note that here we are specifying the ejb-name of the bean we want to apply the interceptor to. Hence, the {{@AroundInvoke}} annotated method of [OtherInterceptor.java|src/org/jboss/tutorial/interceptor/bean/OtherInterceptor.java] will wrap all calls to {{EmailSystemBean}}'s business methods.
-
-!!Method-level interceptors
-
-Just as we can define default and class-level interceptors, we can also bind an interceptor to a particular business method within a bean
-
-!Method-level using annotations
-
-[EmailSystemBean|src/org/jboss/tutorial/interceptor/bean/EmailSystemBean.java]'s {{sendBookingConfirmationMessage()}} method has been annotated with the @Interceptors annotation specifying
-interceptors that will intercept when this perticular method is invoked.
-
-{{{
- @Interceptors({AccountsConfirmInterceptor.class})
- public void sendBookingConfirmationMessage(long orderId)
- {
- ...
- }
-}}}
-
-Method-level interceptors are in addition to default and class-level interceptors, meaning that when we call {{EmailSystemBean.sendBookingConfirmationMessage()}} we get intercepted by
-*DefaultInterceptor (default)
-*TracingInterceptor (class-level)
-*OtherIntercetor (class-level)
-*[AccountsConfirmInterceptor|src/org/jboss/tutorial/interceptor/bean/AccountsConfirmInterceptor.java] (method-level)
-
-An interceptor method can choose to abort an invocation, by not calling {{InvocationContext.proceed()}} as is done in {{AccountConfirmInterceptor}}'s interceptor method when a confirmation already exists.
-
-!Method-level using xml
-We can also bind interceptors to a single business method within a bean using xml. But first let's define an interceptor using xml. All the examples we have looked at so far have used the {{@AroundInvoke}} annotation to mark the interceptor methods.
-
-In [ejb-jar.xml|META-INF/ejb-jar.xml] we have the following:
-{{{
- <interceptors>
- <interceptor>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</interceptor-class>
- <around-invoke-method>
- <method-name>sendCancelMessage</method-name>
- </around-invoke-method>
- ...
- </interceptors>
-}}}
-
-This tells us that the {{sendCancelMessage()}} method of [AccountsCancelInterceptor|src/org/jboss/tutorial/interceptor/bean/AccountsCancelInterceptor.java] is the interceptor method of this interceptor class. (We will see what the other sub-elements of {{interceptor}} mean in the 'injection' section.
-
-To bind interceptors to a particular method using xml, is much the same as how this was done for class-level interceptors apart from that we specify the {{method-name}} of the method we want to intercept. From our [ejb-jar.xml|META-INF/ejb-jar.xml]:
-{{{
- <assembly-descriptor>
- ...
- <!-- Method interceptor will apply to sendBookingCancellationMessage for EmailSystemBean -->
- <interceptor-binding>
- <ejb-name>org.jboss.tutorial.interceptor.bean.EmailSystemBean</ejb-name>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</interceptor-class>
- <method-name>sendBookingCancellationMessage</method-name>
- </interceptor-binding>
- </assembly-descriptor>
-}}}
-
-In the example just shown, if we had several business methods with the name, the interceptor would get applied to all of them. In the case of overloaded methods, we can further narrow down the method by specifying the method parameters, as in this example:
-{{{
- <assembly-descriptor>
- ...
- <!-- Method interceptor will apply to sendBookingCancellationMessage for EmailSystemBean -->
- <interceptor-binding>
- <ejb-name>MyBean</ejb-name>
- <interceptor-class>SomeInterceptor</interceptor-class>
- <method-name>overLoadedMethod</method-name>
- <method-params>
- <method-param>int</method-param>
- <method-param>java.lang.String[][]</method-param>
- </method-params>
-
- </interceptor-binding>
- </assembly-descriptor>
-}}}
-
-If {{MyBean}} has several methods called {{overLoadedMethod}}, {{SomeInterceptor}} will only get applied to the one that matches the signature, i.e. {{{overLoadedMethod(int, java.lang.String[][])}}}
-
-
-!!! Exclusion of default and class interceptors
-For some beans we may want to exclude the default interceptors configured for the deployment, and for some methods with in a bean class we may want to exclude the class interceptors for the bean (and/or the default interceptors)
-!!Annotations
-
-The {{@javax.ejb.ExcludeDefaultInterceptors}} annotation can be applied to a bean class or a method. If applied to a bean class, default interceptors will not get invoked for any of that bean class's methods. If applied to a bean business method, default interceptors will not get invoked when calling that method.
-
-The {{@javax.ejb.ExcludeClassInterceptors}} annotation can be applied to a bean method, and if used class-level interceptors will not get invoked when calling that method.
-
-[EmailMDB.java|src/org/jboss/tutorial/interceptor/bean/EmailMDB.java] defines
-{{{
- @ExcludeDefaultInterceptors
- public class EmailMDB implements MessageListener
- {
- ...
- }
-}}}
-so {{DefaultInterceptor}} is not invoked when invoking the {{EmailMDB.onMessage()}}
-
-
-[EmailSystemBean|src/org/jboss/tutorial/interceptor/bean/EmailSystemBean.java]'s {{noop}} method is annotated with both {{@ExcludeClassInterceptors}} and {{@ExcludeDefaultInterceptors}} and so will not get intercepted by any of these.
-
-
-{{{
- @ExcludeClassInterceptors
- @ExcludeDefaultInterceptors
- public void noop()
- {
- System.out.println("<In EmailSystemBean.noop business method");
- System.out.println("Exiting EmailSystemBean.noop business method>");
- }
-
-}}
-
-
-!!XML
-We can also exclude class and method-level interceptors within an {{interceptor-binding}} by specifying the {{exclude-class-interceptors}} and {{exclude-default-interceptors}} elements.
-{{{
- <assembly-descriptor>
- ...
- <interceptor-binding>
- <ejb-name>org.jboss.tutorial.interceptor.bean.EmailSystemBean</ejb-name>
- <exclude-class-interceptors/>
- <exclude-default-interceptors/>
- <method-name>noop2</method-name>
- </interceptor-binding>
- ...
- </assembly-descriptor>
-}}}
-
-!!!Inheritance Ordering
-If an interceptor (or bean class) inherits from another class which has a method declared to be an interceptor method, the interceptor methods from the super class will be invoked first. However, if the interceptor method in the superclass has been overridden (regardless of if the overriding method is declared to be an interceptor method or not) it is not invoked.
-
-Both [AccountsConfirmInterceptor|src/org/jboss/tutorial/interceptor/bean/AccountsConfirmInterceptor.java] and [AccountsCancelInterceptor|src/org/jboss/tutorial/interceptor/bean/AccountsCancelInterceptor.java]
-inherit from [AccountsInterceptor|src/org/jboss/tutorial/interceptor/bean/AccountsInterceptor.java].
-
-AccountsInterceptor declares the following interceptor method:
-{{{
- @AroundInvoke
- public Object intercept(InvocationContext ctx) throws Exception
- {
- System.out.println("*** AccountsInterceptor intercepting " + ctx.getMethod().getName());
- try
- {
- return ctx.proceed();
- }
- finally
- {
- System.out.println("*** AccountsInterceptor exiting");
- }
- }
-}}}
-
-This method is overridden by {{AccountsConfirmInterceptor}}, even though it is not {{AccountsConfirmInterceptor}}'s interceptor method:
-{{{
-public class AccountsConfirmInterceptor extends AccountsInterceptor
-{
- ...
- public Object intercept(InvocationContext ctx) throws Exception
- {
- //overrides AccountsInterceptor.intercept() so that will not be invoked
- return null;
- }
-
-
- @AroundInvoke
- public Object sendConfirmMessage(InvocationContext ctx) throws Exception
- {
- ...
- }
-}
-
-}}}
-
-So when invoking {{AccountsConfirmInterceptor}}, we simply invoke its {{sendConfirmMessage()}} method. {{AccountsCancelInterceptor}}, on the other hand, does not override {{AccountsInterceptor.intercept()}}, so when invoking {{AccountsCancelInterceptor}}, we first get intercepted by {{AccountsInterceptor.intercept()}} followed by {{AccountsCancelInterceptor.sendCancelMessage()}}.
-
-!!!Injection
-!!Annotations
-Just like a bean class, an interceptor can be the target of [Dependency injection|../injection/injection.html]. The format for how this works is the same, and the injection works off the same ENC as the bean to which the interceptor is bound.
-
-[AccountsConfirmInterceptor|src/org/jboss/tutorial/interceptor/bean/AccountsConfirmInterceptor.java] has dependency injection set up using annotations:
-
-{{{
-public class AccountsConfirmInterceptor extends AccountsInterceptor
-{
- @Resource(mappedName="java:ConnectionFactory")
- QueueConnectionFactory cf;
-
- @Resource(mappedName="queue/tutorial/accounts")
- Queue queue;
-
- @PersistenceContext
- EntityManager em;
-
- ...
-}}}
-
-Remember that interceptors follow the same lifecycle as the bean they are bound to. The interceptors are created at the same time as the bean instance is created, and dependecy injection occurs before the first business method is called. In the example just shown, the container;
-*looks up {{java:ConnectionFactory}}, binds it in the ENC and injects this into the field {{cf}}
-*looks up {{queue/tutorial/accounts}}, binds it in the ENC and injects this into the field {{queue}}
-*Obtains the default EntityManager injects this into the field {{em}}
-
-!!XML
-Injection can also be configured via xml, using the traditional {{ejb-ref}}, {{ejb-local-ref}}, {{resource-ref}}, {{resource-env-ref}} etc. which bind the global names. The only difference from beans is that we put this into the {{interceptors}} element defining the interceptor.
-
-{{{
- <interceptors>
- <interceptor>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</interceptor-class>
- <around-invoke-method>
- <method-name>sendCancelMessage</method-name>
- </around-invoke-method>
- <resource-ref>
- <res-ref-name>jms/ConnFactory</res-ref-name>
- <res-type>javax.jms.QueueConnectionFactory</res-type>
- <res-auth>Container</res-auth>
- <mapped-name>java:/ConnectionFactory</mapped-name>
- <injection-target>
- <injection-target-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</injection-target-class>
- <injection-target-name>cf</injection-target-name>
- </injection-target>
- </resource-ref>
- <resource-env-ref>
- <resource-env-ref-name>accountsQueue</resource-env-ref-name>
- <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
- <res-auth>Container</res-auth>
- <mapped-name>queue/tutorial/accounts</mapped-name>
- <injection-target>
- <injection-target-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</injection-target-class>
- <injection-target-name>queue</injection-target-name>
- </injection-target>
- </resource-env-ref>
- </interceptor>
- </interceptors>
-}}}
-
-*the Container looks up {{java:/ConnectionFactory}} in JNDI and creates the {{java:comp/env/jms/ConnFactory}} entry in the beans ENC, and following bean creation it injects the connction factory into AccountsCancelInterceptor's cf field.
-*the Container looks up {{queue/tutorial/accounts}} in JNDI and creates the {{java:comp/env/accountsQueue}} entry in the beans ENC, and following bean creation it injects the connction factory into AccountsCancelInterceptor's queue field.
-
-!!!Interceptor Ordering
-
-By default the ordering of interceptors when invoking a method are
-
-*External interceptors
-**Default interceptors, if present
-**Class interceptors, if present
-**Method interceptors, if present
-*Bean class interceptor method
-
-Within each group (default, class, method) the order of the interceptors are from left to right as defined in the @Interceptors annotation, and then the xml interceptors.
-
-!!Overriding interceptor ordering
-You can override the default sort order of the external interceptors by specifiying an {{interceptor-binding}} with an {{interceptor-order}} specifying the order of the interceptors
-{{{
- <assembly-descriptor>
- ...
- <interceptor-binding>
- <ejb-name>org.jboss.tutorial.interceptor.bean.EmailSystemBean</ejb-name>
- <method-name>sendBookingCancellationMessage</method-name>
- <interceptor-order>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.AccountsCancelInterceptor</interceptor-class>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.DefaultInterceptor</interceptor-class>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.OtherInterceptor</interceptor-class>
- <interceptor-class>org.jboss.tutorial.interceptor.bean.TracingInterceptor</interceptor-class>
- </interceptor-order>
- </interceptor-binding>
- </assembly-descriptor>
-
-}}}
-
-So when invoking {{EmailSystemBean.sendBookingCancellationMessage}} we will get the following interception order, quite different from the default sort order
-*AccountsCancelInterceptor (method-level)
-*DefaultInterceptor (default interceptor)
-*OtherInterceptor (2nd class-level interceptor)
-*TracingInterceptor(1st class-level interceptor)
-
-!InvocationContext
-As you have seen the @AroundInvoke annotated interceptor methods all take a parameter of type {{javax.ejb.InvocationContext}}.
-The definition of InvocationContext is:
-{{{
- package javax.ejb;
-
- public interface InvocationContext {
- public Object getBean();
- public java.lang.reflect.Method getMethod();
- public Object[] getParameters();
- public void setParameters(Object[] params);
- public java.util.Map getContextData();
- public Object proceed() throws Exception;
- }
-}}}
-
-*{{getBean()}} - returns the bean instance on which we are calling a method
-*{{getMethod()}} - returns the method we are calling on the bean instance
-*{{getParameters()}} - returns the parameters for the method call
-*{{setParameters()}} - allows you to modify the parameters for the method call
-*{{getContextData}} - The EJB interceptions are stateless, but the same InvocationContext instance is used for each interceptor method in a chain. If you want to pass values between interceptor methods in the business method invocation you can store them in the Map retured by getContextData().
-*{{proceed}} - As discussed, invokes the next interceptor, or if we are in the last interceptor invokes the target bean method.
-
-In some case we might want access to the EJBContext, this can be injected into the interceptor instance using the {{@Resource}} annotation.The AroundInvoke methods share the JNDI name space of the bean for whose methods they are invoked and execute within the same transaction and security context as the business methods for which they are invoked.
-
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-}}}
-
-Look at the JBoss console window to see the output of the interceptions taking place, the EmailMDB and AccountsMDB might occur in slightly different places since they execute asynchronously
-
-{{{
-17:34:54,468 INFO [EJB3Deployer] Deployed: file:/C:/cygwin/home/Kabir/cvs/jboss-head/build/output/jboss-5.0.0alpha/server/all/dep
-loy/tutorial.jar
-}}}
-
-Calling EmailSystemBean.emailLostPassword()
-{{{
-17:35:02,328 INFO [STDOUT] *** DefaultInterceptor intercepting emailLostPassword
-17:35:02,328 INFO [STDOUT] *** TracingInterceptor intercepting emailLostPassword
-17:35:02,328 INFO [STDOUT] *** OtherInterceptor intercepting emailLostPassword
-17:35:02,328 INFO [STDOUT] *** EmailSystemBean.myBeanInterceptor - username: whatever
-17:35:02,328 INFO [STDOUT] <In EmailSystemBean.emailLostPassword business method
-17:35:05,343 INFO [STDOUT] Message sent successfully to remote queue.
-17:35:05,343 INFO [STDOUT] Exiting EmailSystemBean.emailLostPassword business method>
-17:35:05,343 INFO [STDOUT] *** OtherInterceptor exiting
-17:35:05,343 INFO [STDOUT] *** TracingInterceptor invocation of org.jboss.tutorial.interceptor.bean.EmailSystemBean.emailLostPass
-word() took 3015ms
-17:35:05,375 INFO [STDOUT] *** EmailMDB.mdbInterceptor intercepting
-17:35:05,375 INFO [STDOUT]
-----------------
-EMailMDB - Got message, sending email
-----------------
-17:35:05,375 INFO [STDOUT] *** DefaultInterceptor exiting
-}}}
-
-Calling EmailSystemBean.sendBookingConfirmationMessage()
-{{{
-17:35:07,421 INFO [STDOUT] *** DefaultInterceptor intercepting sendBookingConfirmationMessage
-17:35:07,421 INFO [STDOUT] *** TracingInterceptor intercepting sendBookingConfirmationMessage
-17:35:07,437 INFO [STDOUT] *** OtherInterceptor intercepting sendBookingConfirmationMessage
-17:35:07,437 INFO [STDOUT] *** AccountsConfirmInterceptor intercepting
-17:35:07,437 INFO [STDOUT] *** AccountsConfirmInterceptor - recording confirmation
-17:35:07,437 INFO [STDOUT] *** AccountsConfirmInterceptor - notifying accounts dept sendBookingConfirmationMessage
-17:35:07,437 INFO [STDOUT] <In EmailSystemBean.sendBookingConfirmationMessage business method
-17:35:07,453 INFO [STDOUT] *** DefaultInterceptor intercepting onMessage
-17:35:07,453 INFO [STDOUT]
-----------------
-AccountsMDB - Got message Confirming order 100
-----------------
-17:35:07,453 INFO [STDOUT] *** DefaultInterceptor exiting
-17:35:10,468 INFO [STDOUT] Message sent successfully to remote queue.
-17:35:10,468 INFO [STDOUT] Exiting EmailSystemBean.sendBookingConfirmationMessage business method>
-17:35:10,468 INFO [STDOUT] *** AccountsConfirmInterceptor exiting
-17:35:10,468 INFO [STDOUT] *** OtherInterceptor exiting
-17:35:10,468 INFO [STDOUT] *** TracingInterceptor invocation of org.jboss.tutorial.interceptor.bean.EmailSystemBean.sendBookingCo
-nfirmationMessage() took 3031ms
-17:35:10,468 INFO [STDOUT] *** DefaultInterceptor exiting
-17:35:10,468 INFO [STDOUT] *** EmailMDB.mdbInterceptor intercepting
-17:35:10,468 INFO [STDOUT]
-----------------
-EMailMDB - Got message, sending email
-----------------
-}}}
-Calling EmailSystemBean.sendBookingConfirmationMessage(), this will be aborted
-{{{
-17:35:12,484 INFO [STDOUT] *** DefaultInterceptor intercepting sendBookingConfirmationMessage
-17:35:12,484 INFO [STDOUT] *** TracingInterceptor intercepting sendBookingConfirmationMessage
-17:35:12,484 INFO [STDOUT] *** OtherInterceptor intercepting sendBookingConfirmationMessage
-17:35:12,484 INFO [STDOUT] *** AccountsConfirmInterceptor intercepting
-17:35:12,484 INFO [STDOUT] *** AccountsConfirmInterceptor - order has already been confirmed aborting
-17:35:12,500 INFO [STDOUT] *** AccountsConfirmInterceptor exiting
-17:35:12,500 INFO [STDOUT] *** OtherInterceptor exiting
-17:35:12,500 INFO [STDOUT] *** TracingInterceptor invocation of org.jboss.tutorial.interceptor.bean.EmailSystemBean.sendBookingCo
-nfirmationMessage() took 16ms
-17:35:12,500 INFO [STDOUT] *** DefaultInterceptor exiting
-}}}
-Calling EmailSystemBean.sendBookingCancellationMessage(), this will be aborted
-{{{
-17:35:14,500 INFO [STDOUT] *** AccountsInterceptor intercepting sendBookingCancellationMessage
-17:35:14,500 INFO [STDOUT] *** AccountsCancelInterceptor intercepting sendBookingCancellationMessage
-17:35:14,500 INFO [STDOUT] *** AccountsConfirmInterceptor - notifying accounts dept
-17:35:14,500 INFO [STDOUT] *** DefaultInterceptor intercepting sendBookingCancellationMessage
-17:35:14,515 INFO [STDOUT] *** OtherInterceptor intercepting sendBookingCancellationMessage
-17:35:14,515 INFO [STDOUT] *** TracingInterceptor intercepting sendBookingCancellationMessage
-17:35:14,515 INFO [STDOUT] <In EmailSystemBean.sendBookingCancellationMessage business method
-17:35:14,515 INFO [STDOUT] *** DefaultInterceptor intercepting onMessage
-17:35:14,515 INFO [STDOUT]
-----------------
-AccountsMDB - Got message Cancelling order 100
-----------------
-17:35:14,515 INFO [STDOUT] *** DefaultInterceptor exiting
-17:35:17,625 INFO [STDOUT] Message sent successfully to remote queue.
-17:35:17,625 INFO [STDOUT] Exiting EmailSystemBean.sendBookingCancellationMessage business method>
-17:35:17,625 INFO [STDOUT] *** TracingInterceptor invocation of org.jboss.tutorial.interceptor.bean.EmailSystemBean.sendBookingCa
-ncellationMessage() took 3110ms
-17:35:17,625 INFO [STDOUT] *** OtherInterceptor exiting
-17:35:17,625 INFO [STDOUT] *** DefaultInterceptor exiting
-17:35:17,625 INFO [STDOUT] *** AccountsCancelInterceptor exiting
-17:35:17,640 INFO [STDOUT] *** AccountsInterceptor exiting
-17:35:17,640 INFO [STDOUT] *** EmailMDB.mdbInterceptor intercepting
-17:35:17,640 INFO [STDOUT]
-----------------
-EMailMDB - Got message, sending email
-----------------
-}}}
-Calling EmailSystemBean.noop()
-
-{{{
-17:35:19,640 INFO [STDOUT] <In EmailSystemBean.noop business method
-17:35:19,640 INFO [STDOUT] Exiting EmailSystemBean.noop business method>
-}}}
-Calling EmailSystemBean.noop2()
-{{{
-17:35:21,640 INFO [STDOUT] <In EmailSystemBean.noop2 business method
-17:35:21,640 INFO [STDOUT] Exiting EmailSystemBean.noop2 business method>
-}}}
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/jndibinding/jndi.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/jndibinding/jndi.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/jndibinding/jndi.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,79 +0,0 @@
-<html>
-<body>
-<p>
-<h4>JNDI Bindings</h4>
-
-By default, session beans will bind to JNDI in the form <tt>ejbName/remote</tt> for remote interfaces and <tt>ejbName/local</tt> in the case of local interfaces. When
-the EJBs are deployed in an .ear file, the default jndi binding will be prepended by the name of the .ear file. So if the ear file name is <tt>foo.ear</tt> the default jndi names would be <tt>foo/EJB-NAME/remote</tt> and <tt>foo/EJB-NAME/local</tt>. You can override this behavior
-by defining your own <tt>@org.jboss.ejb3.LocalBinding</tt> or <tt>@org.jboss.ejb3.remoting.RemoteBinding</tt>.
-</p><p>
-</p><p>
-<h4>Local Interface JNDI Binding.</h4>
-
-To change the JNDI name for your local interface use the <tt>org.jboss.ejb3.LocalBinding</tt> annotation.
-</p><p>
-<pre>
- at Stateless
- at LocalBinding(jndiBinding="custom/MySession")
-public class MySessionBean implements MySession
-{
-}
-</pre>
-</p><p>
-</p><p>
-<h4>Remote Interface JNDI Binding</h4>
-
-To change the JNDI name for your remote interface use the <tt>org.jboss.ejb3.RemoteBindings</tt> annotation.
-</p><p>
-<pre>
- at Stateless
- at RemoteBinding(jndiName="custom/remote/MySession")
-public class MySessionBean implements MySession
-{
-}
-</pre>
-</p><p>
-<h4>Persistence unit JNDI Bindings</h4>
-
-Persistence units are not bound into JNDI by default. You can bind them by defining some jboss specific
-properties in persistence.xml.
-<pre>
- <persistence>
- <persistence-unit name="manager1">
- <jta-data-source>java:/DefaultDS</jta-data-source>
- <jar-file>MyApp.jar</jar-file>
- <class>org.acme.Employee</class>
- <class>org.acme.Person</class>
- <class>org.acme.Address</class>
- <properties>
- <property name="jboss.entity.manager.jndi.name" value="java:/Manager1"/>
- <property name="jboss.entity.manager.factory.jndi.name" value="java:/Manager1Factory"/>
- </properties>
- </persistence-unit>
- </persistence>
-</pre>
-</p><p>
-<h4>Client</h4>
-
-Open up <a href="src/org/jboss/tutorial/jndibinding/client/Client.java">Client.java</a>. You'll see that it looks up the stateless bean under "Calculator". Also notice that there is no Home interface and you can begin executing on the stateless bean right away.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 1 + 1 = 2
- [java] 1 - 1 = 0
-</pre>
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the CalculatorBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/jndibinding/jndi.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/jndibinding/jndi.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/jndibinding/jndi.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,66 +0,0 @@
-!JNDI Bindings
-By default, session beans will bind to JNDI in the form {{ejbName/remote}} for remote interfaces and {{ejbName/local}} in the case of local interfaces. When
-the EJBs are deployed in an .ear file, the default jndi binding will be prepended by the name of the .ear file. So if the ear file name is {{foo.ear}} the default jndi names would be {{foo/EJB-NAME/remote}} and {{foo/EJB-NAME/local}}. You can override this behavior
-by defining your own {{@org.jboss.ejb3.LocalBinding}} or {{@org.jboss.ejb3.remoting.RemoteBinding}}.
-
-
-!Local Interface JNDI Binding.
-To change the JNDI name for your local interface use the {{org.jboss.ejb3.LocalBinding}} annotation.
-
-{{{
- at Stateless
- at LocalBinding(jndiBinding="custom/MySession")
-public class MySessionBean implements MySession
-{
-}
-}}}
-
-
-!Remote Interface JNDI Binding
-To change the JNDI name for your remote interface use the {{org.jboss.ejb3.RemoteBindings}} annotation.
-
-{{{
- at Stateless
- at RemoteBinding(jndiName="custom/remote/MySession")
-public class MySessionBean implements MySession
-{
-}
-}}}
-
-!Persistence unit JNDI Bindings
-Persistence units are not bound into JNDI by default. You can bind them by defining some jboss specific
-properties in persistence.xml.
-{{{
- <persistence>
- <persistence-unit name="manager1">
- <jta-data-source>java:/DefaultDS</jta-data-source>
- <jar-file>MyApp.jar</jar-file>
- <class>org.acme.Employee</class>
- <class>org.acme.Person</class>
- <class>org.acme.Address</class>
- <properties>
- <property name="jboss.entity.manager.jndi.name" value="java:/Manager1"/>
- <property name="jboss.entity.manager.factory.jndi.name" value="java:/Manager1Factory"/>
- </properties>
- </persistence-unit>
- </persistence>
-}}}
-
-!Client
-Open up [Client.java|src/org/jboss/tutorial/jndibinding/client/Client.java]. You'll see that it looks up the stateless bean under "Calculator". Also notice that there is no Home interface and you can begin executing on the stateless bean right away.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 1 + 1 = 2
- [java] 1 - 1 = 0
-}}}
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the CalculatorBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
Deleted: projects/ejb3/trunk/docs/tutorial/joininheritance/join.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/joininheritance/join.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/joininheritance/join.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,102 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Inheritance: Join Strategy</h2>
-
-The EJB specification allows you to define entities that inherit from one another. The inheritance relationships can be reflected in
-queries as well. So, if you queried based on the base class, the query is polymorphic.
-</p><p>
-The tutorial example uses the join table strategy to map an inheritance relationship of <a href="src/org/jboss/tutorial/joininheritance/bean/Pet.java">Pet</a>, which is the base class for <a href="src/org/jboss/tutorial/joininheritance/bean/Cat.java">Cat</a> and <a href="src/org/jboss/tutorial/joininheritance/bean/Dog.java">Dog</a>.
-</p><p>
-With the join table strategy there is a table per class in the hierarchy, but the subclass tables only have the extra attribute they define in their subclass.
-A discriminator column is <i>NOT</i> required to differentiate between which class type is persisted in a particular row unlike the
-single table mapping. The persistence manager does not need a discrimiator column to figure out the type.
-</p><p>
-This is what the annotations look like for Pet.
-</p><p>
-<pre>
- at Entity
- at Inheritance(strategy = InheritanceType.JOINED)
-public class Pet implements java.io.Serializable
-{
-</pre>
-</p><p>
-<pre>
- at Entity
- at Inheritance(strategy = InheritanceType.JOINED)
-public class Dog extends Pet
-{
-</pre>
-</p><p>
-<h4>Polymorphic Queries</h4>
-
-<a href="src/org/jboss/tutorial/joininheritance/bean/PetDAOBean.java">PetDAOBean</a> stateless EJB wraps some polymorphic queries.
-</p><p>
-<pre>
- public List findByWeight(double weight)
- {
- return manager.createQuery("from Pet p where p.weight < :weight").setParameter("weight", weight).getResultList();
- }
-</pre>
-</p><p>
-Even though the <tt>findByWeight</tt> method queries on Pet, either Dog or Cat instances can be returned.
-</p><p>
-<h4>Table mapping</h4>
-
-The table mapping for this example looks like this:
-</p><p>
-<pre>
-create table PET (
- ID integer primary key,
- ANIMAL_TYPE varchar,
- NAME varchar,
- WEIGHT double
-);
-
-create table CAT (
- ID integer primary key,
- LIVES int
-);
-
-create table DOG (
- ID integer primary key,
- NUMBONES int
-);
-</pre>
-</p><p>
-To load subclasses the persistence manager must before a SQL join. This is less efficient than the single table strategy as the SQL query is more complicated.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-07 00:16:20,395 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Sox
- [java] Junior
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>View the tables and rows</h4>
-
-You can view the tables created by JBoss by going to the <a href="http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB">Hypersonic SQL service</a>, scrolling down to the <tt>startDatabaseManager</tt> button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/joininheritance/join.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/joininheritance/join.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/joininheritance/join.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,90 +0,0 @@
-!!!Inheritance: Join Strategy
-The EJB specification allows you to define entities that inherit from one another. The inheritance relationships can be reflected in
-queries as well. So, if you queried based on the base class, the query is polymorphic.
-
-The tutorial example uses the join table strategy to map an inheritance relationship of [Pet|src/org/jboss/tutorial/joininheritance/bean/Pet.java], which is the base class for [Cat|src/org/jboss/tutorial/joininheritance/bean/Cat.java] and [Dog|src/org/jboss/tutorial/joininheritance/bean/Dog.java].
-
-With the join table strategy there is a table per class in the hierarchy, but the subclass tables only have the extra attribute they define in their subclass.
-A discriminator column is ''NOT'' required to differentiate between which class type is persisted in a particular row unlike the
-single table mapping. The persistence manager does not need a discrimiator column to figure out the type.
-
-This is what the annotations look like for Pet.
-
-{{{
- at Entity
- at Inheritance(strategy = InheritanceType.JOINED)
-public class Pet implements java.io.Serializable
-{
-}}}
-
-{{{
- at Entity
- at Inheritance(strategy = InheritanceType.JOINED)
-public class Dog extends Pet
-{
-}}}
-
-!Polymorphic Queries
-[PetDAOBean|src/org/jboss/tutorial/joininheritance/bean/PetDAOBean.java] stateless EJB wraps some polymorphic queries.
-
-{{{
- public List findByWeight(double weight)
- {
- return manager.createQuery("from Pet p where p.weight < :weight").setParameter("weight", weight).getResultList();
- }
-}}}
-
-Even though the {{findByWeight}} method queries on Pet, either Dog or Cat instances can be returned.
-
-!Table mapping
-The table mapping for this example looks like this:
-
-{{{
-create table PET (
- ID integer primary key,
- ANIMAL_TYPE varchar,
- NAME varchar,
- WEIGHT double
-);
-
-create table CAT (
- ID integer primary key,
- LIVES int
-);
-
-create table DOG (
- ID integer primary key,
- NUMBONES int
-);
-}}}
-
-To load subclasses the persistence manager must before a SQL join. This is less efficient than the single table strategy as the SQL query is more complicated.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-07 00:16:20,395 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Sox
- [java] Junior
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!View the tables and rows
-You can view the tables created by JBoss by going to the [Hypersonic SQL service|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB], scrolling down to the {{startDatabaseManager}} button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-
-
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/mdb/mdb.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/mdb/mdb.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/mdb/mdb.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,99 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Message Drive Beans</h2>
-
-</p><p>
-<h3>The MDB</h3>
-
-This example shows you how to implement an MDB with EJB 3.0 using annotations.
-</p><p>
-Take a look at <a href="src/org/jboss/tutorial/mdb/bean/ExampleMDB.java">ExampleMDB.java</a>. The @MessageDriven
-annotation defines the bean as an MDB. The <tt>activationConfig</tt> attribute contains much of the
-MDB configuration via @ActivationConfigProperty annotations. Also notice that the MDB source contains
-properties for <tt>destinationType</tt> and <tt>destination</tt>.
-</p><p>
-The following is the list of standard Activation Config Properties available from the JCA1.5
-specification. Also listed are the respective types and default values where defined.
-</p><p>
-<pre>
-String destination - the jndi name of the Queue or Topic - MANDATORY
-String destinationType - the type of destination valid values are javax.jms.Queue or javax.jms.Topic
-String messageSelector - the message selector of the subscription
-int acknowledgeMode - the type of acknowledgement when not using transacted jms - valid values AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - default is AUTO_ACKNOWLEDGE
-String clientID - the client id of the connection
-boolean subscriptionDurability - whether topic subscriptions are durable - valid values Durable or NonDurable - default is NonDurable
-String subscriptionName - the subsription name of the topic subscription
-</pre>
-</p><p>
-The following is the list of Activation Config Properties available as JBoss extensions.
-Also listed are the respective types and default values where defined.
-</p><p>
-<pre>
-boolean isTopic - sets the destinationType - default is false
-String providerAdapterJNDI - the jndi name of the jms provider - default java:/DefaultJMSProvider
-String user - the user id used to connect to the jms server
-String pass - the password of the user
-int maxMessages - read this number of messages before delivering messages to the mdb (each message is delivered individually on the same thread in an attempt to avoid context excessive context switching) - default 1
-int minSession - the minimum number of jms sessions that are available to concurrently deliver messages to this mdb - default 1
-int maxSession - the maximum number of jms sessions that can concurrently deliver messages to this mdb - default 15
-long reconnectInterval - the length of time in seconds between attempts to (re-)connect to the jms provider - default 10 seconds
-long keepAlive - the length of time in milliseconds that sessions over the minimum are kept alive - default is 60 seconds
-booleam sessionTransacted - whether the sessions are transacted - default is true
-boolean useDLQ - whether to use a DLQ handler - valid values true or false - default is true
-String dLQJNDIName - the JNDI name of the DLQ - default is "queue/DLQ"
-String dLQHandler - the org.jboss.resource.adapter.jms.inflow.DLQHandler implementation class name - default org.jboss.resource.adapter.jms.inflow.dlq.GenericDLQHandler
-int dLQMaxResent - the maximum number of times a message is redelivered before it is sent to the DLQ - default 5
-String dLQUser - the user id used to make the dlq connection to the jms server
-String dLQPassword - the password of the DLQUser
-String dLQClientID - the client id of the dlq connection - default is null
-boolean redeliverUnspecified - whether to attempt to redeliver a message in an unspecified transaction context - default is true
-int transactionTimeout - time in seconds for the transaction timeout - default is the timeout set for the resource manager
-</pre>
-</p><p>
-<h3> The Destination</h3>
-
-The <a href="queue-example-service.xml">queue-example-service.xml</a> file defines the Queues. There are no changes for deploying
-an EJB3 ready Destination as a standard Destination.
-</p><p>
-<h3> Configuring Default MDB Properties</h3>
-
-You can configure MDBs to have default properties using the @DefaultActivationSpecs annotations. Take a
-look at <a href="custom-ejb3-interceptors-aop.xml">custom-ejb3-interceptors-aop.xml</a>. Here we define a custom
-container configuration domain, "Custom Message Driven Bean", that adds a @DefaultActivationSpecs
-annotation and <tt>destinationType</tt> and <tt>destination</tt> properties to each MDB using this domain.
-Now take a look at <a href="src/org/jboss/tutorial/mdb/bean/DefaultedExampleMDB.java">DefaultedExampleMDB.java</a>.
-The MDB is configured to use the "Custom Message Driven Bean" container configuration domain via the
- at AspectDomain annotation. Note there are no properties defined in the @MessageDriven annotation (they
-are all from the defaults).
-</p><p>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-</pre>
-</p><p>
-Look in the console window to determine that the messages was sent and received.
-</p><p>
-<pre>
-09:43:35,893 INFO [STDOUT] ----------------
-09:43:35,894 INFO [STDOUT] ----------------
-09:43:35,894 INFO [STDOUT] Received message
-09:43:35,894 INFO [STDOUT] Received defaulted message
-09:43:35,894 INFO [STDOUT] ----------------
-09:43:35,894 INFO [STDOUT] ----------------
-
-</pre>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/mdb/mdb.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/mdb/mdb.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/mdb/mdb.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,88 +0,0 @@
-!!!Message Drive Beans
-
-!!The MDB
-This example shows you how to implement an MDB with EJB 3.0 using annotations.
-
-Take a look at [ExampleMDB.java|src/org/jboss/tutorial/mdb/bean/ExampleMDB.java]. The @MessageDriven
-annotation defines the bean as an MDB. The {{activationConfig}} attribute contains much of the
-MDB configuration via @ActivationConfigProperty annotations. Also notice that the MDB source contains
-properties for {{destinationType}} and {{destination}}.
-
-The following is the list of standard Activation Config Properties available from the JCA1.5
-specification. Also listed are the respective types and default values where defined.
-
-{{{
-String destination - the jndi name of the Queue or Topic - MANDATORY
-String destinationType - the type of destination valid values are javax.jms.Queue or javax.jms.Topic
-String messageSelector - the message selector of the subscription
-int acknowledgeMode - the type of acknowledgement when not using transacted jms - valid values AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - default is AUTO_ACKNOWLEDGE
-String clientID - the client id of the connection
-boolean subscriptionDurability - whether topic subscriptions are durable - valid values Durable or NonDurable - default is NonDurable
-String subscriptionName - the subsription name of the topic subscription
-}}}
-
-The following is the list of Activation Config Properties available as JBoss extensions.
-Also listed are the respective types and default values where defined.
-
-{{{
-boolean isTopic - sets the destinationType - default is false
-String providerAdapterJNDI - the jndi name of the jms provider - default java:/DefaultJMSProvider
-String user - the user id used to connect to the jms server
-String pass - the password of the user
-int maxMessages - read this number of messages before delivering messages to the mdb (each message is delivered individually on the same thread in an attempt to avoid context excessive context switching) - default 1
-int minSession - the minimum number of jms sessions that are available to concurrently deliver messages to this mdb - default 1
-int maxSession - the maximum number of jms sessions that can concurrently deliver messages to this mdb - default 15
-long reconnectInterval - the length of time in seconds between attempts to (re-)connect to the jms provider - default 10 seconds
-long keepAlive - the length of time in milliseconds that sessions over the minimum are kept alive - default is 60 seconds
-booleam sessionTransacted - whether the sessions are transacted - default is true
-boolean useDLQ - whether to use a DLQ handler - valid values true or false - default is true
-String dLQJNDIName - the JNDI name of the DLQ - default is "queue/DLQ"
-String dLQHandler - the org.jboss.resource.adapter.jms.inflow.DLQHandler implementation class name - default org.jboss.resource.adapter.jms.inflow.dlq.GenericDLQHandler
-int dLQMaxResent - the maximum number of times a message is redelivered before it is sent to the DLQ - default 5
-String dLQUser - the user id used to make the dlq connection to the jms server
-String dLQPassword - the password of the DLQUser
-String dLQClientID - the client id of the dlq connection - default is null
-boolean redeliverUnspecified - whether to attempt to redeliver a message in an unspecified transaction context - default is true
-int transactionTimeout - time in seconds for the transaction timeout - default is the timeout set for the resource manager
-}}}
-
-!! The Destination
-The [queue-example-service.xml|queue-example-service.xml] file defines the Queues. There are no changes for deploying
-an EJB3 ready Destination as a standard Destination.
-
-!! Configuring Default MDB Properties
-You can configure MDBs to have default properties using the @DefaultActivationSpecs annotations. Take a
-look at [custom-ejb3-interceptors-aop.xml|custom-ejb3-interceptors-aop.xml]. Here we define a custom
-container configuration domain, "Custom Message Driven Bean", that adds a @DefaultActivationSpecs
-annotation and {{destinationType}} and {{destination}} properties to each MDB using this domain.
-Now take a look at [DefaultedExampleMDB.java|src/org/jboss/tutorial/mdb/bean/DefaultedExampleMDB.java].
-The MDB is configured to use the "Custom Message Driven Bean" container configuration domain via the
- at AspectDomain annotation. Note there are no properties defined in the @MessageDriven annotation (they
-are all from the defaults).
-
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-}}}
-
-Look in the console window to determine that the messages was sent and received.
-
-{{{
-09:43:35,893 INFO [STDOUT] ----------------
-09:43:35,894 INFO [STDOUT] ----------------
-09:43:35,894 INFO [STDOUT] Received message
-09:43:35,894 INFO [STDOUT] Received defaulted message
-09:43:35,894 INFO [STDOUT] ----------------
-09:43:35,894 INFO [STDOUT] ----------------
-
-}}}
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/mdb_deployment_descriptor/mdb.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/mdb_deployment_descriptor/mdb.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/mdb_deployment_descriptor/mdb.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,43 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Message Drive Beans</h2>
-
-This example shows you how to implement an MDB with EJB 3.0.
-</p><p>
-</p><p>
-You configure properties by using the <message-driven> element and sub elements which correspond to the @ActivationConfigProperty annotation. All
-properties that you can set are defined in the <a href="META-INF/ejb-jar.xml">ejb-jar.xml</a> and
-<a href="META-INF/jboss.xml">jboss.xml</a> deployment descriptors.
-</p><p>
-<a href="http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/main/org/jboss/ejb3/mdb/MDBConfig.java?rev=1.1&view=markup">MDBConfig.java</a>
-</p><p>
-Take a look at <a href="src/org/jboss/tutorial/mdb_deployment_descriptor/bean/ExampleMDB.java">ExampleMDB.java</a>.
-</p><p>
-The <a href="queue-example-service.xml">queue-example-service.xml</a> file defines the queue. This is the same in regular JBoss.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-</pre>
-</p><p>
-Look in the console window to determine that the message was sent.
-</p><p>
-<pre>
-01:01:20,828 INFO [STDOUT] ----------------
-01:01:20,828 INFO [STDOUT] Received message
-01:01:20,828 INFO [STDOUT] ----------------
-</pre>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/mdb_deployment_descriptor/mdb.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/mdb_deployment_descriptor/mdb.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/mdb_deployment_descriptor/mdb.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,35 +0,0 @@
-!!!Message Drive Beans
-This example shows you how to implement an MDB with EJB 3.0.
-
-
-You configure properties by using the <message-driven> element and sub elements which correspond to the @ActivationConfigProperty annotation. All
-properties that you can set are defined in the [ejb-jar.xml|META-INF/ejb-jar.xml] and
-[jboss.xml|META-INF/jboss.xml] deployment descriptors.
-
-[MDBConfig.java|http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-ejb3/src/main/org/jboss/ejb3/mdb/MDBConfig.java?rev=1.1&view=markup]
-
-Take a look at [ExampleMDB.java|src/org/jboss/tutorial/mdb_deployment_descriptor/bean/ExampleMDB.java].
-
-The [queue-example-service.xml|queue-example-service.xml] file defines the queue. This is the same in regular JBoss.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-}}}
-
-Look in the console window to determine that the message was sent.
-
-{{{
-01:01:20,828 INFO [STDOUT] ----------------
-01:01:20,828 INFO [STDOUT] Received message
-01:01:20,828 INFO [STDOUT] ----------------
-}}}
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/merge/merge.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/merge/merge.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/merge/merge.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,85 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Merging and Basic Queries</h2>
-
-This example shows a bunch of things. First, it introduces the <tt>@Column</tt> annotation. It also shows how entities can be detached and reattached to persistence storage using the <tt>EntityManager.merge()</tt>. It also shows some basic queries.
-</p><p>
-<h4>@Column</h4>
-
-EJB 3.0 has a complete Object/Relational mapping. You can use the <tt>@Column</tt> annotation to specify which column in the table your property should map to.
-</p><p>
-Take a look at the <a href="src/org/jboss/tutorial/merge/bean/Customer.java">Customer</a> entity.
-</p><p>
-<pre>
- @Column(name = "FIRST")
- public String getFirst()
- {
- return first;
- }
-</pre>
-</p><p>
-<h4>Find by primary key</h4>
-
-The <tt>EntityManager</tt> service has a built in find by primary key method: <tt><T> find(Class<T>, Object pk)</tt>. The <a href="src/org/jboss/tutorial/merge/bean/CustomerDAOBean.java">CustomerDAOBean</a> stateless EJB's <tt>find()</tt> method wrapps remote calls to the EntityManager.
-</p><p>
-<pre>
- public Customer find(int id)
- {
- return manager.find(Customer.class, id);
- }
-</pre>
-</p><p>
-<h4>Queries</h4>
-
-<tt>EntityManager</tt> allows you to create query objects on the fly that can be reused over and over, or just one time. Also, queries also support named parameters now. The <a href="src/org/jboss/tutorial/merge/bean/CustomerDAOBean.java">CustomerDAOBean</a> reflects this usage in the <tt>findByLastName</tt> method.
-</p><p>
-<pre>
- public List findByLastName(String name)
- {
- return manager.createQuery("from Customer c where c.last = :name").setParameter("name", name).getResultList();
- }
-</pre>
-</p><p>
-<h4>Merging</h4>
-
-The Value Object pattern is built into EJB 3.0. You can detach an object from persistence storage and send it across the network to the client.
-The client can make updates locally to the object, send it back to the server and the changes can be merged/synchronized back
-to the database using the <tt>EntityManager.merge()</tt> method. This is exactly what the <a href="src/org/jboss/tutorial/merge/client/Client.java">Client</a> does.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Create Bill Burke and Monica Smith
- [java] 2004-10-06 22:27:50,344 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Bill and Monica get married
- [java] Get all the Burkes
- [java] There are now 2 Burkes
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>View the tables and rows</h4>
-
-You can view the tables created by JBoss by going to the <a href="http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB">Hypersonic SQL service</a>, scrolling down to the <tt>startDatabaseManager</tt> button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/merge/merge.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/merge/merge.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/merge/merge.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,71 +0,0 @@
-!!!Merging and Basic Queries
-This example shows a bunch of things. First, it introduces the {{@Column}} annotation. It also shows how entities can be detached and reattached to persistence storage using the {{EntityManager.merge()}}. It also shows some basic queries.
-
-!@Column
-EJB 3.0 has a complete Object/Relational mapping. You can use the {{@Column}} annotation to specify which column in the table your property should map to.
-
-Take a look at the [Customer|src/org/jboss/tutorial/merge/bean/Customer.java] entity.
-
-{{{
- @Column(name = "FIRST")
- public String getFirst()
- {
- return first;
- }
-}}}
-
-!Find by primary key
-The {{EntityManager}} service has a built in find by primary key method: {{<T> find(Class<T>, Object pk)}}. The [CustomerDAOBean|src/org/jboss/tutorial/merge/bean/CustomerDAOBean.java] stateless EJB's {{find()}} method wrapps remote calls to the EntityManager.
-
-{{{
- public Customer find(int id)
- {
- return manager.find(Customer.class, id);
- }
-}}}
-
-!Queries
-{{EntityManager}} allows you to create query objects on the fly that can be reused over and over, or just one time. Also, queries also support named parameters now. The [CustomerDAOBean|src/org/jboss/tutorial/merge/bean/CustomerDAOBean.java] reflects this usage in the {{findByLastName}} method.
-
-{{{
- public List findByLastName(String name)
- {
- return manager.createQuery("from Customer c where c.last = :name").setParameter("name", name).getResultList();
- }
-}}}
-
-!Merging
-The Value Object pattern is built into EJB 3.0. You can detach an object from persistence storage and send it across the network to the client.
-The client can make updates locally to the object, send it back to the server and the changes can be merged/synchronized back
-to the database using the {{EntityManager.merge()}} method. This is exactly what the [Client|src/org/jboss/tutorial/merge/client/Client.java] does.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Create Bill Burke and Monica Smith
- [java] 2004-10-06 22:27:50,344 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Bill and Monica get married
- [java] Get all the Burkes
- [java] There are now 2 Burkes
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!View the tables and rows
-You can view the tables created by JBoss by going to the [Hypersonic SQL service|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB], scrolling down to the {{startDatabaseManager}} button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-
-
-
-
-
-
Modified: projects/ejb3/trunk/docs/tutorial/pom.xml
===================================================================
--- projects/ejb3/trunk/docs/tutorial/pom.xml 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/pom.xml 2009-01-22 10:07:10 UTC (rev 83262)
@@ -87,9 +87,9 @@
invoked, there's a Java Shutdownhook in the jbossas-server-manager which cleanly
shuts down the JBossAS -->
<module>init</module>
-
+
<!-- The tutorials go here -->
-
+
<module>asynch</module>
<module>blob</module>
<module>cachedentity</module>
@@ -106,6 +106,7 @@
<module>injection</module>
<module>interceptor</module>
<module>jboss_deployment_descriptor</module>
+ <module>jca_inflow_quartz</module>
<module>jndibinding</module>
<module>joininheritance</module>
<module>mdb</module>
@@ -117,16 +118,18 @@
<module>secondary</module>
<module>security</module>
<module>service</module>
+ <module>service_deployment_descriptor</module>
<module>singleinheritance</module>
<module>ssl</module>
<module>stateful</module>
<module>stateful_deployment_descriptor</module>
<module>stateless</module>
<module>stateless_deployment_descriptor</module>
+ <module>tableperinheritance</module>
<module>timer</module>
<module>webservice</module>
+
-
<!-- Responsible for JBossAS shutdown -->
<module>shutdown</module>
Deleted: projects/ejb3/trunk/docs/tutorial/relationships/relationships.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/relationships/relationships.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/relationships/relationships.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,84 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Relationships</h2>
-
-The entity tutorial only showed one-to-many and many-to-one relationships. This tutorial will show you one-to-one and many-to-many relationships.
-</p><p>
-</p><p>
-<h4>One to One</h4>
-
-There is a unidirectional one to one relationship defined between the <a href="src/org/jboss/tutorial/relationships/bean/Customer.java">Customer</a> and <a href="src/org/jboss/tutorial/relationships/bean/Address.java">Address</a>. Customer defines the uni directional relationship.
-</p><p>
-<pre>
- @OneToOne(cascade = {CascadeType.ALL})
- @JoinColumn(name = "ADDRESS_ID")
- public Address getAddress()
- {
- return address;
- }
-</pre>
-</p><p>
-<tt>CascadeType.ALL</tt> specifies that when a Customer is created, if there is any Address association, then that Address will be created as well(<tt>CascadeType.PERSIST</tt>). If the Customer is deleted from persistence storage, the Address table will be deleted(<tt>CascadeType.REMOVE</tt>). If a Customer instance is reattached to persistence storage, any changes to the Address collection will be merged with persistence storage (<tt>CascadeType.MERGE</tt>).
-</p><p>
-<h4>Many To Many</h4>
-
-There is a mant to many relationship between <a href="src/org/jboss/tutorial/relationships/bean/Customer.java">Customer</a> and <a href="src/org/jboss/tutorial/relationships/bean/Flight.java">Flight</a>. In order to have a many to many relationship there needs to be a distinct join table that maps the many to many relationship. This is called an association table. You can have JBoss automatically generate the association table for you, or you can use the <tt>@JoinTable</tt> annotation to define it yourself. If you use <tt>@JoinTable</tt> it must be defined on both sides of the bi-directional relationship. Let's look at the Customer side of the relationship
-</p><p>
-<pre>
- @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.EAGER, mappedBy="customers")
-</pre>
-</p><p>
-The <tt>mappedBy</tt> attribute states that the Flight.customers property is responsible for mapping and managing the relationship.
- The spec allows for multiple join and inverse join columns. See the <i>Composite Primary Key</i> tutorial for more information.
-</p><p>
-Let's look at the other side of the relationship in Flight.
-</p><p>
-<pre>
- @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.EAGER)
- @JoinTable(table = @Table(name = "flight_customer_table"),
- joinColumns = {@JoinColumn(name = "FLIGHT_ID")},
- inverseJoinColumns = {@JoinColumn(name = "CUSTOMER_ID")})
- public Set<Customer> getCustomers()
- {
- return customers;
- }
-</pre>
-</p><p>
-The database associate table will look like this:
-</p><p>
-<pre>
- create table FLIGHT_CUSTOMER_TABLE (
- CUSTOMER_ID integer,
- FLIGHT_ID integer
- );
-</pre>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-07 14:39:23,103 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Air France customers
- [java] Bill
- [java] Monica
- [java] USAir customers
- [java] Molly
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>View the tables and rows</h4>
-
-You can view the tables created by JBoss by going to the <a href="http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB">Hypersonic SQL service</a>, scrolling down to the <tt>startDatabaseManager</tt> button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/relationships/relationships.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/relationships/relationships.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/relationships/relationships.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,73 +0,0 @@
-!!!Relationships
-The entity tutorial only showed one-to-many and many-to-one relationships. This tutorial will show you one-to-one and many-to-many relationships.
-
-
-!One to One
-There is a unidirectional one to one relationship defined between the [Customer|src/org/jboss/tutorial/relationships/bean/Customer.java] and [Address|src/org/jboss/tutorial/relationships/bean/Address.java]. Customer defines the uni directional relationship.
-
-{{{
- @OneToOne(cascade = {CascadeType.ALL})
- @JoinColumn(name = "ADDRESS_ID")
- public Address getAddress()
- {
- return address;
- }
-}}}
-
-{{CascadeType.ALL}} specifies that when a Customer is created, if there is any Address association, then that Address will be created as well({{CascadeType.PERSIST}}). If the Customer is deleted from persistence storage, the Address table will be deleted({{CascadeType.REMOVE}}). If a Customer instance is reattached to persistence storage, any changes to the Address collection will be merged with persistence storage ({{CascadeType.MERGE}}).
-
-!Many To Many
-There is a mant to many relationship between [Customer|src/org/jboss/tutorial/relationships/bean/Customer.java] and [Flight|src/org/jboss/tutorial/relationships/bean/Flight.java]. In order to have a many to many relationship there needs to be a distinct join table that maps the many to many relationship. This is called an association table. You can have JBoss automatically generate the association table for you, or you can use the {{@JoinTable}} annotation to define it yourself. If you use {{@JoinTable}} it must be defined on both sides of the bi-directional relationship. Let's look at the Customer side of the relationship
-
-{{{
- @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.EAGER, mappedBy="customers")
-}}}
-
-The {{mappedBy}} attribute states that the Flight.customers property is responsible for mapping and managing the relationship.
- The spec allows for multiple join and inverse join columns. See the ''Composite Primary Key'' tutorial for more information.
-
-Let's look at the other side of the relationship in Flight.
-
-{{{
- @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.EAGER)
- @JoinTable(table = @Table(name = "flight_customer_table"),
- joinColumns = {@JoinColumn(name = "FLIGHT_ID")},
- inverseJoinColumns = {@JoinColumn(name = "CUSTOMER_ID")})
- public Set<Customer> getCustomers()
- {
- return customers;
- }
-}}}
-
-The database associate table will look like this:
-
-{{{
- create table FLIGHT_CUSTOMER_TABLE (
- CUSTOMER_ID integer,
- FLIGHT_ID integer
- );
-}}}
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-07 14:39:23,103 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Air France customers
- [java] Bill
- [java] Monica
- [java] USAir customers
- [java] Molly
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!View the tables and rows
-You can view the tables created by JBoss by going to the [Hypersonic SQL service|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB], scrolling down to the {{startDatabaseManager}} button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-
Deleted: projects/ejb3/trunk/docs/tutorial/resource_ref/jboss_rr.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/resource_ref/jboss_rr.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/resource_ref/jboss_rr.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,35 +0,0 @@
-!!!jboss.xml Resource References
-Resources (e.g. data sources, JavaMail sessions, JMS queues) may be added to the local jndi namespace of individual EJBs. This is to separate the jndi names used in the
-bean code from the global jndi bindings set by the Deployer. The mapping of the bean local jndi binding and the global binding may be handled via the ejb-jar.xml and
-jboss.xml deployment descriptors.
-
-!ejb-jar.xml
-Take a look at [ejb-jar.xml|META-INF/ejb-jar.xml]. For {{ENCBean}}, there are 3 <resource-ref> elements indicating resource reference names and types.
-
-!jboss.xml
-Take a look at [jboss.xml|META-INF/jboss.xml]. For {{ENCBean}}, there are again 3 <resource-ref> elements indicating resource reference names and either the global jndi
-binding via the <jndi-name> element or the resource name. Resource managers are used to map resource names to global jndi bindings via the <resource-managers> element.
-
-!TestENCBean.java
-Take a look at [TestENCBean.java|src/org/jboss/tutorial/jboss_resource_ref/bean/TestENCBean.java]. Each one of the resources are accessed from the bean local jndi
-namespace (i.e. java:comp.ejb3/env) by the value set in the <res-ref-name> values in the deployment descriptors.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Successfully accessed bean resource references
-}}}
-
-{{{
-13:44:09,500 INFO [TestENCBean] Found data source resource ref
-13:44:09,500 INFO [TestENCBean] Found mail resource ref
-13:44:09,500 INFO [TestENCBean] Found jms queue resource ref
-13:44:09,500 INFO [TestENCBean] Found jms queue resource env ref
-}}}
-
Deleted: projects/ejb3/trunk/docs/tutorial/secondary/secondary.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/secondary/secondary.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/secondary/secondary.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,65 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Secondary Tables</h2>
-
-The EJB specification allows you to map an entity bean to multiple tables. You do this by using the <tt>@SecondaryTable</tt> annotation.
-</p><p>
-The <a href="src/org/jboss/tutorial/secondary/bean/Customer.java">Customer</a> bean maps its address properties to a separate ADDRESS table. The first thing it does is define the secondary table.
-</p><p>
-<pre>
- at Entity
- at Table(name = "CUSTOMER")
- at SecondaryTable(name = "EMBEDDED_ADDRESS", join = {@JoinColumn(name = "ADDRESS_ID")})
-public class Customer implements java.io.Serializable
-{
-</pre>
-</p><p>
-The <tt>@JoinColumn</tt> of the secondary table must match the value of the Customer's primary key.
-</p><p>
-To map individual properties to a secondary table you use the <tt>secondaryTable</tt> member value of <tt>@Column</tt>.
-</p><p>
-<pre>
- @Column(name = "STREET", secondaryTable = "EMBEDDED_ADDRESS")
- public String getStreet()
- {
- return street;
- }
-</pre>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Create Bill Burke and Monica Smith
- [java] 2004-10-06 22:27:50,344 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Bill and Monica get married
- [java] Get all the Burkes
- [java] There are now 2 Burkes
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>View the tables and rows</h4>
-
-You can view the tables created by JBoss by going to the <a href="http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB">Hypersonic SQL service</a>, scrolling down to the <tt>startDatabaseManager</tt> button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/secondary/secondary.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/secondary/secondary.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/secondary/secondary.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,55 +0,0 @@
-!!!Secondary Tables
-The EJB specification allows you to map an entity bean to multiple tables. You do this by using the {{@SecondaryTable}} annotation.
-
-The [Customer|src/org/jboss/tutorial/secondary/bean/Customer.java] bean maps its address properties to a separate ADDRESS table. The first thing it does is define the secondary table.
-
-{{{
- at Entity
- at Table(name = "CUSTOMER")
- at SecondaryTable(name = "EMBEDDED_ADDRESS", join = {@JoinColumn(name = "ADDRESS_ID")})
-public class Customer implements java.io.Serializable
-{
-}}}
-
-The {{@JoinColumn}} of the secondary table must match the value of the Customer's primary key.
-
-To map individual properties to a secondary table you use the {{secondaryTable}} member value of {{@Column}}.
-
-{{{
- @Column(name = "STREET", secondaryTable = "EMBEDDED_ADDRESS")
- public String getStreet()
- {
- return street;
- }
-}}}
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Create Bill Burke and Monica Smith
- [java] 2004-10-06 22:27:50,344 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Bill and Monica get married
- [java] Get all the Burkes
- [java] There are now 2 Burkes
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!View the tables and rows
-You can view the tables created by JBoss by going to the [Hypersonic SQL service|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB], scrolling down to the {{startDatabaseManager}} button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-
-
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/security/security.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/security/security.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/security/security.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,63 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Transactions and Security</h2>
-
-The EJB 3.0 specification has an optional total replacement of XML deployment descriptors with annotations. This tutorial goes over how to
-use the transaction and security annotations of EJB 3.0.
-</p><p>
-<h4>Transactions</h4>
-
-Using transactions is easy, just use the <tt>javax.ejb.TransactionAttribute</tt> annotation. The <tt>javax.ejb.TransactionAttributeType</tt> enum has every transactional type.
-</p><p>
-<pre>
- @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
- public int add(int x, int y)
- {
- return x + y;
- }
-</pre>
-</p><p>
-<h4>Security</h4>
-
-Take a look at <a href="src/org/jboss/tutorial/security/bean/CalculatorBean.java">calculatorBean</a>.
-</p><p>
-The <tt>javax.annotation.security.RolesAllowed</tt> and <tt>javax.annotation.security.PermitAll</tt> are the EJB 3.0 security annotations. You can attach a MethodPermission to any method and define which roles are allowed to invoke on that method. The <tt>javax.ejb.RunAs</tt> annotation can also be applied at the class level. There is also an additional JBoss specific annotation that you must supply at the class level. <tt>org.jboss.ejb3.security.SecurityDomain</tt>. The SecurityDomain specifies the JAAS repository which will be used by JBoss to authenticate and authorize. See the JBoss Application Server documentation for more details. In this particular example, the "other" domain is used. The "other" domain corresponds to a users.properties and roles.properties files that contain cleartext user, password, and user/role associations. If you open the built tutorial.jar file you will see these two files in there.
-</p><p>
-<h4>Client</h4>
-
-Open up <a href="src/org/jboss/tutorial/security/client/Client.java">Client.java</a>. You'll see that it looks up the stateless bean under its remote interface's fully qualified classname. Also notice that there is no Home interface and you can begin executing on the stateless bean right away. The client uses a proprietary backdoor to set the user name and password through JBoss's SecurityAssociation class. JBoss recommends using JAAS for more portable applicatons.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Kabir is a student.
- [java] Kabir types in the wrong password
- [java] 2004-10-07 15:32:50,916 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Authentication exception, principal=kabir
- [java] Kabir types in correct password.
- [java] Kabir does unchecked addition.
- [java] 1 + 1 = 2
- [java] Kabir is not a teacher so he cannot do division
- [java] Insufficient method permissions, principal=kabir, interface=org.jboss.ejb3.EJBContainerInvocation, requiredR
-oles=[teacher], principalRoles=[student]
- [java] Students are allowed to do subtraction
- [java] 1 - 1 = 0
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/security/security.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/security/security.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/security/security.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,52 +0,0 @@
-!!!Transactions and Security
-The EJB 3.0 specification has an optional total replacement of XML deployment descriptors with annotations. This tutorial goes over how to
-use the transaction and security annotations of EJB 3.0.
-
-!Transactions
-Using transactions is easy, just use the {{javax.ejb.TransactionAttribute}} annotation. The {{javax.ejb.TransactionAttributeType}} enum has every transactional type.
-
-{{{
- @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
- public int add(int x, int y)
- {
- return x + y;
- }
-}}}
-
-!Security
-Take a look at [calculatorBean|src/org/jboss/tutorial/security/bean/CalculatorBean.java].
-
-The {{javax.annotation.security.RolesAllowed}} and {{javax.annotation.security.PermitAll}} are the EJB 3.0 security annotations. You can attach a MethodPermission to any method and define which roles are allowed to invoke on that method. The {{javax.ejb.RunAs}} annotation can also be applied at the class level. There is also an additional JBoss specific annotation that you must supply at the class level. {{org.jboss.ejb3.security.SecurityDomain}}. The SecurityDomain specifies the JAAS repository which will be used by JBoss to authenticate and authorize. See the JBoss Application Server documentation for more details. In this particular example, the "other" domain is used. The "other" domain corresponds to a users.properties and roles.properties files that contain cleartext user, password, and user/role associations. If you open the built tutorial.jar file you will see these two files in there.
-
-!Client
-Open up [Client.java|src/org/jboss/tutorial/security/client/Client.java]. You'll see that it looks up the stateless bean under its remote interface's fully qualified classname. Also notice that there is no Home interface and you can begin executing on the stateless bean right away. The client uses a proprietary backdoor to set the user name and password through JBoss's SecurityAssociation class. JBoss recommends using JAAS for more portable applicatons.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] Kabir is a student.
- [java] Kabir types in the wrong password
- [java] 2004-10-07 15:32:50,916 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Authentication exception, principal=kabir
- [java] Kabir types in correct password.
- [java] Kabir does unchecked addition.
- [java] 1 + 1 = 2
- [java] Kabir is not a teacher so he cannot do division
- [java] Insufficient method permissions, principal=kabir, interface=org.jboss.ejb3.EJBContainerInvocation, requiredR
-oles=[teacher], principalRoles=[student]
- [java] Students are allowed to do subtraction
- [java] 1 - 1 = 0
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/singleinheritance/single.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/singleinheritance/single.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/singleinheritance/single.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,96 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Inheritance: Single Table Strategy</h2>
-
-The EJB specification allows you to define entities that inherit from one another. The inheritance relationships can be reflected in
-queries as well. So, if you queried based on the base class, the query is polymorphic.
-</p><p>
-The tutorial example uses the single table strategy to map an inheritance relationship of <a href="src/org/jboss/tutorial/singleinheritance/bean/Pet.java">Pet</a>, which is the base class for <a href="src/org/jboss/tutorial/singleinheritance/bean/Cat.java">Cat</a> and <a href="src/org/jboss/tutorial/singleinheritance/bean/Dog.java">Dog</a>.
-</p><p>
-With the single table strategy, the entire class hierarchy is persisted in one big single table. A discriminator column is required to differentiate between which class type is persisted in a particular row.
-</p><p>
-This is what the annotations look like for Pet.
-</p><p>
-<pre>
- at Entity
- at Inheritance(strategy = InheritanceType.SINGLE_TABLE)
- at DiscriminatorColumn(name = "ANIMAL_TYPE", discriminatorType = DiscriminatorType.STRING)
-public class Pet implements java.io.Serializable
-{
-</pre>
-</p><p>
-The <tt>@DiscriminatorColumn</tt> specifies the column that will hold the type of the persisted entity. For subclasses, they must define the value of the
-discriminator column that will identify the class.
-</p><p>
-<pre>
- at Entity
- at Inheritance(strategy = InheritanceType.SINGLE_TABLE)
- at DiscriminatorColumn(discriminatorType = DiscriminatorType.STRING)
- at DiscriminatorValue("DOG")
-public class Dog extends Pet
-{
-</pre>
-</p><p>
-<h4>Polymorphic Queries</h4>
-
-<a href="src/org/jboss/tutorial/singleinheritance/bean/PetDAOBean.java">PetDAOBean</a> stateless EJB wraps some polymorphic queries.
-</p><p>
-<pre>
- public List findByWeight(double weight)
- {
- return manager.createQuery("from Pet p where p.weight < :weight").setParameter("weight", weight).getResultList();
- }
-</pre>
-</p><p>
-Even though the <tt>findByWeight</tt> method queries on Pet, either Dog or Cat instances can be returned.
-</p><p>
-<h4>Table mapping</h4>
-
-The table mapping for this example looks like this:
-</p><p>
-<pre>
-create table PET (
- ID integer primary key,
- ANIMAL_TYPE varchar,
- NAME varchar,
- WEIGHT double,
- LIVES int,
- NUMBONES int
-);
-</pre>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-07 00:16:20,395 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Sox
- [java] Junior
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>View the tables and rows</h4>
-
-You can view the tables created by JBoss by going to the <a href="http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB">Hypersonic SQL service</a>, scrolling down to the <tt>startDatabaseManager</tt> button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/singleinheritance/single.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/singleinheritance/single.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/singleinheritance/single.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,84 +0,0 @@
-!!!Inheritance: Single Table Strategy
-The EJB specification allows you to define entities that inherit from one another. The inheritance relationships can be reflected in
-queries as well. So, if you queried based on the base class, the query is polymorphic.
-
-The tutorial example uses the single table strategy to map an inheritance relationship of [Pet|src/org/jboss/tutorial/singleinheritance/bean/Pet.java], which is the base class for [Cat|src/org/jboss/tutorial/singleinheritance/bean/Cat.java] and [Dog|src/org/jboss/tutorial/singleinheritance/bean/Dog.java].
-
-With the single table strategy, the entire class hierarchy is persisted in one big single table. A discriminator column is required to differentiate between which class type is persisted in a particular row.
-
-This is what the annotations look like for Pet.
-
-{{{
- at Entity
- at Inheritance(strategy = InheritanceType.SINGLE_TABLE)
- at DiscriminatorColumn(name = "ANIMAL_TYPE", discriminatorType = DiscriminatorType.STRING)
-public class Pet implements java.io.Serializable
-{
-}}}
-
-The {{@DiscriminatorColumn}} specifies the column that will hold the type of the persisted entity. For subclasses, they must define the value of the
-discriminator column that will identify the class.
-
-{{{
- at Entity
- at Inheritance(strategy = InheritanceType.SINGLE_TABLE)
- at DiscriminatorColumn(discriminatorType = DiscriminatorType.STRING)
- at DiscriminatorValue("DOG")
-public class Dog extends Pet
-{
-}}}
-
-!Polymorphic Queries
-[PetDAOBean|src/org/jboss/tutorial/singleinheritance/bean/PetDAOBean.java] stateless EJB wraps some polymorphic queries.
-
-{{{
- public List findByWeight(double weight)
- {
- return manager.createQuery("from Pet p where p.weight < :weight").setParameter("weight", weight).getResultList();
- }
-}}}
-
-Even though the {{findByWeight}} method queries on Pet, either Dog or Cat instances can be returned.
-
-!Table mapping
-The table mapping for this example looks like this:
-
-{{{
-create table PET (
- ID integer primary key,
- ANIMAL_TYPE varchar,
- NAME varchar,
- WEIGHT double,
- LIVES int,
- NUMBONES int
-);
-}}}
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-07 00:16:20,395 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Sox
- [java] Junior
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!View the tables and rows
-You can view the tables created by JBoss by going to the [Hypersonic SQL service|http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DHypersonic%2Cdatabase%3DlocalDB], scrolling down to the {{startDatabaseManager}} button and clicking it. A Hypersonic SQL window will be minimized, but you can open it up to look at the tables and do queries.
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files and additionally, you will probably need to define a hibernate.properties file in the META-INF directory of the JAR. hibernate.properties is needed if you need to hook in a datasource other than JBoss's DefaultDS, or change the caching of Hibernate. See the EJB 3.0 reference manual and Hibernate reference manual for more details.f
-
-
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/stateful/stateful.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/stateful/stateful.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/stateful/stateful.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,62 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Stateful Beans</h2>
-
-It is very easy to create a Stateful Bean with EJB 3.0. All bean types are homeless in EJB 3.0 so all you have to do to create a Stateful bean is to create a bean class and have it implement at least one interface. Take a look at <a href="src/org/jboss/tutorial/stateful/bean/ShoppingCartBean.java">ShoppingCartBean.java</a>
-</p><p>
-The first thing to notice is that the class is tagged as <tt>@Stateful</tt>. This marks the class as a stateful bean and the deployer will deploy that class as a stateful bean EJB container.
-</p><p>
-ShoppingCartBean also implements a remote interface. Take a look at <a href="src/org/jboss/tutorial/stateful/bean/ShoppingCart.java">ShoppingCart.java</a>. To define this as the remote interface of ShoppingCartBean
-you need to use the <tt>@javax.ejb.Remote</tt> annotation on the ShoppingCartBean class.
-</p><p>
-<h4>@Remove</h4>
-
-Take another look at <a href="src/org/jboss/tutorial/stateful/bean/ShoppingCartBean.java">ShoppingCartBean.java</a>. Look for the method annotated as <tt>@Remove</tt>. Instead of explicitly calling EJBObject.remove() in your applications and thus polluting it further with J2EE specific code, any method tagged with <tt>@Remove</tt> will cause the stateful bean instance to be removed from the container at the end of the method call.
-</p><p>
-<h4>JNDI Bindings</h4>
-
-The ShoppingCartBean will have its remote interface bound in JNDI, by default, under the ejbName/local and/or ejbName/remote for the local and remote interfaces, respectively.
-</p><p>
-<h4>Client</h4>
-
-Open up <a href="src/org/jboss/tutorial/stateful/client/Client.java">Client.java</a>. You'll see that it looks up the stateful bean under "ejbName/remote". Also notice
-that there is no Home interface and you can begin executing on the stateful bean right away. When you access the bean in JNDI, an instance of the stateful bean
-will be created on the server. So, when you need a different instance of the stateful bean, you do an additional <tt>jndi.lookup()</tt> to get this new reference.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
-run:
- [java] Buying 1 memory stick
- [java] 2004-10-06 19:37:16,869 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Buying another memory stick
- [java] Buying a laptop
- [java] Print cart:
- [java] 2 Memory stick
- [java] 1 Laptop
- [java] Checkout
- [java] Should throw an object not found exception by invoking on cart after @Remove method
- [java] Successfully caught no such object exception.
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the ShoppingCartBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/stateful/stateful.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/stateful/stateful.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/stateful/stateful.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,50 +0,0 @@
-!!!Stateful Beans
-It is very easy to create a Stateful Bean with EJB 3.0. All bean types are homeless in EJB 3.0 so all you have to do to create a Stateful bean is to create a bean class and have it implement at least one interface. Take a look at [ShoppingCartBean.java|src/org/jboss/tutorial/stateful/bean/ShoppingCartBean.java]
-
-The first thing to notice is that the class is tagged as {{@Stateful}}. This marks the class as a stateful bean and the deployer will deploy that class as a stateful bean EJB container.
-
-ShoppingCartBean also implements a remote interface. Take a look at [ShoppingCart.java|src/org/jboss/tutorial/stateful/bean/ShoppingCart.java]. To define this as the remote interface of ShoppingCartBean
-you need to use the {{@javax.ejb.Remote}} annotation on the ShoppingCartBean class.
-
-!@Remove
-Take another look at [ShoppingCartBean.java|src/org/jboss/tutorial/stateful/bean/ShoppingCartBean.java]. Look for the method annotated as {{@Remove}}. Instead of explicitly calling EJBObject.remove() in your applications and thus polluting it further with J2EE specific code, any method tagged with {{@Remove}} will cause the stateful bean instance to be removed from the container at the end of the method call.
-
-!JNDI Bindings
-The ShoppingCartBean will have its remote interface bound in JNDI, by default, under the ejbName/local and/or ejbName/remote for the local and remote interfaces, respectively.
-
-!Client
-Open up [Client.java|src/org/jboss/tutorial/stateful/client/Client.java]. You'll see that it looks up the stateful bean under "ejbName/remote". Also notice
-that there is no Home interface and you can begin executing on the stateful bean right away. When you access the bean in JNDI, an instance of the stateful bean
-will be created on the server. So, when you need a different instance of the stateful bean, you do an additional {{jndi.lookup()}} to get this new reference.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
-run:
- [java] Buying 1 memory stick
- [java] 2004-10-06 19:37:16,869 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Buying another memory stick
- [java] Buying a laptop
- [java] Print cart:
- [java] 2 Memory stick
- [java] 1 Laptop
- [java] Checkout
- [java] Should throw an object not found exception by invoking on cart after @Remove method
- [java] Successfully caught no such object exception.
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the ShoppingCartBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/stateful_deployment_descriptor/stateful.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/stateful_deployment_descriptor/stateful.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/stateful_deployment_descriptor/stateful.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,64 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Stateful Beans Using Deployment Descriptors</h2>
-
-Take a look at <a href="META-INF/ejb-jar.xml">ejb-jar.xml</a> and <a href="src/org/jboss/tutorial/stateful_deployment_descriptor/bean/ShoppingCartBean.java">ShoppingCartBean.java</a>.
-You specify a stateful bean with the "session" and "session-type" tags. Note that all
-bean types in EJB 3.0 are homeless, so there is no requirement for a "home" or "local-home" tag. The bean class is specified with the "ejb-class" tag.
-ShoppingCartBean also implements a remote interface. Take a look at <a href="src/org/jboss/tutorial/stateful_deployment_descriptor/bean/ShoppingCart.java">ShoppingCart.java</a>.
-To define this as the remote interface of ShoppingCartBean you need to use the "remote" tag.
-</p><p>
-<h4>@Remove</h4>
-
-Take another look at <a href="META-INF/ejb-jar.xml">ejb-jar.xml</a>. Look for the "remove-list" tag. Instead of explicitly calling EJBObject.remove()
-in your applications and thus polluting it further with J2EE specific code, any method specified in the "remove-list" tag will cause the stateful bean
-instance to be removed from the container at the end of the method call. This deployment descriptor behavior mimics the @Remove annotation.
-</p><p>
-<h4>JNDI Bindings</h4>
-
-The ShoppingCartBean will have its remote interface bound in JNDI. Take a look at <a href="META-INF/jboss.xml">jboss.xml</a>. Note the "jndi-name" tag. This specifies the jndi binding for the remote interface.
-</p><p>
-<h4>Client</h4>
-
-Open up <a href="src/org/jboss/tutorial/stateful_deployment_descriptor/client/Client.java">Client.java</a>. You'll see that it looks up the stateful
-bean under its jndi name. Also notice that there is no Home interface and you can begin executing on the stateful
-bean right away. When you access the bean in JNDI, an instance of the stateful bean will be created on the server. So, when you need a different
-instance of the stateful bean, you do an additional <tt>jndi.lookup()</tt> to get this new reference.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
-run:
- [java] Buying 1 memory stick
- [java] 2004-10-06 19:37:16,869 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Buying another memory stick
- [java] Buying a laptop
- [java] Print cart:
- [java] 2 Memory stick
- [java] 1 Laptop
- [java] Checkout
- [java] Should throw an object not found exception by invoking on cart after @Remove method
- [java] Successfully caught no such object exception.
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the ShoppingCartBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/stateful_deployment_descriptor/stateful.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/stateful_deployment_descriptor/stateful.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/stateful_deployment_descriptor/stateful.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,49 +0,0 @@
-!!!Stateful Beans Using Deployment Descriptors
-Take a look at [ejb-jar.xml|META-INF/ejb-jar.xml] and [ShoppingCartBean.java|src/org/jboss/tutorial/stateful_deployment_descriptor/bean/ShoppingCartBean.java].
-You specify a stateful bean with the "session" and "session-type" tags. Note that all
-bean types in EJB 3.0 are homeless, so there is no requirement for a "home" or "local-home" tag. The bean class is specified with the "ejb-class" tag.
-ShoppingCartBean also implements a remote interface. Take a look at [ShoppingCart.java|src/org/jboss/tutorial/stateful_deployment_descriptor/bean/ShoppingCart.java].
-To define this as the remote interface of ShoppingCartBean you need to use the "remote" tag.
-
-!@Remove
-Take another look at [ejb-jar.xml/META-INF/ejb-jar.xml]. Look for the "remove-list" tag. Instead of explicitly calling EJBObject.remove()
-in your applications and thus polluting it further with J2EE specific code, any method specified in the "remove-list" tag will cause the stateful bean
-instance to be removed from the container at the end of the method call. This deployment descriptor behavior mimics the @Remove annotation.
-
-!JNDI Bindings
-The CalculatorBean will have its remote interface bound in JNDI. Take a look at [jboss.xml|META-INF/jboss.xml]. Note the "jndi-name" tag. This specifies the jndi binding for the remote interface.
-
-!Client
-Open up [Client.java|src/org/jboss/tutorial/stateful_deployment_descriptor/client/Client.java]. You'll see that it looks up the stateful bean under its jndi name. Also notice that there is no Home interface and you can begin executing on the stateful bean right away. When you access the bean in JNDI, an instance of the stateful bean will be created on the server. So, when you need a different instance of the stateful bean, you do an additional {{jndi.lookup()}} to get this new reference.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
-run:
- [java] Buying 1 memory stick
- [java] 2004-10-06 19:37:16,869 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] Buying another memory stick
- [java] Buying a laptop
- [java] Print cart:
- [java] 2 Memory stick
- [java] 1 Laptop
- [java] Checkout
- [java] Should throw an object not found exception by invoking on cart after @Remove method
- [java] Successfully caught no such object exception.
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the ShoppingCartBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/stateless/stateless.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/stateless/stateless.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/stateless/stateless.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,61 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Stateless Beans</h2>
-
-It is very easy to create a Stateless Bean with EJB 3.0. All bean types are homeless in EJB 3.0 so all you have to do to
-create a Stateless bean is to create a bean class and have it implement at least one interface.
-Take a look at <a href="src/org/jboss/tutorial/stateless/bean/CalculatorBean.java">CalculatorBean.java</a>
-</p><p>
-The first thing to notice is that the class is tagged as <tt>@Stateless</tt>. This marks the class as a stateless bean and
-the deployer will deploy that class as a stateless bean EJB container.
-</p><p>
-CalculatorBean also implements two interfaces. One is the remote interface of the EJB the other is the local interface.
-</p><p>
-Take a look at <a href="src/org/jboss/tutorial/stateless/bean/CalculatorRemote.java">CalculatorRemote.java</a>. To define this as the remote interface of Calculator bean
-you either annotate the bean class and specify what the remote interfaces are, or you annotate each remote interface the bean class
-implements with @javax.ejb.Remote. only need to annotate the bean class with @javax.ejb.Remote. Similar for <a href="src/org/jboss/tutorial/stateless/bean/CalculatorLocal.java">CalculatorLocal.java</a> as you need to annotate the bean class with @javax.ejb.Local for it to be the local interface of the CalculatorBean.
-</p><p>
-<h4>JNDI Bindings</h4>
-
-The Calculator bean will have two JNDI bindings for the remote and Local interface. By default, JBoss will use ejbName/local and ejbName/remote for the local and
-remote interfaces, respectively.
-</p><p>
-<h4>Client</h4>
-
-Open up <a href="src/org/jboss/tutorial/stateless/client/Client.java">Client.java</a>. You'll see that it looks up the stateless bean under "ejbName/remote".
-Also notice that there is no Home interface and you can begin executing on the stateless bean right away.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have installed JBoss 5.x and have JBoss running.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 5.x distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 5.x distribution is>
-</pre>
-
-<b> Ant Users: </b>
-<pre>
-$ ant
-$ ant run
-
-run:
- [java] 1 + 1 = 2
- [java] 1 - 1 = 0
-</pre>
-
-<b> Maven Users: </b>
-<pre>
-$ mvn clean install
-</pre>
-
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the CalculatorBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. There is no precompilation step.
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/stateless/stateless.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/stateless/stateless.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/stateless/stateless.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,54 +0,0 @@
-!!!Stateless Beans
-It is very easy to create a Stateless Bean with EJB 3.0. All bean types are homeless in EJB 3.0 so all you have to do to
-create a Stateless bean is to create a bean class and have it implement at least one interface.
-Take a look at [CalculatorBean.java|src/org/jboss/tutorial/stateless/bean/CalculatorBean.java]
-
-The first thing to notice is that the class is tagged as {{@Stateless}}. This marks the class as a stateless bean and
-the deployer will deploy that class as a stateless bean EJB container.
-
-CalculatorBean also implements two interfaces. One is the remote interface of the EJB the other is the local interface.
-
-Take a look at [CalculatorRemote.java|src/org/jboss/tutorial/stateless/bean/CalculatorRemote.java]. To define this as the remote interface of Calculator bean
-you either annotate the bean class and specify what the remote interfaces are, or you annotate each remote interface the bean class
-implements with @javax.ejb.Remote. only need to annotate the bean class with @javax.ejb.Remote. Similar for [CalculatorLocal.java|src/org/jboss/tutorial/stateless/bean/CalculatorLocal.java] as you need to annotate the bean class with @javax.ejb.Local for it to be the local interface of the CalculatorBean.
-
-!JNDI Bindings
-The Calculator bean will have two JNDI bindings for the remote and Local interface. By default, JBoss will use ejbName/local and ejbName/remote for the local and
-remote interfaces, respectively.
-
-!Client
-Open up [Client.java|src/org/jboss/tutorial/stateless/client/Client.java]. You'll see that it looks up the stateless bean under "ejbName/remote".
-Also notice that there is no Home interface and you can begin executing on the stateless bean right away.
-
-!Building and Running
-To build and run the example, make sure you have installed JBoss 5.x and have JBoss running.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 5.x distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 5.x distribution is>
-}}}
-
-!Ant Users:
-{{{
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-06 19:10:35,857 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] 1 + 1 = 2
- [java] 1 - 1 = 0
-}}}
-
-!Maven Users:
-{{{
-$ mvn clean install
-TODO: This part needs to be fixed. In progress.
-$ mvn exec:exec
-}}}
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the CalculatorBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/stateless_deployment_descriptor/stateless.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/stateless_deployment_descriptor/stateless.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/stateless_deployment_descriptor/stateless.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,60 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Stateless Beans</h2>
-
-It is very easy to create a Stateless Bean with EJB 3.0. All bean types are homeless in EJB 3.0 so all you have to do to
-create a Stateless bean is to create a bean class and have it implement at least one interface.
-Take a look at <a href="src/org/jboss/tutorial/stateless_deployment_descriptor/bean/CalculatorBean.java">CalculatorBean.java</a>
-</p><p>
-<h4>ejb-jar.xml</h4>
-
-</p><p>
-CalculatorBean is defined as a stateless session bean through the <session> and <session-type> elements. This marks the class as a stateless bean and
-the deployer will deploy that class as a stateless bean EJB container.
-</p><p>
-CalculatorBean also implements two interfaces. One is the remote interface of the EJB the other is the local interface.
-</p><p>
-Take a look at <a href="src/org/jboss/tutorial/stateless_deployment_descriptor/bean/CalculatorRemote.java">CalculatorRemote.java</a>. To define this as the remote
-interface of Calculator bean you specify the interface with the <remote> tag. Similar for
-<a href="src/org/jboss/tutorial/stateless_deployment_descriptor/bean/CalculatorLocal.java">CalculatorLocal.java</a> as you need to specify the local
-interface with the <local> tag.
-</p><p>
-<h4>JNDI Bindings</h4>
-
-The Calculator bean will have two JNDI bindings for the remote and Local interface. By default, JBoss will use ejbName/local and ejbName/remote for the local and
-remote interfaces, respectively.
-</p><p>
-<h4>Client</h4>
-
-Open up <a href="src/org/jboss/tutorial/stateless_deployment_descriptor/client/Client.java">Client.java</a>. You'll see that it looks up the stateless bean under
-"ejbName/remote". Also notice that there is no Home interface and you can begin executing on the stateless bean right away.
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-06 19:10:35,857 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] 1 + 1 = 2
- [java] 1 - 1 = 0
-</pre>
-</p><p>
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-</p><p>
-<h4>Jar structure</h4>
-
-EJB 3.0 beans must be packaged in a JAR file with the suffix <tt>.jar</tt>. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the CalculatorBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/stateless_deployment_descriptor/stateless.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/stateless_deployment_descriptor/stateless.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/stateless_deployment_descriptor/stateless.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,48 +0,0 @@
-!!!Stateless Beans
-It is very easy to create a Stateless Bean with EJB 3.0. All bean types are homeless in EJB 3.0 so all you have to do to
-create a Stateless bean is to create a bean class and have it implement at least one interface.
-Take a look at [CalculatorBean.java|src/org/jboss/tutorial/stateless_deployment_descriptor/bean/CalculatorBean.java]
-
-!ejb-jar.xml
-
-CalculatorBean is defined as a stateless session bean through the <session> and <session-type> elements. This marks the class as a stateless bean and
-the deployer will deploy that class as a stateless bean EJB container.
-
-CalculatorBean also implements two interfaces. One is the remote interface of the EJB the other is the local interface.
-
-Take a look at [CalculatorRemote.java|src/org/jboss/tutorial/stateless_deployment_descriptor/bean/CalculatorRemote.java]. To define this as the remote
-interface of Calculator bean you specify the interface with the <remote> tag. Similar for
-[CalculatorLocal.java|src/org/jboss/tutorial/stateless_deployment_descriptor/bean/CalculatorLocal.java] as you need to specify the local
-interface with the <local> tag.
-
-!JNDI Bindings
-The Calculator bean will have two JNDI bindings for the remote and Local interface. By default, JBoss will use ejbName/local and ejbName/remote for the local and
-remote interfaces, respectively.
-
-!Client
-Open up [Client.java|src/org/jboss/tutorial/stateless_deployment_descriptor/client/Client.java]. You'll see that it looks up the stateless bean under
-"ejbName/remote". Also notice that there is no Home interface and you can begin executing on the stateless bean right away.
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-run:
- [java] 2004-10-06 19:10:35,857 INFO org.jboss.remoting.InvokerRegistry[main] - Failed to load soap remoting transpo
-rt: org/apache/axis/AxisFault
- [java] 1 + 1 = 2
- [java] 1 - 1 = 0
-}}}
-
-The INFO message you can ignore. It will be fixed in later releases of JBoss 4.0.
-
-!Jar structure
-EJB 3.0 beans must be packaged in a JAR file with the suffix {{.jar}}. Running the ant script above creates a JAR file within the deploy/ directory of JBoss. All that needs to be in that jar is your server-side class files. So basically just the CalculatorBean and the interfaces it implements. JBoss will automatically browse the JAR file to determine if any EJBs are annotated by any classes within it. THere is no precompilation step.
-
-
-
-
Deleted: projects/ejb3/trunk/docs/tutorial/timer/timer.html
===================================================================
--- projects/ejb3/trunk/docs/tutorial/timer/timer.html 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/timer/timer.html 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,52 +0,0 @@
-<html>
-<body>
-<p>
-<h2>Timer Service and Callbacks</h2>
-
-This example shows you how to access <tt>javax.ejb.SessionContext</tt> as well as using the EJB Timer Service. It also explains how
-callbacks work in EJB 3.0.
-</p><p>
-<h4>SessionContext injection</h4>
-
-The <tt>javax.ejb.SessionContext</tt> is injected using the <tt>@javax.annotation.Resource</tt> annotation. When the stateless bean instance is created
-the field will be initialized with the correct SessionContext. Take a look at <a href="src/org/jboss/tutorial/timer/bean/ExampleTimerBean.java">ExampleTimerBean.java</a>
-</p><p>
-<pre>
- private @Resource SessionContext ctx;
-</pre>
-</p><p>
-<h4>Callbacks</h4>
-
-The rest of the bean example registers a timer with the EJB Timer service. In the EJB 2.1 specification it was required to implement an interface to get ejbTimeout callbacks.
-It is still being debated in the EJB 3.0 EG on whether an interface or annotation should be used to specify this callback.
-In JBoss EJB 3 Preview, it is implemented as an annotation.
-All you have to define is a method annotated with <tt>javax.ejb.Timeout</tt>.
-This is the same with other callbacks like @PrePassviate, @PostRemove, etc... No interface is needed to be implemented, just declare the methods as you need them.
-</p><p>
-If you have feedback on this and would like to throw your 2-cents on this topic, please email <a href="mailto:ejb3-feedback at sun.com">ejb3-feedback</a>
-</p><p>
-<h4>Building and Running</h4>
-
-To build and run the example, make sure you have <tt>ejb3.deployer</tt> installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-<pre>
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-</pre>
-</p><p>
-After 5 seconds look at the JBoss console window to see the Timer being fired.
-</p><p>
-<pre>
-00:51:20,074 INFO [STDOUT] ---------------------
-00:51:20,074 INFO [STDOUT] * Received Timer event: Hello World
-00:51:20,074 INFO [STDOUT] ---------------------
-</pre>
-</p><p>
-</p><p>
-</p><p>
-</p><p>
-</p>
-</body>
-</html>
Deleted: projects/ejb3/trunk/docs/tutorial/timer/timer.wiki
===================================================================
--- projects/ejb3/trunk/docs/tutorial/timer/timer.wiki 2009-01-22 08:12:18 UTC (rev 83261)
+++ projects/ejb3/trunk/docs/tutorial/timer/timer.wiki 2009-01-22 10:07:10 UTC (rev 83262)
@@ -1,42 +0,0 @@
-!!!Timer Service and Callbacks
-This example shows you how to access {{javax.ejb.SessionContext}} as well as using the EJB Timer Service. It also explains how
-callbacks work in EJB 3.0.
-
-!SessionContext injection
-The {{javax.ejb.SessionContext}} is injected using the {{@javax.annotation.Resource}} annotation. When the stateless bean instance is created
-the field will be initialized with the correct SessionContext. Take a look at [ExampleTimerBean.java|src/org/jboss/tutorial/timer/bean/ExampleTimerBean.java]
-
-{{{
- private @Resource SessionContext ctx;
-}}}
-
-!Callbacks
-The rest of the bean example registers a timer with the EJB Timer service. In the EJB 2.1 specification it was required to implement an interface to get ejbTimeout callbacks.
-It is still being debated in the EJB 3.0 EG on whether an interface or annotation should be used to specify this callback.
-In JBoss EJB 3 Preview, it is implemented as an annotation.
-All you have to define is a method annotated with {{javax.ejb.Timeout}}.
-This is the same with other callbacks like @PrePassviate, @PostRemove, etc... No interface is needed to be implemented, just declare the methods as you need them.
-
-If you have feedback on this and would like to throw your 2-cents on this topic, please email [ejb3-feedback|mailto:ejb3-feedback at sun.com]
-
-!Building and Running
-To build and run the example, make sure you have {{ejb3.deployer}} installed in JBoss 4.0.x and have JBoss running. See the reference manual on how to install EJB 3.0.
-{{{
-Unix: $ export JBOSS_HOME=<where your jboss 4.0 distribution is>
-Windows: $ set JBOSS_HOME=<where your jboss 4.0 distribution is>
-$ ant
-$ ant run
-
-}}}
-
-After 5 seconds look at the JBoss console window to see the Timer being fired.
-
-{{{
-00:51:20,074 INFO [STDOUT] ---------------------
-00:51:20,074 INFO [STDOUT] * Received Timer event: Hello World
-00:51:20,074 INFO [STDOUT] ---------------------
-}}}
-
-
-
-
More information about the jboss-cvs-commits
mailing list