Built with Seam
You can find the full source code for this website in the Seam package in the directory /examples/wiki. It is licensed under the LGPL.
| Online: | 17 Members of 4546 |
| Forum: Seam Users |
 |
09. Mar 2008, 08:29 CET | Link |
I have a site that looks something like this:
home.xhtml login.xhtml profile-update.xhtml
Some of the profile attributes, which are displayed on the profile-update page are lazy loading.
In my profile-update.page.xml I declare
login-required="true"
In my login.page.xml I declare
<begin-conversation join="true" />
If I am not logged in and I come to the home page, then navigate to the login page, and then navigate to the profile-update page, everything works. And here are the conversation Ids:
home.seam - no long running conversation login.seam - 212 profile-update.seam - 212
And everything is cool.
However, if I am not logged in, and I try to get to the profile-update page directly, I am redirected to the login page (as expected), I login, and am auto-magically redirected back to the profile-update page (I don't know how this is handled). When I get to the profile-update page, I am dropped out of the conversation the login page had created, hence I can't lazy load any properties from the user object loaded from the entityManager during login.
login.seam (redirected to from the profile-update page) - 218 profile-update.seam (auto redirected to after login) - no long running conversation
It looks like whatever is handling the post-login auto-redirection back to the initially requested resource is not propagating the existing conversation.
Any ideas?
Thanks!
Devon
2 Replies: | |||
|---|---|---|---|
I think I may have discovered the cause, but not a good solution. What I believe is happening is that when org.jboss.seam.faces.Redirect is used to handle the login-required="true" redirect to login, then redirect to the initial destination flow, it is killing the conversation. When captureCurrentView is called, it creates a new Conversation (since there wasn't a long running conversation). Then, the login page joins that Conversation, since it has join=true. Then when the returnToCapturedView method is called, it executes Conversation.instance().end(); which ends the Conversation the login action had used. Does this sound like the likely cause? If so, any ideas on how to fix it? Thanks! |
|||
Sorry to keep replying to myself, but there's no edit button. What I'd meant to say was: Any ideas on how to fix it, other than putting <begin-conversation join="true" /> on every single protected page's page.xml, which works, but is a total hack? |
--
Devon Hillard
Tech Blog