You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@myfaces.apache.org by im...@apache.org on 2007/08/21 20:52:39 UTC
svn commit: r568230 - in /myfaces/orchestra/trunk/core/src:
main/java/org/apache/myfaces/orchestra/conversation/spring/ site/ site/xdoc/
Author: imario
Date: Tue Aug 21 11:52:38 2007
New Revision: 568230
URL: http://svn.apache.org/viewvc?rev=568230&view=rev
Log:
fixed bug in flash scope. added Simon's documentation
Added:
myfaces/orchestra/trunk/core/src/site/xdoc/glossary.xml
- copied, changed from r568225, myfaces/orchestra/trunk/core/src/site/xdoc/introduction.xml
Modified:
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/SpringConversationScope.java
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/SpringFlashScope.java
myfaces/orchestra/trunk/core/src/site/site.xml
myfaces/orchestra/trunk/core/src/site/xdoc/installation.xml
myfaces/orchestra/trunk/core/src/site/xdoc/introduction.xml
Modified: myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/SpringConversationScope.java
URL: http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/SpringConversationScope.java?rev=568230&r1=568229&r2=568230&view=diff
==============================================================================
--- myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/SpringConversationScope.java (original)
+++ myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/SpringConversationScope.java Tue Aug 21 11:52:38 2007
@@ -150,6 +150,7 @@
// get the conversation
Conversation conversation = manager.getConversation(conversationName);
+ notifyAccessConversation(conversation);
synchronized(conversation)
{
if (!conversation.hasAttribute(beanName))
@@ -177,6 +178,10 @@
// get the bean
return conversation.getAttribute(beanName);
+ }
+
+ protected void notifyAccessConversation(Conversation conversation)
+ {
}
protected ConversationPolicy getConversationPolicy()
Modified: myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/SpringFlashScope.java
URL: http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/SpringFlashScope.java?rev=568230&r1=568229&r2=568230&view=diff
==============================================================================
--- myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/SpringFlashScope.java (original)
+++ myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/SpringFlashScope.java Tue Aug 21 11:52:38 2007
@@ -37,15 +37,8 @@
return ConversationPolicy.FLASH;
}
- protected Conversation getConversationForBean(String beanName)
+ protected void notifyAccessConversation(Conversation conversation)
{
- Conversation conv = super.getConversationForBean(beanName);
-
- if (conv != null)
- {
- FlashManager.getInstance().addConversationAccess(conv.getName());
- }
-
- return conv;
+ FlashManager.getInstance().addConversationAccess(conversation.getName());
}
}
Modified: myfaces/orchestra/trunk/core/src/site/site.xml
URL: http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/site/site.xml?rev=568230&r1=568229&r2=568230&view=diff
==============================================================================
--- myfaces/orchestra/trunk/core/src/site/site.xml (original)
+++ myfaces/orchestra/trunk/core/src/site/site.xml Tue Aug 21 11:52:38 2007
@@ -61,6 +61,7 @@
<menu name="MyFaces Orchestra - Core">
<item name="Introduction and Glossary" href="introduction.html"/>
+ <item name="Glossary" href="glossary.html"/>
<item name="Installation" href="installation.html"/>
<item name="Conversation API Usage" href="usage.html"/>
<item name="ViewController" href="viewController.html"/>
Copied: myfaces/orchestra/trunk/core/src/site/xdoc/glossary.xml (from r568225, myfaces/orchestra/trunk/core/src/site/xdoc/introduction.xml)
URL: http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/site/xdoc/glossary.xml?p2=myfaces/orchestra/trunk/core/src/site/xdoc/glossary.xml&p1=myfaces/orchestra/trunk/core/src/site/xdoc/introduction.xml&r1=568225&r2=568230&rev=568230&view=diff
==============================================================================
--- myfaces/orchestra/trunk/core/src/site/xdoc/introduction.xml (original)
+++ myfaces/orchestra/trunk/core/src/site/xdoc/glossary.xml Tue Aug 21 11:52:38 2007
@@ -26,207 +26,147 @@
</properties>
<body>
- <section name="Apache MyFaces Orchestra">
- <p>Apache MyFaces Orchestra aims to
- simplify developers life when it comes to build web based applications,
- especially when they build on a persistence layer including object-relational-mapping tools
- such as a JPA implementation (e.g. Toplink or Hibernate).
- </p>
- <p>Whoever has web-application development experience with an ORM layer
- has run into exceptions like the dreaded LazyInitializationException
- or the NonUniqueObjectException that occurs if you try to
- <code>merge</code>
- your detached
- objects back into the persistence session. Most of those problems, if not all, result
- from the fact that a persistence session is opened and closed for each HTTP request.
- In this case, the ORM tool has no chance to manage your entities for the duration of a
- business process - once you close a persistence layer session at the end of the HTTP request,
- all entities are detached from the persistence layer session.
- </p>
- <p> So, the magic is to keep such a persistence session open
- as long as required, but as short as possible; contrary to the often
- propagated OpenSessionInView or OpenSessionPerRequest-patterns. In those patterns,
- the session is closed too early for completing a full business process. Keeping the session
- alive for exactly the necessary timespan is one of the cool features of Apache MyFaces Orchestra.
- </p>
- <p> The demarcation of such a timespan is defined by
- a conversation in Orchestra. A conversation is completely detached from the pageflow,
- it doesn't matter if the conversation spans multiple requests on a single page or multiple pages.
- </p>
- <p>A conversation scope is like the
- request or session scope a place where you can store your beans. A conversation-scoped
- bean will have an attached entity manager which is in use for each database access until
- the application ends the conversation.
- </p>
- <p>There is a lot of ambiguous wording in the area of persistence; before we start we'll provide some definitions
- so that we talk about the same concepts in the same words.
- </p>
- <subsection
- name="Glossary">
- <ul>
- <li>POJO
- <br/>
- A plain-old-Java-object, according to the Java bean standard.
- This is a class with (mostly) private members and a get- and set-method
- (also called getter and setter) for each of them. The original aim
- of object-relational mapping tools was to persist such pojos into the database with the
- help of e.g. an external xml configuration per pojo. When Java 5 came
- up this changed a bit, now it is common to use annotations in the Java
- source itself. With that, strictly spoken, beans are not pojos anymore.
- </li>
-
- <li>Entity
- <br/>
- A pojo with an extended description. The description allows the entitiy
- manger to persist the entity into the database. Common
- descriptions are XML files or annotations in the Java source. This
- data is called metadata.
- </li>
-
- <li>Property
- <br/>
- A property is a member variable of your pojo with a defined
- set and get method. You have to follow the Java Bean
- specification. The following examples show this syntax -
- the first column, named property, shows how you would access
- this property from the outside (e.g. via reflection or from a JSF-JSP-page).
- The second column shows the syntax of defining the member, the next columns
- the name of getter and setter.
- <table width="40%">
- <tr>
- <th>property</th>
-
- <th>member</th>
-
- <th>getter</th>
-
- <th>setter</th>
- </tr>
-
- <tr>
- <td>userId</td>
-
- <td>private String userId</td>
-
- <td>getUserId</td>
-
- <td>setUserId</td>
- </tr>
-
- <tr>
- <td>userName</td>
-
- <td>private String _userName</td>
-
- <td>getUserName</td>
-
- <td>setUserName</td>
- </tr>
-
- <tr>
- <td>displayed</td>
-
- <td>private boolean displayed</td>
-
- <td>isDisplayed</td>
-
- <td>setDisplayed</td>
- </tr>
-
- </table>
- </li>
-
- <li>Entity Manager
- <br/>
- The "entity manager" manages all your entities,
- keeps track of property updates and issues the database statements
- required to synchronize the entity state with the database. If you
- close an entity manager you will loose the coupling between its
- internal state and your entities, they are so called "detached objects"
- afterwards.
- </li>
-
- <li>Entity Manager Factory
- <br/>
- The "entity manager factory" is
- responsible for processing all the entity metadata and to create an
- entity manager based on it.
- </li>
-
- <li>DAO - Data Access Object
- <br/>
- Usage of data access objects is based on the pattern with the same name. Data access
- objects are singletons which contain
- all of the database requests your application will issue - generally, one data access object
- encapsulates all database requests for one entity.
- Thus, the DAO is injected with an entity
- manager.
- </li>
-
- <li>Conversation
- <br/>
- A conversation is the time-span encapsulating all the
- operations in your business logic required to finish a process
- (in the end, this will almost always include the need for executing database transactions).
- Other names of this principle are: application transaction, unit-of-work
- </li>
-
- <li>Session Scope
- <br/>
- The session scope of your servlet container.
- Beans put into this scope live until the configured inactivity timout
- for the session has been reached or the session is closed explicitly
- </li>
-
- <li>Request Scope
- <br/>
- The request scope of your servlet container.
- The lifetime of request-scoped-beans is as long as the duration of a
- single HTTP request. Once the servlet container finishes sending
- the page data, the request will die and with it all the beans put into
- this scope.
- </li>
-
- <li>JPA - Java Persistence API
- <br/>
- The JPA standardizes the way how
- you annotate your entities with regards to persistence. That way you can change the
- ORM tool as long as the ORM tool follows the JPA
- specification.
- </li>
-
- <li>backing bean
- <br/>
- A backing bean is the bean behind a JSF view
- (jsp, facelet, etc page). While JSF does not require such a bean, it is
- good practice to provide one backing-bean per page as a rule of thumb.
- </li>
- </ul>
- </subsection>
- <subsection name="Structure">As of now, the Apache
- MyFaces Orchestra project contains 3 modules.
- <ul>
- <li>core
- <br/>
- The core module is compatible with Java 1.4 - which means that you are
- able to use all this convenient stuff without the need to migrate to
- Java 5.0
- </li>
-
- <li>core15
- <br/>
- Ok, we admit, we couldn't resist, this package will contain
- Java 5.0 enhancements to the core, so that you get some of the cool new annotation based
- stuff as well.
- </li>
-
- <li>examples
- <br/>
- The examples module includes a demo app (one currently) showing off many of Orchestra's
- features.
- </li>
- </ul>
- </subsection>
+ <section
+ name="Glossary">
+ <ul>
+ <li>POJO
+ <br/>
+ A plain-old-Java-object, according to the Java bean standard.
+ This is a class with (mostly) private members and a get- and set-method
+ (also called getter and setter) for each of them. The original aim
+ of object-relational mapping tools was to persist such pojos into the database with the
+ help of e.g. an external xml configuration per pojo. When Java 5 came
+ up this changed a bit, now it is common to use annotations in the Java
+ source itself. With that, strictly spoken, beans are not pojos anymore.
+ </li>
+
+ <li>Entity
+ <br/>
+ A pojo with an extended description. The description allows the entitiy
+ manger to persist the entity into the database. Common
+ descriptions are XML files or annotations in the Java source. This
+ data is called metadata.
+ </li>
+
+ <li>Property
+ <br/>
+ A property is a member variable of your pojo with a defined
+ set and get method. You have to follow the Java Bean
+ specification. The following examples show this syntax -
+ the first column, named property, shows how you would access
+ this property from the outside (e.g. via reflection or from a JSF-JSP-page).
+ The second column shows the syntax of defining the member, the next columns
+ the name of getter and setter.
+ <table width="40%">
+ <tr>
+ <th>property</th>
+
+ <th>member</th>
+
+ <th>getter</th>
+
+ <th>setter</th>
+ </tr>
+
+ <tr>
+ <td>userId</td>
+
+ <td>private String userId</td>
+
+ <td>getUserId</td>
+
+ <td>setUserId</td>
+ </tr>
+
+ <tr>
+ <td>userName</td>
+
+ <td>private String _userName</td>
+
+ <td>getUserName</td>
+
+ <td>setUserName</td>
+ </tr>
+
+ <tr>
+ <td>displayed</td>
+
+ <td>private boolean displayed</td>
+
+ <td>isDisplayed</td>
+
+ <td>setDisplayed</td>
+ </tr>
+
+ </table>
+ </li>
+
+ <li>Entity Manager
+ <br/>
+ The "entity manager" manages all your entities,
+ keeps track of property updates and issues the database statements
+ required to synchronize the entity state with the database. If you
+ close an entity manager you will loose the coupling between its
+ internal state and your entities, they are so called "detached objects"
+ afterwards.
+ </li>
+
+ <li>Entity Manager Factory
+ <br/>
+ The "entity manager factory" is
+ responsible for processing all the entity metadata and to create an
+ entity manager based on it.
+ </li>
+
+ <li>DAO - Data Access Object
+ <br/>
+ Usage of data access objects is based on the pattern with the same name. Data access
+ objects are singletons which contain
+ all of the database requests your application will issue - generally, one data access object
+ encapsulates all database requests for one entity.
+ Thus, the DAO is injected with an entity
+ manager.
+ </li>
+
+ <li>Conversation
+ <br/>
+ A conversation is the time-span encapsulating all the
+ operations in your business logic required to finish a process
+ (in the end, this will almost always include the need for executing database transactions).
+ Other names of this principle are: application transaction, unit-of-work
+ </li>
+
+ <li>Session Scope
+ <br/>
+ The session scope of your servlet container.
+ Beans put into this scope live until the configured inactivity timout
+ for the session has been reached or the session is closed explicitly
+ </li>
+
+ <li>Request Scope
+ <br/>
+ The request scope of your servlet container.
+ The lifetime of request-scoped-beans is as long as the duration of a
+ single HTTP request. Once the servlet container finishes sending
+ the page data, the request will die and with it all the beans put into
+ this scope.
+ </li>
+
+ <li>JPA - Java Persistence API
+ <br/>
+ The JPA standardizes the way how
+ you annotate your entities with regards to persistence. That way you can change the
+ ORM tool as long as the ORM tool follows the JPA
+ specification.
+ </li>
+
+ <li>backing bean
+ <br/>
+ A backing bean is the bean behind a JSF view
+ (jsp, facelet, etc page). While JSF does not require such a bean, it is
+ good practice to provide one backing-bean per page as a rule of thumb.
+ </li>
+ </ul>
</section>
</body>
</document>
Modified: myfaces/orchestra/trunk/core/src/site/xdoc/installation.xml
URL: http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/site/xdoc/installation.xml?rev=568230&r1=568229&r2=568230&view=diff
==============================================================================
--- myfaces/orchestra/trunk/core/src/site/xdoc/installation.xml (original)
+++ myfaces/orchestra/trunk/core/src/site/xdoc/installation.xml Tue Aug 21 11:52:38 2007
@@ -113,6 +113,15 @@
</property>
</bean>
</entry>
+ <entry key="flash">
+ <bean class="org.apache.myfaces.orchestra.conversation.spring.SpringFlashScope">
+ <property name="advices">
+ <list>
+ <ref bean="persistentContextConversationInterceptor"/>
+ </list>
+ </property>
+ </bean>
+ </entry>
</map>
</property>
</bean>
@@ -175,6 +184,11 @@
allows you to configure a number of advices. Advices intercept each
method call to your bean. We build on this mechanism to configure the
entity manager appropriately.
+ <br />
+ We also configure a "flash" scope which allows us to keep beans as long
+ as a page has a reference to it. Once a page has been rendered
+ and the bean were not accessed it will be destroyed - the conversation
+ automatically ends.
<br/>
If your application does not have to
deal with persistence, and you would still like to use the conversation
Modified: myfaces/orchestra/trunk/core/src/site/xdoc/introduction.xml
URL: http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/site/xdoc/introduction.xml?rev=568230&r1=568229&r2=568230&view=diff
==============================================================================
--- myfaces/orchestra/trunk/core/src/site/xdoc/introduction.xml (original)
+++ myfaces/orchestra/trunk/core/src/site/xdoc/introduction.xml Tue Aug 21 11:52:38 2007
@@ -61,148 +61,142 @@
<p>There is a lot of ambiguous wording in the area of persistence; before we start we'll provide some definitions
so that we talk about the same concepts in the same words.
</p>
- <subsection
- name="Glossary">
+
+
+ <subsection name="The Conversation Scope problem">
+ <p>
+ Often a logical operation consists of multiple JSF requests to the server.
+ For example, purchasing an insurance policy requires completing a number
+ of related forms (often referred to as a "conversation" or a "dialog"),
+ during which the same java objects need to be kept in memory.
+ </p>
+
+ <p>
+ However JSF provides only three scopes for data to be stored in:
+ <ul>
+ <li>Application scope</li>
+ <li>Session scope</li>
+ <li> Request scope</li>
+ </ul>
+ </p>
+
+ <p>
+ Application scope is only rarely of use; such data is shared across all users of that JSF application.
+ Request scope is not useful for the above scenario; all data stored in request scope is discarded at
+ the end of each "command".
+ </p>
+
+ <p>
+ Session scope can be used to hold data across multiple requests (a conversation),
+ but suffers from a number of other issues:
+ <ul>
+ <li>When the conversation is complete, it is best to discard all the related objects in order
+ to save memory. However this is quite difficult to do when using session scope.</li>
+ <li>The user cannot have multiple windows open on the same site. Sessions are typically
+ tracked using cookies, and all windows associated with the same browser instance
+ share cookies and therefore are within the same "session". If two windows are created
+ for the same session then very strange effects can be caused due to the same "backing beans"
+ being used by the two windows. Note that JSF implementations generally provide support for
+ multiple concurrent windows (eg MyFaces and Sun RI) but this only means that the JSF
+ *components* are safe for use with multiple windows; any application that uses only
+ request-scope beans will therefore work correctly but apps with session-scoped beans
+ will still suffer confusion.
+ </li>
+ </ul>
+ </p>
+
+ <p>
+ The Tomahawk library provides a partial solution to this conversation problem with
+ the t:saveState tag, which allows data stored in request scope to be passed
+ through to a subsequent request. However this can be difficult to use, as every
+ bean that needs to be part of the conversation needs to be explicitly tracked.
+ </p>
+
+ <p>
+ The Orchestra library provides another alternative.
+ This solution works across all JSF implementations (particularly Apache MyFaces and
+ the Sun Reference Implementation). It works for Java 1.4 or later. If java1.5 is
+ being used then custom annotations are available to make its use even easier.
+ This solution does require that the Spring Framework be used to declare
+ conversation-scoped managed beans rather than the standard JSF facility. However
+ there are many other good reasons to use Spring...
+ </p>
+
+ <p>
+ Various other projects (JBoss Seam, Apache Shale Dialogs) provide
+ conversation/dialog support that is similar to Orchestra. See
+ the Orchestra wiki pages for up-to-date comparisons of Orchestra with other projects.
+ </p>
+ </subsection>
+
+ <subsection name="Orchestra Conversation Scope Features">
+ <p>
+ The normal behaviour for JSF is that when an EL expression references a
+ bean that cannot be found anywhere in the current scopes, the managed bean
+ declarations are searched for the specified name. If a match is found then
+ the bean declaration is used to create an appropriate object instance and
+ insert it into the appropriate scope. The JSF standard provides a way for
+ variable lookup to be extended, and Spring provides an adapter that makes Spring
+ bean declarations accessable to JSF just like managed beans declared in the standard manner.
+ </p>
+
+ <p>
+ While "managed beans" declared using the standard JSF syntax can only be declared with
+ app, session or request scope it is possible with Spring 2.0 to declare custom scopes,
+ including "conversation". When a bean is instantiated which is declared to be part of
+ "conversation Foo" then the conversation with that name is looked up and the bean inserted into it.
+ This scope is user-specific (ie is a child of the session scope) and is created if it doesn't yet exist.
+ </p>
+
+ <p>
+ So far, the effect is just the same as using "session" scope for these beans.
+ However a conversation acts as a "container" for all the beans configured
+ with a particular conversation name. When a conversation ends, all beans
+ associated with that conversation can then be discarded together which is
+ difficult to achieve with simple session storage. A conversation can be
+ terminated in a number of ways:
<ul>
- <li>POJO
- <br/>
- A plain-old-Java-object, according to the Java bean standard.
- This is a class with (mostly) private members and a get- and set-method
- (also called getter and setter) for each of them. The original aim
- of object-relational mapping tools was to persist such pojos into the database with the
- help of e.g. an external xml configuration per pojo. When Java 5 came
- up this changed a bit, now it is common to use annotations in the Java
- source itself. With that, strictly spoken, beans are not pojos anymore.
- </li>
-
- <li>Entity
- <br/>
- A pojo with an extended description. The description allows the entitiy
- manger to persist the entity into the database. Common
- descriptions are XML files or annotations in the Java source. This
- data is called metadata.
- </li>
-
- <li>Property
- <br/>
- A property is a member variable of your pojo with a defined
- set and get method. You have to follow the Java Bean
- specification. The following examples show this syntax -
- the first column, named property, shows how you would access
- this property from the outside (e.g. via reflection or from a JSF-JSP-page).
- The second column shows the syntax of defining the member, the next columns
- the name of getter and setter.
- <table width="40%">
- <tr>
- <th>property</th>
-
- <th>member</th>
-
- <th>getter</th>
-
- <th>setter</th>
- </tr>
-
- <tr>
- <td>userId</td>
-
- <td>private String userId</td>
-
- <td>getUserId</td>
-
- <td>setUserId</td>
- </tr>
-
- <tr>
- <td>userName</td>
-
- <td>private String _userName</td>
-
- <td>getUserName</td>
-
- <td>setUserName</td>
- </tr>
-
- <tr>
- <td>displayed</td>
-
- <td>private boolean displayed</td>
-
- <td>isDisplayed</td>
-
- <td>setDisplayed</td>
- </tr>
-
- </table>
- </li>
-
- <li>Entity Manager
- <br/>
- The "entity manager" manages all your entities,
- keeps track of property updates and issues the database statements
- required to synchronize the entity state with the database. If you
- close an entity manager you will loose the coupling between its
- internal state and your entities, they are so called "detached objects"
- afterwards.
- </li>
-
- <li>Entity Manager Factory
- <br/>
- The "entity manager factory" is
- responsible for processing all the entity metadata and to create an
- entity manager based on it.
- </li>
-
- <li>DAO - Data Access Object
- <br/>
- Usage of data access objects is based on the pattern with the same name. Data access
- objects are singletons which contain
- all of the database requests your application will issue - generally, one data access object
- encapsulates all database requests for one entity.
- Thus, the DAO is injected with an entity
- manager.
- </li>
-
- <li>Conversation
- <br/>
- A conversation is the time-span encapsulating all the
- operations in your business logic required to finish a process
- (in the end, this will almost always include the need for executing database transactions).
- Other names of this principle are: application transaction, unit-of-work
- </li>
-
- <li>Session Scope
- <br/>
- The session scope of your servlet container.
- Beans put into this scope live until the configured inactivity timout
- for the session has been reached or the session is closed explicitly
- </li>
-
- <li>Request Scope
- <br/>
- The request scope of your servlet container.
- The lifetime of request-scoped-beans is as long as the duration of a
- single HTTP request. Once the servlet container finishes sending
- the page data, the request will die and with it all the beans put into
- this scope.
- </li>
-
- <li>JPA - Java Persistence API
- <br/>
- The JPA standardizes the way how
- you annotate your entities with regards to persistence. That way you can change the
- ORM tool as long as the ORM tool follows the JPA
- specification.
- </li>
-
- <li>backing bean
- <br/>
- A backing bean is the bean behind a JSF view
- (jsp, facelet, etc page). While JSF does not require such a bean, it is
- good practice to provide one backing-bean per page as a rule of thumb.
- </li>
+ <li>a JSF endConversation component is provided that can be inserted into a page;</li>
+ <li>a direct call can be made from a backing bean, eg after performing a "save" or "cancel" operation;</li>
+ <li>flash conversations end when a request occurs that does not access any bean in that conversation;</li>
+ <li>a conversation timeout can be configured to automatically expire conversations after a specified time limit.</li>
</ul>
+ And as conversations have names, multiple conversations (bean groupings) can exist concurrently.
+ </p>
+
+ <p>
+ Conversation names are declared simply by specifying attribute orchestra:conversationName on
+ the Spring bean definition. If no name is provided, then the bean is placed in its own
+ private conversation (which happens to have a name equal to the bean name).
+ </p>
+
+ <p>
+ A conversation can have a "policy" of "manual" or "flash".
+ A "flash" conversation is automatically ended (ie deleted) if a request is executed
+ which does not reference any bean in that conversation's scope. This is
+ very convenient when a sequence of pages all have at least one reference
+ to a bean of that conversation scope. If the user navigates to any other
+ page (via direct url entry, or clicking a link, etc) then after that new page is
+ rendered the old (obsolete) conversation scope is automatically discarded. Only
+ when a user's path through the application can reference pages that do not reference
+ conversation-scoped beans is the manual conversation necessary - and in that case, an
+ explicit endConversation component (or direct API call) must be used to discard beans
+ when no longer needed.
+ </p>
+
+ <p>
+ Orchestra also provides the concept of a "conversation context", which holds
+ a set of named conversations. A "separateConversationContext" JSF component
+ creates a new context. When this is a parent of any command component
+ (eg a commandLink) then a new conversation context is automatically
+ created when that command is executed. This allows multiple windows
+ to access the same site while having completely independent sets of
+ objects that are of "conversation scope". A hidden "id" emitted into
+ pages specifies what the current conversation context is, ensuring the
+ new windows "sticks" with its associated conversation context.
+ </p>
</subsection>
+
<subsection name="Structure">As of now, the Apache
MyFaces Orchestra project contains 3 modules.
<ul>