Just a followup from my adventures with http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90169. My root problem turned out to be the Seam practice of redirecting to the displayed page when you return the page itself from your action (see below). My reading of the reference manual led me to believe that Seam passed ALL of the contextual information to the view, even when there was a redirect. While it didn't really make sense to me that request (EVENT scope) data would survive a redirect, I had concluded that Seam was doing some sort of magic to accomplish this. I have now concluded that I was wrong.
I was returning the actual view path from my action methods, like "/Document.xhtml". As mentioned in the manual, this does a redirect to the page. Because of that, the only data that gets preserved is the stuff stored in the session or application context (including long running conversations).
I imagine most of you are saying "well, duh" about now, but I really did believe that Seam was magically taking care of all this! And the Seam examples reinforced my beliefs simply because they tend to promote the Conversation feature of Seam, which stores stuff in the Session, or provide stateless actions with SESSION scoped beans.
Anyway, the solution for me was to define "navigation-case" entries for my pages WITHOUT the "redirect" tag included, like this:
<navigation-rule> <navigation-case> <from-outcome>document</from-outcome> <to-view-id>/Document.xhtml</to-view-id> </navigation-case> </navigation-rule>
I love the conversation idea for things like editing data, where there's a well defined entry and one or more exit points to a workflow. However, most of the rest of my app is made up of "open ended" conversations. Many requests are a typical example of an old CMP style request, where there is no need to store state between requests, and it's impractical to do so because of memory usage on the server. Maybe this is a reflection of imposing the old architecture, but for the most part the workflow is driven by business requirements.
Now that I understand more of the details of how scope works (and have stumbled over the obvious fact that redirects wipe out a lot of state), I can easily mix SESSION, EVENT, and CONVERSATION scoped objects and actions into my app.
In terms of the reference manual, I would like to request the following:
1. Add a new example (or revamp an existing one) to highlight the "mostly stateless" situation, where an incoming request (maybe with a request variable) triggers a database query and the results are passed to the view, without any SESSION or CONVERSATION scoped objects. There may already be an example of this in the existing code, but I couldn't find it. There was always either a conversation involved or the bean that was returned had SESSION scope.
2. Add more description around the scope types.
a. Make it clear that EVENT scope doesn't survive a redirect (even though that should have been obvious to me).
b. Explain the difference between CONVERSATION scope while you're IN a conversation, vs. when you're not [when you're not, it also doesn't seem to survive the redirect, since the implicit conversation wasn't long running].
c. Explain what PAGE scope is and what it does, maybe with examples. The description itself doesn't tell me how to USE this scope, or how it differs from other scopes.
3. Describe the relationship between an action's scope and the use an extended persistence context.
a. What are the requirements on action scope (I assume you need a long running conversation or possibly session scope)
b. What are the advantages of the extended persistence context? Maybe it's just a performance optimization, but it seems like it's no different that executing "em.merge" with the entity bean.
c. What are the consequences of using an extended persistence context? Does it keep a JDBC connection open? (I assume not.) What happens if the action's context expires?