[jboss-cvs] JBossAS SVN: r105464 - projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Tue Jun 1 02:36:58 EDT 2010 

Author: misty at redhat.com
Date: 2010-06-01 02:36:58 -0400 (Tue, 01 Jun 2010)
New Revision: 105464

Modified:
   projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Concepts.xml
Log:
JBPAPP-4387

Modified: projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Concepts.xml
===================================================================
--- projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Concepts.xml	2010-06-01 06:32:08 UTC (rev 105463)
+++ projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Concepts.xml	2010-06-01 06:36:58 UTC (rev 105464)
@@ -137,13 +137,13 @@
 				The context variable name identifies a component instance within a context. (The context variable name usually matches the component name.) You can programmatically access a named component instance in a particula scope with the <literal>Contexts</literal> class, which provides access to several thread-bound instances of the <literal>Context</literal> interface:
 			</para>
 			 
-<programlisting role="JAVA"><![CDATA[User user = (User) Contexts.getSessionContext().get("user");
+<programlisting language="Java" role="JAVA"><![CDATA[User user = (User) Contexts.getSessionContext().get("user");
 ]]></programlisting>
 			 <para>
 				You may also set or change the value associated with a name:
 			</para>
 			 
-<programlisting role="JAVA"><![CDATA[Contexts.getSessionContext().set("user", user);
+<programlisting language="Java" role="JAVA"><![CDATA[Contexts.getSessionContext().set("user", user);
 ]]></programlisting>
 			 <para>
 				However, components are usually obtained from a context via <emphasis>injection</emphasis>. Component instances are subsequently given to contexts via <emphasis>outjection</emphasis>.
@@ -346,7 +346,7 @@
 				To perform actions such as bijection, context demarcation, and validation, Seam must intercept component invocations. For JavaBeans, Seam controls component instantiation completely, and no special configuration is required. For entity beans, interception is not required, since bijection and context demarcation are not defined. For session beans, an EJB interceptor must be registered for the session bean component. This can be done with an annotation, as follows:
 			</para>
 			 
-<programlisting role="JAVA"><![CDATA[@Stateless 
+<programlisting language="Java" role="JAVA"><![CDATA[@Stateless 
 @Interceptors(SeamInterceptor.class) 
 public class LoginAction implements Login { ... }
 ]]></programlisting>
@@ -354,7 +354,7 @@
 				However, it is better to define the interceptor in <filename>ejb-jar.xml</filename>:
 			</para>
 			 
-<programlisting role="XML"><![CDATA[<interceptors> 
+<programlisting language="XML" role="XML"><![CDATA[<interceptors> 
   <interceptor> 
     <interceptor-class>
       org.jboss.seam.ejb.SeamInterceptor
@@ -379,7 +379,7 @@
 				All Seam components require names. Assign a name with the <literal>@Name</literal> annotation:
 			</para>
 			 
-<programlisting role="JAVA"><![CDATA[@Name("loginAction") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("loginAction") 
 @Stateless 
 public class LoginAction implements Login { ... }
 ]]></programlisting>
@@ -396,7 +396,7 @@
 				For very large applications, and for built-in Seam components, qualified component names are often used to avoid naming conflicts.
 			</para>
 			 
-<programlisting role="JAVA"><![CDATA[@Name("com.jboss.myapp.loginAction") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("com.jboss.myapp.loginAction") 
 @Stateless 
 public class LoginAction implements Login { ... }
 ]]></programlisting>
@@ -404,21 +404,21 @@
 				The qualified component name can be used both in Java code and in JSF&#39;s expression language:
 			</para>
 			 
-<programlisting role="XHTML"><![CDATA[<h:commandButton type="submit" value="Login" 
+<programlisting language="XML" role="XHTML"><![CDATA[<h:commandButton type="submit" value="Login" 
    action="#{com.jboss.myapp.loginAction.login}"/>
 ]]></programlisting>
 			 <para>
 				Since this is noisy, Seam also provides a means of aliasing a qualified name to a simple name. Add a line like this to the <filename>components.xml</filename> file:
 			</para>
 			 
-<programlisting role="XML"><![CDATA[<factory name="loginAction" scope="STATELESS" 
+<programlisting language="XML" role="XML"><![CDATA[<factory name="loginAction" scope="STATELESS" 
          value="#{com.jboss.myapp.loginAction}"/>
 ]]></programlisting>
 			 <para>
 				All built-in Seam components have qualified names, but can be accessed through their unqualified names with Seam&#39;s <emphasis>namespace-import</emphasis> feature. The <filename>components.xml</filename> file included in the Seam JAR defines the following namespaces:
 			</para>
 			 
-<programlisting><![CDATA[<components xmlns="http://jboss.com/products/seam/components"> 
+<programlisting language="XML" role="XML"><![CDATA[<components xmlns="http://jboss.com/products/seam/components"> 
   <import>org.jboss.seam.core</import> 
   <import>org.jboss.seam.cache</import> 
   <import>org.jboss.seam.transaction</import> 
@@ -450,7 +450,7 @@
 				The <literal>@Scope</literal> annotation lets us override the scope (context) of a component to define the context a component instance is bound to when instantiated by Seam.
 			</para>
 			 
-<programlisting role="JAVA"><![CDATA[@Name("user") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("user") 
 @Entity 
 @Scope(SESSION) 
 public class User { ... }
@@ -466,7 +466,7 @@
 				Some Seam component classes can fulfill multiple roles in the system. For example, the <literal>User</literal> class is usually a session-scoped component representing the current user, but in user administration screens becomes a conversation-scoped component. The <literal>@Role</literal> annotation lets us define an additional named role for a component, with a different scope — it lets us bind the same component class to different context variables. (Any Seam component <emphasis>instance</emphasis> can be bound to multiple context variables, but this lets us do it at the class level to take advantage of automatic instantiation.)
 			</para>
 			 
-<programlisting role="JAVA"><![CDATA[@Name("user") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("user") 
 @Entity 
 @Scope(CONVERSATION) 
 @Role(name="currentUser", scope=SESSION)
@@ -476,7 +476,7 @@
 				The <literal>@Roles</literal> annotation lets us specify additional roles as required.
 			</para>
 			 
-<programlisting role="JAVA"><![CDATA[@Name("user") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("user") 
 @Entity 
 @Scope(CONVERSATION) 
 @Roles({ @Role(name="currentUser", scope=SESSION), 
@@ -494,7 +494,7 @@
 				The built-in components may be injected like any other Seam component, but they also provide convenient static <literal>instance()</literal> methods:
 			</para>
 			 
-<programlisting role="JAVA"><![CDATA[FacesMessages.instance().add("Welcome back, #{user.name}!");
+<programlisting language="Java" role="JAVA"><![CDATA[FacesMessages.instance().add("Welcome back, #{user.name}!");
 ]]>
 </programlisting>
 		</section>
@@ -539,7 +539,7 @@
 			The <literal>@In</literal> annotation specifies that a value should be injected, either into an instance variable:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("loginAction") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("loginAction") 
 @Stateless 
 public class LoginAction implements Login { 
   @In User user; 
@@ -551,7 +551,7 @@
 			or into a setter method:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("loginAction") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("loginAction") 
 @Stateless 
 public class LoginAction implements Login { 
   User user; 
@@ -573,7 +573,7 @@
 			You can even inject the value of an expression:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("loginAction") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("loginAction") 
 @Stateless 
 public class LoginAction implements Login { 
   @In("#{user.username}") String username; 
@@ -590,7 +590,7 @@
 			The <literal>@Out</literal> annotation specifies that an attribute should be outjected, either from an instance variable:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("loginAction") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("loginAction") 
 @Stateless 
 public class LoginAction implements Login { 
   @Out User user; 
@@ -601,7 +601,7 @@
 			or from a getter method:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("loginAction") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("loginAction") 
 @Stateless 
 public class LoginAction implements Login { 
   User user; 
@@ -617,7 +617,7 @@
 			An attribute may be both injected and outjected:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("loginAction") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("loginAction") 
 @Stateless 
 public class LoginAction implements Login { 
   @In 
@@ -629,7 +629,7 @@
 			or:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("loginAction") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("loginAction") 
 @Stateless 
 public class LoginAction implements Login { 
   User user;
@@ -725,7 +725,7 @@
 			Suppose we have a component named <literal>messageSender</literal> that talks to a JMS queue.
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("messageSender") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("messageSender") 
 public class MessageSender { 
 
   public void sendMessage() { 
@@ -737,7 +737,7 @@
 			In our unit tests, there is no available JMS queue, so we would like to stub out this method. We&#39;ll create a <emphasis>mock</emphasis> component that exists in the classpath when unit tests are running, but is never deployed with the application:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("messageSender") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("messageSender") 
 @Install(precedence=MOCK) 
 public class MockMessageSender extends MessageSender { 
   public void sendMessage() { 
@@ -759,7 +759,7 @@
 			Before Seam, even the simplest log message required verbose code:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[private static final Log log = LogFactory.getLog(CreateOrderAction.class);
+<programlisting language="Java" role="JAVA"><![CDATA[private static final Log log = LogFactory.getLog(CreateOrderAction.class);
  
 public Order createOrder(User user, Product product, int quantity) { 
   if ( log.isDebugEnabled() ) { 
@@ -773,7 +773,7 @@
 			Seam provides a logging API that simplifies this code significantly:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Logger private Log log; 
+<programlisting language="Java" role="JAVA"><![CDATA[@Logger private Log log; 
 
 public Order createOrder(User user, Product product, int quantity) { 
   log.debug("Creating new order for user: #0 product: #1 quantity: #2", 
@@ -794,7 +794,7 @@
 			If <literal>User</literal> and <literal>Product</literal> are Seam components available in the current contexts, the code is even more concise:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Logger private Log log; 
+<programlisting language="Java" role="JAVA"><![CDATA[@Logger private Log log; 
 public Order createOrder(User user, Product product, int quantity) { 
   log.debug("Creating new order for user: #{user.username} 
              product: #{product.name} quantity: #0", quantity); 
@@ -818,7 +818,7 @@
 			For session- or conversation-scoped JavaBean components, Seam automatically forces replication by calling <literal>setAttribute()</literal> once in every request where the component was invoked by the application. However, this strategy is inefficient for read-mostly components. Control this behavior by implementing the <literal>org.jboss.seam.core.Mutable</literal> interface, or by extending <literal>org.jboss.seam.core.AbstractMutable</literal> and writing your own dirty-checking logic inside the component. For example,
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("account") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("account") 
 public class Account extends AbstractMutable { 
   private BigDecimal balance; 
   public void setBalance(BigDecimal balance) { 
@@ -836,7 +836,7 @@
 			Or, you can use the <literal>@ReadOnly</literal> annotation to achieve a similar effect:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("account") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("account") 
 public class Account { 
   private BigDecimal balance; 
   public void setBalance(BigDecimal balance) { 
@@ -854,7 +854,7 @@
 			For session- or conversation-scoped entity bean components, Seam automatically forces replication by calling <literal>setAttribute()</literal> once in every request, unless the (conversation-scoped) entity is currently associated with a Seam-managed persistence context, in which case replication is unnecessary. This strategy is not necessarily efficient, so session or conversation scope entity beans should be used with care. You can always write a stateful session bean or JavaBean component to "manage" the entity bean instance. For example:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Stateful @Name("account") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Stateful @Name("account") 
 public class AccountManager extends AbstractMutable { 
   private Account account; // an entity bean 
   @Unwrap 
@@ -878,7 +878,7 @@
 			The <emphasis>factory component pattern</emphasis> lets a Seam component act as the instantiator for a non-component object. A <emphasis>factory method</emphasis> will be called when a context variable is referenced but has no value bound to it. Factory methods are defined with the <literal>@Factory</literal> annotation. The factory method binds a value to the context variable, and determines the scope of the bound value. There are two styles of factory method. The first style returns a value, which is bound to the context by Seam:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Factory(scope=CONVERSATION) 
+<programlisting language="Java" role="JAVA"><![CDATA[@Factory(scope=CONVERSATION) 
 public List<Customer> getCustomerList() { 
   return ... ; 
 } 
@@ -887,7 +887,7 @@
 			The second style is a method of type <literal>void</literal>, which binds the value to the context variable itself:
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@DataModel List<Customer> customerList; 
+<programlisting language="Java" role="JAVA"><![CDATA[@DataModel List<Customer> customerList; 
 @Factory("customerList") 
 public void initCustomerList() { 
   customerList = ...  ; 
@@ -900,7 +900,7 @@
 			A manager component is any component with an <literal>@Unwrap</literal> method. This method returns the value that will be visible to clients, and is called every time a context variable is referenced.
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("customerList") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("customerList") 
 @Scope(CONVERSATION) 
 public class CustomerListManager { 
   ... 
@@ -914,7 +914,7 @@
 			The manager component pattern is especially useful where more control is required over component lifecycle. For example, if you have a heavyweight object that needs a cleanup operation when the context ends, you could <literal>@Unwrap</literal> the object, and perform cleanup in the <literal>@Destroy</literal> method of the manager component.
 		</para>
 		 
-<programlisting role="JAVA"><![CDATA[@Name("hens") 
+<programlisting language="Java" role="JAVA"><![CDATA[@Name("hens") 
 @Scope(APPLICATION)
 public class HenHouse { 
   Set<Hen> hens;

More information about the jboss-cvs-commits mailing list