struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ana Narvaez Vila" <ana.narv...@sema.es>
Subject Re: Deactivate URL-rewriting in logoff action.
Date Fri, 16 Mar 2001 08:56:14 GMT
What I was trying to say is that when logoff action is called, my
application ends and the user goes to another location. Although I
invalidate() session in logoff, when ActionServlet forward to next page
creates a new session that is not really used by anyone.

For example, I want user to go to www.altavista.com after logoff action
so I don't need new session.

<action path="/logoff"
        type="com.company.package.LogoffAction">
        <forward name="finish" path="http://altavista.com"
redirect="true" />
</action>

Thaks

"Craig R. McClanahan" wrote:
> 
> On Thu, 15 Mar 2001, Ana Narvaez Vila wrote:
> 
> > Logoff action usually invalidates session and sends browser to a index
> > or welcome page, so it is not necesary to rewrite the URL.
> >
> > ActionServlet must have a session, so if there isn't a valid session it
> > creates one.
> > Question is: Is there a way to say to ActionServlet not to create a new
> > session ?
> >
> 
> It's not just the controller servlet that creates sessions -- JSP pages do
> as well, unless you tell them not to with a page directive:
> 
>         <%@ page session="false" %>
> 
> However, trying to run Struts based apps completely without sessions is
> going to cause you some grief in the following areas:
> 
> - Internationalized message lookups in the <bean:message>
>   tag depend on a Locale object stored in the user's session,
>   which indicates this user's current Locale preference.
> 
> - The <html:errors> mechanism for displaying validation errors
>   relies on the same thing, so you cannot use this.
> 
> My advice would be to go ahead and let the sessions be created, and
> minimize the memory occupancy by using request scope (rather than session
> scope) for all your application's form beans.  We're talking tens of bytes
> per simultaneous user for the session itself (and the associated Locale),
> so the memory requirements are not onerous -- even if it took 100 bytes
> per user, 10,000 simultaneous users is still only a megabyte.  And you are
> pretty much certain to run into other resource limits (CPU, database,
> network) before you reach that many users anyway.
> 
> Craig
------------------------------------------------------------------
This email is confidential and intended solely for the use of the individual to whom it is
addressed. Any views or opinions presented are solely those of the author and do not necessarily
represent those of Sema Group. 
If you are not the intended recipient, be advised that you have received this email in error
and that any use, dissemination, forwarding, printing, or copying of this email is strictly
prohibited.
------------------------------------------------------------------


Mime
View raw message