[jboss-cvs] JBossAS SVN: r92095 - projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Aug 6 20:19:05 EDT 2009
Author: laubai
Date: 2009-08-06 20:19:05 -0400 (Thu, 06 Aug 2009)
New Revision: 92095
Added:
projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Clustering_EJBPassivation.xml
Modified:
projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Gettingstarted.xml
projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Performance.xml
projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Revision_History.xml
Log:
Updated with clustering chapter.
Added: projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Clustering_EJBPassivation.xml
===================================================================
--- projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Clustering_EJBPassivation.xml (rev 0)
+++ projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Clustering_EJBPassivation.xml 2009-08-07 00:19:05 UTC (rev 92095)
@@ -0,0 +1,380 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+<chapter id="ClusteringAndEJBPassivation">
+ <title>Clustering and EJB Passivation</title>
+ <!--Note to QE: This chapter is new and has not been revised as of 03 Aug 2009. Trying to have it complete for CR02 on 07 Aug. Contact lbailey at redhat.com if any issues.-->
+ <!--<para>
+ <emphasis>Please note that this chapter is still being reviewed. Tread carefully.</emphasis>
+ </para>-->
+
+ <para>
+ Web clustering and EJB passivation share a common solution in Seam, so they are addressed together. This chapter focuses on the programming model and how it is affected by the use of clustering and EJB passivation. You will learn how Seam passivates component and entity instances, how passivation relates to clustering, and how to enable passivation. You will also learn how to deploy a Seam application into a cluster and verify that HTTP session replication is working correctly.
+ </para>
+ <para>
+ First, we will take you through some background information on clustering and show you an example deployment of a Seam application to a JBoss AS cluster.
+ </para>
+
+
+ <section id="clustering">
+ <title>Clustering</title>
+
+ <para>
+ Clustering, also known as <emphasis>web clustering</emphasis>, lets an application run on two or more parallel servers (<emphasis>nodes</emphasis>), while providing a client with a uniform view of the application. Load is distributed across servers such that if one or more servers fail, the application can still be accessed through any surviving nodes. This is crucial for scalable enterprise applications, since performance and availability can be improved just by adding nodes. However, this also provokes the question of what happens to state held on a server that fails.
+ </para>
+ <para>
+ So far, you know that Seam provides state management by including additional scopes and governing the life cycles of stateful (scoped) components. But Seam's state management goes beyond creating, storing, and destroying instances. Seam tracks changes to JavaBean components and stores those changes at strategic points during a request so that changes can be restored when the request shifts to a secondary node in the cluster. Monitoring and replicating stateful EJB components is already handled by the EJB server; Seam state management provides the same feature for stateful JavaBeans.
+ </para>
+ <para>
+ In addition to monitoring JavaBean components, Seam ensures that managed entity instances (that is, JPA and Hibernate entities) are not attached during replication. Seam keeps a record of entities to be loaded, and loads them automatically on the secondary node. <emphasis>You must be using a Seam-managed persistence context to use this feature.</emphasis> More information is provided later in this chapter<!--, under <xref linkend="" />-->.
+ </para>
+ <para>
+ Next we will take you through how to program for clustering.
+ </para>
+
+ <section id="clustering.programming">
+ <title>Programming for clustering</title>
+
+ <para>
+ Any session- or converation-scoped mutable JavaBean component to be used in a clustered environment must implement the <literal>org.jboss.seam.core.Mutable</literal> interface from the Seam API. As part of the contract, the component must maintain a <literal>dirtyflag</literal> event, which indicates whether the user has made changes to the form that must be saved. This event is reported and reset by the <literal>clearDirty()</literal> method, which is called to determine whether the component must be replicated. This lets you avoid using the Servlet API to add and remove the session attribute for every change to an object.
+ </para>
+
+ <para>
+ You must also make sure that all session- and conversation-scoped JavaBean components are <emphasis>serializable</emphasis>. All fields of a stateful component (EJB or JavaBean) must be serializable, unless marked <emphasis>transient</emphasis> or set to null in a <literal>@PrePassivate</literal> method. You can restore the value of a transient or nullified field in a <literal>@PostActivate</literal> method.
+ </para>
+ <para>
+ One area that can be problematic is in using <literal>List.subList</literal> to create a list, because the list created is not serializable. A similar situation can occur for a number of methods that create objects automatically. If you encounter a <exceptionname>java.io.NotSerializableException</exceptionname>, you can place a breakpoint on this exception and run the application server in debug mode to find the problem method.
+ </para>
+ <note>
+ <para>
+ Clustering does not work with components that are hot-deployed. Further, you should avoid using hot-deployable components in non-development environments.
+ </para>
+ </note>
+ </section>
+
+<!--hajime-->
+ <section id="clustering.deployment">
+ <title>Deploying a Seam application to a JBoss AS cluster with session replication</title>
+
+ <para>
+ The following procedure has been validated against a <application>seam-gen</application> application and the Seam Booking example.
+ </para>
+
+<para>
+ This section assumes that the IP addresses of the master and slave servers are <literal>192.168.1.2</literal> and <literal>192.168.1.3</literal>, respectively. The <literal>mod_jk</literal> load balancer was not use intentionally to make it easier to validate that both nodes are responding to requests and interchanging sessions.
+</para>
+
+<para>
+ The following log messages were generated out of the deployment of a WAR application, <filename>vehicles.war</filename>, and its corresponding datasource, <literal>vehiclesDatasource</literal>. The Booking example fully supports this process, and you can find instructions about deploying it to a cluster in the <filename>examples/booking/readme.txt</filename> file.
+</para>
+<para>
+ These instructions use the farm deployment method, but you can also deploy the application normally and let the two servers negotiate a master/slave relationship based on startup order.
+</para>
+<para>
+ All timestamps in this tutorial have been replaced with zeroes to reduce noise.
+</para>
+<note>
+ <title>A note about SELinux</title>
+ <para>
+ If your nodes are on different machines that run Red Hat Enterpise Linux or Fedora, they may not acknowledge each other automatically. JBoss AS clustering relies on the UDP (User Datagram Protocol) multi-casting provided by jGroups. The SELinux configuration that ships with RHEL and Fedora blocks these packets by default. To allow the packets, modify the <literal>iptables</literal> rules (as root). The following commands apply to an IP address that matches <literal>192.168.1.x</literal>:
+ </para>
+ <programlisting>
+ /sbin/iptables -I RH-Firewall-1-INPUT 5 -p udp -d 224.0.0.0/4 -j ACCEPT
+ /sbin/iptables -I RH-Firewall-1-INPUT 9 -p udp -s 192.168.1.0/24 -j ACCEPT
+ /sbin/iptables -I RH-Firewall-1-INPUT 10 -p tcp -s 192.168.1.0/24 -j ACCEPT
+ /etc/init.d/iptables save
+ </programlisting>
+</note>
+<note>
+ <title>A note about Stateful Session Beans</title>
+ <para>
+ If you are deploying an application with stateful session beans and HTTP Session replication to a JBoss AS cluster, your stateful session bean classes must be annotated with <literal>@Clustered</literal> (from the JBoss EJB 3.0 annotation API) or marked as <literal>clustered</literal> in the <filename>jboss.xml</filename> descriptor. For details, see the Booking example.
+ </para>
+</note>
+</section>
+<section id="clustering.tutorial">
+ <title>Tutorial</title>
+ <orderedlist>
+ <listitem>
+ <para>
+ Create two instances of JBoss AS. (To do so, just extract the <filename>zip</filename> twice.)
+ </para>
+ <para>
+ Deploy the JDBC driver to <filename>server/all/lib/</filename> on both instances if you are not using HSQLDB.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add <literal><distributable/></literal> as the first child element in <filename>WEB-INF/web.xml</filename>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Set the <varname>distributable</varname> property on <literal>org.jboss.seam.core.init</literal> to <literal>true</literal> to enable the <literal>ManagedEntityInterceptor</literal> (that is, <code><core:init distributable="true"></code> in <filename>WEB-INF/components.xml</filename>).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Ensure that you have two IP addresses available (two computers, two network cards, or two IP addresses bound to the same interface). We assume that these two IP addresses are <literal>192.168.1.2</literal> and <literal>192.168.1.3</literal>.
+ </para>
+<!--#modify: to be rewritten with info from pmuir:
+On *nix, you can bind a new IP address to a network interface using the following command:
+
+ /sbin/ifconfig eth1:2 192.168.1.3
+
+Replace eth1 with your interface name and make the IP address conform to your network.
+
+If you're on Windows, follow these steps:
+
+ - Open your network adapter
+ - Click Properties
+ - Select Internet Protocol (TCP/IP) then click Properties
+ - Click Advanced...
+ - Select the IP settings tab and click Add...
+ - Type in an IP address, click Add
+ - Click OK on all open windows
+-->
+ </listitem>
+ <listitem>
+ <para>
+ Start the master JBoss AS instance on the first IP:
+ </para>
+ <programlisting> ./bin/run.sh -c all -b 192.168.1.2</programlisting>
+ <para>
+ You should see the following in the log:
+ </para>
+ <screen>
+00:00:00,000 INFO [DefaultPartition] Number of cluster members: 1
+00:00:00,000 INFO [DefaultPartition] Other members: 0
+00:00:00,000 INFO [DefaultPartition] Fetching state (will wait for 30000 milliseconds):
+00:00:00,000 INFO [DefaultPartition] State could not be retrieved (we are the first member in group)
+ </screen>
+ </listitem>
+ <listitem>
+ <para>
+ Verify that the <filename>server/all/farm</filename> directory in the slave JBoss AS instance is empty.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Start the slave JBoss AS instance on the second IP:
+ </para>
+ <programlisting> ./bin/run.sh -c all -b 192.168.1.3</programlisting>
+ <para>
+ The log should show the following:
+ </para>
+ <screen>
+00:00:00,000 INFO [DefaultPartition] Number of cluster members: 2
+00:00:00,000 INFO [DefaultPartition] Other members: 1
+00:00:00,000 INFO [DefaultPartition] Fetching state (will wait for 30000 milliseconds):
+00:00:00,000 INFO [DefaultPartition] state was retrieved successfully (in 120 milliseconds)
+ </screen>
+ <para>In the log of the first instance, you should see acknowledgement of the new member:</para>
+ <screen>
+00:00:00,000 INFO [DefaultPartition] I am (192.168.1.2:1099) received membershipChanged event:
+00:00:00,000 INFO [DefaultPartition] Dead members: 0 ([])
+00:00:00,000 INFO [DefaultPartition] New Members : 1 ([192.168.1.3:1099])
+00:00:00,000 INFO [DefaultPartition] All Members : 2 ([192.168.1.2:1099, 192.168.1.3:1099])
+ </screen>
+ </listitem>
+ <listitem>
+ <para>
+ Deploy the <filename>-ds.xml</filename> to the <filename>server/all/farm</filename> of the master instance.
+ </para>
+ <para>
+ In the log of the master instance you should see acknowlegement of this deployment:
+ </para>
+ <screen>
+00:00:00,000 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=vehiclesDatasource' to JNDI name 'java:vehiclesDatasource'
+00:00:00,000 INFO [ClusterFileTransfer] Start push of file vehicles-ds.xml to cluster.
+00:00:00,000 INFO [ClusterFileTransfer] Finished push of file vehicles-ds.xml to cluster.
+ </screen>
+ <para>In the log of the slave instance, you should see a complementary message:</para>
+ <screen>
+00:00:00,000 INFO [FarmMemberService] farmDeployment(), deploy locally: farm/vehicles-ds.xml
+00:00:00,000 INFO [ConnectionFactoryBindingService] Unbound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=vehiclesDatasource' from JNDI name 'java:vehiclesDatasource'
+ </screen>
+ </listitem>
+ <listitem>
+ <para>
+ Deploy the application to the server/all/farm directory:
+ </para>
+ <para>
+ In the log of the master instance you should see acknowlegement of this deployment after the normal application startup messages have finished:
+ </para>
+ <screen>
+00:00:00,000 INFO [ClusterFileTransfer] Start push of file vehicles.war to cluster.
+ </screen>
+ <para>
+ Wait for the deployed archive to be transferred. (This takes approximately three minutes.) In the log of the master instance, you should see acknowledgement of this deployment prior to the normal application startup messages:
+ </para>
+ <screen>
+00:00:00,000 INFO [FarmMemberService] farmDeployment(), deploy locally: farm/vehicles.war
+ </screen>
+ <para>
+ Once the application is transferred, you should see confirmation in the log of the master instance:
+ </para>
+ <screen>
+00:00:00,000 INFO [ClusterFileTransfer] Finished push of file vehicles.war to cluster.
+ </screen>
+ <para>
+Finally, you should see the application startup messages in the slave instance log.
+ </para>
+ </listitem>
+ </orderedlist>
+<para>
+ Your application is now running in a cluster with HTTP Session replication. The next step is to validate that the clustering is working correctly.
+</para>
+ </section>
+
+ <section id="clustering.validation">
+ <title>Validating the distributable services of an application running in a JBoss AS cluster </title>
+ <para>
+ Your application now starts successfully on two different JBoss AS servers, but it is important to validate that the two instances are exchanging HTTP Sessions correctly, so that the application continues to operate with the slave instance if the master instance is stopped.
+ </para>
+ <para>
+ First, browse to the application on the master instance to start the first HTTP Session. On the same instance, open the JBoss AS JMX Console and navigate to the following managed bean:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para><emphasis>Category:</emphasis> jboss.cache</para>
+ </listitem>
+ <listitem>
+ <para><emphasis>Entry:</emphasis> service=TomcatClusteringCache</para>
+ </listitem>
+ <listitem>
+ <para><emphasis>Method:</emphasis> printDetails()</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ Invoke the <literal>printDetails()</literal> method. This will present you with a tree of active HTTP Sessions. Verify that the session used by your browser corresponds to one of the sessions on the tree.
+ </para>
+
+ <para>
+ Next, switch to the slave instance and invoke the same method in the JMX Console. You should see an identical tree under this application's context path.
+ </para>
+
+ <para>
+ That these trees are identical proves that both servers claim to have identical sessions. Next, we must test that the data is serializing and inserializing correctly.
+ </para>
+
+ <!--<para>
+ First, remove at least the <literal>JSESSIONID</literal> cookie for the <literal>192.168.1.2</literal> domain. Then, open the application on the master instance. (We used <literal>http://192.168.1.2/seam-booking/</literal>.)
+ </para>
+ <para>Create a URL for the second instance:</para>
+ <itemizedlist>
+ <listitem><para>Copy the URL in the workspace list at the bottom of the page (the Servlet path), and change the IP address to that of the slave instance. (We changed it from <literal>192.168.1.2</literal> to <literal>192.168.1.3</literal>.)</para></listitem>
+ <listitem><para>Place <literal>;jsessionid=XXXX</literal> directly after the Servlet path, where <replaceable>XXXX</replaceable> is the value of the <literal>JSESSIONID</literal> cookie of the current page.</para></listitem>
+ </itemizedlist>
+ <para>Visit this URL in a second browser which has cookies disabled. (This ensures that the session ID specified in the URL will be used.)</para>
+ <para>Complete the booking form and click the <guibutton>Proceed</guibutton> button.</para>
+ <para>Now, return to the original browser and change the URL to match the form of the confirmation page, keeping the <literal>cid</literal> request parameter, like so:</para>
+ <programlisting>http://192.168.1.2/seam-booking/confirm.seam?cid=4
+</programlisting>
+ <para>If desired, verity that you can continue without the slave instance: go to JMX console and execute the <literal>shutdown()</literal> method on <literal>jboss.system:type=Server</literal>.</para>
+ <para>Confirm the booking.</para>
+-->
+ <para>
+ Sign in via the URL of the master instance. Then, construct a URL for the second instance by placing the <literal>;jsessionid=XXXX</literal> immediately after the Servlet path and changing the IP address. (You should see that the session has carried over to the other instance.)</para>
+ <para>Now, kill the master instance and check that you can continue to use the application from the slave instance. Then, remove the deployed applications from the <filename>server/all/farm</filename> directory and restart the instance.</para>
+= <para>Change the IP in the URL back to that of the master instance, and browse to the new URL — you should see that the original session ID is still being used.</para>
+
+ <para>
+ You can watch objects passivate and activate is to create a session- or conversation-scoped Seam component and implement the appropriate life-cycle methods. You can use methods from the <literal>HttpSessionActivationListener</literal> interface (which is automatically registered on all non-EJB components):</para>
+ <programlisting role="JAVA">
+<![CDATA[public void sessionWillPassivate(HttpSessionEvent e);
+public void sessionDidActivate(HttpSessionEvent e);]]>
+ </programlisting>
+ <para>
+ Alternatively, you can mark two public void methods (without arguments) with <literal>@PrePassivate</literal> and <literal>@PostActivate</literal> respectively. Remember that passivation will occur at the end of every request, while activation will occur when a node is called.
+ </para>
+ <para>
+ In order to make replication transparent, Seam automatically keeps track of objects that have been changed. All that you need to do is maintain a <literal>dirtyflag</literal> on your session- or conversation-scoped component, and Seam will handle JPA entity instances for you.
+ </para>
+<!--Warning is unhelpful, but uncomment if required.
+ <warning>
+ <para>
+ Transient fields are not always reinitialized. This problem has been resolved with a patch to the <literal>SecurityInterceptor</literal>, but may occur elsewhere.
+ </para>
+ </warning>-->
+ </section>
+ </section>
+
+ <section>
+ <title>EJB Passivation and the ManagedEntityInterceptor</title>
+
+ <para>
+ The <literal>ManagedEntityInterceptor</literal> (MEI) is an optional interceptor in Seam. When enabled, it is applied to conversation-scoped components. To enable the MEI, set <varname>distributable</varname> to <literal>true</literal> on the <literal>org.jboss.seam.init.core</literal> component. You can also add or update the following component declaration in your <filename>components.xml</filename> file:
+ </para>
+
+ <programlisting role="XML"><![CDATA[<core:init distributable="true"/>]]></programlisting>
+
+ <para>
+ This does not enable HTTP Session replication, but it does let Seam handle the passivation of either EJB components or components in the HTTP Session.
+ </para>
+
+ <para>
+ The MEI ensures that, throughout the life of a conversation with at least one extended persistence context, any entity instances loaded by the persistence context remain managed — that is, they are not prematurely detached by a passivation event. This ensures the integrity of the extended persistence context, and therefore the integrity of its guarantees.</para>
+ <para>
+ There are two situations that threaten integrity: the passivation of a stateful session bean that hosts an extended persistence context, and the passivation of the HTTP Session.</para>
+
+ <section>
+ <title>The friction between passivation and persistence</title>
+
+ <para>
+ The <emphasis>persistence context</emphasis> is used to store entity instances (objects) that the persistence manager has loaded from the database. There is only ever one object per unique database record in a persistence context. It is often referred to as the <emphasis>first-level cache</emphasis> because it allows an application to avoid a call to the database when a record has been loaded into the persistence context.</para>
+ <para>
+ Objects in the persistence context can be modified, and once modified they are considered <emphasis>dirty</emphasis>. Changes are tracked by the persistence manager, which then migrates these changes to the database when necessary. The persistence context, therefore, maintains a set of pending changes to the database.
+ </para>
+ <para>
+ Database-oriented applications capture transactional information that must be transferred into the database immediately. This information cannot always be captured in one screen, and the user may need to decide whether to accept or reject the pending changes.</para>
+ <para>
+ These aspects of transactions have not necessarily been apparent from the user's perspective. The extended persistence context extends the user's understanding of transactions. It can hold changes for as long as the application requires, and then push these pending changes to the database via built-in persistence manager capabilities (<literal>EntityManager#flush()</literal>).
+ </para>
+ <para>
+ The persistence manager is linked to an entity instance via an <emphasis>object reference</emphasis>. Entity instances can be serialized, but the persistence manager cannot. Serialization can occur when either a stateful session bean or the HTTP Session is passivated. For the application to continue its activity, the relationship between the persistence manager and its entity instances must be maintained. MEI provides this support.</para>
+ </section>
+
+ <section>
+ <title>Case #1: Surviving EJB passivation</title>
+
+ <para>
+ Conversations were initially designed for stateful session beans because the EJB3 specification defines stateful session beans as the hosts of the extended persistence context. Seam introduces the <emphasis>Seam-managed persistence context</emphasis>, which works around a number of limitations in the specification. Both contexts can be used with stateful session beans.
+ </para>
+ <para>
+ For a stateful session bean to remain active, a client must hold a reference to the stateful session bean. Seam's conversation context is an ideal location for this reference, which means that the stateful session bean remains active for the duration of the conversation context. Further, <literal>EntityManager</literal>s that are injected into the stateful session bean with the <literal>@PersistenceContext(EXTENDED)</literal> annotation will be bound to the stateful session bean and remain active for the bean's lifetime. <literal>EntityManager</literal>s injected with the <literal>@In</literal> annotation are maintained by Seam and stored directly in the converstion context, so they remain active for the duration of the <emphasis>conversation</emphasis>, independent of the stateful session bean.
+ </para>
+ <para>
+ The Java EE container can also passivate a stateful session bean, but this method can be problematic. Rather than making the container responsible for this process, after each invocation of the stateful session bean, Seam transfers the reference to the entity instance from the stateful session bean to the current conversation, and therefore into the HTTP Session. This nullifies the associated fields on the stateful session bean. Seam then restores these references at the beginning of the subsequent invocation. Because Seam already stores the persistence manager in the conversation, stateful session bean passivation and activation has no adverse effect on the application.</para>
+
+ <important>
+ <para>
+ If your application uses stateful session beans that hold references to extended persistence contexts, and those beans can passivate, then you <emphasis>must</emphasis> use the MEI, regardless of whether you use a single instance or a cluster.
+ </para>
+ </important>
+
+ <para><!--#modify: add details here?-->
+ You can disable passivation on stateful session beans. See the <ulink
+ url="http://www.jboss.org/community/docs/DOC-9656">Ejb3DisableSfsbPassivation</ulink> page on the JBoss
+ Wiki for details.
+ </para>
+ </section>
+
+ <section>
+ <title>Case #2: Surviving HTTP session replication</title>
+
+ <para>
+ The HTTP Session is used when passivating stateful session beans, but in clustered environments that have enabled session replication, the HTTP Session can also be passivated. Since the persistence manager cannot be serialized, passivating the HTTP Session would normally involve destroying the persistence manager.</para>
+ <para>
+ When an entity instance is first placed into a conversation, Seam embeds the instance in a wrapper that contains information about reassociating the instance with the persistence manager post-serialization. When the application changes nodes (when a server fails, for instance), Seam's MEI reconstructs the persistence context. The persistence context is reconstructed from the database, so pending changes to the instance are lost. However, Seam's optimistic locking ensures that, where files have changed, only the most recent changes are accepted where multiple versions of an instance occur.
+ </para>
+
+ <important>
+ <para>
+ If your application is deployed in a cluster with HTTP Session replication, you <emphasis>must</emphasis> use the MEI.
+ </para>
+ </important>
+ </section>
+ </section>
+</chapter>
+
Modified: projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Gettingstarted.xml
===================================================================
--- projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Gettingstarted.xml 2009-08-06 23:18:24 UTC (rev 92094)
+++ projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Gettingstarted.xml 2009-08-07 00:19:05 UTC (rev 92095)
@@ -19,19 +19,19 @@
Make sure you have JDK 5 or JDK 6 (see <xref linkend="jdk_dependencies" /> for details), JBoss AS 4.2 or 5.0 and <!-- #modify: Check Ant version; I thought we needed earlier versions to work with Seam? -->Ant 1.7.0, along with recent versions of Eclipse, the JBoss IDE plugin for Eclipse and the TestNG plugin for Eclipse correctly installed before you begin this tutorial. Add your JBoss installation to the JBoss Server View in Eclipse. Then, start JBoss in debug mode. Finally, start a command prompt in the directory where you unzipped the Seam distribution.
</para>
<para>
- Jboss has sophisticated support for hot redeployment of <filename>WAR</filename>s and <filename>EAR</filename>s. Unfortunately, due to bugs in JVM, repeat redeployment of an EAR (common during development) uses all of the JVM's perm gen space. Therefore, we recommend running JBoss in a JVM with a large perm gen space during development. If you are running JBoss from JBoss IDE, you can configure this in the server launch configuration, under "VM arguments". We suggest the following values:
+ JBoss has sophisticated support for hot redeployment of <filename>WAR</filename>s and <filename>EAR</filename>s. Unfortunately, due to bugs in JVM, repeat redeployment of an EAR (common during development) uses all of the JVM's perm gen space. Therefore, we recommend running JBoss in a JVM with a large perm gen space during development. If you are running JBoss from JBoss IDE, you can configure this in the server launch configuration, under "VM arguments". We suggest the following values:
</para>
<programlisting>-Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m
</programlisting>
<para>
- If you don't have so much memory available, the following is our minimum recommendation:
+ The minimum recommended values are:
</para>
<programlisting>-Xms256m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m
</programlisting>
<para>
- If you're running JBoss from the command line, you can configure the JVM options in <literal>bin/run.conf</literal>.
+ If you are running JBoss from the command line, you can configure the JVM options in <filename>bin/run.conf</filename>.
</para>
</section>
Modified: projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Performance.xml
===================================================================
--- projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Performance.xml 2009-08-06 23:18:24 UTC (rev 92094)
+++ projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Performance.xml 2009-08-07 00:19:05 UTC (rev 92095)
@@ -10,7 +10,7 @@
<section>
<title>Bypassing Interceptors</title>
<para>
- For repetitive value bindings such as those found in a JavaServer Faces (JSF) dataTable, or in iterative controls like <literal>ui:repeat</literal>, the full interceptor stack is invoked upon each invocation of the referenced Seam component. This can substantially decrease performance, particularly if the component is accessed many times. You can improve performance by disabling the interceptor stack for the invoked Seam component —annotate the component class with <literal>@BypassInterceptors</literal>.
+ For repetitive value bindings such as those found in a JavaServer Faces (JSF) dataTable, or in iterative controls such as <literal>ui:repeat</literal>, the full interceptor stack is invoked upon each invocation of the referenced Seam component. This can substantially decrease performance, particularly if the component is accessed many times. You can improve performance by disabling the interceptor stack for the invoked Seam component —annotate the component class with <literal>@BypassInterceptors</literal>.
</para>
<warning>
<para>
Modified: projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Revision_History.xml 2009-08-06 23:18:24 UTC (rev 92094)
+++ projects/docs/enterprise/5.0/Seam_Reference_Guide/en-US/Revision_History.xml 2009-08-07 00:19:05 UTC (rev 92095)
@@ -4,16 +4,16 @@
<revhistory lang="en-US">
<revision>
- <revnumber>5.0.0</revnumber>
- <date>Feb 07 2008</date>
+ <revnumber>6.0.0</revnumber>
+ <date>Aug 05 2009</date>
<author>
- <firstname>Samson</firstname>
- <surname>Kittoli</surname>
+ <firstname>Laura</firstname>
+ <surname>Bailey</surname>
<email></email>
</author>
<revdescription>
<simplelist>
- <member>content reformat</member>
+ <member>revised structure</member>
</simplelist>
</revdescription>
</revision>
More information about the jboss-cvs-commits
mailing list