Valid points all. Didn't consider that aspect of URL rewriting. However, you could prefix the sessionID with the webapp context path string and still have them be unique in your static utility class. Not a problem.
b.t.w., I wasn't suggesting that you store HTTPSession objects this way per se, it would create ClassNotFoundExceptions just as you say. In a later email in this thread (look and see), I stated that you could ONLY store objects created from classes loaded by the shared classloader as well. Both webapps would have access to these class definitions to create shared data objects and store them in the shared static utility class. So, in a single app. server environment, I still don't see why this wouldn't work for a short-term solution. Personally, however, I wouldn't do it this way, I would use an existing database if all apps. 'talk' to a common one already, and if not, fire up an out-of-the-box JBoss bundle somewhere where every app. could 'talk' to it and use CMP to get a rapid solution out there for storing data in the HypersonicSQL database that comes with JBoss (at least, it did, I'm assuming that's still the one they're using). You can always replace the CMP later. I think someone who knows EJB could build this almost as fast as the wacko solution I've been promulgating for the past two days. :) peace, Joe Barefoot > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 6:22 PM > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: RE: Please help clarify or confirm -- HttpSession > > > > > On Thu, 13 Jun 2002, Joseph Barefoot wrote: > > > Date: Thu, 13 Jun 2002 11:09:43 -0700 > > From: Joseph Barefoot <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] > > To: Struts Users Mailing List <[EMAIL PROTECTED]> > > Subject: RE: Please help clarify or confirm -- HttpSession > > > > hmmm...but the sessionIDs have to be unique, even across web > apps., correct? > > Actually, session ids do *not* have to be unique across the entire server. > Tomcat, for example, sets the "path" attribute of the session id cookie to > match the context path of the webapp, so the browser only sends the right > cookie back to the right webapp. If two session ids for different webapps > happen to be the same (possible ... it's based on a random number > generator), there is still no problem. > > > If there weren't unique, URL rewriting would not work correctly > if two users > > using two webapps on the same app. server happened to get the > same session > > ID. > > Still not a problem ... because URL rewriting only rewrites hyperlinks > that point back into the same webapp. So, you are still insulated from > any grief caused by duplicate session ids in different webapps. > > > Therefore, one *should* be able to store objects from webapp A in a > > shared classloader class keyed by the sessionID and retrieve them from > > webapp B. > > That is, unfortunately for this use case, not a valid conclusion. > > * The servlet spec states that the set of sessions for each > webapp is distinct from the set for any other webapp. > > * Even if they *were* shared, you would have serious problems. > Consider the case where you create a bean of some class that > is loaded from /WEB-INF/classes or /WEB-INF/lib, and stick it > in your session. Even if a servlet in another app could get > a reference to this HttpSession instance, it would get a > ClassNotFoundException trying to do anything with the returned > attribute, because it's implementation class is not visible > in the calling webapp's class loader. > > * If the container allows it, there is a way to do "cross context" > request dispatcher calls via ServletContext.getContext() -- but > that doesn't help you much. You cannot ask for a session by id, > so the best you could do would be start a second session in the > other app. > > > Am I missing something here? (besides why the hell you would want to do > > this) > > :) > > > > Good question :-) > > > > > joe > > > > Craig > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
