this is not pluto specific, but results from the portlet specification that requires that each portlet application is a seperate web application.
You're right that this will cause some user experience problems with the session timeouts. This is something that needs to be addressed on the servlet level to allow some kind of parent relationship between sessions.
Regards,
StefanGlenn R. Golden wrote:
I have a concern about how Pluto is designed to use separate webapps for the portal + Pluto, and for sets of portlets. The http session is scoped at the webapp (servlet context) level; if a user is interacting with many different webapps, the user has many different session objects.
This has many advantages; the larger scoping of portlet session objects is by webapp (not portal), separate webapps are protected from each other, etc.
But, here's the problem. If a user logs into a portal, and does some things here and there, establishing many sessions as the user moves around; and if the portlets the user is interacting with are keeping state in the session, which is the proper place for this, and the user stays on for a while, it's likely that some of the http sessions that represent this single portal session with this user will time out.
The session the user appears to have is with the portal, and that will stay fresh, but if the user doesn't come back to a particular portlet for a while, but does come back later, while in the same portal session, that portlet's webapp's session which has not seen any activity from this user for a while could time out and the user could be back at the starting state in that portlet.
I consider this a problem, since from the user's perspective that user has remained active, and then discovers that she has "lost work" since the state in a portlet has been cleared by the timeout.
I expect that this issue came up to the Pluto designers; I wonder what the thinking on this was, and if there's anything special in Pluto to avoid this problem, or if this was in fact considered a problem and not a further "feature".
Thanks.
- Glenn
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
