struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Alexander (KADA 11)" <alexander.je...@csfs.com>
Subject RE: Multiple browser windows, different logical sessions
Date Wed, 07 Aug 2002 06:55:07 GMT
Hi,

nice to see somebody else going for the "decoration-less" browser-windows
for webapps...

As this is an intranet-webapp... Does your company restrict the user's
browser to a well defined set? Then you could add using browser-specific
features to your list of possibilities.
In an intranet-environment a possibility that I see is a signed applet
that starts a really independent copy of the browser (in order to 
create a new, independent session) by using the Runtime.exec(...). In 
an intranet-environment the plugin (for a usable jdk/jre version on the
client) could be preloaded on the clients, and the applet's jar-file
could be cached... => no performance hit if your "open new app-window"-
button is created by an applet...

Sub-dividing the session can be interesting (nice features could be
added...) and works, but is cumbersome to program...


Can you use servlet-spec 2.3 containers (Tomcat >4, WLS >6.1,...)?
Then you could write a filter and create your own session-class. The
filter also could react on certain keywords in the request and create 
new sessions on demand. The filter also could enforce the passing of
the session-id in each html-link, html-form,... (I have not yet found
the time to play with filters, but such stuff is what they can be for...)

hope this helps
Alexander


-----Original Message-----
From: Molitor, Stephen [mailto:SMolitor@erac.com]
Sent: Donnerstag, 1. August 2002 17:11
To: 'Struts Users Mailing List'
Subject: Multiple browser windows, different logical sessions


What's the most practical way to launch a new browser window, and have the
second window use a different session than the first?  Our prototype has a
'Open New Copy of Application' menu item that we need to implement.  The
idea is that this would pop-up a new browser window, just like using the
CNTRL-n key on IE, and that this copy of the app would be totally separate
from the first copy.  So, it would be nice if they had different sessions,
so that we wouldn't have to worry about them stomping on each other in the
shared session.

What's the best way to do this?  I understand that if we use URL rewriting
instead of cookies to keep track of the session id, then we could have
different sessions.  Can I, from the server, enforce URL rewriting instead
of cookie based session management, regardless of what the browser settings
are on the client?  And can I enforce URL rewriting in a portable, J2EE
compliant way?

Other options might include using the same session but sub-dividing it into
two halves, keyed by window id or some such.  For example:

Map myHalf = session.getAttribute("myWindowName");
Object someObject = myHalf.get("someObject");

Or, of course, one could try to avoid using the session entirely, and
persist client specific state via hidden variables, etc.

Any other approaches?  Any one have any experience with this?  Which
approach fits in best with Struts?

(Incidentally, our app is an internal web application, not designed to feel
like a browser.  We've disabled the navigation bars, and plan on using a
synchronizer token to detect if the user does things out of order via hot
keys (CNTRL-N, etc.).  The idea is that we know how they got to a given
page, and know when we can clear out part the session if they leave some
part of the app.  However, the 'Open New Copy of App' menu item kind of
blows that out of the water, if they could have two copies open on any
combination of two pages, sharing the same session.  We never really know
what part of the app they might still have open.  Also, the requirement is
really to allow n copies of the app open, not just two.)

Thanks!

Steve Molitor
smolitor@erac.com




--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message